From owner-scwm-discuss@mit.edu Wed Jun 10 02:07:56 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA18532 for scwm-discuss-outgoing; Wed, 10 Jun 1998 02:07:56 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA18470; Wed, 10 Jun 1998 02:06:26 -0400 Message-Id: <199806100606.CAA18470@huis-clos.mit.edu> To: scwm-discuss@mit.edu, scwm-announce@mit.edu Subject: scwm resources moved Date: Wed, 10 Jun 1998 02:06:25 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk The scwm snapshot ftp archive and CVS repository are now at ftp://huis-clos.mit.edu/pub/scwm and huis-clos.mit.edu:/usr/local/repository respectively. Please let me know if there is a problem with the ftp site (or, if you have access, with the CVS). The mailing lists have also moved, and are now majordomo controlled. They are now at: scwm-announce@huis-clos.mit.edu and scwm-discuss@huis-clos.mit.edu You can subscribe or unsubscribe at majordomo@huis-clos.mit.edu The old lists will forward to the new lists for now, but their use is deprecated. As of now, these lists are being archived; the archives will soon be available on the web, along with the revamped scwm web site. Thank you for your patience during these changes. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Jun 11 03:42:09 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15852 for scwm-discuss-outgoing; Thu, 11 Jun 1998 03:42:09 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15848; Thu, 11 Jun 1998 03:42:07 -0400 Message-Id: <199806110742.DAA15848@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Web site redesign Date: Thu, 11 Jun 1998 03:42:06 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk The scwm web site at http://web.mit.edu/mstachow/www/scwm.html has been redesigned. It now features online archives of the scwm mailing lists (unfortunately only messages since the conversion to majordomo will be archived), somewhat more current information, and a spiffy new graphic. Your feedback is welcome. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Jun 11 03:57:03 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15944 for scwm-discuss-outgoing; Thu, 11 Jun 1998 03:57:03 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15937; Thu, 11 Jun 1998 03:57:01 -0400 Message-Id: <199806110757.DAA15937@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Better error messages Date: Thu, 11 Jun 1998 03:57:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have improved scwm's error reporting considerably in the latest snapshot. It now gives a backtrace and the expression, filename and line number where the error took place. I'd appreciate if people would test this out. Hopefully it will make diagnosing problems with config files considerably easier. After attacking the bug list a bit and dealing with a few other pending items, I will probably release 0.7 pretty soon. Could people maintaining various packages of scwm (FreeBSD port, .rpm, .deb, etc), or planning to do so who are interested in upgrading the versions let me know if there are any issues on that front that I should be aware of? I'd also like to link to the packages at the web page when they are available. Incidentally, is anyone out there maintaining an RPM of scwm? I guess I'll have to do it myself if no one else is doing it, but I won't have access to a remotely recent version of redhat for a while yet. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Jun 12 15:38:21 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01583 for scwm-discuss-outgoing; Fri, 12 Jun 1998 15:38:21 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01579; Fri, 12 Jun 1998 15:38:14 -0400 Message-Id: <199806121938.PAA01579@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Better error messages In-reply-to: Your message of "11 Jun 1998 12:46:01 +0300." Date: Fri, 12 Jun 1998 15:38:13 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Your message failed to make it to the list before due to a misconfiguration in the forwarding from the old list address to the new one. I am responding here, though. I reccomend using the new address from now on, as the old one will probably go away at some point. hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > Incidentally, is anyone out there maintaining an RPM of scwm? I guess > > I'll have to do it myself if no one else is doing it, but I won't have > > access to a remotely recent version of redhat for a while yet. > > I could make the RPM. I guess I could generate binary rpms for > linux/intel rh 4.2, linux/alpha rh 4.2 & linux/alpha rh 5.0, but I > don't know how much I'll be able to test the latter two, and as I've > only been dabbling with scwm a little, I won't test the linux/intel > version so much either. > Extensive testing is probably not important, just see if it installs and runs. However, I think glibc-based RPMS (i.e. something for Red Hat 5.0/5.1) would be most useful these days. SOmeone else can probably build those from the srpm's though. I can make all of these available on the web. I will also probably build SPARC rpms as soon as I get my SPARCstation up and running. > Is there an older source RPM I can start with? > There's been one in Red Hat contrib at some point, but I've been unable to connect to ftp.redhat.com lately to check. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Jun 18 00:48:01 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA27425 for scwm-discuss-outgoing; Thu, 18 Jun 1998 00:48:01 -0400 Received: from deimos.frii.com (deimos.frii.com [208.146.240.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA27393 for ; Thu, 18 Jun 1998 00:47:58 -0400 Received: from beehive.frii.com (cos-0126.ppp.frii.com [204.71.61.26]) by deimos.frii.com (8.9.0/8.9.0) with ESMTP id KAA29417 for ; Sat, 13 Jun 1998 10:01:23 -0600 (MDT) Received: (from samf@localhost) by beehive.frii.com (8.8.7/8.8.7) id KAA32098; Sat, 13 Jun 1998 10:02:12 -0600 To: scwm-discuss@mit.edu Subject: scwm.el font-lock in xemacs From: Sam Falkner Date: 13 Jun 1998 10:02:12 -0600 Message-ID: Lines: 51 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk i use xemacs 20.4, and the font-lock that's bundled with that doesn't have font-lock-defaults-alist. thus, the current inherit-from-scheme font-lock strategy doesn't work for xemacs. here's a diff i made that makes it work with xemacs, and i verified that it still works with GNU emacs 20.2.1 as bundled with redhat 5.0. you'll note that i've moved the work to the scwm-mode function. i don't know if that's a big deal, but it seems like you're slightly more likely to work in that context. if the scheme stuff or the font-lock stuff isn't loaded when you load scwm.el, then it'll do nothing at that time, but it'll work on a later invocation of scwm-mode if these ever do get loaded. - sam --- vendor/utilities/emacs/scwm.el Thu Jun 4 20:05:08 1998 +++ /home/samf/lib/xemacs/scwm.el Fri Jun 12 22:38:54 1998 @@ -109,7 +109,16 @@ Special commands: \\{scwm-mode-map} Turning on Scwm mode calls the value of the variable `scwm-mode-hook', -if that value is non-nil.") +if that value is non-nil." + (cond + ((and (boundp 'font-lock-defaults-alist) + (null (assq 'scwm-mode font-lock-defaults-alist))) + (setq font-lock-defaults-alist + (cons (cons 'scwm-mode + (cdr (assq 'scheme-mode font-lock-defaults-alist))) + font-lock-defaults-alist)))) + (put 'scwm-mode 'font-lock-defaults + (get 'scheme-mode 'font-lock-defaults))) (define-key scwm-mode-map [(control j)] 'scwm-eval-print) (define-key scwm-mode-map [(control c) (control s)] 'scwm-run) @@ -222,14 +231,6 @@ (with-output-to-temp-buffer "*Apropos*" (princ "SCWM apropos `") (princ pat) (princ "':\n\n") (scwm-eval (concat "(apropos \"" pat "\")") standard-output))) - -;;; font-lock (you better (require 'font-lock) before loading this file!) - -(when (boundp 'font-lock-defaults-alist) - (setq font-lock-defaults-alist - (cons (cons 'scwm-mode - (cdr (assq 'scheme-mode font-lock-defaults-alist))) - font-lock-defaults-alist))) (provide 'scwm) ;;; scwm ends here From owner-scwm-discuss@mit.edu Thu Jun 18 00:47:47 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA27257 for scwm-discuss-outgoing; Thu, 18 Jun 1998 00:47:47 -0400 Received: from pong.ping.at (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA27232 for ; Thu, 18 Jun 1998 00:47:45 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id OAA22030 for scwm-discuss@huis-clos.mit.edu; Sat, 13 Jun 1998 14:11:09 +0200 (CEST) Received: (qmail 2398 invoked by uid 115); 12 Jun 1998 13:55:30 -0000 To: scwm-discuss@mit.edu Subject: decorations & hints & stuff X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 12 Jun 1998 11:45:17 +0200 Message-ID: Lines: 34 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, this whole business is a big mess. I already reported, that windows with non-standard border-widths are placed wrongly. Another bug: setting border-width to zero (e.g. with `(window-style "*" #:border-width 0)') gives a lot of bad request, because there are no side windows, but scwm thinks they are there (`fBorder' is true). Both of these can be traced back to the confusion, when various aspects of decoration are processed: windows are placed before their border-width is known, `fBorder' is set while boundary_width is still the default (6). Rather than adding another special case for the abovementioned problems, we should perhaps try to come up with a cleaner solution. I'm sure that this is difficult business, and I admit, that I have only coarse knowledge of these matters. Anyway, can someone explain, why the following naive approach is not possible? 0. MapRequest comes in. 1. Get window title, and initialize decorations from `window-style's that apply. 2. Modify decorations by WM hints given. 3. Move window if necessary, with respect to final border-width and/or title-height 4. Map it and its decorations for real. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --LAA07975.897645065/pong.Austria.EU.net-- From owner-scwm-discuss@mit.edu Thu Jun 18 00:57:05 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01567 for scwm-discuss-outgoing; Thu, 18 Jun 1998 00:57:05 -0400 Received: from life.ai.mit.edu (life.ai.mit.edu [128.52.32.80]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA01544 for ; Thu, 18 Jun 1998 00:57:02 -0400 Received: from foo.ai.mit.edu (foo.ai.mit.edu [128.52.37.95]) by life.ai.mit.edu (8.8.8/AI1.22/ai.master.life:1.24) with ESMTP id AAA23621 for ; Thu, 18 Jun 1998 00:56:47 -0400 (EDT) From: Maciej Stachowiak Received: (from maciej@localhost) by foo.ai.mit.edu (8.8.5/AI1.15/ai.client:1.6) id AAA03083 for scwm-discuss@huis-clos.mit.edu; Thu, 18 Jun 1998 00:56:46 -0400 (EDT) Date: Thu, 18 Jun 1998 00:56:46 -0400 (EDT) Message-Id: <199806180456.AAA03083@foo.ai.mit.edu> To: scwm-discuss@mit.edu Subject: Test Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am testing if this mailing list works from a different account. The machine hosting it sems to have been misconfigured before. If this mesage arrives, the list should accept mail properly. From owner-scwm-discuss@mit.edu Thu Jun 18 00:57:49 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA02106 for scwm-discuss-outgoing; Thu, 18 Jun 1998 00:57:49 -0400 Received: from panda.mscc.huji.ac.il (panda.mscc.huji.ac.il [132.64.178.5]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA02056; Thu, 18 Jun 1998 00:57:45 -0400 Received: from z7 (1Cust141.tnt4.lax3.da.uu.net [153.37.64.141]) by panda.mscc.huji.ac.il (8.8.5/8.8.5) with SMTP id DAA82984; Thu, 18 Jun 1998 03:38:56 +0300 Date: Thu, 18 Jun 1998 03:38:56 +0300 From: 56io6r <56io6r@att.net> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, June 16th, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, June 14th, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, June 12th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, June 11th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, June 17th, 1998 Reply-To: 56io6r@att.net Sender: owner-scwm-discuss@mit.edu Precedence: bulk Authenticated sender is <56io6r@att.net> Subject: 45 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-scwm-discuss@mit.edu Thu Jun 18 00:58:39 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA02715 for scwm-discuss-outgoing; Thu, 18 Jun 1998 00:58:39 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA02696 for ; Thu, 18 Jun 1998 00:58:38 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA13910; Mon, 15 Jun 98 18:26:00 EDT Received: by tis.bellhow.com; id SAA27410; Mon, 15 Jun 1998 18:20:03 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma013002; Mon, 15 Jun 98 16:26:11 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id QAA22783 for ; Mon, 15 Jun 1998 16:26:11 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: (restart "scwm") broken Date: Mon, 15 Jun 1998 20:23:27 GMT Organization: Bell & Howell PSC Message-Id: <358b6f4b.1229742816@mailhost> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id AAA02698 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello All, I'm using scwm (6/2 snapshot) on a Solaris box. (restart "scwm") or (restart "fvwm") both restart fvwm. I remember this being asked on this list, but there was either no satisfactory repy/fix or I deleted it by accident. The guile I'm using is the 5/15 snapshot. Any fixes? Thanks, Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jun 18 03:06:29 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA22317 for scwm-discuss-outgoing; Thu, 18 Jun 1998 03:06:29 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA22306; Thu, 18 Jun 1998 03:06:28 -0400 Message-Id: <199806180706.DAA22306@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: guile-compat.[ch] Date: Thu, 18 Jun 1998 03:06:28 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I forgot to commit these files a few days ago. Now that I have real net access again, I've commited them, but it was too late for tonight's snap, so I also put them on the snapshot ftp site at ftp://huis-clos.mit.edu/pub/scwm for the time being. Sorry about that. - Maciej From owner-scwm-discuss@mit.edu Thu Jun 18 10:10:56 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31901 for scwm-discuss-outgoing; Thu, 18 Jun 1998 10:10:56 -0400 Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA31877 for ; Thu, 18 Jun 1998 10:10:54 -0400 Received: by tis.bellhow.com; id KAA09124; Thu, 18 Jun 1998 10:10:32 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma009109; Thu, 18 Jun 98 10:10:29 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA01818; Thu, 18 Jun 1998 10:10:28 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Compiling scwm on Solaris Date: Thu, 18 Jun 1998 14:07:31 GMT Organization: Bell & Howell PSC Message-ID: <358a1e55.3769690@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA31887 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings! With guile-compat.[hc] and a few changes, I have successfully built scwm 6/18 on Solaris (SunOS wgs 5.5 Generic sun4m sparc sun4m) with the 5/15 snapshot of guile. This is what I had to do: 1. init_scheme_string.c has a spurious '-n ' in the beginning. This should be discovered by configure somehow. 2. The Makefiles in libscwmexec, scmwexec and scmrepl do not have the proper include directories for Solaris. I added $(X_CFLAGS) to the definitions of COMPILE and LT_COMPILE. 2. scwm.el requires some functions that are missing in emacs 19.33 (not sure about 19.34). I found the directions to locate the function `with-output-to-string' from http://sourcery.naggum.no. Unfortunately, that file is from 20.xx and requires other functions that are not in 19.xx. Here is something that seems to work. Using `save-excursion' for `with-current-buffer' is overkill, but I don't think it hurts. Ought to wrap this with some kind of version 19 conditional. Here is what I'm using: ;; Hack (defmacro with-output-to-string (&rest body) "Execute BODY, return the text it sent to `standard-output', as a string." `(let ((standard-output (get-buffer-create (generate-new-buffer-name " *string-output*")))) (let ((standard-output standard-output)) ,@body) (save-excursion (set-buffer standard-output) (prog1 (buffer-string) (kill-buffer nil))))) The other funcitons(macros) that are missing are `when', `unless' and `second'. I just copied in the definitions from cl.el. I would guess that a (require 'cl) would do the same. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jun 18 11:33:52 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31246 for scwm-discuss-outgoing; Thu, 18 Jun 1998 11:33:52 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31225 for ; Thu, 18 Jun 1998 11:33:50 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA00847; Thu, 18 Jun 98 11:33:24 EDT Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id LAA13182; Thu, 18 Jun 1998 11:33:26 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d37.phe-pa.concentric.net [209.31.155.145]) by cliff.concentric.net (8.8.8) id LAA02233; Thu, 18 Jun 1998 11:33:24 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id LAA02180; Thu, 18 Jun 1998 11:09:47 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm.el font-lock in xemacs References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Sam Falkner's message of 13 Jun 1998 10:02:12 -0600 Date: 18 Jun 1998 11:09:46 -0400 Message-Id: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 13 Jun 1998 10:02:12 -0600 >>>> Honorable Sam Falkner writes >>>> on the subject of "scwm.el font-lock in xemacs": >> i use xemacs 20.4, and the font-lock that's bundled with that doesn't >> have font-lock-defaults-alist. thus, the current inherit-from-scheme >> font-lock strategy doesn't work for xemacs. Thanks. I modified your changes slightly; please try this. I do not want to move the code into the `define-derived-mode' form, because then they will be evaluated every time you visit a scwm buffer, while sematically it is necessary to do just once. (define-derived-mode scwm-mode scheme-mode "Scwm" "Major mode for editing scwm code. Special commands: \\{scwm-mode-map} Turning on Scwm mode calls the value of the variable `scwm-mode-hook', if that value is non-nil. If you are using Emacs 20.2 or earlier and want to use fontifications, you have to (require 'font-lock) before loading this. Sorry.") (cond ((boundp 'running-xemacs) (put 'scwm-mode 'font-lock-defaults (get 'scheme-mode 'font-lock-defaults))) ((and (string-lessp emacs-version "20.3") (boundp 'font-lock-defaults-alist)) (unless (assq 'scwm-mode font-lock-defaults-alist) (setq font-lock-defaults-alist (cons (cons 'scwm-mode (cdr (assq 'scheme-mode font-lock-defaults-alist))) font-lock-defaults-alist))))) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Why do we want intelligent terminals when there are so many stupid users? From owner-scwm-discuss@mit.edu Thu Jun 18 15:49:33 1998 Received: (from majordomo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18896 for scwm-discuss-outgoing; Thu, 18 Jun 1998 15:49:33 -0400 Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18854; Thu, 18 Jun 1998 15:49:29 -0400 Message-Id: <199806181949.PAA18854@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: decorations & hints & stuff In-reply-to: Your message of "12 Jun 1998 11:45:17 +0200." Date: Thu, 18 Jun 1998 15:49:28 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > this whole business is a big mess. I already reported, that windows > with non-standard border-widths are placed wrongly. > > Another bug: setting border-width to zero (e.g. with `(window-style > "*" #:border-width 0)') gives a lot of bad request, because there are > no side windows, but scwm thinks they are there (`fBorder' is true). > > Both of these can be traced back to the confusion, when various > aspects of decoration are processed: windows are placed before their > border-width is known, `fBorder' is set while boundary_width is still > the default (6). > > Rather than adding another special case for the abovementioned > problems, we should perhaps try to come up with a cleaner solution. > Yes, everything there is pretty much a kludge on top of the original fvwm2 kludge. > I'm sure that this is difficult business, and I admit, that I have > only coarse knowledge of these matters. Anyway, can someone explain, > why the following naive approach is not possible? > > 0. MapRequest comes in. > 1. Get window title, and initialize decorations from `window-style's > that apply. > 2. Modify decorations by WM hints given. > 3. Move window if necessary, with respect to final border-width and/or > title-height > 4. Map it and its decorations for real. > That sounds reasonable. The trick is that the procedures that set the style options would have to know how to do their business on either a totally undecorated window, i.e. when initializing, or on an existing window when changing options on the fly. This is the key work that has not been done yet. It does need to be done at some point, or these things will continue to haunt us. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Jun 18 22:18:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02154 for scwm-discuss-outgoing; Thu, 18 Jun 1998 22:18:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02147; Thu, 18 Jun 1998 22:18:35 -0400 Message-Id: <199806190218.WAA02147@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: (restart "scwm") broken In-reply-to: Your message of "Mon, 15 Jun 1998 20:23:27 GMT." <358b6f4b.1229742816@mailhost> Date: Thu, 18 Jun 1998 22:18:35 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Hello All, > > I'm using scwm (6/2 snapshot) on a Solaris box. > > (restart "scwm") or (restart "fvwm") both restart fvwm. I remember this bein > g > asked on this list, but there was either no satisfactory repy/fix or I delete > d > it by accident. The guile I'm using is the 5/15 snapshot. > > Any fixes? I've fixed it in CVS; it should be better in tomorrow's snap. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 19 00:30:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA03008 for scwm-discuss-outgoing; Fri, 19 Jun 1998 00:30:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA03004; Fri, 19 Jun 1998 00:30:09 -0400 Message-Id: <199806190430.AAA03004@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Guile 1.2 Date: Fri, 19 Jun 1998 00:30:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've restored Guile 1.2 compatability; the changes should be available in the next snapshot. I'd appreciate if people using Guile 1.2 would test this for me. I tested it against 1.2 myself, but I may have missed something. I will try to maintain compatability at least until the next release, and possibly until guile 1.3 is officially released, if that happens anytime soon. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 19 01:16:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA03409 for scwm-discuss-outgoing; Fri, 19 Jun 1998 01:16:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA03402; Fri, 19 Jun 1998 01:16:19 -0400 Message-Id: <199806190516.BAA03402@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: Compiling scwm on Solaris In-reply-to: Your message of "Thu, 18 Jun 1998 14:07:31 GMT." <358a1e55.3769690@mailhost> Date: Fri, 19 Jun 1998 01:16:19 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Greetings! > > With guile-compat.[hc] and a few changes, I have successfully built > scwm 6/18 on Solaris (SunOS wgs 5.5 Generic sun4m sparc sun4m) with the > 5/15 snapshot of guile. This is what I had to do: > You'll have to help me out on this stuff because I don't currently have easy access to a Solaris box. > 1. init_scheme_string.c has a spurious '-n ' in the beginning. This > should be discovered by configure somehow. > As I recall, this was a problem with `echo' on Solaris, and the way this file is generated. Instead of trying to detect wether or not echo accepts `-n', I've made the Makefile not use `-n' in any case, and merely add a trailing backslash to the line it echos. > 2. The Makefiles in libscwmexec, scmwexec and scmrepl do not have the > proper include directories for Solaris. I added $(X_CFLAGS) to the > definitions of COMPILE and LT_COMPILE. > I fixed the Makefile.am's so this shouldn't be a problem any more. > 2. scwm.el requires some functions that are missing in emacs 19.33 OA> (not sure about 19.34). I found the directions to locate the > function `with-output-to-string' from http://sourcery.naggum.no. > Unfortunately, that file is from 20.xx and requires other functions > that are not in 19.xx. Here is something that seems to work. > Using `save-excursion' for `with-current-buffer' is overkill, but I > don't think it hurts. Ought to wrap this with some kind of version > 19 conditional. Here is what I'm using: > > ;; Hack > (defmacro with-output-to-string (&rest body) > "Execute BODY, return the text it sent to `standard-output', as a = > string." > `(let ((standard-output > (get-buffer-create (generate-new-buffer-name " *string-output*")))) > (let ((standard-output standard-output)) > ,@body) > (save-excursion > (set-buffer standard-output) > (prog1 > (buffer-string) > (kill-buffer nil))))) > > The other funcitons(macros) that are missing are `when', `unless' > and `second'. I just copied in the definitions from cl.el. I would > guess that a (require 'cl) would do the same. > Well, Sam Steingold is the resident emacs expert, I will have to defer to him on this one. I'd also like to hear about build problems anyone else is having, or bugs you are experiencing; I'd like to fix as many of these as possible before getting the rapidly upcoming release out. Thanks, - Maciej From owner-scwm-discuss@mit.edu Fri Jun 19 10:47:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA06349 for scwm-discuss-outgoing; Fri, 19 Jun 1998 10:47:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA06346 for ; Fri, 19 Jun 1998 10:47:23 -0400 Received: by tis.bellhow.com; id KAA29881; Fri, 19 Jun 1998 10:47:14 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma029853; Fri, 19 Jun 98 10:47:11 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA01520; Fri, 19 Jun 1998 10:47:10 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Compiling scwm on Solaris Date: Fri, 19 Jun 1998 14:44:13 GMT Organization: Bell & Howell PSC Message-ID: <358b76f0.91988762@mailhost> References: <199806190516.BAA03402@huis-clos.mit.edu> In-Reply-To: <199806190516.BAA03402@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA06347 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Fri, 19 Jun 1998 01:16:19 EDT, you wrote: >You'll have to help me out on this stuff because I don't currently >have easy access to a Solaris box. Compiled great right-out-of-the-box! I just had to add my scwm.el changes. >> 2. scwm.el requires some functions that are missing in emacs 19.33 ... >> Here is what I'm using: ... >> > >Well, Sam Steingold is the resident emacs expert, I will have to defer >to him on this one. I have added some conditionals around the code that is in 20.xx. Sam has my changes. BTW: The new restart code seems to be working great. Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Fri Jun 19 11:19:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06559 for scwm-discuss-outgoing; Fri, 19 Jun 1998 11:19:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA06556 for ; Fri, 19 Jun 1998 11:19:33 -0400 Received: by tis.bellhow.com; id LAA05226; Fri, 19 Jun 1998 11:19:14 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005148; Fri, 19 Jun 98 11:18:35 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA02762 for ; Fri, 19 Jun 1998 11:18:35 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: BUG: Menu wierdness Date: Fri, 19 Jun 1998 15:15:37 GMT Organization: Bell & Howell PSC Message-ID: <358c7a5a.92862439@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA06557 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi All, I have noticed a small but annoying bug with menus. Using the sample.scwmrc, click Mouse-1 on the root window. The Utilities menu pops up. Slide the mouse down until it is over the Desks item. Slide the mouse to the right until the sub-menu pops up. When you move the mouse into the sub-menu, it goes away. Do it again and it stays. Arrggg! It does not happen if you just wait until the submenu pops up on it's own. If does not happen if you have a submenu with out a title. Also: (use-modules (app scwm std-menus)) is broken on my system because there is no xlock. If I try to use it, the rest of my .scwmrc is not read, so none of my menus are defined, so I can't do anything. Is there some way to check if xlock exists first? Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Fri Jun 19 12:21:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA06821 for scwm-discuss-outgoing; Fri, 19 Jun 1998 12:21:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA06818 for ; Fri, 19 Jun 1998 12:21:33 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA20195; Fri, 19 Jun 98 12:21:22 EDT Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id MAA02509; Fri, 19 Jun 1998 12:21:19 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d16.phe-pa.concentric.net [209.31.155.28]) by mcfeely.concentric.net (8.8.8) id MAA05786; Fri, 19 Jun 1998 12:21:17 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id MAA05171; Fri, 19 Jun 1998 12:20:27 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: Menu wierdness References: <358c7a5a.92862439@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of Fri, 19 Jun 1998 15:15:37 GMT Date: 19 Jun 1998 12:20:26 -0400 Message-Id: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <358c7a5a.92862439@mailhost> >>>> Sent on Fri, 19 Jun 1998 15:15:37 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "BUG: Menu wierdness": >> >> (use-modules (app scwm std-menus)) is broken on my system because there is no >> xlock. If I try to use it, the rest of my .scwmrc is not read, so none of my >> menus are defined, so I can't do anything. Is there some way to check if >> xlock exists first? I fixed this and scwm.el too and will commit them to the csv repository as soon as my ssh problems are fixed. Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Only adults have difficulty with childproof caps. From owner-scwm-discuss@mit.edu Fri Jun 19 12:57:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07126 for scwm-discuss-outgoing; Fri, 19 Jun 1998 12:57:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA07123 for ; Fri, 19 Jun 1998 12:57:09 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27920; Fri, 19 Jun 98 12:56:59 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA14490; Fri, 19 Jun 1998 09:56:53 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: Menu wierdness References: <358c7a5a.92862439@mailhost> From: Greg Badros Date: 19 Jun 1998 09:56:52 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Fri, 19 Jun 1998 15:15:37 GMT" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > I have noticed a small but annoying bug with menus. > > Using the sample.scwmrc, click Mouse-1 on the root window. The Utilities menu > pops up. Slide the mouse down until it is over the Desks item. Slide the > mouse to the right until the sub-menu pops up. When you move the mouse into > the sub-menu, it goes away. Do it again and it stays. Arrggg! > > It does not happen if you just wait until the submenu pops up on it's own. > > If does not happen if you have a submenu with out a title. I can look into this, but it won't happen until early next week. Thanks for the bug report. Greg From owner-scwm-discuss@mit.edu Fri Jun 19 14:54:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07906 for scwm-discuss-outgoing; Fri, 19 Jun 1998 14:54:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07897; Fri, 19 Jun 1998 14:54:24 -0400 Message-Id: <199806191854.OAA07897@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: BUG: Menu wierdness In-reply-to: Your message of "19 Jun 1998 12:20:26 EDT." Date: Fri, 19 Jun 1998 14:54:23 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > I fixed this and scwm.el too and will commit them to the csv repository > as soon as my ssh problems are fixed. > Hi, The ssh problems were due to the server side, I believe they are fixed now. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 19 16:20:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA08952 for scwm-discuss-outgoing; Fri, 19 Jun 1998 16:20:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA08949 for ; Fri, 19 Jun 1998 16:20:05 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA14911; Fri, 19 Jun 98 16:19:46 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id QAA06771; Fri, 19 Jun 1998 16:19:45 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d16.phe-pa.concentric.net [209.31.155.28]) by newman.concentric.net (8.8.8) id QAA29427; Fri, 19 Jun 1998 16:19:43 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id QAA15516; Fri, 19 Jun 1998 16:01:34 -0400 To: Maciej Stachowiak Cc: Bucky LaDieu , scwm-discuss@mit.edu Subject: Re: emacs install References: <199804070423.AAA05968@lady-slings-the-booze.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Sam Steingold's message of 07 Apr 1998 09:49:55 -0400 Date: 19 Jun 1998 16:01:33 -0400 Message-Id: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Apparently, the issue of scwm.el is still not resolved. scwm.el is installed in /usr/local/share/emacs/site-lisp/ which is quite useless. I would like to repeat my suggestion that emacs installation should be done by emacs. Let me repeat: *.el* are completely useless without an emacs (that stands for Emacs or XEmacs). There is absolutely no point in creating the directory /usr/local/share/emacs/site-lisp unless it is in the load path, and of course it is not (why would a non-existent directory be in the load-path?) It would seem to be a *trivial* task to put scwm.el* in the right place: put the following into the file zz.el and do $ emacs --batch -l zz.el || xemacs --batch -l zz.el ------------------------------ zz.el ---------------------------- (require 'cl) (let* ((dd (find-if (lambda (path) (and (string-match "site-lisp.?$" path) (not (string-match (number-to-string emacs-major-version) path)))) load-path)) (fl (expand-file-name "scwm.el" dd))) (copy-file "scwm.el" fl t t) (byte-compile-file fl)) ------------------------------ zz.el ---------------------------- why can't we do this? Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. The software said it requires Windows 3.1 or better, so I installed Linux. From owner-scwm-discuss@mit.edu Fri Jun 19 16:27:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA09039 for scwm-discuss-outgoing; Fri, 19 Jun 1998 16:27:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA09033; Fri, 19 Jun 1998 16:27:21 -0400 Message-Id: <199806192027.QAA09033@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu, nega@vt.edu Subject: Re: emacs install In-reply-to: Your message of "19 Jun 1998 16:01:33 EDT." Date: Fri, 19 Jun 1998 16:27:21 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > Apparently, the issue of scwm.el is still not resolved. OK, I will try applying your solution although I have some concerns; in particular, on some systems it may not be a good thing to install things in the orefix of emacs. On the other hand, perhaps it is the responsibility of the sysadmin to make sure the site-lisp directory is in an appropriate place for site-specific installation. So I'll try doing it this way for now, since scwm.el should work out of the box. I'll also take this up with the Automake maintainer; Automake should probably do the right thing in general for elisp files. - Maciej From owner-scwm-discuss@mit.edu Sat Jun 20 02:08:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA12052 for scwm-discuss-outgoing; Sat, 20 Jun 1998 02:08:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA12047; Sat, 20 Jun 1998 02:08:05 -0400 Message-Id: <199806200608.CAA12047@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: emacs install In-reply-to: Your message of "19 Jun 1998 16:01:33 EDT." Date: Sat, 20 Jun 1998 02:08:05 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > $ emacs --batch -l zz.el || xemacs --batch -l zz.el > > ------------------------------ zz.el ---------------------------- > (require 'cl) > (let* ((dd (find-if (lambda (path) > (and (string-match "site-lisp.?$" path) > (not (string-match > (number-to-string emacs-major-version) > path)))) > load-path)) > (fl (expand-file-name "scwm.el" dd))) > (copy-file "scwm.el" fl t t) > (byte-compile-file fl)) > ------------------------------ zz.el ---------------------------- > OK, I was about to use this, but I have a question. Is it crucial to this code that the file be copied to the proper location before it gets byte-compiled? I'd like to keep the compilation and installation separate. - Maciej From owner-scwm-discuss@mit.edu Sat Jun 20 08:11:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA13827 for scwm-discuss-outgoing; Sat, 20 Jun 1998 08:11:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA13824 for ; Sat, 20 Jun 1998 08:11:21 -0400 Received: from iglou2.iglou.com by MIT.EDU with SMTP id AA27547; Sat, 20 Jun 98 08:10:58 EDT Received: from localhost [204.255.239.86] by iglou.com with smtp (8.7.3/8.6.12) id 0ynMTx-0000Fv-00; Sat, 20 Jun 1998 08:10:58 -0400 Date: Sat, 20 Jun 1998 08:11:38 -0400 (EDT) From: "David E. Brooks Jr" X-Sender: dbj@localhost To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: emacs install In-Reply-To: <199806200608.CAA12047@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sat, 20 Jun 1998, Maciej Stachowiak wrote: [ Elisp code snipped ] > OK, I was about to use this, but I have a question. Is it crucial to > this code that the file be copied to the proper location before it > gets byte-compiled? I'd like to keep the compilation and installation > separate. > > - Maciej > It's not necessary to move a .el to its destination directory before compilation (At least, that's what a simple test showed me). Somewhat related (and somebody correct me if I'm wrong), but aren't the .elc files supposed to be able to run on any relatively modern version of emacs (GNU 19/20 and XEmacs 19/20). This assumes the code is fully conditionalized for the various incarnations of Emacs, of course. If this is true, then the code in question can be precompiled to save a few headaches. By the way (and if this was already mentioned, I'll flay myself with wet noodles for not reading more closely), how are multiple installations of the various Emacsen going to be handled? A fair number of people install both GNU Emacs and XEmacs on communal machines just to provide the option to their users. (For what it's worth, I'd rather have a pointer to an 'extras' directory in the documentation for this kind of stuff since it's not directly scwm related, per se.) -- Dave -- David E. Brooks Jr dbj@iglou.com From owner-scwm-discuss@mit.edu Sat Jun 20 10:28:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA14326 for scwm-discuss-outgoing; Sat, 20 Jun 1998 10:28:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA14323 for ; Sat, 20 Jun 1998 10:28:29 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id QAA17096 for scwm-discuss@huis-clos.mit.edu; Sat, 20 Jun 1998 16:28:02 +0200 (CEST) Received: (qmail 815 invoked by uid 115); 19 Jun 1998 08:03:38 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm.el font-lock in xemacs References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Fri_Jun_19_10:03:37_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 19 Jun 1998 10:03:37 +0200 In-Reply-To: Sam Steingold's message of "18 Jun 1998 11:09:46 -0400" Message-ID: Lines: 53 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" X-Now-Playing: Sonata in F Major - The Newberry Consort Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Fri_Jun_19_10:03:37_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On 18 Jun 1998 11:09:46 -0400 >>>>> Sam Steingold said: Sam> Thanks. I modified your changes slightly; please try this. I do Sam> not want to move the code into the `define-derived-mode' form, Sam> because then they will be evaluated every time you visit a scwm Sam> buffer, while sematically it is necessary to do just once. This makes problems with autoloading: scwm.el is not loaded when scwm-mode is executed - therefore neither the keymap, nor fontification is set correctly. This is because (at least in XEmacs 20.4) the `define-derived-mode' form is put into the autoload file directly. Please try the following: --Multipart_Fri_Jun_19_10:03:37_1998-1 Content-Type: text/plain; charset=US-ASCII Index: scwm.el =================================================================== RCS file: /usr/src/cvs/scwm/utilities/emacs/scwm.el,v retrieving revision 1.8 diff -u -u -r1.8 scwm.el --- scwm.el 1998/06/18 16:20:15 1.8 +++ scwm.el 1998/06/19 07:56:17 @@ -103,7 +103,7 @@ ;; user functions ;; ---- --------- -;;;###autoload +;;;###autoload (autoload 'scwm-mode "scwm" "Major mode for editing scwm code..." t) (define-derived-mode scwm-mode scheme-mode "Scwm" "Major mode for editing scwm code. Special commands: --Multipart_Fri_Jun_19_10:03:37_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Fri_Jun_19_10:03:37_1998-1-- From owner-scwm-discuss@mit.edu Sun Jun 21 20:18:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20242 for scwm-discuss-outgoing; Sun, 21 Jun 1998 20:18:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20148; Sun, 21 Jun 1998 20:18:32 -0400 Message-Id: <199806220018.UAA20148@huis-clos.mit.edu> To: "David E. Brooks Jr" cc: scwm-discuss@mit.edu Subject: Re: emacs install In-reply-to: Your message of "Sat, 20 Jun 1998 08:11:38 EDT." Date: Sun, 21 Jun 1998 20:18:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk For now I've dealt with the emacs problem by adding a --with-lispdir=DIR option to configure; the default behavior is still to install in scwm's prefix (for, say, convenient relocatable RPMs), but people who want it to work with a specific emacs set up can easily do it. dbj@iglou.com writes: > By the way (and if this was already mentioned, I'll flay myself with > wet noodles for not reading more closely), how are multiple > installations of the various Emacsen going to be handled? A fair > number of people install both GNU Emacs and XEmacs on communal > machines just to provide the option to their users. > I'd reccomend configuring both emacsen to be able to get at an appropriate shared site-lisp dir. > (For what it's worth, I'd rather have a pointer to an 'extras' > directory in the documentation for this kind of stuff since it's not > directly scwm related, per se.) It used to not get installed at all, but Automake makes it so easy to compile and install (literally a one-line Makefile.am) that I thought it would be wasteful not to. - Maciej From owner-scwm-discuss@mit.edu Sun Jun 21 20:34:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20516 for scwm-discuss-outgoing; Sun, 21 Jun 1998 20:34:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA20513 for ; Sun, 21 Jun 1998 20:34:44 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00992; Sun, 21 Jun 98 20:34:30 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA08839; Sun, 21 Jun 1998 17:34:31 -0700 (PDT) To: "David E. Brooks Jr" Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: emacs install References: From: Greg Badros Date: 21 Jun 1998 17:34:31 -0700 In-Reply-To: "David E. Brooks Jr"'s message of "Sat, 20 Jun 1998 08:11:38 -0400 (EDT)" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "David E. Brooks Jr" writes: > Somewhat related (and somebody correct me if I'm wrong), but aren't > the .elc files supposed to be able to run on any relatively modern > version of emacs (GNU 19/20 and XEmacs 19/20). This assumes the code > is fully conditionalized for the various incarnations of Emacs, of > course. If this is true, then the code in question can be > precompiled to save a few headaches. I'm pretty sure .elc files that use macros (and perhaps some other features) are not compatible across as many versions of emacs as you'd like. In particular, GNU Emacs 19.29 changed the byte-compilation format from GNU Emacs 19.28 (backwardly compatible -- 19.28 .elc files will run [a bit slower] on 19.29 GNU Emacs). Also XEmacs and Emacs .elc files have demonstrated some quirkiness for me when used with the editor that did not compile them. Greg From owner-scwm-discuss@mit.edu Sun Jun 21 22:23:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA21501 for scwm-discuss-outgoing; Sun, 21 Jun 1998 22:23:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA21498 for ; Sun, 21 Jun 1998 22:23:43 -0400 Received: from inferno.cs.univ-paris8.fr by MIT.EDU with SMTP id AA02568; Sun, 21 Jun 98 22:23:27 EDT Received: from neptune.bocal.cs.univ-paris8.fr (neptune.bocal.cs.univ-paris8.fr [192.168.3.2]) by inferno.cs.univ-paris8.fr (8.8.7/8.7.3) with ESMTP id EAA25649 for ; Mon, 22 Jun 1998 04:21:39 +0200 (CEST) Received: from ocean.bocal.cs.univ-paris8.fr (ocean.bocal.cs.univ-paris8.fr [192.168.2.3]) by neptune.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with ESMTP id EAA24981 for ; Mon, 22 Jun 1998 04:25:30 +0200 (MET DST) Received: from ocean.bocal.cs.univ-paris8.fr (localhost [127.0.0.1]) by ocean.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with SMTP id DAA28131 for ; Mon, 22 Jun 1998 03:25:20 +0100 (WET DST) Message-Id: <358DC090.4778@bocal.cs.univ-paris8.fr> Date: Mon, 22 Jun 1998 03:25:20 +0100 From: Kamel Sehil Organization: univ PARIS VIII X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: scwm-discuss@mit.edu Subject: scwm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk hello people's i have a question and a sugestion i love scwm but why do not make the WM base more simple !! small widgets !!! minimum capacity a mix betwen twm and 9wm !!, or is it a way with scheme script to remove all widgets ??? my desir is to have a WM like 9wm or twm , but with everything can be done with the keyboard , so i don't not really need widget !!! if it's not possible at this stade of scwm , i can try to work on it thanks for reading and sorry for my so bad english From owner-scwm-discuss@mit.edu Mon Jun 22 00:04:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22015 for scwm-discuss-outgoing; Mon, 22 Jun 1998 00:04:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22007; Mon, 22 Jun 1998 00:03:12 -0400 Message-Id: <199806220403.AAA22007@huis-clos.mit.edu> To: Kamel Sehil cc: scwm-discuss@mit.edu Subject: Re: scwm In-reply-to: Your message of "Mon, 22 Jun 1998 03:25:20 BST." <358DC090.4778@bocal.cs.univ-paris8.fr> Date: Mon, 22 Jun 1998 00:03:02 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk skel@bocal.cs.univ-paris8.fr writes: > hello people's i have a question and a sugestion > i love scwm but why do not make the WM base more simple !! > small widgets !!! > minimum capacity > a mix betwen twm and 9wm !!, or is it a way with scheme script to remove > all widgets ??? > my desir is to have a WM like 9wm or twm , but with everything can be > done with the keyboard , so i don't not really need widget !!! > if it's not possible at this stade of scwm , i can try to work on it > It's not possible yet, but one of the orignal goals was to make the decorations dynamically loadable, including the option of no decorations or minimal decorations. If you want to work on this, I'd be glad to discuss the architecture. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 22 00:17:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22090 for scwm-discuss-outgoing; Mon, 22 Jun 1998 00:17:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA22087 for ; Mon, 22 Jun 1998 00:17:10 -0400 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA12720; Mon, 22 Jun 98 00:16:57 EDT Received: from baguette (chlh.tbit.dk [194.182.135.163]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id GAA04347 for ; Mon, 22 Jun 1998 06:16:43 +0200 (MET DST) From: chl@tbit.dk (Christian Lynbech on satellite) Received: by baguette id m0ynxzS-000yWfC (Debian Smail-3.2.0.92 1997-Feb-9 #2); Mon, 22 Jun 1998 06:13:58 +0200 (CEST) Message-Id: Date: Mon, 22 Jun 1998 06:13:58 +0200 (CEST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Re: emacs install In-Reply-To: References: X-Mailer: VM 6.34 under Emacs 19.34.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> "David E. Brooks Jr" writes: >> Somewhat related (and somebody correct me if I'm wrong), but aren't >> the .elc files supposed to be able to run on any relatively modern >> version of emacs (GNU 19/20 and XEmacs 19/20). Greg> I'm pretty sure .elc files that use macros (and perhaps some other Greg> features) are not compatible across as many versions of emacs as you'd Greg> like. There are also problems with running GNU 20.2 compiled .elcs under 19.34. The problem manifests itself in the manner of `#:invalid read syntax', but not all packages are affected, so this is perhaps avoidable. The radical cure is of course to set `byte-compile-compatibility' to `t'. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Mon Jun 22 00:18:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22094 for scwm-discuss-outgoing; Mon, 22 Jun 1998 00:18:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22082; Mon, 22 Jun 1998 00:17:22 -0400 Message-Id: <199806220417.AAA22082@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Prerelease for 0.7 Date: Mon, 22 Jun 1998 00:16:56 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've placed scwm-0.6c.tgz and scwm-icons-0.6c.tgz on the snapshot site. These are essentially identical to what I hope to release for 0.7; if no one points out sever bugs by tomorrow night, I will release it as 0.7 (bumping the version number of course). Bugs I know about but am not expecting to fix for this release: * The menu problem reported recently; Greg said he'd deal sometime next week, so I will leave it to him. * The various problems with changing the border size; these are mostly cosmetic issues, and are hard to fix properly without a large rewrite. Also, I do still remember the various feature patches I've gotten from people (X-property-notify hooks, basic internationalization, Imlib support) and have them in my queue, but they require a fair amount of integration work. I will apply them as soon as 0.7 is out. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 22 09:49:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA25295 for scwm-discuss-outgoing; Mon, 22 Jun 1998 09:49:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA25292 for ; Mon, 22 Jun 1998 09:49:10 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA04198; Mon, 22 Jun 98 09:49:09 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id JAA06927; Mon, 22 Jun 1998 09:49:07 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d15.phe-pa.concentric.net [209.31.155.75]) by newman.concentric.net (8.8.8) id JAA02561; Mon, 22 Jun 1998 09:49:05 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id JAA18295; Mon, 22 Jun 1998 09:46:10 -0400 To: Maciej Stachowiak Cc: "David E. Brooks Jr" , scwm-discuss@mit.edu Subject: Re: emacs install References: <199806220018.UAA20148@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of Sun, 21 Jun 1998 20:18:32 EDT Date: 22 Jun 1998 09:46:09 -0400 Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199806220018.UAA20148@huis-clos.mit.edu> >>>> Sent on Sun, 21 Jun 1998 20:18:32 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: emacs install": >> For now I've dealt with the emacs problem by adding a >> --with-lispdir=DIR option to configure; the default behavior is still >> to install in scwm's prefix (for, say, convenient relocatable RPMs), >> but people who want it to work with a specific emacs set up can easily >> do it. Good idea. Why don't you add an option to have --with-lispdir be an executable (presumed to be a flavor of Emacs), which then will be used to find out the installation directory (using my code), and then to compile the installked scwm.el? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. There are two ways to write error-free programs; only the third one works. From owner-scwm-discuss@mit.edu Mon Jun 22 09:49:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA25300 for scwm-discuss-outgoing; Mon, 22 Jun 1998 09:49:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA25297 for ; Mon, 22 Jun 1998 09:49:14 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA04207; Mon, 22 Jun 98 09:49:13 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id JAA06931; Mon, 22 Jun 1998 09:49:09 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d15.phe-pa.concentric.net [209.31.155.75]) by newman.concentric.net (8.8.8) id JAA02571; Mon, 22 Jun 1998 09:49:07 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id JAA18226; Mon, 22 Jun 1998 09:41:28 -0400 To: "David E. Brooks Jr" Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: emacs install References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: "David E. Brooks Jr"'s message of Sat, 20 Jun 1998 08:11:38 -0400 (EDT) Date: 22 Jun 1998 09:41:28 -0400 Message-Id: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on Sat, 20 Jun 1998 08:11:38 -0400 (EDT) >>>> Honorable "David E. Brooks Jr" writes >>>> on the subject of "Re: emacs install": >> >> Somewhat related (and somebody correct me if I'm wrong), but aren't >> the .elc files supposed to be able to run on any relatively modern >> version of emacs (GNU 19/20 and XEmacs 19/20). This assumes the code >> is fully conditionalized for the various incarnations of Emacs, of >> course. If this is true, then the code in question can be >> precompiled to save a few headaches. FALSE! elc compiled with e19, e20, xe19 and xe20 are mutually incompatible. even elc compiled with e20.2/MBSK and e20.2.95 (pretest) are incompatible. To be shure, this doesn't mean that you *will* get a problem, just that you *might* get a problem. >> By the way (and if this was already mentioned, I'll flay myself with >> wet noodles for not reading more closely), how are multiple >> installations of the various Emacsen going to be handled? A fair >> number of people install both GNU Emacs and XEmacs on communal >> machines just to provide the option to their users. dunno. options are: 1. put the files in separate directories; 2. rename scwm.elc to scwm-e20.elc, scwm-x20.ecl etc. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Why use Windows, when there are Doors? From owner-scwm-discuss@mit.edu Mon Jun 22 11:14:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA25914 for scwm-discuss-outgoing; Mon, 22 Jun 1998 11:14:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA25911 for ; Mon, 22 Jun 1998 11:14:33 -0400 Received: from pat.uio.no by MIT.EDU with SMTP id AA27835; Mon, 22 Jun 98 11:14:32 EDT Received: from octarine.uio.no (actually octarine.uio.no [129.240.186.25]) by pat.uio.no with SMTP (PP); Mon, 22 Jun 1998 17:12:41 +0200 Received: by octarine.uio.no ; Mon, 22 Jun 1998 17:12:40 +0200 (MET DST) To: scwm-discuss@mit.edu Subject: Re: Prerelease for 0.7 References: <199806220417.AAA22082@huis-clos.mit.edu> Mime-Version: 1.0 From: Harald Meland Date: 22 Jun 1998 17:12:40 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 22 Jun 1998 00:16:56 EDT" Message-Id: Lines: 21 X-Mailer: Gnus v5.6.11/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk [Maciej Stachowiak] > I've placed scwm-0.6c.tgz and scwm-icons-0.6c.tgz on the snapshot > site. That's huis-clos.mit.edu, right? It could be just me that are having problems, but anyway, here goes: The ftp server is generally rather slow on responses, and > get scwm-0.6c.tgz scwm-icons-0.6c.tgz scwm-0.6c.tgz: Permission denied. Error: Host is not responding to commands, hanging up. Repeatedly. If this is due to high load caused by your pretest mail, it's kinda cool, but annoying. If it's due to most anything else, it's just plain annoying :) -- Harald From owner-scwm-discuss@mit.edu Mon Jun 22 11:24:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA26016 for scwm-discuss-outgoing; Mon, 22 Jun 1998 11:24:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA26013 for ; Mon, 22 Jun 1998 11:24:18 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA00951; Mon, 22 Jun 98 11:24:01 EDT Received: (from rebecka@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA26004; Mon, 22 Jun 1998 11:23:36 -0400 From: Rebecka Schulman Message-Id: <199806221523.LAA26004@huis-clos.mit.edu> To: Harald Meland Cc: scwm-discuss@mit.edu Subject: FTP site fixed Date: Mon, 22 Jun 1998 11:23:36 EDT Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message , harald.meland@usit.uio.no writes: >[Maciej Stachowiak] > >> I've placed scwm-0.6c.tgz and scwm-icons-0.6c.tgz on the snapshot >> site. > >That's huis-clos.mit.edu, right? yes > >It could be just me that are having problems, but anyway, here goes: >The ftp server is generally rather slow on responses, and > > > get scwm-0.6c.tgz scwm-icons-0.6c.tgz > > scwm-0.6c.tgz: Permission denied. > Error: Host is not responding to commands, hanging up. This should be fixed. I am the maintainer of huis-clos.mit.edu, and moved the files into the ftp site last night, but unfortunately I failed to check the permissions. huis-clos has had other problems, including a breakin, so a reinstall happened this weekend. Sorry to those of you who were trying to download scwm Saturday or Sunday. Everything should be up for the forseeable future. Rebecca > >Repeatedly. If this is due to high load caused by your pretest mail, >it's kinda cool, but annoying. If it's due to most anything else, >it's just plain annoying :) > >-- >Harald From owner-scwm-discuss@mit.edu Mon Jun 22 12:00:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA26464 for scwm-discuss-outgoing; Mon, 22 Jun 1998 12:00:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA26460 for ; Mon, 22 Jun 1998 12:00:24 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id SAA16757 for scwm-discuss@huis-clos.mit.edu; Mon, 22 Jun 1998 18:00:21 +0200 (CEST) Received: (qmail 4697 invoked by uid 115); 22 Jun 1998 07:58:46 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm References: <358DC090.4778@bocal.cs.univ-paris8.fr> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 22 Jun 1998 09:58:45 +0200 In-Reply-To: Kamel Sehil's message of "Mon, 22 Jun 1998 03:25:20 +0100" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 22 Jun 1998 03:25:20 +0100 >>>>> Kamel Sehil said: Kamel> my desir is to have a WM like 9wm or twm , but with everything Kamel> can be done with the keyboard , so i don't not really need Kamel> widget !!! my scwmrc uses *no* decorations, everything can be done from the keyboard (but also with the mouse, if you're that inclined). (Full scwmrc sent to Kamel in private e-mail - if others are interested in it, just holler.) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jun 22 12:00:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA26461 for scwm-discuss-outgoing; Mon, 22 Jun 1998 12:00:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA26456 for ; Mon, 22 Jun 1998 12:00:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id SAA16735 for scwm-discuss@huis-clos.mit.edu; Mon, 22 Jun 1998 18:00:17 +0200 (CEST) Received: (qmail 7281 invoked by uid 115); 22 Jun 1998 08:27:20 -0000 To: scwm-discuss@mit.edu Subject: Re: emacs install References: <199806220018.UAA20148@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 22 Jun 1998 10:27:15 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 21 Jun 1998 20:18:32 EDT" Message-ID: Lines: 30 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 21 Jun 1998 20:18:32 EDT >>>>> Maciej Stachowiak said: Maciej> For now I've dealt with the emacs problem by adding a Maciej> --with-lispdir=DIR option to configure; the default behavior Maciej> is still to install in scwm's prefix [...] This is a good temporary solution. Possible enhancement: whine if the autoguessed directory does not exist (as Sam said, it's unlikely to be in the load-path then), or perhaps always put out a "be sure to put into your load-path"-message when installing (akin to libtool's library-path-blurb). But there's even more to .el-installing: for example, shouldn't autoloads be generated for the newly installed files? I think that the Emacs developers should come up with a solution, something like "install-el scwm" which would install scwm.el* into the appropriate location(s), and update autoloads. (Should I take this to Stallman & Baur directly, or funnel through some lists?) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jun 22 13:31:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA27128 for scwm-discuss-outgoing; Mon, 22 Jun 1998 13:31:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA27125 for ; Mon, 22 Jun 1998 13:31:52 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA12073; Mon, 22 Jun 98 13:31:52 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id NAA21651; Mon, 22 Jun 1998 13:31:38 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d15.phe-pa.concentric.net [209.31.155.75]) by newman.concentric.net (8.8.8) id NAA01320; Mon, 22 Jun 1998 13:31:36 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA19382; Mon, 22 Jun 1998 13:27:45 -0400 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: emacs install References: <199806220018.UAA20148@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of 22 Jun 1998 10:27:15 +0200 Date: 22 Jun 1998 13:27:34 -0400 Message-Id: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 22 Jun 1998 10:27:15 +0200 >>>> Honorable Robert Bihlmeyer writes >>>> on the subject of "Re: emacs install": >> I think that the Emacs developers should come up with a solution, >> something like "install-el scwm" which would install scwm.el* into the >> appropriate location(s), and update autoloads. good idea! >> (Should I take this to Stallman & Baur directly, or funnel through >> some lists?) all of the above. :-) You should write a brief and convincing proposal, post it to the relevant newsgroups and CC it to RMS - he doesn't read newsgroups. I suggest that you post the elisp code too - just to make sure that you will not be accused of just whining and doing nothing. You can add update-file-autoloads to my code and you will have enough to start with. (you don't need a solution, just a semi-working prototype). -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Life is a sexually transmitted disease with 100% mortality. From owner-scwm-discuss@mit.edu Mon Jun 22 18:23:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA28841 for scwm-discuss-outgoing; Mon, 22 Jun 1998 18:23:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA28838 for ; Mon, 22 Jun 1998 18:23:33 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA06015; Mon, 22 Jun 98 18:23:29 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id PAA15659; Mon, 22 Jun 1998 15:23:18 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id PAA13033; Mon, 22 Jun 1998 15:23:17 -0700 To: sds@goems.com Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: emacs install References: <199806220018.UAA20148@huis-clos.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 22 Jun 1998 15:23:17 -0700 In-Reply-To: Sam Steingold's message of "22 Jun 1998 13:27:34 -0400" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 22 Jun 1998 10:27:15 +0200 > >>>> Honorable Robert Bihlmeyer writes > >>>> on the subject of "Re: emacs install": > >> I think that the Emacs developers should come up with a solution, > >> something like "install-el scwm" which would install scwm.el* into the > >> appropriate location(s), and update autoloads. > > good idea! > > >> (Should I take this to Stallman & Baur directly, or funnel through > >> some lists?) > > all of the above. :-) > > You should write a brief and convincing proposal, post it to the > relevant newsgroups and CC it to RMS - he doesn't read newsgroups. It would be nice if this proposal were compatible with the Debian Linux solution. If you have access to a Debian "hamm" (code name for Debian 2.0) machine, this is documented in /usr/doc/emacsen-common/debian-emacs-policy.gz; I can send a copy to anyone who wants one. (Greatly simplified, the policy states that each package should provide an install script and an uninstall script. During package installation, these scripts will get called once for each version of Emacs installed. This allows "the right thing" to happen when versions of Emacs are installed or uninstalled, as well as when packages with elisp files are installed or uninstalled.) Another solution which would probably work fine for scwm is to not byte-compile the files; I'm guessing that there's nothing performance-critical here (although I've never looked at them, so I could easily be wrong). Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Jun 22 18:43:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA28972 for scwm-discuss-outgoing; Mon, 22 Jun 1998 18:43:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA28969 for ; Mon, 22 Jun 1998 18:43:20 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA09272; Mon, 22 Jun 98 18:43:17 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id SAA20402; Mon, 22 Jun 1998 18:43:14 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d15.phe-pa.concentric.net [209.31.155.75]) by newman.concentric.net (8.8.8) id SAA02919; Mon, 22 Jun 1998 18:43:12 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id SAA20524; Mon, 22 Jun 1998 18:37:44 -0400 To: cwitty@newtonlabs.com (Carl R. Witty) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: emacs install References: <199806220018.UAA20148@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: cwitty@newtonlabs.com's message of 22 Jun 1998 15:23:17 -0700 Date: 22 Jun 1998 18:37:44 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 22 Jun 1998 15:23:17 -0700 >>>> Honorable cwitty@newtonlabs.com (Carl R. Witty) writes >>>> on the subject of "Re: emacs install": >> Another solution which would probably work fine for scwm is to not >> byte-compile the files; I'm guessing that there's nothing >> performance-critical here (although I've never looked at them, so I >> could easily be wrong). Look at the completition stuff. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Diplomacy is the art of saying "nice doggy" until you can find a rock. From owner-scwm-discuss@mit.edu Mon Jun 22 21:28:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA30234 for scwm-discuss-outgoing; Mon, 22 Jun 1998 21:28:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA30213 for ; Mon, 22 Jun 1998 21:28:00 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23854; Mon, 22 Jun 98 21:27:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA19415; Mon, 22 Jun 1998 18:27:47 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: Menu wierdness References: <358c7a5a.92862439@mailhost> From: Greg Badros Date: 22 Jun 1998 18:27:46 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Fri, 19 Jun 1998 15:15:37 GMT" Message-Id: Lines: 16 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > I have noticed a small but annoying bug with menus. > > Using the sample.scwmrc, click Mouse-1 on the root window. The Utilities menu > pops up. Slide the mouse down until it is over the Desks item. Slide the > mouse to the right until the sub-menu pops up. When you move the mouse into > the sub-menu, it goes away. Do it again and it stays. Arrggg! > > It does not happen if you just wait until the submenu pops up on it's own. > > If does not happen if you have a submenu with out a title. I just committed the fix. Thanks again for the bug report, Dale! Greg From owner-scwm-discuss@mit.edu Mon Jun 22 21:36:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA30513 for scwm-discuss-outgoing; Mon, 22 Jun 1998 21:36:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA30510 for ; Mon, 22 Jun 1998 21:36:27 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00333; Mon, 22 Jun 98 21:36:25 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA19794; Mon, 22 Jun 1998 18:36:29 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Prerelease for 0.7 References: <199806220417.AAA22082@huis-clos.mit.edu> From: Greg Badros Date: 22 Jun 1998 18:36:29 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 22 Jun 1998 00:16:56 EDT" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I've placed scwm-0.6c.tgz and scwm-icons-0.6c.tgz on the snapshot > site. These are essentially identical to what I hope to release for > 0.7; if no one points out sever bugs by tomorrow night, I will release > it as 0.7 (bumping the version number of course). > > Bugs I know about but am not expecting to fix for this release: > > * The menu problem reported recently; Greg said he'd deal sometime > next week, so I will leave it to him. I just got this fix in, so the problem should be gone in 0.7. Greg From owner-scwm-discuss@mit.edu Mon Jun 22 21:50:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA30724 for scwm-discuss-outgoing; Mon, 22 Jun 1998 21:50:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA30719; Mon, 22 Jun 1998 21:50:04 -0400 Message-Id: <199806230150.VAA30719@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Prerelease for 0.7 In-reply-to: Your message of "22 Jun 1998 18:36:29 PDT." Date: Mon, 22 Jun 1998 21:50:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > * The menu problem reported recently; Greg said he'd deal sometime > > next week, so I will leave it to him. > > I just got this fix in, so the problem should be gone in 0.7. > Cool. Are you done committing? I'm waiting for the tree to stabilize befoore I tar it up... From owner-scwm-discuss@mit.edu Mon Jun 22 22:03:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA31203 for scwm-discuss-outgoing; Mon, 22 Jun 1998 22:03:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA31200 for ; Mon, 22 Jun 1998 22:03:24 -0400 Received: from inferno.cs.univ-paris8.fr by MIT.EDU with SMTP id AA03484; Mon, 22 Jun 98 22:03:19 EDT Received: from neptune.bocal.cs.univ-paris8.fr (neptune.bocal.cs.univ-paris8.fr [192.168.3.2]) by inferno.cs.univ-paris8.fr (8.8.7/8.7.3) with ESMTP id EAA04891 for ; Tue, 23 Jun 1998 04:01:27 +0200 (CEST) Received: from aqua.bocal.cs.univ-paris8.fr (aqua.bocal.cs.univ-paris8.fr [192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with ESMTP id EAA29871 for ; Tue, 23 Jun 1998 04:05:15 +0200 (MET DST) Received: from aqua.bocal.cs.univ-paris8.fr (localhost [127.0.0.1]) by aqua.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with SMTP id DAA14251 for ; Tue, 23 Jun 1998 03:04:56 +0100 (WET DST) Message-Id: <358F0D48.2A2D@bocal.cs.univ-paris8.fr> Date: Tue, 23 Jun 1998 03:04:56 +0100 From: Kamel Sehil Organization: univ PARIS VIII X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: scwm-discuss@mit.edu Subject: scwm-0.6c install prob Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk hi , i download the scwm-0.6c.tgz , but i have some trouble with the configure file , i'm not root on this machine , on fact i'm root , but the policy of my school , is to no install program's on the system tree , so i can install prog on my account or on /usr/free with scwm-0.6a i just substite -lguile bye -L/guile/path but with the scwm-0.6c , i try to configure it but no way ton indicates him to get the guile include and lib !!! i try all way i know export: LD_LIBRARY_PATH , hack configure (but i don't know them good) From owner-scwm-discuss@mit.edu Mon Jun 22 22:11:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA31403 for scwm-discuss-outgoing; Mon, 22 Jun 1998 22:11:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA31400 for ; Mon, 22 Jun 1998 22:11:05 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04640; Mon, 22 Jun 98 22:11:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA20548; Mon, 22 Jun 1998 19:10:28 -0700 (PDT) To: Kamel Sehil Cc: scwm-discuss@mit.edu Subject: Re: scwm-0.6c install prob References: <358F0D48.2A2D@bocal.cs.univ-paris8.fr> From: Greg Badros Date: 22 Jun 1998 19:10:28 -0700 In-Reply-To: Kamel Sehil's message of "Tue, 23 Jun 1998 03:04:56 +0100" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Kamel Sehil writes: > hi , i download the scwm-0.6c.tgz , but i have some trouble with the > configure file , i'm not root on this machine , on fact i'm root , > but the policy of my school , is to no install program's on the system > tree , so i can install prog on my account or on /usr/free > with scwm-0.6a i just substite -lguile bye -L/guile/path > > but with the scwm-0.6c , i try to configure it but no way ton indicates > him to get the guile include and lib !!! > > i try all way i know export: LD_LIBRARY_PATH , hack configure (but i > don't know them good) I use: CFLAGS="-g -I/uns/include" LDFLAGS="-L/uns/lib" ./configure --prefix=/uns To install under /uns, which is where we install stuff when we lack root privileges. We need to add (or is there already) a way to pass these arguments more directly to configure? Greg From owner-scwm-discuss@mit.edu Tue Jun 23 16:40:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05217 for scwm-discuss-outgoing; Tue, 23 Jun 1998 16:40:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from eshu.request.net (eshu.request.net [207.48.132.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA05214 for ; Tue, 23 Jun 1998 16:40:15 -0400 Received: from munin.request.net ([208.236.140.172]) by eshu.request.net with ESMTP id <748-21973>; Tue, 23 Jun 1998 16:39:44 -0400 Received: from localhost ([132.66.250.105]) by munin.request.net with SMTP id <4431748-22529>; Tue, 23 Jun 1998 16:39:27 -0400 Received: from cmm by localhost with local (Exim 1.62 #1) id 0yoZph-0001BQ-00 (Debian); Tue, 23 Jun 1998 23:38:25 +0300 To: scwm-discuss@mit.edu Subject: scwm 0.7 notes Reply-to: mike@olan.com Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: mike@olan.com (Michael N. Livshin) Date: 23 Jun 1998 23:38:25 +0300 Message-ID: <85hg1brgzi.fsf@alucard.one.way> Lines: 14 X-Mailer: Gnus v5.6.2/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1) It's cool. 2) std-menus.scm should (use-module (ice-9 regex)). Badly. 3) If `bind-key' doesn't recognize a modifier, it shouldn't bind a key at all. Or at least when the key is alphabetical. 4) Just checking: have anyone here written a menu parser for Debian menus (like RedHat's wmconfig only different). Just so I won't duplicate the effort. thanks, mike From owner-scwm-discuss@mit.edu Tue Jun 23 22:11:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08397 for scwm-discuss-outgoing; Tue, 23 Jun 1998 22:11:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA08394 for ; Tue, 23 Jun 1998 22:11:43 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA23369; Tue, 23 Jun 98 22:11:37 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08380; Tue, 23 Jun 1998 22:10:57 -0400 Message-Id: <199806240210.WAA08380@huis-clos.mit.edu> To: Greg Badros Cc: Kamel Sehil Cc: scwm-discuss@mit.edu Subject: Re: scwm-0.6c install prob In-Reply-To: Your message of "22 Jun 1998 19:10:28 PDT." Date: Tue, 23 Jun 1998 22:10:56 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > I use: > > CFLAGS="-g -I/uns/include" LDFLAGS="-L/uns/lib" ./configure --prefix=/uns > > To install under /uns, which is where we install stuff when we lack root > privileges. > > We need to add (or is there already) a way to pass these arguments more > directly to configure? I think the way you do it is the official approved way of doing it. If it's worth providing a better syntax, it's worth doing so in Automake or Autoconf, or else people will just confused between different packages. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 23 22:16:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08461 for scwm-discuss-outgoing; Tue, 23 Jun 1998 22:16:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08452; Tue, 23 Jun 1998 22:15:57 -0400 Message-Id: <199806240215.WAA08452@huis-clos.mit.edu> To: mike@olan.com cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "23 Jun 1998 23:38:25 +0300." <85hg1brgzi.fsf@alucard.one.way> Date: Tue, 23 Jun 1998 22:15:57 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mike@olan.com writes: > > 1) It's cool. > Glad you think so. > 2) std-menus.scm should (use-module (ice-9 regex)). Badly. > Whoops, looks like I will have to put out a bugfix release after all. > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > bind a key at all. Or at least when the key is alphabetical. > If this is a bug report, please desribe the bug more specifically, so we can try to reproduce it. > 4) Just checking: have anyone here written a menu parser for > Debian menus (like RedHat's wmconfig only different). Just so > I won't duplicate the effort. > Not to my knowledge. If you did it, that would be really cool, and I'd gladly add it. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 23 22:19:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08529 for scwm-discuss-outgoing; Tue, 23 Jun 1998 22:19:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08524; Tue, 23 Jun 1998 22:19:44 -0400 Message-Id: <199806240219.WAA08524@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Packaging scwm 0.7? Date: Tue, 23 Jun 1998 22:19:44 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk A couple of people are maintaining binary packages of scwm for various OS distributions, or have volunteered to do so. If any of you get around to making a pakcage of 0.7, could you please let me know, so I could add an appropriate link to the web site? - Maciej From owner-scwm-discuss@mit.edu Tue Jun 23 23:00:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA08864 for scwm-discuss-outgoing; Tue, 23 Jun 1998 23:00:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA08861 for ; Tue, 23 Jun 1998 22:59:50 -0400 Received: from inferno.cs.univ-paris8.fr by MIT.EDU with SMTP id AA29078; Tue, 23 Jun 98 22:59:46 EDT Received: from neptune.bocal.cs.univ-paris8.fr (neptune.bocal.cs.univ-paris8.fr [192.168.3.2]) by inferno.cs.univ-paris8.fr (8.8.7/8.7.3) with ESMTP id EAA15528 for ; Wed, 24 Jun 1998 04:58:12 +0200 (CEST) Received: from aqua.bocal.cs.univ-paris8.fr (aqua.bocal.cs.univ-paris8.fr [192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with ESMTP id FAA04836 for ; Wed, 24 Jun 1998 05:01:57 +0200 (MET DST) Received: from aqua.bocal.cs.univ-paris8.fr (localhost [127.0.0.1]) by aqua.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with SMTP id EAA07526 for ; Wed, 24 Jun 1998 04:01:36 +0100 (WET DST) Message-Id: <35906C0F.1393@bocal.cs.univ-paris8.fr> Date: Wed, 24 Jun 1998 04:01:35 +0100 From: Kamel Sehil Organization: univ PARIS VIII X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: scwm-discuss@mit.edu Subject: Re: scwm-0.6c install prob References: <199806240210.WAA08380@huis-clos.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak wrote: > > gjb@cs.washington.edu writes: > > > > I use: > > > > CFLAGS="-g -I/uns/include" LDFLAGS="-L/uns/lib" ./configure --prefix=/uns > > > > To install under /uns, which is where we install stuff when we lack root > > privileges. > > > > We need to add (or is there already) a way to pass these arguments more > > directly to configure? > > I think the way you do it is the official approved way of doing it. If > it's worth providing a better syntax, it's worth doing so in Automake > or Autoconf, or else people will just confused between different > packages. > > - Maciej ok ok i thinks you just don't understand my odd english , so i try to be more precis !! i have guile on my account on /home/skel/guile so libguile is on /home/skel/guile/lib i do export LD_LIBRARY_PATH=/home/skel/guile/lib:$LD_LIBRARY_PATH export PATH=/home/skel/guile/bin:$PATH ./configure when i do the check i notice that's creating libtool checking for build-guile... yes . . . checking for scm_done_malloc in -lguile... no checking for scm_puts in -lguile... no checking for gh_vector_ref in -lguile... no checking for gh_vector_set_x in -lguile... no checking for scm_readline in -lguile... no checking for gh_length in -lguile... no checking for scm_parse_path in -lguile... no checking for scm_internal_select in -lguile... no checking for scm_internal_cwdr in -lguile... no checking for scm_internal_stack_catch in -lguile... no so the compilation don't work , i got the same probleme with scwm0.6 it i just substitute "-lguile" by "-L/home/skel/guile/lib -lguile". with scwm0.6c or scwm0.7 i just can't compile them , i found no way to links scwm with guile , i hope i've been more explicit and sorry if my question bother you !! thanks From owner-scwm-discuss@mit.edu Tue Jun 23 23:52:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA09213 for scwm-discuss-outgoing; Tue, 23 Jun 1998 23:52:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id XAA09210 for ; Tue, 23 Jun 1998 23:52:22 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA2D45 for ; Tue, 23 Jun 1998 23:52:06 -0400 From: "Jason Kirtland" To: Subject: stacking order Date: Tue, 23 Jun 1998 23:48:12 -0400 Message-ID: <000101bd9f22$e92eba20$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk This is a long-time pet peeve of mine. When I want to "lower" a window, I often only want to lower it one notch in the stacking order, not drop it all the way to the bottom. I was hoping to do something like this, bound to a button: Click: lower one Long click: drop to bottom (mouse down, wait, mouse up) Digging down through the source, it doesn't seem like 'lower one' is quite possible at the moment. Seems XLowerWindow always drops the window all the way to the bottom- not useful. I'm not a C or an X programmer, but poking through the man pages gave me an idea- is it possible to re-implement raise and lower using XRestackWindows? If so, it might be possible to also implement another long-time wish of mine, "stays on bottom". If we keep track of windows marked for Top or Bottom, new raise or lower functions could manipulate the stacking order between the two extremes- (T T w w w w B B B) moving the window by 'one' or 'all'. Perhaps another 'zone' could be added, an "almost bottom" to be used for icons such that a lowered window doesn't drop below the icons. (Which looks silly, IMHO.) Maybe also an "absolute top" zone for folks who like their popups to stand out above normal "on top" windows. As I said, I'm not versed in these things, so I may be badly misinterpreting the Xlib function or the complexity involved. Just a thought. -=j From owner-scwm-discuss@mit.edu Wed Jun 24 00:41:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA09685 for scwm-discuss-outgoing; Wed, 24 Jun 1998 00:41:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA09682 for ; Wed, 24 Jun 1998 00:41:26 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA11380; Wed, 24 Jun 98 00:41:22 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id VAA28756 for ; Tue, 23 Jun 1998 21:41:20 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276568-9109>; Tue, 23 Jun 1998 21:41:42 -0700 To: scwm-discuss@mit.edu Subject: incompatability with scm_parse_path() Date: Tue, 23 Jun 1998 21:41:37 -0600 From: Ken Pizzini Message-Id: <19980624044142Z276568-9109+17@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk When compiling scwm-0.7 using the snapshot guile-core-19980623 (on Linux 2.0.33, gcc version 2.8.1), I get: gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6.3/include -g -O2 -c events.c In file included from events.c:79: guile-compat.h:40: conflicting types for `scm_parse_path' /usr/include/libguile/load.h:50: previous declaration of `scm_parse_path' make[1]: *** [events.o] Error 1 Attached is a patch which reflects how I solved the problem sufficiently to get scwm-0.7 built on my machine, but it is not a complete solution --- either configure has to be taught about the two differerent scm_parse_path() prototypes, or the scm_parse_path() in guile-compat.{c,h} needs to be modified to take a SCM as the first argument. --Ken Pizzini diff -ru scwm-0.7-orig/scwm/guile-compat.h scwm-0.7/scwm/guile-compat.h --- scwm-0.7-orig/scwm/guile-compat.h Mon Jun 22 15:18:55 1998 +++ scwm-0.7/scwm/guile-compat.h Tue Jun 23 21:21:05 1998 @@ -37,7 +37,9 @@ #define scm_internal_select select #endif +#ifndef HAVE_SCM_PARSE_PATH SCM scm_parse_path (char *path, SCM tail); +#endif #ifndef HAVE_GH_VECTOR_SET_X #define gh_vector_set_x gh_vset diff -ru scwm-0.7-orig/scwm/scwm.c scwm-0.7/scwm/scwm.c --- scwm-0.7-orig/scwm/scwm.c Mon Jun 22 15:19:15 1998 +++ scwm-0.7/scwm/scwm.c Tue Jun 23 21:24:57 1998 @@ -1442,7 +1442,11 @@ loc_load_path = SCM_CDRLOC(scm_sysintern0("%load-path")); path=*loc_load_path; path=gh_cons(gh_str02scm(SCWM_LOAD_PATH),path); +#ifndef HAVE_SCM_PARSE_PATH path=scm_parse_path(getenv("SCWM_LOAD_PATH"), path); +#else + path=scm_parse_path(scm_makfrom0str(getenv("SCWM_LOAD_PATH")), path); +#endif *loc_load_path = path; } From owner-scwm-discuss@mit.edu Wed Jun 24 00:48:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA09783 for scwm-discuss-outgoing; Wed, 24 Jun 1998 00:48:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA09780 for ; Wed, 24 Jun 1998 00:48:08 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA06963; Wed, 24 Jun 98 00:48:05 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id VAA21207 for ; Tue, 23 Jun 1998 21:48:03 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276568-9109>; Tue, 23 Jun 1998 21:49:28 -0700 To: scwm-discuss@mit.edu Subject: focus oddity Date: Tue, 23 Jun 1998 21:49:13 -0600 From: Ken Pizzini Message-Id: <19980624044928Z276568-9109+18@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk While I'm submitting bugs, I'll add a minor one that I've just never seemed to have gotten around to... I've noticed this off-and-on with 0.6, and just noticed again with 0.7: My xterms have #:focus 'sloppy set; sometimes (probably about one time in 25), when I have a pair of partially overlapping windows and I move the cursor quickly from the root window, crossing one of the xterms (which held the sloppy focus), and landing in the other xterm, the new window does not gain focus. I have to take the cursor off of the window in which I desire focus and bring it back in, crossing the border slowly. --Ken Pizzini From owner-scwm-discuss@mit.edu Wed Jun 24 00:51:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA09851 for scwm-discuss-outgoing; Wed, 24 Jun 1998 00:51:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA09842; Wed, 24 Jun 1998 00:51:01 -0400 Message-Id: <199806240451.AAA09842@huis-clos.mit.edu> To: Ken Pizzini cc: scwm-discuss@mit.edu Subject: Re: incompatability with scm_parse_path() In-reply-to: Your message of "Tue, 23 Jun 1998 21:41:37 MDT." <19980624044142Z276568-9109+17@pulsar.halcyon.com> Date: Wed, 24 Jun 1998 00:51:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk ken@halcyon.com writes: > When compiling scwm-0.7 using the snapshot guile-core-19980623 > (on Linux 2.0.33, gcc version 2.8.1), I get: > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6.3/include -g -O2 - > c events.c > In file included from events.c:79: > guile-compat.h:40: conflicting types for `scm_parse_path' > /usr/include/libguile/load.h:50: previous declaration of `scm_parse_path' > make[1]: *** [events.o] Error 1 > *sigh* Based on this and other bug reports, it looks like I managed to ship a release that breaks with both guile 1.2 _and_ the latest snapshot. (Mental note, repeat 100 times: _test_ the releases). I actually tried to add some code to fix this problem shortly before tarring up the release (to use scm_internal_parse_path when appropriate) but it seems to have somehow not made it in. I'll try to make sure tonight's snapshot is fixed for both 1.2 and the latest guile snapshot, and will actually test the compilation. I'll probaby release an 0.7a or 0.8 real soon to fix these problems. - Maciej From owner-scwm-discuss@mit.edu Wed Jun 24 01:23:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA10329 for scwm-discuss-outgoing; Wed, 24 Jun 1998 01:23:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id BAA10326 for ; Wed, 24 Jun 1998 01:23:44 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA2D98 for ; Wed, 24 Jun 1998 01:23:26 -0400 From: "Jason Kirtland" To: "scwm-discuss" Subject: Re: focus oddity Date: Wed, 24 Jun 1998 01:19:32 -0400 Message-ID: <000001bd9f2f$ab88f200$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini wrote: > > While I'm submitting bugs, I'll add a minor one that I've just > never seemed to have gotten around to... > > I've noticed this off-and-on with 0.6, and just noticed again with > 0.7: My xterms have #:focus 'sloppy set; sometimes (probably about > one time in 25), when I have a pair of partially overlapping > windows and I move the cursor quickly from the root window, > crossing one of the xterms (which held the sloppy focus), and > landing in the other xterm, the new window does not gain focus. > I have to take the cursor off of the window in which I desire > focus and bring it back in, crossing the border slowly. This bug has been around in fvwm for as long as I can remember. I found that the thinner the window border the more likely the window wouldn't gain focus. Oddly, I've never seen anything about this bug on the fvwm list. I thought I was the only lucky one. :) -=j From owner-scwm-discuss@mit.edu Wed Jun 24 04:57:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA11838 for scwm-discuss-outgoing; Wed, 24 Jun 1998 04:57:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA11835 for ; Wed, 24 Jun 1998 04:57:36 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA02148; Wed, 24 Jun 98 04:57:34 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA31868; Wed, 24 Jun 1998 11:57:24 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Packaging scwm 0.7? References: <199806240219.WAA08524@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 24 Jun 1998 11:57:23 +0300 In-Reply-To: Maciej Stachowiak's message of "Tue, 23 Jun 1998 22:19:44 EDT" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > A couple of people are maintaining binary packages of scwm for various > OS distributions, or have volunteered to do so. If any of you get > around to making a pakcage of 0.7, could you please let me know, so I > could add an appropriate link to the web site? I'll try to build v0.7 this weekend (after all the initial release bugs are flushed out & I get some time to fool around with it). One tricky part is going to be the guile dependency. Is there a Guile RPM? We're going to need to have a dependency on it. BTW, has anyone ever built an RPM for scwm? If so, where's the source RPM? It'd be easier to modify an existing one than start from scratch. Also, I've been assuming that whoever originally built the RPM is no longer interested in doing so. Is this really the case? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jun 24 07:29:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA12399 for scwm-discuss-outgoing; Wed, 24 Jun 1998 07:29:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA12394 for ; Wed, 24 Jun 1998 07:29:19 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id NAA14822 for scwm-discuss@huis-clos.mit.edu; Wed, 24 Jun 1998 13:29:14 +0200 (CEST) Received: (qmail 599 invoked by uid 115); 24 Jun 1998 11:01:15 -0000 To: scwm-discuss@mit.edu Subject: Re: stacking order References: <000101bd9f22$e92eba20$6463a7cc@panopticon.postalmodern.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 24 Jun 1998 13:01:13 +0200 In-Reply-To: "Jason Kirtland"'s message of "Tue, 23 Jun 1998 23:48:12 -0400" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 23 Jun 1998 23:48:12 -0400 >>>>> "Jason Kirtland" said: Jason> Perhaps another 'zone' could be added, an "almost bottom" to Jason> be used for icons such that a lowered window doesn't drop Jason> below the icons. (Which looks silly, IMHO.) How do you reach icons which are buried below a window in this configuration? Having to move the window off the icons is a bit much work, IMHO. Anyway, when stay-on-bottom is implemented, we could provide a way to enforce this on all icons. (I don't think that you can make window-styles apply only to iconified windows, this would make another good addition.) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Jun 24 07:29:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA12402 for scwm-discuss-outgoing; Wed, 24 Jun 1998 07:29:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA12397 for ; Wed, 24 Jun 1998 07:29:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id NAA14849 for scwm-discuss@huis-clos.mit.edu; Wed, 24 Jun 1998 13:29:18 +0200 (CEST) Received: (qmail 610 invoked by uid 115); 24 Jun 1998 11:05:01 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <85hg1brgzi.fsf@alucard.one.way> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 24 Jun 1998 13:04:59 +0200 In-Reply-To: mike@olan.com's message of "23 Jun 1998 23:38:25 +0300" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.11/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 23 Jun 1998 23:38:25 +0300 >>>>> mike@olan.com (Michael N. Livshin) said: Michael> 3) If `bind-key' doesn't recognize a modifier, it shouldn't Michael> bind a key at all. Or at least when the key is Michael> alphabetical. I think I'm responsible for this, and indeed I have encountered this bug myself. So when I've finished whipping myself, I'll fix this. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Jun 24 10:46:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA13228 for scwm-discuss-outgoing; Wed, 24 Jun 1998 10:46:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA13222 for ; Wed, 24 Jun 1998 10:45:59 -0400 Received: from king.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA12765; Wed, 24 Jun 98 10:42:59 EDT Received: (from marko@localhost) by king.ki.informatik.uni-frankfurt.de (8.7.1/8.7.1) id QAA03148; Wed, 24 Jun 1998 16:42:14 +0200 (MESZ) Date: Wed, 24 Jun 1998 16:42:14 +0200 (MESZ) Message-Id: <199806241442.QAA03148@king.ki.informatik.uni-frankfurt.de> From: Marko Schuetz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: compiling scwm-0.7: where is gh_memq? X-Mailer: VM 6.34 under Emacs 20.2.1 Reply-To: marko@cs.uni-frankfurt.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk I grabbed scwm-0.7 and tried to compile it. That failed to link scwm with an undefined symbol _gh_memq. Marko From owner-scwm-discuss@mit.edu Wed Jun 24 14:16:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA14553 for scwm-discuss-outgoing; Wed, 24 Jun 1998 14:16:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA14550 for ; Wed, 24 Jun 1998 14:16:33 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA08819; Wed, 24 Jun 98 14:16:30 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA14545; Wed, 24 Jun 1998 14:16:24 -0400 Message-Id: <199806241816.OAA14545@huis-clos.mit.edu> To: marko@cs.uni-frankfurt.de Cc: scwm-discuss@mit.edu Subject: Re: compiling scwm-0.7: where is gh_memq? In-Reply-To: Your message of "Wed, 24 Jun 1998 16:42:14 +0200." <199806241442.QAA03148@king.ki.informatik.uni-frankfurt.de> Date: Wed, 24 Jun 1998 14:16:23 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk marko@king.ki.informatik.uni-frankfurt.de writes: > I grabbed scwm-0.7 and tried to compile it. That failed to link scwm > with an undefined symbol _gh_memq. > This is a problem with the dstribution when used with Guile 1.2. You can do one of the following things: * Replace the call to gh_memq with one to scm_memq by hand. * Download ftp://huis-clos.mit.edu/pub/scwm/scwm-19980624.tar.gz and use that instead; it is essentially identical to the release, but fixes this and a few other bugs. * Wait for the bugfix release to be out shortly (I'll wait another day or two for other major bug reports). - Maciej From owner-scwm-discuss@mit.edu Wed Jun 24 17:06:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA15595 for scwm-discuss-outgoing; Wed, 24 Jun 1998 17:06:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA15592 for ; Wed, 24 Jun 1998 17:06:02 -0400 Received: from eshu.request.net by MIT.EDU with SMTP id AA22828; Wed, 24 Jun 98 17:05:55 EDT Received: from munin.request.net ([208.236.140.172]) by eshu.request.net with ESMTP id <700-26209>; Wed, 24 Jun 1998 17:05:11 -0400 Received: from localhost ([132.66.250.105]) by munin.request.net with SMTP id <4218217-13582>; Wed, 24 Jun 1998 17:04:58 -0400 Received: from cmm by localhost with local (Exim 1.62 #1) id 0yohb4-00005b-00 (Debian); Wed, 24 Jun 1998 07:55:50 +0300 To: Maciej Stachowiak Cc: mike@olan.com, scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <199806240215.WAA08452@huis-clos.mit.edu> Reply-To: mike@olan.com Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: mike@olan.com (Michael N. Livshin) Date: 24 Jun 1998 07:55:50 +0300 In-Reply-To: Maciej Stachowiak's message of "Tue, 23 Jun 1998 22:15:57 EDT" Message-Id: <857m27wg89.fsf@alucard.one.way> Lines: 27 X-Mailer: Gnus v5.6.2/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > > bind a key at all. Or at least when the key is alphabetical. > > > > If this is a bug report, please desribe the bug more specifically, so > we can try to reproduce it. > ------------------>8 cut 8<------------------------- $ scwmrepl scwm> (bind-key 'all "H-z" (lambda () (display "lose lose\n" (current-error-port)))) [Scwm][PchModifiersToModmask]: <> Unbound modifier H- ignored # [--- now I press the Z key with no modifiers, two times ---] scwm> lose lose lose lose ------------------>8 cut 8<------------------------- Maybe it's a feature, but then it's a feature that bugs me :). HTH, mike. From owner-scwm-discuss@mit.edu Wed Jun 24 18:11:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA15948 for scwm-discuss-outgoing; Wed, 24 Jun 1998 18:11:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA15945 for ; Wed, 24 Jun 1998 18:11:47 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05979; Wed, 24 Jun 98 18:11:43 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA20588; Wed, 24 Jun 1998 15:11:47 -0700 (PDT) To: mike@olan.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <199806240215.WAA08452@huis-clos.mit.edu> <857m27wg89.fsf@alucard.one.way> From: Greg Badros Date: 24 Jun 1998 15:11:45 -0700 In-Reply-To: mike@olan.com's message of "24 Jun 1998 07:55:50 +0300" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk mike@olan.com (Michael N. Livshin) writes: > Maciej Stachowiak writes: > > > > > > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > > > bind a key at all. Or at least when the key is alphabetical. > > > > > > > If this is a bug report, please desribe the bug more specifically, so > > we can try to reproduce it. > > > > ------------------>8 cut 8<------------------------- > $ scwmrepl > scwm> (bind-key 'all "H-z" (lambda () (display "lose lose\n" (current-error-port)))) > [Scwm][PchModifiersToModmask]: <> Unbound modifier H- ignored > # > > [--- now I press the Z key with no modifiers, two times ---] > > scwm> lose lose > lose lose > ------------------>8 cut 8<------------------------- > > Maybe it's a feature, but then it's a feature that bugs me :). :-) I just fixed it. See tomorrow's snapshot or patches, and let me know if it doesn't do the right thing. Greg From owner-scwm-discuss@mit.edu Wed Jun 24 18:27:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA16118 for scwm-discuss-outgoing; Wed, 24 Jun 1998 18:27:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA16115 for ; Wed, 24 Jun 1998 18:27:34 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04831; Wed, 24 Jun 98 18:27:33 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA21302; Wed, 24 Jun 1998 15:27:33 -0700 (PDT) To: "Jason Kirtland" Cc: "scwm-discuss" Subject: Re: focus oddity References: <000001bd9f2f$ab88f200$6463a7cc@panopticon.postalmodern.com> From: Greg Badros Date: 24 Jun 1998 15:27:33 -0700 In-Reply-To: "Jason Kirtland"'s message of "Wed, 24 Jun 1998 01:19:32 -0400" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Jason Kirtland" writes: > Ken Pizzini wrote: > > > > While I'm submitting bugs, I'll add a minor one that I've just > > never seemed to have gotten around to... > > > > I've noticed this off-and-on with 0.6, and just noticed again with > > 0.7: My xterms have #:focus 'sloppy set; sometimes (probably about > > one time in 25), when I have a pair of partially overlapping > > windows and I move the cursor quickly from the root window, > > crossing one of the xterms (which held the sloppy focus), and > > landing in the other xterm, the new window does not gain focus. > > I have to take the cursor off of the window in which I desire > > focus and bring it back in, crossing the border slowly. > > This bug has been around in fvwm for as long as I can remember. I found that > the thinner the window border the more likely the window wouldn't gain focus. > > Oddly, I've never seen anything about this bug on the fvwm list. I thought I > was the only lucky one. :) I can't seem to reproduce this... can you try again to explain very explicitly how you reproduce it (your description seems really good, but I might still be doing something differently). What kind of machine/X-Server are you guys using (maybe it's a timing thing and this server is a bit too fast too let me see the problem). Thanks, Greg From owner-scwm-discuss@mit.edu Wed Jun 24 21:48:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17180 for scwm-discuss-outgoing; Wed, 24 Jun 1998 21:48:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id VAA17177 for ; Wed, 24 Jun 1998 21:48:26 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA3086; Wed, 24 Jun 1998 21:48:10 -0400 From: "Jason Kirtland" To: Cc: "scwm-discuss" , Subject: Re: focus oddity Date: Wed, 24 Jun 1998 21:44:11 -0400 Message-ID: <000001bd9fda$c086f980$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros wrote in message ... > "Jason Kirtland" writes: > > > Ken Pizzini wrote: > > > [snip] > > > I've noticed this off-and-on with 0.6, and just noticed again with > > > 0.7: My xterms have #:focus 'sloppy set; sometimes (probably about > > > one time in 25), when I have a pair of partially overlapping > > > windows and I move the cursor quickly from the root window, > > > crossing one of the xterms (which held the sloppy focus), and > > > landing in the other xterm, the new window does not gain focus. > > > I have to take the cursor off of the window in which I desire > > > focus and bring it back in, crossing the border slowly. > > > > This bug has been around in fvwm for as long as I can remember. > > I found that the thinner the window border the more likely the > > window wouldn't gain focus. > > [snip] > > I can't seem to reproduce this... can you try again to explain very > explicitly how you reproduce it (your description seems really good, but > I might still be doing something differently). What kind of > machine/X-Server are you guys using (maybe it's a timing thing and this > server is a bit too fast too let me see the problem). I've run into this bug on and off since ~1994 on the following assorted systems: - Intel 486-50 through P233 / Linux (various) / XFree86 (various), Metro X, Accelerated X / Fvwm 2.0.x - SGI Indy R5000 / IRIX 5.3, 6.2 / SGI X / Fvwm 2.0.4x - SGI O2 R5000 / IRIX 6.3 / SGI X / Fvwm 2.0.4x I've been unable to set off the bug on this very slow box: DEC Alpha 133 / Linux 2.0.30 / XFree TGA / scwm 0.7 I've been using the SGI systems almost exclusively the past couple years, and somewhere in there came up with a configuration where this bug didn't crop up. I seem to recall that the focus bug would happen most often while also running the SGI desktop environment. The desktop environment basically allows you to put file icons on the desktop and captures buttons 1+2 for moving icons around, activating them, etc. I no longer use this. It seems that GNOME or KDE might be somewhat similar to the SGI desktop? Perhaps the bug might crop up again on a system so equipped. Sorry I can't be any more explicit about reproducing this bug. Its been a while since I've seen it. -jason From owner-scwm-discuss@mit.edu Wed Jun 24 21:58:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17257 for scwm-discuss-outgoing; Wed, 24 Jun 1998 21:58:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tolt.cs.washington.edu (tolt.cs.washington.edu [128.95.1.155]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id VAA17254 for ; Wed, 24 Jun 1998 21:58:11 -0400 Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA29965; Wed, 24 Jun 1998 18:58:04 -0700 (PDT) To: "Jason Kirtland" Cc: "scwm-discuss" , Subject: Re: focus oddity References: <000001bd9fda$c086f980$6463a7cc@panopticon.postalmodern.com> From: Greg Badros Date: 24 Jun 1998 18:58:04 -0700 In-Reply-To: "Jason Kirtland"'s message of "Wed, 24 Jun 1998 21:44:11 -0400" Message-ID: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Jason Kirtland" writes: > Sorry I can't be any more explicit about reproducing this bug. Its been a > while since I've seen it. Thanks for all the info... it narrows down some of the things I was considering... if anyone out there can give explicit directions, I'll be glad to try to track this one down. Thanks again, Jason. Greg From owner-scwm-discuss@mit.edu Thu Jun 25 09:38:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA21355 for scwm-discuss-outgoing; Thu, 25 Jun 1998 09:38:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA21352 for ; Thu, 25 Jun 1998 09:38:32 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA19621; Thu, 25 Jun 98 09:38:22 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id JAA04026; Thu, 25 Jun 1998 09:38:20 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts009d24.phe-pa.concentric.net [209.31.155.180]) by marconi.concentric.net (8.8.8) id JAA07171; Thu, 25 Jun 1998 09:38:18 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id KAA02553; Thu, 25 Jun 1998 10:32:03 -0400 To: scwm-discuss@mit.edu Subject: crash Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold Date: 25 Jun 1998 10:32:03 -0400 Message-Id: Lines: 123 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. when I build: Making all in doc make[1]: Entering directory `/usr/src/scwm/doc' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/usr/src/scwm/doc' make: *** [all-recursive] Error 1 2. when I run: $ gdb scwm GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run Starting program: /usr/src/scwm/scwm/scwm Program received signal SIGSEGV, Segmentation fault. 0x4019d941 in _IO_fclose (fp=0x8096650) at iofclose.c:44 iofclose.c:44: No such file or directory. (gdb) where #0 0x4019d941 in _IO_fclose (fp=0x8096650) at iofclose.c:44 #1 0x4019f4c9 in pclose (fp=0x8096650) at pclose.c:15 #2 0x400e1074 in local_pclose () at fports.c:455 #3 0x400e257a in scm_gc_sweep () at gc.c:1024 #4 0x400e1589 in scm_igc () at gc.c:1371 #5 0x400e1420 in scm_gc_for_alloc () at gc.c:1371 #6 0x400e14c9 in scm_gc_for_newcell () at gc.c:1371 #7 0x400f1a5a in scm_cons2 () at pairs.c:162 #8 0x400db86f in scm_deval () at eval.c:3067 #9 0x400d993d in scm_deval () at eval.c:3067 #10 0x400d993d in scm_deval () at eval.c:3067 #11 0x400da325 in scm_deval () at eval.c:3067 #12 0x400da325 in scm_deval () at eval.c:3067 #13 0x400dcf39 in scm_dapply () at eval.c:3067 #14 0x400d8099 in scm_apply () at eval.c:1328 #15 0x40106433 in scm_sym2vcell () at symbols.c:328 #16 0x400d3f9b in scm_lookupcar1 () at eval.c:2545 #17 0x400da94c in scm_deval () at eval.c:3067 #18 0x400db859 in scm_deval () at eval.c:3067 #19 0x400d92f5 in scm_deval_args () at eval.c:3067 #20 0x400dbdac in scm_deval () at eval.c:3067 #21 0x400d99b2 in scm_deval () at eval.c:3067 #22 0x400d99b2 in scm_deval () at eval.c:3067 #23 0x400d907a in scm_eval_3 () at eval.c:3067 #24 0x400d9152 in scm_eval_x () at eval.c:3067 #25 0x400e91b2 in scm_init_load () at load.c:298 #26 0x400dc2ca in scm_deval () at eval.c:3067 #27 0x400d4150 in scm_eval_car () at eval.c:2545 #28 0x401146b8 in scm_m_start_stack () at debug.c:149 #29 0x400dcdda in scm_dapply () at eval.c:3067 #30 0x400da9b3 in scm_deval () at eval.c:3067 #31 0x400dcf39 in scm_dapply () at eval.c:3067 #32 0x400d8099 in scm_apply () at eval.c:1328 #33 0x400d2a91 in scm_init_dynwind () at dynwind.c:162 #34 0x400dc2ae in scm_deval () at eval.c:3067 #35 0x400dcf39 in scm_dapply () at eval.c:3067 #36 0x400d8099 in scm_apply () at eval.c:1328 #37 0x400d2a91 in scm_init_dynwind () at dynwind.c:162 #38 0x400dc2ae in scm_deval () at eval.c:3067 #39 0x400d99b2 in scm_deval () at eval.c:3067 ---Type to continue, or q to quit--- #40 0x400db155 in scm_deval () at eval.c:3067 #41 0x400d993d in scm_deval () at eval.c:3067 #42 0x400da325 in scm_deval () at eval.c:3067 #43 0x400dcf39 in scm_dapply () at eval.c:3067 #44 0x400d8099 in scm_apply () at eval.c:1328 #45 0x400d2a91 in scm_init_dynwind () at dynwind.c:162 #46 0x400dc2ae in scm_deval () at eval.c:3067 #47 0x400d99b2 in scm_deval () at eval.c:3067 #48 0x400da325 in scm_deval () at eval.c:3067 #49 0x400d99b2 in scm_deval () at eval.c:3067 #50 0x400da29d in scm_deval () at eval.c:3067 #51 0x400da29d in scm_deval () at eval.c:3067 #52 0x400dcf39 in scm_dapply () at eval.c:3067 #53 0x400d8099 in scm_apply () at eval.c:1328 #54 0x400d89af in scm_for_each () at eval.c:1328 #55 0x400dc2ae in scm_deval () at eval.c:3067 #56 0x400d907a in scm_eval_3 () at eval.c:3067 #57 0x400d9152 in scm_eval_x () at eval.c:3067 #58 0x806974d in scwm_body_eval_x (body_data=0xbfffeeec) at callbacks.c:184 #59 0x40108bf4 in scm_internal_lazy_catch () at throw.c:300 #60 0x40108cf1 in cwss_body () at throw.c:363 #61 0x40108a00 in scm_internal_catch () at throw.c:134 #62 0x40108d34 in scm_internal_stack_catch () at throw.c:364 #63 0x80697a9 in scwm_body_load (body_data=0xbffff020) at callbacks.c:190 #64 0x40108a00 in scm_internal_catch () at throw.c:134 #65 0x400fed4d in scm_internal_cwdr () at root.c:243 #66 0x8069878 in safe_load (fname=1076090632) at callbacks.c:236 #67 0x400dc2ca in scm_deval () at eval.c:3067 #68 0x400d907a in scm_eval_3 () at eval.c:3067 #69 0x400d9152 in scm_eval_x () at eval.c:3067 #70 0x806974d in scwm_body_eval_x (body_data=0xbffff248) at callbacks.c:184 #71 0x40108bf4 in scm_internal_lazy_catch () at throw.c:300 #72 0x40108cf1 in cwss_body () at throw.c:363 #73 0x40108a00 in scm_internal_catch () at throw.c:134 #74 0x40108d34 in scm_internal_stack_catch () at throw.c:364 #75 0x8069821 in scwm_body_eval_str (body_data=0x806a69c) at callbacks.c:190 #76 0x40108a00 in scm_internal_catch () at throw.c:134 #77 0x400fed4d in scm_internal_cwdr () at root.c:243 #78 0x80698b1 in scwm_safe_eval_str ( string=0x806a69c "(let ((home-scwmrc (string-append (getenv \"HOME\") ---Type to continue, or q to quit--- \"/\" \".scwmrc\")) (system-scwmrc \"/usr/local/lib/X11/scwm/system.scwmrc\")) (if (access? home-scwmrc R_OK) (safe-load home-scwmrc) (if"...) at callbacks.c:249 #79 0x8054b72 in scwm_main (argc=1, argv=0xbffff874) at scwm.c:509 #80 0x8054325 in scwm_gh_launch_pad (closure=0x805435c, argc=1, argv=0xbffff874) at scwm.c:163 #81 0x400e6ed8 in invoke_main_func (body_data=0xbffff81c) at init.c:509 #82 0x40108a00 in scm_internal_catch () at throw.c:134 #83 0x400e6e91 in scm_boot_guile_1 (base=0xbffff818, closure=0xbffff81c) at init.c:485 #84 0x400e6c39 in scm_boot_guile () at init.c:274 #85 0x8054342 in scwm_gh_enter (argc=1, argv=0xbffff874, c_main_prog=0x805435c ) at scwm.c:170 #86 0x8054357 in main (argc=1, argv=0xbffff874) at scwm.c:185 -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Diplomacy is the art of saying "nice doggy" until you can find a rock. From owner-scwm-discuss@mit.edu Thu Jun 25 12:06:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22180 for scwm-discuss-outgoing; Thu, 25 Jun 1998 12:06:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from sig.bsh.com (sig-int-206.33.103.14.sig.bsh.com [206.33.103.14]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA22177 for ; Thu, 25 Jun 1998 12:06:04 -0400 Received: from sig.bsh.com (ginger.sig.bsh.com [206.33.103.231]) by sig.bsh.com (8.8.5/8.7.3/http://www.sig.bsh.com) with ESMTP id MAA02768 for ; Thu, 25 Jun 1998 12:07:32 -0400 (EDT) Message-ID: <35927588.3C7C490@sig.bsh.com> Date: Thu, 25 Jun 1998 12:06:33 -0400 From: "Jesse N. Glick" Organization: Strategic Interactive Group, Inc. X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 6.3 IP32) MIME-Version: 1.0 To: scwm-discuss@mit.edu Subject: SCWM 0.6a: minor peeves Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Under SCWM 0.6a, error messages in scwmrepl go to the console (i.e. SCWM fd #2) rather than stderr for the scwmrepl. E.g. typing in a bogus expression will give #f as a result, but the actual error message goes to SCWM stderr. Also, one error message seems to have a misuse of some Scheme formatting primitive: Scwm got an error; tag is misc-error (#f Unbound variable: %S (+++++) #f) The %S looks like a micro-braino. One more thing: I routinely (every few minutes?) get the following on SCWM stderr: [Scwm][ScwmErrorHandler]: <> *** internal error *** [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 2 I'm not sure what it is associated with but if I track it down I will mention it. -Jesse -- Jesse N. Glick * mailto:jglick@sig.bsh.com Sr. Programmer/Analyst * Strategic Interactive Group 800 Boylston St. Boston MA 02199 * 617-867-1017 (tel) 617-867-1111 (fax) ************************************************************************ IF I HAD KNOWN THAT IT WAS HARMLESS, I WOULD HAVE KILLED IT MYSELF. From owner-scwm-discuss@mit.edu Thu Jun 25 13:27:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA22639 for scwm-discuss-outgoing; Thu, 25 Jun 1998 13:27:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA22636 for ; Thu, 25 Jun 1998 13:27:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20931; Thu, 25 Jun 98 13:27:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA07306; Thu, 25 Jun 1998 10:27:33 -0700 (PDT) To: "Jesse N. Glick" Cc: scwm-discuss@mit.edu Subject: Re: SCWM 0.6a: minor peeves References: <35927588.3C7C490@sig.bsh.com> From: Greg Badros Date: 25 Jun 1998 10:27:32 -0700 In-Reply-To: "Jesse N. Glick"'s message of "Thu, 25 Jun 1998 12:06:33 -0400" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Jesse N. Glick" writes: > One more thing: I routinely (every few minutes?) get the following on > SCWM stderr: > > [Scwm][ScwmErrorHandler]: <> *** internal error *** > [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 2 > > I'm not sure what it is associated with but if I track it down I will > mention it. Please run these kinds of error messages through X-error-describe (a perl script I wrote to make these messages more meaningful)-- it is available in utilities/dev/. This one is: [Scwm][ScwmErrorHandler]: <> Req=X_ConfigureWindow, Error=BadValue, Event: KeyPress and I've seen it before, too. I'm pretty sure it's related to using scwmrepl, but haven't tried tracking it down yet. Thanks for the bug reports! Greg From owner-scwm-discuss@mit.edu Thu Jun 25 16:38:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24100 for scwm-discuss-outgoing; Thu, 25 Jun 1998 16:38:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24092; Thu, 25 Jun 1998 16:37:59 -0400 Message-Id: <199806252037.QAA24092@huis-clos.mit.edu> To: "Jesse N. Glick" cc: scwm-discuss@mit.edu Subject: Re: SCWM 0.6a: minor peeves In-reply-to: Your message of "Thu, 25 Jun 1998 12:06:33 EDT." <35927588.3C7C490@sig.bsh.com> Date: Thu, 25 Jun 1998 16:37:58 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jglick@sig.bsh.com writes: > Under SCWM 0.6a, error messages in scwmrepl go to the console (i.e. SCWM > fd #2) rather than stderr for the scwmrepl. E.g. typing in a bogus > expression will give #f as a result, but the actual error message goes > to SCWM stderr. > I reccomend upgrading to a newer version. You may have trouble building the recent 0.7 release; if so, try the latest snapshot. scmrepl has been much improved (along with the whole scwmexec protocol); error messages will now be reported directly in scwmrepl. > Also, one error message seems to have a misuse of some Scheme formatting > primitive: > > Scwm got an error; tag is > misc-error > (#f Unbound variable: %S (+++++) #f) > > The %S looks like a micro-braino. > This is probably a Guile problem, some of the error messages print bare %S's. However, new scwm versions have much more detailed error reporting, so if you try a newer version, you may be better able to track down what is causing this error (line number and file name are now given). > One more thing: I routinely (every few minutes?) get the following on > SCWM stderr: > > [Scwm][ScwmErrorHandler]: <> *** internal error *** > [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 2 > I think this bug is fixed in newer versions as well, I believe it was some flakiness relating to the icons or something, but I could be wrong. Thanks for the bug reports, and please let us know if the problems persist with the latest version. - Maciej From owner-scwm-discuss@mit.edu Thu Jun 25 22:15:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA25667 for scwm-discuss-outgoing; Thu, 25 Jun 1998 22:15:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA25661 for ; Thu, 25 Jun 1998 22:15:00 -0400 Received: from inferno.cs.univ-paris8.fr by MIT.EDU with SMTP id AA08584; Thu, 25 Jun 98 22:14:56 EDT Received: from neptune.bocal.cs.univ-paris8.fr (neptune.bocal.cs.univ-paris8.fr [192.168.3.2]) by inferno.cs.univ-paris8.fr (8.8.7/8.7.3) with ESMTP id EAA08756 for ; Fri, 26 Jun 1998 04:13:22 +0200 (CEST) Received: from aqua.bocal.cs.univ-paris8.fr (aqua.bocal.cs.univ-paris8.fr [192.168.3.3]) by neptune.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with ESMTP id EAA15274 for ; Fri, 26 Jun 1998 04:17:01 +0200 (MET DST) Received: from aqua.bocal.cs.univ-paris8.fr (localhost [127.0.0.1]) by aqua.bocal.cs.univ-paris8.fr (8.8.8/8.8.8) with SMTP id DAA11653 for ; Fri, 26 Jun 1998 03:16:36 +0100 (WET DST) Message-Id: <35930484.58E8@bocal.cs.univ-paris8.fr> Date: Fri, 26 Jun 1998 03:16:36 +0100 From: Kamel Sehil Organization: univ PARIS VIII X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.6 sun4u) Mime-Version: 1.0 To: scwm-discuss@mit.edu Subject: scwm compilations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk it's me again i just can't compile scwm0.7 , can someone tell me where i can found scwm0.6a.tar.gz , i want to look on configure diff beetwen both versions , on scwm0.6a , the configure (with small hack) find my guilelib , the scwm0.7 configure ignore them . From owner-scwm-discuss@mit.edu Thu Jun 25 23:48:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26181 for scwm-discuss-outgoing; Thu, 25 Jun 1998 23:48:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id XAA26178 for ; Thu, 25 Jun 1998 23:48:12 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA3441 for ; Thu, 25 Jun 1998 23:47:53 -0400 From: "Jason Kirtland" To: "scwm-discuss" Subject: 0.7 sds.scwmrc gotchas Date: Thu, 25 Jun 1998 23:43:51 -0400 Message-ID: <000401bda0b4$a2a19da0$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I found a couple of problems while tinkering with sds.scwmrc: I'm on a 8bit display. When the gradient style fails to allocate its colors, scwm dumps core. If (run-fvwm-module) can't find its module, scwm dies horribly. With some hacking I can get sds to load all the way through. What happens after is a bit odd, however: scwm hangs before decorating its windows, and keyboard & mouse clicks aren't recognized. This shows up on the console: potrzebie kernel: alpha_fp_emul: unexpected function code 0x9 at 0x155560bb940 potrzebie kernel: scwm: arithmetic trap at 00000155560bb944: 03 0001000000000000 There are serious floating point problems on my platform (Linux/Alpha 2.0.30) which are probably causing this bug (i.e. no fault of scwm's), but what struck me as odd is that it didn't croak with a floating point exception. -=j Error logs available on request. From owner-scwm-discuss@mit.edu Fri Jun 26 00:02:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26294 for scwm-discuss-outgoing; Fri, 26 Jun 1998 00:02:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA26291 for ; Fri, 26 Jun 1998 00:02:15 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA344A for ; Fri, 26 Jun 1998 00:01:58 -0400 From: "Jason Kirtland" To: "scwm-discuss" Subject: Re: scwm 0.7 notes Date: Thu, 25 Jun 1998 23:57:56 -0400 Message-ID: <000501bda0b6$9a043160$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > > > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > > > > bind a key at all. Or at least when the key is alphabetical. I think it would be handy to have a few convenience functions to determine what modifiers were available. I would be much happier crafting an rc file which made intelligent decisions based on, say, the availablity of a Hyper modifier rather than make huge conditional blocks based on machine name or something. Similarly, access to MAX_BUTTONS would be nice. (When its no longer hard-coded to 3... why is that, anyway?) -=j From owner-scwm-discuss@mit.edu Fri Jun 26 00:24:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26590 for scwm-discuss-outgoing; Fri, 26 Jun 1998 00:24:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26576; Fri, 26 Jun 1998 00:23:36 -0400 Message-Id: <199806260423.AAA26576@huis-clos.mit.edu> To: Kamel Sehil cc: scwm-discuss@mit.edu Subject: Re: scwm compilations In-reply-to: Your message of "Fri, 26 Jun 1998 03:16:36 BST." <35930484.58E8@bocal.cs.univ-paris8.fr> Date: Fri, 26 Jun 1998 00:23:35 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk skel@bocal.cs.univ-paris8.fr writes: > it's me again i just can't compile scwm0.7 , can someone tell me where i > can found scwm0.6a.tar.gz , i want to look on configure diff beetwen > both versions , on scwm0.6a , the configure (with small hack) find my > guilelib , the scwm0.7 configure ignore them . Look at ftp://huis-clos.mit.edu/pub/scwm The 0.6a and 0.6c versions are still there. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 00:34:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26755 for scwm-discuss-outgoing; Fri, 26 Jun 1998 00:34:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26748; Fri, 26 Jun 1998 00:34:21 -0400 Message-Id: <199806260434.AAA26748@huis-clos.mit.edu> To: "Jason Kirtland" cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "Thu, 25 Jun 1998 23:57:56 EDT." <000501bda0b6$9a043160$6463a7cc@panopticon.postalmodern.com> Date: Fri, 26 Jun 1998 00:34:21 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jason@postalmodern.com writes: > > > > > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > > > > > bind a key at all. Or at least when the key is alphabetical. > > I think it would be handy to have a few convenience functions to determine > what modifiers were available. I would be much happier crafting an rc file > which made intelligent decisions based on, say, the availablity of a Hyper > modifier rather than make huge conditional blocks based on machine name or > something. That's a good idea. An available-modifiers primitive or something. I guess this is another thing for the post-bugfix-release idea pile. > > Similarly, access to MAX_BUTTONS would be nice. (When its no longer > hard-coded to 3... why is that, anyway?) > Probably because no one whith a more than 3-button mouse ever looked at it. Do you actually have one? If so I'll take a look at handling this more gracefully. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Jun 26 00:41:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26861 for scwm-discuss-outgoing; Fri, 26 Jun 1998 00:41:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26855; Fri, 26 Jun 1998 00:41:33 -0400 Message-Id: <199806260441.AAA26855@huis-clos.mit.edu> To: "Jason Kirtland" cc: scwm-discuss@mit.edu Subject: Re: 0.7 sds.scwmrc gotchas In-reply-to: Your message of "Thu, 25 Jun 1998 23:43:51 EDT." <000401bda0b4$a2a19da0$6463a7cc@panopticon.postalmodern.com> Date: Fri, 26 Jun 1998 00:41:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jason@postalmodern.com writes: > I found a couple of problems while tinkering with sds.scwmrc: > > I'm on a 8bit display. When the gradient style fails to allocate its colors, > scwm dumps core. > SCWM has a number of problems with failed color allocations, left over from fvwm2 I believe. I will try to take a look, but I can't promise I will be able to do anything about it soon. > If (run-fvwm-module) can't find its module, scwm dies horribly. > That's also bad, I'll try to fix it, as I think a simple fix is quite possible. > With some hacking I can get sds to load all the way through. What happens > after is a bit odd, however: scwm hangs before decorating its windows, and > keyboard & mouse clicks aren't recognized. This shows up on the console: > > potrzebie kernel: alpha_fp_emul: unexpected function code 0x9 at > 0x155560bb940 > potrzebie kernel: scwm: arithmetic trap at 00000155560bb944: 03 > 0001000000000000 > > There are serious floating point problems on my platform (Linux/Alpha 2.0.30) > which are probably causing this bug (i.e. no fault of scwm's), but what > struck me as odd is that it didn't croak with a floating point exception. > I think this is because Guile catches SIGFPE and turns in into a Scheme-level exception, and because scwm aggresively tries to catch otherwise uncaught exceptions, so it might hang in this case instead of dieing. Scwm does in fact use floating-point in some of the initialization code. I'm not sure how to fix this problem, short of fixing the underlying problem with floating point on Linux/Alpha. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 00:50:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA27077 for scwm-discuss-outgoing; Fri, 26 Jun 1998 00:50:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA27071; Fri, 26 Jun 1998 00:50:37 -0400 Message-Id: <199806260450.AAA27071@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: crash In-reply-to: Your message of "25 Jun 1998 10:32:03 EDT." Date: Fri, 26 Jun 1998 00:50:37 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > 1. when I build: > Making all in doc > make[1]: Entering directory `/usr/src/scwm/doc' > make[1]: *** No rule to make target `all'. Stop. > make[1]: Leaving directory `/usr/src/scwm/doc' > make: *** [all-recursive] Error 1 > This definitely works for me. Maybe your TexInfo setup or something is messed up? > 2. when I run: > $ gdb scwm [... long backtrace ...] Yipe. I can't reproduce this here, and I can't guess what is going on from the backtrace. Looks like some file I/O thing is failing somewhere. Let me know if you continue to have this problem. Maybe your Guile install or your Scwm source got corrupted somehow? - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 07:34:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA29397 for scwm-discuss-outgoing; Fri, 26 Jun 1998 07:34:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA29394 for ; Fri, 26 Jun 1998 07:34:02 -0400 Received: from king.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA26383; Fri, 26 Jun 98 07:34:01 EDT Received: (from marko@localhost) by king.ki.informatik.uni-frankfurt.de (8.7.1/8.7.1) id NAA05972; Fri, 26 Jun 1998 13:33:58 +0200 (MESZ) Date: Fri, 26 Jun 1998 13:33:58 +0200 (MESZ) Message-Id: <199806261133.NAA05972@king.ki.informatik.uni-frankfurt.de> From: Marko Schuetz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Keyboard question X-Mailer: VM 6.34 under Emacs 20.2.1 Reply-To: marko@cs.uni-frankfurt.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have a Toshiba Portege laptop and try to do as much as possible with the keyboard. I do not have a use for the caps lock key and there is also a Fn key on the keyboard. Can I make these additional modifier keys recognized by X? Can I make e.g. caps lock the hyper key and the Fn key say super-duper Marko From owner-scwm-discuss@mit.edu Fri Jun 26 09:35:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30000 for scwm-discuss-outgoing; Fri, 26 Jun 1998 09:35:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mars.zserv.tuwien.ac.at (mars.zserv.tuwien.ac.at [193.170.75.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA29997 for ; Fri, 26 Jun 1998 09:35:32 -0400 Received: (qmail 7641 invoked by uid 524); 26 Jun 1998 13:35:29 -0000 To: scwm-discuss@mit.edu Subject: undecorated scwmrc X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 26 Jun 1998 15:35:29 +0200 Message-ID: Lines: 18 X-Mailer: Gnus v5.6.11/XEmacs 20.3 - "Vatican City" Organization: Gumby & Gumby, Brain Specialists Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, as quite a bunch of people were interested in my barebones scwmrc, I made it availiable as Some hints: * the standard modifier is super (s-), redefine the `super' function to change this. * s-d gives you back some decorations. * `which' malfunctions with some guile-versions. I think guile string-fun is to blame. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Jun 26 10:01:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30155 for scwm-discuss-outgoing; Fri, 26 Jun 1998 10:01:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA30152 for ; Fri, 26 Jun 1998 10:01:25 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA21186; Fri, 26 Jun 98 10:01:21 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id KAA22706; Fri, 26 Jun 1998 10:01:20 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by newman.concentric.net (8.8.8) id KAA12350; Fri, 26 Jun 1998 10:01:18 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id JAA21680; Fri, 26 Jun 1998 09:17:24 -0400 To: "Jason Kirtland" Cc: "scwm-discuss" Subject: Re: 0.7 sds.scwmrc gotchas References: <000401bda0b4$a2a19da0$6463a7cc@panopticon.postalmodern.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: "Jason Kirtland"'s message of Thu, 25 Jun 1998 23:43:51 -0400 Date: 26 Jun 1998 09:17:24 -0400 Message-Id: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <000401bda0b4$a2a19da0$6463a7cc@panopticon.postalmodern.com> >>>> Sent on Thu, 25 Jun 1998 23:43:51 -0400 >>>> Honorable "Jason Kirtland" writes >>>> on the subject of "0.7 sds.scwmrc gotchas": >> I found a couple of problems while tinkering with sds.scwmrc: >> >> I'm on a 8bit display. When the gradient style fails to allocate its colors, >> scwm dumps core. 1. I have a 16-bit display; sds.scwmrc uses gradients, which is very color-consuming; I don't think you will get anything pretty out of it on a 8-bit display without killing the gradient fills. 2. The distributed version is *very* old. While I am not sure that my current version is all that different from the distributed one, I'll submit mine now, it should be in the next snapshot then. 3. I am delighted to learn that someone is using my file! -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. An elephant is a mouse with an operating system. From owner-scwm-discuss@mit.edu Fri Jun 26 10:01:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30160 for scwm-discuss-outgoing; Fri, 26 Jun 1998 10:01:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA30157 for ; Fri, 26 Jun 1998 10:01:31 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA21216; Fri, 26 Jun 98 10:01:27 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id KAA22710; Fri, 26 Jun 1998 10:01:22 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by newman.concentric.net (8.8.8) id KAA12357; Fri, 26 Jun 1998 10:01:20 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id JAA21621; Fri, 26 Jun 1998 09:11:28 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: crash References: <199806260450.AAA27071@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of Fri, 26 Jun 1998 00:50:37 EDT Date: 26 Jun 1998 09:11:27 -0400 Message-Id: Lines: 49 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199806260450.AAA27071@huis-clos.mit.edu> >>>> Sent on Fri, 26 Jun 1998 00:50:37 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: crash": >> sds@goems.com writes: >> > 1. when I build: >> > Making all in doc >> > make[1]: Entering directory `/usr/src/scwm/doc' >> > make[1]: *** No rule to make target `all'. Stop. >> > make[1]: Leaving directory `/usr/src/scwm/doc' >> > make: *** [all-recursive] Error 1 >> > >> >> This definitely works for me. Maybe your TexInfo setup or something is >> messed up? when I do cvs -z9 update -dP, I get ? doc/Makefile apparently, doc/.cvsignore is missing. yep! I'll put it there. maybe that was the problem (preventing rebuilding of Makefile or somesuch). >> > 2. when I run: >> > $ gdb scwm >> [... long backtrace ...] >> >> Yipe. I can't reproduce this here, and I can't guess what is going on >> from the backtrace. Looks like some file I/O thing is failing >> somewhere. Let me know if you continue to have this problem. Maybe >> your Guile install or your Scwm source got corrupted somehow? I reinstalled the latest guile snapshot, and now I am stuck with gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6/include -g -O2 -c events.c In file included from events.c:79: guile-compat.h:40: conflicting types for `scm_parse_path' /usr/local/include/libguile/load.h:50: previous declaration of `scm_parse_path' make[1]: *** [events.o] Error 1 make[1]: Leaving directory `/usr/src/scwm/scwm' make: *** [all-recursive] Error 1 like everyone else... :-) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Fri Jun 26 10:43:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30446 for scwm-discuss-outgoing; Fri, 26 Jun 1998 10:43:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA30443 for ; Fri, 26 Jun 1998 10:43:53 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA02978; Fri, 26 Jun 98 10:43:52 EDT Received: from newman.concentric.net (newman.concentric.net [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id KAA29274; Fri, 26 Jun 1998 10:43:36 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by newman.concentric.net (8.8.8) id KAA22322; Fri, 26 Jun 1998 10:43:34 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id KAA25664; Fri, 26 Jun 1998 10:42:57 -0400 To: marko@cs.uni-frankfurt.de Cc: scwm-discuss@mit.edu Subject: Re: Keyboard question References: <199806261133.NAA05972@king.ki.informatik.uni-frankfurt.de> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Marko Schuetz's message of Fri, 26 Jun 1998 13:33:58 +0200 (MESZ) Date: 26 Jun 1998 10:42:57 -0400 Message-Id: Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199806261133.NAA05972@king.ki.informatik.uni-frankfurt.de> >>>> Sent on Fri, 26 Jun 1998 13:33:58 +0200 (MESZ) >>>> Honorable Marko Schuetz writes >>>> on the subject of "Keyboard question": >> I have a Toshiba Portege laptop and try to do as much as possible with >> the keyboard. I do not have a use for the caps lock key and there is >> also a Fn key on the keyboard. Can I make these additional modifier >> keys recognized by X? Can I make e.g. caps lock the hyper key and the >> Fn key say super-duper yes, xmodmap is your friend. (man xmodmap) you have to find out the keycodes for the keys you are about to modify (use xev for that), then create a file ~/.xmodmaprc and add `xmodmap ~/.xmodmaprc` to ~/.xsession or ~/.xinitrc depending on whether you use xdm or xinit. I have the following in my ~/.xmodmaprc: ------------------------------ ! Left win key keycode 115 = Hyper_L ! Right win key keycode 116 = Hyper_R ! Caps Lock keycode 66 = Hyper_L ! Menu key keycode 117 = Super_R add mod3 = Super_L Super_R add mod4 = Hyper_L Hyper_R ------------------------------ HTH -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A computer scientist is someone who fixes things that aren't broken. From owner-scwm-discuss@mit.edu Fri Jun 26 11:47:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30733 for scwm-discuss-outgoing; Fri, 26 Jun 1998 11:47:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mandrake.sig.bsh.com (sig-int-206.33.103.249.sig.bsh.com [206.33.103.249]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30730 for ; Fri, 26 Jun 1998 11:47:15 -0400 Received: from sig.bsh.com (localhost [127.0.0.1]) by mandrake.sig.bsh.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08371; Fri, 26 Jun 1998 11:48:03 -0400 Message-ID: <3593C2B3.7E4104CA@sig.bsh.com> Date: Fri, 26 Jun 1998 11:48:03 -0400 From: jason kirtland Organization: Strategic Interactive Group X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 6.3 IP32) MIME-Version: 1.0 To: Maciej Stachowiak CC: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak wrote: > > > [snip] > > > Probably because no one whith a more than 3-button mouse ever looked > at it. Do you actually have one? If so I'll take a look at handling > this more gracefully. Yeh, I've got a wheel mouse with up and down translated to buttons 4 and 5. I'm thinking the wheel would be great bound to desktop scrolling... I'm planning on playing around more seriously with the extra buttons next week- I'll let you know how things go. There is some handy multi-button mouse information at http://www.inria.fr/koala/colas/mouse-wheel-scroll/ The page is also chock full of clever ways to support wheel-scrolling in X apps using just X resources. -=j PS- also of interest over at inria is GWM, the long defunct but nifty Lisp(ish) based window manager. http://www.inria.fr/koala/gwm/ -- j a s o n k i r t l a n d e m e r g i n g t e c h n o l o g i e s s t r a t e g i c i n t e r a c t i v e g r o u p From owner-scwm-discuss@mit.edu Fri Jun 26 11:52:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30774 for scwm-discuss-outgoing; Fri, 26 Jun 1998 11:52:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA30770 for ; Fri, 26 Jun 1998 11:52:24 -0400 Received: by tis.bellhow.com; id LAA15221; Fri, 26 Jun 1998 11:52:22 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma015112; Fri, 26 Jun 98 11:51:46 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA26645 for ; Fri, 26 Jun 1998 11:51:45 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes Date: Fri, 26 Jun 1998 15:48:42 GMT Organization: Bell & Howell PSC Message-ID: <3593bb61.592854329@mailhost> References: <199806240215.WAA08452@huis-clos.mit.edu> In-Reply-To: <199806240215.WAA08452@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA30772 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 23 Jun 1998 22:15:57 EDT, you wrote: >mike@olan.com writes: >> 4) Just checking: have anyone here written a menu parser for >> Debian menus (like RedHat's wmconfig only different). Just so >> I won't duplicate the effort. >> > >Not to my knowledge. If you did it, that would be really cool, and I'd >gladly add it. There *is* a Debian package for scwm. I think it's for 0.5 or so. It definitely had some of the menu stuff in it. I was just starting to look at it last friday. I have been gone all this week at a class in Chicago (OO Analysis and Design using UML, Cool), so I can't say much. It appears that f.tapparo@vi.nettuno.it is the current maintainer. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Fri Jun 26 12:55:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA31270 for scwm-discuss-outgoing; Fri, 26 Jun 1998 12:55:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA31267 for ; Fri, 26 Jun 1998 12:55:25 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA07681; Fri, 26 Jun 98 12:55:20 EDT Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id MAA23198; Fri, 26 Jun 1998 12:55:16 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by mcfeely.concentric.net (8.8.8) id MAA13619; Fri, 26 Jun 1998 12:55:14 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id MAA25983; Fri, 26 Jun 1998 12:21:58 -0400 To: jason kirtland Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <3593C2B3.7E4104CA@sig.bsh.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: jason kirtland's message of Fri, 26 Jun 1998 11:48:03 -0400 Date: 26 Jun 1998 12:21:58 -0400 Message-Id: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <3593C2B3.7E4104CA@sig.bsh.com> >>>> Sent on Fri, 26 Jun 1998 11:48:03 -0400 >>>> Honorable jason kirtland writes >>>> on the subject of "Re: scwm 0.7 notes": >> >> PS- also of interest over at inria is GWM, the long defunct but >> nifty Lisp(ish) based window manager. >> >> http://www.inria.fr/koala/gwm/ it's not defunct, just not actively developed anymore. it still has many features that other wm's lack: like infinite size desktops, placement functions etc. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Why use Windows, when there are Doors? From owner-scwm-discuss@mit.edu Fri Jun 26 13:14:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31418 for scwm-discuss-outgoing; Fri, 26 Jun 1998 13:14:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31415 for ; Fri, 26 Jun 1998 13:14:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08038; Fri, 26 Jun 98 13:14:26 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA29677; Fri, 26 Jun 1998 10:14:27 -0700 (PDT) To: sds@goems.com Cc: jason kirtland , Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <3593C2B3.7E4104CA@sig.bsh.com> From: Greg Badros Date: 26 Jun 1998 10:14:26 -0700 In-Reply-To: Sam Steingold's message of "26 Jun 1998 12:21:58 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <3593C2B3.7E4104CA@sig.bsh.com> > >>>> Sent on Fri, 26 Jun 1998 11:48:03 -0400 > >>>> Honorable jason kirtland writes > >>>> on the subject of "Re: scwm 0.7 notes": > >> > >> PS- also of interest over at inria is GWM, the long defunct but > >> nifty Lisp(ish) based window manager. > >> > >> http://www.inria.fr/koala/gwm/ > > it's not defunct, just not actively developed anymore. > it still has many features that other wm's lack: like infinite size > desktops, placement functions etc. Yep, GWM is pretty nifty. There is lots of good code and ideas in there (the synthetic keypresses I added to scwm a while back were motivated and inspired by GWM's similar feature). Down side of GWM was trying to do too much in WOOL (its Lisp-like configuration language) and not enough in C. Greg From owner-scwm-discuss@mit.edu Fri Jun 26 13:46:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31640 for scwm-discuss-outgoing; Fri, 26 Jun 1998 13:46:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31637 for ; Fri, 26 Jun 1998 13:46:38 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA15274; Fri, 26 Jun 98 13:46:33 EDT Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id NAA09183; Fri, 26 Jun 1998 13:46:34 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by mcfeely.concentric.net (8.8.8) id NAA27753; Fri, 26 Jun 1998 13:46:33 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA26460; Fri, 26 Jun 1998 13:46:14 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <3593C2B3.7E4104CA@sig.bsh.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of 26 Jun 1998 10:14:26 -0700 Date: 26 Jun 1998 13:46:13 -0400 Message-Id: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 26 Jun 1998 10:14:26 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: scwm 0.7 notes": >> Sam Steingold writes: >> >> > >> http://www.inria.fr/koala/gwm/ >> > >> > it's not defunct, just not actively developed anymore. >> > it still has many features that other wm's lack: like infinite size >> > desktops, placement functions etc. >> >> Yep, GWM is pretty nifty. There is lots of good code and ideas in there >> (the synthetic keypresses I added to scwm a while back were motivated >> and inspired by GWM's similar feature). what is a "synthetic keypress"? >> Down side of GWM was trying to do too much in WOOL (its Lisp-like WOOL == window object-oriented lisp >> configuration language) and not enough in C. Well, I'd say that the problem is that WOOL does not have a good compiler (actually, no compiler at all). When and if guile will have a decent compiler, much of scwm development should move to guile. (IMHO) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. The difference between genius and stupidity is that genius has its limits. From owner-scwm-discuss@mit.edu Fri Jun 26 15:48:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA32159 for scwm-discuss-outgoing; Fri, 26 Jun 1998 15:48:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA32156 for ; Fri, 26 Jun 1998 15:48:36 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22828; Fri, 26 Jun 98 15:48:31 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA04326; Fri, 26 Jun 1998 12:48:33 -0700 (PDT) To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <3593C2B3.7E4104CA@sig.bsh.com> From: Greg Badros Date: 26 Jun 1998 12:48:32 -0700 In-Reply-To: Sam Steingold's message of "26 Jun 1998 13:46:13 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: scwm 0.7 notes": > >> Sam Steingold writes: > >> > >> > >> http://www.inria.fr/koala/gwm/ > >> > > >> > it's not defunct, just not actively developed anymore. > >> > it still has many features that other wm's lack: like infinite size > >> > desktops, placement functions etc. > >> > >> Yep, GWM is pretty nifty. There is lots of good code and ideas in there > >> (the synthetic keypresses I added to scwm a while back were motivated > >> and inspired by GWM's similar feature). > > what is a "synthetic keypress"? A "fake" keypress event that the window manager can send to an application. e.g., C-S-M-7 sends a Mouse-button-1-down and Mouse-button-1-up event in my SCWM configuration so that I can clink on links in Netscape Communicator w/o using the mouse. Greg From owner-scwm-discuss@mit.edu Fri Jun 26 16:28:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA32645 for scwm-discuss-outgoing; Fri, 26 Jun 1998 16:28:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA32642 for ; Fri, 26 Jun 1998 16:28:23 -0400 Received: from talisker.channelpoint.com by MIT.EDU with SMTP id AA03113; Fri, 26 Jun 98 16:28:23 EDT Received: by channelpoint.com (SMI-8.6/SMI-SVR4) id OAA26490; Fri, 26 Jun 1998 14:28:19 -0600 To: Greg Badros Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <3593C2B3.7E4104CA@sig.bsh.com> From: Sam Falkner Date: 26 Jun 1998 14:28:18 -0600 In-Reply-To: Greg Badros's message of "26 Jun 1998 12:48:32 -0700" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.16/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > A "fake" keypress event that the window manager can send to an > application. e.g., C-S-M-7 sends a Mouse-button-1-down and > Mouse-button-1-up event in my SCWM configuration so that I can clink on > links in Netscape Communicator w/o using the mouse. cool, but (stupid question) doesn't the mouse cursor have to already be sitting on the link that you want? i pride myself on how many hours i can go without touching a mouse, and web browsing is one of the few remaining tasks where i need the mouse. thanks! - sam From owner-scwm-discuss@mit.edu Fri Jun 26 16:34:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00012 for scwm-discuss-outgoing; Fri, 26 Jun 1998 16:34:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00007; Fri, 26 Jun 1998 16:34:31 -0400 Message-Id: <199806262034.QAA00007@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: crash In-reply-to: Your message of "26 Jun 1998 09:11:27 EDT." Date: Fri, 26 Jun 1998 16:34:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > I reinstalled the latest guile snapshot, and now I am stuck with > > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6/include -g -O2 -c e > vents.c > In file included from events.c:79: > guile-compat.h:40: conflicting types for `scm_parse_path' > /usr/local/include/libguile/load.h:50: previous declaration of `scm_parse_ > path' > make[1]: *** [events.o] Error 1 > make[1]: Leaving directory `/usr/src/scwm/scwm' > make: *** [all-recursive] Error 1 > > like everyone else... :-) > Whoops. I just fixed this problem in CVS, people who can't wait for the snapshot and are having this problem (I guess I will wait until tomorrow morning for the release since the bugs are still coming in) feel free to delete that prototype from guile-compat.h. From owner-scwm-discuss@mit.edu Fri Jun 26 16:37:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00083 for scwm-discuss-outgoing; Fri, 26 Jun 1998 16:37:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00069; Fri, 26 Jun 1998 16:37:45 -0400 Message-Id: <199806262037.QAA00069@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: 0.7 sds.scwmrc gotchas In-reply-to: Your message of "26 Jun 1998 09:17:24 EDT." Date: Fri, 26 Jun 1998 16:37:45 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <000401bda0b4$a2a19da0$6463a7cc@panopticon.postalmodern.co > m> > >>>> Sent on Thu, 25 Jun 1998 23:43:51 -0400 > >>>> Honorable "Jason Kirtland" writes > >>>> on the subject of "0.7 sds.scwmrc gotchas": > >> I found a couple of problems while tinkering with sds.scwmrc: > >> > >> I'm on a 8bit display. When the gradient style fails to allocate its > colors, > >> scwm dumps core. > > 1. I have a 16-bit display; sds.scwmrc uses gradients, which is very > color-consuming; I don't think you will get anything pretty out of it on > a 8-bit display without killing the gradient fills. > Well, I think I just made it throw an error instead of dumping core when it can't allocate colors, which should be nicer. I think in general we will need to look into ways of reducing color usage on 8-bit displays - maybe automatic dithering to a reduced pallette or something. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 17:18:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA00738 for scwm-discuss-outgoing; Fri, 26 Jun 1998 17:18:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA00735 for ; Fri, 26 Jun 1998 17:18:49 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA15209; Fri, 26 Jun 98 17:18:49 EDT Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id RAA15411; Fri, 26 Jun 1998 17:18:46 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts004d32.phe-pa.concentric.net [209.31.154.188]) by mcfeely.concentric.net (8.8.8) id RAA25784; Fri, 26 Jun 1998 17:18:44 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id RAA27315; Fri, 26 Jun 1998 17:18:02 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: crash References: <199806262034.QAA00007@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of Fri, 26 Jun 1998 16:34:31 EDT Date: 26 Jun 1998 17:17:59 -0400 Message-Id: Lines: 75 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199806262034.QAA00007@huis-clos.mit.edu> >>>> Sent on Fri, 26 Jun 1998 16:34:31 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: crash": >> > guile-compat.h:40: conflicting types for `scm_parse_path' >> > /usr/local/include/libguile/load.h:50: previous declaration of `scm_parse_ >> > path' >> > make[1]: *** [events.o] Error 1 >> >> Whoops. I just fixed this problem in CVS, people who can't wait for >> the snapshot and are having this problem (I guess I will wait until >> tomorrow morning for the release since the bugs are still coming in) >> feel free to delete that prototype from guile-compat.h. I synced my source tree with the huis-clos, and tried to compile. I got several compilation errors, which I fixed by $ cvs diff -cwb scwm/guile-compat.h Index: scwm/guile-compat.h =================================================================== RCS file: /usr/local/repository/scwm/scwm/guile-compat.h,v retrieving revision 1.6 diff -c -w -b -r1.6 guile-compat.h *** guile-compat.h 1998/06/26 20:32:38 1.6 --- guile-compat.h 1998/06/26 21:15:31 *************** *** 33,45 **** #define gh_length gh_list_length #endif /* HAVE_GH_LENGTH */ - #ifndef HAVE_SCM_INTERNAL_SELECT #define scm_internal_select select - #endif - - #ifndef HAVE_SCM_INTERNAL_PARSE_PATH - SCM scm_parse_path (char *path, SCM tail); - #endif #ifndef HAVE_GH_VECTOR_SET_X #define gh_vector_set_x gh_vset --- 33,39 ---- then I managed to compile, and now I am getting a segfault: Starting program: /usr/src/scwm/scwm/scwm Program received signal SIGSEGV, Segmentation fault. 0x400e880c in scm_parse_path (path=0, tail=1076046968) at load.c:179 179 SCM_ASSERT (SCM_FALSEP (path) || (SCM_NIMP (path) && SCM_ROSTRINGP (path)), (gdb) where #0 0x400e880c in scm_parse_path (path=0, tail=1076046968) at load.c:179 #1 0x8055e7e in init_scwm_load_path () at scwm.c:1445 #2 0x80549b8 in scwm_main (argc=1, argv=0xbffffb1c) at scwm.c:488 #3 0x8054199 in scwm_gh_launch_pad (closure=0x80541d0, argc=1, argv=0xbffffb1c) at scwm.c:163 #4 0x400e659c in invoke_main_func (body_data=0xbffffac4) at init.c:506 #5 0x40107dcc in scm_internal_catch (tag=9076, body=0x400e657c , body_data=0xbffffac4, handler=0x4010822c , handler_data=0x0) at throw.c:236 #6 0x400e6553 in scm_boot_guile_1 (base=0xbffffac0, closure=0xbffffac4) at init.c:482 #7 0x400e6309 in scm_boot_guile (argc=1, argv=0xbffffb1c, main_func=0x805417c , closure=0x80541d0) at init.c:347 #8 0x80541b6 in scwm_gh_enter (argc=1, argv=0xbffffb1c, c_main_prog=0x80541d0 ) at scwm.c:170 #9 0x80541cb in main (argc=1, argv=0xbffffb1c) at scwm.c:185 -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. If it has syntax, it isn't user friendly. From owner-scwm-discuss@mit.edu Fri Jun 26 17:38:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01003 for scwm-discuss-outgoing; Fri, 26 Jun 1998 17:38:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA00998 for ; Fri, 26 Jun 1998 17:38:14 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAA3708 for ; Fri, 26 Jun 1998 17:37:52 -0400 From: "Jason Kirtland" To: "scwm-discuss" Subject: can't find guile (was: scwm compilations) Date: Fri, 26 Jun 1998 17:33:47 -0400 Message-ID: <000001bda14a$1a39f660$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've run into a situation similar to Kamel's while trying to build scwm at work. I've got guile built and installed onto a local drive on my workstation- the ld paths are all hunky dory, and guile works. However, configure gets a bit confused. I do this: INCLUDES=/flurble/include LIBS=/flurble/lib ./configure --prefix=/flurble This makes configure happy- it finds guile and sets things up properly. However, when it gets around to making the Makefiles, the include and lib information vanishes. Ok, so I edit scwm/Makefile appropriately and do a make. Things go fine until the Makefile gets re-written and I've got to modify it again. (grumble). Could/does configure take an option akin to --guile-prefix= that would propagate to the Makefiles? -=j From owner-scwm-discuss@mit.edu Fri Jun 26 17:38:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01004 for scwm-discuss-outgoing; Fri, 26 Jun 1998 17:38:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from waste.postalmodern.com (waste.postalmodern.com [204.167.99.101]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA00997 for ; Fri, 26 Jun 1998 17:38:14 -0400 Received: from panopticon.postalmodern.com ([204.167.99.100]) by waste.postalmodern.com (Netscape Messaging Server 3.5) with ESMTP id AAB3708; Fri, 26 Jun 1998 17:37:53 -0400 From: "Jason Kirtland" To: Cc: "scwm-discuss" Subject: Re: 0.7 sds.scwmrc gotchas Date: Fri, 26 Jun 1998 17:33:48 -0400 Message-ID: <000101bda14a$1aa64cc0$6463a7cc@panopticon.postalmodern.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak wrote: > > [snip: floating point woes on Linux/Alpha] > > I'm not sure how to fix this problem, short of fixing the underlying > problem with floating point on Linux/Alpha. The Linux/Alpha floating point problems have been getting some attention lately... potrzebie$ ./mozilla Floating point exception potrzebie$ *sigh* -=j From owner-scwm-discuss@mit.edu Fri Jun 26 22:07:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02605 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:07:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02600; Fri, 26 Jun 1998 22:07:11 -0400 Message-Id: <199806270207.WAA02600@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: undecorated scwmrc In-reply-to: Your message of "26 Jun 1998 15:35:29 +0200." Date: Fri, 26 Jun 1998 22:07:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk e9426626@stud2.tuwien.ac.at writes: > Hi, > > as quite a bunch of people were interested in my barebones scwmrc, I > made it availiable as > > > Some hints: > * the standard modifier is super (s-), redefine the `super' function > to change this. > * s-d gives you back some decorations. > * `which' malfunctions with some guile-versions. I think guile > string-fun is to blame. > Maybe you could check it into CVS after the bugfix release? If a lot of people are interested, we may as well distribute it. You don't have to, of course, but it might be useful. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 22:09:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02649 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:09:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02645; Fri, 26 Jun 1998 22:09:35 -0400 Message-Id: <199806270209.WAA02645@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "Fri, 26 Jun 1998 15:48:42 GMT." <3593bb61.592854329@mailhost> Date: Fri, 26 Jun 1998 22:09:35 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > On Tue, 23 Jun 1998 22:15:57 EDT, you wrote: > >mike@olan.com writes: > >> 4) Just checking: have anyone here written a menu parser for > >> Debian menus (like RedHat's wmconfig only different). Just so > >> I won't duplicate the effort. > >> > > > >Not to my knowledge. If you did it, that would be really cool, and I'd > >gladly add it. > > There *is* a Debian package for scwm. I think it's for 0.5 or so. It > definitely had some of the menu stuff in it. I was just starting to look > at > it last friday. I have been gone all this week at a class in Chicago (OO > Analysis and Design using UML, Cool), so I can't say much. > > It appears that f.tapparo@vi.nettuno.it is the current maintainer. > Hmm, perhaps I should write to him. He was interested in doing an upstream upgrade at some point. I'm not sure how the Debian menu system is normally handled, but it would be neat to have code to parse the menu stuff directly from scwm if that would be possible, and to distribute it along with scwm so Debian users don't have to depend on just the packaged version. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 22:17:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02803 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:17:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02798; Fri, 26 Jun 1998 22:17:14 -0400 Message-Id: <199806270217.WAA02798@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "26 Jun 1998 13:46:13 EDT." Date: Fri, 26 Jun 1998 22:17:14 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > Well, I'd say that the problem is that WOOL does not have a good > compiler (actually, no compiler at all). When and if guile will have a > decent compiler, much of scwm development should move to guile. (IMHO) > The available Guile compiler, hobbit (available in the contrib section of the Guile archive) is reportedly pretty good. I'm kind of holding off on using it for scwm until it is stable, officially supported, and widely used. Some stuff will always have to be in C, of course; at the very least enough stuff to export the X primitives needed for window management. I guess we'll see where the performance/flexibility tradeoff ends up. - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 22:24:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02913 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:24:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA02902; Fri, 26 Jun 1998 22:24:47 -0400 Message-Id: <199806270224.WAA02902@huis-clos.mit.edu> To: Sam Falkner cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "26 Jun 1998 14:28:18 MDT." Date: Fri, 26 Jun 1998 22:24:47 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk samf@channelpoint.com writes: > cool, but (stupid question) doesn't the mouse cursor have to already > be sitting on the link that you want? > > i pride myself on how many hours i can go without touching a mouse, > and web browsing is one of the few remaining tasks where i need the > mouse. > Greg also uses other window manager keybindings for warping the mouse cursor by various amounts. Web browsing is one of the few tasks I use the mouse for as well (well, that and using the GIMP), but I'm not quite hardcore enough to use bindings like that myself :-) - Maciej From owner-scwm-discuss@mit.edu Fri Jun 26 22:57:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA03192 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:57:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA03188; Fri, 26 Jun 1998 22:57:10 -0400 Message-Id: <199806270257.WAA03188@huis-clos.mit.edu> To: "Jason Kirtland" cc: scwm-discuss@mit.edu Subject: Re: can't find guile (was: scwm compilations) In-reply-to: Your message of "Fri, 26 Jun 1998 17:33:47 EDT." <000001bda14a$1a39f660$6463a7cc@panopticon.postalmodern.com> Date: Fri, 26 Jun 1998 22:57:10 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jason@postalmodern.com writes: > I've run into a situation similar to Kamel's while trying to build scwm at > work. > > I've got guile built and installed onto a local drive on my workstation- t > he > ld paths are all hunky dory, and guile works. However, configure gets a b > it > confused. I do this: > > INCLUDES=/flurble/include LIBS=/flurble/lib ./configure --prefix=/flurble > > This makes configure happy- it finds guile and sets things up properly. > However, when it gets around to making the Makefiles, the include and lib > information vanishes. Ok, so I edit scwm/Makefile appropriately and do a > make. Things go fine until the Makefile gets re-written and I've got to > modify it again. (grumble). > > Could/does configure take an option akin to --guile-prefix= that would > propagate to the Makefiles? > It doesn't, but that is a great idea. I'll add --with-guile-prefix= (and maybe --with-guile-exec-prefix=) ASAP, since numerous people are hacing this problem. Ideally, there should be an AM_PATH_GUILE macro that would handle such things automatically, maybe I will try to hack one up and submit it to the automake maintainer (but I will probably wait until Guile 1.3 is out so it doesn't have to deal with 1.2 compatibility). - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Jun 26 22:59:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA03251 for scwm-discuss-outgoing; Fri, 26 Jun 1998 22:59:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA03246 for ; Fri, 26 Jun 1998 22:59:35 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA28090; Fri, 26 Jun 98 22:59:33 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA03238; Fri, 26 Jun 1998 22:59:31 -0400 Message-Id: <199806270259.WAA03238@huis-clos.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: crash In-Reply-To: Your message of "26 Jun 1998 17:17:59 EDT." Date: Fri, 26 Jun 1998 22:59:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > I synced my source tree with the huis-clos, and tried to compile. I got > several compilation errors, which I fixed by I believe your patch (snipped below) is indicative of not removing config.cache and reconfiguring after installing the new guile. > > then I managed to compile, and now I am getting a segfault: > > Starting program: /usr/src/scwm/scwm/scwm > > Program received signal SIGSEGV, Segmentation fault. > 0x400e880c in scm_parse_path (path=0, tail=1076046968) at load.c:179 > 179 SCM_ASSERT (SCM_FALSEP (path) || (SCM_NIMP (path) && SCM_ROSTRINGP > (path)), The path here is NULL it seems, I'm guessing that might also be a configure problem. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sat Jun 27 11:24:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06981 for scwm-discuss-outgoing; Sat, 27 Jun 1998 11:24:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06978 for ; Sat, 27 Jun 1998 11:24:49 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA10346; Sat, 27 Jun 98 11:24:49 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA12989; Sat, 27 Jun 1998 18:24:39 +0300 To: scwm-discuss@mit.edu Subject: cvs repository checkout failure. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 27 Jun 1998 18:24:39 +0300 Message-Id: Lines: 14 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried to checkout from the CVS repository, but failed: hjstein@bacall:~/software/guilesw$ cvs -d :pserver:anonymous@huis-clos.mit.edu:/usr/local/repository checkout scwm -d scwm-repo cvs [checkout aborted]: connect to huis-clos.mit.edu:2401 failed: Connection refused Attempts at cvs login also fail with "Connection refused". What's the scoop? I thought anonymous CVS was supported. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Jun 27 11:30:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA07053 for scwm-discuss-outgoing; Sat, 27 Jun 1998 11:30:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA07050 for ; Sat, 27 Jun 1998 11:30:21 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA10805; Sat, 27 Jun 98 11:30:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA13019; Sat, 27 Jun 1998 18:30:18 +0300 Date: Sat, 27 Jun 1998 18:30:18 +0300 Message-Id: <199806271530.SAA13019@blinky.bfr.co.il> From: "Harvey J. Stein" To: scwm-discuss@mit.edu Subject: Configure & compilation failures. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have guile 1.2 installed in /usr/local. I'm running (more or less) RH 4.2 Linux. With scwm-0.7, when trying to compile, I get (as expected from the mailing list): /bin/sh ../libtool --mode=link gcc -g -O2 -o scwm string_token.o ICCCM.o system.o Grab.o add_window.o borders.o colormaps.o colors.o complex.o decorations.o events.o focus.o scwm.o icons.o misc.o xmisc.o move.o placement.o resize.o virtual.o scmprocs.o scmtypes.o font.o color.o miscprocs.o binding.o errors.o util.o window.o scwmmenu.o drawmenu.o menuitem.o deskpage.o decor.o face.o module-interface.o image.o callbacks.o shutdown.o init_scheme_string.o guile-compat.o syscompat.o getopt.o getopt1.o -L/usr/X11R6/lib -lXext -lXpm -lX11 -lguile -ldl -lqt -lrx -lm gcc -g -O2 -o scwm string_token.o ICCCM.o system.o Grab.o add_window.o borders.o colormaps.o colors.o complex.o decorations.o events.o focus.o scwm.o icons.o misc.o xmisc.o move.o placement.o resize.o virtual.o scmprocs.o scmtypes.o font.o color.o miscprocs.o binding.o errors.o util.o window.o scwmmenu.o drawmenu.o menuitem.o deskpage.o decor.o face.o module-interface.o image.o callbacks.o shutdown.o init_scheme_string.o guile-compat.o syscompat.o getopt.o getopt1.o -L/usr/X11R6/lib -lXext -lXpm -lX11 -lguile -ldl -lqt -lrx -lm callbacks.o: In function `force_new_input_hooks': /home/hjstein/software/guilesw/scwm-0.7/scwm/callbacks.c:536: undefined reference to `gh_memq' make[1]: *** [scwm] Error 1 So, I tried out scwm-19980627.tar.gz (which I thought would fix the problem). This one doesn't configure cleanly: checking for scm_handle_by_message_noexit in -lguile... ./configure: -ldl: command not found no configure: error: Can not find Guile 1.2 or later on the system -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Jun 27 12:21:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07299 for scwm-discuss-outgoing; Sat, 27 Jun 1998 12:21:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA07296 for ; Sat, 27 Jun 1998 12:21:49 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA22357; Sat, 27 Jun 98 12:21:45 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA13202; Sat, 27 Jun 1998 19:21:39 +0300 To: scwm-discuss@mit.edu Subject: Re: Configure & compilation failures. References: <199806271530.SAA13019@blinky.bfr.co.il> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 27 Jun 1998 19:21:39 +0300 In-Reply-To: "Harvey J. Stein"'s message of "Sat, 27 Jun 1998 18:30:18 +0300" Message-Id: Lines: 43 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Harvey J. Stein" writes: > So, I tried out scwm-19980627.tar.gz (which I thought would fix the > problem). This one doesn't configure cleanly: > > checking for scm_handle_by_message_noexit in -lguile... ./configure: > -ldl: command not found > no > configure: error: Can not find Guile 1.2 or later on the system Deleting two double quotes from scwm-19980627/configure allowed it to compile & build. Here's a patch: diff -C 4 scwm-19980627/configure scwm-19980627.new/configure *** scwm-19980627/configure Sat Jun 27 08:53:08 1998 --- scwm-19980627.new/configure Sat Jun 27 19:05:33 1998 *************** *** 2977,2985 **** if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then echo $ac_n "(cached) $ac_c" 1>&6 else ac_save_LIBS="$LIBS" ! LIBS="-lguile "${GUILE_LIBS_PRE} ${GUILE_LIBS}" $LIBS" cat > conftest.$ac_ext <&6 else ac_save_LIBS="$LIBS" ! LIBS="-lguile ${GUILE_LIBS_PRE} ${GUILE_LIBS} $LIBS" cat > conftest.$ac_ext <; Sat, 27 Jun 1998 15:58:58 -0400 Received: from eshu.request.net by MIT.EDU with SMTP id AA00705; Sat, 27 Jun 98 15:58:58 EDT Received: from munin.request.net ([208.236.140.172]) by eshu.request.net with ESMTP id <416-14381>; Sat, 27 Jun 1998 15:58:45 -0400 Received: from localhost ([132.66.250.95]) by munin.request.net with SMTP id <4881873-2510>; Sat, 27 Jun 1998 15:58:36 -0400 Received: from cmm by localhost with local (Exim 1.62 #1) id 0yq17Q-00009Y-00 (Debian); Sat, 27 Jun 1998 22:58:40 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <199806270209.WAA02645@huis-clos.mit.edu> Reply-To: mike@olan.com Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: mike@olan.com (Michael N. Livshin) Date: 27 Jun 1998 22:58:40 +0300 In-Reply-To: Maciej Stachowiak's message of "Fri, 26 Jun 1998 22:09:35 EDT" Message-Id: <85iulmzken.fsf@alucard.one.way> Lines: 44 X-Mailer: Gnus v5.6.2/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > dale.smith@bellhow.com writes: > > There *is* a Debian package for scwm. I think it's for 0.5 or so. It > > definitely had some of the menu stuff in it. I was just starting to look > > at > > it last friday. I have been gone all this week at a class in Chicago (OO > > Analysis and Design using UML, Cool), so I can't say much. > > > > It appears that f.tapparo@vi.nettuno.it is the current maintainer. > > > > Hmm, perhaps I should write to him. He was interested in doing an > upstream upgrade at some point. I'm not sure how the Debian menu > system is normally handled, but it would be neat to have code to parse > the menu stuff directly from scwm if that would be possible, and to > distribute it along with scwm so Debian users don't have to depend on > just the packaged version. Well, I just checked the Debian package, and here are my findings: 1) It handles the menus all right. 2) Debian menus are not ment to be parsed by WM at run-time - instead, each WM package provides a way to generate menus for it. Once. The WM is then registered with the debian-menu thingie, so that when any package with a menu entry is installed on the system, the menus for all WM's are updated. Once. The system.scwmrc that is installed by the SCWM package just reads in the static file with the pre-made menus. 3) Hopefully the previous paragraph is human-parseable :) 4) The bottom line: dealing with Debian menus is an install-time issue. Interacting with the Debian menu system (registering a menu generator, deregistering the menu generator, etc.) appears to be complex enough to not bother with it at all. In general, Debian menus probably shouldn't be dealt with in upstream packages. After all, if root wants to play with SCWM and have it integrated with the system, it's straightforward to grab the Debian diff and build Debian package. > - Maciej mike. From owner-scwm-discuss@mit.edu Sun Jun 28 11:04:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA08503 for scwm-discuss-outgoing; Sun, 28 Jun 1998 11:04:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA08500 for ; Sun, 28 Jun 1998 11:04:16 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01738; Sun, 28 Jun 98 11:04:13 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA19212; Sun, 28 Jun 1998 18:04:12 +0300 To: scwm-discuss@mit.edu Subject: Startup time seems long. Why? Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 28 Jun 1998 18:04:11 +0300 In-Reply-To: hjstein@bfr.co.il's message of "27 Jun 1998 19:21:39 +0300" Message-Id: Lines: 13 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Startup time (& time to do restarts) seems to be long for scwm. Does anyone know why? Is it predominantly guile startup time? I'm using guile 1.2. Is it any better with the guile snapshots? Is there any possibility of a restart which just goes back to the initial state & re-reads the appropriate files (as opposed to what it seems to do, namely killing & restarting itself)? Thanks, Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Jun 28 11:08:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA08535 for scwm-discuss-outgoing; Sun, 28 Jun 1998 11:08:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA08532 for ; Sun, 28 Jun 1998 11:08:07 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01914; Sun, 28 Jun 98 11:08:04 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA19231; Sun, 28 Jun 1998 18:08:03 +0300 To: scwm-discuss@mit.edu Subject: Long click times. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 28 Jun 1998 18:08:03 +0300 In-Reply-To: hjstein@bfr.co.il's message of "27 Jun 1998 19:21:39 +0300" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Another thing which seems slow with scwm is processing mouse clicks. I have the usual sort of maximize title bar button. It seems to take a while after clicking on it before the window changes. The same goes for my alt-mouse-1 (alt-mouse-3) which is bound to move-or-lower (raise-or-lower). Is this because scwm is delaying processing of mouse clicks to make sure they're not double clicks? Is there any way around this? Thanks, Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Jun 28 14:10:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA09554 for scwm-discuss-outgoing; Sun, 28 Jun 1998 14:10:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA09551 for ; Sun, 28 Jun 1998 14:10:48 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id UAA14592 for scwm-discuss@huis-clos.mit.edu; Sun, 28 Jun 1998 20:10:46 +0200 (CEST) Received: (qmail 759 invoked by uid 115); 28 Jun 1998 14:06:46 -0000 To: scwm-discuss@mit.edu Subject: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Jun 1998 16:06:45 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 26 Jun 1998 00:41:32 EDT" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 26 Jun 1998 00:41:32 EDT >>>>> Maciej Stachowiak said: Maciej> [...] scwm aggresively tries to catch otherwise uncaught Maciej> exceptions, so it might hang in this case instead of dieing. What about also catching SIGSEGV, and trying to exit cleanly in this case (like on SIGINT and friends)? It's very humilating having to resort to cut-and-pasting commandlines, because your wm has crashed on you while it had the keyboard grabbed, or somesuch. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Jun 28 14:23:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA09780 for scwm-discuss-outgoing; Sun, 28 Jun 1998 14:23:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA09777 for ; Sun, 28 Jun 1998 14:23:08 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26482; Sun, 28 Jun 98 14:23:09 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA06098; Sun, 28 Jun 1998 11:23:11 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> From: Greg Badros Date: 28 Jun 1998 11:23:11 -0700 In-Reply-To: Robert Bihlmeyer's message of "28 Jun 1998 16:06:45 +0200" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On Fri, 26 Jun 1998 00:41:32 EDT > >>>>> Maciej Stachowiak said: > > Maciej> [...] scwm aggresively tries to catch otherwise uncaught > Maciej> exceptions, so it might hang in this case instead of dieing. > > What about also catching SIGSEGV, and trying to exit cleanly in this > case (like on SIGINT and friends)? Good idea.... we should definitely try to do a better job about this... > It's very humilating having to resort to cut-and-pasting commandlines, > because your wm has crashed on you while it had the keyboard grabbed, > or somesuch. :-) I'm glad I'm not the only one! Greg From owner-scwm-discuss@mit.edu Mon Jun 29 03:49:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA14148 for scwm-discuss-outgoing; Mon, 29 Jun 1998 03:49:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA14145 for ; Mon, 29 Jun 1998 03:49:24 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id JAA25332 for scwm-discuss@huis-clos.mit.edu; Mon, 29 Jun 1998 09:49:15 +0200 (CEST) Received: (qmail 1093 invoked by uid 115); 28 Jun 1998 18:53:33 -0000 To: scwm-discuss@mit.edu Subject: Re: Long click times. References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Jun 1998 20:53:32 +0200 In-Reply-To: hjstein@bfr.co.il's message of "28 Jun 1998 18:08:03 +0300" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 28 Jun 1998 18:08:03 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> Another thing which seems slow with scwm is processing mouse Harvey> clicks. I have the usual sort of maximize title bar button. Harvey> It seems to take a while after clicking on it before the Harvey> window changes. The same goes for my alt-mouse-1 Harvey> (alt-mouse-3) which is bound to move-or-lower Harvey> (raise-or-lower). Harvey> Is this because scwm is delaying processing of mouse clicks Harvey> to make sure they're not double clicks? Yes, and it could also be a drag. Actually, it's in this time intervall, when scwm tries to decide which of the actions bound by you to alt-mouse-1 it should execute. Harvey> Is there any way around this? The default time interval (150 ms) is barely noticeable for me. If this is really a problem, we could make this information available "on demand", i.e. action-functions that didn't care if the trigger event was a click, double-click, or drag, wouldn't produce any delay. But things like `move-or-raise' would still be delayed. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jun 29 06:02:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA14649 for scwm-discuss-outgoing; Mon, 29 Jun 1998 06:02:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA14646 for ; Mon, 29 Jun 1998 06:02:43 -0400 Received: from [192.116.142.129] by MIT.EDU with SMTP id AA09905; Mon, 29 Jun 98 06:02:38 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA23841; Mon, 29 Jun 1998 13:02:15 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Long click times. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 13:02:15 +0300 In-Reply-To: Robert Bihlmeyer's message of "28 Jun 1998 20:53:32 +0200" Message-Id: Lines: 68 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Harvey> Another thing which seems slow with scwm is processing mouse > Harvey> clicks. I have the usual sort of maximize title bar button. > Harvey> It seems to take a while after clicking on it before the > Harvey> window changes. The same goes for my alt-mouse-1 > Harvey> (alt-mouse-3) which is bound to move-or-lower > Harvey> (raise-or-lower). > > Harvey> Is this because scwm is delaying processing of mouse clicks > Harvey> to make sure they're not double clicks? > > Yes, and it could also be a drag. Actually, it's in this time > intervall, when scwm tries to decide which of the actions bound by you > to alt-mouse-1 it should execute. > > Harvey> Is there any way around this? > > The default time interval (150 ms) is barely noticeable for me. If > this is really a problem, we could make this information available "on > demand", i.e. action-functions that didn't care if the trigger event > was a click, double-click, or drag, wouldn't produce any delay. But > things like `move-or-raise' would still be delayed. In fvwm, I have the following on alt-mouse-3: Mouse 3 W M Function "Move-or-Raise" Move-or-Raise is defined as: Function "Move-or-Raise" Move "Motion" Raise "Click" EndFunction Then fvwm behaves as follows: mb3-press (& hold) - The cursor changes to a circle. After a pause, it changes to a cross arrow & I can move the window around. mb3-press-release - The window raises immediately - no delay. mb3-press & move - The window starts moving immediately. If I change Move-or-Raise to: Function "Move-or-Raise" Move "Motion" Raise "Click" Iconify "DoubleClick" EndFunction then mb3-press-release doesn't raise the window immediately. There's a delay before it happens. It seems like two things are going on. In the second case it looks like if there's no doubleclick binding, then there's no waiting for a 2nd click. For the first case, it looks like both press+delay and press+move are bound to Motion & release is bound to Raise & the first one to happen gets its action executed. How hard would it be to get similar behavior in scwm? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 07:31:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA15332 for scwm-discuss-outgoing; Mon, 29 Jun 1998 07:31:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA15326; Mon, 29 Jun 1998 07:31:24 -0400 Message-Id: <199806291131.HAA15326@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Configure & compilation failures. In-reply-to: Your message of "27 Jun 1998 19:21:39 +0300." Date: Mon, 29 Jun 1998 07:31:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > "Harvey J. Stein" writes: > > > So, I tried out scwm-19980627.tar.gz (which I thought would fix the > > problem). This one doesn't configure cleanly: > > > > checking for scm_handle_by_message_noexit in -lguile... ./configure: > > -ldl: command not found > > no > > configure: error: Can not find Guile 1.2 or later on the system > > Deleting two double quotes from scwm-19980627/configure allowed it to > compile & build. Here's a patch: > Hi, thanks for reporting this problem. I fixed it before I saw your message because I tried actually building with guile 1.2 :-), so hopefully it works now. Just for reference, though, configure is an automatically generated file (created by `autoconf' from configure.in), although patching configure may be useful to get things to work, a general solution requires patching configure.in, so that the right code is generated when that gets changed. As the standard GNU `INSTALL' file says, "You are in twisty a maze of automatically generated files, all different." :-) - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 07:34:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA15358 for scwm-discuss-outgoing; Mon, 29 Jun 1998 07:34:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA15354; Mon, 29 Jun 1998 07:34:09 -0400 Message-Id: <199806291134.HAA15354@huis-clos.mit.edu> To: mike@olan.com cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "27 Jun 1998 22:58:40 +0300." <85iulmzken.fsf@alucard.one.way> Date: Mon, 29 Jun 1998 07:34:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mike@olan.com writes: > > Well, I just checked the Debian package, and here are my findings: > > 1) It handles the menus all right. > > 2) Debian menus are not ment to be parsed by WM at run-time - instead, > each WM package provides a way to generate menus for it. Once. The > WM is then registered with the debian-menu thingie, so that when any > package with a menu entry is installed on the system, the menus for > all WM's are updated. Once. The system.scwmrc that is installed by > the SCWM package just reads in the static file with the pre-made menus. > > 3) Hopefully the previous paragraph is human-parseable :) > > 4) The bottom line: dealing with Debian menus is an install-time > issue. Interacting with the Debian menu system (registering a menu > generator, deregistering the menu generator, etc.) appears to be > complex enough to not bother with it at all. In general, Debian menus > probably shouldn't be dealt with in upstream packages. After all, if > root wants to play with SCWM and have it integrated with the system, > it's straightforward to grab the Debian diff and build Debian package. > Well, if that's the deal I am happy with the menu parsing being done by the menu system. What I'd like, though, is for any user to be able to easily place the system default menu in any menu he or she likes, in any personal .scwmrc, not just the system.scwmrc, like you can do with the Red Hat wmconfig stuff. Is this feasible with the Debian menu system? Does it work with the current scwm package? - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 07:40:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA15420 for scwm-discuss-outgoing; Mon, 29 Jun 1998 07:40:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA15413 for ; Mon, 29 Jun 1998 07:39:48 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16443; Mon, 29 Jun 98 07:39:27 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id OAA24564; Mon, 29 Jun 1998 14:39:17 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Configure & compilation failures. References: <199806291131.HAA15326@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 14:39:17 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 07:31:24 EDT" Message-Id: Lines: 22 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Just for reference, though, configure is an automatically generated > file (created by `autoconf' from configure.in), although patching > configure may be useful to get things to work, a general solution > requires patching configure.in, so that the right code is generated > when that gets changed. As the standard GNU `INSTALL' file says, "You > are in twisty a maze of automatically generated files, all different." > :-) I know... I just backtraced it down to what was wrong with the configure script & what it probably *should* look like. I never screwed with autoconf so I didn't continue back to the source. I figured it'd be easy for someone familiar with autoconf to take that step. I didn't mean for the patch to be the final word, just for it to show exactly what needs to happen. A patch is worth a million descriptions. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 08:06:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15746 for scwm-discuss-outgoing; Mon, 29 Jun 1998 08:06:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA15742 for ; Mon, 29 Jun 1998 08:06:49 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA27384; Mon, 29 Jun 98 08:06:36 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15734; Mon, 29 Jun 1998 08:06:28 -0400 Message-Id: <199806291206.IAA15734@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) To: scwm-discuss@mit.edu Subject: Re: Startup time seems long. Why? In-Reply-To: Your message of "28 Jun 1998 18:04:11 +0300." Date: Mon, 29 Jun 1998 08:06:28 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Startup time (& time to do restarts) seems to be long for scwm. Does > anyone know why? Is it predominantly guile startup time? Yes, especially the time to load boot-9.scm. However, parsing the scwmrc probably takes a not entirely trivial amount of time as well. Part of that is due to some slowness in the module system. One thing you could do that might speed loading of the scwmrc in particular is add (debug-disable 'debug) at the top of the scwmrc and (debug-enable 'debug) at the end; this should turn off debugging information for the duration of the scwmrc loading. However, only do this if you are sure your scwmrc works or you will get relatively useless error messages. > I'm using guile 1.2. Is it any better with the guile snapshots? Somewhat. Since 1.2, Jim Blandy has incorporated my patch to put some of the stuff in boot-9.scm that doesn't really need to be there into separate files, so it loads faster. However, the pause is still noticeable when starting up a fresh Guile interpreter, especially on a slow machine. There are several packages available in the Guile contrib archive that could help, if this issue is important to you. In particular, the guile-hobbit compiler speeds up load time significantly when used to compile boot-9.scm, and it may be possible to adopt the freezer or the guile-unexec stuff to work with scwm. > Is there any possibility of a restart which just goes back to the > initial state & re-reads the appropriate files (as opposed to what > it seems to do, namely killing & restarting itself)? It's somewhat complicated; I don't think Guile has any functions to restore the interpreter state, or spawn a fresh interpreter other than the first. With guile multiple-interpreter support, it could (and probably would) be done. OTOH one of the purposes of restart (IMO) is to clear out _any_ potential cruft in a losing copy of the WM, and exec-ing a new copy is really the only way to be sure. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 08:16:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15828 for scwm-discuss-outgoing; Mon, 29 Jun 1998 08:16:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15808; Mon, 29 Jun 1998 08:16:03 -0400 Message-Id: <199806291216.IAA15808@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: Long click times. In-reply-to: Your message of "29 Jun 1998 13:02:15 +0300." Date: Mon, 29 Jun 1998 08:16:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Robert Bihlmeyer writes: > > > Harvey> Another thing which seems slow with scwm is processing mouse > > Harvey> clicks. I have the usual sort of maximize title bar button. > > Harvey> It seems to take a while after clicking on it before the > > Harvey> window changes. The same goes for my alt-mouse-1 > > Harvey> (alt-mouse-3) which is bound to move-or-lower > > Harvey> (raise-or-lower). > > > > Harvey> Is this because scwm is delaying processing of mouse clicks > > Harvey> to make sure they're not double clicks? > > This is definitely a problem. It can also be somewhat annoying for menus, which take a barely perceptible delay to pop up even thought the could do so with just a mouse-down event, in theory. > > Yes, and it could also be a drag. Actually, it's in this time > > intervall, when scwm tries to decide which of the actions bound by you > > to alt-mouse-1 it should execute. > > > > Harvey> Is there any way around this? > > > > The default time interval (150 ms) is barely noticeable for me. If > > this is really a problem, we could make this information available "on > > demand", i.e. action-functions that didn't care if the trigger event > > was a click, double-click, or drag, wouldn't produce any delay. But > > things like `move-or-raise' would still be delayed. Greg and I had some discussions a while back about changing the event model. We were thinking in terms of having separate bindings in event maps for each different type of mouse event (mouse-down, mouse-up, click, double-click, etc). This would probably lead to less delay, and would IMO be more intuitive. This is up there on the list of Really Big Rewrites(tm) that have been on the table for a while and might actually get done this summer (the other big things being the window structure rewrite and the window adding and decorating code rewrite). [snip examples with fvwm] > > It seems like two things are going on. In the second case it looks > like if there's no doubleclick binding, then there's no waiting for a > 2nd click. > > For the first case, it looks like both press+delay and press+move are > bound to Motion & release is bound to Raise & the first one to happen > gets its action executed. > > How hard would it be to get similar behavior in scwm? > Right now, scwm does not know which types of events an action procedure cares about; fvwm does because If bindings for different actions are set separately as described above, that would not be the case, however, since the event map would know wether it had bindings for double click, motion, etc. Of course, it would still be possible to provide a backwards-compatability facility of some kind. Perhaps if you don't specify a particular mouse action in the binding specifier, it would give you a generic binding of the sort done now, in case anyone actually finds that intuitive. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 08:31:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15925 for scwm-discuss-outgoing; Mon, 29 Jun 1998 08:31:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA15921 for ; Mon, 29 Jun 1998 08:31:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21884; Mon, 29 Jun 98 08:30:57 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA24888; Mon, 29 Jun 1998 15:30:45 +0300 To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Long click times. References: <199806291216.IAA15808@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 15:30:45 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 08:16:03 EDT" Message-Id: Lines: 27 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > It seems like two things are going on. In the second case it looks > > like if there's no doubleclick binding, then there's no waiting for a > > 2nd click. > > > > For the first case, it looks like both press+delay and press+move are > > bound to Motion & release is bound to Raise & the first one to happen > > gets its action executed. > > > > How hard would it be to get similar behavior in scwm? > > Right now, scwm does not know which types of events an action > procedure cares about; fvwm does because ^^^^^^^^^^^^^ > > If bindings for different actions are set separately as described > above, that would not be the case, however, since the event map would > know wether it had bindings for double click, motion, etc. Because why? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 08:47:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA16122 for scwm-discuss-outgoing; Mon, 29 Jun 1998 08:47:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA16118 for ; Mon, 29 Jun 1998 08:47:19 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21308; Mon, 29 Jun 98 08:25:28 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA24859; Mon, 29 Jun 1998 15:25:14 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Startup time seems long. Why? References: <199806291206.IAA15734@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 15:25:13 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 08:06:28 EDT" Message-Id: Lines: 31 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > Is there any possibility of a restart which just goes back to the > > initial state & re-reads the appropriate files (as opposed to what > > it seems to do, namely killing & restarting itself)? > > It's somewhat complicated; I don't think Guile has any functions to > restore the interpreter state, or spawn a fresh interpreter other than > the first. With guile multiple-interpreter support, it could (and > probably would) be done. OTOH one of the purposes of restart (IMO) is > to clear out _any_ potential cruft in a losing copy of the WM, and > exec-ing a new copy is really the only way to be sure. In my experience, I mostly restart to reload the config file. I guess that unless I load some screwed up macros, (or other obvious things that would screw up the interpreter) then doing (load ".scwmrc") might be close enough to what I'm thinking of, in which case I guess the functionality exists. Would this be a problem with existing decorations (if I change them in the .scwmrc)? I'll experiment with it when I get a chance... In any case, I wasn't suggesting that restart be changed. One obviously needs a function to start again from scratch. I was just wondering about ways to basically re-read the .scwmrc file which don't involve restarting the window manager. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 09:11:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16473 for scwm-discuss-outgoing; Mon, 29 Jun 1998 09:11:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16463; Mon, 29 Jun 1998 09:11:00 -0400 Message-Id: <199806291311.JAA16463@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV In-reply-to: Your message of "28 Jun 1998 16:06:45 +0200." Date: Mon, 29 Jun 1998 09:11:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Fri, 26 Jun 1998 00:41:32 EDT > >>>>> Maciej Stachowiak said: > > Maciej> [...] scwm aggresively tries to catch otherwise uncaught > Maciej> exceptions, so it might hang in this case instead of dieing. > > What about also catching SIGSEGV, and trying to exit cleanly in this > case (like on SIGINT and friends)? > That's probably a good idea. In general, though, is it safe to do moderately complicated things in a SEGV handler? Is there anything special to consider, or would hooking up the SIGINT/SIGTERM handler to SIGSEGV be sufficient? > It's very humilating having to resort to cut-and-pasting commandlines, > because your wm has crashed on you while it had the keyboard grabbed, > or somesuch. > I know what you mean. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 09:22:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16655 for scwm-discuss-outgoing; Mon, 29 Jun 1998 09:22:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16647; Mon, 29 Jun 1998 09:22:03 -0400 Message-Id: <199806291322.JAA16647@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Long click times. In-reply-to: Your message of "29 Jun 1998 15:30:45 +0300." Date: Mon, 29 Jun 1998 09:22:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > hjstein@bfr.co.il writes: > > > It seems like two things are going on. In the second case it looks > > > like if there's no doubleclick binding, then there's no waiting for a > > > 2nd click. > > > > > > For the first case, it looks like both press+delay and press+move are > > > bound to Motion & release is bound to Raise & the first one to happen > > > gets its action executed. > > > > > > How hard would it be to get similar behavior in scwm? > > > > Right now, scwm does not know which types of events an action > > procedure cares about; fvwm does because > ^^^^^^^^^^^^^ > > > > If bindings for different actions are set separately as described > > above, that would not be the case, however, since the event map would > > know wether it had bindings for double click, motion, etc. > > Because why? > Whoops, some bad editing there. Fvwm knows this because it represents the functions as just the actual text of the function definition, and it has no complex control flow, just specifiers for each statement indicating what type of event they should execute on. Fvwm can iterate over all of thse and know what events the function might care about, whereas scwm would have to do essentially dataflow analyisis on the code to know that for the general case. Perhaps it would be useful to allow the user to provide a hint of some kind when defining a mouse binding which would indicate what sorts of bindings the action function might care about. Perhaps this could even be set as an object property on the procedure and thus be transparent to the user for system-defined things. But I do not think this is a very good approach. Binding different event types separately would probably be better. - Maciej From owner-scwm-discuss@mit.edu Mon Jun 29 09:35:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16786 for scwm-discuss-outgoing; Mon, 29 Jun 1998 09:35:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA16782 for ; Mon, 29 Jun 1998 09:35:24 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05281; Mon, 29 Jun 98 09:35:20 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA25307; Mon, 29 Jun 1998 16:35:15 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Startup time seems long. Why? References: <199806291328.JAA16723@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 16:35:15 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 09:28:58 EDT" Message-Id: Lines: 16 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Maybe it would be useful to provide clear or reset commands for many > of the settable parameters which would reset them to the startup > default. By running some of these and reloading .scwmrc, you could get > a virtual restart. That's basically what I was thinking of. OTOH, it wouldn't be needed if the startup/restart time wasn't so long. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 09:53:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA17021 for scwm-discuss-outgoing; Mon, 29 Jun 1998 09:53:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA17018 for ; Mon, 29 Jun 1998 09:53:20 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA10100; Mon, 29 Jun 98 09:53:15 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA25384; Mon, 29 Jun 1998 16:53:11 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199806291322.JAA16647@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Jun 1998 16:53:10 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 09:22:03 EDT" Message-Id: Lines: 32 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Perhaps it would be useful to allow the user to provide a hint of some > kind when defining a mouse binding which would indicate what sorts of > bindings the action function might care about. Perhaps this could even > be set as an object property on the procedure and thus be transparent > to the user for system-defined things. But I do not think this is a > very good approach. > > Binding different event types separately would probably be better. I'd definitely vote for finer grained callbacks. Not only does the current implementation run into these sorts of event detection problems, it seems kind of silly that the WM would wait around to try to decide what sort of event occurred but then the user side code would have to again branch on the event type. How hard would it be to add (eg) mb1-press & mb1-release & fire off attendant actions as soon as such events occur? Binding menu creations to mb1-press & simple button actions to mb1-release would at least fix a large class of the delays. And, if user code could bind to press & release, then the user code could implement its own double click processing to handle a larger class of delays. Finally, if mb1-move could also be added, then everything could be handled in user space. Would this be any easer than redoing things to work off of event maps? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 12:15:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA18031 for scwm-discuss-outgoing; Mon, 29 Jun 1998 12:15:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA18028 for ; Mon, 29 Jun 1998 12:15:34 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19872; Mon, 29 Jun 98 12:15:30 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA18017; Mon, 29 Jun 1998 09:15:35 -0700 (PDT) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806291311.JAA16463@huis-clos.mit.edu> From: Greg Badros Date: 29 Jun 1998 09:15:34 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 09:11:00 EDT" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > That's probably a good idea. In general, though, is it safe to do > moderately complicated things in a SEGV handler? Is there anything > special to consider, or would hooking up the SIGINT/SIGTERM handler to > SIGSEGV be sufficient? I don't see any reason that SIGSEGV needs to be different from the others (I just looked quickly through Stevens' book). The ideal behaviour is to just reset the state of the X display, and then still core-dump usefully. I don't see how that's possible, so maybe we need a cmd line option to turn off SEGV handling so we get the useful core-dump (this will negatively impact our ability to analyze sporadic problems that others have as we won't get a dump file unless they started with the option to core dump normally). More informed opinions on these matters are sought! Greg From owner-scwm-discuss@mit.edu Mon Jun 29 13:23:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA18405 for scwm-discuss-outgoing; Mon, 29 Jun 1998 13:23:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA18402 for ; Mon, 29 Jun 1998 13:23:41 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA10717; Mon, 29 Jun 98 13:23:33 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id NAA20931; Mon, 29 Jun 1998 13:23:32 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d23.phe-pa.concentric.net [209.31.155.131]) by marconi.concentric.net (8.8.8) id NAA23437; Mon, 29 Jun 1998 13:23:27 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA00843; Mon, 29 Jun 1998 13:23:17 -0400 To: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of 28 Jun 1998 16:06:45 +0200 Date: 29 Jun 1998 13:23:15 -0400 Message-Id: Lines: 17 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 28 Jun 1998 16:06:45 +0200 >>>> Honorable Robert Bihlmeyer writes >>>> on the subject of "catching SIGSEGV": >> >> It's very humilating having to resort to cut-and-pasting commandlines, >> because your wm has crashed on you while it had the keyboard grabbed, >> or somesuch. hear!!! I have to C-A-F2 and start a WM from a console. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. In every non-trivial program there is at least one bug. From owner-scwm-discuss@mit.edu Mon Jun 29 14:19:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA19069 for scwm-discuss-outgoing; Mon, 29 Jun 1998 14:19:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA19065 for ; Mon, 29 Jun 1998 14:19:10 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22938; Mon, 29 Jun 98 14:19:04 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA18377; Mon, 29 Jun 1998 11:19:07 -0700 (PDT) To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> From: Greg Badros Date: 29 Jun 1998 11:19:06 -0700 In-Reply-To: Sam Steingold's message of "29 Jun 1998 13:23:15 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 28 Jun 1998 16:06:45 +0200 > >>>> Honorable Robert Bihlmeyer writes > >>>> on the subject of "catching SIGSEGV": > >> > >> It's very humilating having to resort to cut-and-pasting commandlines, > >> because your wm has crashed on you while it had the keyboard grabbed, > >> or somesuch. > > hear!!! > I have to C-A-F2 and start a WM from a console. That gives me an idea-- maybe a simple X program that restores sanity to the focus behaviour, etc., is all we really need. Then scwm can be started like so: scwm || reset-X-display so if scwm dies a horrible death, X is reset more reasonably, but we still get the core dump file. Greg From owner-scwm-discuss@mit.edu Mon Jun 29 15:51:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA20112 for scwm-discuss-outgoing; Mon, 29 Jun 1998 15:51:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA20109 for ; Mon, 29 Jun 1998 15:51:37 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA18854; Mon, 29 Jun 98 15:51:31 EDT Received: from mcfeely.concentric.net (mcfeely.concentric.net [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id PAA07570; Mon, 29 Jun 1998 15:51:27 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d23.phe-pa.concentric.net [209.31.155.131]) by mcfeely.concentric.net (8.8.8) id PAA01749; Mon, 29 Jun 1998 15:51:25 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA01038; Mon, 29 Jun 1998 13:58:07 -0400 To: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806291311.JAA16463@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of 29 Jun 1998 09:15:34 -0700 Date: 29 Jun 1998 13:58:05 -0400 Message-Id: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 29 Jun 1998 09:15:34 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: catching SIGSEGV": >> Maciej Stachowiak writes: >> >> > That's probably a good idea. In general, though, is it safe to do >> > moderately complicated things in a SEGV handler? Is there anything >> > special to consider, or would hooking up the SIGINT/SIGTERM handler to >> > SIGSEGV be sufficient? >> >> I don't see any reason that SIGSEGV needs to be different from the >> others (I just looked quickly through Stevens' book). The ideal >> behaviour is to just reset the state of the X display, and then still >> core-dump usefully. I don't see how that's possible, so maybe we need a >> cmd line option to turn off SEGV handling so we get the useful core-dump >> (this will negatively impact our ability to analyze sporadic problems >> that others have as we won't get a dump file unless they started with >> the option to core dump normally). >> >> More informed opinions on these matters are sought! Emacs (and other programs) can dump core on demand. What we can do is the following: catch the signal, fix the state (keyboard focus etc), remove the signal handler and then generate the signal (sigsegv: *(0)=10; sigfpe: 1/0 etc). -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Life is a sexually transmitted disease with 100% mortality. From owner-scwm-discuss@mit.edu Mon Jun 29 17:39:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA20624 for scwm-discuss-outgoing; Mon, 29 Jun 1998 17:39:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA20621 for ; Mon, 29 Jun 1998 17:39:05 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA12819; Mon, 29 Jun 98 17:38:49 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA27573; Tue, 30 Jun 1998 00:38:48 +0300 To: scwm-discuss@mit.edu Subject: Fvwm interaction bug - missing window names. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jun 1998 00:38:48 +0300 In-Reply-To: hjstein@bfr.co.il's message of "29 Jun 1998 16:53:10 +0300" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm using the fvwm2 pager. It doesn't display the names of windows which already exist when it's invoked. Windows that are brought up when the pager is already running have their names displayed. But: a) The windows that are brought up before the window manager comes up don't have names displayed, b) When I switch from fvwm to scwm (restart scwm from fvwm), none of the existing windows have names displayed, and c) restarting scwm clears all the displayed names. BTW, is it expected that the fvwm pager crashes scwm but the fvwm2 pager works? This seems to be the case on my system. Or is it just a matter of using the fvwm-compat module? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jun 29 17:47:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA20700 for scwm-discuss-outgoing; Mon, 29 Jun 1998 17:47:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA20696 for ; Mon, 29 Jun 1998 17:47:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14257; Mon, 29 Jun 98 17:47:15 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA27643; Tue, 30 Jun 1998 00:47:13 +0300 To: scwm-discuss@mit.edu Subject: Re: Fvwm interaction bug - missing window names. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jun 1998 00:47:13 +0300 In-Reply-To: hjstein@bfr.co.il's message of "30 Jun 1998 00:38:48 +0300" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > BTW, is it expected that the fvwm pager crashes scwm but the fvwm2 > pager works? This seems to be the case on my system. Or is it just a > matter of using the fvwm-compat module? More details: fvwm-compat + fvwm pager = crash no fvwm-compat + fvwm pager = crash fvwm-compat + fvwm95-2 pager = ok no fvwm-compat + fvwm95-2 pager = ok -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jun 30 02:49:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA23127 for scwm-discuss-outgoing; Tue, 30 Jun 1998 02:49:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA23118 for ; Tue, 30 Jun 1998 02:49:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id IAA15771 for scwm-discuss@huis-clos.mit.edu; Tue, 30 Jun 1998 08:49:04 +0200 (CEST) Received: (qmail 1005 invoked by uid 115); 29 Jun 1998 20:55:48 -0000 To: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199806291322.JAA16647@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Jun 1998 22:55:46 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 29 Jun 1998 09:22:03 EDT" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 29 Jun 1998 09:22:03 EDT >>>>> Maciej Stachowiak said: Maciej> Binding different event types separately would probably be Maciej> better. Definitely. The current approach, where you have to define a function for such things, is not very intuitive. That's probably just fvwm slack. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Jun 30 02:49:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA23129 for scwm-discuss-outgoing; Tue, 30 Jun 1998 02:49:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA23121 for ; Tue, 30 Jun 1998 02:49:22 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id IAA15791 for scwm-discuss@huis-clos.mit.edu; Tue, 30 Jun 1998 08:49:06 +0200 (CEST) Received: (qmail 1017 invoked by uid 115); 29 Jun 1998 21:00:31 -0000 To: scwm-discuss@mit.edu Subject: Re: Startup time seems long. Why? References: <199806291206.IAA15734@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Jun 1998 23:00:31 +0200 In-Reply-To: hjstein@bfr.co.il's message of "29 Jun 1998 15:25:13 +0300" Message-ID: Lines: 19 X-Mailer: Gnus v5.6.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 29 Jun 1998 15:25:13 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> In any case, I wasn't suggesting that restart be changed. One Harvey> obviously needs a function to start again from scratch. I was Harvey> just wondering about ways to basically re-read the .scwmrc Harvey> file which don't involve restarting the window manager. What about scwmexec '(load "path/to/scwmrc")' ? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Jun 30 02:49:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA23128 for scwm-discuss-outgoing; Tue, 30 Jun 1998 02:49:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA23116 for ; Tue, 30 Jun 1998 02:49:18 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id IAA15758 for scwm-discuss@huis-clos.mit.edu; Tue, 30 Jun 1998 08:49:01 +0200 (CEST) Received: (qmail 965 invoked by uid 115); 29 Jun 1998 20:47:05 -0000 To: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Mon_Jun_29_22:47:04_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 29 Jun 1998 22:47:04 +0200 In-Reply-To: Greg Badros's message of "29 Jun 1998 11:19:06 -0700" Message-ID: Lines: 105 X-Mailer: Gnus v5.6.13/XEmacs 20.4 - "Emerald" X-Now-Playing: 42_The_Battle_of_Five_Armies Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Mon_Jun_29_22:47:04_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On 29 Jun 1998 11:19:06 -0700 >>>>> Greg Badros said: Greg> That gives me an idea-- maybe a simple X program that restores Greg> sanity to the focus behaviour, etc., is all we really need. Greg> Then scwm can be started like so: Greg> scwm || reset-X-display Greg> so if scwm dies a horrible death, X is reset more reasonably, Greg> but we still get the core dump file. Another possibility would be this patch. When SIGSEGV was catched, after restoring sanity, it calls abort(), which causes a core dump. --Multipart_Mon_Jun_29_22:47:04_1998-1 Content-Type: text/plain; charset=US-ASCII Index: scwm/scwm/scwm.c diff -c scwm/scwm/scwm.c:1.9 scwm/scwm/scwm.c:1.10 *** scwm/scwm/scwm.c:1.9 Mon Jun 29 22:30:48 1998 --- scwm/scwm/scwm.c Mon Jun 29 22:42:33 1998 *************** *** 1305,1313 **** *********************************************************************** */ void ! SigDone(int nonsense) { ! Done(0, NULL); SIGNAL_RETURN; } --- 1305,1316 ---- *********************************************************************** */ void ! SigDone(int signr) { ! if (signr == SIGSEGV) ! Done(-1, NULL); ! else ! Done(0, NULL); SIGNAL_RETURN; } Index: scwm/scwm/shutdown.c diff -c scwm/scwm/shutdown.c:1.1.1.2 scwm/scwm/shutdown.c:1.2 *** scwm/scwm/shutdown.c:1.1.1.2 Wed Jun 24 22:21:17 1998 --- scwm/scwm/shutdown.c Mon Jun 29 22:41:54 1998 *************** *** 62,68 **** /* Pretty sure this should be done... */ XDeleteProperty(dpy, Scr.Root, _XA_MOTIF_WM); ! if (restart) { SaveDesktopState(); /* I wonder why ... */ /* Really make sure that the connection is closed and cleared! */ --- 62,68 ---- /* Pretty sure this should be done... */ XDeleteProperty(dpy, Scr.Root, _XA_MOTIF_WM); ! if (restart > 0) { SaveDesktopState(); /* I wonder why ... */ /* Really make sure that the connection is closed and cleared! */ *************** *** 75,81 **** run_restart_command(command); } else { XCloseDisplay(dpy); ! exit(0); } } --- 75,84 ---- run_restart_command(command); } else { XCloseDisplay(dpy); ! if (restart < 0) ! abort(); ! else ! exit(0); } } --Multipart_Mon_Jun_29_22:47:04_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Mon_Jun_29_22:47:04_1998-1-- From owner-scwm-discuss@mit.edu Tue Jun 30 03:44:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA23820 for scwm-discuss-outgoing; Tue, 30 Jun 1998 03:44:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA23817 for ; Tue, 30 Jun 1998 03:44:14 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28402; Tue, 30 Jun 98 03:44:03 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA30354; Tue, 30 Jun 1998 10:43:51 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Startup time seems long. Why? References: <199806291206.IAA15734@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jun 1998 10:43:51 +0300 In-Reply-To: Robert Bihlmeyer's message of "29 Jun 1998 23:00:31 +0200" Message-Id: Lines: 55 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> In any case, I wasn't suggesting that restart be changed. One > Harvey> obviously needs a function to start again from scratch. I was > Harvey> just wondering about ways to basically re-read the .scwmrc > Harvey> file which don't involve restarting the window manager. > > What about > scwmexec '(load "path/to/scwmrc")' Yes. Except for problems pointed out by Maciej Stachowiak : > hjstein@bfr.co.il writes: > In my experience, I mostly restart to reload the config file. I guess > that unless I load some screwed up macros, (or other obvious things > that would screw up the interpreter) then doing (load ".scwmrc") might > be close enough to what I'm thinking of, in which case I guess the > functionality exists. Would this be a problem with existing > decorations (if I change them in the .scwmrc)? I'll experiment with > it when I get a chance... > Probably not, most decorations can be changed on the fly. The things that could potentially be problems will be the following: * Key and mouse bindings will not be cleared, so if you remove one and do not redefine the same key or mouse button as something else, it will stay. * If you add new style definitions, even if they are exact copies of the old ones, additional memory will be used However, this is something of a bug in the current implementation of window styles; I have a plan for a better one that won't have this problem. * Style definitions will not be cleared, so if you remove an option it won't be gone when you reload .scmwrc. * More generally, various settings will not be cleared or reset to defaults. Maybe it would be useful to provide clear or reset commands for many of the settable parameters which would reset them to the startup default. By running some of these and reloading .scwmrc, you could get a virtual restart. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jun 30 09:36:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA25550 for scwm-discuss-outgoing; Tue, 30 Jun 1998 09:36:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA25547 for ; Tue, 30 Jun 1998 09:36:18 -0400 Received: from king.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA20535; Tue, 30 Jun 98 09:36:00 EDT Received: (from marko@localhost) by king.ki.informatik.uni-frankfurt.de (8.7.1/8.7.1) id PAA10330; Tue, 30 Jun 1998 15:35:48 +0200 (MESZ) Date: Tue, 30 Jun 1998 15:35:48 +0200 (MESZ) Message-Id: <199806301335.PAA10330@king.ki.informatik.uni-frankfurt.de> From: Marko Schuetz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: scwm-0.7a not loading packages?! X-Mailer: VM 6.34 under Emacs 20.2.1 Reply-To: marko@cs.uni-frankfurt.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk I compiled scwm-0.7a using guile-1.2 and installed it on FreeBSD. when I try to use some of the sample.scwmrc there are a lot of error messages printed to the console that started X about unbound variables such as 'menu', 'toggle-raise', 'show-window-list-menu'. 'gmake install' installed the *.scm files in /usr/local/share/scwm-modules which should be the right place, scwm just seems not to find them on startup. Any ideas how to solve this? Marko From owner-scwm-discuss@mit.edu Tue Jun 30 12:53:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA26339 for scwm-discuss-outgoing; Tue, 30 Jun 1998 12:53:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA26336 for ; Tue, 30 Jun 1998 12:53:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27125; Tue, 30 Jun 98 12:53:18 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA27516; Tue, 30 Jun 1998 09:52:40 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806260441.AAA26855@huis-clos.mit.edu> From: Greg Badros Date: 30 Jun 1998 09:52:39 -0700 In-Reply-To: Robert Bihlmeyer's message of "29 Jun 1998 22:47:04 +0200" Message-Id: Lines: 53 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> On 29 Jun 1998 11:19:06 -0700 > >>>>> Greg Badros said: > > Greg> That gives me an idea-- maybe a simple X program that restores > Greg> sanity to the focus behaviour, etc., is all we really need. > Greg> Then scwm can be started like so: > > Greg> scwm || reset-X-display > > Greg> so if scwm dies a horrible death, X is reset more reasonably, > Greg> but we still get the core dump file. > > Another possibility would be this patch. When SIGSEGV was catched, > after restoring sanity, it calls abort(), which causes a core dump. > > *********************************************************************** > */ > void > ! SigDone(int signr) > { > ! if (signr == SIGSEGV) > ! Done(-1, NULL); > ! else > ! Done(0, NULL); > SIGNAL_RETURN; > } > This is the part I'm really skeptical about. I don't think you can (portably, safely) call Done from a signal handler. Library code doesn't have to be (and in general isn't) re-entrant, so doing almost anythin in a signal handler is implementation-defined. If another core dump is forced while the signal call is still on the stack, then the core dump is useful because it will contain the backtrace from the offending code. However, I don't think you can clean up from the signal handler like this. Instead, we need to set a volatile global variable that then gets checked in the main loop and does the right thing. But by the point the main loop comes around again, the signal handler has returned, and the offending code is no longer on the stack. Perhaps this is a place where "in practice" makes all the difference, and the routines we care to call from our signal handler are not going to cause segvs (or have caused the segv) so we can call them anyway. Greg From owner-scwm-discuss@mit.edu Tue Jun 30 14:02:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26881 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:02:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26872; Tue, 30 Jun 1998 14:02:15 -0400 Message-Id: <199806301802.OAA26872@huis-clos.mit.edu> To: marko@cs.uni-frankfurt.de cc: scwm-discuss@mit.edu Subject: Re: scwm-0.7a not loading packages?! In-reply-to: Your message of "Tue, 30 Jun 1998 15:35:48 +0200." <199806301335.PAA10330@king.ki.informatik.uni-frankfurt.de> Date: Tue, 30 Jun 1998 14:02:15 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk marko@king.ki.informatik.uni-frankfurt.de writes: > I compiled scwm-0.7a using guile-1.2 and installed it on FreeBSD. when > I try to use some of the sample.scwmrc there are a lot of error > messages printed to the console that started X about unbound variables > such as 'menu', 'toggle-raise', 'show-window-list-menu'. 'gmake > install' installed the *.scm files in /usr/local/share/scwm-modules > which should be the right place, scwm just seems not to find them on > startup. > > Any ideas how to solve this? > Scwm should compile in the right path to the modules when you configure it, so I am not sure why this is happening. One thing you could try is setting the environment variable SCWM_LOAD_PATH to the location of the modules, scwm checks that as well when starting up. If that doesn't work, a more complete trace of the error messages would be useful, but sending it to the list would probably be a bit gratuitous, so just e-mail it to me personally. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 30 14:15:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27129 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:15:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA27126 for ; Tue, 30 Jun 1998 14:15:53 -0400 Received: by tis.bellhow.com; id OAA22019; Tue, 30 Jun 1998 14:15:33 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma021844; Tue, 30 Jun 98 14:14:42 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA19098 for ; Tue, 30 Jun 1998 14:14:41 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: scm_parse_path conflict with newer guile snapshot. Date: Tue, 30 Jun 1998 18:11:29 GMT Organization: Bell & Howell PSC Message-ID: <3598fde5.92302033@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA27127 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings, Thought I'd try out a newer a newer guile snapshot. We are talking 19980629 for guile and 19980626 for scwm. There is a conflict with scm_parse_path. The guile version is scm_parse_path(SCM path, SCM tail) while the scwm version is scm_parse_path(char *path, SCM tail). In guile-compat.h: I #define'd HAVE_SCM_PARSE_PATH and removed the prototype for scm_parse_path. In scwm.c, int the function UnBlackoutScreen: Instead of: path=scm_parse_path(getenv("SCWM_LOAD_PATH"), path); I'm using: path=scm_parse_path(gh_str02scm(getenv("SCWM_LOAD_PATH")), path); Everything seems to be running ok. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jun 30 14:17:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27163 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:17:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27156; Tue, 30 Jun 1998 14:17:27 -0400 Message-Id: <199806301817.OAA27156@huis-clos.mit.edu> To: swittams@cix.compulink.co.uk cc: scwm-discuss@mit.edu Subject: Re: Menus In-reply-to: Your message of "Tue, 30 Jun 1998 14:51:00 -0000." Date: Tue, 30 Jun 1998 14:17:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk swittams@cix.compulink.co.uk writes: > Everybody seems to be arguing about menus atm. > Has anybody ever thought that the defaults propagated > in most desktop systems make little sense? (Exit&Close under File,etc.) > > I think we should decide one of two courses: > 1) Stick as far as possible to the system everybody is used to. Ie > Preferences under File... > I hardly think "evverybody" is used to it. The standard on Windows 95 at least is "Options..." under the "View" menu. And Netscape, reportedly the second most used program in the world after Windows itself, has "Preferences..." under "Edit". Personally, I think all of these suck, but "Preferences..." under "Edit" sucks the least. I think the best thing would be a "Preferences..." entry in an "Options" menu, along with check menu items or radio menu items for common settings. However, this has the problem that for a fair number of apps, it might be the only entry in the Options menu, which would look a bit lame, IMO. > It really is not worth attempting to fool people into thinking they are > using Win/Mac menu options if *everything* isn't the same. > I don't think many people here have copying Win/Mac as the primary goal, and it is not possible in any case, since there are significant differences. > 2) Make an entirely new default menu structure, in which every menu > option has to be semantically viable. > Eg have an > *App(renamable) menu as the leftmost with quit, preferences etc... > * File with close, open, properties... > Menus that are not named the same thing in each app are a terrible idea once keyboard menu traversal is up and running. Also you get used to dragging the mouse to a certain position on the screen, and if the first menuu entry had a variable length This is why I think substituting a "Game" menu for a "File" menu is somewhat bad, but it is somewhat more logical, and if all games and only games do that, perhaps it is not so bad. > *Edit, for undo, redo, cut&paste etc ... > * successive Object menus (renamable) next, for commands on the currently se > lected > object/layer/word/CORBA exported thingy/whatever ... These should be right-button context menus. They should not make the standard menubar constantly mutate. > * {insert|new} to insert new objects/funny characters/etc ..... > *help right most ( but not right justified). > *only app and help mandatory > I reiterate > The thing I'm really trying to get at is that only operations relating to fi > les > should be in the file menu... > I agree. Well, I think printing operations can go in there too by common convention. > > eg in a word processor: > > App file edit page paragraph {word|object|etc} help > > I would prefer the 2nd choice, but if we are going for the first, which I re > alise is > much more likely due to the amount of work already done using this kind of m > odel, > then we must at least keep to copying MS/Apple consistently. > > If we have been copying them at all, it is only in ways that are either minor or unavoidable. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 30 14:52:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27546 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:52:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27537; Tue, 30 Jun 1998 14:51:46 -0400 Message-Id: <199806301851.OAA27537@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV In-reply-to: Your message of "30 Jun 1998 09:52:39 PDT." Date: Tue, 30 Jun 1998 14:51:36 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Robert Bihlmeyer writes: > > > >>>>> On 29 Jun 1998 11:19:06 -0700 > > >>>>> Greg Badros said: > > > > Greg> That gives me an idea-- maybe a simple X program that restores > > Greg> sanity to the focus behaviour, etc., is all we really need. > > Greg> Then scwm can be started like so: > > > > Greg> scwm || reset-X-display > > > > Greg> so if scwm dies a horrible death, X is reset more reasonably, > > Greg> but we still get the core dump file. > > > > Another possibility would be this patch. When SIGSEGV was catched, > > after restoring sanity, it calls abort(), which causes a core dump. > I'd reccomend instead forcing an actual segfault as Sam Steingold suggested (by, for example, intentionally dereferencing a NULL pointer). It would probably also be better to have Done actually return on the SEGV case and do the forced SEGV from within the signal handler (after it uninstalls itself) so we have as little extraneous junk on the stack as possible. > > > > > > *********************************************************************** > > */ > > void > > ! SigDone(int signr) > > { > > ! if (signr == SIGSEGV) > > ! Done(-1, NULL); > > ! else > > ! Done(0, NULL); > > SIGNAL_RETURN; > > } > > > > This is the part I'm really skeptical about. I don't think you can > (portably, safely) call Done from a signal handler. Library code > doesn't have to be (and in general isn't) re-entrant, so doing almost > anythin in a signal handler is implementation-defined. True, and I don't think Guile is re=entrant either. In particular, if the Guile heap has gotten corrupted, we will probably lose if we try to make any libguile calls. Perhaps we should have a more minimal cleanup routine for segfaults. > If another > core dump is forced while the signal call is still on the stack, then the > core dump is useful because it will contain the backtrace from the > offending code. > > However, I don't think you can clean up from the signal handler like > this. Instead, we need to set a volatile global variable that then gets > checked in the main loop and does the right thing. But by the point the > main loop comes around again, the signal handler has returned, and the > offending code is no longer on the stack. > > Perhaps this is a place where "in practice" makes all the difference, > and the routines we care to call from our signal handler are not going > to cause segvs (or have caused the segv) so we can call them anyway. > I'll have to check my A.P.U.E. on this, but why don't we just try if it works for now? We could add a test routine to cause a segfault or something. I wonder if there are any other programs that catch SEGV and do notable cleanup before intentionally dumping core. It would probably help to see how it's done. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 30 14:55:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27678 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:55:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27668; Tue, 30 Jun 1998 14:55:05 -0400 Message-Id: <199806301855.OAA27668@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: scm_parse_path conflict with newer guile snapshot. In-reply-to: Your message of "Tue, 30 Jun 1998 18:11:29 GMT." <3598fde5.92302033@mailhost> Date: Tue, 30 Jun 1998 14:54:58 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Greetings, > > Thought I'd try out a newer a newer guile snapshot. We are talking 19980629 > for guile and 19980626 for scwm. > > There is a conflict with scm_parse_path. The guile version is > scm_parse_path(SCM path, SCM tail) while the scwm version is > scm_parse_path(char *path, SCM tail). > This is fixed in 0.7a and in newer snapshots. If scwm detects that libguile has scm_internal_parse path, it will not prototype or use scm_parse_path. - Maciej From owner-scwm-discuss@mit.edu Tue Jun 30 14:58:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA27689 for scwm-discuss-outgoing; Tue, 30 Jun 1998 14:58:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA27686 for ; Tue, 30 Jun 1998 14:57:43 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05474; Tue, 30 Jun 98 14:57:22 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA28925; Tue, 30 Jun 1998 11:57:26 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV References: <199806301851.OAA27537@huis-clos.mit.edu> From: Greg Badros Date: 30 Jun 1998 11:57:26 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 30 Jun 1998 14:51:36 EDT" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I'll have to check my A.P.U.E. on this, but why don't we just try if > it works for now? We could add a test routine to cause a segfault or > something. I wonder if there are any other programs that catch SEGV > and do notable cleanup before intentionally dumping core. It would > probably help to see how it's done. I don't see what's wrong with a separate small binary that just does the cleanup in case scwm exits (aborts) with non-zero exit status. Yes, it's one more program to install, but that's no big deal. And it's safer to have something checking the exit status of the window manager anyway, just in case it crashes -- no one wants all the windows to close and work to be lost (I usually exec an xterm if my wm exits w/ non-zero exit status). Greg From owner-scwm-discuss@mit.edu Tue Jun 30 22:59:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30748 for scwm-discuss-outgoing; Tue, 30 Jun 1998 22:59:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA30743 for ; Tue, 30 Jun 1998 22:59:06 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA09186; Tue, 30 Jun 98 22:58:43 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id WAA21219; Tue, 30 Jun 1998 22:58:42 -0400 To: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199806291322.JAA16647@huis-clos.mit.edu> From: Jim Blandy Date: 30 Jun 1998 22:58:41 -0400 In-Reply-To: Robert Bihlmeyer's message of 29 Jun 1998 22:55:46 +0200 Message-Id: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I don't know if this is acceptable to folks, but you could simply always execute the single click commands immediately, and then also execute the double click commands, if a second click arrives in time. Double clicking isn't a completely reliable gesture; sometimes you intend a double click, but actually do two single clicks. Thus, one might make the rule that, if you have something bound to a double click and a single click, the single click command should always be benign. The usual bindings for text selection exemplify this: a single click moves the cursor, while a double click starts selecting words; the latter command obscures the effect of the frist. Following that rule, the technical issues here go away. From owner-scwm-discuss@mit.edu Tue Jun 30 23:10:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA30881 for scwm-discuss-outgoing; Tue, 30 Jun 1998 23:10:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA30877; Tue, 30 Jun 1998 23:10:01 -0400 Message-Id: <199807010310.XAA30877@huis-clos.mit.edu> To: Jim Blandy cc: scwm-discuss@mit.edu Subject: Re: Long click times. In-reply-to: Your message of "30 Jun 1998 22:58:41 EDT." Date: Tue, 30 Jun 1998 23:10:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > I don't know if this is acceptable to folks, but you could simply > always execute the single click commands immediately, and then also > execute the double click commands, if a second click arrives in time. > > Double clicking isn't a completely reliable gesture; sometimes you > intend a double click, but actually do two single clicks. Thus, one > might make the rule that, if you have something bound to a double > click and a single click, the single click command should always be > benign. The usual bindings for text selection exemplify this: a > single click moves the cursor, while a double click starts selecting > words; the latter command obscures the effect of the frist. > > Following that rule, the technical issues here go away. I know this is the usual solution with most GUI interfaces. This has a specific problem in the context of window managers, however. People very often will bind a single left mouse click on the title bar to raise, but want a double click to do something completely different which should not necessarily do a raise. Common options include lower (this can be dealt with, a raise before a lower is not that bad), maximize (sometimes useful to maximize a window below the current windows), window-shade and toggle-raise (which is probably a poor idea in the first place but would clearly break if the window got raised first). Making a single click on the title bar _not_ do raise is unfortunately not tenable, and limiting the double-click actions to only things that will work if a raise happens first seems unnecessarily limiting, at least to me. Do other people think differently? - Maciej From owner-scwm-discuss@mit.edu Wed Jul 1 00:13:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA31473 for scwm-discuss-outgoing; Wed, 1 Jul 1998 00:13:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA31470 for ; Wed, 1 Jul 1998 00:13:31 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA17428; Wed, 1 Jul 98 00:13:07 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id AAA21496; Wed, 1 Jul 1998 00:13:07 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199807010310.XAA30877@huis-clos.mit.edu> From: Jim Blandy Date: 01 Jul 1998 00:13:06 -0400 In-Reply-To: Maciej Stachowiak's message of Tue, 30 Jun 1998 23:10:01 EDT Message-Id: Lines: 17 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Making a single click on the title bar _not_ do raise is unfortunately > not tenable, and limiting the double-click actions to only things that > will work if a raise happens first seems unnecessarily limiting, at > least to me. > > Do other people think differently? I suppose it's nice to continue to support people's existing configurations. :) But when you consider the utter chaos and confusion that reigns in the world of X window manager user interfaces, you should not be surprised that catering to existing practice leads you to unpleasant conclusions. I guess my opinion is clear, so I'll shut up. :) From owner-scwm-discuss@mit.edu Wed Jul 1 09:39:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA01544 for scwm-discuss-outgoing; Wed, 1 Jul 1998 09:39:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA01541 for ; Wed, 1 Jul 1998 09:39:09 -0400 Received: from nuc04.t30.physik.tu-muenchen.de by MIT.EDU with SMTP id AA16002; Wed, 1 Jul 98 09:39:10 EDT Received: by nuc04.t30.physik.tu-muenchen.de via sendmail from stdin id (Debian Smail3.2.0.101) for scwm-discuss@mit.edu; Wed, 1 Jul 1998 15:39:04 +0200 (CEST) To: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199807010310.XAA30877@huis-clos.mit.edu> X-Subversiveness: radar [Hello to all my fans in domestic surveillance] FBI PLO jihad cracking BATF NSA FSF munitions Mail-Copies-To: never X-Url: http://WWW.Physik.TU-Muenchen.DE/~ecl From: Emilio Lopes Date: 01 Jul 1998 15:39:04 +0200 In-Reply-To: Maciej Stachowiak's message of "Tue, 30 Jun 1998 23:10:01 EDT" Message-Id: <87d8bpsnbb.fsf@nuc04.t30.physik.tu-muenchen.de> Lines: 21 X-Mailer: Gnus v5.6.13/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Do other people think differently? Well, I think scwm should do the following upon a mouse-click: check if there is something bound to a double-click. If no, then execute the action bound to single-click. If yes, then wait double-click-timeout miliseconds for the second click. I think this is very reasonable. The wm cannot previously guess if one wants a double or a single click. If people are annoyed by the delay, they should either reduce the double-click timeout or remove their double-click bindings. Just MHO. -- Emilio.Lopes@Physik.TU-Muenchen.DE If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Wed Jul 1 12:42:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA02349 for scwm-discuss-outgoing; Wed, 1 Jul 1998 12:42:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA02346 for ; Wed, 1 Jul 1998 12:42:17 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27776; Wed, 1 Jul 98 12:42:14 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA29446; Wed, 1 Jul 1998 09:42:25 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Long click times. References: <199807010310.XAA30877@huis-clos.mit.edu> <87d8bpsnbb.fsf@nuc04.t30.physik.tu-muenchen.de> From: Greg Badros Date: 01 Jul 1998 09:42:24 -0700 In-Reply-To: Emilio Lopes's message of "01 Jul 1998 15:39:04 +0200" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Emilio Lopes writes: > Maciej Stachowiak writes: > > > Do other people think differently? > > Well, I think scwm should do the following upon a mouse-click: check > if there is something bound to a double-click. If no, then execute the > action bound to single-click. If yes, then wait double-click-timeout > miliseconds for the second click. > > I think this is very reasonable. The wm cannot previously guess if one > wants a double or a single click. > > If people are annoyed by the delay, they should either reduce the > double-click timeout or remove their double-click bindings. > > Just MHO. The problem with this approach, though, is that you forbid the user from avoiding the double-click delay even if she choose to always use gestures with appropriate or benign prefixes. The way SCWM currently handles this (always waiting to reliably see what the gesture was) is definitely wrong. Also, Jim's notion is more compatible with the idea of event maps and is a bit lower level, which means that more complicated functionality could be provided at the scheme level (e.g., you, Emilio, could get the behaviour you want, too). Greg From owner-scwm-discuss@mit.edu Wed Jul 1 18:48:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA05124 for scwm-discuss-outgoing; Wed, 1 Jul 1998 18:48:01 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA05118 for ; Wed, 1 Jul 1998 18:47:54 -0400 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA16980; Wed, 1 Jul 98 18:47:57 EDT Received: (from smap@localhost) by bastion.artisan.com (8.8.8/8.8.4) id PAA16022 for ; Wed, 1 Jul 1998 15:45:27 -0700 (PDT) X-Authentication-Warning: bastion.artisan.com: smap set sender to using -f Received: from pup(172.16.11.3) by bastion via smap (V2.0) id xma016016; Wed, 1 Jul 98 15:44:59 -0700 Received: from lamb.artisan.com (lamb.artisan.com [172.16.10.20]) by pup.artisan.com (8.7.4/8.8.4) with ESMTP id PAA17981 for ; Wed, 1 Jul 1998 15:47:04 -0700 (PDT) Received: (from alt@localhost) by lamb.artisan.com (8.8.4/8.8.4) id PAA12102; Wed, 1 Jul 1998 15:47:03 -0700 (PDT) From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13722.48231.171383.894034@lamb.artisan.com> Date: Wed, 1 Jul 1998 15:47:03 -0700 (PDT) To: scwm-discuss@mit.edu Subject: scwm placement questions X-Mailer: VM 6.53 under Emacs 20.2.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Just started using scwm 0.7, works quite well! But I have a couple questions. 1. Is there a way to define my own placement algorithm for transient windows from an application? I'd like to tell scwm to always place the window relative to the main application (or possibly the current mouse position). The random-placement and smart-placement variables doesn't do what I want. 2. When iconifying, the icon is always aligned to the right. Can this be changed? 3. Some programs have the name embedded in the icon (such as contool) or the name is not necessary (such xclock). Can I possibly remove the icon name? Thanks, Albert -- Albert L. M. Ting * alt@artisan.com * 408-548-3111 * http://www.artisan.com Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA 94089 * USA From owner-scwm-discuss@mit.edu Wed Jul 1 18:54:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA05192 for scwm-discuss-outgoing; Wed, 1 Jul 1998 18:54:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA05189 for ; Wed, 1 Jul 1998 18:54:12 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA17890; Wed, 1 Jul 98 18:54:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA05727; Wed, 1 Jul 1998 15:53:57 -0700 (PDT) To: "Albert L. Ting" Cc: scwm-discuss@mit.edu Subject: Re: scwm placement questions References: <13722.48231.171383.894034@lamb.artisan.com> From: Greg Badros Date: 01 Jul 1998 15:53:56 -0700 In-Reply-To: "Albert L. Ting"'s message of "Wed, 1 Jul 1998 15:47:03 -0700 (PDT)" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Albert L. Ting" writes: > Just started using scwm 0.7, works quite well! But I have a couple > questions. > > 1. Is there a way to define my own placement algorithm for transient > windows from an application? I'd like to tell scwm to always place the > window relative to the main application (or possibly the current mouse > position). The random-placement and smart-placement variables doesn't > do what I want. We plan to make this a callback of some sort. Also, I'm working on integrating a powerful constraint solver into SCWM that might make good behaviour of window placement even easier to manage. Greg From owner-scwm-discuss@mit.edu Thu Jul 2 03:32:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA08806 for scwm-discuss-outgoing; Thu, 2 Jul 1998 03:32:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA08797 for ; Thu, 2 Jul 1998 03:31:50 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id JAA17584 for scwm-discuss@huis-clos.mit.edu; Thu, 2 Jul 1998 09:31:45 +0200 (CEST) Received: (qmail 663 invoked by uid 115); 2 Jul 1998 07:22:44 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm placement questions References: <13722.48231.171383.894034@lamb.artisan.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 02 Jul 1998 09:22:43 +0200 In-Reply-To: "Albert L. Ting"'s message of "Wed, 1 Jul 1998 15:47:03 -0700 (PDT)" Message-ID: Lines: 38 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 1 Jul 1998 15:47:03 -0700 (PDT) >>>>> "Albert L. Ting" said: Albert> 1. Is there a way to define my own placement algorithm for Albert> transient windows from an application? I'd like to tell Albert> scwm to always place the window relative to the main Albert> application (or possibly the current mouse position). AFAIK this is not yet possible. But placing transients under the mouse cursor is a very good idea IMHO - they usually want immediate action. I hate having to refocus because Netscape's Find Dialog pops up in a remote corner of the screen. Albert> 2. When iconifying, the icon is always aligned to the right. Albert> Can this be changed? Icons appear in the icon box. The recommended way to set this, is with the #:icon-box window-style. See doc/procedures or the sample scwmrcs. With window-styles it should be possible to give different windows different icon-boxes, so that - for example - your xterms are iconified to the right, all other windows to the bottom. Albert> 3. Some programs have the name embedded in the icon (such as Albert> contool) or the name is not necessary (such xclock). Can I Albert> possibly remove the icon name? Setting the window-style #:icon-title to #f should do the trick. BTW, the doc for set-icon-title and #:icon-title wrongly state that they take strings - in reality only booleans (show title or not) are allowed. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Jul 2 05:30:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA09385 for scwm-discuss-outgoing; Thu, 2 Jul 1998 05:30:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA09382 for ; Thu, 2 Jul 1998 05:30:15 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25518; Thu, 2 Jul 98 05:30:12 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id MAA07540; Thu, 2 Jul 1998 12:30:10 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Default bindings change request. From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Jul 1998 12:30:10 +0300 In-Reply-To: Maciej Stachowiak's message of "Sat, 06 Jun 1998 18:27:18 EDT" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk May I suggest taking the following out of system.scwmrc (or at least modifying it): ;; in case of emergency, hit Control-Meta-Q (bind-key 'all "C-M-q" quit) Emacs has this default binding in C, scheme & lisp mode: M-C-q runs the command scheme-indent-sexp: Indent each line of the list starting just after point. It's not nice for your window manager to die when you try to indent an s-expression. The default setup has one go through a chain of menus to exit with the mouse, but will also exit with a simple keypress. Maybe at least change it to: (bind-key 'all "C-M-S-q" quit) Is it really even useful, though? How often does the window manager get hosed, but not so hosed that it still executes keyboard bindings? Thanks, Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 2 09:41:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA10534 for scwm-discuss-outgoing; Thu, 2 Jul 1998 09:41:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA10531 for ; Thu, 2 Jul 1998 09:41:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25480; Thu, 2 Jul 98 09:40:56 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA20021; Thu, 2 Jul 1998 16:40:55 +0300 To: scwm-discuss@mit.edu Subject: scwm binary dependencies. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Jul 1998 16:40:54 +0300 In-Reply-To: Robert Bihlmeyer's message of "02 Jul 1998 09:22:43 +0200" Message-Id: Lines: 20 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk What dependencies does scwm have on the version of guile installed? In particular, if I build scwm using the latest guile snapshot, will it run on a system which has guile 1.2 installed? Conversely, if I build using guile 1.2, will it run on a system which has a recent guile snapshot installed? Finally, if I build using a guile snapshot, will it run on systems which have different guile snapshots installed? BTW, this is relevant to distributing binaries for scwm. If the answer to last 3 questions is no, then I don't see how much value there'd be in maing scwm binary RPMs available. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 2 12:29:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11209 for scwm-discuss-outgoing; Thu, 2 Jul 1998 12:29:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA11206 for ; Thu, 2 Jul 1998 12:29:04 -0400 Received: by tis.bellhow.com; id MAA21689; Thu, 2 Jul 1998 12:28:56 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma021573; Thu, 2 Jul 98 12:28:07 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA11082 for ; Thu, 2 Jul 1998 12:28:07 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: restarted? always #t Date: Thu, 02 Jul 1998 16:24:54 GMT Organization: Bell & Howell PSC Message-ID: <359fb295.269630177@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA11207 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings, In my setup, (restarted?) always returns #t. I use fvwm as my main window manager and restart scwm from there. I will probably be going straight to scwm once I get a pager working properly. Anyway, because I'm starting scwm from fvwm, scwm sees a number of desktops and sets Restarted to True in scwm.c:InitVariables. Is there a better way to test is this is the first time scwm is started? I want to start a clock and some perfmeters. Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 2 13:51:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA11621 for scwm-discuss-outgoing; Thu, 2 Jul 1998 13:51:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA11616 for ; Thu, 2 Jul 1998 13:51:18 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04415; Thu, 2 Jul 98 13:51:21 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA25580; Thu, 2 Jul 1998 10:51:18 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Default bindings change request. References: From: Greg Badros Date: 02 Jul 1998 10:51:17 -0700 In-Reply-To: hjstein@bfr.co.il's message of "02 Jul 1998 12:30:10 +0300" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > May I suggest taking the following out of system.scwmrc (or at least > modifying it): > > ;; in case of emergency, hit Control-Meta-Q > (bind-key 'all "C-M-q" quit) > > Emacs has this default binding in C, scheme & lisp mode: > > M-C-q runs the command scheme-indent-sexp: > > Indent each line of the list starting just after point. > > It's not nice for your window manager to die when you try to indent an > s-expression. The default setup has one go through a chain of menus > to exit with the mouse, but will also exit with a simple keypress. > > Maybe at least change it to: > > (bind-key 'all "C-M-S-q" quit) Done. I agree completely, and wouldn't be offended to see it disappear (my configuration takes a couple keystrokes walking through a menu to exit). Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 2 14:12:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA12117 for scwm-discuss-outgoing; Thu, 2 Jul 1998 14:12:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA12114 for ; Thu, 2 Jul 1998 14:12:22 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10531; Thu, 2 Jul 98 14:12:26 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA25665; Thu, 2 Jul 1998 11:12:29 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Recent changes to repository From: Greg Badros Date: 02 Jul 1998 11:12:28 -0700 Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Lately I've done a bit of clean up to the scwm code base -- touching lots of lines, with the intent of making no changes to functionality. This has all happened after the 0.7a release. Upshot, though, is that patches will be a lot more useful to the scwm developers if they are based on snapshots on or after tomorrow morning's. We'll always take whatever we can get, of course! If you are a frequent patcher (first, THANKS!), you may want to grab the snapshot tomorrow morning so that you're working with a code base more close to what is at the head of the main trunk in our CVS repository. The main changes were to make scwm compile cleanly under C++'s stronger typechecking, to use the variable name "psw" consistently for "ScwmWindow *"s, and to use guile-snarf pervasively for all primitives (instead of having a hodge-podge in scmprocs.c -- that file and its header file are now gone). I also fixed a couple of problems in the Makefile (e.g., building tags, the clean target, etc.) These periodic cleanups are essential to keeping the code manageable, and moving forward with the largish rewrites of essential features that lies ahead. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 2 14:47:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA12296 for scwm-discuss-outgoing; Thu, 2 Jul 1998 14:47:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA12293 for ; Thu, 2 Jul 1998 14:47:14 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA13178; Thu, 2 Jul 98 14:47:12 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA26550; Thu, 2 Jul 1998 11:47:14 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Recent changes to repository References: <35a0ce62.276747892@mailhost> From: Greg Badros Date: 02 Jul 1998 11:47:13 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 02 Jul 1998 18:27:57 GMT" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > On 02 Jul 1998 11:12:28 -0700, you wrote: > > >I also fixed a couple of problems in the Makefile (e.g., building tags, > >the clean target, etc.) > > All the files in $(BUILD_SOURCES) are no longer being made in the 19980702 > snapshot. Also, set-window-decor! doesn't seem to be defined in scheme. You may want to try an absolutely clean build... set_window_decor has been renamed to set_window_decor_x, now so that could be your problem (maybe it was inconsistent in today's snapshot, too -- perhaps a clean build on tomorrow's will fix your problems.) Thanks for testing this stuff! Greg From owner-scwm-discuss@mit.edu Fri Jul 3 02:04:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA15294 for scwm-discuss-outgoing; Fri, 3 Jul 1998 02:04:44 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA15291 for ; Fri, 3 Jul 1998 02:04:35 -0400 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA27978; Fri, 3 Jul 98 02:04:40 EDT Received: (from smap@localhost) by bastion.artisan.com (8.8.8/8.8.4) id XAA22581 for ; Thu, 2 Jul 1998 23:01:59 -0700 (PDT) X-Authentication-Warning: bastion.artisan.com: smap set sender to using -f Received: from pup(172.16.11.3) by bastion via smap (V2.0) id xma022579; Thu, 2 Jul 98 23:01:42 -0700 Received: from lamb.artisan.com (lamb.artisan.com [172.16.10.20]) by pup.artisan.com (8.7.4/8.8.4) with ESMTP id XAA02614 for ; Thu, 2 Jul 1998 23:04:02 -0700 (PDT) Received: (from alt@localhost) by lamb.artisan.com (8.8.4/8.8.4) id XAA16633; Thu, 2 Jul 1998 23:04:01 -0700 (PDT) From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13724.29777.41458.489082@lamb.artisan.com> Date: Thu, 2 Jul 1998 23:04:01 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: scwm placement questions X-Mailer: VM 6.53 under Emacs 20.2.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > From: Robert Bihlmeyer > To: scwm-discuss@mit.edu > Subject: Re: scwm placement questions > Date: 02 Jul 1998 09:22:43 +0200 > > Hi, > > >>>>> On Wed, 1 Jul 1998 15:47:03 -0700 (PDT) > >>>>> "Albert L. Ting" said: > > Albert> 1. Is there a way to define my own placement algorithm for > Albert> transient windows from an application? I'd like to tell > Albert> scwm to always place the window relative to the main > Albert> application (or possibly the current mouse position). > > AFAIK this is not yet possible. But placing transients under the mouse > cursor is a very good idea IMHO - they usually want immediate action. > I hate having to refocus because Netscape's Find Dialog pops up in a > remote corner of the screen. There are also situations when the application wants to control where the dialog boxes should be (such as in the center of the parent window). In this situation, scwm shouldn't override the location (or perhaps make it an option). > > Albert> 2. When iconifying, the icon is always aligned to the right. > Albert> Can this be changed? > > Icons appear in the icon box. The recommended way to set this, is with > the #:icon-box window-style. See doc/procedures or the sample scwmrcs. > With window-styles it should be possible to give different windows > different icon-boxes, so that - for example - your xterms are > iconified to the right, all other windows to the bottom. Great, this is more than what I was looking for. I like the idea of having multiple icon boxes. > > Albert> 3. Some programs have the name embedded in the icon (such as > Albert> contool) or the name is not necessary (such xclock). Can I > Albert> possibly remove the icon name? > > Setting the window-style #:icon-title to #f should do the trick. BTW, > the doc for set-icon-title and #:icon-title wrongly state that they > take strings - in reality only booleans (show title or not) are > allowed. This works, but it has bug? I have a key binding to toggle-iconify. But if there is no icon-title, scwm doesn't see the icon when I hit the key binding. It also seems to affect how you specify window-styles, perhaps because it doesn't see the icon name. I have something like this: (window-style "*" #:icon-box (list 0 0 65 (y- 100))) (window-style "clock" #:icon-title #f #:icon-box (list 500 0 65 (y- 100))) The clock icon is stored in the first icon box, not the second one. Albert -- Albert L. M. Ting * alt@artisan.com * 408-548-3111 * http://www.artisan.com Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA 94089 * USA From owner-scwm-discuss@mit.edu Fri Jul 3 17:44:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA19170 for scwm-discuss-outgoing; Fri, 3 Jul 1998 17:44:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from sfi.santafe.edu (sfi.santafe.edu [192.12.12.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA19167 for ; Fri, 3 Jul 1998 17:44:01 -0400 Received: from wijiji.santafe.edu by sfi.santafe.edu (4.1/SMI-4.1) id AA27097; Fri, 3 Jul 98 15:39:07 MDT Received: by wijiji.santafe.edu (SMI-8.6/SMI-SVR4) id PAA23585; Fri, 3 Jul 1998 15:39:07 -0600 Date: Fri, 3 Jul 1998 15:39:07 -0600 Message-Id: <199807032139.PAA23585@wijiji.santafe.edu> From: "Marcus G. Daniels" To: scwm-discuss@mit.edu Subject: how to get desk number in a client? Reply-To: mgd@santafe.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'd like to be able have my application ask the window manager for the desk number being used for a given window, so that it can be saved in a way that is controlled by the application. It's clear to me how to do this in a way specific to scwm (use libscwmexec), but it would be nicer to have either a single mechanism portable across several popular window managers with virtual desktops (e.g. fvwm), or different bits of client code to do the job. Any suggestions? From owner-scwm-discuss@mit.edu Fri Jul 3 18:22:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA19462 for scwm-discuss-outgoing; Fri, 3 Jul 1998 18:22:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA19459 for ; Fri, 3 Jul 1998 18:22:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28222; Fri, 3 Jul 98 18:22:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA22083; Fri, 3 Jul 1998 15:22:35 -0700 (PDT) To: mgd@santafe.edu Cc: scwm-discuss@mit.edu Subject: Re: how to get desk number in a client? References: <199807032139.PAA23585@wijiji.santafe.edu> From: Greg Badros Date: 03 Jul 1998 15:22:34 -0700 In-Reply-To: "Marcus G. Daniels"'s message of "Fri, 3 Jul 1998 15:39:07 -0600" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Marcus G. Daniels" writes: > I'd like to be able have my application ask the window manager for the > desk number being used for a given window, so that it can be saved in > a way that is controlled by the application. > > It's clear to me how to do this in a way specific to scwm (use > libscwmexec), but it would be nicer to have either a single mechanism > portable across several popular window managers with virtual desktops > (e.g. fvwm), or different bits of client code to do the job. > > Any suggestions? Using X Properties, perhaps. The GNOME project has some guidelines that may encompass, this, but I couldn't find the page in a quick look. Greg From owner-scwm-discuss@mit.edu Fri Jul 3 18:37:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA19618 for scwm-discuss-outgoing; Fri, 3 Jul 1998 18:37:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA19615 for ; Fri, 3 Jul 1998 18:37:16 -0400 Received: from M37-312-10.MIT.EDU by MIT.EDU with SMTP id AA29308; Fri, 3 Jul 98 18:37:13 EDT Received: by m37-312-10.MIT.EDU (SMI-8.6/4.7) id SAA09877; Fri, 3 Jul 1998 18:37:09 -0400 Message-Id: <199807032237.SAA09877@m37-312-10.MIT.EDU> To: "Albert L. Ting" Cc: scwm-discuss@mit.edu Subject: Re: scwm placement questions In-Reply-To: Your message of "Wed, 01 Jul 1998 15:47:03 PDT." <13722.48231.171383.894034@lamb.artisan.com> Date: Fri, 03 Jul 1998 18:37:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk alt@artisan.com writes: > > Just started using scwm 0.7, works quite well! But I have a couple > questions. > > 1. Is there a way to define my own placement algorithm for transient > windows from an application? I'd like to tell scwm to always place the > window relative to the main application (or possibly the current mouse > position). The random-placement and smart-placement variables doesn't > do what I want. > User-defined placement functions are not yet supported, but they will be soon. > 2. When iconifying, the icon is always aligned to the right. Can this be > changed? > Yes, give different values for the #:icon-box style option. > 3. Some programs have the name embedded in the icon (such as contool) or > the name is not necessary (such xclock). Can I possibly remove the icon > name? > I think there is a #:no-icon-title style option, but I could be wrong. I will check. - Maciej From owner-scwm-discuss@mit.edu Fri Jul 3 19:10:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA19810 for scwm-discuss-outgoing; Fri, 3 Jul 1998 19:10:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA19807 for ; Fri, 3 Jul 1998 19:10:48 -0400 Received: from M37-312-10.MIT.EDU by MIT.EDU with SMTP id AA25972; Fri, 3 Jul 98 19:10:52 EDT Received: by m37-312-10.MIT.EDU (SMI-8.6/4.7) id TAA10188; Fri, 3 Jul 1998 19:10:44 -0400 Message-Id: <199807032310.TAA10188@m37-312-10.MIT.EDU> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: scwm binary dependencies. In-Reply-To: Your message of "02 Jul 1998 16:40:54 +0300." Date: Fri, 03 Jul 1998 19:10:44 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > What dependencies does scwm have on the version of guile installed? > > In particular, if I build scwm using the latest guile snapshot, will > it run on a system which has guile 1.2 installed? > > Conversely, if I build using guile 1.2, will it run on a system which > has a recent guile snapshot installed? > No, there are a number of build-time dependencies. > Finally, if I build using a guile snapshot, will it run on systems > which have different guile snapshots installed? > Yes if there are no incompatible changes that scwm cares about between them. > BTW, this is relevant to distributing binaries for scwm. If the > answer to last 3 questions is no, then I don't see how much value > there'd be in maing scwm binary RPMs available. > I think it is OK and useful to make them against 1.2 or a specific fixed snapshot. The main target audience would most likely be people who do not build their own Guile snapshots from source and want a simple binary package that will just plain work. 1.3 is probably lurking around the corner now, and at that point, we will try to stick with the 1.3 release as the standard platform as long as is practical. - Maciej From owner-scwm-discuss@mit.edu Fri Jul 3 21:28:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA20876 for scwm-discuss-outgoing; Fri, 3 Jul 1998 21:28:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA20873 for ; Fri, 3 Jul 1998 21:28:37 -0400 Received: from M37-312-10.MIT.EDU by MIT.EDU with SMTP id AA04840; Fri, 3 Jul 98 21:28:42 EDT Received: by m37-312-10.MIT.EDU (SMI-8.6/4.7) id VAA11054; Fri, 3 Jul 1998 21:28:34 -0400 Message-Id: <199807040128.VAA11054@m37-312-10.MIT.EDU> To: mgd@santafe.edu Cc: scwm-discuss@mit.edu Subject: Re: how to get desk number in a client? In-Reply-To: Your message of "Fri, 03 Jul 1998 15:39:07 MDT." <199807032139.PAA23585@wijiji.santafe.edu> Date: Fri, 03 Jul 1998 21:28:34 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mgd@santafe.edu writes: > > I'd like to be able have my application ask the window manager for the > desk number being used for a given window, so that it can be saved in > a way that is controlled by the application. > > It's clear to me how to do this in a way specific to scwm (use > libscwmexec), but it would be nicer to have either a single mechanism > portable across several popular window managers with virtual desktops > (e.g. fvwm), or different bits of client code to do the job. > > Any suggestions? There is a proposal floating around somewhere off the Gnome web site for a set of X properties that will do this. A number of window managers are implementing them and scwm probably will too. But I reccomend against using a mechanism like this, because it imposes a particular view of virtual desktops which may not fit with what the window manager expects. For example, gwm supports having a single unbounded virtual desktop, and scwm will probably do so as well at some point. If this is for session-management purposes, I think the window manager should handle session-managing the desktops different windows are on. But if you provide more background on your intentions here, I can probably give more specific suggestions. - Maciej From owner-scwm-discuss@mit.edu Sat Jul 4 03:56:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA26411 for scwm-discuss-outgoing; Sat, 4 Jul 1998 03:56:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA26408 for ; Sat, 4 Jul 1998 03:56:54 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28471; Sat, 4 Jul 98 03:56:58 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA31635; Sat, 4 Jul 1998 10:56:46 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: Re: scwm binary dependencies. References: <199807032310.TAA10188@m37-312-10.MIT.EDU> From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Jul 1998 10:56:46 +0300 In-Reply-To: Maciej Stachowiak's message of "Fri, 03 Jul 1998 19:10:44 EDT" Message-Id: Lines: 27 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I think it is OK and useful to make them against 1.2 or a specific > fixed snapshot. The main target audience would most likely be people > who do not build their own Guile snapshots from source and want a > simple binary package that will just plain work. What about positional dependencies? I have guile installed in /usr/local. Suppose there's some RPM floating around for guile which installs it in /usr. Will an scwm built by me run on a system with this guile RPM installed? What about the regexp comment in the scwm INSTALL file? It looks like I'd better see if there is a guile RPM floating around, verify that scwm works with it, and build against it. I hope there's only one of them... > 1.3 is probably lurking around the corner now, and at that point, we > will try to stick with the 1.3 release as the standard platform as > long as is practical. I'll believe it when I see it. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Jul 4 04:58:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA28002 for scwm-discuss-outgoing; Sat, 4 Jul 1998 04:58:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA27997; Sat, 4 Jul 1998 04:58:17 -0400 Message-Id: <199807040858.EAA27997@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: scwm binary dependencies. In-reply-to: Your message of "04 Jul 1998 10:56:46 +0300." Date: Sat, 04 Jul 1998 04:58:16 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > I think it is OK and useful to make them against 1.2 or a specific > > fixed snapshot. The main target audience would most likely be people > > who do not build their own Guile snapshots from source and want a > > simple binary package that will just plain work. > > What about positional dependencies? I have guile installed in > /usr/local. Suppose there's some RPM floating around for guile which > installs it in /usr. Will an scwm built by me run on a system with > this guile RPM installed? If your LD_LIBRARY_PATH is set OK, it should not be a problem. > > What about the regexp comment in the scwm INSTALL file? It looks like > I'd better see if there is a guile RPM floating around, verify > that scwm works with it, and build against it. I hope there's only > one of them... > There is a Guile 1.2 RPM floating around from Red Hat themselves. I'd probably reccommend using that. The i386 binary RPM is at: ftp://ftp.redhat.com/pub/redhat/redhat-5.1/i386/gnome/RPMS/guile-1.2-4.i386.rpm The source RPM is at (despite the directory path, I think this is not platform dependent): ftp://ftp.redhat.com/pub/redhat/redhat-5.1/i386/gnome/SRPMS/guile-1.2-4.i386.srpm - Maciej From owner-scwm-discuss@mit.edu Sat Jul 4 15:26:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA30412 for scwm-discuss-outgoing; Sat, 4 Jul 1998 15:26:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA30409 for ; Sat, 4 Jul 1998 15:26:26 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03395; Sat, 4 Jul 98 15:26:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA01530; Sat, 4 Jul 1998 22:26:19 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm binary dependencies. References: <199807040858.EAA27997@huis-clos.mit.edu> From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Jul 1998 22:26:19 +0300 In-Reply-To: Maciej Stachowiak's message of "Sat, 04 Jul 1998 04:58:16 EDT" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > Maciej Stachowiak writes: > > > > > I think it is OK and useful to make them against 1.2 or a specific > > > fixed snapshot. The main target audience would most likely be people > > > who do not build their own Guile snapshots from source and want a > > > simple binary package that will just plain work. > > > > What about positional dependencies? I have guile installed in > > /usr/local. Suppose there's some RPM floating around for guile which > > installs it in /usr. Will an scwm built by me run on a system with > > this guile RPM installed? > > If your LD_LIBRARY_PATH is set OK, it should not be a problem. It'll still find the guile .scwm files? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Jul 4 16:42:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA30853 for scwm-discuss-outgoing; Sat, 4 Jul 1998 16:42:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA30850 for ; Sat, 4 Jul 1998 16:42:06 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07604; Sat, 4 Jul 98 16:42:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA04657; Sat, 4 Jul 1998 13:42:12 -0700 (PDT) To: scwm-discuss@mit.edu Subject: my xlock uses stderr for the menu... From: Greg Badros Date: 04 Jul 1998 13:42:12 -0700 Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk and thus the code in std-menus.scm doesn't do the right thing since it reads only from stderr. How can we make guile read both stdout and stderr from a pipe? Ideally we'd not have to use a shell to redirect 2>&1 (that's my current workaround, but guile's gotta be able to handle this better). Greg Current code which doesn't work if xlock prints modes to stderr: (define (xlock-query-modes xlock) (let ((pipe (open-input-pipe (string-append xlock " -help")))) (do ((line (read-line pipe) (read-line pipe)) (start-re (make-regexp "where mode is one of:" regexp/icase))) ((or (eof-object? line) (regexp-exec start-re line)) (if (eof-object? line) (display "xlock modes not found\n")))) (do ((line (read-line pipe) (read-line pipe)) (match #f) (ml '()) (mode-re (make-regexp "^[ ]*([a-zA-Z0-9]+)"))) ((eof-object? line) (close-pipe pipe) (reverse! (delete! "random" (delete! "bomb" (delete! "blank" ml))))) (set! match (regexp-exec mode-re line)) (if match (set! ml (cons (match:substring match 1) ml)))))) From owner-scwm-discuss@mit.edu Sat Jul 4 17:18:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA31208 for scwm-discuss-outgoing; Sat, 4 Jul 1998 17:18:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA31205 for ; Sat, 4 Jul 1998 17:18:36 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09496; Sat, 4 Jul 98 17:18:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA05397; Sat, 4 Jul 1998 14:18:41 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Segfault on callbacks when hook takes wrong number of args From: Greg Badros Date: 04 Jul 1998 14:18:40 -0700 Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm seeing hooks seg fault when the hook takes a different number of arguments (both more or less) from what it is supposed to. e.g., (add-hook! before-new-window-hook (lambda () (display "here\n"))) will cause a core dump since the before-new-window-hook is supposed to take a single argument. It looks like we need to do better checking; ideally, extra or missing arguments would just have the right thing done (ignore or set to #f). Greg From owner-scwm-discuss@mit.edu Sat Jul 4 21:16:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00863 for scwm-discuss-outgoing; Sat, 4 Jul 1998 21:16:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA00856 for ; Sat, 4 Jul 1998 21:15:54 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA23327; Sat, 4 Jul 98 21:15:58 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00851; Sat, 4 Jul 1998 21:15:48 -0400 Message-Id: <199807050115.VAA00851@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: scwm binary dependencies. In-Reply-To: Your message of "04 Jul 1998 22:26:19 +0300." Date: Sat, 04 Jul 1998 21:15:47 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > hjstein@bfr.co.il writes: > > > Maciej Stachowiak writes: > > > > > > > I think it is OK and useful to make them against 1.2 or a specific > > > > fixed snapshot. The main target audience would most likely be people > > > > who do not build their own Guile snapshots from source and want a > > > > simple binary package that will just plain work. > > > > > > What about positional dependencies? I have guile installed in > > > /usr/local. Suppose there's some RPM floating around for guile which > > > installs it in /usr. Will an scwm built by me run on a system with > > > this guile RPM installed? > > > > If your LD_LIBRARY_PATH is set OK, it should not be a problem. > > It'll still find the guile .scwm files? > Yes, the path to those is compiled into the Guile library, scwm doesn't even really depend on it directly. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sat Jul 4 21:23:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA01011 for scwm-discuss-outgoing; Sat, 4 Jul 1998 21:23:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA01008 for ; Sat, 4 Jul 1998 21:23:03 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA23638; Sat, 4 Jul 98 21:23:07 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00997; Sat, 4 Jul 1998 21:22:59 -0400 Message-Id: <199807050122.VAA00997@huis-clos.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Segfault on callbacks when hook takes wrong number of args In-Reply-To: Your message of "04 Jul 1998 14:18:40 PDT." Date: Sat, 04 Jul 1998 21:22:59 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > I'm seeing hooks seg fault when the hook takes a different number of > arguments (both more or less) from what it is supposed to. e.g., > > (add-hook! before-new-window-hook (lambda () (display "here\n"))) > > will cause a core dump since the before-new-window-hook is supposed to > take a single argument. > What it _should_ do (and what I intended) is to display an appropriate error message and go on to the next hook in the list. It's definitely not meant to core dump. > It looks like we need to do better checking; ideally, extra or missing > arguments would just have the right thing done (ignore or set to #f). > I don't think we should try to be too clever if a hook procedure has the wrong number of arguments, we should just print an error message as above. I'll try to check out why this doesn't work. However, with newer guiles you can detect the arity of a procedure, so we could actually check the arity of a procedure before even trying to call it if the right error does not get thrown otherwise. - Maciej From owner-scwm-discuss@mit.edu Sun Jul 5 13:43:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05823 for scwm-discuss-outgoing; Sun, 5 Jul 1998 13:43:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05820 for ; Sun, 5 Jul 1998 13:43:42 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29447; Sun, 5 Jul 98 13:43:39 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA09202; Sun, 5 Jul 1998 10:43:54 -0700 (PDT) To: Maciej Stachowiak Cc: "Jason Kirtland" , scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes References: <199806260434.AAA26748@huis-clos.mit.edu> From: Greg Badros Date: 05 Jul 1998 10:43:53 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 26 Jun 1998 00:34:21 EDT" Message-Id: Lines: 39 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > jason@postalmodern.com writes: > > > > > > 3) If `bind-key' doesn't recognize a modifier, it shouldn't > > > > > > bind a key at all. Or at least when the key is alphabetical. > > > > I think it would be handy to have a few convenience functions to determine > > what modifiers were available. I would be much happier crafting an rc file > > which made intelligent decisions based on, say, the availablity of a Hyper > > modifier rather than make huge conditional blocks based on machine name or > > something. > > That's a good idea. An available-modifiers primitive or something. I > guess this is another thing for the post-bugfix-release idea pile. Yesterday I added (mod-mask-{meta,alt,hyper,super}) primitives to provide this functionality. I also added handling of a MappingNotify event to re-call init_modifiers so if xmodmap is used to change a modifier, the window manager will see it w/o needing restarting (keybindings still need to be re-done, though). An available-modifiers scheme procedure could augment the 4 primitives I wrote (which return 0 if the modifier is not available, and otherwise the power-of-2 modmask that the modifier is using). > > Similarly, access to MAX_BUTTONS would be nice. (When its no longer > > hard-coded to 3... why is that, anyway?) > > > > Probably because no one whith a more than 3-button mouse ever looked > at it. Do you actually have one? If so I'll take a look at handling > this more gracefully. I'm cleaning this up now... scwm now queries the X server for the pointer mapping and uses that as the max buttons, and I'm adding a primitive X-pointer-mapping that returns a scheme list of the physical buttons attached to each of the logical mouse buttons. (Like xmodmap -pp output). Greg From owner-scwm-discuss@mit.edu Sun Jul 5 15:45:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA06590 for scwm-discuss-outgoing; Sun, 5 Jul 1998 15:45:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA06587 for ; Sun, 5 Jul 1998 15:45:07 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06502; Sun, 5 Jul 98 15:45:03 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA09317; Sun, 5 Jul 1998 12:45:18 -0700 (PDT) To: scwm-discuss@mit.edu Cc: Maciej Stachowiak Subject: SCWM_PROC macro for primitives From: Greg Badros Date: 05 Jul 1998 12:45:18 -0700 Message-Id: Lines: 56 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Now that all the primitives use SCM_PROC to mark their existence, I am switching over to a slightly less redundant means of marking primitives. color.c in tomorrows snapshot has these changes, and I'll make the rest of the changes after getting some feedback. What was, e.g.: SCM_PROC (s_set_menu_stipple_x, "set-menu-stipple!", 1, 0, 0, set_menu_stipple_x); SCM set_menu_stipple_x(SCM st) { /* primitive body here */ } is now the more concise, less error prone: SCWM_PROC (set_menu_stipple_x, "set-menu-stipple!", 1, 0, 0, (SCM st) ) by macro definition, this still uses the symbol name s_set_menu_stipple_x (just prefixes an s_ to the function name). The big difference is that SCWM_PROC also serves as the prototype for the function. There are still some hand-maintained consistencies: o the scheme procedure name is really almost automatically generateable from the C primitive name; we could have a perl script check these and warn for mismatches o the number of arguments of various kinds specified on the first line should match the formal parameter list for the C primitive definition; the same script could check this, too. o the prototype for the .h file does not necessarily match the function definition signature. We could generate, e.g., color.hp that contains the prototypes of primitives from color.c and have color.c #include them at the top of the file (they shouldn't be #include-d by color.h, since that would create a circular dependence -- scheme primitives are rarely used from C code, and even more rarely used from C code outside the current module (i.e., file), so the scheme primitive prototypes are rarely needed in the corresponding header file. The prototypes are needed, since the definition of the symbol precedes the function definition. Ideally, I'd like to combine these ideas with a documentation- preparation tool, perhaps based on sgml-doc, that has lots of smarts about SCWM_PROC declarations and just combines with English text describing the details of the primitives. The documentation is very sparse right now, and we need to at least have accurate tightly-couple documentation for *all* scheme primitives. The only sensible way to do this is with some source-code extraction tool. Feedback is appreciated. Greg From owner-scwm-discuss@mit.edu Sun Jul 5 18:24:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA08192 for scwm-discuss-outgoing; Sun, 5 Jul 1998 18:24:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA08184; Sun, 5 Jul 1998 18:24:50 -0400 Message-Id: <199807052224.SAA08184@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: my xlock uses stderr for the menu... In-reply-to: Your message of "04 Jul 1998 13:42:12 PDT." Date: Sun, 05 Jul 1998 18:24:49 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > and thus the code in std-menus.scm doesn't do the right thing since it > reads only from stderr. How can we make guile read both stdout and > stderr from a pipe? Ideally we'd not have to use a shell to redirect > 2>&1 (that's my current workaround, but guile's gotta be able to handle > this better). > Guile has a "dup" procedure which would allow us to do the effect of 2>&1 from Guile itself, however, it would complicate the code a bit. > > Current code which doesn't work if xlock prints modes to stderr: > > (define (xlock-query-modes xlock) > (let ((pipe (open-input-pipe (string-append xlock " -help")))) > (do ((line (read-line pipe) (read-line pipe)) > (start-re (make-regexp "where mode is one of:" regexp/icase))) > ((or (eof-object? line) (regexp-exec start-re line)) > (if (eof-object? line) (display "xlock modes not found\n")))) > (do ((line (read-line pipe) (read-line pipe)) (match #f) (ml '()) > (mode-re (make-regexp "^[ ]*([a-zA-Z0-9]+)"))) > ((eof-object? line) (close-pipe pipe) > (reverse! (delete! "random" (delete! "bomb" (delete! "blank" ml))))) > (set! match (regexp-exec mode-re line)) > (if match (set! ml (cons (match:substring match 1) ml)))))) This should work (but is untested), if someone can test it with both stderr and stdout printing versions of xlock, it would probably be good to incorporate it. (define (open-input-pipe-with-stderr prog) (let ((p (pipe)) (rp (car p)) (wp (cdr p))) (cond ((= (primitive-fork) 0) ;; child process (close rp) (dup wp 1) (dup wp 2) (execlp prog)) (else ;; parent process (close rp) wp)))) (define (xlock-query-modes xlock) (let ((pipe (open-input-pipe-with-stderr (string-append xlock " -help")))) (do ((line (read-line pipe) (read-line pipe)) (start-re (make-regexp "where mode is one of:" regexp/icase))) ((or (eof-object? line) (regexp-exec start-re line)) (if (eof-object? line) (display "xlock modes not found\n")))) (do ((line (read-line pipe) (read-line pipe)) (match #f) (ml '()) (mode-re (make-regexp "^[ ]*([a-zA-Z0-9]+)"))) ((eof-object? line) (close pipe) (reverse! (delete! "random" (delete! "bomb" (delete! "blank" ml))))) (set! match (regexp-exec mode-re line)) (if match (set! ml (cons (match:substring match 1) ml)))))) From owner-scwm-discuss@mit.edu Sun Jul 5 20:00:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA08734 for scwm-discuss-outgoing; Sun, 5 Jul 1998 20:00:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA08723; Sun, 5 Jul 1998 20:00:15 -0400 Message-Id: <199807060000.UAA08723@huis-clos.mit.edu> To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) cc: scwm-discuss@mit.edu Subject: Re: how to get desk number in a client? In-reply-to: Your message of "04 Jul 1998 11:16:26 PDT." Date: Sun, 05 Jul 1998 20:00:14 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu writes: > >>>>> "MS" == Maciej Stachowiak writes: > > MS> But I reccomend against using a mechanism like this, because > MS> it imposes a particular view of virtual desktops which may not fit > MS> with what the window manager expects. > > Hmm, my hope was that a desk number would be sufficient data to recover an > intuitive (if imperfect) layout. Well, I'm just pointing out that there are window managers that don't use that concept. In fact, there are window managers with no virtual desktop support at all, and Twm and Mwm are pretty widely deployed. > > MS> If this is for session-management > MS> purposes, I think the window manager should handle > MS> session-managing the desktops different windows are on. But if you > MS> provide more background on your intentions here, I can probably > MS> give more specific suggestions. > > The toolkit in question can generate many windows, and my sense is > that the users of this toolkit aren't comfortable hacking window > manager configurations. Because of this, there is a feature that lets > the user save the current (manually-placed) layout to file. Ideally, > the data about display layout could be shared across different GUIs > and window managers so that applications deployed using the toolkit > could be pre-configured, to some extent. > Well, if this is meant to be first configured and then deployed to other users, I would again reccomend against making assumptions about how virtual desktops work. However, if this is indeed very important to the application, you will probably need wm-specific hacks for at least some window managers, such as the CDE window manager, dtwm and the standard Irix window manager, 4Dwm, since these are highly unlikely to support unified desktop hints any time soon. Are you at liberty to say what the toolkit in question does, specifically? From owner-scwm-discuss@mit.edu Sun Jul 5 20:17:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA09049 for scwm-discuss-outgoing; Sun, 5 Jul 1998 20:17:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA09043; Sun, 5 Jul 1998 20:17:25 -0400 Message-Id: <199807060017.UAA09043@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7 notes In-reply-to: Your message of "05 Jul 1998 10:43:53 PDT." Date: Sun, 05 Jul 1998 20:17:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > That's a good idea. An available-modifiers primitive or something. I > > guess this is another thing for the post-bugfix-release idea pile. > > Yesterday I added (mod-mask-{meta,alt,hyper,super}) primitives to > provide this functionality. I also added handling of a MappingNotify > event to re-call init_modifiers so if xmodmap is used to change a > modifier, the window manager will see it w/o needing restarting > (keybindings still need to be re-done, though). An available-modifiers > scheme procedure could augment the 4 primitives I wrote (which return 0 > if the modifier is not available, and otherwise the power-of-2 modmask > that the modifier is using). I've been looking over these changes and I have some questions. In particular: * Do (mod-mask-{meta,alt,hyper,super}) really add any specifically useful functionality or great ease of implementation above just providing available-modifiers? There way well be something I am missing, but I don't think the modmasks are very useful to know. * I see that there is now a user-settable X-MappingNotify-hook. Much though I hate to say this, this seems _too_ general to me. I'd guess the only use for this is if the user wants to set different key bindings when different modifiers become available. That's pretty neat, however, I imagine MappingNotify can happen in a lot more cases, and we don't really care about those. How about specifically checking if the modifiers did actually change, and invoking a modifiers-changed-hook in that case? > > > > Similarly, access to MAX_BUTTONS would be nice. (When its no longer > > > hard-coded to 3... why is that, anyway?) > > > > > > > Probably because no one whith a more than 3-button mouse ever looked > > at it. Do you actually have one? If so I'll take a look at handling > > this more gracefully. > > I'm cleaning this up now... scwm now queries the X server for the > pointer mapping and uses that as the max buttons, and I'm adding a > primitive X-pointer-mapping that returns a scheme list of the physical > buttons attached to each of the logical mouse buttons. (Like xmodmap -pp > output). > This seems like potential overkill as well, but I will take a look at the code. From owner-scwm-discuss@mit.edu Sun Jul 5 20:19:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA09107 for scwm-discuss-outgoing; Sun, 5 Jul 1998 20:19:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA09101 for ; Sun, 5 Jul 1998 20:19:00 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA24359; Sun, 5 Jul 98 20:18:56 EDT Received: (qmail 2135 invoked by uid 11105); 6 Jul 1998 00:18:57 -0000 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: how to get desk number in a client? References: <199807060000.UAA08723@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 05 Jul 1998 17:18:57 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 05 Jul 1998 20:00:14 EDT" Message-Id: Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "MS" == Maciej Stachowiak writes: MS> Well, if this is meant to be first configured and then deployed to MS> other users, I would again reccomend against making assumptions MS> about how virtual desktops work. Ok, makes sense. And I suppose it begs the question: "why not just deploy scwm as well." MS> However, if this is indeed very important MS> to the application, you will probably need wm-specific hacks for at MS> least some window managers, such as the CDE window manager, dtwm and MS> the standard Irix window manager, 4Dwm, since these are highly MS> unlikely to support unified desktop hints any time soon. I guess it all comes out in the wash -- collect wm-specific hacks or collect wm-specific configuration information. MS> Are you at liberty to say what the toolkit in question does, MS> specifically? It's simulator for studying complex adaptive systems; systems that can be described but can't be predicted without iterating them forward in time. http://www.santafe.edu/projects/swarm Thanks! From owner-scwm-discuss@mit.edu Mon Jul 6 03:19:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA13019 for scwm-discuss-outgoing; Mon, 6 Jul 1998 03:19:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA13016 for ; Mon, 6 Jul 1998 03:19:31 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id JAA02309 for scwm-discuss@huis-clos.mit.edu; Mon, 6 Jul 1998 09:19:27 +0200 (CEST) Received: (qmail 1107 invoked by uid 115); 5 Jul 1998 18:03:28 -0000 To: scwm-discuss@mit.edu Subject: Re: my xlock uses stderr for the menu... References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Jul 1998 20:03:28 +0200 In-Reply-To: Greg Badros's message of "04 Jul 1998 13:42:12 -0700" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 04 Jul 1998 13:42:12 -0700 >>>>> Greg Badros said: (I really *hate* programs that print help messages to stderr! I guess fixing xlock is not an option, is it?) Greg> How can we make guile read both stdout and stderr from a pipe? I don't think there's a function that does this in guile ... Greg> Ideally we'd not have to use a shell to redirect 2>&1 (that's Greg> my current workaround, but guile's gotta be able to handle this Greg> better). ... why do you think there should be? "2>&1" is perfectly valid IMHO, because the shell is involved anyway. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jul 6 11:44:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA23269 for scwm-discuss-outgoing; Mon, 6 Jul 1998 11:44:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from sig.bsh.com (sig-int-206.33.103.14.sig.bsh.com [206.33.103.14]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA23266 for ; Mon, 6 Jul 1998 11:44:40 -0400 Received: from sig.bsh.com (ginger.sig.bsh.com [206.33.103.231]) by sig.bsh.com (8.8.5/8.7.3/http://www.sig.bsh.com) with ESMTP id LAA09112 for ; Mon, 6 Jul 1998 11:46:24 -0400 (EDT) Message-ID: <35A0F117.7BF464AD@sig.bsh.com> Date: Mon, 06 Jul 1998 11:45:27 -0400 From: "Jesse N. Glick" Organization: Strategic Interactive Group, Inc. X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 6.3 IP32) MIME-Version: 1.0 To: scwm-discuss@mit.edu Subject: Re: catching SIGSEGV Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's a twisted trick I used (successfully, I think!) a few years back. If you need a core dump for debugging purposes _but_ just dumping core where you stand is not acceptable (because you need to do more cleanup): have the SIGSEGV handler fork(); the parent continues on doing cleanup (releasing Xlib stuff, exiting with error status, etc.), while the child immediately calls abort() (that should be more portable than doing a `*NULL', which is not guaranteed to trigger SEGV AFAIK, though it is guaranteed not to be program data). So, your child process dumps the core trace, which should be something like abort(), then the signal handler, then the offending code; hopefully no global variables/structures of any interest to debugging will have been modified in the child (the parent might have done all sorts of things that could confuse you during cleanup). Would this help? -Jesse -- Jesse N. Glick * mailto:jglick@sig.bsh.com Sr. Programmer/Analyst * Strategic Interactive Group 800 Boylston St. Boston MA 02199 * 617-867-1017 (tel) 617-867-1111 (fax) ************************************************************************ IF I HAD KNOWN THAT IT WAS HARMLESS, I WOULD HAVE KILLED IT MYSELF. From owner-scwm-discuss@mit.edu Mon Jul 6 13:21:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23650 for scwm-discuss-outgoing; Mon, 6 Jul 1998 13:21:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23647 for ; Mon, 6 Jul 1998 13:21:11 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23934; Mon, 6 Jul 98 13:21:03 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA14916; Mon, 6 Jul 1998 10:21:11 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: my xlock uses stderr for the menu... References: From: Greg Badros Date: 06 Jul 1998 10:21:11 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Jul 1998 20:03:28 +0200" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> How can we make guile read both stdout and stderr from a pipe? > > I don't think there's a function that does this in guile ... > > Greg> Ideally we'd not have to use a shell to redirect 2>&1 (that's > Greg> my current workaround, but guile's gotta be able to handle this > Greg> better). > > ... why do you think there should be? "2>&1" is perfectly valid IMHO, > because the shell is involved anyway. Except what shell is it? (t)csh don't recognize that syntax. My workaround is a wrapper around xlock, xlock-stdout: #!/bin/sh xlock "$@" 2>&1 Which means we guarantee using sh. I suppose we could use: sh -c 'xlock -help 2>&1' but I'm hesitant to introduce `-c's because it complicates the quoting inside the command you're really trying to run -- it's no big deal here, but doesn't generalize well. Greg From owner-scwm-discuss@mit.edu Mon Jul 6 15:42:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA24706 for scwm-discuss-outgoing; Mon, 6 Jul 1998 15:42:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA24696; Mon, 6 Jul 1998 15:42:12 -0400 Message-Id: <199807061942.PAA24696@huis-clos.mit.edu> To: Greg Badros cc: robbe@orcus.priv.at cc: scwm-discuss@mit.edu Subject: Re: my xlock uses stderr for the menu... In-reply-to: Your message of "06 Jul 1998 10:21:11 PDT." Date: Mon, 06 Jul 1998 15:42:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Robert Bihlmeyer writes: > > > Greg> How can we make guile read both stdout and stderr from a pipe? > > > > I don't think there's a function that does this in guile ... > > > > Greg> Ideally we'd not have to use a shell to redirect 2>&1 (that's > > Greg> my current workaround, but guile's gotta be able to handle this > > Greg> better). > > > > ... why do you think there should be? "2>&1" is perfectly valid IMHO, > > because the shell is involved anyway. > > Except what shell is it? (t)csh don't recognize that syntax. My > workaround is a wrapper around xlock, xlock-stdout: > Umm, did you guys miss my mail on this subject, which demonstrated how to do all this from Guile, along with sample code? It's in the online list archive.... - Maciej From owner-scwm-discuss@mit.edu Mon Jul 6 16:43:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA25352 for scwm-discuss-outgoing; Mon, 6 Jul 1998 16:43:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA25349 for ; Mon, 6 Jul 1998 16:43:18 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12825; Mon, 6 Jul 98 16:43:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16863; Mon, 6 Jul 1998 13:43:00 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Recent changes to repository References: <35a22305.626094796@mailhost> From: Greg Badros Date: 06 Jul 1998 13:42:59 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Mon, 06 Jul 1998 19:33:01 GMT" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Ok, I found out what's going on. > > There are a lot of primitives that are not being (initialized? registered? > made-avaliable-to-guile?). The file that was hozing me was decor.scm. The > primitive set-window-decor! was undefined. Just try a (use-modules (app scwm > decor)) and see what happens. Yep.. I missed this one. Your fix is exactly right (except I edited the Makefile.am, not the Makefile or Makefile.in). I made the changes and they'll be available in the next snapshot > Better go over *all* the files that have the snarfing code and make sure that > there are .x files and that the init_xxx's are called in scwm_main. I just did this by hand (not perfect, but better than not having done it at all). Thanks, Dale! Greg From owner-scwm-discuss@mit.edu Tue Jul 7 10:35:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA00755 for scwm-discuss-outgoing; Tue, 7 Jul 1998 10:35:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA00752 for ; Tue, 7 Jul 1998 10:35:36 -0400 Received: by tis.bellhow.com; id KAA26121; Tue, 7 Jul 1998 10:35:19 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma026081; Tue, 7 Jul 98 10:34:57 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA04595 for ; Tue, 7 Jul 1998 10:34:57 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Solaris and FvwmPager Date: Tue, 07 Jul 1998 14:31:41 GMT Organization: Bell & Howell PSC Message-ID: <35a22b36.693727297@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA00753 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings List! I have been trying to get the FvwmPager module and scwm on Solaris to talk to each other. It isn't happening. It is *very* hard to debug, because scwm is exiting on the failure. Here is what is in my X11errors file, which is redirected stdout and stderr: *** start of `scwmrc' Scwm version: 0.7a Guile version: 1.3a libguile-config-stamp: Mon Jun 29 14:54:23 EDT 1998 ice-9-config-stamp: Mon Jun 29 14:54:23 EDT 1998 done loading modules *** `scwmrc' processed. child: /home/users10/smithd/bin/FvwmPager2 11 12 ~/.fvwm2rc 0 0 0 1 packet: (0 17 "SET_MASK 9227263 " 1) X connection to pcw3089.systems.bellhow.com:0.0 broken (explicit kill or server shutdown). I have uncommented some of the display code in fvwm-module.scm. I am not sure if I have built FvwmPager correctly. This is a Solaris box using gcc 2.8.1. Imake and friends are not set up for that compiler properly, so I had to edit all the makefiles by hand, and could have made some mistakes. I have a working FvwmPager from a 1.x version of Fvwm (I am trying to use 2.0.46), but I have heard that the protocol has been changed. Is there some way to test FvwmPager without using scwm? I don't have Fvwm2 installed. Can someone point me to a (working) FvwmPager binary that is compiled for Solaris 2.5? What bugs me though, is why is scwm exiting? Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 7 14:18:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA02313 for scwm-discuss-outgoing; Tue, 7 Jul 1998 14:18:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA02310 for ; Tue, 7 Jul 1998 14:18:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19984; Tue, 7 Jul 98 14:17:43 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA24450; Tue, 7 Jul 1998 11:17:44 -0700 (PDT) To: scwm-discuss@mit.edu Subject: primitive documentation conventions From: Greg Badros Date: 07 Jul 1998 11:17:44 -0700 Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just checked in for tomorrow's snapshot a new version of binding.c that has all its primitives documented. Below is an example of what a primitive looks like in the C source code by this proposal. It's similar to the style used by Emacs source (except the comment is a comment, not a final argument to the macro, and the list of arguments for the function is an argument to the macro instead of being bare text after the macro). I expect to write a similar perl script to extract the comments and mark them up in sgml to use with sgml-tools. Feedback is appreciated. We all know we want better documentation, so let's try to get a good system together for keeping the documentation current and easy to maintain: Greg SCWM_PROC(bind_key, "bind-key", 3, 0, 0, (SCM contexts, SCM key, SCM proc)) /** Bind the given KEY within the CONTEXTS to invoke PROC. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete) PROC is a procedure (possibly a thunk) that should be invoked */ { KeySym keysym; int len = 0; /* rest of primitive here */ . . . } From owner-scwm-discuss@mit.edu Tue Jul 7 15:06:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02826 for scwm-discuss-outgoing; Tue, 7 Jul 1998 15:06:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02822 for ; Tue, 7 Jul 1998 15:06:08 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA03152; Tue, 7 Jul 98 15:05:47 EDT Received: from mcfeely.concentric.net (mcfeely [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id PAA12652; Tue, 7 Jul 1998 15:05:49 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts009d06.phe-pa.concentric.net [209.31.155.162]) by mcfeely.concentric.net (8.8.8) id PAA25518; Tue, 7 Jul 1998 15:05:47 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id PAA05624; Tue, 7 Jul 1998 15:05:39 -0400 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of 07 Jul 1998 11:17:44 -0700 Date: 07 Jul 1998 15:05:38 -0400 Message-Id: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 07 Jul 1998 11:17:44 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "primitive documentation conventions": >> I just checked in for tomorrow's snapshot a new version of binding.c >> that has all its primitives documented. Cool! >> I expect to write a similar perl script to extract the comments and mark >> them up in sgml to use with sgml-tools. I suggest you use guile. Using perl to work with something extensible in guile looks self-damning: why not use perl for everything then? Initially I thought of using perl for wmconfig-menu.scm, I am glad I decided against it. (2 years ago I had a similar discussion with RMS: I volunteered to do something - see gulp.el in Emacs distribution - which in my opinion called for perl; RMS asked for elisp - so that he will be able to maintain it - and now I think it was a very wise decision). -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Our business is run on trust. We trust you will pay in advance. From owner-scwm-discuss@mit.edu Tue Jul 7 15:23:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03124 for scwm-discuss-outgoing; Tue, 7 Jul 1998 15:23:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA03121 for ; Tue, 7 Jul 1998 15:23:46 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07818; Tue, 7 Jul 98 15:23:25 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA24534; Tue, 7 Jul 1998 12:23:25 -0700 (PDT) To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: From: Greg Badros Date: 07 Jul 1998 12:23:24 -0700 In-Reply-To: Sam Steingold's message of "07 Jul 1998 15:05:38 -0400" Message-Id: Lines: 46 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 07 Jul 1998 11:17:44 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "primitive documentation conventions": > >> I just checked in for tomorrow's snapshot a new version of binding.c > >> that has all its primitives documented. > > Cool! But still lots of work left in documenting all the other .c files' primitives and the other functions in the .scm files in the scheme directory. :-) > >> I expect to write a similar perl script to extract the comments and mark > >> them up in sgml to use with sgml-tools. > > I suggest you use guile. > Using perl to work with something extensible in guile looks > self-damning: why not use perl for everything then? > Initially I thought of using perl for wmconfig-menu.scm, I am glad I > decided against it. Different languages have different strengths, so why use the same language for all tasks? Though I know I'll take a beating for saying this, I wouldn't have been opposed to using perl as the extension language for PCWM instead of SCWM! :-) Perl has a lot of nice features, including closures and higher-order functions. Most importantly, it's really easy to do this kind of text-processing using perl, and a bit harder using guile. > (2 years ago I had a similar discussion with RMS: I volunteered to do > something - see gulp.el in Emacs distribution - which in my opinion > called for perl; RMS asked for elisp - so that he will be able to > maintain it - and now I think it was a very wise decision). My prototype is in perl. I do believe the right thing to do is write it in guile, but it'd take *me* longer. After the documentation stabilizes and the prototype extractor works, then one of us can rewrite in guile-scheme. Greg From owner-scwm-discuss@mit.edu Tue Jul 7 15:59:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03480 for scwm-discuss-outgoing; Tue, 7 Jul 1998 15:59:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03474; Tue, 7 Jul 1998 15:59:22 -0400 Message-Id: <199807071959.PAA03474@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager In-reply-to: Your message of "Tue, 07 Jul 1998 14:31:41 GMT." <35a22b36.693727297@mailhost> Date: Tue, 07 Jul 1998 15:59:21 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Greetings List! > > I have been trying to get the FvwmPager module and scwm on Solaris to talk to > each other. It isn't happening. It is *very* hard to debug, because scwm is > exiting on the failure. > > Here is what is in my X11errors file, which is redirected stdout and stderr: > > *** start of `scwmrc' > Scwm version: 0.7a > Guile version: 1.3a > libguile-config-stamp: Mon Jun 29 14:54:23 EDT 1998 > ice-9-config-stamp: Mon Jun 29 14:54:23 EDT 1998 > done loading modules > *** `scwmrc' processed. > child: /home/users10/smithd/bin/FvwmPager2 11 12 ~/.fvwm2rc 0 0 0 1 > packet: (0 17 "SET_MASK 9227263 > " 1) > X connection to pcw3089.systems.bellhow.com:0.0 broken (explicit kill or > server shutdown). > Well, it looks like it gets the first packet OK at least, and then dies. > I have uncommented some of the display code in fvwm-module.scm. > > I am not sure if I have built FvwmPager correctly. This is a Solaris box > using gcc 2.8.1. Imake and friends are not set up for that compiler properly, > so I had to edit all the makefiles by hand, and could have made some mistakes. > > I have a working FvwmPager from a 1.x version of Fvwm (I am trying to use > 2.0.46), but I have heard that the protocol has been changed. Is there some > way to test FvwmPager without using scwm? I don't have Fvwm2 installed. Can > someone point me to a (working) FvwmPager binary that is compiled for Solaris > 2.5? > I will try building and running on a Solaris box, I have one to try it on, although I will only be able to run it over a slow net connection. If I can't reproduce this, would you mind adding some debugging statements (which I'd send you a patch for) and then testing again? > What bugs me though, is why is scwm exiting? > It really shouldn't. I am not sure what is going wrong. It may be that I screwed up the big-endian versions of the binary communication code or something. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Tue Jul 7 16:11:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03659 for scwm-discuss-outgoing; Tue, 7 Jul 1998 16:11:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA03656 for ; Tue, 7 Jul 1998 16:11:46 -0400 Received: by tis.bellhow.com; id QAA05026; Tue, 7 Jul 1998 16:11:28 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma004839; Tue, 7 Jul 98 16:10:50 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id QAA16350 for ; Tue, 7 Jul 1998 16:10:49 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager Date: Tue, 07 Jul 1998 20:07:34 GMT Organization: Bell & Howell PSC Message-ID: <35a57fe5.715406249@mailhost> References: <199807071959.PAA03474@huis-clos.mit.edu> In-Reply-To: <199807071959.PAA03474@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id QAA03657 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 07 Jul 1998 15:59:21 EDT, you wrote: >I will try building and running on a Solaris box, I have one to try it >on, although I will only be able to run it over a slow net >connection. If I can't reproduce this, would you mind adding some >debugging statements (which I'd send you a patch for) and then testing >again? Not at all. Send them! If you have a *working* FvwmPager, I'd like to have at it also. >> What bugs me though, is why is scwm exiting? >> > >It really shouldn't. I am not sure what is going wrong. It may be that >I screwed up the big-endian versions of the binary communication code >or something. Ahhh. I was bitten by that last year. The debug code worked great but the non-debug would fail miserably. Forgot to -DINTEL (this was in Developer Studio). I Hate Windows! What's the story with utilities/pager/ ? Are there plans for a ScwmPager? Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 7 16:51:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA04012 for scwm-discuss-outgoing; Tue, 7 Jul 1998 16:51:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA04009 for ; Tue, 7 Jul 1998 16:51:53 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA09904; Tue, 7 Jul 98 16:51:43 EDT Received: (qmail 1406 invoked by uid 11105); 7 Jul 1998 20:51:32 -0000 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 07 Jul 1998 13:51:32 -0700 In-Reply-To: Sam Steingold's message of 07 Jul 1998 15:05:38 -0400 Message-Id: Lines: 8 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I recently implemented a documentation parser for Objective C in elisp (the output format being DocBook SGML). Using Emacs for such things is a convenient and flexible way to go. It's essentially Common Lisp with random buffer access and regular expressions -- works fine in batch mode too. From owner-scwm-discuss@mit.edu Tue Jul 7 17:10:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04187 for scwm-discuss-outgoing; Tue, 7 Jul 1998 17:10:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA04184 for ; Tue, 7 Jul 1998 17:10:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14550; Tue, 7 Jul 98 17:10:09 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA25377; Tue, 7 Jul 1998 14:09:57 -0700 (PDT) To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: From: Greg Badros Date: 07 Jul 1998 14:09:56 -0700 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of "07 Jul 1998 13:51:32 -0700" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes: > I recently implemented a documentation parser for Objective C in elisp > (the output format being DocBook SGML). Using Emacs for such things > is a convenient and flexible way to go. It's essentially Common Lisp with > random buffer access and regular expressions -- works fine in batch mode too. Sounds similar to our goals.. I've got a prototype in Perl that does the extraction w/o adding the tags for sgml-tools. Were you using sgml-tools? DocBook is just a Document Translation Description, right? What did your output look like? (i.e., what did the input to the sgml formatter look like?) Thanks, Greg From owner-scwm-discuss@mit.edu Tue Jul 7 17:19:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04334 for scwm-discuss-outgoing; Tue, 7 Jul 1998 17:19:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04324; Tue, 7 Jul 1998 17:19:30 -0400 Message-Id: <199807072119.RAA04324@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-reply-to: Your message of "07 Jul 1998 11:17:44 PDT." Date: Tue, 07 Jul 1998 17:19:29 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > I just checked in for tomorrow's snapshot a new version of binding.c > that has all its primitives documented. Below is an example of what a > primitive looks like in the C source code by this proposal. It's > similar to the style used by Emacs source (except the comment is a > comment, not a final argument to the macro, and the list of arguments > for the function is an argument to the macro instead of being bare text > after the macro). > > I expect to write a similar perl script to extract the comments and mark > them up in sgml to use with sgml-tools. > If this means sgml-tools as in the linuxdoc-sgml, I would reccomend against, and urge DocBook instead. If you do mean DocBook, I strongly approve. There is stuff to generate TexInfo and HTML output automatically from DocBook, and possibly even a minimal man page with optional additional tags. > Feedback is appreciated. We all know we want better documentation, so > let's try to get a good system together for keeping the documentation > current and easy to maintain: > > This looks good to me (except, of course, that the format for key specifiers should be documented in more detail). Of course, we will have to do something similar for the Scheme files, and also add a general tutorial introduction, but this looks like a generally good idea. One thing I might suggest adding is another standard comment type to use next to DEFINE_HOOK so that hook documentation be auto-generated too. I foresee hooks getting used more and more in scwm, they seem like a pretty useful abstraction. > > SCWM_PROC(bind_key, "bind-key", 3, 0, 0, > (SCM contexts, SCM key, SCM proc)) > /** Bind the given KEY within the CONTEXTS to invoke PROC. > CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) > KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete) > PROC is a procedure (possibly a thunk) that should be invoked */ > { > KeySym keysym; > int len = 0; > /* rest of primitive here */ > . . . > } Hmm, maybe we should give that comment some slightly more distinctive formatting, as an extra check, like start it with /** DOC: */ or something? - Maciej From owner-scwm-discuss@mit.edu Tue Jul 7 17:28:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04509 for scwm-discuss-outgoing; Tue, 7 Jul 1998 17:28:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA04502 for ; Tue, 7 Jul 1998 17:27:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07168; Tue, 7 Jul 98 17:27:05 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA25454; Tue, 7 Jul 1998 14:27:01 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807072119.RAA04324@huis-clos.mit.edu> From: Greg Badros Date: 07 Jul 1998 14:27:01 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 07 Jul 1998 17:19:29 EDT" Message-Id: Lines: 60 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > If this means sgml-tools as in the linuxdoc-sgml, I would reccomend > against, and urge DocBook instead. If you do mean DocBook, I strongly > approve. There is stuff to generate TexInfo and HTML output > automatically from DocBook, and possibly even a minimal man page with > optional additional tags. I guess a bit confused as to what all the different pieces of the text formatting puzzle are. > > Feedback is appreciated. We all know we want better documentation, so > > let's try to get a good system together for keeping the documentation > > current and easy to maintain: > > > > > > This looks good to me (except, of course, that the format for key > specifiers should be documented in more detail). Of course, we will Thats in the doc/concepts list -- no point in documenting key specifiers in every primitive that uses them. > have to do something similar for the Scheme files, and also add a > general tutorial introduction, but this looks like a generally good > idea. Right, scheme files should be very similar, except using ;;; comments instead. The doc/concepts file is meant to keep track of the things that are general knowledge that need to be documented. > One thing I might suggest adding is another standard comment type to > use next to DEFINE_HOOK so that hook documentation be auto-generated > too. I foresee hooks getting used more and more in scwm, they seem > like a pretty useful abstraction. Sounds good. > > SCWM_PROC(bind_key, "bind-key", 3, 0, 0, > > (SCM contexts, SCM key, SCM proc)) > > /** Bind the given KEY within the CONTEXTS to invoke PROC. > > CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) > > KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete) > > PROC is a procedure (possibly a thunk) that should be invoked */ > > { > > KeySym keysym; > > int len = 0; > > /* rest of primitive here */ > > . . . > > } > > > Hmm, maybe we should give that comment some slightly more distinctive > formatting, as an extra check, like start it with /** DOC: */ or > something? It comes right after a meaningful macro, so I don't think more is necessary.... it just makes it easier to screw up, IMHO. Greg From owner-scwm-discuss@mit.edu Tue Jul 7 19:05:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA05356 for scwm-discuss-outgoing; Tue, 7 Jul 1998 19:05:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA05353 for ; Tue, 7 Jul 1998 19:05:17 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA06759; Tue, 7 Jul 98 19:05:05 EDT Received: from 192.168.1.1 (emu4@INS11.tokyo-ap4.dti.ne.jp [210.159.155.11]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id IAA11597 for ; Wed, 8 Jul 1998 08:04:53 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) id IAA09151; Wed, 8 Jul 1998 08:04:51 +0900 From: emu@ceres.dti.ne.jp To: scwm-discuss@mit.edu Subject: multibyte stuff Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII Date: 08 Jul 1998 08:04:50 +0900 Message-Id: Lines: 38 X-Mailer: Gnus v5.4.64/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried new multibyte stuff in latest snapshot(1998/07/07), and met three problems. 1. I18N macro not defined. --enable-multibyte directive have no effect :) 2. In resize.c, tmp_win still used. Please apply patch below. 3. Multibyte string not displayed in menu. I have no time now, but I'll check source later. But it looks like menu struct lacking XFontSet infomation... I have not tested new version much, but seems working well without these points. -- Eiichiro ITANI Tokyo, Japan Now, this is patch. *** resize.c~ Wed Jul 8 00:33:14 1998 --- resize.c Wed Jul 8 07:34:52 1998 *************** *** 141,147 **** if (Init) { XClearWindow(dpy, Scr.SizeWindow); if (Scr.d_depth >= 2) ! RelieveWindow(tmp_win, Scr.SizeWindow, 0, 0, Scr.SizeStringWidth + SIZE_HINDENT * 2, log_ret.height + SIZE_VINDENT * 2, Scr.MenuReliefGC, Scr.MenuShadowGC, FULL_HILITE); --- 141,147 ---- if (Init) { XClearWindow(dpy, Scr.SizeWindow); if (Scr.d_depth >= 2) ! RelieveWindow(psw, Scr.SizeWindow, 0, 0, Scr.SizeStringWidth + SIZE_HINDENT * 2, log_ret.height + SIZE_VINDENT * 2, Scr.MenuReliefGC, Scr.MenuShadowGC, FULL_HILITE); From owner-scwm-discuss@mit.edu Tue Jul 7 19:31:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA05993 for scwm-discuss-outgoing; Tue, 7 Jul 1998 19:31:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA05987 for ; Tue, 7 Jul 1998 19:30:55 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10644; Tue, 7 Jul 98 19:30:43 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA25641; Tue, 7 Jul 1998 16:30:30 -0700 (PDT) To: emu@ceres.dti.ne.jp Cc: scwm-discuss@mit.edu Subject: Re: multibyte stuff References: From: Greg Badros Date: 07 Jul 1998 16:30:29 -0700 In-Reply-To: emu@ceres.dti.ne.jp's message of "08 Jul 1998 08:04:50 +0900" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk emu@ceres.dti.ne.jp writes: > I tried new multibyte stuff in latest snapshot(1998/07/07), and met > three problems. > > 1. I18N macro not defined. --enable-multibyte directive have no > effect :) > 2. In resize.c, tmp_win still used. Please apply patch below. > 3. Multibyte string not displayed in menu. I have no time now, but > I'll check source later. But it looks like menu struct lacking > XFontSet infomation... > > I have not tested new version much, but seems working well without > these points. Thanks for the patch... this happened because the multibyte patch was generated relative to the old baseline from before fixing all the tmp_win references. I've not looked into issues 1 and 3. Greg From owner-scwm-discuss@mit.edu Tue Jul 7 19:33:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06030 for scwm-discuss-outgoing; Tue, 7 Jul 1998 19:33:14 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06026 for ; Tue, 7 Jul 1998 19:33:12 -0400 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA26702; Tue, 7 Jul 98 19:32:50 EDT Received: (from smap@localhost) by bastion.artisan.com (8.8.8/8.8.4) id QAA13884 for ; Tue, 7 Jul 1998 16:29:26 -0700 (PDT) X-Authentication-Warning: bastion.artisan.com: smap set sender to using -f Received: from pup(172.16.11.3) by bastion via smap (V2.0) id xma013879; Tue, 7 Jul 98 16:29:24 -0700 Received: from lamb.artisan.com (lamb.artisan.com [172.16.10.20]) by pup.artisan.com (8.7.4/8.8.4) with ESMTP id QAA23766 for ; Tue, 7 Jul 1998 16:32:38 -0700 (PDT) Received: (from alt@localhost) by lamb.artisan.com (8.8.4/8.8.4) id QAA29521; Tue, 7 Jul 1998 16:32:38 -0700 (PDT) From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13730.45077.793328.955962@lamb.artisan.com> Date: Tue, 7 Jul 1998 16:32:37 -0700 (PDT) To: scwm-discuss@mit.edu Subject: minor icon name bug X-Mailer: VM 6.53 under Emacs 20.2.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Some applications sees to save the icon name in a different format (UTF8?). HotJava is one such example, the icon name says "AWTApp" when it should say something like "What's Hot" (according to Solaris CDE). Albert -- Albert L. M. Ting * alt@artisan.com * 408-548-3111 * http://www.artisan.com Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA 94089 * USA From owner-scwm-discuss@mit.edu Tue Jul 7 23:07:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01533 for scwm-discuss-outgoing; Tue, 7 Jul 1998 23:07:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01512; Tue, 7 Jul 1998 23:07:30 -0400 Message-Id: <199807080307.XAA01512@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-reply-to: Your message of "07 Jul 1998 15:05:38 EDT." Date: Tue, 07 Jul 1998 23:07:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message > >>>> Sent on 07 Jul 1998 11:17:44 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "primitive documentation conventions": > >> I just checked in for tomorrow's snapshot a new version of binding.c > >> that has all its primitives documented. > > Cool! > > >> I expect to write a similar perl script to extract the comments and mark > >> them up in sgml to use with sgml-tools. > > I suggest you use guile. > Using perl to work with something extensible in guile looks > self-damning: why not use perl for everything then? > Initially I thought of using perl for wmconfig-menu.scm, I am glad I > decided against it. > > (2 years ago I had a similar discussion with RMS: I volunteered to do > something - see gulp.el in Emacs distribution - which in my opinion > called for perl; RMS asked for elisp - so that he will be able to > maintain it - and now I think it was a very wise decision). > I have two conflicting thoughts here. First of all, I think the best thing generally is to use the right tool for the right job, and perl is currently better at text processing tasks. On the other hand, I personally would like scwm to promote the use of Guile generally, at the very least because this will lead to Guile being improved and therefore to scwm working better. My general conclusions is, if Greg feels most comfortable doing the first versions in perl, he should do that, and the code can probably be easily translated by hand to Guile later. We worked that way for the fvwm module stuff and it worked out pretty well, since Greg is one of the few people in the world who writes understandable perl code (even to me, a mostly perl-non-user). However, I also saw mention of some elisp code that would do something similar to what we want and generate DocBook. If we start with that, translating to Guile (or augmenting the elisp version) would probably be the best bet, because changing the regexps to match on is probably easier than outputting the actual SGML output. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Tue Jul 7 23:23:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01752 for scwm-discuss-outgoing; Tue, 7 Jul 1998 23:23:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01746; Tue, 7 Jul 1998 23:23:26 -0400 Message-Id: <199807080323.XAA01746@huis-clos.mit.edu> To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-reply-to: Your message of "07 Jul 1998 13:51:32 PDT." Date: Tue, 07 Jul 1998 23:23:25 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu writes: > > I recently implemented a documentation parser for Objective C in elisp > (the output format being DocBook SGML). Using Emacs for such things > is a convenient and flexible way to go. It's essentially Common Lisp with > random buffer access and regular expressions -- works fine in batch mode too. > I'd personally love to see this. I expect it would be a great help. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 7 23:43:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01968 for scwm-discuss-outgoing; Tue, 7 Jul 1998 23:43:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01963; Tue, 7 Jul 1998 23:43:35 -0400 Message-Id: <199807080343.XAA01963@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-reply-to: Your message of "07 Jul 1998 14:27:01 PDT." Date: Tue, 07 Jul 1998 23:43:35 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > If this means sgml-tools as in the linuxdoc-sgml, I would reccomend > > against, and urge DocBook instead. If you do mean DocBook, I strongly > > approve. There is stuff to generate TexInfo and HTML output > > automatically from DocBook, and possibly even a minimal man page with > > optional additional tags. > > I guess a bit confused as to what all the different pieces of the text > formatting puzzle are. > There are pointers to a lot of useful packages and information at http://www.gnome.org/devel/arch/doc.shtml I especially recommend these links: http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html http://www.oreilly.com/davenport/ I was mistaken in that no one has yet done the work to generate .texi or .info files from DocBook, although HTML and nice hard copy can both be generated, and there is some work on man pages. I would really like to see TexInfo getting generated, but I am not sure when or if that will happen. > > > > This looks good to me (except, of course, that the format for key > > specifiers should be documented in more detail). Of course, we will > > Thats in the doc/concepts list -- no point in documenting key specifiers > in every primitive that uses them. > OK, sounds good to me. I'd love for there to be a awya to generate an appropriate cross-rerence. > > have to do something similar for the Scheme files, and also add a > > general tutorial introduction, but this looks like a generally good > > idea. > > Right, scheme files should be very similar, except using ;;; comments > instead. The doc/concepts file is meant to keep track of the things > that are general knowledge that need to be documented. > Well, we will especially need an extra marker in the comment here, since a lot of comments might start with ";;;". > > > > Hmm, maybe we should give that comment some slightly more distinctive > > formatting, as an extra check, like start it with /** DOC: */ or > > something? > > It comes right after a meaningful macro, so I don't think more is > necessary.... it just makes it easier to screw up, IMHO. > Well, in my opinion, some level of redundancy is good. I like to be warned when I scres up. :-) - Maciej From owner-scwm-discuss@mit.edu Wed Jul 8 00:01:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA02312 for scwm-discuss-outgoing; Wed, 8 Jul 1998 00:01:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA02307; Wed, 8 Jul 1998 00:01:24 -0400 Message-Id: <199807080401.AAA02307@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: multibyte stuff In-reply-to: Your message of "07 Jul 1998 16:30:29 PDT." Date: Wed, 08 Jul 1998 00:01:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > emu@ceres.dti.ne.jp writes: > > > I tried new multibyte stuff in latest snapshot(1998/07/07), and met > > three problems. > > > > 1. I18N macro not defined. --enable-multibyte directive have no > > effect :) > > 2. In resize.c, tmp_win still used. Please apply patch below. > > 3. Multibyte string not displayed in menu. I have no time now, but > > I'll check source later. But it looks like menu struct lacking > > XFontSet infomation... > > > > I have not tested new version much, but seems working well without > > these points. > > Thanks for the patch... this happened because the multibyte patch was > generated relative to the old baseline from before fixing all the > tmp_win references. > It's my falt, I tried to hand-fix the patch by search & replacing tmp_win with psw, but I must have missed a spot. > I've not looked into issues 1 and 3. Just fixed issue #1 in CVS I think. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 8 08:01:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA05096 for scwm-discuss-outgoing; Wed, 8 Jul 1998 08:01:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA05093 for ; Wed, 8 Jul 1998 08:01:37 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id OAA17462 for scwm-discuss@huis-clos.mit.edu; Wed, 8 Jul 1998 14:01:30 +0200 (CEST) Received: (qmail 603 invoked by uid 115); 8 Jul 1998 09:37:53 -0000 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807072119.RAA04324@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 08 Jul 1998 11:37:51 +0200 In-Reply-To: Maciej Stachowiak's message of "Tue, 07 Jul 1998 17:19:29 EDT" Message-ID: Lines: 42 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 07 Jul 1998 17:19:29 EDT >>>>> Maciej Stachowiak said: Maciej> If this means sgml-tools as in the linuxdoc-sgml, I would Maciej> reccomend against, and urge DocBook instead. sgml-tools are moving from linuxdoc to DocBook, BTW. The hacker version (1.1.x) of sgml-tools includes DocBook support (but it deserves the name "hacker version") - don't know about 1.0.x. So DocBook is certainly a good idea, as it is the quasi-standard. Maciej> Of course, we will have to do something similar for the Maciej> Scheme files, and also add a general tutorial introduction, Maciej> but this looks like a generally good idea. We should definitely use documentation-strings. For those who don't know them: guile> (define (foo x) "Foo just returns its only parameter X." x) guile> (foo 1) 1 guile> (procedure-documentation foo) "Foo just returns its only parameter X." If you want the documentation in one place, scheme code that applies `procedure-documentation' to all procedures in a given module should be trivial. This should work: (module-for-each (lambda (sym var) (display sym) (write-line ":") (let ((proc (string->symbol sym))) (if (procedure? proc) (write-line (procedure-documentation proc)))) (newline)) (current-module)) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Jul 8 11:08:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA05840 for scwm-discuss-outgoing; Wed, 8 Jul 1998 11:08:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA05837 for ; Wed, 8 Jul 1998 11:08:55 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA14813; Wed, 8 Jul 98 11:08:58 EDT Received: from 192.168.1.1 (emu4@INS291.tokyo-ap4.dti.ne.jp [210.159.142.61]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id AAA02864 for ; Thu, 9 Jul 1998 00:08:44 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) id AAA18168; Thu, 9 Jul 1998 00:08:42 +0900 To: scwm-discuss@mit.edu Subject: Re: multibyte stuff References: <199807080401.AAA02307@huis-clos.mit.edu> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro Date: 09 Jul 1998 00:08:42 +0900 In-Reply-To: Maciej Stachowiak's message of "Wed, 08 Jul 1998 00:01:24 EDT" Message-Id: Lines: 50 X-Mailer: Gnus v5.4.64/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > emu@ceres.dti.ne.jp writes: > > > > > I tried new multibyte stuff in latest snapshot(1998/07/07), and met > > > three problems. > > > > > > 1. I18N macro not defined. --enable-multibyte directive have no > > > effect :) > > > 2. In resize.c, tmp_win still used. Please apply patch below. > > > 3. Multibyte string not displayed in menu. I have no time now, but > > > I'll check source later. But it looks like menu struct lacking > > > XFontSet infomation... > > Just fixed issue #1 in CVS I think. I checked new snapshot(19980708), #1 and #2 look fixed already, thanks. But about #3, there's another problem has something to do with configure. After checking source, I noticed that #3 problem raised at compile time. C source file and I18N patch are correct mostly as a source, though I found new one mistake :) Problem is, some files don't include . For example, font.h and drawmenu.c. So even if config.h have entry "#define I18N", drawmenu.o get created without I18N stuff. So I made scwm with make option CFLAGS="-g -O2 -DI18N", successfully compiled. Now scwm with multibyte support working fine for me, no problem but many many warning "Calling hook (maybe empty)" ;) -- Eiichiro ITANI Tokyo, Japan. This is another fix. Without this, scwm won't compile when I18N. *** drawmenu.c.~1~ Wed Jul 8 00:33:14 1998 --- drawmenu.c Wed Jul 8 08:43:15 1998 *************** *** 348,353 **** --- 348,356 ---- int max_above_image_width = 0; int label_font_height = 0; int max_item_width = 0; + #ifdef I18N + XRectangle dummy,log_ret; + #endif From owner-scwm-discuss@mit.edu Wed Jul 8 12:17:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA06149 for scwm-discuss-outgoing; Wed, 8 Jul 1998 12:17:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA06146 for ; Wed, 8 Jul 1998 12:17:56 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09087; Wed, 8 Jul 98 12:17:47 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA29275; Wed, 8 Jul 1998 09:17:46 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: multibyte stuff References: <199807080401.AAA02307@huis-clos.mit.edu> From: Greg Badros Date: 08 Jul 1998 09:17:45 -0700 In-Reply-To: ITANI Eiichiro's message of "09 Jul 1998 00:08:42 +0900" Message-Id: Lines: 45 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > I checked new snapshot(19980708), #1 and #2 look fixed already, > thanks. > > But about #3, there's another problem has something to do with > configure. After checking source, I noticed that #3 problem raised at > compile time. C source file and I18N patch are correct mostly as a > source, though I found new one mistake :) > > Problem is, some files don't include . For example, font.h > and drawmenu.c. So even if config.h have entry "#define I18N", > drawmenu.o get created without I18N stuff. So I made scwm with make > option CFLAGS="-g -O2 -DI18N", successfully compiled. Now scwm with > multibyte support working fine for me, no problem but many many > warning "Calling hook (maybe empty)" ;) Ok, I'll fix this so everything does include config.h. The warnings you're getting are better thought of as debug code and can be ignored... I'll take them out soon. > -- > Eiichiro ITANI > Tokyo, Japan. > > > This is another fix. Without this, scwm won't compile when I18N. > > *** drawmenu.c.~1~ Wed Jul 8 00:33:14 1998 > --- drawmenu.c Wed Jul 8 08:43:15 1998 > *************** > *** 348,353 **** > --- 348,356 ---- > int max_above_image_width = 0; > int label_font_height = 0; > int max_item_width = 0; > + #ifdef I18N > + XRectangle dummy,log_ret; > + #endif Thanks for this patch, too. Greg From owner-scwm-discuss@mit.edu Wed Jul 8 12:32:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA06268 for scwm-discuss-outgoing; Wed, 8 Jul 1998 12:32:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA06265 for ; Wed, 8 Jul 1998 12:32:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12720; Wed, 8 Jul 98 12:31:54 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA29282; Wed, 8 Jul 1998 09:31:50 -0700 (PDT) To: Christian Lynbech Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Guile documentation References: <13731.10520.217861.65554@dur.tbit.dk> From: Greg Badros Date: 08 Jul 1998 09:31:50 -0700 In-Reply-To: Christian Lynbech's message of "Wed, 8 Jul 1998 10:08:56 +0200 (MET DST)" Message-Id: Lines: 38 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Christian Lynbech writes: > None of all this is rocket-science, but if we can agree on some sort > of conventions, I think it can help us improving the overall quality > of the documentation in the long run. We've been having a similar discussion on scwm-discuss. See our archive at: http://huis-clos.mit.edu/scwm-discuss.1998/ In particular, we've got macros SCWM_PROC, SCWM_DEFINE_HOOK, etc. that better encapsulate what SCM_PROC does, but do not include the documentation for the primitive -- that is done in a /** stylized-comment */ immediately after the SCWM_PROC. Then we plan to use a documentation extraction (somewhat like a literate programming tool, really) that will write DocBook-compliant output to then be generated into HTML, texinfo, man, etc. The extractor is just a simple prototype now that does the extraction but no markup. Ideally we (the guile and scwm developers) could come to some agreement so we can reuse tools as much as possible. A while ago when this came up, I was encouraged *not* to use the documentation strings at the scheme level because they were incredibly inefficient (in space, I believe -- they were always loaded). We were planning on using a similar, comment-based documentation method for scheme procedures, and do extraction there, too. Then procedure-documentation could look up the documentation in some external index file instead of right out of the memory image. We're starting to add documentation to scwm, so would really like to come to some consensus on how this should be done for both guile and scwm in the near future.... Greg From owner-scwm-discuss@mit.edu Wed Jul 8 12:34:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA06298 for scwm-discuss-outgoing; Wed, 8 Jul 1998 12:34:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA06294 for ; Wed, 8 Jul 1998 12:34:58 -0400 Received: by tis.bellhow.com; id MAA05839; Wed, 8 Jul 1998 12:34:50 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005741; Wed, 8 Jul 98 12:34:15 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA12019; Wed, 8 Jul 1998 12:34:14 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager Date: Wed, 08 Jul 1998 16:30:58 GMT Organization: Bell & Howell PSC Message-ID: <35a398ca.787315770@mailhost> References: <199807071959.PAA03474@huis-clos.mit.edu> In-Reply-To: <199807071959.PAA03474@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA06295 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 07 Jul 1998 15:59:21 EDT, you wrote: >dale.smith@bellhow.com writes: >> What bugs me though, is why is scwm exiting? >It really shouldn't. I am not sure what is going wrong. It may be that >I screwed up the big-endian versions of the binary communication code >or something. Things seem to be failing in fvwm-module.scm in run-fvwm-module in the line: (eval-fvwm-command command fmod (id->window window-id)) window-id is a 0. When id->window is called with an argument of 0, scwm exits. Duh, I just passed (id->window 0) to scwm using scwmrepl and got a core file. Should have checked for a core file before. Anyway, scwm aborted at window.c:2001 2001 return ((psw&& psw->w==w) ? psw->schwin : SCM_BOOL_F); That ought to narrow things down a bit! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Wed Jul 8 13:00:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA06679 for scwm-discuss-outgoing; Wed, 8 Jul 1998 13:00:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA06676 for ; Wed, 8 Jul 1998 12:59:59 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA18703; Wed, 8 Jul 98 13:00:01 EDT Received: by tis.bellhow.com; id MAA11876; Wed, 8 Jul 1998 12:59:50 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma011764; Wed, 8 Jul 98 12:59:32 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA12888; Wed, 8 Jul 1998 12:59:32 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager Date: Wed, 08 Jul 1998 16:56:15 GMT Organization: Bell & Howell PSC Message-Id: <35a5a1a7.789584532@mailhost> References: <199807071959.PAA03474@huis-clos.mit.edu> <35a398ca.787315770@mailhost> In-Reply-To: <35a398ca.787315770@mailhost> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA06677 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, 08 Jul 1998 16:30:58 GMT, you wrote: >window-id is a 0. When id->window is called with an argument of 0, scwm >exits. > >Duh, I just passed (id->window 0) to scwm using scwmrepl and got a core file. >Should have checked for a core file before. Anyway, scwm aborted at >window.c:2001 > >2001 return ((psw&& psw->w==w) ? psw->schwin : SCM_BOOL_F); > >That ought to narrow things down a bit! Whoah! psw was never being assigned from SwFromWindow() in both id_to_window and frame_id_to_window! psw = SwFromWindow(dpy, w); And now she works! Yessss. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Wed Jul 8 13:44:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA07167 for scwm-discuss-outgoing; Wed, 8 Jul 1998 13:44:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA07164 for ; Wed, 8 Jul 1998 13:44:13 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA01719; Wed, 8 Jul 98 13:44:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA00547; Wed, 8 Jul 1998 10:44:04 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807080343.XAA01963@huis-clos.mit.edu> From: Greg Badros Date: 08 Jul 1998 10:44:04 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 07 Jul 1998 23:43:35 EDT" Message-Id: Lines: 66 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > There are pointers to a lot of useful packages and information at > > http://www.gnome.org/devel/arch/doc.shtml > > I especially recommend these links: > > http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html > > http://www.oreilly.com/davenport/ Cool -- the middle link looks good and I hadn't come across it yet (or at least hadn't followed it). > I was mistaken in that no one has yet done the work to generate .texi > or .info files from DocBook, although HTML and nice hard copy can both > be generated, and there is some work on man pages. I would really like > to see TexInfo getting generated, but I am not sure when or if that > will happen. TexInfo, LaTeX (for postscript/pdf), and HTML are the big three for me-- I can live without man pages... > > Thats in the doc/concepts list -- no point in documenting key specifiers > > in every primitive that uses them. > > > > OK, sounds good to me. I'd love for there to be a awya to generate an > appropriate cross-rerence. Yep, I'm now using /**CONCEPT: ... */ to mark concept documentation (still in the source code, near where the concept details exist, and we could use something like "See also L" in the body of the docs for the keys to represent a reference to that concept keyword. > > > have to do something similar for the Scheme files, and also add a > > > general tutorial introduction, but this looks like a generally good > > > idea. > > > > Right, scheme files should be very similar, except using ;;; comments > > instead. The doc/concepts file is meant to keep track of the things > > that are general knowledge that need to be documented. > > > > Well, we will especially need an extra marker in the comment here, > since a lot of comments might start with ";;;". Or we just use the documentation strings-- a thread just began on the guile mailing list about this. > > > Hmm, maybe we should give that comment some slightly more distinctive > > > formatting, as an extra check, like start it with /** DOC: */ or > > > something? > > > > It comes right after a meaningful macro, so I don't think more is > > necessary.... it just makes it easier to screw up, IMHO. > > > > Well, in my opinion, some level of redundancy is good. I like to be > warned when I scres up. :-) Perhaps, for consistency it might be good (as I've now added the CONCEPT doc comment header). Greg From owner-scwm-discuss@mit.edu Wed Jul 8 14:10:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07323 for scwm-discuss-outgoing; Wed, 8 Jul 1998 14:10:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA07320 for ; Wed, 8 Jul 1998 14:10:45 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07987; Wed, 8 Jul 98 14:10:34 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA00580; Wed, 8 Jul 1998 11:10:25 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager References: <199807071959.PAA03474@huis-clos.mit.edu> <35a398ca.787315770@mailhost> <35a5a1a7.789584532@mailhost> From: Greg Badros Date: 08 Jul 1998 11:10:25 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Wed, 08 Jul 1998 16:56:15 GMT" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > On Wed, 08 Jul 1998 16:30:58 GMT, you wrote: > > >window-id is a 0. When id->window is called with an argument of 0, scwm > >exits. > > > >Duh, I just passed (id->window 0) to scwm using scwmrepl and got a core file. > >Should have checked for a core file before. Anyway, scwm aborted at > >window.c:2001 > > > >2001 return ((psw&& psw->w==w) ? psw->schwin : SCM_BOOL_F); > > > >That ought to narrow things down a bit! > > Whoah! psw was never being assigned from SwFromWindow() in both > id_to_window and frame_id_to_window! > > psw = SwFromWindow(dpy, w); > > And now she works! Yessss. Good eye-- thanks for the fix. I just published the change. Greg From owner-scwm-discuss@mit.edu Wed Jul 8 14:11:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07335 for scwm-discuss-outgoing; Wed, 8 Jul 1998 14:11:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA07332 for ; Wed, 8 Jul 1998 14:11:17 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA09755; Wed, 8 Jul 98 14:11:19 EDT Received: (qmail 5478 invoked by uid 11105); 8 Jul 1998 18:11:08 -0000 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807080343.XAA01963@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 08 Jul 1998 11:11:08 -0700 In-Reply-To: Greg Badros's message of 08 Jul 1998 10:44:04 -0700 Message-Id: Lines: 11 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "GB" == Greg Badros writes: GB> TexInfo, LaTeX (for postscript/pdf), and HTML are the big three GB> for me-- I can live without man pages... W.r.t. DocBook, at least in the popular DSSSL system Jade (http://www.jclark.com/jade/), there isn't a backend for Texinfo. I think it would make more sense to output Texinfo directly from the comment parsing system (in addition to SGML). From owner-scwm-discuss@mit.edu Wed Jul 8 19:17:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA09454 for scwm-discuss-outgoing; Wed, 8 Jul 1998 19:17:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA09451 for ; Wed, 8 Jul 1998 19:17:38 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA24702; Wed, 8 Jul 98 19:17:37 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA25098; Wed, 8 Jul 1998 19:17:22 -0400 To: Greg Badros Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: From: Jim Blandy Date: 08 Jul 1998 19:17:21 -0400 In-Reply-To: Greg Badros's message of 07 Jul 1998 12:23:24 -0700 Message-Id: Lines: 8 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Though I know I'll take a beating for saying this, I wouldn't have been > opposed to using perl as the extension language for PCWM instead of > SCWM! :-) *Whack* :) From owner-scwm-discuss@mit.edu Wed Jul 8 19:29:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA09676 for scwm-discuss-outgoing; Wed, 8 Jul 1998 19:29:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA09673 for ; Wed, 8 Jul 1998 19:29:32 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA26427; Wed, 8 Jul 98 19:29:31 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA25119; Wed, 8 Jul 1998 19:29:20 -0400 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807080343.XAA01963@huis-clos.mit.edu> From: Jim Blandy Date: 08 Jul 1998 19:29:19 -0400 In-Reply-To: Maciej Stachowiak's message of Tue, 07 Jul 1998 23:43:35 EDT Message-Id: Lines: 90 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk For the record, the /** foo */ format for doc strings looks like someone's borrowing it from Java. I think it's even discussed in the language spec. They've invented their own markup language for the strings, which I don't recommend you emulate. :) I'm not sure what I think about grunging through comments, but I'm very interested in what you guys come up with, for possible use in Guile. So I encourage you to take the time to do things right. I wish I know what that meant, exactly, in this case... You shouldn't use ;;; as your introducer for docstrings in Scheme code. Emacs Lisp has a set of conventions for comments which I find very helpful, and which the Emacs lisp and Scheme editing modes support: File: elisp, Node: Comment Tips, Next: Library Headers, Prev: Documentation Tips, Up: Tips Tips on Writing Comments ======================== We recommend these conventions for where to put comments and how to indent them: `;' Comments that start with a single semicolon, `;', should all be aligned to the same column on the right of the source code. Such comments usually explain how the code on the same line does its job. In Lisp mode and related modes, the `M-;' (`indent-for-comment') command automatically inserts such a `;' in the right place, or aligns such a comment if it is already present. (The following examples are taken from the Emacs sources.) (setq base-version-list ; there was a base (assoc (substring fn 0 start-vn) ; version to which file-version-assoc-list)) ; this looks like ; a subversion `;;' Comments that start with two semicolons, `;;', should be aligned to the same level of indentation as the code. Such comments usually describe the purpose of the following lines or the state of the program at that point. For example: (prog1 (setq auto-fill-function ... ... ;; update mode line (force-mode-line-update))) Every function that has no documentation string (because it is use only internally within the package it belongs to), should have instead a two-semicolon comment right before the function, explaining what the function does and how to call it properly. Explain precisely what each argument means and how the function interprets its possible value. `;;;' Comments that start with three semicolons, `;;;', should start at the left margin. Such comments are used outside function definitions to make general statements explaining the design principles of the program. For example: ;;; This Lisp code is run in Emacs ;;; when it is to operate as a server ;;; for other processes. Another use for triple-semicolon comments is for commenting out line within a function. We use triple-semicolons for this precisely so that they remain at the left margin. (defun foo (a) ;;; This is no longer necessary. ;;; (force-mode-line-update) (message "Finished with %s" a)) `;;;;' Comments that start with four semicolons, `;;;;', should be aligned to the left margin and are used for headings of major sections of a program. For example: ;;;; The kill ring The indentation commands of the Lisp modes in Emacs, such as `M-;' (`indent-for-comment') and TAB (`lisp-indent-line') automatically indent comments according to these conventions, depending on the the number of semicolons. *Note Manipulating Comments: (emacs)Comments. From owner-scwm-discuss@mit.edu Wed Jul 8 19:37:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA09813 for scwm-discuss-outgoing; Wed, 8 Jul 1998 19:37:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA09810 for ; Wed, 8 Jul 1998 19:37:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19063; Wed, 8 Jul 98 19:36:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA01069; Wed, 8 Jul 1998 16:36:47 -0700 (PDT) To: Jim Blandy Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807080343.XAA01963@huis-clos.mit.edu> From: Greg Badros Date: 08 Jul 1998 16:36:46 -0700 In-Reply-To: Jim Blandy's message of "08 Jul 1998 19:29:19 -0400" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > For the record, the /** foo */ format for doc strings looks like > someone's borrowing it from Java. I think it's even discussed in the > language spec. They've invented their own markup language for the > strings, which I don't recommend you emulate. :) The use of /** as a special comment initiator precedes Java-- we have no intentions of using javadoc to process our comments, or even its language. Instead the current (documented only by example) conventions are more like emacs lisp code. > I'm not sure what I think about grunging through comments, but I'm > very interested in what you guys come up with, for possible use in > Guile. So I encourage you to take the time to do things right. I > wish I know what that meant, exactly, in this case... We certainly want to get it reasonably close to right, but it's okay if it has to evolve a bit. We've a very difficult situation in that there is virtually no documentation for scwm (and guiles is pretty sparse, too). This is a *major* impediment to people using SCWM (and guile). > You shouldn't use ;;; as your introducer for docstrings in Scheme > code. Emacs Lisp has a set of conventions for comments which I find > very helpful, and which the Emacs lisp and Scheme editing modes > support: You're right, maybe `;;*' would be better. What is the current state of the documentation strings in guile? For the scheme level code, perhaps they are the right thing to use if they are not too inefficient. Greg From owner-scwm-discuss@mit.edu Thu Jul 9 00:10:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA11558 for scwm-discuss-outgoing; Thu, 9 Jul 1998 00:10:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA11549; Thu, 9 Jul 1998 00:10:03 -0400 Message-Id: <199807090410.AAA11549@huis-clos.mit.edu> To: Emilio Lopes cc: scwm-discuss@mit.edu Subject: Re: Long click times. In-reply-to: Your message of "01 Jul 1998 15:39:04 +0200." <87d8bpsnbb.fsf@nuc04.t30.physik.tu-muenchen.de> Date: Thu, 09 Jul 1998 00:10:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk emilio.lopes@physik.tu-muenchen.de writes: > Maciej Stachowiak writes: > > > Do other people think differently? > > Well, I think scwm should do the following upon a mouse-click: check > if there is something bound to a double-click. If no, then execute the > action bound to single-click. If yes, then wait double-click-timeout > miliseconds for the second click. > > I think this is very reasonable. The wm cannot previously guess if one > wants a double or a single click. > > If people are annoyed by the delay, they should either reduce the > double-click timeout or remove their double-click bindings. > > Just MHO. > Well, the original goal of Jim's suggestion was at least partly to reduce the complexity of the event-handling code. But I guess timing is an issue too. I'm thinking one potentially useful approach when implementing separate event type bindings is to provide both `click' and `single-click' bindings. The `click' action would always happen wether or not a double click followed, but the single-click action would wait for the timeout if there were a double-click binding for the same action. Then I think everyone could be happy. OTOH having to duplicate this work if we decided to support triple clicks would be a pain. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 9 00:19:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA11704 for scwm-discuss-outgoing; Thu, 9 Jul 1998 00:19:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA11699; Thu, 9 Jul 1998 00:19:01 -0400 Message-Id: <199807090419.AAA11699@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: restarted? always #t In-reply-to: Your message of "Thu, 02 Jul 1998 16:24:54 GMT." <359fb295.269630177@mailhost> Date: Thu, 09 Jul 1998 00:19:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Greetings, > > In my setup, (restarted?) always returns #t. I use fvwm as my main window > manager and restart scwm from there. I will probably be going straight to > scwm once I get a pager working properly. Anyway, because I'm starting scwm > from fvwm, scwm sees a number of desktops and sets Restarted to True in > scwm.c:InitVariables. > > Is there a better way to test is this is the first time scwm is started? I > want to start a clock and some perfmeters. > You're right, scwm can't tell the difference between getting restarted from fvwm and getting restarted from scwm right now. One possible approach is to set a special property on the root window the first time scwm runs, and check for it later. Does anyone have comments on wether this is a good idea? I don't know wether polluting the root window property namespace is considered really bad, or what. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 9 11:00:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA17338 for scwm-discuss-outgoing; Thu, 9 Jul 1998 11:00:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA17335 for ; Thu, 9 Jul 1998 11:00:45 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA02855; Thu, 9 Jul 98 11:00:24 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id LAA05375; Thu, 9 Jul 1998 11:00:26 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d44.phe-pa.concentric.net [209.31.155.56]) by marconi.concentric.net (8.8.8) id LAA21079; Thu, 9 Jul 1998 11:00:24 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id JAA11683; Thu, 9 Jul 1998 09:59:11 -0400 To: scwm-discuss@mit.edu Subject: get-window Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold Date: 09 Jul 1998 09:59:10 -0400 Message-Id: Lines: 13 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk When I call (get-window), the mouse cursor turns into a solid disk and I try to select a window. It takes enormous amount of time to do this using the mouse: I click all the buttons, and wait, and click again, and eventually the window is selected. OTOH, if I just hit RET, the window under the mouse is selected immediately. Try it with `window-info'. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. What garlic is to food, insanity is to art. From owner-scwm-discuss@mit.edu Thu Jul 9 11:32:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18213 for scwm-discuss-outgoing; Thu, 9 Jul 1998 11:32:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18210 for ; Thu, 9 Jul 1998 11:32:40 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA11900; Thu, 9 Jul 98 11:32:19 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id LAA13770; Thu, 9 Jul 1998 11:32:15 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807080343.XAA01963@huis-clos.mit.edu> From: Jim Blandy Date: 09 Jul 1998 11:32:14 -0400 In-Reply-To: Greg Badros's message of 08 Jul 1998 16:36:46 -0700 Message-Id: Lines: 19 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > What is the current state of the documentation strings in guile? For > the scheme level code, perhaps they are the right thing to use if they > are not too inefficient. They work, but they're stored in core. We are lacking a proper user-level command to view them, that would show the function's argument list, show the docstring using DISPLAY, etc. I have some vague ideas about how to read docstrings lazily (i.e. let them sit in the source file until referenced), but it's not clear to me yet how to implement them in a clean way. For Scheme code, I would recommend you go ahead and use Guile's docstring facilities. I don't think the overhead will be so bad; remember that Emacs was much larger than SCWM by the time it switched to extracted docstrings. And that way, when we do get around to implementing lazily-read docstrings, I will have a good test case to work with, to measure the impact. From owner-scwm-discuss@mit.edu Thu Jul 9 11:46:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18868 for scwm-discuss-outgoing; Thu, 9 Jul 1998 11:46:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18863 for ; Thu, 9 Jul 1998 11:46:27 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15976; Thu, 9 Jul 98 11:46:05 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA14757; Thu, 9 Jul 1998 18:45:47 +0300 To: scwm-discuss@mit.edu Subject: Cool other-proc use. From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Jul 1998 18:45:47 +0300 In-Reply-To: Jim Blandy's message of "09 Jul 1998 11:32:14 -0400" Message-Id: Lines: 53 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I thought people might like this. I like the alternate placement fcn gotten by having: (set-smart-placement-is-really-smart! #t) in my .scwmrc file. The only thing I don't like is that whereas the normal placement algorithm will cascade windows of the same name, the alternative fcn places them all over the screen. This is usually fine, but is a big pain for those annoying netscape question popups: Netscape: Question Accept cookie? They have to be clicked in order (most recent first), and some pages will pop up 5 or 10 of them. I fixed it with scwm as follows: (define (stack-windows . w) (display "stacking...\n") (let* ((size (apply window-size w)) (desired-lr (map inexact->exact (map * '(.6 .6) (display-size)))) (needed-tl (map - desired-lr size))) (apply move-to (append needed-tl w)))) (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) The stack-windows procedure places the specified window (or the current if none is specified) with it's lower right-hand corner at the point (map * '(.6 .6) (display-size)). Now I can quickly click through all those stupid cancel windows. To go one better, is there any way to move the mouse over to the cancel button & click it? Would I have to guess the correct location to move the mouse, or is there a better way to find it? Scwm is cool. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 9 11:48:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18976 for scwm-discuss-outgoing; Thu, 9 Jul 1998 11:48:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18973 for ; Thu, 9 Jul 1998 11:48:17 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA16419; Thu, 9 Jul 98 11:47:56 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id LAA13812; Thu, 9 Jul 1998 11:47:58 -0400 To: Maciej Stachowiak Cc: dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: restarted? always #t References: <199807090419.AAA11699@huis-clos.mit.edu> From: Jim Blandy Date: 09 Jul 1998 11:47:56 -0400 In-Reply-To: Maciej Stachowiak's message of Thu, 09 Jul 1998 00:19:01 EDT Message-Id: Lines: 29 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > You're right, scwm can't tell the difference between getting restarted > from fvwm and getting restarted from scwm right now. One possible > approach is to set a special property on the root window the first > time scwm runs, and check for it later. Does anyone have comments on > wether this is a good idea? I don't know wether polluting the root > window property namespace is considered really bad, or what. I don't think polluting the root window property namespace is bad; just choose a property name beginning with "SCWM_" and you'll be fine. However, I wonder if this quite solves the problem. What kind of "first-timeness" are you trying to capture? If you're trying to distinguish "the first time scwm starts in this X session", then a root window property will work. But maybe you mean "SCWM has just taken over from some non-SCWM window manager --- possibly none." In this case, if you go from scwm to fvwm, and then back to scwm, you'd want RESTARTED? to be true. Setting a root window property wouldn't work, because it would still be there from the first scwm invocation. So I think it's unclear what RESTARTED? is supposed to indicate. What is the intended application of RESTARTED? ? Maybe there are better ways to perform those functions that have semantics that are better-defined, and closer to what you want. From owner-scwm-discuss@mit.edu Thu Jul 9 12:07:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19315 for scwm-discuss-outgoing; Thu, 9 Jul 1998 12:07:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA19307 for ; Thu, 9 Jul 1998 12:06:36 -0400 Received: by tis.bellhow.com; id MAA02618; Thu, 9 Jul 1998 12:06:11 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma002450; Thu, 9 Jul 98 12:05:38 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA16092 for ; Thu, 9 Jul 1998 12:05:38 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: apropos-mode and emacs 19.xx Date: Thu, 09 Jul 1998 16:02:13 GMT Organization: Bell & Howell PSC Message-ID: <35a4e8db.5223761@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA19313 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The latest snapshot (19980709) has a call to (apropos-mode) scwm.el. This is not loaded under emacs 19.xx. I added this to scwm.el and it works. There might be better ways than this, I'm no lisp expert. (eval-and-compile (or (fboundp 'apropos-mode) (autoload 'apropos-mode "apropos"))) Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 9 12:16:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19382 for scwm-discuss-outgoing; Thu, 9 Jul 1998 12:16:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mars.zserv.tuwien.ac.at (mars.zserv.tuwien.ac.at [193.170.75.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19379 for ; Thu, 9 Jul 1998 12:16:49 -0400 Received: (qmail 7070 invoked by uid 524); 9 Jul 1998 16:16:34 -0000 To: scwm-discuss@mit.edu Subject: Autogenerated files X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Jul 1998 18:16:34 +0200 Message-ID: Lines: 17 Organization: Bene Tleilax Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I removed all(?) files that can be regenerated with autoconf, automake, and aclocal from CVS. People checking out from CVS directly will have to run ./autogen.sh on fresh checkouts (see the file HACKING). And of course, you need to have the abovementioned tools. All others, who snarf the nightly snapshots or releases should not be affected at all. (At least I hope so - tonight's snapshot will show.) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Jul 9 12:29:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19667 for scwm-discuss-outgoing; Thu, 9 Jul 1998 12:29:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19664 for ; Thu, 9 Jul 1998 12:29:47 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27553; Thu, 9 Jul 98 12:29:25 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA02299; Thu, 9 Jul 1998 09:29:16 -0700 (PDT) To: Jim Blandy Cc: Maciej Stachowiak , dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: restarted? always #t References: <199807090419.AAA11699@huis-clos.mit.edu> From: Greg Badros Date: 09 Jul 1998 09:29:15 -0700 In-Reply-To: Jim Blandy's message of "09 Jul 1998 11:47:56 -0400" Message-Id: Lines: 39 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > I don't think polluting the root window property namespace is bad; > just choose a property name beginning with "SCWM_" and you'll be fine. And this is something that we don't need to officially condone by integrating into our RESTARTED? primitive-- the primitives for setting and getting text properties already exist and users can do with them as they wish. (Keeping in mind that properties on the root window are a global namespace so prefixing with SCWM_ and the user's initials, e.g., would be a Good Thing). > However, I wonder if this quite solves the problem. What kind of > "first-timeness" are you trying to capture? > > If you're trying to distinguish "the first time scwm starts in this X > session", then a root window property will work. > > But maybe you mean "SCWM has just taken over from some non-SCWM window > manager --- possibly none." In this case, if you go from scwm to > fvwm, and then back to scwm, you'd want RESTARTED? to be true. > Setting a root window property wouldn't work, because it would still > be there from the first scwm invocation. > > So I think it's unclear what RESTARTED? is supposed to indicate. > > What is the intended application of RESTARTED? ? Maybe there are > better ways to perform those functions that have semantics that are > better-defined, and closer to what you want. I think in general, the better thing to do is handle these "once-per-session" things from your .xsession or other X-startup script that starts scwm. But, I'm not sure what uses people have in mind, either. Bottom line is: what behaviour are users hoping to achieve? There may be a better way to get there from here than using restarted?. Greg From owner-scwm-discuss@mit.edu Thu Jul 9 12:43:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19900 for scwm-discuss-outgoing; Thu, 9 Jul 1998 12:43:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19897 for ; Thu, 9 Jul 1998 12:43:34 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00815; Thu, 9 Jul 98 12:43:12 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA02316; Thu, 9 Jul 1998 09:43:01 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Autogenerated files References: From: Greg Badros Date: 09 Jul 1998 09:43:01 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Jul 1998 18:16:34 +0200" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > I removed all(?) files that can be regenerated with autoconf, > automake, and aclocal from CVS. People checking out from CVS directly > will have to run ./autogen.sh on fresh checkouts (see the file > HACKING). And of course, you need to have the abovementioned tools. > > All others, who snarf the nightly snapshots or releases should not be > affected at all. > > (At least I hope so - tonight's snapshot will show.) CVS does permit a script to be run on checout -- perhaps we should make autogen.sh get run automatically -- or at least a script that outputs some simple instructions about what files to read and that the user needs to run autogen.sh? Opposition to this idea? Preferences? Greg From owner-scwm-discuss@mit.edu Thu Jul 9 12:59:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA20110 for scwm-discuss-outgoing; Thu, 9 Jul 1998 12:59:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA20107 for ; Thu, 9 Jul 1998 12:59:38 -0400 Received: by tis.bellhow.com; id MAA12639; Thu, 9 Jul 1998 12:59:15 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma012568; Thu, 9 Jul 98 12:58:59 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA17929; Thu, 9 Jul 1998 12:58:58 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Cc: Jim Blandy Subject: Re: restarted? always #t Date: Thu, 09 Jul 1998 16:55:33 GMT Organization: Bell & Howell PSC Message-ID: <35a5ea2c.5560054@mailhost> References: <199807090419.AAA11699@huis-clos.mit.edu> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA20108 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 09 Jul 1998 11:47:56 -0400, you wrote: >However, I wonder if this quite solves the problem. What kind of >"first-timeness" are you trying to capture? > >If you're trying to distinguish "the first time scwm starts in this X >session", then a root window property will work. > >But maybe you mean "SCWM has just taken over from some non-SCWM window >manager --- possibly none." In this case, if you go from scwm to >fvwm, and then back to scwm, you'd want RESTARTED? to be true. >Setting a root window property wouldn't work, because it would still >be there from the first scwm invocation. > > >So I think it's unclear what RESTARTED? is supposed to indicate. > >What is the intended application of RESTARTED? ? Maybe there are >better ways to perform those functions that have semantics that are >better-defined, and closer to what you want. In my .fvwmrc, the InitFunction does a GoodStuff, xsetroot, FvwmPager and fires up an rxvt. The RestartFunction is the same except for the rxvt. GoodSuff starts up (captures) an rclock and a couple of perfmeters. The reason you need to restart fvwm is to re-read the .fvwmrc (at least that's what I use it for). There has been an argument that you don't need to do this for scwm, but because scwm is changing a lot and I'm still experimenting, I'm restarting scwm and bouncing back and forth to fvwm. In scwm I want to start the pager, rclock and the perfmeters to using just scwm, I'd like to start an rxvt. I don't want to start them again if I restart scwm. Basically, I want a don't-run-this-app-unless-it's-already-running. But at the same time, I want to be able start up another rxvt (or whatever) anytime I want. Mabe a series of hooks? Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 9 13:28:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20314 for scwm-discuss-outgoing; Thu, 9 Jul 1998 13:28:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20311 for ; Thu, 9 Jul 1998 13:28:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA04997; Thu, 9 Jul 98 13:28:01 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA15418; Thu, 9 Jul 1998 20:27:22 +0300 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu, Jim Blandy Subject: Re: restarted? always #t References: <199807090419.AAA11699@huis-clos.mit.edu> <35a5ea2c.5560054@mailhost> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Jul 1998 20:27:22 +0300 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 09 Jul 1998 16:55:33 GMT" Message-Id: Lines: 41 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Basically, I want a don't-run-this-app-unless-it's-already-running. > But at the same time, I want to be able start up another rxvt (or > whatever) anytime I want. Mabe a series of hooks? I take it you mean "Run-this-app-unless-it's-already-running". I tried to do this: (define (find-window-by-name window-name) (let ((wlist (list-windows #:only (lambda (w) (string=? (window-title w) window-name))))) (if (not (null? wlist)) (car wlist) #f))) (define (window-bottom window-name) (let ((window (find-window-by-name window-name))) (if (window? window) (map + (window-position window) (window-size window)) `(129 63)))) (if (not (window? (find-window-by-name "xclock"))) (execute (string-append "xclock -bg Grey20 -fg Orchid -hd Orchid -hl Orchid -geometry 60x60+0+" (number->string (cadr (window-bottom "Fvwm Pager")))))) (if (not (window? (find-window-by-name "xbiff"))) (execute (string-append "xbiff -bg Grey20 -fg Orchid -geometry +0+" (number->string (cadr (window-bottom "xclock")))))) but for some reason, during restart, (find-window-by-name ...) is returning false. Is there a way to fix this? Is there another way of doing this? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 9 13:49:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20490 for scwm-discuss-outgoing; Thu, 9 Jul 1998 13:49:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20487 for ; Thu, 9 Jul 1998 13:49:15 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA17549; Thu, 9 Jul 98 13:48:52 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id NAA04990; Thu, 9 Jul 1998 13:48:54 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d44.phe-pa.concentric.net [209.31.155.56]) by marconi.concentric.net (8.8.8) id NAA07214; Thu, 9 Jul 1998 13:48:52 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA13005; Thu, 9 Jul 1998 13:48:37 -0400 To: scwm-discuss@mit.edu Subject: Re: Cool other-proc use. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of 09 Jul 1998 18:45:47 +0300 Date: 09 Jul 1998 13:48:36 -0400 Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I didn't know about other-proc before. Now I do. Starting with the next snapshot, the happy users of flux.scm will be able to do (window-style "netscape" #:other-proc (in-viewport 1 1)) and have all the netscape windows appear strictly in the viewport 1:1 (the initial top left being 0:0). Essentially, `other-proc' can do the job of the much awaited placement functions. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Don't ascribe to malice what can be adequately explained for by stupidity. From owner-scwm-discuss@mit.edu Thu Jul 9 13:49:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20499 for scwm-discuss-outgoing; Thu, 9 Jul 1998 13:49:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20496 for ; Thu, 9 Jul 1998 13:49:29 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA10932; Thu, 9 Jul 98 13:49:20 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id NAA05018; Thu, 9 Jul 1998 13:49:04 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d44.phe-pa.concentric.net [209.31.155.56]) by marconi.concentric.net (8.8.8) id NAA07228; Thu, 9 Jul 1998 13:48:54 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.8.7/8.8.7) id NAA13003; Thu, 9 Jul 1998 13:42:47 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: apropos-mode and emacs 19.xx References: <35a4e8db.5223761@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of Thu, 09 Jul 1998 16:02:13 GMT Date: 09 Jul 1998 13:42:46 -0400 Message-Id: Lines: 14 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35a4e8db.5223761@mailhost> >>>> Sent on Thu, 09 Jul 1998 16:02:13 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "apropos-mode and emacs 19.xx": >> The latest snapshot (19980709) has a call to (apropos-mode) scwm.el. >> This is not loaded under emacs 19.xx. fixed. thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Thu Jul 9 14:08:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA20697 for scwm-discuss-outgoing; Thu, 9 Jul 1998 14:08:44 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA20694 for ; Thu, 9 Jul 1998 14:08:43 -0400 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA17085; Thu, 9 Jul 98 14:08:34 EDT Received: (from smap@localhost) by bastion.artisan.com (8.8.8/8.8.4) id LAA15889; Thu, 9 Jul 1998 11:04:24 -0700 (PDT) X-Authentication-Warning: bastion.artisan.com: smap set sender to using -f Received: from pup(172.16.11.3) by bastion via smap (V2.0) id xma015885; Thu, 9 Jul 98 11:04:20 -0700 Received: from lamb.artisan.com (lamb.artisan.com [172.16.10.20]) by pup.artisan.com (8.7.4/8.8.4) with ESMTP id LAA09636; Thu, 9 Jul 1998 11:07:54 -0700 (PDT) Received: (from alt@localhost) by lamb.artisan.com (8.8.4/8.8.4) id LAA00725; Thu, 9 Jul 1998 11:07:54 -0700 (PDT) From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13733.1785.889517.363631@lamb.artisan.com> Date: Thu, 9 Jul 1998 11:07:53 -0700 (PDT) To: hjstein@bfr.co.il Cc: scwm-discuss@mit.edu Subject: Re: Cool other-proc use. References: X-Mailer: VM 6.53 under Emacs 20.2.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Thanks for pointing out this feature. As for control the mouse position, there is this function that you can probably use. - Function: move-pointer-to X Y Moves the pointer to the absolute position X, Y. -- Albert L. M. Ting * alt@artisan.com * 408-548-3111 * http://www.artisan.com Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA 94089 * USA From owner-scwm-discuss@mit.edu Thu Jul 9 14:36:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA20860 for scwm-discuss-outgoing; Thu, 9 Jul 1998 14:36:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA20857 for ; Thu, 9 Jul 1998 14:36:19 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id UAA25616 for scwm-discuss@huis-clos.mit.edu; Thu, 9 Jul 1998 20:36:00 +0200 (CEST) Received: (qmail 398 invoked by uid 115); 9 Jul 1998 09:07:22 -0000 To: scwm-discuss@mit.edu Subject: FlipFocus X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Jul 1998 11:07:21 +0200 Message-ID: Lines: 10 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, why is FlipFocus marked as "intentionally omitted" in doc/progress? I do deem it useful. Should it be implemented in scheme? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Jul 9 14:47:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA20954 for scwm-discuss-outgoing; Thu, 9 Jul 1998 14:47:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA20951 for ; Thu, 9 Jul 1998 14:47:36 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04187; Thu, 9 Jul 98 14:47:14 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA02567; Thu, 9 Jul 1998 11:47:11 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: FlipFocus References: From: Greg Badros Date: 09 Jul 1998 11:47:11 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Jul 1998 11:07:21 +0200" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > why is FlipFocus marked as "intentionally omitted" in doc/progress? I > do deem it useful. Should it be implemented in scheme? That's my guess -- it'd be silly to write as a C primitive. (doc/progress is pretty dang old!) Greg From owner-scwm-discuss@mit.edu Thu Jul 9 17:56:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21671 for scwm-discuss-outgoing; Thu, 9 Jul 1998 17:56:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21668 for ; Thu, 9 Jul 1998 17:56:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA27392; Thu, 9 Jul 98 17:56:27 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA16761; Fri, 10 Jul 1998 00:56:07 +0300 To: scwm-discuss@mit.edu Subject: DeferExecution click lossage bug & repair-hack. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 10 Jul 1998 00:56:07 +0300 In-Reply-To: hjstein@bfr.co.il's message of "09 Jul 1998 20:27:22 +0300" Message-Id: Lines: 66 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk It seems like close-window doesn't react unless some mouse motion occurs btw the mouse-button-press & the mouse-button-release. Here's how I can consistently reproduce it: 1. Bring up a window. 2. Bring up close window. I do it by clicking on the root window with mb2 & selecting the "Close" item. My .scwmrc is pretty close to the default system one, with the following menu item on the window-ops-menu, and window-ops-menu bound to mb2 clicks in the root window: (menuitem "Close" #:action close-window) 3. Click the mouse in the window brought up in 1, being very careful not to move the mouse while clicking. When I do this, the window doesn't close. It only closes if the mouse moves between the mb1-press & the mb1-release. Checking the code, I see that close-window uses get-window, which uses select-window, which uses DeferExecution to do the actual clickwork. It looks like the bug is in DeferExecution. I think the problem is as follows: 1. The code enters the: while (!fFinished) {...} loop. 2. The first XMaskEvent grabs a button press. 3. The next 2 if stmts are false, so fFinished remains false (because FinishEvent is ButtonRelease). 4. The next if stmt is true, so the next call to XMaskEvent fires & grabs the button release. fDone gets set to True, but fFinised is still false. 5. We're fDone, but we're not fFinished, so we loop! Thus, the events are lost!!! However, if there's a motion btw the button-press & the button release, then the 2nd XMaskEvent call in the loop will grab the motion, & the top call will get the button-release, so fFinised will become True & the loop will exit (although I'm still worrying about what happens if there's an even number of mouse motions). I guess one fix would be to check for eventp->type == FinishEvent again after the 2nd call to XMaskEvent, but it's not at all clear to me why the 2nd call to XMaskEvent should even be made when fFinished is True. Why is it grabbing another event if we already found the event we wanted? I'd think it should just keep grabbing & dispatching events until it finds the FinishEvent - I don't see why there should be 2 XMaskEvent calls in the loop. Can anyone shed some light on this? Thanks, Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 9 18:09:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA21783 for scwm-discuss-outgoing; Thu, 9 Jul 1998 18:09:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA21780 for ; Thu, 9 Jul 1998 18:09:39 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28009; Thu, 9 Jul 98 18:09:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA02967; Thu, 9 Jul 1998 15:09:12 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: DeferExecution click lossage bug & repair-hack. References: From: Greg Badros Date: 09 Jul 1998 15:09:11 -0700 In-Reply-To: hjstein@bfr.co.il's message of "10 Jul 1998 00:56:07 +0300" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > It seems like close-window doesn't react unless some mouse motion > occurs btw the mouse-button-press & the mouse-button-release. > > Here's how I can consistently reproduce it: > > 1. Bring up a window. > > 2. Bring up close window. I do it by clicking on the root window with > mb2 & selecting the "Close" item. My .scwmrc is pretty close to > the default system one, with the following menu item on the > window-ops-menu, and window-ops-menu bound to mb2 clicks in the > root window: > > (menuitem "Close" #:action close-window) > > 3. Click the mouse in the window brought up in 1, being very careful > not to move the mouse while clicking. > > When I do this, the window doesn't close. It only closes if the mouse > moves between the mb1-press & the mb1-release. > > Checking the code, I see that close-window uses get-window, which uses > select-window, which uses DeferExecution to do the actual clickwork. > It looks like the bug is in DeferExecution. Yep. DeferExecution's problem has been on the BUGS list for a while-- I'll look into your analysis and try to fix the problem or write select-interactively which I've meant to replace (get-window) with for a long time. Thanks for your careful study of the problem -- it'll certainly help me figure it out (if you don't have a fix before I get to it! :-) ) Thanks, Greg From owner-scwm-discuss@mit.edu Fri Jul 10 02:02:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA25037 for scwm-discuss-outgoing; Fri, 10 Jul 1998 02:02:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA25034 for ; Fri, 10 Jul 1998 02:02:18 -0400 Received: from rukbat.cs.unc.edu (rukbat.cs.unc.edu [152.2.133.170]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id CAA13268 for ; Fri, 10 Jul 1998 02:01:52 -0400 (EDT) Date: Fri, 10 Jul 1998 02:01:52 -0400 (EDT) From: Stephen Tell To: scwm-discuss@mit.edu Subject: scwm 0.7a on HP-UX 10.20 - problems overcome, patches enclosed In-Reply-To: <199807100412.AAA24595@huis-clos.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I ran into various difficulties while compiling scwm 0.7a on HP-UX 10.20. This long-winded message says what I did to get them resolved, including some little patches. Maybe they'll help others, maybe our esteemed maintainers will pick some of them up. The first difficulty I encountered while running configure - couldn't find guile. I had built/installed it with more than just a simple --prefix, so --with-guile-prefix didn't quite do the job. I wound up with this mess, which got through configure: GUILE_LIBS_PRE=-L/home/msl/tell/lib/hp700_hpux10 \ LIBS=-L/home/msl/tell/lib/hp700_hpux10 \ ./configure --prefix=/home/msl/tell \ --bindir=/home/msl/tell/bin/hp700_hpux10 \ --sbindir=/home/msl/tell/bin/hp700_hpux10 \ --libexecdir=/home/msl/tell/lib/hp700_hpux10 \ --libdir=/home/msl/tell/lib/hp700_hpux10 \ --with-guile-prefix=/home/msl/tell \ --with-guile-exec-prefix=/home/msl/tell/bin/hp700_hpux10 I had to build guile like this to get it installed in my home directory and allow for installing multiple architectures: ./configure --prefix=/home/msl/tell \ --bindir=/home/msl/tell/bin/hp700_hpux10 \ --sbindir=/home/msl/tell/bin/hp700_hpux10 \ --libexecdir=/home/msl/tell/lib/hp700_hpux10 \ --libdir=/home/msl/tell/lib/hp700_hpux10 Autoconf handles very badly this situation where you need an explicit architecture/OS path component. My home directory is nfs-mounted on many different kinds of machines and I don't have permission to install into /usr or /usr/local, so I run into this all the time. Moving on to "make": while linking scwm, I got these undefined symbols: scwm_internal_select (code) setlinebuf (code) setlinebuf doesn't exist on HP-UX; it has setbuf and setvbuf only. Checking some man pages and old manuals: - 4.3 BSD has setbuf, setbuffer, setlinebuf. "setbuffer and setlinebuf are not portable to non 4.2BSD systems" - Western Electric Unix 5.0 (early SYSV, I think) has setbuf only, with no way to explicitly set line-buffering. It adds that "output streams directed to terminals are always line-buffered unless they are unbuffered." - Linux with libc6 (glibc2) has the whole lot of them: setvbuf, setbuffer, setlinebuf, setvbuf setvbuf is the most general routine, I think. Suggested strategy: check for setvbuf, use it if it exists. else check for setlinebuf, use it if it exists. else setbuf(NULL) to get no buffering at all. (One could argue for checking for setlinebuf first.) (as an aside, I'd love to be able to buy a book that described these sorts of unix variances across all functions commonly found in libc and elsewhere. I suppose in an ideal world autoconf would already know about all of them...) I changed scwm.c, config.h.in, and configure.in to implement this; patches below. As for scwm_internal_select, I'm pretty sure its a typo in a "#ifdef _hpux" in events.c. The obvious one-character patch is below. I got type mismatch warnings while compiling that; I think that the ifdef with its casts may not be correct for HP-UX 10.20. Anyway, after all that, I got scwm compiled and running. context diffs: (I'm new at autoconf; I think this is right but corrections are welcome) *** configure.in.orig Sat Jun 27 22:37:56 1998 --- configure.in Fri Jul 10 00:02:27 1998 *************** *** 188,193 **** --- 188,194 ---- AC_CHECK_FUNCS(gethostname waitpid sysconf uname) AC_CHECK_FUNCS(strerror strcasecmp strncasecmp) AC_CHECK_FUNC(usleep, AC_DEFINE(HAVE_USLEEP)) + AC_CHECK_FUNC(setvbuf, AC_DEFINE(HAVE_SETVBUF), AC_CHECK_FUNCS(setlinebuf)) dnl # Check for bleeding-edge guile funcs *** config.h.in.orig Sat Jun 27 22:39:02 1998 --- config.h.in Fri Jul 10 00:05:54 1998 *************** *** 103,108 **** --- 103,111 ---- /* Define this if your system has the usleep function. */ #undef HAVE_USLEEP + #undef HAVE_SETVBUF + #undef HAVE_SETLINEBUF + /* Define if you have the gethostname function. */ #undef HAVE_GETHOSTNAME *** scwm.c.orig Sat Jun 27 22:41:03 1998 --- scwm.c Fri Jul 10 00:00:03 1998 *************** *** 223,230 **** --- 223,240 ---- it's useful to pipe through to grep -v or X-error-describe while debugging: FIXGJB: make these runtime options -- also, isn't stderr never block bufferred?? */ + #ifdef HAVE_SETVBUF + setvbuf(stderr, NULL, _IOLBF, BUFSIZ); + setvbuf(stdout, NULL, _IOLBF, BUFSIZ); + #else + #ifdef HAVE_SETLINEBUF setlinebuf(stderr); setlinebuf(stdout); + #else + setbuf(stderr, NULL); + setbuf(stdout, NULL); + #endif + #endif init_scwm_types(); init_callbacks(); *** events.c.orig Sat Jun 27 22:40:22 1998 --- events.c Thu Jul 9 23:51:24 1998 *************** *** 1515,1521 **** } #ifdef __hpux ! retval = scwm_internal_select(fd_width + 1, (int *) &in_fdset, (int *) &out_fdset, 0, tp); #else retval = scm_internal_select(fd_width + 1, &in_fdset, &out_fdset, 0, tp); #endif --- 1515,1521 ---- } #ifdef __hpux ! retval = scm_internal_select(fd_width + 1, (int *) &in_fdset, (int *) &out_fdset, 0, tp); #else retval = scm_internal_select(fd_width + 1, &in_fdset, &out_fdset, 0, tp); #endif -- Steve Tell tell@cs.unc.edu http://www.cs.unc.edu/~tell W:919-962-1845 Research Associate, Microelectronic Systems Laboratory Computer Science Department, UNC@Chapel Hill. From owner-scwm-discuss@mit.edu Fri Jul 10 05:40:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA26519 for scwm-discuss-outgoing; Fri, 10 Jul 1998 05:40:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id FAA26516 for ; Fri, 10 Jul 1998 05:40:38 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id LAA22048 for scwm-discuss@huis-clos.mit.edu; Fri, 10 Jul 1998 11:40:11 +0200 (CEST) Received: (qmail 1767 invoked by uid 115); 10 Jul 1998 09:16:56 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm 0.7a on HP-UX 10.20 - problems overcome, patches enclosed References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 10 Jul 1998 11:16:54 +0200 In-Reply-To: Stephen Tell's message of "Fri, 10 Jul 1998 02:01:52 -0400 (EDT)" Message-ID: Lines: 52 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> On Fri, 10 Jul 1998 02:01:52 -0400 (EDT) >>>>> Stephen Tell said: Stephen> ./configure --prefix=/home/msl/tell \ Stephen> --bindir=/home/msl/tell/bin/hp700_hpux10 \ Stephen> --sbindir=/home/msl/tell/bin/hp700_hpux10 \ Stephen> --libexecdir=/home/msl/tell/lib/hp700_hpux10 \ Stephen> --libdir=/home/msl/tell/lib/hp700_hpux10 Stephen> Autoconf handles very badly this situation where you need an Stephen> explicit architecture/OS path component. My home directory Stephen> is nfs-mounted on many different kinds of machines and I Stephen> don't have permission to install into /usr or /usr/local, so Stephen> I run into this all the time. I have a very similar situation at my university: no root, home dir accessible from two different architectures. Autoconf does better if you layout directories like this (I hope this is readable): [your home or whatever] lib arch-independent stuff share bin scripts & such [arch1] bin lib [arch2] bin lib ... So, assuming /x is your home directory, and you want to install for architecture arch1, it will suffice to give "--prefix=/x --exec-prefix=/x/arch1" to configure. This should work for all packages, anything else (e.g. if it installs arch-dependent directly under /x) is a bug. Back to scwm: If you have configured/built/installed guile like this, setting the --with-guile-{exec}prefix switches should be enough. One enhancement, that would be nice: --with-guile-* should default to PREFIX and EPREFIX. It is reasonable to assume that the user installs scwm the same way he installed guile (or would tell us otherwise). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Jul 10 07:57:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA27535 for scwm-discuss-outgoing; Fri, 10 Jul 1998 07:57:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA27532 for ; Fri, 10 Jul 1998 07:57:06 -0400 Received: from mars.zserv.tuwien.ac.at by MIT.EDU with SMTP id AA14128; Fri, 10 Jul 98 07:56:35 EDT Received: (qmail 28999 invoked by uid 524); 10 Jul 1998 11:56:40 -0000 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Autogenerated files References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 10 Jul 1998 13:56:40 +0200 In-Reply-To: Greg Badros's message of "09 Jul 1998 09:43:01 -0700" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.11/XEmacs 20.3 - "Vatican City" Organization: The Cabal (There Is None) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 09 Jul 1998 09:43:01 -0700 >>>>> Greg Badros said: Greg> CVS does permit a script to be run on checout -- perhaps we Greg> should make autogen.sh get run automatically -- Seems like a nice idea. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Jul 10 09:54:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA28651 for scwm-discuss-outgoing; Fri, 10 Jul 1998 09:54:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA28647; Fri, 10 Jul 1998 09:54:51 -0400 Message-Id: <199807101354.JAA28647@huis-clos.mit.edu> To: Greg Badros , jimb@red-bean.com cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions In-reply-to: Your message of "08 Jul 1998 16:36:46 PDT." Date: Fri, 10 Jul 1998 09:54:51 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've just caught up on the whole documentation threads on the guile and scwm-discuss lists. I am posting on both lists with my thoughts because I think cooperation in this area would be extremely beneficial. I would like to suggest first off that we should design and implement the scwm documentation extraction system with the intention of it being eventually incorporated in Guile, perhaps with some changes. Here are some things I think are important for this goal: * Implementation language: the final version of the document extractor should be written in Guile. Scwm could ship with a perl script without _too_ much embarassment, but it would probably be a poor idea for Guile :-) * Output: We should, for now at least, output each of DocBook SGML, TexInfo, and an on-disk documentation string database. When we can generate TexInfo from DocBook, we can drop the second of these. I think DocBook is clearly becoming the de facto free software standard, and with good reason. TexInfo must be supported because it is still the GNU standard. And it would be nice for users to still be able to access documentation interactively from within an interpeter. * How to get at docstrings for functions written in C: I suggest that we try for a system where they are not kept in core straight off. We'll have to make _some_ kind of changes anyway to support docstrings for procedures written in C at all, anyway, so we may as well do it right. It's necessary to be a bit careful here and add some special flag to the procedure object to indicate wether it has an on-disk docstring, and if so, in which file. If we just always look things up by the symbol name, we will lose if the primitives get redefined, or if something else gets defined as a primitive. * Syntax in the source files: This is really two separate questions, namely how to specify documentation in C files, and how to do it in Scheme files. ** For C files, there are two alternatives that are, IMO, more or less equally acceptable. One is to use specially distinguished comments, the other is to add an extra string parameter to SCM_PROC which guile-snarf would ignore, but which the doc extractor would use for it's own purposes. Jim Blandy seemed suspcious of the concept of looking through the comments; however, I'm not sure it is that bad. It's certainly more expandable to documenting concepts and specially distinguished variables, and not just procedures. ** For Scheme files, we could use either the existing docstring mechanism or use comments. Given Jim's comments, I'd suggest we just go for regular docstrings, since that is the syntax we'll want to use eventually. One possibility is to never worry about docstrings in Scheme files, and just make sure that the compiler generates the right thing for the doc extractor, when it is sufficiently mature to use regularly on all installed Scheme files. * Markup: We may want extra markup in the docs in addition to the presumably automatically generated function signature. If this is ever supported, I suggest we use DocBook tags, as opposed to TexInfo or worse yet, something ad-hoc. It seems to me that DocBook->TexInfo is likely to be the easier translation, and if there's ever a DocBook system tht generates texi automatically, we won't have to worry about it ourselves at all. Comments, anyone? - Maciej From owner-scwm-discuss@mit.edu Fri Jul 10 10:01:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA28722 for scwm-discuss-outgoing; Fri, 10 Jul 1998 10:01:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA28716; Fri, 10 Jul 1998 10:01:28 -0400 Message-Id: <199807101401.KAA28716@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Cool other-proc use. In-reply-to: Your message of "09 Jul 1998 18:45:47 +0300." Date: Fri, 10 Jul 1998 10:01:28 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > I fixed it with scwm as follows: > > (define (stack-windows . w) > (display "stacking...\n") > (let* ((size (apply window-size w)) > (desired-lr (map inexact->exact > (map * '(.6 .6) (display-size)))) > (needed-tl (map - desired-lr size))) > (apply move-to (append needed-tl w)))) > > (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) > That's really cool. I never even thought of the possibility of using #:other-proc to get the effect of placement functions. I think my work on placement procedures will still be useful, though, because it will clean up the currently very messy placement code, and give easy user-controllable access to the different fvwm-inherited placement algorithms currently controlled only by a bunch of weird options. > The stack-windows procedure places the specified window (or the > current if none is specified) with it's lower right-hand corner at the > point (map * '(.6 .6) (display-size)). > > Now I can quickly click through all those stupid cancel windows. > > To go one better, is there any way to move the mouse over to the > cancel button & click it? Would I have to guess the correct location > to move the mouse, or is there a better way to find it? > Well, if netscape is at all reasonably designed, calling close-window should have the same effect as clicking Cancel. If you really never want to see these dialogs, so if you're feeling brave, you could do (window-style "Netscape: Question" #:other-proc close-window) and never even see those dialogs. - Maciej From owner-scwm-discuss@mit.edu Fri Jul 10 10:54:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA29381 for scwm-discuss-outgoing; Fri, 10 Jul 1998 10:54:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA29376; Fri, 10 Jul 1998 10:54:12 -0400 Message-Id: <199807101454.KAA29376@huis-clos.mit.edu> To: Stephen Tell cc: scwm-discuss@mit.edu Subject: Re: scwm 0.7a on HP-UX 10.20 - problems overcome, patches enclosed In-reply-to: Your message of "Fri, 10 Jul 1998 02:01:52 EDT." Date: Fri, 10 Jul 1998 10:54:12 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk tell@cs.unc.edu writes: > > > Moving on to "make": while linking scwm, I got these undefined symbols: > scwm_internal_select (code) > setlinebuf (code) > > setlinebuf doesn't exist on HP-UX; it has setbuf and setvbuf only. > > Checking some man pages and old manuals: > > - 4.3 BSD has setbuf, setbuffer, setlinebuf. > "setbuffer and setlinebuf are not portable to non 4.2BSD systems" > > > - Western Electric Unix 5.0 (early SYSV, I think) has setbuf only, with no > way to explicitly set line-buffering. It adds that "output streams > directed to terminals are always line-buffered unless they are > unbuffered." > > - Linux with libc6 (glibc2) has the whole lot of them: setvbuf, setbuffer, > setlinebuf, setvbuf > > setvbuf is the most general routine, I think. > > Suggested strategy: > check for setvbuf, use it if it exists. > else check for setlinebuf, use it if it exists. > else setbuf(NULL) to get no buffering at all. > (One could argue for checking for setlinebuf first.) > I agree completely, we should be careful about non-portable functions. > (as an aside, I'd love to be able to buy a book that described these sorts > of unix variances across all functions commonly found in libc and > elsewhere. I suppose in an ideal world autoconf would already know about > all of them...) > There's O'Reilley's "Porting UNIX Software", but unfortunately that doesn't cover everything. > I changed scwm.c, config.h.in, and configure.in to implement this; patches > below. > > As for scwm_internal_select, I'm pretty sure its a typo in a "#ifdef > _hpux" in events.c. The obvious one-character patch is below. I got type > mismatch warnings while compiling that; I think that the ifdef with its > casts may not be correct for HP-UX 10.20. > I will remove the #ifdef; it's wrong to use system checks than feature checks, but I was waiting for someone to compile on HPUX and tell me wether those casts even make sense. > Anyway, after all that, I got scwm compiled and running. > Cool. - Maciej > > context diffs: > (I'm new at autoconf; I think this is right but corrections are welcome) > Looks good to me. I rearranged this somewhat, but the fixes in general should be in tomorrow's snapshot. > *** configure.in.orig Sat Jun 27 22:37:56 1998 > --- configure.in Fri Jul 10 00:02:27 1998 > *************** > *** 188,193 **** > --- 188,194 ---- > AC_CHECK_FUNCS(gethostname waitpid sysconf uname) > AC_CHECK_FUNCS(strerror strcasecmp strncasecmp) > AC_CHECK_FUNC(usleep, AC_DEFINE(HAVE_USLEEP)) > + AC_CHECK_FUNC(setvbuf, AC_DEFINE(HAVE_SETVBUF), AC_CHECK_FUNCS(setlinebuf)) > > dnl # Check for bleeding-edge guile funcs > > *** config.h.in.orig Sat Jun 27 22:39:02 1998 > --- config.h.in Fri Jul 10 00:05:54 1998 > *************** > *** 103,108 **** > --- 103,111 ---- For future reference, acconfig.h is the right place to add the #undefs to. From owner-scwm-discuss@mit.edu Fri Jul 10 11:13:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29708 for scwm-discuss-outgoing; Fri, 10 Jul 1998 11:13:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29705 for ; Fri, 10 Jul 1998 11:13:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24256; Fri, 10 Jul 98 11:12:43 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA04952; Fri, 10 Jul 1998 08:12:30 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Autogenerated files References: From: Greg Badros Date: 10 Jul 1998 08:12:30 -0700 In-Reply-To: Robert Bihlmeyer's message of "10 Jul 1998 13:56:40 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 09 Jul 1998 09:43:01 -0700 > >>>>> Greg Badros said: > > Greg> CVS does permit a script to be run on checout -- perhaps we > Greg> should make autogen.sh get run automatically -- > > Seems like a nice idea. I'll add it in sometime soon. Greg From owner-scwm-discuss@mit.edu Fri Jul 10 11:26:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29901 for scwm-discuss-outgoing; Fri, 10 Jul 1998 11:26:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA29898 for ; Fri, 10 Jul 1998 11:26:56 -0400 Received: by tis.bellhow.com; id LAA05204; Fri, 10 Jul 1998 11:26:26 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005170; Fri, 10 Jul 98 11:25:52 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA15817 for ; Fri, 10 Jul 1998 11:25:51 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: scwm.el and 19980710 snapshot Date: Fri, 10 Jul 1998 15:22:26 GMT Organization: Bell & Howell PSC Message-ID: <35a730ba.89158362@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA29899 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The first `unless' in scwm.el should be `or'. You can't really use unless to see if you need to load unless. :) Dale --- ./src/scwm-19980710/utilities/emacs/scwm.el Thu Jul 9 13:06:11 1998 +++ ./share/emacs/site-lisp/scwm.el Fri Jul 10 10:57:52 1998 @@ -76,7 +76,7 @@ ;; Type M-TAB to complete symbol at point. (eval-and-compile - (unless (and (fboundp 'cadr) (fboundp 'unless)) (require 'cl)) + (or (and (fboundp 'cadr) (fboundp 'unless)) (require 'cl)) (or (fboundp 'apropos-mode) (autoload 'apropos-mode "apropos")) (unless (fboundp 'with-output-to-string) (defmacro with-output-to-string (&rest body) -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Fri Jul 10 11:53:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30245 for scwm-discuss-outgoing; Fri, 10 Jul 1998 11:53:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30242 for ; Fri, 10 Jul 1998 11:53:26 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA22249; Fri, 10 Jul 98 11:53:08 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id LAA10170; Fri, 10 Jul 1998 11:52:53 -0400 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 10 Jul 1998 11:52:52 -0400 In-Reply-To: Maciej Stachowiak's message of Fri, 10 Jul 1998 09:54:51 EDT Message-Id: Lines: 73 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I would like to suggest first off that we should design and implement > the scwm documentation extraction system with the intention of it > being eventually incorporated in Guile, perhaps with some changes. Exactly. This is a problem that all Guile users will face, so if we can solve it thoroughly, that's a big win. I agree that we should implement the extractor in Guile. It may be slow at first, but speeding up Guile's I/O is on the list, and I'd like to have some actual text-processing applications to test my changes. > * Output: We should, for now at least, output each of DocBook SGML, > TexInfo, and an on-disk documentation string database. Sounds reasonable. > * How to get at docstrings for functions written in C: I suggest that > we try for a system where they are not kept in core straight off. Emacs does this. Docstrings are included as an argument to a macro which drops them when generating normal Emacs code. Then there's another function which scans the source code for these macros and extracts the docstrings into a file, labeled with the function name. I seem to remember long-standing bugs or FAQ's about this process; the installation procedure wasn't quite right, and the docstring files were always out of date with respect to the executable. I haven't thought about this at all, but if all Guile users are going to follow this procedure, we should look for something foolproof. > ** For C files, there are two alternatives that are, IMO, more or less > equally acceptable. One is to use specially distinguished comments, > the other is to add an extra string parameter to SCM_PROC which > guile-snarf would ignore, but which the doc extractor would use for > it's own purposes. Jim Blandy seemed suspcious of the concept of > looking through the comments; however, I'm not sure it is that > bad. It's certainly more expandable to documenting concepts and > specially distinguished variables, and not just procedures. I'm not so suspicious of it; I've done similar things before. However, you can't make comments conditional on configure-generated #defines, so your extracted docstrings may not always correspond to the source that got compiled. Something that operates post-CPP wouldn't have this problem. Note that, contrary to Knuth's claims, you can't generate decent internals documentation by extracting stuff from the source. Source code and manuals are laid out differently. This system is only going to be providing point documentation, not a full manual. That is, the FSF does the right thing in providing *both* docstrings and a full Emacs Lisp manual, and having them be separate. A manual entry knows a lot more about its context than a docstring does, so the best docstrings rely little on context, while the best manuals have overview sections, explanations of common concepts, and then function descriptions which operate in that context. > * Markup: We may want extra markup in the docs in addition to the > presumably automatically generated function signature. If this is ever > supported, I suggest we use DocBook tags, as opposed to TexInfo or > worse yet, something ad-hoc. It seems to me that DocBook->TexInfo is > likely to be the easier translation, and if there's ever a DocBook > system tht generates texi automatically, we won't have to worry about > it ourselves at all. DocBook is fine, but we'll need to specify which tags we allow in docstrings, right? I'm familiar with the general idea of SGML, DTD's, style sheets, and DocBook, but I don't know the details. From owner-scwm-discuss@mit.edu Fri Jul 10 12:35:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30471 for scwm-discuss-outgoing; Fri, 10 Jul 1998 12:35:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30468 for ; Fri, 10 Jul 1998 12:35:31 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14864; Fri, 10 Jul 98 12:34:57 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA05016; Fri, 10 Jul 1998 09:34:50 -0700 (PDT) To: Jim Blandy Cc: Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Greg Badros Date: 10 Jul 1998 09:34:49 -0700 In-Reply-To: Jim Blandy's message of "10 Jul 1998 11:52:52 -0400" Message-Id: Lines: 139 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > I would like to suggest first off that we should design and implement > > the scwm documentation extraction system with the intention of it > > being eventually incorporated in Guile, perhaps with some changes. > > Exactly. This is a problem that all Guile users will face, so if we > can solve it thoroughly, that's a big win. > > I agree that we should implement the extractor in Guile. It may be > slow at first, but speeding up Guile's I/O is on the list, and I'd > like to have some actual text-processing applications to test my > changes. I agree, but to the extent that I work on a prototype system, the initial versions will probably be in perl. After things are stable, I can rewrite in guile. (Partially a chick & egg problem -- guile's documentation is still sparse enough that I find it difficult to learn about aspects which I haven't used before). > > * Output: We should, for now at least, output each of DocBook SGML, > > TexInfo, and an on-disk documentation string database. > > Sounds reasonable. Ditto. > > * How to get at docstrings for functions written in C: I suggest that > > we try for a system where they are not kept in core straight off. > > Emacs does this. Docstrings are included as an argument to a macro > which drops them when generating normal Emacs code. Then there's > another function which scans the source code for these macros and > extracts the docstrings into a file, labeled with the function name. > > I seem to remember long-standing bugs or FAQ's about this process; the > installation procedure wasn't quite right, and the docstring files > were always out of date with respect to the executable. I haven't > thought about this at all, but if all Guile users are going to follow > this procedure, we should look for something foolproof. > > > ** For C files, there are two alternatives that are, IMO, more or less > > equally acceptable. One is to use specially distinguished comments, > > the other is to add an extra string parameter to SCM_PROC which > > guile-snarf would ignore, but which the doc extractor would use for > > it's own purposes. Jim Blandy seemed suspcious of the concept of > > looking through the comments; however, I'm not sure it is that > > bad. It's certainly more expandable to documenting concepts and > > specially distinguished variables, and not just procedures. > > I'm not so suspicious of it; I've done similar things before. > However, you can't make comments conditional on configure-generated > #defines, so your extracted docstrings may not always correspond to > the source that got compiled. Something that operates post-CPP > wouldn't have this problem. I hadn't thought of the CPP issue before (ironic, since some of my research in the past couple of years has related to it). In any case, we could run the preprocessor w/o the SCWM_PROC macro defined and w/o discarding comments and use that as the source if we really cared. I like comments as comments instead of strings, and it'd be a bit annoying to have to deal with the \n\ at the end of each comment line (though I'm sure an emacs command to reformat doc strings would be easy enough). > Note that, contrary to Knuth's claims, you can't generate decent > internals documentation by extracting stuff from the source. Source > code and manuals are laid out differently. This system is only going > to be providing point documentation, not a full manual. One of the things I am going for, though, is the ability to embed concept documentation in the source, too. E.g., the key-specifier form in SCWM is determined by a single C support procedure of the key-binding and unbinding primitives. I'd like comments near that support procedure to be woven into a section on the appropriate form for a key-specifier, and have the related primitives reference that section. > That is, the FSF does the right thing in providing *both* docstrings > and a full Emacs Lisp manual, and having them be separate. A manual > entry knows a lot more about its context than a docstring does, so the > best docstrings rely little on context, while the best manuals have > overview sections, explanations of common concepts, and then function > descriptions which operate in that context. Some of the "concept" sections extracted from the source would be appropriate for a manual, IMHO. Tight coupling of documentation and the code that it documents is essential to keep them in sync. > > * Markup: We may want extra markup in the docs in addition to the > > presumably automatically generated function signature. If this is ever > > supported, I suggest we use DocBook tags, as opposed to TexInfo or > > worse yet, something ad-hoc. It seems to me that DocBook->TexInfo is > > likely to be the easier translation, and if there's ever a DocBook > > system tht generates texi automatically, we won't have to worry about > > it ourselves at all. > > DocBook is fine, but we'll need to specify which tags we allow in > docstrings, right? I'm familiar with the general idea of SGML, DTD's, > style sheets, and DocBook, but I don't know the details. I'd like the documentation to be as easy and unobtrusive to write as possible, and would prefer to use conventions (yes, ad hoc conventions) for much of the markup. e.g., my current system scans the argument list of the procedure and determines the formal names. Then, any time a formal name appears in the comment in all uppercase, it can be marked as a formal. I think: SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, (SCM contexts, SCM key)) /** Remove any bindings attached to KEY in given CONTEXTS. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete) */ Is a lot easier to write and read (in the source code) than: SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, (SCM contexts, SCM key)) /** Remove any bindings attached to KEY in given CONTEXTS. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete) */ I'm exaggerating a bit, but I'd like the extraction system to have a certain degree of "smarts" from some simple conventions for the standard cases. Beyond that, a well-defined subset of DocBook tags could be used for the less common cases. In particular, we'll need cross-referencing. We need to get the big decisions right about what the markup should look like in the source code, but once we do, we need to start documenting and we can deal with the extraction tools iteratively. The current sparse docs are way too limiting. Greg From owner-scwm-discuss@mit.edu Fri Jul 10 12:55:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30649 for scwm-discuss-outgoing; Fri, 10 Jul 1998 12:55:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30646 for ; Fri, 10 Jul 1998 12:55:41 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA19040; Fri, 10 Jul 98 12:55:04 EDT Received: (qmail 15920 invoked by uid 11105); 10 Jul 1998 16:54:57 -0000 To: Jim Blandy Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 10 Jul 1998 09:54:57 -0700 In-Reply-To: Jim Blandy's message of "10 Jul 1998 11:52:52 -0400" Message-Id: Lines: 11 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "JB" == Jim Blandy writes: JB> I agree that we should implement the extractor in Guile. It may JB> be slow at first, but speeding up Guile's I/O is on the list, and JB> I'd like to have some actual text-processing applications to test JB> my changes. If the idea is to kill two birds with one stone, then write the extractor in elisp. My understanding was that integrating Guile with Emacs was a fairly fundamental goal. ;-) From owner-scwm-discuss@mit.edu Fri Jul 10 12:57:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30687 for scwm-discuss-outgoing; Fri, 10 Jul 1998 12:57:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30684 for ; Fri, 10 Jul 1998 12:57:51 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19520; Fri, 10 Jul 98 12:57:17 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA05035; Fri, 10 Jul 1998 09:57:16 -0700 (PDT) To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: Jim Blandy , Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Greg Badros Date: 10 Jul 1998 09:57:15 -0700 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of "10 Jul 1998 09:54:57 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes: > >>>>> "JB" == Jim Blandy writes: > > JB> I agree that we should implement the extractor in Guile. It may > JB> be slow at first, but speeding up Guile's I/O is on the list, and > JB> I'd like to have some actual text-processing applications to test > JB> my changes. > > If the idea is to kill two birds with one stone, then write the > extractor in elisp. My understanding was that integrating Guile with > Emacs was a fairly fundamental goal. ;-) Except you shouldn't need to have emacs installed to be able to build documentation for scwm or guile. Some (crazy! :-) ) people still are using vi! :-) Greg From owner-scwm-discuss@mit.edu Fri Jul 10 13:26:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31221 for scwm-discuss-outgoing; Fri, 10 Jul 1998 13:26:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31218 for ; Fri, 10 Jul 1998 13:26:09 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA25664; Fri, 10 Jul 98 13:25:36 EDT Received: (qmail 16082 invoked by uid 11105); 10 Jul 1998 17:25:38 -0000 To: Greg Badros Cc: Jim Blandy , Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 10 Jul 1998 10:25:38 -0700 In-Reply-To: Greg Badros's message of "10 Jul 1998 09:57:15 -0700" Message-Id: Lines: 8 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "GB" == Greg Badros writes: GB> Except you shouldn't need to have emacs installed to be able to GB> build documentation for scwm or guile. Some (crazy! :-) ) people GB> still are using vi! :-) Most GNU packages come with .info files preformatted, so that makeinfo isn't needed. From owner-scwm-discuss@mit.edu Fri Jul 10 18:09:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA00132 for scwm-discuss-outgoing; Fri, 10 Jul 1998 18:09:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA00126 for ; Fri, 10 Jul 1998 18:09:00 -0400 Received: from wugate.wustl.edu by MIT.EDU with SMTP id AA01130; Fri, 10 Jul 98 18:08:39 EDT Received: from hubert.wuh.wustl.edu (ats@nb22-pool-16.wustl.edu [128.252.113.16]) by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id RAA28792; Fri, 10 Jul 1998 17:08:14 -0500 (CDT) Received: (from ats@localhost) by hubert.wuh.wustl.edu (8.8.7/8.8.7) id RAA07215; Fri, 10 Jul 1998 17:07:57 -0500 To: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Alan Shutko Date: 10 Jul 1998 17:07:56 -0500 In-Reply-To: Jim Blandy's message of "10 Jul 1998 11:52:52 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "J" == Jim Blandy writes: J> I seem to remember long-standing bugs or FAQ's about this process; J> the installation procedure wasn't quite right, and the docstring J> files were always out of date with respect to the executable. I J> haven't thought about this at all, but if all Guile users are going J> to follow this procedure, we should look for something foolproof. The emacs installation didn't have a problem, iirc, but sometimes Linux distributions did. The problem arises if you have a DOC file that wasn't created at the same time the emacs was. For example, if you have separate tar files with the Emacs binary and Emacs data directories. It's easy in this case for one to be updated without the other. The solution was just to rebuild and reinstall emacs. -- Alan Shutko - By consent of the corrupted Because the wine remembers. From owner-scwm-discuss@mit.edu Fri Jul 10 19:09:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA00546 for scwm-discuss-outgoing; Fri, 10 Jul 1998 19:09:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA00543 for ; Fri, 10 Jul 1998 19:09:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09054; Fri, 10 Jul 98 19:08:53 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA24194; Fri, 10 Jul 1998 16:08:48 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: DeferExecution click lossage bug & repair-hack. References: From: Greg Badros Date: 10 Jul 1998 16:08:48 -0700 In-Reply-To: hjstein@bfr.co.il's message of "10 Jul 1998 00:56:07 +0300" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I guess one fix would be to check for eventp->type == FinishEvent > again after the 2nd call to XMaskEvent, but it's not at all clear to > me why the 2nd call to XMaskEvent should even be made when fFinished > is True. Why is it grabbing another event if we already found the > event we wanted? I'd think it should just keep grabbing & dispatching > events until it finds the FinishEvent - I don't see why there should > be 2 XMaskEvent calls in the loop. > > Can anyone shed some light on this? I just did a fairly minimal fix to DeferExecution in the hopes of at least eliminating the obvious bugs. I still think the code should be revisited and (get-window) should perhaps do something a bit different than my (select-window-interactively) [still unwritten]. In particular the former should respect from what context the command was invoked, if possible, whereas the latter should always select interactively. Please let me know if the next snapshot makes things better or worse. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Jul 10 19:22:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA00677 for scwm-discuss-outgoing; Fri, 10 Jul 1998 19:22:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA00674 for ; Fri, 10 Jul 1998 19:22:33 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA11046; Fri, 10 Jul 98 19:22:11 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA11000; Fri, 10 Jul 1998 19:21:55 -0400 To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: Jim Blandy , Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 10 Jul 1998 19:21:53 -0400 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of 10 Jul 1998 09:54:57 -0700 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > If the idea is to kill two birds with one stone, then write the > extractor in elisp. My understanding was that integrating Guile with > Emacs was a fairly fundamental goal. ;-) We want to use these doc conventions in Guile itself. The Guile distribution shouldn't depend on Emacs. From owner-scwm-discuss@mit.edu Fri Jul 10 19:24:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA00713 for scwm-discuss-outgoing; Fri, 10 Jul 1998 19:24:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA00710 for ; Fri, 10 Jul 1998 19:24:24 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA11232; Fri, 10 Jul 98 19:24:02 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA11005; Fri, 10 Jul 1998 19:23:39 -0400 To: Alan Shutko Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 10 Jul 1998 19:23:38 -0400 In-Reply-To: Alan Shutko's message of 10 Jul 1998 17:07:56 -0500 Message-Id: Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > The emacs installation didn't have a problem, iirc, but sometimes Linux > distributions did. The problem arises if you have a DOC file that > wasn't created at the same time the emacs was. For example, if you > have separate tar files with the Emacs binary and Emacs data > directories. It's easy in this case for one to be updated without the > other. The solution was just to rebuild and reinstall emacs. No, I'm pretty sure we had problems before Linux even existed. I don't know. It's just a vague memory. We need to think this through carefully. From owner-scwm-discuss@mit.edu Fri Jul 10 19:48:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA00905 for scwm-discuss-outgoing; Fri, 10 Jul 1998 19:48:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA00902 for ; Fri, 10 Jul 1998 19:48:34 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA13904; Fri, 10 Jul 98 19:48:12 EDT Received: (qmail 17893 invoked by uid 11105); 10 Jul 1998 23:48:00 -0000 To: Jim Blandy Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 10 Jul 1998 16:48:00 -0700 In-Reply-To: Jim Blandy's message of "10 Jul 1998 19:21:53 -0400" Message-Id: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "JB" == Jim Blandy writes: JB> We want to use these doc conventions in Guile itself. The Guile JB> distribution shouldn't depend on Emacs. guile-doc depends on automake and makeinfo to make this happen: .texi.info: @cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9] cd $(srcdir) \ && $(MAKEINFO) `echo $< | sed 's,.*/,,'` From owner-scwm-discuss@mit.edu Sat Jul 11 08:11:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA04453 for scwm-discuss-outgoing; Sat, 11 Jul 1998 08:11:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA04450 for ; Sat, 11 Jul 1998 08:11:33 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id OAA06977 for scwm-discuss@huis-clos.mit.edu; Sat, 11 Jul 1998 14:10:54 +0200 (CEST) Received: (qmail 1779 invoked by uid 115); 11 Jul 1998 11:14:15 -0000 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 11 Jul 1998 13:14:13 +0200 In-Reply-To: Greg Badros's message of "10 Jul 1998 09:34:49 -0700" Message-ID: Lines: 39 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 10 Jul 1998 09:34:49 -0700 >>>>> Greg Badros said: Greg> I'd like the documentation to be as easy and unobtrusive to Greg> write as possible, and would prefer to use conventions (yes, ad Greg> hoc conventions) for much of the markup. e.g., my current Greg> system scans the argument list of the procedure and determines Greg> the formal names. Then, any time a formal name appears in the Greg> comment in all uppercase, it can be marked as a formal. This it can and should do. But there are things, where human markup inside docstrings is still useful. E.g. in your example: Greg> SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, Greg> (SCM contexts, SCM key)) Greg> /** Remove any bindings attached to KEY in given CONTEXTS. Greg> CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) Greg> KEY is a string giving the key-specifier (e.g., M-Delete for Greg> META+Delete) */ It would be nice to format example code ("'(button1 sidebar)") different (tradition suggests courier). This is hard to do automatically, so something like [...] of event contexts (e.g. '(button1 sidebar)) [...] should be allowed. You must of course handle this for non-sgml-output (texi & external docstrings). We must also think about the "&"-stuff. Should it be fully supported? Or only "&", and "<" (this is the minimum)? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Jul 11 13:44:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05933 for scwm-discuss-outgoing; Sat, 11 Jul 1998 13:44:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05930 for ; Sat, 11 Jul 1998 13:44:30 -0400 Received: from sapphire.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA16897; Sat, 11 Jul 98 13:43:44 EDT Received: (from esuci@localhost) by sapphire.dcs.warwick.ac.uk (8.8.8/8.8.8) id SAA04089; Sat, 11 Jul 1998 18:43:47 +0100 (BST) Message-Id: <19980711184345.39968@dcs.warwick.ac.uk> Date: Sat, 11 Jul 1998 18:43:45 +0100 From: Michael Stevens To: scwm-discuss@mit.edu Subject: install problems - scwm 0.7a Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi. I've almost successfully installed scwm 0.7a with guile 1.2, but get the following errors on stderr when I try to start it: Backtrace: 0* (define BLACK (make-color "black")) 1* [define (define BLACK (make-color "black")) (#)] 2* (make-color "black") ERROR: In expression (make-color "black"): ERROR: Unbound variable: make-color Backtrace: 0* (define GRAY (make-color "gray")) 1* [define (define GRAY (make-color "gray")) (#)] 2* (make-color "gray") ERROR: In expression (make-color "gray"): ERROR: Unbound variable: make-color Backtrace: 0* (define SLATEGRAY (make-color "slategray")) 1* [define (define SLATEGRAY (make-color "slategray")) (#)] 2* (make-color "slategray") ERROR: In expression (make-color "slategray"): ERROR: Unbound variable: make-color Backtrace: 0* (set-menu-foreground! BLACK) ERROR: In expression (set-menu-foreground! BLACK): ERROR: Unbound variable: set-menu-foreground! Backtrace: 0* (set-menu-background! GRAY) ERROR: In expression (set-menu-background! GRAY): ERROR: Unbound variable: set-menu-background! Backtrace: 0* (set-menu-stipple! SLATEGRAY) ERROR: In expression (set-menu-stipple! SLATEGRAY): ERROR: Unbound variable: set-menu-stipple! Backtrace: 0* (set-hilight-foreground! BLACK) ERROR: In expression (set-hilight-foreground! BLACK): ERROR: Unbound variable: set-hilight-foreground! Backtrace: 0* (set-hilight-background! GRAY) ERROR: In expression (set-hilight-background! GRAY): ERROR: Unbound variable: set-hilight-background! Backtrace: 0* (let ((home-scwmrc #) (system-scwmrc "/local/newwords/usr/michael/lib/X11/scwm/system.scwmrc")) (if (access? home-scwmrc R_OK) (safe-load home-scwmrc) ...)) 1 (if (access? home-scwmrc R_OK) (safe-load home-scwmrc) ...) ... 2 (safe-load system-scwmrc) ERROR: In expression (safe-load system-scwmrc): ERROR: Unbound variable: safe-load It doesn't seem to make a difference whether I have a .scwmrc file in my home directory or not. -- Down, not across. From owner-scwm-discuss@mit.edu Sat Jul 11 21:28:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08504 for scwm-discuss-outgoing; Sat, 11 Jul 1998 21:28:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08495; Sat, 11 Jul 1998 21:28:12 -0400 Message-Id: <199807120128.VAA08495@huis-clos.mit.edu> To: Michael Stevens cc: scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a In-reply-to: Your message of "Sat, 11 Jul 1998 18:43:45 BST." <19980711184345.39968@dcs.warwick.ac.uk> Date: Sat, 11 Jul 1998 21:28:12 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk michael@rmta.org writes: > Hi. > I've almost successfully installed scwm 0.7a with guile 1.2, but get the > following errors on stderr when I try to start it: > [errors snipped] This looks like there was a problem of some kind during the build. The make-color primitive appears not to have been defined. It may help to `make clean' and rebuild. Also, you may want to check if there is a file `color.x' in the scwm directory of the scwm distribution. It seems that this file may not have been generated; it should be generated automatically as part of the build process. - Maciej From owner-scwm-discuss@mit.edu Sat Jul 11 21:58:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08925 for scwm-discuss-outgoing; Sat, 11 Jul 1998 21:58:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA08922 for ; Sat, 11 Jul 1998 21:58:21 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA18258; Sat, 11 Jul 98 21:57:33 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08917; Sat, 11 Jul 1998 21:58:19 -0400 Message-Id: <199807120158.VAA08917@huis-clos.mit.edu> To: Jim Blandy Cc: Greg Badros , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions In-Reply-To: Your message of "10 Jul 1998 11:52:52 EDT." Date: Sat, 11 Jul 1998 21:58:19 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > Note that, contrary to Knuth's claims, you can't generate decent > internals documentation by extracting stuff from the source. Source > code and manuals are laid out differently. This system is only going > to be providing point documentation, not a full manual. > > That is, the FSF does the right thing in providing *both* docstrings > and a full Emacs Lisp manual, and having them be separate. A manual > entry knows a lot more about its context than a docstring does, so the > best docstrings rely little on context, while the best manuals have > overview sections, explanations of common concepts, and then function > descriptions which operate in that context. > I think the goal is to provide something more like a reference manual than either a user manual or internals documentation. Whatever else the documentation contains, it should certainly provide documentation of each exported procedure, it's arguments, and a description something like an over-detailed docstring. If this information is organized conceptually, i.e. by file boundaries; has documentation of broader concepts that apply to many different primitives or to the program as a whole; documents distinguished variables; and allows for cross-references from each procedure's documentation to related procedures and concepts; then you have a start on a very good reference manual. And these are all things I envision for the doc-extraction system. A user manual is still necessary, of course. You can't learn how to use a program with just a reference manual (or at least you shouldn't have to). Also, it may be necessary to impose some kind of hierarchical structure externally to even have a good reference manual. Another potential problem is how to provide the concept documentation interactively from within the program. Perhaps an eventual `concept-documentation' procedure similar to `procedure-documentation' would be useful. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sun Jul 12 19:02:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA16232 for scwm-discuss-outgoing; Sun, 12 Jul 1998 19:02:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA16229 for ; Sun, 12 Jul 1998 19:02:42 -0400 Received: from whelk.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA15742; Sun, 12 Jul 98 19:01:59 EDT Received: (from esuci@localhost) by whelk.dcs.warwick.ac.uk (8.8.8/8.8.8) id AAA05266; Mon, 13 Jul 1998 00:01:39 +0100 (BST) Message-Id: <19980713000134.03664@dcs.warwick.ac.uk> Date: Mon, 13 Jul 1998 00:01:34 +0100 From: Michael Stevens To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a References: <19980711184345.39968@dcs.warwick.ac.uk> <199807120128.VAA08495@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199807120128.VAA08495@huis-clos.mit.edu>; from Maciej Stachowiak on Sat, Jul 11, 1998 at 09:28:12PM -0400 X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sat, Jul 11, 1998 at 09:28:12PM -0400, Maciej Stachowiak wrote: > > michael@rmta.org writes: > > Hi. > > I've almost successfully installed scwm 0.7a with guile 1.2, but get the > > following errors on stderr when I try to start it: > [errors snipped] > This looks like there was a problem of some kind during the build. The > make-color primitive appears not to have been defined. It may help to > `make clean' and rebuild. Also, you may want to check if there is a > file `color.x' in the scwm directory of the scwm distribution. It > seems that this file may not have been generated; it should be > generated automatically as part of the build process. Hi. I found color.x - I now have a successfully built scwm (I deleted the source tree and started again). However, in the process, I seem to have broken something else: 13* [# # # ...] 14 [regexp-substitute/global # "\\\\\\*|\\\\\\?" ...] ... 15 [# "XTerm"] 16 (let ((match #)) (if (not match) (display str port) ...)) 17* [regexp-exec # "XTerm"] 18* [gsubr-apply #> # ...] ERROR: In procedure gsubr-apply in expression (regexp-exec rx str): ERROR: Memory allocation error scwm has started, but it is currently using 157mb of memory: 4189 esuci 1 34 0 157M 15M run 0:31 1.57% scwm I seem to have managed to trigger a memory leak or loop somehow - sometimes scwm will not start and sometimes it will - when it does, errors of that form are common. I'm using Solaris 2.6. gcc 2.8.1, guile 1.2. The window manager is being run on a Sparc 5 with 32mb of ram and about 180mb of swap. To build scwm, I had to point scwmrepl at locally installed libreadline ( the systemwide one is good enough to pass the checks, but is apparently not quite right - the latest version from prep.ai.mit.edu seems to work), a locally installed -lXpm (also, scwm didn't seem to be including -lXpm when linking itself, despite having a dependency on Xpm), and have had problems with the scwm binary not being able to find libguile due to the guile lib directory not being in the runtime search path. When building scwm, I have errors of the form: callbacks.c: In function `scm_internal_stack_cwdr': callbacks.c:118: warning: passing arg 2 of `scm_internal_catch' from incompatible pointer type callbacks.c: In function `scwm_safe_apply': callbacks.c:139: warning: passing arg 1 of `scm_internal_stack_cwdr' from incompatible pointer type for a number of functions. I'm beginning to suspect I'm screwing up something obvious, as I've never had this much trouble with scwm before... I've also been very impressed with the support for scwm available on this list - keep up the good work... (flattery will get you anywhere, but I actually _have_ been impressed...) -- Knock hard *here* for new monitor. From owner-scwm-discuss@mit.edu Sun Jul 12 23:19:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA17828 for scwm-discuss-outgoing; Sun, 12 Jul 1998 23:19:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA17825 for ; Sun, 12 Jul 1998 23:19:32 -0400 Received: from whelk.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA07271; Sun, 12 Jul 98 23:18:46 EDT Received: (from esuci@localhost) by whelk.dcs.warwick.ac.uk (8.8.8/8.8.8) id EAA05654; Mon, 13 Jul 1998 04:18:27 +0100 (BST) Message-Id: <19980713041825.07665@dcs.warwick.ac.uk> Date: Mon, 13 Jul 1998 04:18:25 +0100 From: Michael Stevens To: Maciej Stachowiak , Michael Stevens Cc: scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a References: <19980713000134.03664@dcs.warwick.ac.uk> <199807130255.WAA17670@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: <199807130255.WAA17670@huis-clos.mit.edu>; from Maciej Stachowiak on Sun, Jul 12, 1998 at 10:55:49PM -0400 X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sun, Jul 12, 1998 at 10:55:49PM -0400, Maciej Stachowiak wrote: Think I must have mistyped scwm-discuss somewhere - corrected in the cc. > > I seem to have managed to trigger a memory leak or loop somehow - sometimes > > scwm will not start and sometimes it will - when it does, errors of that > > form are common. > Hmm, scwm might accidentally be linking against librx if that is > installed anywhere, I seem to remember a problem of this sort popping > up long ago. Maybe someone else remembers more about it. ldd gives: libXext.so.0 => /usr/openwin/lib/libXext.so.0 libX11.so.4 => /usr/openwin/lib/libX11.so.4 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libguile.so.2 => /gnu/lib/libguile.so.2 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libXpm.so.4.11 => /usr/local/lib/libXpm.so.4.11 libc.so.1 => /usr/lib/libc.so.1 libmp.so.2 => /usr/lib/libmp.so.2 I see no librx here :) Don't think it's that... Although, librx _is_ in /gnu/lib, and I'm having to point scwm fairly forcefully in that direction to get things to build... > > I'm using Solaris 2.6. gcc 2.8.1, guile 1.2. The window manager is being run > > on a Sparc 5 with 32mb of ram and about 180mb of swap. > > > > To build scwm, I had to point scwmrepl at locally installed libreadline ( > > the systemwide one is good enough to pass the checks, but is apparently not > > quite right - the latest version from prep.ai.mit.edu seems to work), a > > locally installed -lXpm (also, scwm didn't seem to be including -lXpm when > > linking itself, despite having a dependency on Xpm), and have had problems > > with the scwm binary not being able to find libguile due to the guile lib > > directory not being in the runtime search path. > I guess these are configure problems. For libXpm, we should either > fail or actually check whether the lib was not found in the source and > not provide xpm support in that case. I'll try to fix it in one of > thse ways. If we could have a --with-xpm-prefix, I'd like that. Round here, there are lots of bits in different places that need to be put together - guile with one prefix, X libs with another, and Xpm with get another. > As for readline, I can't say because I don't really know how that code > works, but if you tell me what problems you are having with a version > of readline that passes the checks (missing functions at link time? > buggy output?) and what version it is, I may be able to take a look. Sorry. Wasn't clear. ./configure is satisfied with it as being the Right Thing, but actually attempting to compile scwmrepl fails with errors about redefinition of Function (amongst others, IIRC). I believe the new version is readline 2.2 - not sure what the old one is. > The runtime search path thing can be circumvented by setting > LD_LIBRARY_PATH, but I wonder why libtool is not giving a -rpath > argument on the link line. I'm puzzled. It's not a problem I've had before, and not one I had the first time I built _this_ version. > > When building scwm, I have errors of the form: > > callbacks.c: In function `scm_internal_stack_cwdr': > > callbacks.c:118: warning: passing arg 2 of `scm_internal_catch' from > > incompatible pointer type > > callbacks.c: In function `scwm_safe_apply': > > callbacks.c:139: warning: passing arg 1 of `scm_internal_stack_cwdr' from > > incompatible pointer type > > > > for a number of functions. > These warnings are not dangerous, they just indicate some missing but > unimportant casts that I should probably put in. Was unsure, because they seemed to correspond a little to functions that were dying at one point - I saw mention of 'safe-load' at one point, and I had a trace (the first one) that seemed to indicate to me that safe-load was dying or missing. > > I'm beginning to suspect I'm screwing up something obvious, as I've never > > had this much trouble with scwm before... > Probably not, I guess you just have a configuration that we have not > previously encountered and have not had a chance to iron out the bugs > for. It's interesting. I've built earlier versions with much less trouble. Something weird is breaking. > > I've also been very impressed with the support for scwm available on this > > list - keep up the good work... (flattery will get you anywhere, but I > > actually _have_ been impressed...) > Thanks. We do our best. Nothing improves a program like having users. :-) While we're mentioning it, how am I doing on trouble reports - I try to do a balanced amount of detail - is it good? -- "We've replaced this man's regular OS with Folgers Crystals... let's see if he notices." - David Waite (mass@ufl.edu) From owner-scwm-discuss@mit.edu Mon Jul 13 03:01:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA19565 for scwm-discuss-outgoing; Mon, 13 Jul 1998 03:01:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA19562 for ; Mon, 13 Jul 1998 03:01:49 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA27709; Mon, 13 Jul 98 03:01:03 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id AAA30875 for ; Mon, 13 Jul 1998 00:00:48 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276568-21476>; Sun, 12 Jul 1998 23:25:26 -0700 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-Reply-To: Robert Bihlmeyer's message of "11 Jul 1998 13:14:13 +0200." Date: Sun, 12 Jul 1998 23:25:10 -0600 From: Ken Pizzini Message-Id: <19980713062526Z276568-21476+2@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > [...] of event contexts (e.g. '(button1 sidebar)) [...] > > should be allowed. You must of course handle this for non-sgml-output > (texi & external docstrings). > > We must also think about the "&"-stuff. Should it be fully > supported? Or only "&", and "<" (this is the minimum)? I feel that the extractor should have some heuristics which allow for simpler input of the common structures via ad-hoc conventions, but passes through SGML markup unmolested. In particular, the extractor should allow any &xxx; markup that DocBook can handle in the docstrings. Actual _use_ of &xxx; notation should be kept down to the minimum required, to simplify arbitrary automated processing of the docstrings. But the extractor should not be an obstacle to some unanticipated use of a less-common &xxx;. --Ken Pizzini From owner-scwm-discuss@mit.edu Mon Jul 13 07:42:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA20966 for scwm-discuss-outgoing; Mon, 13 Jul 1998 07:42:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA20961 for ; Mon, 13 Jul 1998 07:41:56 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id NAA28075 for scwm-discuss@huis-clos.mit.edu; Mon, 13 Jul 1998 13:40:55 +0200 (CEST) Received: (qmail 355 invoked by uid 115); 13 Jul 1998 08:41:14 -0000 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <19980713062526Z276568-21476+2@pulsar.halcyon.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 13 Jul 1998 10:41:14 +0200 In-Reply-To: Ken Pizzini's message of "Sun, 12 Jul 1998 23:25:10 -0600" Message-ID: Lines: 64 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 12 Jul 1998 23:25:10 -0600 >>>>> Ken Pizzini said: Ken> I feel that the extractor should have some heuristics which Ken> allow for simpler input of the common structures via ad-hoc Ken> conventions, but passes through SGML markup unmolested. In Ken> particular, the extractor should allow any &xxx; markup that Ken> DocBook can handle in the docstrings. Ken> Actual _use_ of &xxx; notation should be kept down to the Ken> minimum required, to simplify arbitrary automated processing of Ken> the docstrings. But the extractor should not be an obstacle to Ken> some unanticipated use of a less-common &xxx;. Suppose that I want a literal "<" in my docstring. Since we want to pass through arbitrary tags to SGML, it has to be escaped. The logical choice is "<". You can get away with simply leaving it alone for SGML output. But the real problem are the other output formats (plain text, maybe texinfo). For them you'd have to map "<" back to "<". I think the Right Thing would be to support a minimal set ("&", and "<", anything else?), and document this. Other &xxx; sequences will work for SGML output only, so this has to be documented too, plus perhaps generate a warning if such a sequence is encountered. We have a quite similar situation for markup tags. There is certainly a rich variety - we may want to allow only a few, to prevent exeggerated markup of docstrings. Just for reference, DocBook 3.0[1] defines these tags for technicalities alone: A small subset may be useful, but "slide-desktop will move the given desktop x to the right, and y down. #t is returned, if the action was performed successfully, #f otherwise. We recommend binding this function to Shift-1 to avoid disaster." is certainly excessive. (No guarantees, that this even makes sense, I don't know DocBook at all.) Robbe [1] actually "-//Davenport//ELEMENTS DocBook Information Pool V3.0//EN" -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jul 13 07:42:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA20972 for scwm-discuss-outgoing; Mon, 13 Jul 1998 07:42:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA20965 for ; Mon, 13 Jul 1998 07:42:00 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id NAA28093 for scwm-discuss@huis-clos.mit.edu; Mon, 13 Jul 1998 13:40:59 +0200 (CEST) Received: (qmail 471 invoked by uid 115); 13 Jul 1998 09:14:56 -0000 To: scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a References: <19980713000134.03664@dcs.warwick.ac.uk> <199807130255.WAA17670@huis-clos.mit.edu> <19980713041825.07665@dcs.warwick.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 13 Jul 1998 11:14:55 +0200 In-Reply-To: Michael Stevens's message of "Mon, 13 Jul 1998 04:18:25 +0100" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" X-Now-Playing: Philip Glass - Facades Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 13 Jul 1998 04:18:25 +0100 >>>>> Michael Stevens said: Michael> If we could have a --with-xpm-prefix, I'd like that. Round Michael> here, there are lots of bits in different places that need Michael> to be put together - guile with one prefix, X libs with Michael> another, and Xpm with get another. Rather than adding a swath of --with-*-prefixes for guile, xpm, and whatnot, why not have an --with-additional-prefixes (or somesuch), that takes a list (colon-seperated) of prefixes, and tries them all in order for every library and other file we depend on? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Jul 13 12:28:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22495 for scwm-discuss-outgoing; Mon, 13 Jul 1998 12:28:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA22492 for ; Mon, 13 Jul 1998 12:28:05 -0400 Received: by tis.bellhow.com; id MAA17154; Mon, 13 Jul 1998 12:27:02 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma016939; Mon, 13 Jul 98 12:26:12 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA07177 for ; Mon, 13 Jul 1998 12:26:11 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: scwm.el bugs and additions Date: Mon, 13 Jul 1998 16:22:43 GMT Organization: Bell & Howell PSC Message-ID: <35aa3174.246114313@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_35aa345324684964101905799.MFSBCHJLHS" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ----=_35aa345324684964101905799.MFSBCHJLHS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Here is a patch (well, a diff -u) for scwm.el. =46ixes: 1. apropos-internal is being called with "*" as an argument, it should be= ".*" 2. completing-read is being called with two many arguments. At least = there are too many for emacs 19.33, I'm not sure about 20.x. Additions: I have added a command which I bind to C-h C-f. It finds and displays = the info documentation for the scheme procedure under the point. It's just = some hacked-up version of a similar routine that finds emacs commands. It = uses the guile-ref, r4rs, and (updated) scwm info files. I have also updated scwm.texi with more complete @node and @menu entries, along with more up-to-date (not-nearly-as-obsolete?) function = descriptions. If this patch is unreadable or something, I can ftp it somewhere. Dale --=20 Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ ----=_35aa345324684964101905799.MFSBCHJLHS Content-Type: application/octet-stream; name=scwm.el.diffs Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=scwm.el.diffs LS0tIC9ob21lL3VzZXJzMTAvc21pdGhkL3NoYXJlL2VtYWNzL3NpdGUtbGlzcC9zY3dtLmVsCU1v biBKdWwgMTMgMTI6MDM6MzggMTk5OAorKysgLi9zY3dtLmVsCU1vbiBKdWwgMTMgMTI6MTA6NTEg MTk5OApAQCAtMTI5LDYgKzEyOSw3IEBACiAoZGVmaW5lLWtleSBzY3dtLW1vZGUtbWFwIFsoY29u dHJvbCB4KSAoY29udHJvbCBqKV0gJ3Njd20tZXZhbC10by1taW5pYnVmZmVyKQogKGRlZmluZS1r ZXkgc2N3bS1tb2RlLW1hcCBbKGNvbnRyb2wgaCkgKGNvbnRyb2wgcyldICdzY3dtLWRvY3VtZW50 YXRpb24pCiAoZGVmaW5lLWtleSBzY3dtLW1vZGUtbWFwIFsoY29udHJvbCBoKSAoY29udHJvbCBh KV0gJ3Njd20tYXByb3BvcykKKyhkZWZpbmUta2V5IHNjd20tbW9kZS1tYXAgWyhjb250cm9sIGgp IChjb250cm9sIGYpXSAnc2N3bS1nb3RvLWd1aWxlLXByb2NlZHVyZS1ub2RlKQogKGRlZmluZS1r ZXkgc2N3bS1tb2RlLW1hcCBbKG1ldGEgdGFiKV0gJ3Njd20tY29tcGxldGUtc3ltYm9sLWluc2Vy dCkKIAogOzs7IyMjYXV0b2xvYWQKQEAgLTE4MSw3ICsxODIsNyBAQAogICAobGV0ICgob2JhcnJh eSAobWFrZS12ZWN0b3IgNjcgMCkpIChwb3MgMikKIAkodGIgKGdldC1idWZmZXItY3JlYXRlICIg KnNjd20tb2JhcnJheSoiKSkpCiAgICAgKHNldC1idWZmZXIgdGIpIChlcmFzZS1idWZmZXIpCi0g ICAgKHNjd20tZXZhbCAiKGFwcm9wb3MtaW50ZXJuYWwgXCIqXCIpIiB0YikKKyAgICAoc2N3bS1l dmFsICIoYXByb3Bvcy1pbnRlcm5hbCBcIi4qXCIpIiB0YikKICAgICAoZ290by1jaGFyIDEpCiAg ICAgKHdoaWxlIChzZWFyY2gtZm9yd2FyZCAiICIgbmlsIHQpCiAgICAgICAoaW50ZXJuIChidWZm ZXItc3Vic3RyaW5nLW5vLXByb3BlcnRpZXMgcG9zICgxLSAocG9pbnQpKSkgb2JhcnJheSkKQEAg LTE5Myw3ICsxOTQsNyBAQAogUmV0dXJucyBhIHN0cmluZy4iCiAgIChzZXRxIHN5bSAob3Igc3lt ICh0aGluZy1hdC1wb2ludCAnc3ltYm9sKSkKIAlzY3dtLW9iYXJyYXkgKG9yIHNjd20tb2JhcnJh eSAoc2N3bS1tYWtlLW9iYXJyYXkpKSkKLSAgKGNvbXBsZXRpbmctcmVhZCAiU0NXTSBzeW1ib2w6 ICIgc2N3bS1vYmFycmF5IG5pbCBuaWwgc3ltIHNjd20taGlzdG9yeSBzeW0pKQorICAoY29tcGxl dGluZy1yZWFkICJTQ1dNIHN5bWJvbDogIiBzY3dtLW9iYXJyYXkgbmlsIG5pbCBzeW0gc2N3bS1o aXN0b3J5KSkKIAogOzs7IyMjYXV0b2xvYWQKIChkZWZ1biBzY3dtLWNvbXBsZXRlLXN5bWJvbC1p bnNlcnQgKCkKQEAgLTI0OSw2ICsyNTAsNzggQEAKICAgICAgICAgICAgICAgIChjb25zIChjb25z ICdzY3dtLW1vZGUKICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ3NjaGVt ZS1tb2RlIGZvbnQtbG9jay1kZWZhdWx0cy1hbGlzdCkpKQogICAgICAgICAgICAgICAgICAgICAg Zm9udC1sb2NrLWRlZmF1bHRzLWFsaXN0KSkpKSkKKworCisocmVxdWlyZSAnaW5mbykKKworKGRl ZnZhciBzY3dtLWluZm8tZmlsZS1saXN0CisgICcoKCJyNHJzIiAuICJJbmRleCIpCisgICAgKCJn dWlsZS1yZWYiIC4gIlByb2NlZHVyZSBJbmRleCIpCisgICAgKCJndWlsZS1yZWYiIC4gIlZhcmlh YmxlIEluZGV4IikKKyAgICAoInNjd20iIC4gIkZ1bmN0aW9uIEluZGV4IikKKyAgICAoInNjd20i IC4gIlZhcmlhYmxlIEluZGV4IikpCisgICJMaXN0IG9mIEluZm8gZmlsZXMgdGhhdCBkZXNjcmli ZSBHdWlsZSBwcm9jZWR1cmVzLgorQW4gZWxlbWVudCBsaXN0IG9mIHRoZSBmb3JtIChGSUxFIC4g Tk9ERSkuIikKKworCisoZGVmdW4gc2N3bS1maW5kLWd1aWxlLXByb2NlZHVyZS1ub2RlcyAocHJv Y2VkdXJlKQorICAiUmV0dXJuIGEgbGlzdCBvZiBsb2NhdGlvbnMgZG9jdW1lbnRpbmcgUFJPQ0VE VVJFLgorVGhlIHZhcmlhYmxlIGBzY3dtLWluZm8tZmlsZS1saXN0JyBkZWZpbmVzIGhldXJpc3Rp Y3MgZm9yIHdoaWNoIEluZm8KK21hbnVhbCB0byB0cnkuICBUaGUgbG9jYXRpb25zIGFyZSBvZiB0 aGUgZm9ybWF0IHVzZWQgaW4gSW5mby1oaXN0b3J5LAoraS5lLiAgXChGSUxFTkFNRSBOT0RFTkFN RSBCVUZGRVJQT1NcKS4iCisgIChsZXQgKCh3aGVyZSAnKCkpCisJKGNtZC1kZXNjIChjb25jYXQg Il5cXCogIiAocmVnZXhwLXF1b3RlIHByb2NlZHVyZSkKKwkJCSAgIjpcXHMgKlxcKC4qXFwpXFwu JCIpKQorCShmaWxlLWxpc3Qgc2N3bS1pbmZvLWZpbGUtbGlzdCkpCisgICAgKHdoaWxlIGZpbGUt bGlzdAorICAgICAgKGxldCogKChmaWxlIChjYXIgKGNhciBmaWxlLWxpc3QpKSkKKwkgICAgIChp bmRleCAoY2RyIChjYXIgZmlsZS1saXN0KSkpKQorCShzZXRxIGZpbGUtbGlzdCAoY2RyIGZpbGUt bGlzdCkpCisJKHNhdmUtZXhjdXJzaW9uCisJICAoY29uZGl0aW9uLWNhc2UgbmlsCisJICAgICAg KHByb2duCisJCShJbmZvLWZpbmQtbm9kZSBmaWxlIGluZGV4KQorCQk7OyBUYWtlIHRoZSBpbmRl eCBub2RlIG9mZiB0aGUgSW5mbyBoaXN0b3J5LgorCQkoc2V0cSBJbmZvLWhpc3RvcnkgKGNkciBJ bmZvLWhpc3RvcnkpKQorCQkoZ290by1jaGFyIChwb2ludC1tYXgpKQorCQkod2hpbGUgKHJlLXNl YXJjaC1iYWNrd2FyZCBjbWQtZGVzYyBuaWwgdCkKKwkJICAoc2V0cSB3aGVyZSAoY29ucyAobGlz dCBJbmZvLWN1cnJlbnQtZmlsZQorCQkJCQkgIChidWZmZXItc3Vic3RyaW5nCisJCQkJCSAgICht YXRjaC1iZWdpbm5pbmcgMSkKKwkJCQkJICAgKG1hdGNoLWVuZCAxKSkKKwkJCQkJICAwKQorCQkJ CSAgICB3aGVyZSkpKSkKKwkgICAgKGVycm9yKSkpKSkKKyAgICB3aGVyZSkpCisKKyhkZWZ1biBz Y3dtLWdvdG8tZ3VpbGUtcHJvY2VkdXJlLW5vZGUgKHByb2NlZHVyZSkKKyAgIkdvIHRvIHRoZSBJ bmZvIG5vZGUgaW4gdGhlIEd1aWxlIG1hbnVhbCBmb3IgcHJvY2VkdXJlIFBST0NFRFVSRS4KK1Ro ZSBwcm9jZWR1cmUgaXMgZm91bmQgYnkgbG9va2luZyB1cCBpbiB0aGUgR3VpbGUgUmVmZXJlbmNl IG1hbnVhbCdzCitQcm9jZWR1cmUgSW5kZXggb3IgaW4gYW5vdGhlciBtYW51YWwgZm91bmQgdmlh IHRoZSB2YXJpYWJsZQorYHNjd20taW5mby1maWxlLWxpc3QnLiIKKyAgKGludGVyYWN0aXZlIChs aXN0IChzY3dtLWNvbXBsZXRlLXN5bWJvbCkpKQorICAobGV0ICgod2hlcmUgKHNjd20tZmluZC1n dWlsZS1wcm9jZWR1cmUtbm9kZXMgcHJvY2VkdXJlKSkpCisgICAgKGlmIHdoZXJlCisJKGxldCAo KG51bS1tYXRjaGVzIChsZW5ndGggd2hlcmUpKSkKKwkgIDs7IEdldCBJbmZvIHJ1bm5pbmcsIGFu ZCBwb3AgdG8gaXQgaW4gYW5vdGhlciB3aW5kb3cuCisJICAoc2F2ZS13aW5kb3ctZXhjdXJzaW9u CisJICAgIChpbmZvKSkKKwkgIChwb3AtdG8tYnVmZmVyICIqaW5mbyoiKQorCSAgOzsgKGZpbGVu YW1lIG5vZGVuYW1lIGJ1ZmZlcnBvcykKKwkgIChJbmZvLWZpbmQtbm9kZSAoY2FyIChjYXIgd2hl cmUpKQorCQkJICAoY2FyIChjZHIgKGNhciB3aGVyZSkpKSkKKwkgIChpZiAoPiBudW0tbWF0Y2hl cyAxKQorCSAgICAgIChwcm9nbgorCQk7OyBJbmZvLWZpbmQtbm9kZSBhbHJlYWR5IHB1c2hlZCAo Y2FyIHdoZXJlKSBvbnRvCisJCTs7IEluZm8taGlzdG9yeS4gIFB1dCB0aGUgb3RoZXIgbm9kZXMg dGhhdCB3ZXJlIGZvdW5kIG9uCisJCTs7IHRoZSBoaXN0b3J5LgorCQkoc2V0cSBJbmZvLWhpc3Rv cnkgKG5jb25jIChjZHIgd2hlcmUpIEluZm8taGlzdG9yeSkpCisJCShtZXNzYWdlICJGb3VuZCAl ZCBvdGhlciBlbnRyJXMuICBVc2UgJXMgdG8gc2VlICVzLiIKKwkJCSAoMS0gbnVtLW1hdGNoZXMp CisJCQkgKGlmICg+IG51bS1tYXRjaGVzIDIpICJpZXMiICJ5IikKKwkJCSAoc3Vic3RpdHV0ZS1j b21tYW5kLWtleXMgIlxcW0luZm8tbGFzdF0iKQorCQkJIChpZiAoPiBudW0tbWF0Y2hlcyAyKSAi dGhlbSIgIml0IikpKSkpCisgICAgICAoZXJyb3IgIkNvdWxkbid0IGZpbmQgZG9jdW1lbnRhdGlv biBmb3IgJXMiIHByb2NlZHVyZSkpKSkKIAogKHByb3ZpZGUgJ3Njd20pCiA7Ozsgc2N3bSBlbmRz IGhlcmUK ----=_35aa345324684964101905799.MFSBCHJLHS-- From owner-scwm-discuss@mit.edu Mon Jul 13 16:10:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA23939 for scwm-discuss-outgoing; Mon, 13 Jul 1998 16:10:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA23936 for ; Mon, 13 Jul 1998 16:10:16 -0400 Received: from [137.205.227.167] by MIT.EDU with SMTP id AA29714; Mon, 13 Jul 98 16:07:40 EDT Received: (from esuci@localhost) by diamond.dcs.warwick.ac.uk (8.8.8/8.8.8) id VAA07087; Mon, 13 Jul 1998 21:07:34 +0100 (BST) Message-Id: <19980713210733.58579@dcs.warwick.ac.uk> Date: Mon, 13 Jul 1998 21:07:33 +0100 From: Michael Stevens To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a References: <19980713000134.03664@dcs.warwick.ac.uk> <199807130255.WAA17670@huis-clos.mit.edu> <19980713041825.07665@dcs.warwick.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Robert Bihlmeyer on Mon, Jul 13, 1998 at 11:14:55AM +0200 X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Mon, Jul 13, 1998 at 11:14:55AM +0200, Robert Bihlmeyer wrote: > Hi, > >>>>> On Mon, 13 Jul 1998 04:18:25 +0100 > >>>>> Michael Stevens said: > Michael> If we could have a --with-xpm-prefix, I'd like that. Round > Michael> here, there are lots of bits in different places that need > Michael> to be put together - guile with one prefix, X libs with > Michael> another, and Xpm with get another. > > Rather than adding a swath of --with-*-prefixes for guile, xpm, and > whatnot, why not have an --with-additional-prefixes (or somesuch), > that takes a list (colon-seperated) of prefixes, and tries them all in > order for every library and other file we depend on? This idea I like. And occasionally wonder why something like this isn't a default autoconf thing. Although I can envision wanting to specify that particular libraries should be found in particular places... -- I bet the human brain is a kludge. -- Minsky From owner-scwm-discuss@mit.edu Mon Jul 13 16:35:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24260 for scwm-discuss-outgoing; Mon, 13 Jul 1998 16:35:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA24257 for ; Mon, 13 Jul 1998 16:35:17 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA19495; Mon, 13 Jul 98 16:34:25 EDT Received: from mcfeely.concentric.net (mcfeely [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id QAA29646; Mon, 13 Jul 1998 16:34:11 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts005d26.phe-pa.concentric.net [209.31.154.230]) by mcfeely.concentric.net (8.8.8) id QAA26261; Mon, 13 Jul 1998 16:34:10 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA21494; Mon, 13 Jul 1998 15:38:40 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of "Mon, 13 Jul 1998 16:22:43 GMT" Date: 13 Jul 1998 15:38:40 -0400 Message-Id: Lines: 41 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35aa3174.246114313@mailhost> >>>> Sent on Mon, 13 Jul 1998 16:22:43 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "scwm.el bugs and additions": >> Content-Type: text/plain; charset=us-ascii >> Content-Transfer-Encoding: quoted-printable >> >> Here is a patch (well, a diff -u) for scwm.el. Please use "diff -cwb" next time. Please do ***NOT*** use MIME, but if you feel you ***MUST***, please use correct `Content-Type'. "application/octet-stream" is inappropriate. "plain text" would work fine. >> 1. apropos-internal is being called with "*" as an argument, it >> should be ".*" Both give the same result. Are you sure this is important? ".*" is a regexp, which is compiled and applied. "*" might be handled in a special, faster way. >> 2. completing-read is being called with two many arguments. At least there >> are too many for emacs 19.33, I'm not sure about 20.x. The call is appropriate in e20. I'll remove the extra arg for backward compatibility. Thanks. >> I have added a command which I bind to C-h C-f. It finds and >> displays the info documentation for the scheme procedure under the >> point. It's just some hacked-up version of a similar routine that >> finds emacs commands. It uses the guile-ref, r4rs, and (updated) >> scwm info files. Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Just because you're paranoid doesn't mean they AREN'T after you. From owner-scwm-discuss@mit.edu Mon Jul 13 17:05:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA24439 for scwm-discuss-outgoing; Mon, 13 Jul 1998 17:05:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA24436 for ; Mon, 13 Jul 1998 17:05:13 -0400 Received: by tis.bellhow.com; id RAA23164; Mon, 13 Jul 1998 17:04:04 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma023100; Mon, 13 Jul 98 17:03:53 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id RAA17073; Mon, 13 Jul 1998 17:03:52 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: sds@goems.com, scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions Date: Mon, 13 Jul 1998 21:00:22 GMT Organization: Bell & Howell PSC Message-ID: <35aa74fb.946050@mailhost> References: <35aa3174.246114313@mailhost> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA24437 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 13 Jul 1998 15:38:40 -0400, you wrote: > >> 1. apropos-internal is being called with "*" as an argument, it > >> should be ".*" > >Both give the same result. Are you sure this is important? >".*" is a regexp, which is compiled and applied. >"*" might be handled in a special, faster way. [~] smithd@wgs guile guile> (apropos-internal "*") ERROR: In procedure gsubr-apply in expression (make-regexp rgx): ERROR: ?, *, +, or { } not preceded by valid regular expression ABORT: (regular-expression-syntax) Type "(backtrace)" to get more information. guile> (backtrace) Backtrace: 0* [apropos-internal "*"] 1 (let ((match #) (modules #) (recorded #) ...) (let (#) (for-each # modules)) ...) 2* [gsubr-apply #> "*"] Type "(debug-enable 'backtrace)" if you would like a backtrace automatically if an error occurs in the future. guile> -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Mon Jul 13 18:12:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24771 for scwm-discuss-outgoing; Mon, 13 Jul 1998 18:12:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA24768 for ; Mon, 13 Jul 1998 18:12:01 -0400 Received: from mcfeely.concentric.net (mcfeely [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id SAA22446; Mon, 13 Jul 1998 18:10:53 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts005d26.phe-pa.concentric.net [209.31.154.230]) by mcfeely.concentric.net (8.8.8) id SAA24146; Mon, 13 Jul 1998 18:10:51 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA21852; Mon, 13 Jul 1998 17:37:40 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35aa74fb.946050@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of "Mon, 13 Jul 1998 21:00:22 GMT" Date: 13 Jul 1998 17:37:40 -0400 Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35aa74fb.946050@mailhost> >>>> Sent on Mon, 13 Jul 1998 21:00:22 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: scwm.el bugs and additions": >> On 13 Jul 1998 15:38:40 -0400, you wrote: >> >> > >> 1. apropos-internal is being called with "*" as an argument, it >> > >> should be ".*" >> > >> >Both give the same result. Are you sure this is important? >> >".*" is a regexp, which is compiled and applied. >> >"*" might be handled in a special, faster way. >> >> [~] >> smithd@wgs guile >> guile> (apropos-internal "*") >> ERROR: In procedure gsubr-apply in expression (make-regexp rgx): >> ERROR: ?, *, +, or { } not preceded by valid regular expression >> ABORT: (regular-expression-syntax) Interesting. what version of guile are you using? at any rate, I'll make the appropriate modification in scwm.el. Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Sinners can repent, but stupid is forever. From owner-scwm-discuss@mit.edu Mon Jul 13 18:17:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24825 for scwm-discuss-outgoing; Mon, 13 Jul 1998 18:17:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA24822 for ; Mon, 13 Jul 1998 18:17:58 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00384; Mon, 13 Jul 98 18:16:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA29912; Mon, 13 Jul 1998 15:16:35 -0700 (PDT) To: sds@goems.com Cc: dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35aa74fb.946050@mailhost> From: Greg Badros Date: 13 Jul 1998 15:16:35 -0700 In-Reply-To: Sam Steingold's message of "13 Jul 1998 17:37:40 -0400" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <35aa74fb.946050@mailhost> > >>>> Sent on Mon, 13 Jul 1998 21:00:22 GMT > >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes > >>>> on the subject of "Re: scwm.el bugs and additions": > >> On 13 Jul 1998 15:38:40 -0400, you wrote: > >> > >> > >> 1. apropos-internal is being called with "*" as an argument, it > >> > >> should be ".*" > >> > > >> >Both give the same result. Are you sure this is important? > >> >".*" is a regexp, which is compiled and applied. > >> >"*" might be handled in a special, faster way. > >> > >> [~] > >> smithd@wgs guile > >> guile> (apropos-internal "*") > >> ERROR: In procedure gsubr-apply in expression (make-regexp rgx): > >> ERROR: ?, *, +, or { } not preceded by valid regular expression > >> ABORT: (regular-expression-syntax) > > Interesting. > what version of guile are you using? > at any rate, I'll make the appropriate modification in scwm.el. > Thanks. Perhaps this has something to do with which regular expression engine is being used? Greg From owner-scwm-discuss@mit.edu Mon Jul 13 20:21:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA25447 for scwm-discuss-outgoing; Mon, 13 Jul 1998 20:21:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA25444 for ; Mon, 13 Jul 1998 20:21:14 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA17172; Mon, 13 Jul 98 20:20:03 EDT Received: from newman.concentric.net (newman [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id UAA18649; Mon, 13 Jul 1998 20:20:05 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts005d26.phe-pa.concentric.net [209.31.154.230]) by newman.concentric.net (8.8.8) id UAA14268; Mon, 13 Jul 1998 20:20:03 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA22456; Mon, 13 Jul 1998 18:53:43 -0400 To: Greg Badros Cc: dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35aa74fb.946050@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of "13 Jul 1998 15:16:35 -0700" Date: 13 Jul 1998 18:53:42 -0400 Message-Id: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 13 Jul 1998 15:16:35 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: scwm.el bugs and additions": >> Sam Steingold writes: >> >> > >>>> In message <35aa74fb.946050@mailhost> >> > >>>> Sent on Mon, 13 Jul 1998 21:00:22 GMT >> > >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >> > >>>> on the subject of "Re: scwm.el bugs and additions": >> > >> On 13 Jul 1998 15:38:40 -0400, you wrote: >> > >> >> > >> > >> 1. apropos-internal is being called with "*" as an argument, it >> > >> > >> should be ".*" >> > >> > >> > >> >Both give the same result. Are you sure this is important? >> > >> >".*" is a regexp, which is compiled and applied. >> > >> >"*" might be handled in a special, faster way. >> > >> >> > >> [~] >> > >> smithd@wgs guile >> > >> guile> (apropos-internal "*") >> > >> ERROR: In procedure gsubr-apply in expression (make-regexp rgx): >> > >> ERROR: ?, *, +, or { } not preceded by valid regular expression >> > >> ABORT: (regular-expression-syntax) >> > >> > what version of guile are you using? >> >> Perhaps this has something to do with which regular expression engine is >> being used? are there many of them?! -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Type louder, please. From owner-scwm-discuss@mit.edu Mon Jul 13 23:06:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26252 for scwm-discuss-outgoing; Mon, 13 Jul 1998 23:06:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA26249 for ; Mon, 13 Jul 1998 23:06:01 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA07531; Mon, 13 Jul 98 23:04:48 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id UAA18045 for ; Mon, 13 Jul 1998 20:04:50 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276569-21476>; Mon, 13 Jul 1998 20:03:31 -0700 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions In-Reply-To: Robert Bihlmeyer's message of "13 Jul 1998 10:41:14 +0200." Date: Mon, 13 Jul 1998 20:03:22 -0600 From: Ken Pizzini Message-Id: <19980714030331Z276569-21476+4@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Suppose that I want a literal "<" in my docstring. Since we want to > pass through arbitrary tags to SGML, it has to be escaped. The logical > choice is "<". You can get away with simply leaving it alone for > SGML output. But the real problem are the other output formats (plain > text, maybe texinfo). For them you'd have to map "<" back to "<". > > I think the Right Thing would be to support a minimal set ("&", > and "<", anything else?), and document this. Other &xxx; sequences > will work for SGML output only, so this has to be documented too, plus > perhaps generate a warning if such a sequence is encountered. But I thought we were having a DocBook translator handling the conversion from SGML (using the DocBook DTD) to whatever other format was desired, such as texinfo? I feel that it is the job of the DocBook->XXX translator to know how to "do the right thing" for these cases. > We have a quite similar situation for markup tags. There is certainly > a rich variety - we may want to allow only a few, to prevent > exeggerated markup of docstrings. ... > "slide-desktop will move the given class=option>desktop x > to the right, and y down. > #t is returned, if the action was performed > successfully, #f otherwise. We recommend > binding this function to > Shift-1 > to avoid disaster." > > is certainly excessive. (No guarantees, that this even makes sense, I > don't know DocBook at all.) I think the idea of having some conventions specific to scwm documentation, which a heuristic-based translator can map into DocBook, and which is still comfortably readable by humans, makes a *lot* of sense. But I also think that it is a mistake to prohibit a writer of documentation from being able to add arbritrary DocBook SGML markup where appropriate. Perhaps a style guide specifying "use of other than ... is to be avoided" may be reasonable, but exceptional cases are bound to pop up, and if &xxx; and were passed through to DocBook untouched the documenter could express whatever was required. If the domain-specific heuristics-based extractor is done well one should see very little SGML in the source-as-written. And again, I think it is the problem of the writer of the, say, DocBook->texinfo translater to handle the whole of DocBook right, not the problem of the scwm documentation process. --Ken Pizzini From owner-scwm-discuss@mit.edu Tue Jul 14 02:36:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA27892 for scwm-discuss-outgoing; Tue, 14 Jul 1998 02:36:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA27884; Tue, 14 Jul 1998 02:36:07 -0400 Message-Id: <199807140636.CAA27884@huis-clos.mit.edu> To: Michael Stevens cc: scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a In-reply-to: Your message of "Mon, 13 Jul 1998 04:18:25 BST." <19980713041825.07665@dcs.warwick.ac.uk> Date: Tue, 14 Jul 1998 02:36:07 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk michael@rmta.org writes: > > Hmm, scwm might accidentally be linking against librx if that is > > installed anywhere, I seem to remember a problem of this sort popping > > up long ago. Maybe someone else remembers more about it. > > ldd gives: > libXext.so.0 => /usr/openwin/lib/libXext.so.0 > libX11.so.4 => /usr/openwin/lib/libX11.so.4 > libsocket.so.1 => /usr/lib/libsocket.so.1 > libnsl.so.1 => /usr/lib/libnsl.so.1 > libguile.so.2 => /gnu/lib/libguile.so.2 > libdl.so.1 => /usr/lib/libdl.so.1 > libm.so.1 => /usr/lib/libm.so.1 > libXpm.so.4.11 => /usr/local/lib/libXpm.so.4.11 > libc.so.1 => /usr/lib/libc.so.1 > libmp.so.2 => /usr/lib/libmp.so.2 > > I see no librx here :) Don't think it's that... Although, librx _is_ in > /gnu/lib, and I'm having to point scwm fairly forcefully in that direction > to get things to build... > Maybe it is linking with a static librx.a? That would not show up on the ldd output. > > I guess these are configure problems. For libXpm, we should either > > fail or actually check whether the lib was not found in the source and > > not provide xpm support in that case. I'll try to fix it in one of > > thse ways. > > If we could have a --with-xpm-prefix, I'd like that. Round here, there are > lots of bits in different places that need to be put together - guile with > one prefix, X libs with another, and Xpm with get another. > This is getting to be too many --with-whatever-prefixes. I guess a generic -with-extra-includedirs and -with-extra-libdirs are the only sane solutions, but it would be really nice to get that stuck right in automake. > Sorry. Wasn't clear. ./configure is satisfied with it as being the Right > Thing, but actually attempting to compile scwmrepl fails with errors about > redefinition of Function (amongst others, IIRC). I believe the new version > is readline 2.2 - not sure what the old one is. > That sounds like a weird failure mode. > > These warnings are not dangerous, they just indicate some missing but > > unimportant casts that I should probably put in. > > Was unsure, because they seemed to correspond a little to functions that > were dying at one point - I saw mention of 'safe-load' at one point, and I > had a trace (the first one) that seemed to indicate to me that safe-load was > dying or missing. > Right, but that is just because it was failing to get defined, because the .x-file did not get built. When it gets defined it actually works. > > > I'm beginning to suspect I'm screwing up something obvious, as I've never > > > had this much trouble with scwm before... > > Probably not, I guess you just have a configuration that we have not > > previously encountered and have not had a chance to iron out the bugs > > for. > > It's interesting. I've built earlier versions with much less trouble. > Something weird is breaking. > It does sound like it. > While we're mentioning it, how am I doing on trouble reports - I try to do a > balanced amount of detail - is it good? > Pretty good. However, in general, for compile or configure problems, it would be nice to always get a copy of config.log and the compiler error output, unless you are totally sure you know exactly what the problem is. From owner-scwm-discuss@mit.edu Tue Jul 14 03:12:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28353 for scwm-discuss-outgoing; Tue, 14 Jul 1998 03:12:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28344; Tue, 14 Jul 1998 03:11:57 -0400 Message-Id: <199807140711.DAA28344@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions In-reply-to: Your message of "13 Jul 1998 15:38:40 EDT." Date: Tue, 14 Jul 1998 03:11:57 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >> Here is a patch (well, a diff -u) for scwm.el. > > Please use "diff -cwb" next time. I concur on -wb, but I prefer unified diffs to context diffs, I find them a lot easier to read. However, either are fine for me. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 03:28:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28513 for scwm-discuss-outgoing; Tue, 14 Jul 1998 03:28:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28509; Tue, 14 Jul 1998 03:28:03 -0400 Message-Id: <199807140728.DAA28509@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: bug in scwm 0.7a In-reply-to: Your message of "Mon, 13 Jul 1998 16:55:04 EDT." <199807132055.QAA02873@jekyll.piermont.com> Date: Tue, 14 Jul 1998 03:28:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > The most important thing I am looking to do that I haven't figured out > is how to set up my virtual desktop right. > > I prefer having just one virtual desktop that is several times the > size of the real desktop in each direction, with a window in the > corner that displays whats in the 3x3 "grid of desktops". I also like > being able to use the keyboard to shift from one desktop to another (I > have my keys in my current window manager bound so I can type C-arrow > (where arrow is up, down, left or right) and get to the "screen" in > the corresponding direction.) > > Is there any way to do this in scwm? > Yes, but some parts of it are tricky. To establish a 3x3 virtual desktop, you'd want to do: (set-desk-size! 3 3) The system.scwmrc already has these key bindings defined that move by one screen's worth within this virtual desktop: ;; move the viewport with the keyboard (bind-key 'all "C-M-Left" (lambda () (move-viewport (%x -100) 0))) (bind-key 'all "C-M-Right" (lambda () (move-viewport (%x 100) 0))) (bind-key 'all "C-M-Up" (lambda () (move-viewport 0 (%y -100)))) (bind-key 'all "C-M-Down" (lambda () (move-viewport 0 (%y 100)))) They are set to use + as a modifier, but it is easy to remove the M- part. Scwm currently does not have a native pager, although one is in the works. However, it is possible to use the pager from fvwm2 through the fvwm module adapter. To do this, it is necessary to do make sure that the (use-modules) clause at the top of the scwmrc includes (app scwm fvwm-module). Then you include a statement like this in your .scwmrc: (define fvwm-pager-module (run-fvwm-module ;; path to the module - XXX FIXME "/mit/windowmanagers/lib/X11/fvwm2/FvwmPager" ;; your .fvwm2rc (does not need to exist for most modules) "~/.fvwm2rc" ;; list of configuration lines, obviously this should be adjusted to taste. '("*FvwmPagerBack grey76" "*FvwmPagerFore black" "*FvwmPagerHilight navyblue" "*FvwmPagerFont none" "*FvwmPagerDeskTopScale 40" "*FvwmPagerLabel 0 Top" "*FvwmPagerLabel 1 Bottom" "*FvwmPagerSmallFont 5x8") ;; module arguments: only manage desktops 0 through 0, i.e. only one. '("0" "0"))) This is a silly way to run the pager, granted. We hope to have a native pager soon which will eliminate this pain. You don't strictly need to define the results of run-fvwm-module as a varibale, but it makes it easy to kill the pager by executing (kill-fvwm-module fvwm-pager-module), perhaps from a keybinding. Thanks again for your interest. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 05:39:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29708 for scwm-discuss-outgoing; Tue, 14 Jul 1998 05:39:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA29701 for ; Tue, 14 Jul 1998 05:39:53 -0400 Received: from kinetic.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA00741; Tue, 14 Jul 98 05:38:54 EDT Received: from localhost (localhost [127.0.0.1]) by kinetic.ki.informatik.uni-frankfurt.de (8.8.8/8.8.7) with ESMTP id TAA04985 for ; Mon, 13 Jul 1998 19:38:57 +0200 (CEST) (envelope-from marko@cs.uni-frankfurt.de) To: scwm-discuss@mit.edu Subject: synthetic mouse drags Reply-To: marko@cs.uni-frankfurt.de X-Mailer: Mew version 1.92.4 on Emacs 19.34 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980713193856Z.marko@cs.uni-frankfurt.de> Date: Mon, 13 Jul 1998 19:38:56 +0200 From: Marko Schuetz X-Dispatcher: imput version 971024 Lines: 21 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In the spirit of gjb.scwmrc I tried putting (bind-key 'all "C-M-S-0" (lambda () (send-button-press 1 0 (get-window) #t #f))) (bind-key 'all "C-M-S-9" (lambda () (send-button-press 1 0 (get-window) #f #t))) in my .scwmrc. My intention is to synthesize a button down event, followed by mouse movement and a button up event. This does work perfectly in emacs, but does not work in gimp, xterm, gv. In xdvi the small zoom window does pop up, but mouse movement does not move it. Running xev it seems that the only difference is that the synthetic events have synthetic=YES whereas the `real` events have synthetic=NO. Does anyone know if this behavior of the apps mentioned is intentional? Is there a reason for insisting on events with synthetic=NO? Marko From owner-scwm-discuss@mit.edu Tue Jul 14 05:40:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29712 for scwm-discuss-outgoing; Tue, 14 Jul 1998 05:40:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA29705 for ; Tue, 14 Jul 1998 05:39:55 -0400 Received: from kinetic.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA00744; Tue, 14 Jul 98 05:38:57 EDT Received: from localhost (localhost [127.0.0.1]) by kinetic.ki.informatik.uni-frankfurt.de (8.8.8/8.8.7) with ESMTP id PAA29896 for ; Mon, 13 Jul 1998 15:18:05 +0200 (CEST) (envelope-from marko@cs.uni-frankfurt.de) To: scwm-discuss@mit.edu Subject: fixed: scwm seemingly not reading *.scm files Reply-To: marko@cs.uni-frankfurt.de X-Mailer: Mew version 1.92.4 on Emacs 19.34 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980713151804W.marko@cs.uni-frankfurt.de> Date: Mon, 13 Jul 1998 15:18:04 +0200 From: Marko Schuetz X-Dispatcher: imput version 971024 Lines: 12 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maybe sharing this prevents others from maiking the same mistake: I had scwm compile and start, but it seemed not to read any of the *.scm files. This turned out to be due to misconfiguration: during `configure` C_INCLUDE_PATH was not set, which caused the C compiler to not find guile headers which in turn caused tests to fail that shouldn't have failed. Since I ran `configure` with --x-includes and --x-libraries set to sensible values the subsequent compilation went smoothly. Maybe the values provided for --x-{includes,libraries} should be used for the compiler runs during configuration...? Marko -- now happily running guile-snap and scwm-snap From owner-scwm-discuss@mit.edu Tue Jul 14 05:42:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29777 for scwm-discuss-outgoing; Tue, 14 Jul 1998 05:42:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id FAA29774 for ; Tue, 14 Jul 1998 05:42:28 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id LAA14596 for scwm-discuss@huis-clos.mit.edu; Tue, 14 Jul 1998 11:41:06 +0200 (CEST) Received: (qmail 11194 invoked by uid 115); 14 Jul 1998 09:36:50 -0000 To: scwm-discuss@mit.edu Subject: Re: install problems - scwm 0.7a References: <19980713000134.03664@dcs.warwick.ac.uk> <199807130255.WAA17670@huis-clos.mit.edu> <19980713041825.07665@dcs.warwick.ac.uk> <19980713210733.58579@dcs.warwick.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 14 Jul 1998 11:36:48 +0200 In-Reply-To: Michael Stevens's message of "Mon, 13 Jul 1998 21:07:33 +0100" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 13 Jul 1998 21:07:33 +0100 >>>>> Michael Stevens said: Michael> On Mon, Jul 13, 1998 at 11:14:55AM +0200, Robert Bihlmeyer Michael> wrote: >> Rather than adding a swath of --with-*-prefixes for guile, xpm, >> and whatnot, why not have an --with-additional-prefixes (or >> somesuch), that takes a list (colon-seperated) of prefixes, and >> tries them all in order for every library and other file we depend >> on? Michael> This idea I like. And occasionally wonder why something like Michael> this isn't a default autoconf thing. Dunno. I will hack something up for scwm, and ask the autoconf maintainers what they think about this issue. Michael> Although I can envision wanting to specify that particular Michael> libraries should be found in particular places... One can think of some convoluted setups where this is needed. For example, if you have two libraries libx and liby in two versions each, and the version of libx, that you want to use, is in the same directory as the version of liby, that you /don't/ want, and vice versa. The question is: are these exeedingly rare cases worth supporting? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Jul 14 08:42:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA30519 for scwm-discuss-outgoing; Tue, 14 Jul 1998 08:42:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA30516 for ; Tue, 14 Jul 1998 08:42:13 -0400 Received: by tis.bellhow.com; id IAA22637; Tue, 14 Jul 1998 08:41:00 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma022582; Tue, 14 Jul 98 08:40:40 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id IAA00914; Tue, 14 Jul 1998 08:40:39 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: sds@goems.com, scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions Date: Tue, 14 Jul 1998 12:37:08 GMT Organization: Bell & Howell PSC Message-ID: <35ac4f9a.51933105@mailhost> References: <35aa3174.246114313@mailhost> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id IAA30517 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 13 Jul 1998 15:38:40 -0400, you wrote: >Please use "diff -cwb" next time. Please do ***NOT*** use MIME, but if >you feel you ***MUST***, please use correct `Content-Type'. >"application/octet-stream" is inappropriate. "plain text" would work >fine. Ok, here is another. If the scheme procedure cannot be found, an info buffer is left on the screen. I thought that `save-excursion' is supposed to handle this, but is appears that Info-goto-node bypasses this somehow. I'm not sure if this is right yet. Dale *** /home/users10/smithd/src/scwm-19980714/utilities/emacs/scwm.el Mon Jul 13 18:35:28 1998 --- /home/users10/smithd/share/emacs/site-lisp/scwm.el Tue Jul 14 08:30:05 1998 *************** *** 274,280 **** (let ((where '()) (cmd-desc (concat "^\\* " (regexp-quote procedure) ":\\s *\\(.*\\)\\.$")) ! (file-list scwm-info-file-list)) (while file-list (let ((file (car (car file-list))) (index (cdr (car file-list)))) --- 274,281 ---- (let ((where '()) (cmd-desc (concat "^\\* " (regexp-quote procedure) ":\\s *\\(.*\\)\\.$")) ! (file-list scwm-info-file-list) ! (this-buffer (current-buffer))) (while file-list (let ((file (car (car file-list))) (index (cdr (car file-list)))) *************** *** 292,297 **** --- 293,299 ---- (match-end 1)) 0) where))))))) + (switch-to-buffer this-buffer) where)) ;;;###autoload -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 14 08:44:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA30530 for scwm-discuss-outgoing; Tue, 14 Jul 1998 08:44:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA30527 for ; Tue, 14 Jul 1998 08:44:13 -0400 Received: by tis.bellhow.com; id IAA22925; Tue, 14 Jul 1998 08:43:00 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma022910; Tue, 14 Jul 98 08:42:50 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id IAA00979 for ; Tue, 14 Jul 1998 08:42:50 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: -LNONE/lib in 7/14 snapshot Date: Tue, 14 Jul 1998 12:39:20 GMT Organization: Bell & Howell PSC Message-ID: <35ad50fa.52285011@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id IAA30528 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The 19980714 snapshot is trying to link with -LNONE/lib on my system. Removing these from all the Makefile gives me a clean compile. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 14 08:55:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA30659 for scwm-discuss-outgoing; Tue, 14 Jul 1998 08:55:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA30656 for ; Tue, 14 Jul 1998 08:55:13 -0400 Received: by tis.bellhow.com; id IAA24496; Tue, 14 Jul 1998 08:54:00 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma024445; Tue, 14 Jul 98 08:53:40 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id IAA01312; Tue, 14 Jul 1998 08:53:39 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: Greg Badros , scwm-discuss@mit.edu Subject: Re: DeferExecution click lossage bug & repair-hack. Date: Tue, 14 Jul 1998 12:50:09 GMT Organization: Bell & Howell PSC Message-ID: <35ae53de.53025526@mailhost> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id IAA30657 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 10 Jul 1998 16:08:48 -0700, you wrote: >I just did a fairly minimal fix to DeferExecution in the hopes of at >least eliminating the obvious bugs. I still think the code should be >revisited and (get-window) should perhaps do something a bit different >than my (select-window-interactively) [still unwritten]. In particular >the former should respect from what context the command was invoked, if >possible, whereas the latter should always select interactively. > >Please let me know if the next snapshot makes things better or worse. *Much* Better!! Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 14 08:56:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA30694 for scwm-discuss-outgoing; Tue, 14 Jul 1998 08:56:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA30690 for ; Tue, 14 Jul 1998 08:56:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25108; Tue, 14 Jul 98 08:55:08 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA19281; Tue, 14 Jul 1998 15:55:02 +0300 To: scwm-discuss@mit.edu Subject: scwm.el bug report - no apropos in guile 1.2. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 14 Jul 1998 15:55:02 +0300 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 12:37:08 GMT" Message-Id: Lines: 10 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Have any of the scwm.el bug fixes addressed the fact that there is no apropos function in guile 1.2? Basically, none of the scwm.el help features work with guile 1.2. scwm.el should either disable those commands if scwm is using guile 1.2, or should work around it. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 14 09:22:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30984 for scwm-discuss-outgoing; Tue, 14 Jul 1998 09:22:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA30981 for ; Tue, 14 Jul 1998 09:22:14 -0400 Received: by tis.bellhow.com; id JAA28906; Tue, 14 Jul 1998 09:21:02 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma028769; Tue, 14 Jul 98 09:20:03 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id JAA02313; Tue, 14 Jul 1998 09:20:01 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions Date: Tue, 14 Jul 1998 13:16:31 GMT Organization: Bell & Howell PSC Message-ID: <35af59c0.54531912@mailhost> References: <35aa3174.246114313@mailhost> <35ac4f9a.51933105@mailhost> In-Reply-To: <35ac4f9a.51933105@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA30982 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 14 Jul 1998 12:37:08 GMT, you wrote: >On 13 Jul 1998 15:38:40 -0400, you wrote: > >>Please use "diff -cwb" next time. Please do ***NOT*** use MIME, but if >>you feel you ***MUST***, please use correct `Content-Type'. >>"application/octet-stream" is inappropriate. "plain text" would work >>fine. > >Ok, here is another. If the scheme procedure cannot be found, an >info buffer is left on the screen. I thought that `save-excursion' >is supposed to handle this, but is appears that Info-goto-node bypasses >this somehow. I'm not sure if this is right yet. In `scwm-goto-guile-procedure-node' change the call (pop-to-buffer "*info*") to (pop-to-buffer "*info*" t) Much nicer. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 14 09:28:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA31037 for scwm-discuss-outgoing; Tue, 14 Jul 1998 09:28:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA31033 for ; Tue, 14 Jul 1998 09:28:00 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA02319; Tue, 14 Jul 98 09:26:43 EDT Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id JAA06288; Tue, 14 Jul 1998 09:26:47 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by cliff.concentric.net (8.8.8) id JAA06606; Tue, 14 Jul 1998 09:26:44 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id JAA23420; Tue, 14 Jul 1998 09:26:34 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "14 Jul 1998 15:55:02 +0300" Date: 14 Jul 1998 09:26:33 -0400 Message-Id: Lines: 17 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 14 Jul 1998 15:55:02 +0300 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes >>>> on the subject of "scwm.el bug report - no apropos in guile 1.2.": >> Have any of the scwm.el bug fixes addressed the fact that there is no >> apropos function in guile 1.2? Basically, none of the scwm.el help >> features work with guile 1.2. scwm.el should either disable those >> commands if scwm is using guile 1.2, or should work around it. 1.2 will be history pretty soon. why bother? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);} From owner-scwm-discuss@mit.edu Tue Jul 14 09:42:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA31194 for scwm-discuss-outgoing; Tue, 14 Jul 1998 09:42:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA31191 for ; Tue, 14 Jul 1998 09:42:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03942; Tue, 14 Jul 98 09:41:25 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA19545; Tue, 14 Jul 1998 16:40:53 +0300 To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 14 Jul 1998 16:40:53 +0300 In-Reply-To: Sam Steingold's message of "14 Jul 1998 09:26:33 -0400" Message-Id: Lines: 31 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 14 Jul 1998 15:55:02 +0300 > >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes > >>>> on the subject of "scwm.el bug report - no apropos in guile 1.2.": > >> Have any of the scwm.el bug fixes addressed the fact that there is no > >> apropos function in guile 1.2? Basically, none of the scwm.el help > >> features work with guile 1.2. scwm.el should either disable those > >> commands if scwm is using guile 1.2, or should work around it. > > 1.2 will be history pretty soon. > why bother? I never count on software being released "soon". The only thing I count on regarding software release dates is that the release dates won't be met. As far as I'm concerned, 1.2 is the last official release, the guile snapshots are development snapshots - they're not even beta releases, and this might go on arbitrarily long. And, I don't think the last official release should be abandoned the moment the next release comes out. Is disabling scwm.el features based on guile version difficult? At least they wouldn't read in the manual that apropos help exists, then try it & see a backtrace. They should at least see "unsupported under guile 1.2". -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 14 09:48:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA31264 for scwm-discuss-outgoing; Tue, 14 Jul 1998 09:48:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA31261 for ; Tue, 14 Jul 1998 09:48:46 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA07769; Tue, 14 Jul 98 09:47:29 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id JAA18935; Tue, 14 Jul 1998 09:47:30 -0400 To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 14 Jul 1998 09:47:29 -0400 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of 10 Jul 1998 16:48:00 -0700 Message-Id: Lines: 37 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes: > JB> We want to use these doc conventions in Guile itself. The Guile > JB> distribution shouldn't depend on Emacs. > > guile-doc depends on automake and makeinfo to make this happen: > > .texi.info: > @cd $(srcdir) && rm -f $@ $@-[0-9] $@-[0-9][0-9] > cd $(srcdir) \ > && $(MAKEINFO) `echo $< | sed 's,.*/,,'` Hmm, not sure exactly what you mean here... Guile-doc shouldn't require users to have automake installed to do anything. If it does, that's a bug. I think it's okay to require that one have the texinfo tools installed to process texinfo source. That's very different from requiring that Emacs be installed. That is: With nothing but Guile installed, you should be able to: - view docstrings in a readable way from the Guile repl I'm willing to require: - the texinfo tools, if you want to produce texinfo output - texi2html, if you want html output I'm not willing to require: - Emacs - automake That is, if you want output in format FOO, it seems reasonable to require the FOO tools to be installed. From owner-scwm-discuss@mit.edu Tue Jul 14 10:38:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31595 for scwm-discuss-outgoing; Tue, 14 Jul 1998 10:38:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA31592 for ; Tue, 14 Jul 1998 10:38:09 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA20733; Tue, 14 Jul 98 10:36:51 EDT Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id KAA17417; Tue, 14 Jul 1998 10:36:55 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by cliff.concentric.net (8.8.8) id KAA23481; Tue, 14 Jul 1998 10:36:53 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id KAA23746; Tue, 14 Jul 1998 10:35:12 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "14 Jul 1998 16:40:53 +0300" Date: 14 Jul 1998 10:35:12 -0400 Message-Id: Lines: 41 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 14 Jul 1998 16:40:53 +0300 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes >>>> on the subject of "Re: scwm.el bug report - no apropos in guile 1.2.": >> Sam Steingold writes: >> >> > >>>> In message >> > >>>> Sent on 14 Jul 1998 15:55:02 +0300 >> > >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes >> > >>>> on the subject of "scwm.el bug report - no apropos in guile 1.2.": >> > >> Have any of the scwm.el bug fixes addressed the fact that there is no >> > >> apropos function in guile 1.2? Basically, none of the scwm.el help >> > >> features work with guile 1.2. scwm.el should either disable those >> > >> commands if scwm is using guile 1.2, or should work around it. >> > >> > 1.2 will be history pretty soon. >> > why bother? >> >> I never count on software being released "soon". The only thing I >> count on regarding software release dates is that the release dates >> won't be met. As far as I'm concerned, 1.2 is the last official >> release, the guile snapshots are development snapshots - they're not >> even beta releases, and this might go on arbitrarily long. And, I >> don't think the last official release should be abandoned the moment >> the next release comes out. This would have been true if scwm were officially released. scwm is at 0.7a and, IMHO, we can dump 1.2 support at any time. >> Is disabling scwm.el features based on guile version difficult? At >> least they wouldn't read in the manual that apropos help exists, then >> try it & see a backtrace. They should at least see "unsupported under >> guile 1.2". done. should be in the next snapshot. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);} From owner-scwm-discuss@mit.edu Tue Jul 14 10:38:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31604 for scwm-discuss-outgoing; Tue, 14 Jul 1998 10:38:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from uhura.concentric.net (uhura.concentric.net [206.173.119.93]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA31601 for ; Tue, 14 Jul 1998 10:38:17 -0400 Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id KAA17430; Tue, 14 Jul 1998 10:37:01 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by cliff.concentric.net (8.8.8) id KAA23494; Tue, 14 Jul 1998 10:36:55 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id KAA23721; Tue, 14 Jul 1998 10:12:23 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35ac4f9a.51933105@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 12:37:08 GMT" Date: 14 Jul 1998 10:12:22 -0400 Message-ID: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35ac4f9a.51933105@mailhost> >>>> Sent on Tue, 14 Jul 1998 12:37:08 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: scwm.el bugs and additions": >> On 13 Jul 1998 15:38:40 -0400, you wrote: >> >> I'm not sure if this is right yet. I hate to sound rude, and I am sorry if I do, but I would appreciate if you test your patches before submitting them. Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. There's always free cheese in a mousetrap. From owner-scwm-discuss@mit.edu Tue Jul 14 10:49:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31793 for scwm-discuss-outgoing; Tue, 14 Jul 1998 10:49:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA31789 for ; Tue, 14 Jul 1998 10:49:17 -0400 Received: by tis.bellhow.com; id KAA15342; Tue, 14 Jul 1998 10:48:03 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma015244; Tue, 14 Jul 98 10:47:18 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA05562; Tue, 14 Jul 1998 10:47:12 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: sds@goems.com, scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions Date: Tue, 14 Jul 1998 14:43:42 GMT Organization: Bell & Howell PSC Message-ID: <35b06ca4.59367706@mailhost> References: <35aa3174.246114313@mailhost> <35ac4f9a.51933105@mailhost> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA31790 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 14 Jul 1998 10:12:22 -0400, you wrote: >>>>> In message <35ac4f9a.51933105@mailhost> >>>>> Sent on Tue, 14 Jul 1998 12:37:08 GMT >>>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>>> on the subject of "Re: scwm.el bugs and additions": > >> On 13 Jul 1998 15:38:40 -0400, you wrote: > >> > >> I'm not sure if this is right yet. > >I hate to sound rude, and I am sorry if I do, but I would appreciate if >you test your patches before submitting them. Sorry. I did test it. And it was/is working fine. I was just not satisfied with the way the buffers were behaving. I guess I was hoping that someone with more elisp lore than I would tidy things up. I *do* have *real* work to do! :) Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 14 11:09:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31965 for scwm-discuss-outgoing; Tue, 14 Jul 1998 11:09:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from darius.concentric.net (darius.concentric.net [207.155.184.79]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA31960 for ; Tue, 14 Jul 1998 11:09:18 -0400 Received: from mcfeely.concentric.net (mcfeely [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id LAA19067; Tue, 14 Jul 1998 11:07:57 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by mcfeely.concentric.net (8.8.8) id LAA25150; Tue, 14 Jul 1998 11:07:52 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id LAA23827; Tue, 14 Jul 1998 11:03:17 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35ac4f9a.51933105@mailhost> <35b06ca4.59367706@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 14:43:42 GMT" Date: 14 Jul 1998 11:03:16 -0400 Message-ID: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35b06ca4.59367706@mailhost> >>>> Sent on Tue, 14 Jul 1998 14:43:42 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: scwm.el bugs and additions": >> On 14 Jul 1998 10:12:22 -0400, you wrote: >> >> >>>>> In message <35ac4f9a.51933105@mailhost> >> >>>>> Sent on Tue, 14 Jul 1998 12:37:08 GMT >> >>>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >> >>>>> on the subject of "Re: scwm.el bugs and additions": >> > >> On 13 Jul 1998 15:38:40 -0400, you wrote: >> > >> >> > >> I'm not sure if this is right yet. >> > >> >I hate to sound rude, and I am sorry if I do, but I would appreciate if >> >you test your patches before submitting them. >> >> Sorry. I did test it. And it was/is working fine. I was just not >> satisfied with the way the buffers were behaving. I guess I was hoping >> that someone with more elisp lore than I would tidy things up. looked fine to me (although I did do some clean-up :-) I'll probably look more at the matter. >> I *do* have *real* work to do! :) everyone does. :-) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. An elephant is a mouse with an operating system. From owner-scwm-discuss@mit.edu Tue Jul 14 11:24:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32097 for scwm-discuss-outgoing; Tue, 14 Jul 1998 11:24:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA32094 for ; Tue, 14 Jul 1998 11:24:21 -0400 Received: from junk.hemmet.s-hem.chalmers.se by MIT.EDU with SMTP id AA03826; Tue, 14 Jul 98 11:23:15 EDT Received: from james by junk.nocrew.org with local (Exim 1.92 #1 (Debian)) id 0yw6uy-0008Bk-00; Tue, 14 Jul 1998 16:23:00 +0100 To: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: Mail-Copies-To: never Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: James Troup Date: 14 Jul 1998 16:23:00 +0100 In-Reply-To: Sam Steingold's message of "14 Jul 1998 10:35:12 -0400" Message-Id: <7zlnpwihij.fsf@junk.nocrew.org> Lines: 16 X-Mailer: Gnus v5.6.23/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > This would have been true if scwm were officially released. What's officially released? It was certainly announced as a release. > scwm is at 0.7a and, IMHO, we can dump 1.2 support at any time. That would be exceedingly unhelpful; the *development snapshots* (emphasised on the web site as ``pre-release'' code) don't work for everyone (I've had a lot of problems with them on Solaris here at Uni). -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ From owner-scwm-discuss@mit.edu Tue Jul 14 12:10:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32358 for scwm-discuss-outgoing; Tue, 14 Jul 1998 12:10:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32355 for ; Tue, 14 Jul 1998 12:10:36 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA16265; Tue, 14 Jul 98 12:09:17 EDT Received: from newman.concentric.net (newman [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id MAA00777; Tue, 14 Jul 1998 12:09:20 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by newman.concentric.net (8.8.8) id MAA01161; Tue, 14 Jul 1998 12:09:19 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA24058; Tue, 14 Jul 1998 12:09:05 -0400 To: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: <7zlnpwihij.fsf@junk.nocrew.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: James Troup's message of "14 Jul 1998 16:23:00 +0100" Date: 14 Jul 1998 12:09:05 -0400 Message-Id: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <7zlnpwihij.fsf@junk.nocrew.org> >>>> Sent on 14 Jul 1998 16:23:00 +0100 >>>> Honorable James Troup writes >>>> on the subject of "Re: scwm.el bug report - no apropos in guile 1.2.": >> Sam Steingold writes: >> >> > This would have been true if scwm were officially released. >> What's officially released? It was certainly announced as a release. version >= 1.0 everything before that is considered beta. >> > scwm is at 0.7a and, IMHO, we can dump 1.2 support at any time. >> >> That would be exceedingly unhelpful; the *development snapshots* >> (emphasised on the web site as ``pre-release'' code) don't work for >> everyone (I've had a lot of problems with them on Solaris here at >> Uni). This is why we are not dumping 1.2. Note that apropos and help etc are not "major functionality" (major functionality: related to the scwm as a WM; apropos etc just help the user/developer write scheme code, if you are writing scheme you are likely to use guile snap anyway), and it is wasteful to support minor deficiencies of guile 1.2 in this area. It is even more wasteful to keep discussing the matter after I added the support. :-) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A computer scientist is someone who fixes things that aren't broken. From owner-scwm-discuss@mit.edu Tue Jul 14 12:13:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32406 for scwm-discuss-outgoing; Tue, 14 Jul 1998 12:13:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tolt.cs.washington.edu (tolt.cs.washington.edu [128.95.1.155]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA32403 for ; Tue, 14 Jul 1998 12:13:11 -0400 Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA15604; Tue, 14 Jul 1998 09:11:50 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: DeferExecution click lossage bug & repair-hack. References: <35ae53de.53025526@mailhost> From: Greg Badros Date: 14 Jul 1998 09:11:50 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 12:50:09 GMT" Message-ID: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > >I just did a fairly minimal fix to DeferExecution in the hopes of at > >least eliminating the obvious bugs. I still think the code should be > >revisited and (get-window) should perhaps do something a bit different > >than my (select-window-interactively) [still unwritten]. In particular > >the former should respect from what context the command was invoked, if > >possible, whereas the latter should always select interactively. > > > >Please let me know if the next snapshot makes things better or worse. > > > *Much* Better!! Thanks for the report that the bug is gone for you-- these are very helpful in eliminating open issues! Greg From owner-scwm-discuss@mit.edu Tue Jul 14 12:17:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32494 for scwm-discuss-outgoing; Tue, 14 Jul 1998 12:17:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32490 for ; Tue, 14 Jul 1998 12:17:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18114; Tue, 14 Jul 98 12:16:14 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA15610; Tue, 14 Jul 1998 09:16:16 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: scwm.el bugs and additions References: <35aa3174.246114313@mailhost> <35ac4f9a.51933105@mailhost> <35af59c0.54531912@mailhost> From: Greg Badros Date: 14 Jul 1998 09:16:15 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 13:16:31 GMT" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > On Tue, 14 Jul 1998 12:37:08 GMT, you wrote: > > >On 13 Jul 1998 15:38:40 -0400, you wrote: > > > >>Please use "diff -cwb" next time. Please do ***NOT*** use MIME, but if > >>you feel you ***MUST***, please use correct `Content-Type'. > >>"application/octet-stream" is inappropriate. "plain text" would work > >>fine. > > > >Ok, here is another. If the scheme procedure cannot be found, an > >info buffer is left on the screen. I thought that `save-excursion' > >is supposed to handle this, but is appears that Info-goto-node bypasses > >this somehow. I'm not sure if this is right yet. > > In `scwm-goto-guile-procedure-node' change the call > (pop-to-buffer "*info*") > to > (pop-to-buffer "*info*" t) > > > Much nicer. Cool-- thanks for your continued patches -- these improvements are much appreciated! Greg From owner-scwm-discuss@mit.edu Tue Jul 14 14:38:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00753 for scwm-discuss-outgoing; Tue, 14 Jul 1998 14:38:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00750 for ; Tue, 14 Jul 1998 14:38:27 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA24977; Tue, 14 Jul 98 14:37:07 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA19589; Tue, 14 Jul 1998 14:37:11 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: generating a manual from annotations in source code References: <199807120158.VAA08917@huis-clos.mit.edu> From: Jim Blandy Date: 14 Jul 1998 14:37:10 -0400 In-Reply-To: Maciej Stachowiak's message of Sat, 11 Jul 1998 21:58:19 EDT Message-Id: Lines: 53 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk If you showed me a reference manual, and I looked it over and said it looked like a good manual, and then you showed me that the manual was generated automatically by extracting bits of text from source code, then I wouldn't suddenly change my mind and call it a bad manual. In other words, if your doc extraction system tends to all the usual details required for writing a good manual, then I'm sure you'll get a good manual. And I believe it is mechanically possible to do this. My concern is that it will be unmaintainable, realistically, given the human nature of maintainers. If the layout of the code has any influence on the layout of the manual, then you will sometimes find places where good coding style conflicts with good manual style. Certainly one can find compromises, but remember that these compromises are only necessary at all because you're trying to extract a manual from code. If you just simply move the text out of the code into the manual, then these tensions never exist in the first place. Or, because the form of the manual is obscured by being scattered throughout the source files, you will make changes that hurt the manual without realizing it at all. Did you ever read over the Java class documentation in the early days of Java? They had it on the web. It was terrible. You couldn't figure anything out. That's one example I have of a manual extracted from docstrings. I also know that Stallman was quite opposed to the idea, and over the years I decided he was probably right. It's just a gut feeling. If you don't agree, you don't agree, and you should go with your own gut feeling. If the goal is to provide on-line documentation associated with SCWM procedures, I would be much happier with a system that extracted in the reverse direction: from a manual to a database accessible by the code. For example, go ahead and write texinfo or DocBook describing the SCWM functions, then have a program grunge through the @deffn's (or the DocBook equivalent) and build a database, then have SCWM retrieve that text upon user request. Or, if you think it is valuable to have the text mingled with the source code, add a notation to your manual format that says "extract the docstring for this function from the source, and insert it here." That way, the layout of the source has no influence on the layout of the manual. Do people feel that, if the documentation is a separate file, programmers will be discouraged from writing docs, whereas, if the documentation were mingled with the source, then programmers would naturally write docstrings as they go along? From owner-scwm-discuss@mit.edu Tue Jul 14 14:47:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01014 for scwm-discuss-outgoing; Tue, 14 Jul 1998 14:47:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA00963 for ; Tue, 14 Jul 1998 14:47:25 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id UAA09244 for scwm-discuss@huis-clos.mit.edu; Tue, 14 Jul 1998 20:46:10 +0200 (CEST) Received: (qmail 11297 invoked by uid 115); 14 Jul 1998 10:17:40 -0000 To: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <19980714030331Z276569-21476+4@pulsar.halcyon.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 14 Jul 1998 12:17:39 +0200 In-Reply-To: Ken Pizzini's message of "Mon, 13 Jul 1998 20:03:22 -0600" Message-ID: Lines: 40 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 13 Jul 1998 20:03:22 -0600 >>>>> Ken Pizzini said: Ken> But I thought we were having a DocBook translator handling the Ken> conversion from SGML (using the DocBook DTD) to whatever other Ken> format was desired, such as texinfo? AFAIK there is no working DocBook->texinfo translator right now[1]. But even more important: We want plain-text versions of the docstrings that are accessible from inside guile (with something like "(write-line (procedure-documentation blah))"). Generating these with a markup_docstring->DocBook->plaintext_docstring process seems a bit extreme, and markup_docstring->plaintext_docstring is more straight-forward. For the latter, we need some knowledge of &xxx; and stuff. The former may also be viable, or even be a good solution. It *does* have it's merit, e.g. unlike in Emacs spaces and aribtrary long lines in docstrings are then easy to handle. . . . Or do the last step on demand, i.e. save the markup_docstrings (or even docbook_docstring!) and render them to the current terminal whenever they are requested. Just idle thinking, but there are a lot of possiblities... Robbe [1] Of course time spent on making this translator work would probably be better invested than on writing a docstring->texi translator from scratch. -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Jul 14 14:47:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01021 for scwm-discuss-outgoing; Tue, 14 Jul 1998 14:47:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01007 for ; Tue, 14 Jul 1998 14:47:34 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA27547; Tue, 14 Jul 98 14:46:13 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA19634; Tue, 14 Jul 1998 14:46:13 -0400 To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: primitive documentation conventions References: <19980714030331Z276569-21476+4@pulsar.halcyon.com> From: Jim Blandy Date: 14 Jul 1998 14:46:12 -0400 In-Reply-To: Ken Pizzini's message of Mon, 13 Jul 1998 20:03:22 -0600 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The SGML/Docbook tools I've seen are pretty heavy-weight. I think we want to choose a heavily subsetted version of Docbook for docstrings, because the Guile REPL's `help' function shouldn't have to fire up Jade. Maciej, do you agree with this? From owner-scwm-discuss@mit.edu Tue Jul 14 14:52:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01121 for scwm-discuss-outgoing; Tue, 14 Jul 1998 14:52:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01118 for ; Tue, 14 Jul 1998 14:52:14 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA28877; Tue, 14 Jul 98 14:50:54 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA19657; Tue, 14 Jul 1998 14:50:51 -0400 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. References: From: Jim Blandy Date: 14 Jul 1998 14:50:50 -0400 In-Reply-To: hjstein@bfr.co.il's message of 14 Jul 1998 16:40:53 +0300 Message-Id: Lines: 8 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I never count on software being released "soon". The only thing I > count on regarding software release dates is that the release dates > won't be met. *ouch* See, that's why I never announce a date... people get angrier... From owner-scwm-discuss@mit.edu Tue Jul 14 15:38:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01900 for scwm-discuss-outgoing; Tue, 14 Jul 1998 15:38:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01897 for ; Tue, 14 Jul 1998 15:38:47 -0400 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA17619; Tue, 14 Jul 98 15:37:43 EDT Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id VAA19410; Tue, 14 Jul 1998 21:37:23 +0200 (MET DST) To: Jim Blandy Cc: Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code References: <199807120158.VAA08917@huis-clos.mit.edu> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 14 Jul 1998 21:37:23 +0200 In-Reply-To: Jim Blandy's message of 14 Jul 1998 14:37:10 -0400 Message-Id: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > Do people feel that, if the documentation is a separate file, > programmers will be discouraged from writing docs, whereas, if the > documentation were mingled with the source, then programmers would > naturally write docstrings as they go along? If this is the case, then there might be alternative solutions to *that* problem. E.g., if the programmer is adding a new function, it is possible to write an Emacs function which looks up the definitions of the neighboring functions in the texinfo code, splits the window, and positions the cursor at a putative place in the texinfo file---something in the style of C-x 4 a. Also, note that while it is difficult to automatically generate a well-structured manual, it may be easier to try to write texinfo function descriptions as self-contained as possible so that we could have a function in (ice-9 session): (info ) which looks up and prints the info entry of the procedure. I.e., it might be possible to go the other way, using the info documentation also as docstrings... /mdj From owner-scwm-discuss@mit.edu Tue Jul 14 15:52:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02056 for scwm-discuss-outgoing; Tue, 14 Jul 1998 15:52:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02046; Tue, 14 Jul 1998 15:52:44 -0400 Message-Id: <199807141952.PAA02046@huis-clos.mit.edu> To: marko@cs.uni-frankfurt.de cc: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags In-reply-to: Your message of "Mon, 13 Jul 1998 19:38:56 +0200." <19980713193856Z.marko@cs.uni-frankfurt.de> Date: Tue, 14 Jul 1998 15:52:44 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk marko@cs.uni-frankfurt.de writes: > In the spirit of gjb.scwmrc I tried putting > > (bind-key 'all "C-M-S-0" (lambda () (send-button-press 1 0 (get-window) #t #f))) > > (bind-key 'all "C-M-S-9" (lambda () (send-button-press 1 0 (get-window) #f #t))) > > in my .scwmrc. > > My intention is to synthesize a button down event, followed by mouse > movement and a button up event. > This does work perfectly in emacs, but does not work in gimp, xterm, > gv. In xdvi the small zoom window does pop up, but mouse movement does > not move it. Running xev it seems that the only difference is that the > synthetic events have synthetic=YES whereas the `real` events have > synthetic=NO. > > Does anyone know if this behavior of the apps mentioned is > intentional? Is there a reason for insisting on events with > synthetic=NO? I'm not sure if it is intentional, but I would consider it a bug either way. At least I can't think of a good reason for treating synthetic events differently. In fact, I just read over the Gtk+ source code breifly (specifically gdk_event_filter) and I can't figure out why or how a gtk+ app like the gimp would ever ignore synthetic events. It is possible, however, that some apps have the server grabbed during a mouse drag operation, and scwm's synthetic events are not reaching the X server in time. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 16:04:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02248 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:04:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02243; Tue, 14 Jul 1998 16:04:29 -0400 Message-Id: <199807142004.QAA02243@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: -LNONE/lib in 7/14 snapshot In-reply-to: Your message of "Tue, 14 Jul 1998 12:39:20 GMT." <35ad50fa.52285011@mailhost> Date: Tue, 14 Jul 1998 16:04:29 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > The 19980714 snapshot is trying to link with -LNONE/lib on my system. > Removing these from all the Makefile gives me a clean compile. > I think this is related to the recent changes to try to improve configuration in the case where packages are scattered all around the disk. My guess is some variables we are copying default to NONE and relevant macros specially hack them to be /usr/local by default, so we should check this case ourselves as well. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 16:18:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02436 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:18:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02433 for ; Tue, 14 Jul 1998 16:18:06 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA21574; Tue, 14 Jul 98 16:16:43 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id VAA04310; Tue, 14 Jul 1998 21:22:50 +0100 Date: Tue, 14 Jul 1998 21:22:50 +0100 (BST) From: Danius Michaelides To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: bug in scwm 0.7a In-Reply-To: <199807140728.DAA28509@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 14 Jul 1998, Maciej Stachowiak wrote: > This is a silly way to run the pager, granted. We hope to have a > native pager soon which will eliminate this pain. Is it likely that this native pager will be swallow-able by FvwmButtons? Not that its a great problem if it isnt, but it brings me neatly onto the subject of Fvwm module support. Recently, I've been converting my Fvwm2 config to scwm. Now i've got most of the way there, but fell over on the module support. I use FvwmIconMan, and FvwmButtons with a swallowed FvwmPager. I found the fvwm module support in fvwm-module.scm and fvwm-eval.scm abit incomplete, and have been hacking things to enable my config to work. - it seems that if a module sends an undefined command, it causes scwm to die with "scwm: Error communicating with module ". Possibly caused by some kind of problem in kill-fvwm-module ? A solution, put a catch around (eval-fvwm-command command fmod (id->window window-id)) (catch #t (lambda() (eval-fvwm-command command fmod (id->window window-id))) (lambda args (display "Error evaling packet: ") (write packet) (newline)) ) - the fvwm commands dont seem to be work interactively. This seems to be because eval-fvwm-command always gets called with the optional window argument, which defaults to a get-window call. This window argument is #f (i think) when the fvwm module didnt supply a valid, eg when it was for interactive use. So we need something like: (let ((w (id->window window-id))) (if w (eval-fvwm-command command fmod w) (eval-fvwm-command command fmod))) - Added Lower, Resize and Exec (so far). - Resize raises a problem wih the above solution. Since we get-window is already being called for us, we use (interactive-resize window). Except now we have to click (and release) on the window, then drag out the new size of the window. As opposed to the more usual interactive-resize without the window argument, where you click, and drag in one motion. So i'm not sure if the above is really the right thing todo, and instead whether each individual fvwm command should decide how it gets the window context if its unspecified. eg with variable arguments to eval-fvwm-command, we'd have: (define-fvwm-command "Raise" (if window (raise-window window))) but with the current way of calling eval-fvwm-command, you'd have this: (define-fvwm-command "Raise" (raise-window (if window window (get-window)))) - Added Eval, to basically enable buttons in FvwmButton to run some specified code; (define-fvwm-command "Eval" (eval-string args)) and "*FvwmButtons(Title xterm, Icon Shell.xpm, Action `Eval (run-xterm)` Frame 1)" But this is slightly unsatifactory, because the code you specify doesnt have access to any context (eg window). Anyway, i just thought i'd be vocal about this stuff, to see what the general opinion is of persuing it further (I'm happy todo so, and supply a patch, when i'm done) and what is the right thing todo. Danius PS: I'm sorry if this has all been thrashed out before, but i couldnt see any mention of it in the archive of this list. From owner-scwm-discuss@mit.edu Tue Jul 14 16:22:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02490 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:22:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02481; Tue, 14 Jul 1998 16:22:31 -0400 Message-Id: <199807142022.QAA02481@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: scwm.el bug report - no apropos in guile 1.2. In-reply-to: Your message of "14 Jul 1998 10:35:12 EDT." Date: Tue, 14 Jul 1998 16:22:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > This would have been true if scwm were officially released. > scwm is at 0.7a and, IMHO, we can dump 1.2 support at any time. > In my opinion (which I hope carries some weight since I've been coordinating the releases so far :-), although scwm is in a rapidly evolving, mostly pre-stable state, we should not gratuitously break people's setups, and should treat things mostly like a real release. Thus, I think we should continue to support 1.2 for at least one realease of scwm after 1.3 comes out (even if in some cases this just means disabling functionality that cannot be supported easily by 1.2 in some cases, as with `apropos'). And in any case, keeping the 1.2 support we have now is not very hard. In my opnion, the biggest benefit of the 1.3 release is that, for a while at least, we won't have to track the Guile development snapshots to have all the features we need. Tracking evolving snapshots inflicts a lot more pain than just having to support two fixed versions. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 16:37:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02742 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:37:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02739 for ; Tue, 14 Jul 1998 16:37:54 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26923; Tue, 14 Jul 98 16:36:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16933; Tue, 14 Jul 1998 13:36:34 -0700 (PDT) To: Maciej Stachowiak Cc: marko@cs.uni-frankfurt.de, scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <199807141952.PAA02046@huis-clos.mit.edu> From: Greg Badros Date: 14 Jul 1998 13:36:33 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 14 Jul 1998 15:52:44 EDT" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > Does anyone know if this behavior of the apps mentioned is > > intentional? Is there a reason for insisting on events with > > synthetic=NO? > > I'm not sure if it is intentional, but I would consider it a bug > either way. At least I can't think of a good reason for treating > synthetic events differently. In fact, I just read over the Gtk+ > source code breifly (specifically gdk_event_filter) and I can't figure > out why or how a gtk+ app like the gimp would ever ignore synthetic > events. Security. E.g., synthetic keystroke events to an xterm is a huge security hole if xterm listens to synthetic events (by default it does not). Emacs does honour synthetic events by default (at least some versions do; I don't know of any that don't). As for the gimp, there are certainly bad things one could do, but they'd have to be more creative than getting to send events to an XTerm running a shell. X security is often pretty lax (witness the `xhost +' command so often used w/o much thought by many), and if you have ill-intentioned people around, can be a big problem. Greg From owner-scwm-discuss@mit.edu Tue Jul 14 16:38:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02765 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:38:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02762 for ; Tue, 14 Jul 1998 16:38:52 -0400 Received: from brazil.tcimet.net by MIT.EDU with SMTP id AA04776; Tue, 14 Jul 98 16:37:48 EDT Received: (from bakicale@localhost) by brazil.tcimet.net (8.8.8/8.7.3) id QAA06970; Tue, 14 Jul 1998 16:38:59 -0400 From: Aleksandar Bakic Message-Id: <199807142038.QAA06970@brazil.tcimet.net> Subject: Re: primitive documentation conventions To: jimb@red-bean.com (Jim Blandy) Date: Tue, 14 Jul 1998 16:38:59 -0400 (EDT) Cc: ken@halcyon.com, scwm-discuss@mit.edu In-Reply-To: from "Jim Blandy" at Jul 14, 98 02:46:12 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Just in case you want to take a look at something similar (a reference manual generated by Jade from manually-create DocBook source), check http://www.egr.msu.edu/Pgrt/PGRT-TIE-REF/book1.htm Regards, Aleksandar > > > The SGML/Docbook tools I've seen are pretty heavy-weight. I think we > want to choose a heavily subsetted version of Docbook for docstrings, > because the Guile REPL's `help' function shouldn't have to fire up > Jade. > > Maciej, do you agree with this? > From owner-scwm-discuss@mit.edu Tue Jul 14 16:39:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02783 for scwm-discuss-outgoing; Tue, 14 Jul 1998 16:39:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02779 for ; Tue, 14 Jul 1998 16:39:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27439; Tue, 14 Jul 98 16:37:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16943; Tue, 14 Jul 1998 13:37:52 -0700 (PDT) To: marko@cs.uni-frankfurt.de Cc: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <19980713193856Z.marko@cs.uni-frankfurt.de> From: Greg Badros Date: 14 Jul 1998 13:37:51 -0700 In-Reply-To: Marko Schuetz's message of "Mon, 13 Jul 1998 19:38:56 +0200" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Marko Schuetz writes: > This does work perfectly in emacs, but does not work in gimp, xterm, > gv. In xdvi the small zoom window does pop up, but mouse movement does > not move it. Running xev it seems that the only difference is that the > synthetic events have synthetic=YES whereas the `real` events have > synthetic=NO. Try it in an xterm after choosing "Allow SendEvents" from the main options menu [Ctrl+Mouse1] (beware of the security hole -- see my other message in response to Maciej). Greg From owner-scwm-discuss@mit.edu Tue Jul 14 17:17:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03345 for scwm-discuss-outgoing; Tue, 14 Jul 1998 17:17:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03338; Tue, 14 Jul 1998 17:17:33 -0400 Message-Id: <199807142117.RAA03338@huis-clos.mit.edu> To: Jim Blandy cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: generating a manual from annotations in source code In-reply-to: Your message of "14 Jul 1998 14:37:10 EDT." Date: Tue, 14 Jul 1998 17:17:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > Did you ever read over the Java class documentation in the early days > of Java? They had it on the web. It was terrible. You couldn't > figure anything out. That's one example I have of a manual extracted > from docstrings. I also know that Stallman was quite opposed to the > idea, and over the years I decided he was probably right. > It definitely sucked, but I think we can do better. I think the main reason it sucked was because it was organized solely be the class names and package hierarchy, rather than in any logical way. I mean, if I knew the name of the class I wanted and the package it was hiding in, I probably didn't really need the manual that much anyway. Another problem is that there was only a reference manual, and no decent user manual providing task-oriented examples. > It's just a gut feeling. If you don't agree, you don't agree, and > you should go with your own gut feeling. > I trust your experience in this area, and I agree with many of your specific concerns. But I also think we have a way of addressing some of them, and I think the benefit is worth it. > > Or, if you think it is valuable to have the text mingled with the > source code, add a notation to your manual format that says "extract > the docstring for this function from the source, and insert it here." > That way, the layout of the source has no influence on the layout of > the manual. > Well, I don't think the layout of the source should dictate the layout of the manual, for the reasons you cited. As I said before, I think the hierarchy of the manual needs to be externally imposed, because, as you said, the program's logical layout will not necessarily match the manual's. If documentation of code implemented in C and in Scheme need to be combined in one place, for instance, there's no possible way to restructure the program to get this in one file. However, I am not sure something as extreme as writing a manula skeleton with special notations to extract the specific documentation is necessary. Perhaps it is, and if it comes to that, I still think it is a superior solution to extracting docstrings from the manual, for the reasons below. > > Do people feel that, if the documentation is a separate file, > programmers will be discouraged from writing docs, whereas, if the > documentation were mingled with the source, then programmers would > naturally write docstrings as they go along? This is the primary motivation to me. First, it helps get the manual off the ground in the first place. If I look at the old outdated crufty manual, I think "It sure will be a lot of work to get this to match the current code." But if I can incrementally add docstrings and get continually improving documentation as a result, I'll be a lot more motivated. I think it also makes maintenance of the docs a more automatic thing. It makes the transaction cost of updating the docs when you change the program much lower, and it makes it a lot easier to remember to do so (and perhaps makes you feel guilty when you don't), since all the surrounding code will be annotated already. The problem of coming up with a good manual _structure_ starting with all this point documentation is not triviall, but I think it is well worth the effort. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 14 17:47:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03539 for scwm-discuss-outgoing; Tue, 14 Jul 1998 17:47:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03536 for ; Tue, 14 Jul 1998 17:47:22 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA22428; Tue, 14 Jul 98 17:46:19 EDT Received: (qmail 7992 invoked by uid 11105); 14 Jul 1998 21:46:04 -0000 To: Jim Blandy Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 14 Jul 1998 14:46:04 -0700 In-Reply-To: Jim Blandy's message of "14 Jul 1998 09:47:29 -0400" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "JB" == Jim Blandy writes: JB> I think it's okay to require that one have the texinfo tools JB> installed to process texinfo source. That's very different from JB> requiring that Emacs be installed. I am saying is that many GNU packages already depend on the Texinfo package to preprocess the texinfo into info for distribution. It's an issue for the maintainer, not for the user. Personally, I find it annoying when packages, typically packages maintained by Cygnus, assume that texinfo is installed. I mean, you aren't thinking of requiring that the user have Jade, are you? Sure, it would be neat to have an integrated DSSSL engine in Guile, but is that really feasible? From owner-scwm-discuss@mit.edu Tue Jul 14 18:44:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03903 for scwm-discuss-outgoing; Tue, 14 Jul 1998 18:44:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03900 for ; Tue, 14 Jul 1998 18:44:23 -0400 Received: from netcom9.netcom.com by MIT.EDU with SMTP id AA04720; Tue, 14 Jul 98 18:43:19 EDT Received: (from ttn@localhost) by netcom9.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id PAA24570; Tue, 14 Jul 1998 15:41:48 -0700 (PDT) Date: Tue, 14 Jul 1998 15:41:48 -0700 (PDT) Message-Id: <199807142241.PAA24570@netcom9.netcom.com> From: thi To: jimb@red-bean.com Cc: mstachow@mit.edu, scwm-discuss@mit.edu, guile@cygnus.com In-Reply-To: (message from Jim Blandy on 14 Jul 1998 14:37:10 -0400) Subject: Re: generating a manual from annotations in source code Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > Do people feel that, if the documentation is a separate file, > programmers will be discouraged from writing docs, whereas, if the > documentation were mingled with the source, then programmers would > naturally write docstrings as they go along? sort of but not entirely. definitely docstring-grokking support reduces the inconvenience barrier to a point where it is indeed natural to throw a few words in the source. but i don't see it as a either-or situation; having a separate file encourages conceptual and task-oriented (ugh) documentation. i prefer access to both approaches w/ docstring-grepping relegated to a reference or internals manual. other programmers i know simply avoid documentation, claiming the required skillset makes all efforts by the non-skilled ineffective and actually dangerous (eg, out-of-sync docs causing catastrophic operator error). obviously there are many views. thi From owner-scwm-discuss@mit.edu Tue Jul 14 18:46:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03937 for scwm-discuss-outgoing; Tue, 14 Jul 1998 18:46:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03934 for ; Tue, 14 Jul 1998 18:46:18 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA24553; Tue, 14 Jul 98 18:44:56 EDT Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id SAA17406; Tue, 14 Jul 1998 18:44:52 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d03.phe-pa.concentric.net [209.31.155.111]) by cliff.concentric.net (8.8.8) id SAA14981; Tue, 14 Jul 1998 18:44:50 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id QAA24661; Tue, 14 Jul 1998 16:03:50 -0400 To: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code References: <199807120158.VAA08917@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Jim Blandy's message of "14 Jul 1998 14:37:10 -0400" Date: 14 Jul 1998 16:03:49 -0400 Message-Id: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 14 Jul 1998 14:37:10 -0400 >>>> Honorable Jim Blandy writes >>>> on the subject of "generating a manual from annotations in source code": >> Do people feel that, if the documentation is a separate file, >> programmers will be discouraged from writing docs, whereas, if the >> documentation were mingled with the source, then programmers would >> naturally write docstrings as they go along? Manual is manual and docstrings are docstrings. Both are necessary, and one cannot replace or autogenerate the other. The manual can include the docstrings though, e.g., as hypertext links whenever a function or a variable is mentioned (a la CLHS), but, again, this doesn't replace a coherent, purposefully written and thoroughly designed (yep, `designed'!) manual. IMHO, docstrings should be written and modified along with the code, should be kept there until the compile time, and then extracted and placed in a in a special location convenient for run-time documentation extraction (Emacs model). The larger, conceptual issues should be addressed in a separate manual, which can refer to the docstrings for formal details, while providing examples and explanations. Just my $0.02... -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. The software said it requires Windows 3.1 or better, so I installed Linux. From owner-scwm-discuss@mit.edu Tue Jul 14 22:06:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA05419 for scwm-discuss-outgoing; Tue, 14 Jul 1998 22:06:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id WAA05416 for ; Tue, 14 Jul 1998 22:06:54 -0400 Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id WAA12464; Tue, 14 Jul 1998 22:05:36 -0400 (EDT) To: scwm-discuss@mit.edu Subject: problems with scwm Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 14 Jul 1998 22:05:35 -0400 Message-ID: <87hg0j27io.fsf@jekyll.piermont.com> Lines: 40 Sender: owner-scwm-discuss@mit.edu Precedence: bulk First of all, I want to thank the developers of scwm. I looked at about eight or nine window managers in the last several days, and finally picked it after a tedious search. I now have my environment almost exactly right, with a few small exceptions. 1) I do not understand the (undocumented) set-edge-resistance! When I do a (set-edge-resistance! 100 100) I thought that I would then get a bit of "stickyness" when trying to move a window off the edge of the viewport, or when moving the mouse. The former happens, the latter does not. I want the latter, too. Anyone have any ideas/explanations? 2) I've been having a bit of trouble with window geometries. This may or may not have anything to do with scwm -- I'm not sure. For instance, if I set xclock -geometry -0-0 -digital -update 1 -chime -fg white -bg steelblue I would expect the xclock to appear touching the bottom of the screen in the corner. It doesn't quite work that way. It ends up floating many pixels off the corner :( Some applications (xterm) seem to work right, others (xclock) work slightly wrong. I never noticed this before I used scwm. I'm not sure if it is an scwm issue, though. 3) I'm having trouble configuring my .scwmrc to make the FvwmPanner module sticky. So far, I have to configure it manually when I run. I also cant make it undecorated, or manage to get it to display the names of the windows in teenyfont. All but the last are probably scwm issues -- the last may or may not be, I'm not sure. 4) I'm not entirely sure, based on the documentation, of how to change around the buttons in a title bar. I suppose this is just a documentation issue. Again, I want to thank you guys a lot. This has been a big improvement in my window manager quality-of-life. Perry From owner-scwm-discuss@mit.edu Tue Jul 14 22:42:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA05674 for scwm-discuss-outgoing; Tue, 14 Jul 1998 22:42:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA05671 for ; Tue, 14 Jul 1998 22:42:54 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA24958; Tue, 14 Jul 98 22:41:30 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id WAA12603; Tue, 14 Jul 1998 22:41:33 -0400 (EDT) Message-Id: <199807150241.WAA12603@jekyll.piermont.com> To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: problems with scwm In-Reply-To: Your message of "14 Jul 1998 22:05:35 EDT." <87hg0j27io.fsf@jekyll.piermont.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Jul 1998 22:41:33 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > 2) I've been having a bit of trouble with window geometries. This may > or may not have anything to do with scwm -- I'm not sure. For > instance, if I set > > xclock -geometry -0-0 -digital -update 1 -chime -fg white -bg steelblue > > I would expect the xclock to appear touching the bottom of the > screen in the corner. It doesn't quite work that way. It ends up > floating many pixels off the corner :( > Some applications (xterm) seem to work right, others (xclock) work > slightly wrong. I never noticed this before I used scwm. I'm not > sure if it is an scwm issue, though. Another data point: 1) This works fine in other window managers for people I've polled over IRC. 2) in case it matters, I've done a (window-style "xclock" #:no-titlebar #t #:use-style desk-widget) but I don't know that this has anything to do with it. Perry From owner-scwm-discuss@mit.edu Tue Jul 14 22:55:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA05847 for scwm-discuss-outgoing; Tue, 14 Jul 1998 22:55:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from voicenet.com (mail12.voicenet.com [207.103.0.6]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA05844 for ; Tue, 14 Jul 1998 22:55:48 -0400 Received: (qmail 20721 invoked from network); 15 Jul 1998 02:54:28 -0000 Received: from philax06.pa.107-pri.voicenet.com (HELO twz.twz.me) (207.103.157.107) by mail12.voicenet.com with SMTP; 15 Jul 1998 02:54:28 -0000 Date: Tue, 14 Jul 1998 22:51:06 -0400 (EDT) From: "\"Terrence W. Zellers\"" To: scwm-discuss@mit.edu Subject: building with recent guile snapshot. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Total newbie to SCWM and not that well versed in desktops generally (Chose scwm because I want to learn a scheme/lisp-like language anyway) FWIW the scm_make_vector function seems to have changed in the recent guile snapshot. To get scwm to build I removed the SCM_BOOL_F param from the function invocation in font.c, color.c and image.c. My build of scwm seems to have worked as I can start progs and did some simple basic configuration with the .scwmrc file. Seems rather unadorned compared to Fvwm (what I was using) but that may just be my failure to read through the docs and configure appropriately... Just a heads up and invite for comment. -- TWZ +-------------------------------------------------------------------------+ ! Copyright 1998 by Terrence W. Zellers. All rights explicitly reserved. | |-------------------------------------------------------------------------| | terrence.w.zellers@pobox.com | Warning: The Surgeon General has found | | | that smoking may cause some individuals | | | to ignore the Surgeon General. | +-------------------------------------------------------------------------+ From owner-scwm-discuss@mit.edu Tue Jul 14 23:20:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA06089 for scwm-discuss-outgoing; Tue, 14 Jul 1998 23:20:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA06086 for ; Tue, 14 Jul 1998 23:20:09 -0400 Received: from runyon.cygnus.com by MIT.EDU with SMTP id AA12714; Tue, 14 Jul 98 23:19:02 EDT Received: from lanl.gov (transitory142.lanl.gov [128.165.7.90]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id UAA17014; Tue, 14 Jul 1998 20:18:43 -0700 (PDT) Received: (from rosalia@localhost) by lanl.gov (8.8.5/8.8.5) id VAA06105; Tue, 14 Jul 1998 21:18:42 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Jul 1998 21:18:42 -0600 (MDT) From: Mark Galassi To: Jim Blandy Cc: Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: References: <199807120158.VAA08917@huis-clos.mit.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <13740.7863.350682.230274@papageno.lanl.gov> Sender: owner-scwm-discuss@mit.edu Precedence: bulk I fully agree with Jim on all his points about generating docs from source. I think that the real problem with Guile docs actually had to do with defining the product and its major categories more clearly. Jim and Tim and I and others had made several good starts at reorganizing the manual, but after a while we never felt that the manual's structure was quite right, and after a while we would have trouble getting motivated to do any detail work. I sometimes think the best thing might be to just write a long list of chapters on rather fine-grained topics, and end up with a manual that has 30 or more chapters but no hierarchy beyond that. That would be a good start, and the organization could improve later when people figure out how to break it up into more coarse-grained categories. From owner-scwm-discuss@mit.edu Tue Jul 14 23:22:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA06132 for scwm-discuss-outgoing; Tue, 14 Jul 1998 23:22:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA06128; Tue, 14 Jul 1998 23:22:49 -0400 Message-Id: <199807150322.XAA06128@huis-clos.mit.edu> To: "\"Terrence W. Zellers\"" cc: scwm-discuss@mit.edu Subject: Re: building with recent guile snapshot. In-reply-to: Your message of "Tue, 14 Jul 1998 22:51:06 EDT." Date: Tue, 14 Jul 1998 23:22:49 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk zellert@twz.twz.me writes: > > Total newbie to SCWM and not that well versed in desktops generally > (Chose scwm because I want to learn a scheme/lisp-like language anyway) > > FWIW the scm_make_vector function seems to have changed in the > recent guile snapshot. To get scwm to build I removed the SCM_BOOL_F > param from the function invocation in font.c, color.c and image.c. > My build of scwm seems to have worked as I can start progs and did > some simple basic configuration with the .scwmrc file. > This should be fixed in the nightly snapshots soon, though perhaps not until tomorrow's. > Seems rather unadorned compared to Fvwm (what I was using) but > that may just be my failure to read through the docs and configure > appropriately... > > Just a heads up and invite for comment. > Try running with decor.scwmrc in the sample.scwmrc directory, it shows a few examples of what you can do with scwm window decorations. There's a screen shot on the scwm homepage which shows the different decorations possible with that. However, flexibility in this area is planned to increase even more with time. In particular, we want to use loadable modules for window decorations at some point. I think that is the only way to make all users, from those who want no window decorations at all, and want to gain the associated memory savings, to those who want wacky shaped pixmap Enlightemnet-style decorations, and are willing to pay the cost in memory and damage to their optic nerve (just kidding about that last part :-), as well as the majority of middle-of-the-road users who want a simple Motif or Win95 or fvwm-type look. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Tue Jul 14 23:43:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA06519 for scwm-discuss-outgoing; Tue, 14 Jul 1998 23:43:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA06516 for ; Tue, 14 Jul 1998 23:43:45 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01490; Tue, 14 Jul 98 23:42:20 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id XAA12801; Tue, 14 Jul 1998 23:42:24 -0400 (EDT) Message-Id: <199807150342.XAA12801@jekyll.piermont.com> To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: problems with scwm In-Reply-To: Your message of "Tue, 14 Jul 1998 23:12:24 EDT." <199807150312.XAA06048@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 14 Jul 1998 23:42:23 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > It _should_ do the same thing as the fvwm2 EdeResistance command, > since the virtual desktop stuff has not been rewritten yet. If it > doesn't, that is a bug. It doesn't. I guess it is a bug. :( BTW, "edge-resistance" is a good name for it. > The problem here is that scwm is not properly respecting window > gravity hints, in particular when changing the border size. I am now > rewriting most of the placement code, and one result should be a fix > for this prooblem. I'm not sure if there is a very good workaround > right now. It is okay. I can just manually move my clock and pager when I start up for now. It is annoying, but hardly fatal -- what is more important is knowing that I should quit fiddling with my init file to try to fix it. > > 3) I'm having trouble configuring my .scwmrc to make the FvwmPanner > > module sticky. So far, I have to configure it manually when I > > run. I also cant make it undecorated, or manage to get it to display > > the names of the windows in teenyfont. All but the last are > > probably scwm issues -- the last may or may not be, I'm not sure. > > > > I think if you add a window-style command for FvwmPager, like this: > > (window-style "FvwmPager" #:no-titlebar #t #:use-style desk-widget) Weird. That worked on eliminating the titlebar, where (window-style "FvwmPager" #:notitlebar #t) didn't do anything remotely right. Anyway, I now have it sticking and undecorated, and it looks great. > Displaying the names of the windows actually _is_ a scwm issue, I > think - it is not sending quite all the information that fvwm2 > does. But I think fvwm module support will improve soon - I will fix > some of these issues myself, and someone has recently volunteered to > do more work on the fvwm module support. Cool. > > 4) I'm not entirely sure, based on the documentation, of how to change > > around the buttons in a title bar. I suppose this is just a > > documentation issue. > > Do you mean change the way the buttons look, or change the actions > bound to them? > > I realize the documentation is poor right now, but it has been > improving pretty rapidly lately. I'm sort of interested in both -- I want to rearrange the buttons, change their appearance, add a couple, and bind things to them. > > Again, I want to thank you guys a lot. This has been a big improvement > > in my window manager quality-of-life. > > Thanks, your comments are appreciated, and maybe we can make it work > even better based on your problem reports. I'm happy to pitch in, too, btw, to the extent possible. I can write lisp okay, but my X hacking leaves something to be desired. :( I'm probably of most use documentation hacking, but unfortunately I don't know enough yet to try to do much on that. Perry From owner-scwm-discuss@mit.edu Wed Jul 15 00:14:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA06786 for scwm-discuss-outgoing; Wed, 15 Jul 1998 00:14:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA06781; Wed, 15 Jul 1998 00:14:32 -0400 Message-Id: <199807150414.AAA06781@huis-clos.mit.edu> To: Danius Michaelides cc: scwm-discuss@mit.edu Subject: Re: bug in scwm 0.7a In-reply-to: Your message of "Tue, 14 Jul 1998 21:22:50 BST." Date: Wed, 15 Jul 1998 00:14:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk danius@duff.org writes: > On Tue, 14 Jul 1998, Maciej Stachowiak wrote: > > > This is a silly way to run the pager, granted. We hope to have a > > native pager soon which will eliminate this pain. > > Is it likely that this native pager will be swallow-able by FvwmButtons? > Not that its a great problem if it isnt, but it brings me neatly onto > the subject of Fvwm module support. Recently, I've been converting my > Fvwm2 config to scwm. Now i've got most of the way there, but fell > over on the module support. I use FvwmIconMan, and FvwmButtons with a > swallowed FvwmPager. > > I found the fvwm module support in fvwm-module.scm and fvwm-eval.scm abit > incomplete, and have been hacking things to enable my config to work. > That's great, I would love to see your changes. I have not been able to improve this stuff as rapidly as I had hoped, and your changes would help a lot. > - it seems that if a module sends an undefined command, it causes > scwm to die with "scwm: Error communicating with module ". Possibly > caused by some kind of problem in kill-fvwm-module ? > You mean scwm actually dies, as opposed to just closing the module? Does this still happen with recent snapshots? I thought I'd managed to get scwm to kill modules cleanly without dying... > A solution, put a catch around > (eval-fvwm-command command fmod (id->window window-id)) > > (catch #t > (lambda() (eval-fvwm-command command > fmod > (id->window window-id))) > (lambda args (display "Error evaling packet: ") > (write packet) > (newline)) > ) It should probably do that anyway, one bad command should not kill the module. > > - the fvwm commands dont seem to be work interactively. This > seems to be because eval-fvwm-command always gets called > with the optional window argument, which defaults to a get-window call. > This window argument is #f (i think) when the fvwm module didnt supply > a valid, eg when it was for interactive use. So we need something > like: > (let ((w (id->window window-id))) > (if w > (eval-fvwm-command command fmod w) > (eval-fvwm-command command fmod))) > You're right, actually, the code should explicitly check for the Window ID being 0, IMO. > - Added Lower, Resize and Exec (so far). > > - Resize raises a problem wih the above solution. Since we get-window > is already being called for us, we use (interactive-resize window). > Except now we have to click (and release) on the window, then drag > out the new size of the window. As opposed to the more usual > interactive-resize without the window argument, where you click, > and drag in one motion. So i'm not sure if the above is really the > right thing todo, and instead whether each individual fvwm command > should decide how it gets the window context if its unspecified. > That might be smart. The primitives will already DTRT if you pass no window argument. Perhaps the window arguments to fvwm commands should default to #f, and any fvwm command that needs a window should check the window argument, and just not pass any at all if it is #f. The primitives should DTRT with respect to their own window selection. > eg with variable arguments to eval-fvwm-command, we'd have: > (define-fvwm-command "Raise" > (if window > (raise-window window))) > but with the current way of calling eval-fvwm-command, you'd have > this: > (define-fvwm-command "Raise" > (raise-window (if window window (get-window)))) > Under the model of not imposing get-window, this would be: (define-fvwm-command "Raise" (if window (raise-window window) (raise-window))) > - Added Eval, to basically enable buttons in FvwmButton to run > some specified code; > (define-fvwm-command "Eval" > (eval-string args)) > and > "*FvwmButtons(Title xterm, Icon Shell.xpm, > Action `Eval (run-xterm)` Frame 1)" > But this is slightly unsatifactory, because the code you specify > doesnt have access to any context (eg window). > That's a pretty cool idea. > Anyway, i just thought i'd be vocal about this stuff, to see what the > general opinion is of persuing it further (I'm happy todo so, and > supply a patch, when i'm done) and what is the right thing todo. Personally, I am really glad to see someone working on this, and I'd love to see your changes, in either their current or any future improved state. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 15 02:12:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA07301 for scwm-discuss-outgoing; Wed, 15 Jul 1998 02:12:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA07298 for ; Wed, 15 Jul 1998 02:12:15 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA16060; Wed, 15 Jul 98 02:10:50 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id CAA14009; Wed, 15 Jul 1998 02:10:54 -0400 (EDT) To: scwm-discuss@mit.edu Subject: one more problem... Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 15 Jul 1998 02:10:46 -0400 Message-Id: <87vhozlk49.fsf@jekyll.piermont.com> Lines: 18 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've noticed that double click actions (like binding an action to double clicking an icon) don't seem to work. Am I correct, or am I crazy? I have the following code in my .scwmrc, and yet, no matter how often I double click on an icon, nothing ever happens -- it certainly never de-iconifies. (define (move-or-deiconify) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (deiconify)))) (bind-mouse 'icon 1 move-or-deiconify) Perry From owner-scwm-discuss@mit.edu Wed Jul 15 02:24:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA07389 for scwm-discuss-outgoing; Wed, 15 Jul 1998 02:24:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA07382 for ; Wed, 15 Jul 1998 02:24:13 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id IAA19691 for scwm-discuss@huis-clos.mit.edu; Wed, 15 Jul 1998 08:22:51 +0200 (CEST) Received: (qmail 394 invoked by uid 115); 14 Jul 1998 19:06:31 -0000 To: scwm-discuss@mit.edu Subject: Re: -LNONE/lib in 7/14 snapshot References: <35ad50fa.52285011@mailhost> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Tue_Jul_14_21:06:30_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 14 Jul 1998 21:06:30 +0200 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 14 Jul 1998 12:39:20 GMT" Message-ID: Lines: 47 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Tue_Jul_14_21:06:30_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Tue, 14 Jul 1998 12:39:20 GMT >>>>> dale.smith@bellhow.com (Dale Smith) said: Dale> The 19980714 snapshot is trying to link with -LNONE/lib on my Dale> system. Sorry, my oversight. Try this patch: --Multipart_Tue_Jul_14_21:06:30_1998-1 Content-Type: text/plain; charset=US-ASCII --- scwm/configure.orig Tue Jul 14 21:02:32 1998 +++ scwm/configure Tue Jul 14 21:02:37 1998 @@ -2773,8 +2773,13 @@ -GUILE_LIBS_PRE="-L${prefix}/lib" -GUILE_INCLUDES="-L${prefix}/include" +if test "x$prefix" = "xNONE"; then + GUILE_LIBS_PRE="-L$ac_default_prefix/lib" + GUILE_INCLUDES="-L$ac_default_prefix/include" +else + GUILE_LIBS_PRE="-L$prefix/lib" + GUILE_INCLUDES="-L$prefix/include" +fi # Check whether --with-guile-prefix or --without-guile-prefix was given. if test "${with_guile_prefix+set}" = set; then --Multipart_Tue_Jul_14_21:06:30_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Tue_Jul_14_21:06:30_1998-1-- From owner-scwm-discuss@mit.edu Wed Jul 15 02:24:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA07390 for scwm-discuss-outgoing; Wed, 15 Jul 1998 02:24:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA07383 for ; Wed, 15 Jul 1998 02:24:13 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id IAA19694 for scwm-discuss@huis-clos.mit.edu; Wed, 15 Jul 1998 08:22:52 +0200 (CEST) Received: (qmail 417 invoked by uid 115); 14 Jul 1998 19:21:25 -0000 To: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <19980713193856Z.marko@cs.uni-frankfurt.de> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 14 Jul 1998 21:21:25 +0200 In-Reply-To: Marko Schuetz's message of "Mon, 13 Jul 1998 19:38:56 +0200" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 13 Jul 1998 19:38:56 +0200 >>>>> Marko Schuetz said: Marko> Does anyone know if this behavior of the apps mentioned is Marko> intentional? Is there a reason for insisting on events with Marko> synthetic=NO? AFAIK xterm accepts synthetic *key*presses only if you instruct it to (e.g. Allow SendEvents in the menu). Security concerns, it seems - but I can't quite figure why. Maybe this afflicts mouse-events as well. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Jul 15 03:05:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA07954 for scwm-discuss-outgoing; Wed, 15 Jul 1998 03:05:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA07951 for ; Wed, 15 Jul 1998 03:05:12 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA20194; Wed, 15 Jul 98 03:03:46 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA24242; Wed, 15 Jul 1998 10:03:47 +0300 To: Maciej Stachowiak Cc: Danius Michaelides , scwm-discuss@mit.edu Subject: Re: bug in scwm 0.7a References: <199807150414.AAA06781@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Jul 1998 10:03:47 +0300 In-Reply-To: Maciej Stachowiak's message of "Wed, 15 Jul 1998 00:14:31 EDT" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Under the model of not imposing get-window, this would be: > > (define-fvwm-command "Raise" > (if window > (raise-window window) > (raise-window))) If window was a typical scheme optional argument (i.e. - either a list containing a window or nil), then it could just be: (define-fvwm-command "Raise" (apply raise-window window)) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jul 15 03:18:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA08094 for scwm-discuss-outgoing; Wed, 15 Jul 1998 03:18:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA08091 for ; Wed, 15 Jul 1998 03:18:02 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21178; Wed, 15 Jul 98 03:16:35 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA24317; Wed, 15 Jul 1998 10:16:32 +0300 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: problems with scwm References: <87hg0j27io.fsf@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Jul 1998 10:16:32 +0300 In-Reply-To: "Perry E. Metzger"'s message of "14 Jul 1998 22:05:35 -0400" Message-Id: Lines: 87 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > First of all, I want to thank the developers of scwm. I looked at > about eight or nine window managers in the last several days, and > finally picked it after a tedious search. I now have my environment > almost exactly right, with a few small exceptions. > > 1) I do not understand the (undocumented) set-edge-resistance! > When I do a (set-edge-resistance! 100 100) I thought that I would > then get a bit of "stickyness" when trying to move a window off the > edge of the viewport, or when moving the mouse. The former happens, > the latter does not. I want the latter, too. Anyone have any > ideas/explanations? ;;; Use alternative auto-placement fcn. (set-smart-placement-is-really-smart! #t) ;;; (set-edge-resistance! time distance) ;;; Wait TIME seconds when mouse is at the edge of the viewport before ;;; scrolling. ;;; The mouse must move DISTANCE pixels when dragging a window past ;;; the edge of the viewport before the window actually moves. (set-edge-resistance! 250 0) ;;; How much (in pixels) to scroll viewport in x & y dir when ;;; encountering the edge. (set-edge-scroll! (%x 100) (%y 100)) ;;; Whether or not to wrap around when scrolling the view #t/#f for X dir ;;; & #t/#f for Y dir. (set-edge-wrap! #f #f) > 2) I've been having a bit of trouble with window geometries. This may > or may not have anything to do with scwm -- I'm not sure. For > instance, if I set > > xclock -geometry -0-0 -digital -update 1 -chime -fg white -bg steelblue > > I would expect the xclock to appear touching the bottom of the > screen in the corner. It doesn't quite work that way. It ends up > floating many pixels off the corner :( > Some applications (xterm) seem to work right, others (xclock) work > slightly wrong. I never noticed this before I used scwm. I'm not > sure if it is an scwm issue, though. I was about to report the same bug! A little testing indicates that windows seem to always be placed as if #:border-width and #:handle-width are = 6. E.g. - I have the following in my .scwmrc: (window-style "*" #:fg "Wheat" #:bg "DimGrey" #:icon "unknown1.xpm" #:icon-box (list (x- 70) 1 69 (y- 141)) #:border-width 4 #:handle-width 4 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:int-override #t #:decorate-transient #t #:PPosition-hint #f #:lenience #t) When I do: xterm -geometry -0-0 & the window appears at (1550, 420), 4 pixels off from the lower right corner of the screen. When I change #:border-width and #:handle-width to 6, re-eval the form, and pop up a new xterm as above, the window still shows up at (1550, 420), but exactly lines up with the lower right corner. Etc... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jul 15 03:24:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA08159 for scwm-discuss-outgoing; Wed, 15 Jul 1998 03:24:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA08156 for ; Wed, 15 Jul 1998 03:24:42 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA07026; Wed, 15 Jul 98 03:23:33 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA24350; Wed, 15 Jul 1998 10:23:08 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: problems with scwm References: <199807150342.XAA12801@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Jul 1998 10:23:07 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 14 Jul 1998 23:42:23 -0400" Message-Id: Lines: 41 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > > > 3) I'm having trouble configuring my .scwmrc to make the FvwmPanner > > > module sticky. So far, I have to configure it manually when I > > > run. I also cant make it undecorated, or manage to get it to display > > > the names of the windows in teenyfont. All but the last are > > > probably scwm issues -- the last may or may not be, I'm not sure. > > > > > > > I think if you add a window-style command for FvwmPager, like this: > > > > (window-style "FvwmPager" #:no-titlebar #t #:use-style desk-widget) > > Weird. That worked on eliminating the titlebar, where > > (window-style "FvwmPager" #:notitlebar #t) > > didn't do anything remotely right. > > Anyway, I now have it sticking and undecorated, and it looks great. Is this an exact quote - i.e. - did you leave out the dash in the keyword when you were actually doing this? If so, then that explains the problem and it's also an annoyance I've experienced. There seems to be a lack of checking of keyword arguments. For example, I was trying to use #:other-proc to solve a placement problem. I had: (window-style "Netscape: Question" #:sticky #:other-proc stack-windows) I thought it was just #:sticky or #:no-sticky. I didn't realize those two keywords took arguments. I don't know what it was doing, but stack-windows was never getting executed. In any case, no complaints were ever printed by scwm. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jul 15 04:08:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA08882 for scwm-discuss-outgoing; Wed, 15 Jul 1998 04:08:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA08879 for ; Wed, 15 Jul 1998 04:08:29 -0400 Received: from king.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA25412; Wed, 15 Jul 98 04:07:02 EDT Received: (from marko@localhost) by king.ki.informatik.uni-frankfurt.de (8.7.1/8.7.1) id KAA04182; Wed, 15 Jul 1998 10:06:55 +0200 (METDST) Date: Wed, 15 Jul 1998 10:06:55 +0200 (METDST) Message-Id: <199807150806.KAA04182@king.ki.informatik.uni-frankfurt.de> From: Marko Schuetz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Cc: guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: <13740.7863.350682.230274@papageno.lanl.gov> References: <199807120158.VAA08917@huis-clos.mit.edu> <13740.7863.350682.230274@papageno.lanl.gov> X-Mailer: VM 6.34 under Emacs 20.2.1 Reply-To: marko@cs.uni-frankfurt.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk If we are talking about a reference manual describing the way the implementation works, as I think we are, I suggest to borrow from Haskells literate style. In literate Haskell files code is specifically marked. A '>' in the first column of a line marks this line as code. Alternatively, \begin{code} and \end{code} mark a section of code. This makes it very convenient to document the whole program using LaTeX and run the exact same files through LaTeX producing the documentation or through the compiler producing the executable. Marko From owner-scwm-discuss@mit.edu Wed Jul 15 07:25:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA09620 for scwm-discuss-outgoing; Wed, 15 Jul 1998 07:25:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA09617 for ; Wed, 15 Jul 1998 07:25:20 -0400 Received: from runyon.cygnus.com by MIT.EDU with SMTP id AA08391; Wed, 15 Jul 98 07:23:52 EDT Received: from lanl.gov (transitory142.lanl.gov [128.165.7.90]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id EAA03981; Wed, 15 Jul 1998 04:23:54 -0700 (PDT) Received: (from rosalia@localhost) by lanl.gov (8.8.5/8.8.5) id FAA08724; Wed, 15 Jul 1998 05:23:52 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 15 Jul 1998 05:23:51 -0600 (MDT) From: Mark Galassi To: marko@cs.uni-frankfurt.de Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: <199807150806.KAA04182@king.ki.informatik.uni-frankfurt.de> References: <199807120158.VAA08917@huis-clos.mit.edu> <13740.7863.350682.230274@papageno.lanl.gov> <199807150806.KAA04182@king.ki.informatik.uni-frankfurt.de> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <13740.37161.815894.448665@papageno.lanl.gov> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Marko> If we are talking about a reference manual describing the Marko> way the implementation works, as I think we are, I suggest Marko> to borrow from Haskells literate style. We are not describing how the implementation works. We are describing the various APIs and how the programmer should use them. From owner-scwm-discuss@mit.edu Wed Jul 15 11:47:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA11228 for scwm-discuss-outgoing; Wed, 15 Jul 1998 11:47:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA11225 for ; Wed, 15 Jul 1998 11:47:36 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA00454; Wed, 15 Jul 98 11:46:35 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA15982; Wed, 15 Jul 1998 11:46:13 -0400 (EDT) Message-Id: <199807151546.LAA15982@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: perry@piermont.com, Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: problems with scwm In-Reply-To: Your message of "15 Jul 1998 10:23:07 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jul 1998 11:46:13 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > > > (window-style "FvwmPager" #:no-titlebar #t #:use-style desk-widget) > > > > Weird. That worked on eliminating the titlebar, where > > > > (window-style "FvwmPager" #:notitlebar #t) > > > > didn't do anything remotely right. > > > > Anyway, I now have it sticking and undecorated, and it looks great. > > Is this an exact quote - i.e. - did you leave out the dash in the > keyword when you were actually doing this? Groan. Yes, I did. > If so, then that explains the problem It does. > and it's also an annoyance I've experienced. There seems to be a > lack of checking of keyword arguments. Indeed, that is an annoyance. Perry From owner-scwm-discuss@mit.edu Wed Jul 15 12:06:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11397 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:06:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11394 for ; Wed, 15 Jul 1998 12:06:34 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA12128; Wed, 15 Jul 98 12:05:16 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA16086; Wed, 15 Jul 1998 12:05:20 -0400 (EDT) Message-Id: <199807151605.MAA16086@jekyll.piermont.com> To: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: Your message of "14 Jul 1998 16:03:49 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jul 1998 12:05:20 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk It seems painfully clear to me that the problem here is the distinction between "tutorial" and "reference manual". It seems fine to me for a skeletal reference manual to somehow slurp in (in an intelligent way) the contents of doc strings in order to assure the reference manual is always 100% up to date. It also seems equally clear that a human organized manual must exist that points people at how to figure out how the parts fit together -- such a manual is either the "programmers guide" or "tutorial" or something similar, but it is not the reference manual. Hopefully, hyperlinks exist from the one to the other (in the online version) to assure that you can find out the exact definition of a function or where it fits in to the wider scheme of things. Perry From owner-scwm-discuss@mit.edu Wed Jul 15 12:08:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11429 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:08:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11426 for ; Wed, 15 Jul 1998 12:08:38 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06731; Wed, 15 Jul 98 12:07:46 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA20031; Wed, 15 Jul 1998 09:06:51 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <19980713193856Z.marko@cs.uni-frankfurt.de> From: Greg Badros Date: 15 Jul 1998 09:06:51 -0700 In-Reply-To: Robert Bihlmeyer's message of "14 Jul 1998 21:21:25 +0200" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > AFAIK xterm accepts synthetic *key*presses only if you instruct it to > (e.g. Allow SendEvents in the menu). Security concerns, it seems - but > I can't quite figure why. Maybe this afflicts mouse-events as well. Because if you've `xhost +'d, I can do whatever I want w/ your account if you've got a shell running in an xterm accepting synthetic events. Greg From owner-scwm-discuss@mit.edu Wed Jul 15 12:13:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11553 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:13:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11549 for ; Wed, 15 Jul 1998 12:13:41 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14334; Wed, 15 Jul 98 12:12:30 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA20038; Wed, 15 Jul 1998 09:12:28 -0700 (PDT) To: "\"Terrence W. Zellers\"" Cc: scwm-discuss@mit.edu Subject: Re: building with recent guile snapshot. References: From: Greg Badros Date: 15 Jul 1998 09:12:28 -0700 In-Reply-To: "\"Terrence W. Zellers\""'s message of "Tue, 14 Jul 1998 22:51:06 -0400 (EDT)" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "\"Terrence W. Zellers\"" writes: > Seems rather unadorned compared to Fvwm (what I was using) but > that may just be my failure to read through the docs and configure > appropriately... Check out the various sample scwmrc files in the sample.scwmrc directory -- the default system configuration is pretty minimal and doesn't show off many of the features. Perhaps you could be more specific w.r.t. what you think is missing relative to fvwm2? Greg From owner-scwm-discuss@mit.edu Wed Jul 15 12:18:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11698 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:18:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11693 for ; Wed, 15 Jul 1998 12:18:04 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA15446; Wed, 15 Jul 98 12:16:53 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA16113; Wed, 15 Jul 1998 12:16:50 -0400 (EDT) Message-Id: <199807151616.MAA16113@jekyll.piermont.com> To: Mark Galassi Cc: Jim Blandy , Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: Your message of "Tue, 14 Jul 1998 21:18:42 MDT." <13740.7863.350682.230274@papageno.lanl.gov> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jul 1998 12:16:50 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk As I say in another message, the issue is the distinction between the "programmer's guide", "tutorial" or whatever you want to call it, and the "reference manual". The difficulty in structuring the document you seem to have hit is precisely this difficulty. You need a breezy, reasonbly high level document that takes a user through the steps of doing various tasks, and then you need an exhaustive reference manual that contains every function in every module. .pm Mark Galassi writes: > > I fully agree with Jim on all his points about generating docs from > source. > > I think that the real problem with Guile docs actually had to do with > defining the product and its major categories more clearly. > > Jim and Tim and I and others had made several good starts at > reorganizing the manual, but after a while we never felt that the > manual's structure was quite right, and after a while we would have > trouble getting motivated to do any detail work. > > I sometimes think the best thing might be to just write a long list of > chapters on rather fine-grained topics, and end up with a manual that > has 30 or more chapters but no hierarchy beyond that. That would be a > good start, and the organization could improve later when people > figure out how to break it up into more coarse-grained categories. From owner-scwm-discuss@mit.edu Wed Jul 15 12:21:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11801 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:21:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11798 for ; Wed, 15 Jul 1998 12:21:42 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10665; Wed, 15 Jul 98 12:20:50 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA20041; Wed, 15 Jul 1998 09:17:07 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: problems with scwm References: <199807150342.XAA12801@jekyll.piermont.com> From: Greg Badros Date: 15 Jul 1998 09:17:07 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 14 Jul 1998 23:42:23 -0400" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I'm happy to pitch in, too, btw, to the extent possible. I can write > lisp okay, but my X hacking leaves something to be desired. :( > > I'm probably of most use documentation hacking, but unfortunately I > don't know enough yet to try to do much on that. Great-- we're hopefully getting close to deciding something more about at least the documentation strings to accompany each primitive. When we have some guidelines, all help with documentation will be *much* appreciated since there is a lot to document. For now, I'd just keep playing with SCWM and keep the dialogue open with your ideas and questions. Thanks for the feedback. Greg From owner-scwm-discuss@mit.edu Wed Jul 15 12:21:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11815 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:21:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11806; Wed, 15 Jul 1998 12:21:51 -0400 Message-Id: <199807151621.MAA11806@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-reply-to: Your message of "Wed, 15 Jul 1998 12:05:20 EDT." <199807151605.MAA16086@jekyll.piermont.com> Date: Wed, 15 Jul 1998 12:21:51 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > It seems painfully clear to me that the problem here is the > distinction between "tutorial" and "reference manual". > > It seems fine to me for a skeletal reference manual to somehow slurp > in (in an intelligent way) the contents of doc strings in order to > assure the reference manual is always 100% up to date. > > It also seems equally clear that a human organized manual must exist > that points people at how to figure out how the parts fit together -- > such a manual is either the "programmers guide" or "tutorial" or > something similar, but it is not the reference manual. Hopefully, > hyperlinks exist from the one to the other (in the online version) to > assure that you can find out the exact definition of a function or > where it fits in to the wider scheme of things. > In case it wasn't previously clear, this is my intention and my point: the reference manual can be generated semi-automatically, and I believe there are benefits to doing so. However, there still needs to be a user's guide or tutorial or whatever you want to call it. In the case of scwm, these may end up just being different chapters or groups of chapters in the same manual, but the general idea is the same. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 15 12:35:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12108 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:35:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12103; Wed, 15 Jul 1998 12:35:11 -0400 Message-Id: <199807151635.MAA12103@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: problems with scwm In-reply-to: Your message of "Tue, 14 Jul 1998 23:42:23 EDT." <199807150342.XAA12801@jekyll.piermont.com> Date: Wed, 15 Jul 1998 12:35:10 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > It _should_ do the same thing as the fvwm2 EdeResistance command, > > since the virtual desktop stuff has not been rewritten yet. If it > > doesn't, that is a bug. > > It doesn't. I guess it is a bug. :( > I'll see if I can reproduce this. > > Weird. That worked on eliminating the titlebar, where > > (window-style "FvwmPager" #:notitlebar #t) > > didn't do anything remotely right. > As someone else mentioned, this is because the dash is missing, and the style handling code does not currently flag bad keywords or othewise mis-structured keyword lists. I will try to fix this soon, as it is clearly an annoyance. > > I'm sort of interested in both -- I want to rearrange the buttons, > change their appearance, add a couple, and bind things to them. > You can use bind-mouse to bind an action to a title button, for example like this: (bind-mouse 'button-1 1 minimize) The button numbering is a bit strange. Button 1 is the leftmost, button 2 is the rightmost, button 3 is the second from the left, and so on. There is an arbitrary limit of 10 buttons currently. This is considered a bug, but should not be a huge problem in pratice. To change the appearance of a button, you can use button-style. See decor.scwmrc for a number of examples. I think button visibility may currently be determined in a somwhat silly way, so that dynamically changing the number of buttons will not work, but if you bind an action for a button in your .scwmrc, it should automatically be visible on the titlebar. > > > > Thanks, your comments are appreciated, and maybe we can make it work > > even better based on your problem reports. > > I'm happy to pitch in, too, btw, to the extent possible. I can write > lisp okay, but my X hacking leaves something to be desired. :( > > I'm probably of most use documentation hacking, but unfortunately I > don't know enough yet to try to do much on that. > We're always glad to have more help. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Wed Jul 15 12:48:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12265 for scwm-discuss-outgoing; Wed, 15 Jul 1998 12:48:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA12262 for ; Wed, 15 Jul 1998 12:48:57 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA22974; Wed, 15 Jul 98 12:48:05 EDT Received: from mcfeely.concentric.net (mcfeely [207.155.184.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id MAA29186; Wed, 15 Jul 1998 12:48:09 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d22.phe-pa.concentric.net [209.31.155.34]) by mcfeely.concentric.net (8.8.8) id MAA04477; Wed, 15 Jul 1998 12:48:08 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA26698; Wed, 15 Jul 1998 12:47:19 -0400 To: scwm-discuss@mit.edu Subject: Re: building with recent guile snapshot. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: "\"Terrence W. Zellers\""'s message of "Tue, 14 Jul 1998 22:51:06 -0400 (EDT)" Date: 15 Jul 1998 12:47:19 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on Tue, 14 Jul 1998 22:51:06 -0400 (EDT) >>>> Honorable "\"Terrence W. Zellers\"" writes >>>> on the subject of "building with recent guile snapshot.": >> Seems rather unadorned compared to Fvwm (what I was using) but >> that may just be my failure to read through the docs and configure >> appropriately... sample.scwmrc/sds.scwmrc is specifically designed to be well-adorned. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Bus error -- please leave by the rear door. From owner-scwm-discuss@mit.edu Wed Jul 15 13:27:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12509 for scwm-discuss-outgoing; Wed, 15 Jul 1998 13:27:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA12506 for ; Wed, 15 Jul 1998 13:27:08 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28671; Wed, 15 Jul 98 13:27:11 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA20103; Wed, 15 Jul 1998 10:26:48 -0700 (PDT) To: scwm-discuss@mit.edu, guile@cygnus.com Subject: Documentation conventions refocusing... From: Greg Badros Date: 15 Jul 1998 10:26:48 -0700 In-Reply-To: Maciej Stachowiak's message of "Wed, 15 Jul 1998 12:21:51 EDT" Message-Id: Lines: 125 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm really excited to see the amount of discussion we've had about generating documentation for scwm and guile. I'd like to refocus the conversation so that we can make some real progress. We all agree that there's a difference between a reference manual and a tutorial or other higher-level user guide. My initial motivation, which the scwm developers and guile developers seem to share, is to improve the reference documentation of the APIs for scwm and guile. There are lots of arguments as to why documenting primitives should be done as close to the implementation as possible (ease of update, awareness of documentation, consideration of the API when writing the primitive, etc.). There are also many success stories involving the approach of embedding documentation in the source code. There is a consensus that this is a reasonable way to produce some subset of the reference manual (and a very important subset that is best to happen early). So now the technical question we must answer is: What should that source code markup look like and what conventions should we use? There are two kinds of source we must annotate: C primitives and scheme library procedures. The former (to me the more important, since the compiled code is less available to the end user) has an example format in scwm/binding.c. It is based on using SCWM_PROC, a macro that uses guile's slightly less specific SCM_PROC. An extraction tool (written in perl for now--there is general agreement that it should instead be written in guile ultimately) scans and extracts the comments (see scwm's utilities/dev/extract-docs). There are a couple issues: 1) Should the doc string be a final string argument to the macro, or should it just be a slightly-stylized comment? I'm in favor of the latter, since the extraction is extra-linguistic, and needn't use a language-level mechanism. Jim made the good point that a macro argument and that macros expansion is subject to normal conditional compilation, so if a feature were compiled out of binary, then the documentation would appropriately be elided as well. However, it's easy to run the preprocessor w/o removing comments and still look for the stylized comment, so I think if differing documentation for alternate compile-time options is an issue, we can still handle it either way. Additionally, using comments permits what I called concept references; my example was the specification of keystrokes --- the place to best put that documentation is near the C function that parses key specifiers, and that documentation could be linked to by all the primitives and procedures that use a key-specifier argument (ultimately perhaps the key-specifier should be a regular primitive anyway, so maybe the need for separate "concept" comments on ordinary C functions will disappear as some of our abstractions improve -- in this specific case, e.g., as the new event model is written). Another big advantage of comments is fewer quoting issues -- the only special sequence is '*/'. Strings can cause backslashitis-- ponder documenting the regular expression engine in guile -- much harder if you must worry about C's literal string quoting. 2) Within the documentation, what should the markup look like? In particular, there has been some consensus to generate SGML (specifically DocBook DTD) from the comments. This seems like the right thing to me, as there are others working on the ability to generate various formats from the DocBook DTD, and a handful of useful formats are already able to be produced. The subquestion is: To what extent should conventions be used to reduce the amount of by-hand tagging in the source comment? It was pointed out that JavaDoc gains a bit of leverage by knowing something about the language. Similarly, I think our documentation can benefit from conventions biased for our application. The goal here is to make writing the documentation as simple and painless as possible, anticipating that this will increase the quality and ease-of-maintenance of the documentation. Note that these conventions are just in the embedded comments (or macro argument strings) and are understood by the extraction tool which then writes pure DocBook SGML as output. There are two special cases for which some conventions are absolutely necessary: 1) formal arguments, and 2) references to other primitives/procedures. E.g., an all-uppercase identifier in the documentation should refer to a formal parameter name (a warning can be given if it does not) and it should be tagged appropriately; similarly, a legal scheme identifier embedded in between ` and ' can be a reference to another primitive/procedure. Thus we can write: SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, (SCM contexts, SCM key)) /** Remove any bindings attached to KEY in given CONTEXTS. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) KEY is a string giving the key-specifier (e.g., M-Delete for META+Delete). See also `bind-key'. */ Note the reduction in the number of tags needed for the above example by the two simple and unambiguous conventions. Where convention does not make the logical content obvious, we need to use tags so that we preserve as much information as possible. I also suggest using \< to expand into <, and \& to expand into & (instead of < and & which I think are a lot less readable). We could also forbid spaces from following `<' or '&', and if we see a space, just take that to mean that we want the literal character (since those characters will almost always be separated from adjacent identifiers by spaces when they are used for themselves instead of markup). Though this is summary is longer than I'd hoped, I think it is imperative that we at least make this handful of design decision very soon -- and discuss any other design decisions that need to be made before we can start writing the documentation. Bottom line: we need documentation, we need it yesterday, and I'd like to see us to be able to move forward with at least the content of the documentation ASAP! Greg J. Badros gjb@cs.washington.edu Seattle, WA USA http://www.cs.washington.edu/homes/gjb From owner-scwm-discuss@mit.edu Wed Jul 15 13:50:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12658 for scwm-discuss-outgoing; Wed, 15 Jul 1998 13:50:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA12655 for ; Wed, 15 Jul 1998 13:50:49 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA08681; Wed, 15 Jul 98 13:50:33 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id SAA05731; Wed, 15 Jul 1998 18:50:37 +0100 Date: Wed, 15 Jul 1998 18:50:37 +0100 (BST) From: Danius Michaelides To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: fvwm-(module|eval).scm In-Reply-To: <199807150414.AAA06781@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > - it seems that if a module sends an undefined command, it causes > > scwm to die with "scwm: Error communicating with module ". Possibly > > caused by some kind of problem in kill-fvwm-module ? > > You mean scwm actually dies, as opposed to just closing the module? > Does this still happen with recent snapshots? I thought I'd managed to > get scwm to kill modules cleanly without dying... Well it doesnt seem to be doing it now with 19980711.. perhaps it was an artifact of me mucking around.. > > - Resize raises a problem wih the above solution. Since we get-window > > is already being called for us, we use (interactive-resize window). > > Except now we have to click (and release) on the window, then drag > > out the new size of the window. As opposed to the more usual > > interactive-resize without the window argument, where you click, > > and drag in one motion. So i'm not sure if the above is really the > > right thing todo, and instead whether each individual fvwm command > > should decide how it gets the window context if its unspecified. > > That might be smart. The primitives will already DTRT if you pass no > window argument. Perhaps the window arguments to fvwm commands should > default to #f, and any fvwm command that needs a window should check > the window argument, and just not pass any at all if it is #f. The > primitives should DTRT with respect to their own window selection. Ok. i shall continue with this model of doing things. > > eg with variable arguments to eval-fvwm-command, we'd have: > > (define-fvwm-command "Raise" > > (if window > > (raise-window window))) > > but with the current way of calling eval-fvwm-command, you'd have > > this: > > (define-fvwm-command "Raise" > > (raise-window (if window window (get-window)))) > > Under the model of not imposing get-window, this would be: > > (define-fvwm-command "Raise" > (if window > (raise-window window) > (raise-window))) Harvey Stein suggested that this could be simplified to: (define-fvwm-command "Raise" (apply raise-window window)) Which is more efficient? I personally prefer the former, since its abit clearer what happens; I just wondered if efficiency was also an issue here. > > - Added Eval, to basically enable buttons in FvwmButton to run > > some specified code; > > (define-fvwm-command "Eval" > > (eval-string args)) > > and > > "*FvwmButtons(Title xterm, Icon Shell.xpm, > > Action `Eval (run-xterm)` Frame 1)" > > But this is slightly unsatifactory, because the code you specify > > doesnt have access to any context (eg window). > > That's a pretty cool idea. Thinking about it, i think this is sufficient to do most things you'd want todo (especially from FvwmButtons). If anybody can think of more elaborate things, that would require more than this provides, let me know. > > Anyway, i just thought i'd be vocal about this stuff, to see what the > > general opinion is of persuing it further (I'm happy todo so, and > > supply a patch, when i'm done) and what is the right thing todo. > Personally, I am really glad to see someone working on this, and I'd > love to see your changes, in either their current or any future > improved state. I'm happy to contiune working on this. The problem is that once i've got all the modules i routinely use working, i'll be stuck for module configs to test out, so if anybody has modules they'd like to see working can you send me the configurations. Danius From owner-scwm-discuss@mit.edu Wed Jul 15 13:56:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12737 for scwm-discuss-outgoing; Wed, 15 Jul 1998 13:56:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA12734 for ; Wed, 15 Jul 1998 13:56:02 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA10184; Wed, 15 Jul 98 13:55:56 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id NAA01067; Wed, 15 Jul 1998 13:55:58 -0400 To: Mark Galassi Cc: marko@cs.uni-frankfurt.de, scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code References: <199807120158.VAA08917@huis-clos.mit.edu> <13740.7863.350682.230274@papageno.lanl.gov> <199807150806.KAA04182@king.ki.informatik.uni-frankfurt.de> <13740.37161.815894.448665@papageno.lanl.gov> From: Jim Blandy Date: 15 Jul 1998 13:55:52 -0400 In-Reply-To: Mark Galassi's message of Wed, 15 Jul 1998 05:23:51 -0600 (MDT) Message-Id: Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Marko> If we are talking about a reference manual describing the > Marko> way the implementation works, as I think we are, I suggest > Marko> to borrow from Haskells literate style. > > We are not describing how the implementation works. We are describing > the various APIs and how the programmer should use them. Well, be careful --- this discussion has drifted. We started out discussing how to do docstrings right. We then started talking about generating real manuals from docstrings. Then there's also a thread about documenting Guile itself, and the Guile manual. Which, by the way, I have no interest in generating from docstrings, but I don't think that means that the idea is not useful or worth implementing in Guile for other programs to use. I think they're all possibly helpful discussions, but posters should be clear about which one they're trying to participate in. From owner-scwm-discuss@mit.edu Wed Jul 15 14:19:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA13030 for scwm-discuss-outgoing; Wed, 15 Jul 1998 14:19:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA13027 for ; Wed, 15 Jul 1998 14:19:05 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA16114; Wed, 15 Jul 98 14:18:59 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA01248; Wed, 15 Jul 1998 14:19:00 -0400 To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 15 Jul 1998 14:18:59 -0400 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of 14 Jul 1998 14:46:04 -0700 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I mean, you aren't thinking of requiring that the user have Jade, are you? > Sure, it would be neat to have an integrated DSSSL engine in Guile, > but is that really feasible? No, we're not considering that. It's unacceptable to require the user to have Jade installed to read docstrings. From owner-scwm-discuss@mit.edu Wed Jul 15 14:24:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA13104 for scwm-discuss-outgoing; Wed, 15 Jul 1998 14:24:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA13101 for ; Wed, 15 Jul 1998 14:24:50 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA15855; Wed, 15 Jul 98 14:25:03 EDT Received: (qmail 31125 invoked by uid 11105); 15 Jul 1998 18:24:47 -0000 To: Jim Blandy Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 15 Jul 1998 11:24:47 -0700 In-Reply-To: Jim Blandy's message of "15 Jul 1998 14:18:59 -0400" Message-Id: Lines: 10 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "JB" == Jim Blandy writes: MD> I mean, you aren't thinking of requiring that the user have Jade, MD> are you? JB> No, we're not considering that. It's unacceptable to require the JB> user to have Jade installed to read docstrings. And what about the manual? From owner-scwm-discuss@mit.edu Wed Jul 15 15:22:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA13681 for scwm-discuss-outgoing; Wed, 15 Jul 1998 15:22:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA13675 for ; Wed, 15 Jul 1998 15:21:57 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.8.8/8.8.8) with UUCP id VAA12486 for scwm-discuss@huis-clos.mit.edu; Wed, 15 Jul 1998 21:21:52 +0200 (CEST) Received: (qmail 2135 invoked by uid 115); 15 Jul 1998 19:14:36 -0000 To: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <199807141952.PAA02046@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Jul 1998 21:14:34 +0200 In-Reply-To: Greg Badros's message of "14 Jul 1998 13:36:33 -0700" Message-ID: Lines: 30 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 14 Jul 1998 13:36:33 -0700 >>>>> Greg Badros said: Greg> Security. E.g., synthetic keystroke events to an xterm is a Greg> huge security hole if xterm listens to synthetic events (by Greg> default it does not). Is this still a hole if X is sufficiently secured (allowing only clients with cookies[1] to connect)? Greg> Emacs does honour synthetic events by default (at least some Greg> versions do; I don't know of any that don't). Since Emacs can do everything an xterm can, this is a bit inconsistent. Greg> X security is often pretty lax (witness the `xhost +' command Greg> so often used w/o much thought by many), and if you have Greg> ill-intentioned people around, can be a big problem. It's better to fix the server than to cripple the clients. Robbe [1] Or, preferably, stronger methods: ssh, kerberos, ... -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Jul 15 15:40:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA13834 for scwm-discuss-outgoing; Wed, 15 Jul 1998 15:40:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA13828 for ; Wed, 15 Jul 1998 15:39:13 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA07441; Wed, 15 Jul 98 15:39:20 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id PAA22338; Wed, 15 Jul 1998 15:38:55 -0400 (EDT) Message-Id: <199807151938.PAA22338@jekyll.piermont.com> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags In-Reply-To: Your message of "15 Jul 1998 21:14:34 +0200." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jul 1998 15:38:55 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> On 14 Jul 1998 13:36:33 -0700 > >>>>> Greg Badros said: > > Greg> Security. E.g., synthetic keystroke events to an xterm is a > Greg> huge security hole if xterm listens to synthetic events (by > Greg> default it does not). > > Is this still a hole if X is sufficiently secured (allowing only > clients with cookies[1] to connect)? I personally don't trust the MIT Magic Cookie generation algorithm, and in any case the connections are made in the clear and can be hijacked even if they are strong. Myself, none of this is a good enough security mechanism for me -- I simply run my X server with "-nolisten tcp" and accept only local connections. However, now we are getting into an entirely different realm from scwm -- we are not talking about security, which is a much bigger topic and probably not one we want to discuss here. Perry From owner-scwm-discuss@mit.edu Wed Jul 15 15:46:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA13900 for scwm-discuss-outgoing; Wed, 15 Jul 1998 15:46:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA13887 for ; Wed, 15 Jul 1998 15:45:53 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA09903; Wed, 15 Jul 98 15:45:46 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id PAA22358; Wed, 15 Jul 1998 15:45:50 -0400 (EDT) To: scwm-discuss@mit.edu Subject: two questions Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 15 Jul 1998 15:45:50 -0400 Message-Id: <87n2aalwy9.fsf@jekyll.piermont.com> Lines: 13 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1) I've turned off random placement and left on smart placement, which is the way I like things (since if my desktop is cluttered I prefer to place windows myself.) I'm used to doing this from fvwm. However, in fvwm, the transients still pop up and place themselves automatically even if random placement is off and smart placement is on. In scwm this doesn't happen, which is annoying. Is there a way to get that to happen without having to turn on random placement? 2) I still cannot get double click mouse events to do anything regardless of what I try. Hints? Perry From owner-scwm-discuss@mit.edu Wed Jul 15 15:57:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14034 for scwm-discuss-outgoing; Wed, 15 Jul 1998 15:57:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14028 for ; Wed, 15 Jul 1998 15:56:57 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA12966; Wed, 15 Jul 98 15:56:50 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA07848; Wed, 15 Jul 1998 22:56:49 +0300 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: two questions References: <87n2aalwy9.fsf@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Jul 1998 22:56:49 +0300 In-Reply-To: "Perry E. Metzger"'s message of "15 Jul 1998 15:45:50 -0400" Message-Id: Lines: 12 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > 2) I still cannot get double click mouse events to do anything > regardless of what I try. Hints? I haven't seen it personally. Maybe it has to do with the double click time? Have you tried fooling around with set-click-time!? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jul 15 16:02:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA14099 for scwm-discuss-outgoing; Wed, 15 Jul 1998 16:02:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA14096 for ; Wed, 15 Jul 1998 16:02:42 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14549; Wed, 15 Jul 98 16:02:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA21392; Wed, 15 Jul 1998 13:02:35 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: synthetic mouse drags References: <199807141952.PAA02046@huis-clos.mit.edu> From: Greg Badros Date: 15 Jul 1998 13:02:35 -0700 In-Reply-To: Robert Bihlmeyer's message of "15 Jul 1998 21:14:34 +0200" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> On 14 Jul 1998 13:36:33 -0700 > >>>>> Greg Badros said: > > Greg> Security. E.g., synthetic keystroke events to an xterm is a > Greg> huge security hole if xterm listens to synthetic events (by > Greg> default it does not). > > Is this still a hole if X is sufficiently secured (allowing only > clients with cookies[1] to connect)? It's a hole exactly as big as any holes in X security. I use ssh and don't wory too much about my emacs trusting synthetic events. > > Greg> Emacs does honour synthetic events by default (at least some > Greg> versions do; I don't know of any that don't). > > Since Emacs can do everything an xterm can, this is a bit inconsistent. I agree, but it wasn't my decision, of course. It's easy enough to turn on SendEvents by default in an xterm using a resource setting. > Greg> X security is often pretty lax (witness the `xhost +' command > Greg> so often used w/o much thought by many), and if you have > Greg> ill-intentioned people around, can be a big problem. > > It's better to fix the server than to cripple the clients. Agreed completely. I just was commenting on the background as to why apps treat synthetic events specially. > > Robbe > > [1] Or, preferably, stronger methods: ssh, kerberos, ... Yep. ssh rocks! Greg From owner-scwm-discuss@mit.edu Wed Jul 15 16:14:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA14234 for scwm-discuss-outgoing; Wed, 15 Jul 1998 16:14:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA14231 for ; Wed, 15 Jul 1998 16:14:25 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA17469; Wed, 15 Jul 98 16:14:19 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id QAA22543; Wed, 15 Jul 1998 16:14:08 -0400 (EDT) Message-Id: <199807152014.QAA22543@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: two questions In-Reply-To: Your message of "15 Jul 1998 22:56:49 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 15 Jul 1998 16:14:08 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > "Perry E. Metzger" writes: > > 2) I still cannot get double click mouse events to do anything > > regardless of what I try. Hints? > > I haven't seen it personally. Maybe it has to do with the double > click time? Have you tried fooling around with set-click-time!? Yes, I have. Doesn't help. sample code: (define (move-or-deiconify) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (deiconify)))) (bind-mouse 'icon 1 move-or-deiconify) And if I double click over the icon, nothing happens. .pm From owner-scwm-discuss@mit.edu Wed Jul 15 16:22:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA14304 for scwm-discuss-outgoing; Wed, 15 Jul 1998 16:22:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA14299 for ; Wed, 15 Jul 1998 16:22:27 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA19387; Wed, 15 Jul 98 16:22:15 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA07988; Wed, 15 Jul 1998 23:22:11 +0300 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: two questions References: <199807152014.QAA22543@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Jul 1998 23:22:10 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Wed, 15 Jul 1998 16:14:08 -0400" Message-Id: Lines: 68 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > "Perry E. Metzger" writes: > > > 2) I still cannot get double click mouse events to do anything > > > regardless of what I try. Hints? > > > > I haven't seen it personally. Maybe it has to do with the double > > click time? Have you tried fooling around with set-click-time!? > > Yes, I have. Doesn't help. > > sample code: > > (define (move-or-deiconify) > (case (mouse-event-type) > ((motion) (interactive-move)) > ((double-click) (deiconify)))) > > (bind-mouse 'icon 1 move-or-deiconify) I have the same code in my .scwmrc. It's from the default system .scwmrc. How about changing it to: (define (move-or-deiconify) (display "move-or-deiconify: (mouse-event-type) = ") (display (mouse-event-type)) (newline) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (deiconify)))) and seeing what it prints for the mouse event type. What about other double-click actions? I have: (set-animation! '#(0 .01 .03 .08 .18 .3 .45 .60 .75 .85 .90 .94 .97 .99 1)) (define (move-or-raise) (case (mouse-event-type) ((motion) (interactive-move)) ((click) (raise-window)))) (define (move-or-shade) (case (mouse-event-type) ((double-click) (toggle-window-shade-animated)) ((motion) (move-or-raise)) (else (if (window-shaded?) (toggle-window-shade-animated) (move-or-raise))))) (bind-mouse 'title 1 move-or-shade) For me, this works as follows: motion - window moves. double-click - shades or unshades. single-click - When shaded, unshade. When unshaded, raise. Do you get the same results? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Jul 15 17:26:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA14938 for scwm-discuss-outgoing; Wed, 15 Jul 1998 17:26:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA14935 for ; Wed, 15 Jul 1998 17:26:40 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA05054; Wed, 15 Jul 98 17:26:34 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id RAA06676; Wed, 15 Jul 1998 17:26:38 -0400 Date: Wed, 15 Jul 1998 17:26:38 -0400 Message-Id: <199807152126.RAA06676@totoro.red-bean.com> From: Jim Blandy To: Guile Discussion , scwm-discuss@mit.edu Subject: Re: generating a manual from annotations in source code Sender: owner-scwm-discuss@mit.edu Precedence: bulk It sounds like Maciej's got a specific plan in mind. Which is better than I've got. Probably the best thing for the discussion would be for him to write it down (or write it up) and post it. That would certainly help make the discussion more concrete. the coders shall inherit the earth From owner-scwm-discuss@mit.edu Wed Jul 15 17:50:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA15092 for scwm-discuss-outgoing; Wed, 15 Jul 1998 17:50:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA15089 for ; Wed, 15 Jul 1998 17:50:16 -0400 Received: from runyon.cygnus.com by MIT.EDU with SMTP id AA12821; Wed, 15 Jul 98 17:50:28 EDT Received: from lanl.gov (transitory142.lanl.gov [128.165.7.90]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA15369; Wed, 15 Jul 1998 14:50:08 -0700 (PDT) Received: (from rosalia@localhost) by lanl.gov (8.8.5/8.8.5) id PAA11615; Wed, 15 Jul 1998 15:50:07 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 15 Jul 1998 15:50:06 -0600 (MDT) From: Mark Galassi To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: Jim Blandy , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions In-Reply-To: References: <199807101354.JAA28647@huis-clos.mit.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <13741.9065.168.126212@papageno.lanl.gov> Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Marcus" == Marcus G Daniels writes: >>>>> "JB" == Jim Blandy writes: MD> I mean, you aren't thinking of requiring that the user have MD> Jade, are you? JB> No, we're not considering that. It's unacceptable to require JB> the user to have Jade installed to read docstrings. Marcus> And what about the manual? The Guile manuals are written in TeXinfo, and for Guile this will probably not change soon. I can only see it changing when the interchange between DocBook and TeXinfo is mature (it is non-existent now). With docstrings there is a chance of a fresh start, and DocBook tags might be interesting. If docstrings make their way into the manual (as a "quickref" appendix, for example) they would have to use tags with no depth that map quite easily to the equivalent TeXinfo tags. From owner-scwm-discuss@mit.edu Wed Jul 15 18:15:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA15340 for scwm-discuss-outgoing; Wed, 15 Jul 1998 18:15:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA15337 for ; Wed, 15 Jul 1998 18:15:29 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA14274; Wed, 15 Jul 98 18:15:22 EDT Received: (qmail 32414 invoked by uid 11105); 15 Jul 1998 22:15:26 -0000 To: Mark Galassi Cc: Jim Blandy , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> <13741.9065.168.126212@papageno.lanl.gov> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 15 Jul 1998 15:15:26 -0700 In-Reply-To: Mark Galassi's message of "Wed, 15 Jul 1998 15:50:06 -0600 (MDT)" Message-Id: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "MG" == Mark Galassi writes: >>>>> "MD" == Marcus G Daniels writes: >>>>> "JB" == Jim Blandy writes: MD> I mean, you aren't thinking of requiring that the user have Jade, MD> are you? JB> No, we're not considering that. It's unacceptable to require the JB> user to have Jade installed to read docstrings. MD> And what about the manual? MG> With docstrings there is a chance of a fresh start, and DocBook MG> tags might be interesting. If docstrings make their way into the MG> manual (as a "quickref" appendix, for example) they would have to MG> use tags with no depth that map quite easily to the equivalent MG> TeXinfo tags. The trivial (and by now, disconnected) point I am trying to make, is that using a program like Emacs to extract documentation tags doesn't mean that the user needs to have Emacs. If the notion is that the documentation system ought to be all self-contained, then you can forget about DocBook, since it would be absurd to put all the needed capability into guiledoc. Using DocBook implies significant preprocessing by the maintainer(s), just like with automake and makeinfo -- and maintainer(s) might as well use the most powerful tools (Emacs being equal or more powerful than than Perl when it comes to text processing, and far more powerful than Guile.) Granted, it would be nice to avoid entirely a separate pass over the code, using the interpreter to store and report the documentation encoded in Scheme code. But how do you scan the bits implemented in C? From owner-scwm-discuss@mit.edu Wed Jul 15 20:02:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA16286 for scwm-discuss-outgoing; Wed, 15 Jul 1998 20:02:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA16283 for ; Wed, 15 Jul 1998 20:02:33 -0400 Received: from smtp5.nwnexus.com by MIT.EDU with SMTP id AA04368; Wed, 15 Jul 98 20:02:45 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp5.nwnexus.com (8.8.8/8.8.8) with ESMTP id RAA12715 for ; Wed, 15 Jul 1998 17:00:56 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-21476>; Wed, 15 Jul 1998 17:00:31 -0700 To: scwm-discuss@mit.edu Subject: is there a form to hide/banish/unmap a window? Date: Wed, 15 Jul 1998 17:00:20 -0600 From: Ken Pizzini Message-Id: <19980716000031Z276516-21476+23@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk I was wanting to add a form to have scwm to simply not display a window --- no windowshade, no icon, no icon-title (but it should still show up in a (show-window-list-menu)). This almost is what I want: (define hide-window (lambda* (#&optional (w (get-window))) (style-one-window w #:icon #f #:icon-title #f) (iconify))) Except that if I then open this window through the window-list-menu and then do a regular (iconify) on it, I want the icon style to be whatever was in effect before my hide-window operation. I.e., I want this to be a fourth display option: displayed, window-shaded, iconified, hidden. Can this be done with the existing primitives? If not, does it seem like it'd be an easy feature to add? --Ken Pizzini From owner-scwm-discuss@mit.edu Wed Jul 15 22:38:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA17704 for scwm-discuss-outgoing; Wed, 15 Jul 1998 22:38:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA17698 for ; Wed, 15 Jul 1998 22:38:06 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA23239; Wed, 15 Jul 98 22:38:20 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id WAA07515; Wed, 15 Jul 1998 22:38:01 -0400 To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> <13741.9065.168.126212@papageno.lanl.gov> From: Jim Blandy Date: 15 Jul 1998 22:38:00 -0400 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of 15 Jul 1998 15:15:26 -0700 Message-Id: Lines: 9 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > The trivial (and by now, disconnected) point I am trying to make, is > that using a program like Emacs to extract documentation tags doesn't > mean that the user needs to have Emacs. Ahh. You mean that Emacs would just be one consumer of the docstrings, and that other consumers would exist? Sure, I'll buy that. I'd love to have Guile docstrings pop up when I hit C-h f in a Scheme buffer. From owner-scwm-discuss@mit.edu Wed Jul 15 22:49:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA17911 for scwm-discuss-outgoing; Wed, 15 Jul 1998 22:49:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA17908 for ; Wed, 15 Jul 1998 22:49:49 -0400 Received: from cathcart.sysc.pdx.edu by MIT.EDU with SMTP id AA18851; Wed, 15 Jul 98 22:49:43 EDT Received: (qmail 19273 invoked by uid 11105); 16 Jul 1998 02:49:46 -0000 To: Jim Blandy Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> <13741.9065.168.126212@papageno.lanl.gov> From: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Date: 15 Jul 1998 19:49:46 -0700 In-Reply-To: Jim Blandy's message of "15 Jul 1998 22:38:00 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "JB" == Jim Blandy writes: JB> Ahh. You mean that Emacs would just be one consumer of the JB> docstrings, and that other consumers would exist? Sure, I'll buy JB> that. I'd love to have Guile docstrings pop up when I hit C-h f JB> in a Scheme buffer. I'm not talking about Emacs as a consumer, no. Although if there was Emacs docstring parsing code, it would probably make sense to use it all the time. I'm saying that in order to do DocBook at all, you need to have a lot of infrastructure (DTDs, Jade, stylesheets), and that users won't have it. This implies that the DocBook source will need to be preprocessed for the users, much like Texinfo is preprocessed into Info. So long as there is preprocessing going on, there's no point in minimizing the number of required tools. From owner-scwm-discuss@mit.edu Thu Jul 16 00:07:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA18447 for scwm-discuss-outgoing; Thu, 16 Jul 1998 00:07:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA18444 for ; Thu, 16 Jul 1998 00:07:39 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA04625; Thu, 16 Jul 98 00:07:52 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id AAA07859; Thu, 16 Jul 1998 00:07:32 -0400 To: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions References: <199807101354.JAA28647@huis-clos.mit.edu> From: Jim Blandy Date: 16 Jul 1998 00:07:31 -0400 In-Reply-To: marcusd@cathcart.sysc.pdx.edu's message of 15 Jul 1998 11:24:47 -0700 Message-Id: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes: > MD> I mean, you aren't thinking of requiring that the user have Jade, > MD> are you? > > JB> No, we're not considering that. It's unacceptable to require the > JB> user to have Jade installed to read docstrings. > > And what about the manual? For now, the manual is in Texinfo, because that's the FSF's standard format. We could switch to Docbook, but there are no Docbook/Texinfo conversion tools yet, so that would make info users (like me) quite unhappy. From owner-scwm-discuss@mit.edu Thu Jul 16 01:06:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA19025 for scwm-discuss-outgoing; Thu, 16 Jul 1998 01:06:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA19022 for ; Thu, 16 Jul 1998 01:06:46 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA03175; Thu, 16 Jul 98 01:06:39 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id BAA00522; Thu, 16 Jul 1998 01:06:33 -0400 (EDT) Message-Id: <199807160506.BAA00522@jekyll.piermont.com> To: Jim Blandy Cc: marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels), scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: primitive documentation conventions In-Reply-To: Your message of "16 Jul 1998 00:07:31 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jul 1998 01:06:33 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk There are DocBook->html converters. Surely this couldn't require more than some tuning of an existing converter for some format... Jim Blandy writes: > > marcusd@cathcart.sysc.pdx.edu (Marcus G. Daniels) writes: > > MD> I mean, you aren't thinking of requiring that the user have Jade, > > MD> are you? > > > > JB> No, we're not considering that. It's unacceptable to require the > > JB> user to have Jade installed to read docstrings. > > > > And what about the manual? > > For now, the manual is in Texinfo, because that's the FSF's standard > format. We could switch to Docbook, but there are no Docbook/Texinfo > conversion tools yet, so that would make info users (like me) quite > unhappy. From owner-scwm-discuss@mit.edu Thu Jul 16 03:00:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA19761 for scwm-discuss-outgoing; Thu, 16 Jul 1998 03:00:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA19758 for ; Thu, 16 Jul 1998 03:00:50 -0400 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA11697; Thu, 16 Jul 98 03:00:43 EDT Received: from baguette (chlh.tbit.dk [194.182.135.163]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id JAA01761; Thu, 16 Jul 1998 09:00:43 +0200 (MET DST) Received: by baguette id m0ywYFW-000yXTC (Debian Smail-3.2.0.92 1997-Feb-9 #2); Wed, 15 Jul 1998 22:34:02 +0200 (CEST) Message-Id: Date: Wed, 15 Jul 1998 22:34:02 +0200 (CEST) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Blandy Cc: Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: generating a manual from annotations in source code In-Reply-To: References: <199807120158.VAA08917@huis-clos.mit.edu> X-Mailer: VM 6.34 under Emacs 19.34.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Jim" == Jim Blandy writes: Jim> Do people feel that, if the documentation is a separate file, Jim> programmers will be discouraged from writing docs, whereas, if Jim> the documentation were mingled with the source, then programmers Jim> would naturally write docstrings as they go along? I would claim that it is close to empirically demonstrated that volunteer programmers produce a lot more code than documentation. That code and documentation should live next to each other, is one of the fundamental concepts underlying the notion of Literate Programming (invented by Knuth, see for instance `TeX: the Program'). I am not so bold as to promise that mingling code and doc-strings will make programmers write more new documentation, but I think that it will make it easier to keep existing documentation in sync with the code, as it evolves. How ambitious the extraction process should be, is one good question. Knuth can make entire books (and good ones) directly from source, but he is of course also Knuth. Going with some skeleton and/or predefined structure, is probably more viable for us. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Thu Jul 16 06:40:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA21045 for scwm-discuss-outgoing; Thu, 16 Jul 1998 06:40:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA21042 for ; Thu, 16 Jul 1998 06:40:52 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA06446; Thu, 16 Jul 98 06:41:05 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA11935; Thu, 16 Jul 1998 13:40:46 +0300 To: scwm-discuss@mit.edu Subject: resizing bug. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 13:40:45 +0300 In-Reply-To: Ken Pizzini's message of "Wed, 15 Jul 1998 17:00:20 -0600" Message-Id: Lines: 26 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. I pop up an xterm 2. I do a horizontal-toggle-maximize, as in: (define (horizontal-toggle-maximize) (toggle-maximize (%x 100) 0)) 3. I change to a smaller font. 4. The window automatically resizes due to 3, preserving the number of rows & columns. 5. I do a horizontal-toggle-maximize again to bring it back to normal size. 6. The window resizes to many more rows and columns than it originally had. It ends up about the same size in pixels, though. Evidentally toggle-maximize isn't differentiating between windows sized in characters & windows sized in pixels. Shouldn't toggling back to the original size go back to the orignal number of rows & columns, not the original size in pixels? If I recall correctly, that's what fvwm does. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 09:11:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA21993 for scwm-discuss-outgoing; Thu, 16 Jul 1998 09:11:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA21986; Thu, 16 Jul 1998 09:11:01 -0400 Message-Id: <199807161311.JAA21986@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: set-edge-resistance! and double clicks Date: Thu, 16 Jul 1998 09:11:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tested both of these and they work for me. In particular, when I do (set-edge-resistance! 250 100) in a scwmrepl, I get a very noticable delay at the edge of the screen before the screen scrolls. And binding double click events definitely works for me. This makes me suspect that the way scwm does the delays for these things is not working on NetBSD, since, AFAIK, you're the only person using scwm on NetBSD. The code uses usleep() in small increments in both of these cases to delay for a little while repeatedly until the timeout expires or the mouse is moved away. On systems that do not have usleep(), it is implemented in terms of select() in the file syscompat.c. Is there any reason this might not work right on your machine? - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 11:28:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22581 for scwm-discuss-outgoing; Thu, 16 Jul 1998 11:28:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA22578 for ; Thu, 16 Jul 1998 11:28:29 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA17603; Thu, 16 Jul 98 11:28:21 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA02569; Thu, 16 Jul 1998 11:28:26 -0400 (EDT) Message-Id: <199807161528.LAA02569@jekyll.piermont.com> To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: set-edge-resistance! and double clicks In-Reply-To: Your message of "Thu, 16 Jul 1998 09:11:00 EDT." <199807161311.JAA21986@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jul 1998 11:28:26 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I tested both of these and they work for me. In particular, when I do > (set-edge-resistance! 250 100) in a scwmrepl, I get a very noticable > delay at the edge of the screen before the screen scrolls. And binding > double click events definitely works for me. > > This makes me suspect that the way scwm does the delays for these > things is not working on NetBSD, since, AFAIK, you're the only person > using scwm on NetBSD. The code uses usleep() in small increments in > both of these cases to delay for a little while repeatedly until the > timeout expires or the mouse is moved away. On systems that do not > have usleep(), it is implemented in terms of select() in the file > syscompat.c. Is there any reason this might not work right on your > machine? I'll have a look at the way the code works and I'll let you know. Perry From owner-scwm-discuss@mit.edu Thu Jul 16 11:54:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22851 for scwm-discuss-outgoing; Thu, 16 Jul 1998 11:54:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22847; Thu, 16 Jul 1998 11:54:42 -0400 Message-Id: <199807161554.LAA22847@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: New placement code Date: Thu, 16 Jul 1998 11:54:42 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've done up proper support for user placmenet functions. I've also made new primitives for the existing fvwm placement algorithms. Details are in the ChangeLog in tonights's snapshot. I'd like feedback on this, especially some of the design decisions like separating #:placement-proc from #:transient-placement-proc. (Note: the gravity bug with placement and border sizes is still there, in fact, it is probably exacerbated. However, I know how to fix it now, and will probably do so by tomorrow's snap.) - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 12:24:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23306 for scwm-discuss-outgoing; Thu, 16 Jul 1998 12:24:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23303 for ; Thu, 16 Jul 1998 12:24:37 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03013; Thu, 16 Jul 98 12:24:30 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA13862; Thu, 16 Jul 1998 19:24:31 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: New placement code References: <199807161554.LAA22847@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 19:24:31 +0300 In-Reply-To: Maciej Stachowiak's message of "Thu, 16 Jul 1998 11:54:42 EDT" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I've done up proper support for user placmenet functions. I've also > made new primitives for the existing fvwm placement > algorithms. Details are in the ChangeLog in tonights's snapshot. I'd > like feedback on this, especially some of the design decisions like > separating #:placement-proc from #:transient-placement-proc. Is there a function for determining whether or not a window is a transient window? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 12:29:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23336 for scwm-discuss-outgoing; Thu, 16 Jul 1998 12:29:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23333 for ; Thu, 16 Jul 1998 12:29:04 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA04150; Thu, 16 Jul 98 12:28:56 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA13899; Thu, 16 Jul 1998 19:28:58 +0300 To: scwm-discuss@mit.edu Subject: transient question. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 19:28:58 +0300 In-Reply-To: hjstein@bfr.co.il's message of "16 Jul 1998 19:24:31 +0300" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have: (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) in my .scwmrc. I've noticed that when Netscape pops up one of these windows, and netscape is on a different desktop from where I'm currently working, the desktop switches to the netscape desktop. On the other hand, the window stays where it came up on all desktops. Is this intended behavior? I can't say I really like it... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 12:34:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23427 for scwm-discuss-outgoing; Thu, 16 Jul 1998 12:34:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23424 for ; Thu, 16 Jul 1998 12:34:36 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23731; Thu, 16 Jul 98 12:34:49 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA23849; Thu, 16 Jul 1998 09:34:27 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: New placement code References: <199807161554.LAA22847@huis-clos.mit.edu> From: Greg Badros Date: 16 Jul 1998 09:34:27 -0700 In-Reply-To: hjstein@bfr.co.il's message of "16 Jul 1998 19:24:31 +0300" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Is there a function for determining whether or not a window is a > transient window? (transient? ...) For a list of all SCWM C primitives, do: grep -A1 SCWM_PROC *.c # assume GNU grep w/ -A option for 1 line # trailing context Greg From owner-scwm-discuss@mit.edu Thu Jul 16 12:45:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23591 for scwm-discuss-outgoing; Thu, 16 Jul 1998 12:45:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23588 for ; Thu, 16 Jul 1998 12:45:17 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08242; Thu, 16 Jul 98 12:45:06 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA14029; Thu, 16 Jul 1998 19:45:05 +0300 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: New placement code References: <199807161554.LAA22847@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 19:45:05 +0300 In-Reply-To: Greg Badros's message of "16 Jul 1998 09:34:27 -0700" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Is there a function for determining whether or not a window is a > > transient window? > > (transient? ...) > > For a list of all SCWM C primitives, do: > > grep -A1 SCWM_PROC *.c # assume GNU grep w/ -A option for 1 line > # trailing context or SCM_PROC, I suppose, if you're running 0.7a? In any case, what exactly makes a window transient? I thought these netscape popups were transients, but they don't seem to be: scwm> (map window-title (list-all-windows)) ("xclock" "Fvwm Pager" "10.l.lsp" "xbiff" "*scwm*" "ssh randy" "ssh randy" "blinky" "*inferior-lisp*" "ssh blaster" "ssh randy" "Notes" "*info*" ".scwmrc" "blinky" "Netscape: Welcome to Excite!" "Netscape: Question" "Netscape: Question") scwm> (map transient? (list-all-windows)) (#f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f #f) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 12:50:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23670 for scwm-discuss-outgoing; Thu, 16 Jul 1998 12:50:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23666 for ; Thu, 16 Jul 1998 12:50:07 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27820; Thu, 16 Jul 98 12:50:19 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA23872; Thu, 16 Jul 1998 09:49:59 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: New placement code References: <199807161554.LAA22847@huis-clos.mit.edu> From: Greg Badros Date: 16 Jul 1998 09:49:59 -0700 In-Reply-To: hjstein@bfr.co.il's message of "16 Jul 1998 19:45:05 +0300" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > or SCM_PROC, I suppose, if you're running 0.7a? Yep, but not as reliably-- sometime after 0.7a I made the SCWM_PROC used for *all* primitives and cleaned stuff up a bit. > > In any case, what exactly makes a window transient? I thought these > netscape popups were transients, but they don't seem to be: Transients are temporary child windows of the root window -- e.g., pop-up menus. It's really just a hint from the application to the wm as to how to handle the window -- the Xlib prging manual suggests it be used for windows that deserve lighter treatment (decoration-wise) than a normal top-level window, but are longer lived than override-redirect windows which are used for very-short-lived windows for which the application wants total control. Greg From owner-scwm-discuss@mit.edu Thu Jul 16 13:45:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24496 for scwm-discuss-outgoing; Thu, 16 Jul 1998 13:45:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24492; Thu, 16 Jul 1998 13:45:26 -0400 Message-Id: <199807161745.NAA24492@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: New placement code In-reply-to: Your message of "16 Jul 1998 09:49:59 PDT." Date: Thu, 16 Jul 1998 13:45:26 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > or SCM_PROC, I suppose, if you're running 0.7a? > > Yep, but not as reliably-- sometime after 0.7a I made the SCWM_PROC > used for *all* primitives and cleaned stuff up a bit. > > > > > In any case, what exactly makes a window transient? I thought these > > netscape popups were transients, but they don't seem to be: > The application controls this. I think you have observed a bug in scwm. A quick test indicates that the transient flag is set for Netscape pop-ups right after the appropriate hint is checked, but not, apparently, when transient? is getting called. I will investigate further. > Transients are temporary child windows of the root window -- e.g., > pop-up menus. It's really just a hint from the application to the wm as > to how to handle the window -- the Xlib prging manual suggests it be > used for windows that deserve lighter treatment (decoration-wise) than > a normal top-level window, but are longer lived than override-redirect > windows which are used for very-short-lived windows for which the > application wants total control. > ICCCM also reccomends placing them without user interaction, and preferably where asked by the application. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 13:46:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24523 for scwm-discuss-outgoing; Thu, 16 Jul 1998 13:46:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA24520 for ; Thu, 16 Jul 1998 13:46:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23801; Thu, 16 Jul 98 13:46:43 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA23926; Thu, 16 Jul 1998 10:46:46 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Backtraces from scwm-mode in Emacs From: Greg Badros Date: 16 Jul 1998 10:46:45 -0700 Message-Id: Lines: 6 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I thought I remember getting error messages reported back to my Emacs when using scwm-mode a while back. This doesn't seem to work any longer for me (if it never did, I wish it would). If I get an error evaluating a scheme expression in the scwm interpreter, I'd like to know about it. Greg From owner-scwm-discuss@mit.edu Thu Jul 16 14:04:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24773 for scwm-discuss-outgoing; Thu, 16 Jul 1998 14:04:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA24767 for ; Thu, 16 Jul 1998 14:03:52 -0400 Received: by tis.bellhow.com; id OAA22371; Thu, 16 Jul 1998 14:03:46 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma022333; Thu, 16 Jul 98 14:03:26 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA16612 for ; Thu, 16 Jul 1998 14:03:25 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: 1998 07 16 snapshot build errors Date: Thu, 16 Jul 1998 17:59:53 GMT Organization: Bell & Howell PSC Message-ID: <35b03be0.176408251@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA24771 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi All, 1. configure wasn't finding my guile libs. Looks like I have to run configure like: "./configure --prefix=$HOME --with-guile-prefix=$HOME". I previously just used --prefix. Yes, that did it, it's building now. 2. configure is trying to set GUILE_INCLUDES to -L.... instead of -I.... Here is a patch: -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 16 14:10:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24868 for scwm-discuss-outgoing; Thu, 16 Jul 1998 14:10:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA24865 for ; Thu, 16 Jul 1998 14:10:46 -0400 Received: by tis.bellhow.com; id OAA23533; Thu, 16 Jul 1998 14:10:45 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma023406; Thu, 16 Jul 98 14:10:01 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA16865 for ; Thu, 16 Jul 1998 14:10:01 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: 1998 07 16 snapshot build errors Date: Thu, 16 Jul 1998 18:06:28 GMT Organization: Bell & Howell PSC Message-ID: <35b14010.177480753@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA24866 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi All, 1. configure wasn't finding my guile libs. Looks like I have to run configure like: "./configure --prefix=$HOME --with-guile-prefix=$HOME". I previously just used --prefix. Yes, that did it, it's building now. 2. configure is trying to set GUILE_INCLUDES to -L.... instead of -I.... Here is a patch: *** configure.old Thu Jul 16 13:25:58 1998 --- configure Thu Jul 16 13:26:42 1998 *************** *** 2957,2965 **** GUILE_LIBS_PRE="-L$exec_prefix/lib" fi if test "x$prefix" = "xNONE"; then ! GUILE_INCLUDES="-L$ac_default_prefix/include" else ! GUILE_INCLUDES="-L$prefix/include" fi # Check whether --with-guile-prefix or --without-guile-prefix was given. --- 2957,2965 ---- GUILE_LIBS_PRE="-L$exec_prefix/lib" fi if test "x$prefix" = "xNONE"; then ! GUILE_INCLUDES="-I$ac_default_prefix/include" else ! GUILE_INCLUDES="-I$prefix/include" fi # Check whether --with-guile-prefix or --without-guile-prefix was given. -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 16 14:11:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24894 for scwm-discuss-outgoing; Thu, 16 Jul 1998 14:11:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24891 for ; Thu, 16 Jul 1998 14:11:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00301; Thu, 16 Jul 98 14:11:44 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA24047; Thu, 16 Jul 1998 11:11:44 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: 1998 07 16 snapshot build errors References: <35b03be0.176408251@mailhost> From: Greg Badros Date: 16 Jul 1998 11:11:44 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 16 Jul 1998 17:59:53 GMT" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Hi All, > > 1. configure wasn't finding my guile libs. Looks like I have to run configure > like: "./configure --prefix=$HOME --with-guile-prefix=$HOME". I previously just > used --prefix. Yes, that did it, it's building now. > > > 2. configure is trying to set GUILE_INCLUDES to -L.... instead of -I.... > > Here is a patch: > > I don't think your patch made it. Greg From owner-scwm-discuss@mit.edu Thu Jul 16 14:15:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA25031 for scwm-discuss-outgoing; Thu, 16 Jul 1998 14:15:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA25027 for ; Thu, 16 Jul 1998 14:15:34 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA21789; Thu, 16 Jul 98 14:15:47 EDT Received: from cliff.concentric.net (cliff [206.173.119.90]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id OAA21427; Thu, 16 Jul 1998 14:15:31 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d01.phe-pa.concentric.net [209.31.155.61]) by cliff.concentric.net (8.8.8) id OAA14144; Thu, 16 Jul 1998 14:15:29 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id OAA29433; Thu, 16 Jul 1998 14:15:19 -0400 To: scwm-discuss@mit.edu Subject: Re: Backtraces from scwm-mode in Emacs References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of "16 Jul 1998 10:46:45 -0700" Date: 16 Jul 1998 14:15:17 -0400 Message-Id: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 16 Jul 1998 10:46:45 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Backtraces from scwm-mode in Emacs": >> I thought I remember getting error messages reported back to my Emacs >> when using scwm-mode a while back. This doesn't seem to work any longer >> for me (if it never did, I wish it would). If I get an error evaluating >> a scheme expression in the scwm interpreter, I'd like to know about it. When I type "sdfg C-j" in .scwmrc, the following is inserted: Backtrace: 0* sdfg ERROR: In expression sdfg: ERROR: Unbound variable: sdfg when I type "sdfg C-x C-j" the same appears in MB. emacs-version ==> "20.2.97.1" It should be the same with your XEmacs. Does it work with "(+ 1 2) C-j" (is "3" inserted?) If yes, the problem is with `scwm-eval'. Please try to figure out what has to be given to `call-process' so that both stdout and stderr go into the same buffer. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Really cancel? [OK] [Cancel] From owner-scwm-discuss@mit.edu Thu Jul 16 15:02:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25456 for scwm-discuss-outgoing; Thu, 16 Jul 1998 15:02:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25453 for ; Thu, 16 Jul 1998 15:02:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05834; Thu, 16 Jul 98 15:02:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA25103; Thu, 16 Jul 1998 12:01:57 -0700 (PDT) To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: Backtraces from scwm-mode in Emacs References: From: Greg Badros Date: 16 Jul 1998 12:01:56 -0700 In-Reply-To: Sam Steingold's message of "16 Jul 1998 14:15:17 -0400" Message-Id: Lines: 57 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > When I type "sdfg C-j" in .scwmrc, the following is inserted: > > Backtrace: > 0* sdfg > > ERROR: In expression sdfg: > ERROR: Unbound variable: sdfg > > when I type "sdfg C-x C-j" the same appears in MB. > > emacs-version ==> "20.2.97.1" > > It should be the same with your XEmacs. > > Does it work with "(+ 1 2) C-j" (is "3" inserted?) > If yes, the problem is with `scwm-eval'. > Please try to figure out what has to be given to `call-process' so that > both stdout and stderr go into the same buffer. It works with C-j, but not with C-x C-j. call-process docs says: `call-process' is a compiled Lisp function -- loaded from "process.elc" (call-process PROGRAM &optional INFILE BUFFER DISPLAYP &rest ARGS) Call PROGRAM synchronously in separate process. The program's input comes from file INFILE (nil means `/dev/null'). Insert output in BUFFER before point; t means current buffer; nil for BUFFER means discard it; 0 means discard and don't wait. BUFFER can also have the form (REAL-BUFFER STDERR-FILE); in that case, REAL-BUFFER says what to do with standard output, as above, while STDERR-FILE says what to do with standard error in the child. STDERR-FILE may be nil (discard standard error output), t (mix it with ordinary output), or a file name string. Fourth arg DISPLAYP non-nil means redisplay buffer as output is inserted. Remaining arguments are strings passed as command arguments to PROGRAM. If BUFFER is 0, `call-process' returns immediately with value nil. Otherwise it waits for PROGRAM to terminate and returns a numeric exit status or a signal description string. If you quit, the process is killed with SIGINT, or SIGKILL if you quit again. But I can't get the form (REAL_BUFFER STDERR_FILE) to work as advertised. Also, why does the code in scwm-eval-to-minibuffer not use scwm-eval-last? (it duplicates the code for getting the last sexp). I'm using XEmacs 20.4 on a Linux box. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 16 15:46:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25770 for scwm-discuss-outgoing; Thu, 16 Jul 1998 15:46:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25767 for ; Thu, 16 Jul 1998 15:46:46 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25659; Thu, 16 Jul 98 15:46:38 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA14831; Thu, 16 Jul 1998 22:46:39 +0300 To: scwm-discuss@mit.edu Subject: Anonymous CVS supported? Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 22:46:39 +0300 In-Reply-To: hjstein@bfr.co.il's message of "27 Jun 1998 18:24:39 +0300" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I thought anonymous CVS was supported for scwm, but it fails when I try: hjstein@bacall:~/software/guilesw$ CVSROOT=:pserver:anonymous@huis-clos.mit.edu:/usr/local/repository cvs -z9 checkout scwm -d scwm cvs [checkout aborted]: connect to huis-clos.mit.edu:2401 failed: Connection refused hjstein@bacall:~/software/guilesw$ CVSROOT=:pserver:anonymous@huis-clos.mit.edu:/usr/local/repository cvs log cvs [log aborted]: connect to huis-clos.mit.edu:2401 failed: Connection refused hjstein@bacall:~/software/guilesw$ Is anonymous CVS supported? If so, how am I supposed to use it? Thanks, Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 16:37:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26025 for scwm-discuss-outgoing; Thu, 16 Jul 1998 16:37:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26022 for ; Thu, 16 Jul 1998 16:36:58 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08642; Thu, 16 Jul 98 16:36:52 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA25163; Thu, 16 Jul 1998 13:36:45 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: From: Greg Badros Date: 16 Jul 1998 13:36:44 -0700 In-Reply-To: hjstein@bfr.co.il's message of "16 Jul 1998 22:46:39 +0300" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Is anonymous CVS supported? If so, how am I supposed to use it? I didn't think so, but it'd be nice if we did support it. (If we do support it, we need to add instructions to the web page.) Anybody have any experience setting anonymous read-only CVS? Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 16 16:45:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26121 for scwm-discuss-outgoing; Thu, 16 Jul 1998 16:45:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26118 for ; Thu, 16 Jul 1998 16:45:38 -0400 Received: from junk.hemmet.s-hem.chalmers.se by MIT.EDU with SMTP id AA10881; Thu, 16 Jul 98 16:45:31 EDT Received: from james by junk.nocrew.org with local (Exim 1.92 #1 (Debian)) id 0ywuuF-0003oC-00; Thu, 16 Jul 1998 21:45:35 +0100 To: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: Mail-Copies-To: never Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: James Troup Date: 16 Jul 1998 21:45:35 +0100 In-Reply-To: Greg Badros's message of "16 Jul 1998 13:36:44 -0700" Message-Id: <7zd8b5y174.fsf@junk.nocrew.org> Lines: 23 X-Mailer: Gnus v5.6.24/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Anybody have any experience setting anonymous read-only CVS? Yep, IIRC, all you need is a readers and passwd file in your CVSROOT. 21:41:40@junk| ~/yawncvs/CVSROOT $cat readers anonymous 21:41:42@junk| ~/yawncvs/CVSROOT $cat passwd anonymous:69S/nLyi1wYKc:james 21:41:45@junk| ~/yawncvs/CVSROOT $ (You'll want to replace "james" with the name of some registered CVS user; don't ask me why it's needed, 'cos I don't know :) Then you can use it anonymously in a la yawn/gnome/gimp/openBSD (see any of their web pages for user-instructions). HTH. -- James ~Yawn And Walk North~ http://yawn.nocrew.org/ From owner-scwm-discuss@mit.edu Thu Jul 16 16:50:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26184 for scwm-discuss-outgoing; Thu, 16 Jul 1998 16:50:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26180 for ; Thu, 16 Jul 1998 16:50:48 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA07854; Thu, 16 Jul 98 16:50:54 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA15157; Thu, 16 Jul 1998 23:50:32 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 23:50:32 +0300 In-Reply-To: Greg Badros's message of "16 Jul 1998 13:36:44 -0700" Message-Id: Lines: 32 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Is anonymous CVS supported? If so, how am I supposed to use it? > > I didn't think so, but it'd be nice if we did support it. (If we do > support it, we need to add instructions to the web page.) > > Anybody have any experience setting anonymous read-only CVS? I haven't done it, but there's a "Password authentication server" node in the info pages. It gives the cvs cmd to put on port 2401 for cvs pserver support. You can also set up a cvs specific password file. Then, I guess you just make a password file with username anonymous, maybe map it to user nobody on your system (or some other user with no privileges), making sure none of the files in the CVS repository are writable by this user. The Gnome guys just set one up. Maybe sopwith@redhat.com could help out (they ask people willing to set up an anonymous CVS mirror to write him). Maybe you could mirror each other (since the projects are related). BTW, they've also set up Bonsai & LXR for their source tree. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 16:52:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26249 for scwm-discuss-outgoing; Thu, 16 Jul 1998 16:52:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26246 for ; Thu, 16 Jul 1998 16:52:55 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA12824; Thu, 16 Jul 98 16:52:48 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA15174; Thu, 16 Jul 1998 23:52:50 +0300 To: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <7zd8b5y174.fsf@junk.nocrew.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Jul 1998 23:52:50 +0300 In-Reply-To: James Troup's message of "16 Jul 1998 21:45:35 +0100" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk James Troup writes: > Greg Badros writes: > > > Anybody have any experience setting anonymous read-only CVS? > > Yep, IIRC, all you need is a readers and passwd file in your CVSROOT. > > 21:41:40@junk| ~/yawncvs/CVSROOT $cat readers > anonymous > 21:41:42@junk| ~/yawncvs/CVSROOT $cat passwd > anonymous:69S/nLyi1wYKc:james > 21:41:45@junk| ~/yawncvs/CVSROOT $ > > (You'll want to replace "james" with the name of some registered CVS > user; don't ask me why it's needed, 'cos I don't know :) cvs runs as user james when remote user anonymous connects. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 16 17:01:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA26432 for scwm-discuss-outgoing; Thu, 16 Jul 1998 17:01:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA26429 for ; Thu, 16 Jul 1998 17:01:53 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA11044; Thu, 16 Jul 98 17:02:06 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA25440; Thu, 16 Jul 1998 14:01:48 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: From: Greg Badros Date: 16 Jul 1998 14:01:47 -0700 In-Reply-To: hjstein@bfr.co.il's message of "16 Jul 1998 23:50:32 +0300" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > > > Is anonymous CVS supported? If so, how am I supposed to use it? > > > > I didn't think so, but it'd be nice if we did support it. (If we do > > support it, we need to add instructions to the web page.) > > > > Anybody have any experience setting anonymous read-only CVS? > > I haven't done it, but there's a "Password authentication server" node > in the info pages. It gives the cvs cmd to put on port 2401 for cvs > pserver support. Maciej, it looks like some root files will need to be munged to make this work. I think it'd be a real good thing to support anonymous read cvs (definitely easier for others to track the development version that way). Greg From owner-scwm-discuss@mit.edu Thu Jul 16 17:54:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA26701 for scwm-discuss-outgoing; Thu, 16 Jul 1998 17:54:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA26697 for ; Thu, 16 Jul 1998 17:54:11 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA22959; Thu, 16 Jul 98 17:54:24 EDT Received: from marconi.concentric.net (marconi [206.173.119.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id RAA01980; Thu, 16 Jul 1998 17:54:02 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d01.phe-pa.concentric.net [209.31.155.61]) by marconi.concentric.net (8.8.8) id RAA01000; Thu, 16 Jul 1998 17:54:00 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA29603; Thu, 16 Jul 1998 15:28:26 -0400 To: scwm-discuss@mit.edu Subject: Re: Backtraces from scwm-mode in Emacs References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: Greg Badros's message of "16 Jul 1998 12:01:56 -0700" Date: 16 Jul 1998 15:28:25 -0400 Message-Id: Lines: 57 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 16 Jul 1998 12:01:56 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Backtraces from scwm-mode in Emacs": >> It works with C-j, but not with C-x C-j. call-process docs says: does XEmacs have a *Messages* buffer? (a buffer where all the messages are logged) What can you see there? (It might be called " *message-0*" with the leading space or something). >> `call-process' is a compiled Lisp function >> -- loaded from "process.elc" >> (call-process PROGRAM &optional INFILE BUFFER DISPLAYP &rest ARGS) this is identical to Emacs. >> But I can't get the form (REAL_BUFFER STDERR_FILE) to work as >> advertised. you shouldn't need to. >> Also, why does the code in scwm-eval-to-minibuffer not use >> scwm-eval-last? (it duplicates the code for getting the last sexp). Because XEmacs' implementation of with-output-to-string is buggy: `last' in the function `scwm-eval-to-minibuffer' will be nil. It was (defun scwm-eval-to-minibuffer () "Evaluate the last SEXP and show the result in the minibuffer." (interactive) (message (with-output-to-string (scwm-eval-last standard-output)))) until someone (possibly you :-) complained that it didn't work with XEmacs. Put (with-output-to-string (prin1 (buffer-substring-no-properties 1 10))) in the beginning of *scratch* and hit C-j. You should get "\"(with-out\"" inserted into the buffer, and that's what you get with Emacs. XEmacs barfs. >> I'm using XEmacs 20.4 on a Linux box. I think you should report these (1. scwm.el C-x C-j problem and 2. `with-output-to-string') as XEmacs bugs. PS Please remove my name from the "To:" list when replying to my messages if you keep scwm-discuss. I **am** subscribed to the list, and I do not like getting 2 copies of every message. Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A man paints with his brains and not with his hands. From owner-scwm-discuss@mit.edu Thu Jul 16 20:19:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA27623 for scwm-discuss-outgoing; Thu, 16 Jul 1998 20:19:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA27620 for ; Thu, 16 Jul 1998 20:19:03 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA25150; Thu, 16 Jul 98 20:19:16 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id UAA05764; Thu, 16 Jul 1998 20:18:52 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: From: Jim Blandy Date: 16 Jul 1998 20:18:50 -0400 In-Reply-To: Greg Badros's message of 16 Jul 1998 14:01:47 -0700 Message-Id: Lines: 8 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Keep in mind, CVS was not at all written to be secure. The obvious holes have been closed, but I'm sure there are potential buffer overruns or perversities. It's probably not worth worrying about, but you should be aware of the issue. The Guile group is probably going to switch to anonymous CVS very soon. From owner-scwm-discuss@mit.edu Thu Jul 16 21:23:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA27902 for scwm-discuss-outgoing; Thu, 16 Jul 1998 21:23:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA27899 for ; Thu, 16 Jul 1998 21:23:57 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA27577; Thu, 16 Jul 98 21:23:49 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id VAA04400; Thu, 16 Jul 1998 21:23:53 -0400 (EDT) Message-Id: <199807170123.VAA04400@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: set-edge-resistance! and double clicks In-Reply-To: Your message of "Thu, 16 Jul 1998 09:11:00 EDT." <199807161311.JAA21986@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jul 1998 21:23:51 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > This makes me suspect that the way scwm does the delays for these > things is not working on NetBSD, since, AFAIK, you're the only person > using scwm on NetBSD. The code uses usleep() in small increments in > both of these cases to delay for a little while repeatedly until the > timeout expires or the mouse is moved away. On systems that do not > have usleep(), it is implemented in terms of select() in the file > syscompat.c. Is there any reason this might not work right on your > machine? I've checked, and our usleep() implementation works fine, and HAVE_USLEEP is being defined in config.h Bleh! (BTW, I'm a little surprised the code there uses polling and not timeouts or some other interrupt driven mechanism, but...) Any other ideas on debugging this? Perry From owner-scwm-discuss@mit.edu Thu Jul 16 21:50:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA28346 for scwm-discuss-outgoing; Thu, 16 Jul 1998 21:50:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA28340 for ; Thu, 16 Jul 1998 21:50:45 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA00487; Thu, 16 Jul 98 21:50:38 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA28330; Thu, 16 Jul 1998 21:50:40 -0400 Message-Id: <199807170150.VAA28330@huis-clos.mit.edu> To: hjstein@bfr.co.il Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? Date: Thu, 16 Jul 1998 21:50:38 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Is anonymous CVS supported? If so, how am I supposed to use it? Anonymous CVS is not supported. The last time this came up, most people seemed to be satisfied with nightly snapshots. Is there a big demand for this? I am hesitant to do it because the machine that's generously hosting the scwm CVS repository right now has had problems with system crackers before, and I don't want to open any potential security holes (this is why all the real CVS access is through ssh, but I don't think that can scale to anonymous CVS). - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 22:00:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA28570 for scwm-discuss-outgoing; Thu, 16 Jul 1998 22:00:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA28555; Thu, 16 Jul 1998 21:59:59 -0400 Message-Id: <199807170159.VAA28555@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-reply-to: Your message of "16 Jul 1998 14:01:47 PDT." Date: Thu, 16 Jul 1998 21:59:58 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > Maciej, it looks like some root files will need to be munged to make > this work. I think it'd be a real good thing to support anonymous read > cvs (definitely easier for others to track the development version that > way). > OK, I read over the instructions people posted. If people can give me some vague assurance that there's no way read-only anonymous CVS access can compromise the machine's security (currently all remote access is done by ssh because system crackers really love to attack MITnet), I'll do it. (Well, I'll also have to ask the owner of the machine if she doesn't mind the potential network/cpu load from this, which I have no way of estimating). - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 22:17:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA28842 for scwm-discuss-outgoing; Thu, 16 Jul 1998 22:17:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA28839 for ; Thu, 16 Jul 1998 22:17:46 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10059; Thu, 16 Jul 98 22:17:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA27787; Thu, 16 Jul 1998 19:17:40 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807170159.VAA28555@huis-clos.mit.edu> From: Greg Badros Date: 16 Jul 1998 19:17:40 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 16 Jul 1998 21:59:58 EDT" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > OK, I read over the instructions people posted. If people can give me > some vague assurance that there's no way read-only anonymous CVS > access can compromise the machine's security (currently all remote There's always a way, of course. > access is done by ssh because system crackers really love to attack > MITnet), I'll do it. (Well, I'll also have to ask the owner of the > machine if she doesn't mind the potential network/cpu load from this, > which I have no way of estimating). If it's ok with the owner, it may be worth a trial period w/o any promises of it living beyond that trial period... Greg From owner-scwm-discuss@mit.edu Thu Jul 16 22:25:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA28988 for scwm-discuss-outgoing; Thu, 16 Jul 1998 22:25:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA28984; Thu, 16 Jul 1998 22:25:15 -0400 Message-Id: <199807170225.WAA28984@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Re: set-edge-resistance! and double clicks In-reply-to: Your message of "Thu, 16 Jul 1998 21:23:51 EDT." <199807170123.VAA04400@jekyll.piermont.com> Date: Thu, 16 Jul 1998 22:25:14 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > > I've checked, and our usleep() implementation works fine, and > HAVE_USLEEP is being defined in config.h > > Bleh! > Weird! > (BTW, I'm a little surprised the code there uses polling and not > timeouts or some other interrupt driven mechanism, but...) > That's largely because We Haven't Rewritten That Yet(tm). I think this should be the new scwm motto. > Any other ideas on debugging this? > Umm, add debugging printf()s to the timing loops in question to see what's really going on? That's about all I can think of. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Jul 16 23:02:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA29423 for scwm-discuss-outgoing; Thu, 16 Jul 1998 23:02:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA29415 for ; Thu, 16 Jul 1998 23:01:51 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA15068; Thu, 16 Jul 98 23:02:02 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id XAA04654; Thu, 16 Jul 1998 23:01:46 -0400 (EDT) Message-Id: <199807170301.XAA04654@jekyll.piermont.com> To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "Thu, 16 Jul 1998 21:59:58 EDT." <199807170159.VAA28555@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jul 1998 23:01:46 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > OK, I read over the instructions people posted. If people can give me > some vague assurance that there's no way read-only anonymous CVS > access can compromise the machine's security There is no such assurance. CVS hasn't been well enough beaten on, IMHO. There is stuff you can do to make it better, though. Perry From owner-scwm-discuss@mit.edu Thu Jul 16 23:14:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA29786 for scwm-discuss-outgoing; Thu, 16 Jul 1998 23:14:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA29783 for ; Thu, 16 Jul 1998 23:14:56 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA16602; Thu, 16 Jul 98 23:15:08 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA29779; Thu, 16 Jul 1998 23:14:53 -0400 Message-Id: <199807170314.XAA29779@huis-clos.mit.edu> To: perry@piermont.com Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "Thu, 16 Jul 1998 23:01:46 EDT." <199807170301.XAA04654@jekyll.piermont.com> Date: Thu, 16 Jul 1998 23:14:53 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > OK, I read over the instructions people posted. If people can give me > > some vague assurance that there's no way read-only anonymous CVS > > access can compromise the machine's security > > There is no such assurance. CVS hasn't been well enough beaten on, > IMHO. There is stuff you can do to make it better, though. > If you can suggest ways to mitigate the risk (or where I can look such things up), I'd appreciate it. I spoke to the owner of the machine and she was willing to haave it set up on a trial basis, so everyone can expect anonymous CVS to come soon, at least temporarily. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 16 23:22:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA29898 for scwm-discuss-outgoing; Thu, 16 Jul 1998 23:22:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA29895 for ; Thu, 16 Jul 1998 23:22:36 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA17465; Thu, 16 Jul 98 23:22:48 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id XAA04723; Thu, 16 Jul 1998 23:22:32 -0400 (EDT) Message-Id: <199807170322.XAA04723@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "Thu, 16 Jul 1998 23:14:53 EDT." <199807170314.XAA29779@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 16 Jul 1998 23:22:32 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > There is no such assurance. CVS hasn't been well enough beaten on, > > IMHO. There is stuff you can do to make it better, though. > > If you can suggest ways to mitigate the risk (or where I can look such > things up), I'd appreciate it. Run the CVS server at very low privs, for one thing. Create an ID just for it if you can. If I had my druthers, I'd run the thing in a chrooted jail and make sure there was very little capable of being touched outside the jail. (In fact, if I *really* had my druthers, I'd do that and only have anon cvs available from a mirror machine, but that's a giant pain.) The biggest risk is, of course, buffer overflows, which an audit can reduce. Unfortunately, as a user, your goal here is probably to run CVS, not to do a full security audit of it. :( > I spoke to the owner of the machine and she was willing to haave it > set up on a trial basis, so everyone can expect anonymous CVS to come > soon, at least temporarily. BTW, no joke -- but if CVS was written in scheme instead of C it would be much safer. Of course, it is already slow as hell, and besides, if it were to be rewritten, the design would be best totally changed given its defects... Perry From owner-scwm-discuss@mit.edu Thu Jul 16 23:33:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA30045 for scwm-discuss-outgoing; Thu, 16 Jul 1998 23:33:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA30039; Thu, 16 Jul 1998 23:33:23 -0400 Message-Id: <199807170333.XAA30039@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-reply-to: Your message of "Thu, 16 Jul 1998 23:22:32 EDT." <199807170322.XAA04723@jekyll.piermont.com> Date: Thu, 16 Jul 1998 23:33:23 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > > There is no such assurance. CVS hasn't been well enough beaten on, > > > IMHO. There is stuff you can do to make it better, though. > > > > If you can suggest ways to mitigate the risk (or where I can look such > > things up), I'd appreciate it. > > Run the CVS server at very low privs, for one thing. Create an ID just > for it if you can. > > If I had my druthers, I'd run the thing in a chrooted jail and make > sure there was very little capable of being touched outside the jail. > > (In fact, if I *really* had my druthers, I'd do that and only have > anon cvs available from a mirror machine, but that's a giant pain.) > Thanks for the suggestions. There's a limit to how many of those I can do (a mirror machine is right out) but I'll see what I can whip up. > The biggest risk is, of course, buffer overflows, which an audit can > reduce. Unfortunately, as a user, your goal here is probably to run > CVS, not to do a full security audit of it. :( > Yeah. :-( > > BTW, no joke -- but if CVS was written in scheme instead of C it would > be much safer. Of course, it is already slow as hell, and besides, if > it were to be rewritten, the design would be best totally changed > given its defects... > I think most of us here already know that C is the language that's made us live in the wonderful world of buffer overflows for 30 years now. - Maciej From owner-scwm-discuss@mit.edu Fri Jul 17 10:35:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA00704 for scwm-discuss-outgoing; Fri, 17 Jul 1998 10:35:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA00701 for ; Fri, 17 Jul 1998 10:35:19 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24425; Fri, 17 Jul 98 10:35:17 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA19660; Fri, 17 Jul 1998 17:34:50 +0300 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807170159.VAA28555@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Jul 1998 17:34:50 +0300 In-Reply-To: Maciej Stachowiak's message of "Thu, 16 Jul 1998 21:59:58 EDT" Message-Id: Lines: 43 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > OK, I read over the instructions people posted. If people can give me > some vague assurance that there's no way read-only anonymous CVS > access can compromise the machine's security (currently all remote > access is done by ssh because system crackers really love to attack > MITnet), I'll do it. (Well, I'll also have to ask the owner of the > machine if she doesn't mind the potential network/cpu load from this, > which I have no way of estimating). What'd be nice about anon cvs vs nightly snaps is that: a) people wouldn't have to download, untar & rebuild to check out the latest version. They could just cvs update & make (assuming your deps are set up & assuming no configure changes). b) people could maintain their patches against the latest code until they've made it into the code. I'd think the project isn't big enough for b) to be common yet, but I'd personally like a). As for security, how much damage can be done if: a) cvs pserver runs as user anoncvs, b) user anoncvs doesn't have a login shell, c) user anoncvs's password is turned off, d) cvs pserver runs chrooted to /usr/local/cvs, e) nothing in /usr/local/cvs is writable by user anoncvs, f) nothing in /usr/local/cvs is setuid or setgid. Even in the face of buffer overflows, what could happen? I guess the only thing that could happen would be a buffer overflow which causes code to execute which exploits a kernel security hole. And, BTW, with respect to the comments about cvs being safe if implemented in scheme: Don't forget that the scheme interpreter is written in C. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Jul 17 11:46:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA01271 for scwm-discuss-outgoing; Fri, 17 Jul 1998 11:46:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA01268 for ; Fri, 17 Jul 1998 11:46:07 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA29541; Fri, 17 Jul 98 11:45:53 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA02527; Fri, 17 Jul 1998 11:45:44 -0400 (EDT) Message-Id: <199807171545.LAA02527@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "17 Jul 1998 17:34:50 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 11:45:44 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > a) cvs pserver runs as user anoncvs, Good. > b) user anoncvs doesn't have a login shell, > c) user anoncvs's password is turned off, Neither help anything. The way you break in is with a buffer overflow attack on CVS, and at that point you have shell access, and presumably use another exploit to get root. The reason for running chrooted is to try to minimize the chance of getting on to the host being of use to the attacker. > d) cvs pserver runs chrooted to /usr/local/cvs, Good. > e) nothing in /usr/local/cvs is writable by user anoncvs, > f) nothing in /usr/local/cvs is setuid or setgid. Good. > Even in the face of buffer overflows, what could happen? Plenty, but our hope is that the attackers aren't going to bother if the machine is this tough. > And, BTW, with respect to the comments about cvs being safe if > implemented in scheme: Don't forget that the scheme interpreter is > written in C. Yes, but it is, in practice, harder to miss overflows in the interpreter itself, and once fixed there, all programs gain security. Perry From owner-scwm-discuss@mit.edu Fri Jul 17 12:16:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01491 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:16:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01485 for ; Fri, 17 Jul 1998 12:15:57 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA23982; Fri, 17 Jul 98 12:16:03 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA02638 for ; Fri, 17 Jul 1998 12:15:44 -0400 (EDT) Message-Id: <199807171615.MAA02638@jekyll.piermont.com> To: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "Fri, 17 Jul 1998 11:45:44 EDT." <199807171545.LAA02527@jekyll.piermont.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 12:15:44 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > > b) user anoncvs doesn't have a login shell, > > c) user anoncvs's password is turned off, > > Neither help anything. That was, of course, too strong a statement. They both help stopping people from merely logging in as anoncvs. .pm From owner-scwm-discuss@mit.edu Fri Jul 17 12:16:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01510 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:16:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01507 for ; Fri, 17 Jul 1998 12:16:50 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08147; Fri, 17 Jul 98 12:16:34 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA20181; Fri, 17 Jul 1998 19:16:32 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807171545.LAA02527@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Jul 1998 19:16:31 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 17 Jul 1998 11:45:44 -0400" Message-Id: Lines: 51 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > a) cvs pserver runs as user anoncvs, > > Good. > > > b) user anoncvs doesn't have a login shell, > > c) user anoncvs's password is turned off, > > Neither help anything. It makes sure the anoncvs account can't be directly exploited (via telnet, rsh, ...). > The way you break in is with a buffer overflow attack on CVS, and at > that point you have shell access, and presumably use another exploit > to get root. > > The reason for running chrooted is to try to minimize the chance of > getting on to the host being of use to the attacker. > > > d) cvs pserver runs chrooted to /usr/local/cvs, > > Good. > > > e) nothing in /usr/local/cvs is writable by user anoncvs, > > f) nothing in /usr/local/cvs is setuid or setgid. > > Good. > > > Even in the face of buffer overflows, what could happen? > > Plenty, but our hope is that the attackers aren't going to bother if > the machine is this tough. Like what? Point a) means that the server is always run as user anoncvs. Points d) & e) mean that cvs can't write to the disk. Point f) means that even if someone manages to get a shell via a buffer overflow, they can't exploit anything else to get root. Basically, as far as I can see, if the above holds, then there are no user space exploits left. The only thing that would be left is a buffer overflow to utilize a kernel exploit. Are you saying there'd still be user space exploits? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Jul 17 12:19:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01557 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:19:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01553 for ; Fri, 17 Jul 1998 12:19:21 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24968; Fri, 17 Jul 98 12:19:25 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA20198; Fri, 17 Jul 1998 19:18:57 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807171545.LAA02527@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Jul 1998 19:18:57 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 17 Jul 1998 11:45:44 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > And, BTW, with respect to the comments about cvs being safe if > > implemented in scheme: Don't forget that the scheme interpreter is > > written in C. > > Yes, but it is, in practice, harder to miss overflows in the > interpreter itself, and once fixed there, all programs gain security. It's not just in the interpreter itself. It's in the interpreter, the C library, whatever other libraries are linked in, and in the kernel. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Jul 17 12:22:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01596 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:22:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01593 for ; Fri, 17 Jul 1998 12:22:07 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA25933; Fri, 17 Jul 98 12:22:13 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA02683; Fri, 17 Jul 1998 12:21:52 -0400 (EDT) Message-Id: <199807171621.MAA02683@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: perry@piermont.com, Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "17 Jul 1998 19:16:31 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 12:21:52 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > > > > Good. > > > > > e) nothing in /usr/local/cvs is writable by user anoncvs, > > > f) nothing in /usr/local/cvs is setuid or setgid. > > > > Good. > > > > > Even in the face of buffer overflows, what could happen? > > > > Plenty, but our hope is that the attackers aren't going to bother if > > the machine is this tough. > Like what? Point a) means that the server is always run as user > anoncvs. Points d) & e) mean that cvs can't write to the disk. Point > f) means that even if someone manages to get a shell via a buffer > overflow, they can't exploit anything else to get root. Why do you assume that is necessary to get root? You can get root in all sorts of other ways. For a while, on Suns, you could get root by a bug in the division emulation. I bleat you not. There are frequently other sorts of non-suid/sgid bugs around. I agree that those are *easier*, but hardly the sole things available. BTW, you can't stop anoncvs from writing at all, because it needs to write to do some of its work. :( Perry From owner-scwm-discuss@mit.edu Fri Jul 17 12:22:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01617 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:22:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01613 for ; Fri, 17 Jul 1998 12:22:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA09874; Fri, 17 Jul 98 12:22:08 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA20241; Fri, 17 Jul 1998 19:22:07 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807171545.LAA02527@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Jul 1998 19:22:07 +0300 In-Reply-To: hjstein@bfr.co.il's message of "17 Jul 1998 19:18:57 +0300" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > "Perry E. Metzger" writes: > > > Harvey J. Stein writes: > > > And, BTW, with respect to the comments about cvs being safe if > > > implemented in scheme: Don't forget that the scheme interpreter is > > > written in C. > > > > Yes, but it is, in practice, harder to miss overflows in the > > interpreter itself, and once fixed there, all programs gain security. > > It's not just in the interpreter itself. It's in the interpreter, the > C library, whatever other libraries are linked in, and in the kernel. And don't forget race conditions associated with writing files (symlink attacks, mv attacks, etc) and with dropping permissions (suid & sgid stuff). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Jul 17 12:29:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01837 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:29:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01834 for ; Fri, 17 Jul 1998 12:29:52 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28347; Fri, 17 Jul 98 12:29:56 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA20292; Fri, 17 Jul 1998 19:29:12 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807171621.MAA02683@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Jul 1998 19:29:11 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 17 Jul 1998 12:21:52 -0400" Message-Id: Lines: 30 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Why do you assume that is necessary to get root? > > You can get root in all sorts of other ways. For a while, on Suns, you > could get root by a bug in the division emulation. I bleat you not. > > There are frequently other sorts of non-suid/sgid bugs around. I agree > that those are *easier*, but hardly the sole things available. Ok, so let's say kernel or hardware exploits. If you're in user space and there are no kernel or hardware exploits, and you're chrooted to a directory tree in which all directories & files aren't (according to permissions) writable by you, and this directory tree contains no s[ug]id scripts, are you saying that there are still ways to: a) write to the disk, or b) gain root? What did I leave out? > BTW, you can't stop anoncvs from writing at all, because it needs to > write to do some of its work. :( That *sucks*. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Jul 17 12:58:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA02059 for scwm-discuss-outgoing; Fri, 17 Jul 1998 12:58:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA02056 for ; Fri, 17 Jul 1998 12:58:19 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA19227; Fri, 17 Jul 98 12:58:02 EDT Received: from newman.concentric.net (newman [207.155.184.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id MAA19448; Fri, 17 Jul 1998 12:58:01 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts006d46.phe-pa.concentric.net [209.31.155.58]) by newman.concentric.net (8.8.8) id MAA15067; Fri, 17 Jul 1998 12:57:58 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id LAA31170; Fri, 17 Jul 1998 11:02:52 -0400 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , Greg Badros , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807170159.VAA28555@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "17 Jul 1998 17:34:50 +0300" Date: 17 Jul 1998 11:02:52 -0400 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk since I have CVS access anyway, the following is just some disinterested informatory remarks. >>>> In message >>>> Sent on 17 Jul 1998 17:34:50 +0300 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes >>>> on the subject of "Re: Anonymous CVS supported?": >> What'd be nice about anon cvs vs nightly snaps is that: >> a) people wouldn't have to download, untar & rebuild to check out >> the latest version. They could just cvs update & make (assuming >> your deps are set up & assuming no configure changes). aren't the nightly patches available too? downloading and applying the patches is *faster* than `cvs update`; especially when done daily. cvs' advantages start when you actively tweak with the sources. >> b) people could maintain their patches against the latest code until >> they've made it into the code. this is certainly an advantage. but those for whom this matters should have write access anyway. I am not opposed to anoncvs; I am just trying to say that cvs gives most of its advantages to the developers, not to those who are just trying to stay on the leading edge. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Diplomacy is the art of saying "nice doggy" until you can find a rock. From owner-scwm-discuss@mit.edu Fri Jul 17 13:02:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02092 for scwm-discuss-outgoing; Fri, 17 Jul 1998 13:02:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02088 for ; Fri, 17 Jul 1998 13:02:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20215; Fri, 17 Jul 98 13:02:05 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA00529; Fri, 17 Jul 1998 10:02:07 -0700 (PDT) To: sds@goems.com Cc: hjstein@bfr.co.il (Harvey J. Stein), Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807170159.VAA28555@huis-clos.mit.edu> From: Greg Badros Date: 17 Jul 1998 10:02:06 -0700 In-Reply-To: Sam Steingold's message of "17 Jul 1998 11:02:52 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > aren't the nightly patches available too? > downloading and applying the patches is *faster* than `cvs update`; > especially when done daily. > cvs' advantages start when you actively tweak with the sources. It's not as easy nor as robust. Yes one could write a script that would make it almost as easy. Also, getting people using CVS may encourage more developers. Lots of good coders haven't used CVS before, and some of them could be useful to have on-board working with us. Greg From owner-scwm-discuss@mit.edu Fri Jul 17 13:47:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02539 for scwm-discuss-outgoing; Fri, 17 Jul 1998 13:47:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02536 for ; Fri, 17 Jul 1998 13:47:22 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01847; Fri, 17 Jul 98 13:47:06 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA03095; Fri, 17 Jul 1998 13:46:55 -0400 (EDT) Message-Id: <199807171746.NAA03095@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: Your message of "17 Jul 1998 19:29:11 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 17 Jul 1998 13:46:54 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > If you're in user space and there are no kernel or hardware exploits, And if my grandmother was a duck? But of course, she wasn't. > and you're chrooted to a directory tree in which all directories & > files aren't (according to permissions) writable by you, As I said, cvs needs to be able to write tmp files to do its work, so that isn't even an option. > > BTW, you can't stop anoncvs from writing at all, because it needs to > > write to do some of its work. :( > > That *sucks*. Yes, it does. Sow does CVS in general. It is better than all the alternatives, but not good. Unfortunately it is "just good enough" that no one will replace it. .pm From owner-scwm-discuss@mit.edu Sat Jul 18 00:31:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA08381 for scwm-discuss-outgoing; Sat, 18 Jul 1998 00:31:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA08374 for ; Sat, 18 Jul 1998 00:31:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18865; Sat, 18 Jul 98 00:31:28 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA05990; Fri, 17 Jul 1998 21:31:10 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Important changes to the development sources From: Greg Badros Date: 17 Jul 1998 21:31:09 -0700 Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Couple big changes everyone should be aware of: You should now never use malloc, safemalloc, or calloc -- use the new macros in system.h -- NEW, NEWC (takes a count like calloc), etc. Similarly, use FREE and FREEC from there as well -- FREEC's should match NEWC's (like delete []'s match new []'s in C++). The NEW, NEWC have the advantage of not requiring a cast to be legitimate C++. I've renamed lots and lots of ScwmWindow *'s to psw -- they were inconsistently named t, tmp_win, and lots of other things. Yes, psw is a Hungarian name, but I'm a big fan, and it's still really short and unambiguous. Other ScwmWindow *'s in the same scope generally have names such as pswTmp, etc. For the embeddable constraint solver, I am currently compiling using a C++ compiler (egcs 1.0.1 or better or gcc-2.8.1 or better) so lots of the recent changes I've made go to making scwm compile cleanly as both C++ and C. In another week or two I'll be posting some directions about what you need to do if you're interested in this compile-time-optional extension. Greg From owner-scwm-discuss@mit.edu Sat Jul 18 03:36:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA10282 for scwm-discuss-outgoing; Sat, 18 Jul 1998 03:36:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA10279 for ; Sat, 18 Jul 1998 03:36:49 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00373; Sat, 18 Jul 98 03:36:48 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA23785; Sat, 18 Jul 1998 10:36:16 +0300 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? References: <199807171746.NAA03095@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Jul 1998 10:36:16 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 17 Jul 1998 13:46:54 -0400" Message-Id: Lines: 44 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > If you're in user space and there are no kernel or hardware exploits, > > And if my grandmother was a duck? > > But of course, she wasn't. > > > and you're chrooted to a directory tree in which all directories & > > files aren't (according to permissions) writable by you, > > As I said, cvs needs to be able to write tmp files to do its work, so > that isn't even an option. Firstly, we were talking both generally & specifically. I gave a list of things to do & claimed that only kernel exploits would remain if they were done. I thought you said that other exploits would also remain. Whether or not CVS can be set up in such a way to satisfy the points I listed is another matter. If there are only root/hw exploits left after such a setup, and if CVS cannot be set up in that fashion, the questions become: a) How much work is it to modify CVS so that it can be set up satisfying the points, and b) How much is security compromised by relaxing the points sufficiently to allow the stock CVS implementation to run? In particular, where does CVS want to put temp files? Can it be configured to always put them into 1 particular directory in the chrooteed tree? If so, what's the worst thing that can happen if 1 directory is left world writable? The attacker fills the partition? The attacker uses the tmp directory as an internet software repository? I'd think that, aside from filling the damage would still be completely contained. > Sow does CVS in general. It is better than all the alternatives, but ^^^ ? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Jul 19 16:51:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA25076 for scwm-discuss-outgoing; Sun, 19 Jul 1998 16:51:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA25073 for ; Sun, 19 Jul 1998 16:51:01 -0400 Received: from smtp7.nwnexus.com by MIT.EDU with SMTP id AA18763; Sun, 19 Jul 98 16:50:44 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp7.nwnexus.com (8.8.8/8.8.8) with ESMTP id NAA14914 for ; Sun, 19 Jul 1998 13:50:24 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-21476>; Sun, 19 Jul 1998 13:47:29 -0700 To: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? In-Reply-To: scwm-discuss message of "18 Jul 1998 10:36:16 +0300." Date: Sun, 19 Jul 1998 13:47:18 -0600 From: Ken Pizzini Message-Id: <19980719204729Z276516-21476+35@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message , Harvey J. Stein said: > I gave a list > of things to do & claimed that only kernel exploits would remain if > they were done. I thought you said that other exploits would also > remain. It shouldn't be an issue on a machine which is already security concious, but another _potential_ exploit would be to take advantage of trust based on IP addressess, such as rsh's "authentication" mechanism. --Ken Pizzini From owner-scwm-discuss@mit.edu Mon Jul 20 06:19:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA29604 for scwm-discuss-outgoing; Mon, 20 Jul 1998 06:19:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA29601 for ; Mon, 20 Jul 1998 06:19:48 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA27797; Mon, 20 Jul 98 06:19:01 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id LAA15963 for ; Mon, 20 Jul 1998 11:19:05 +0100 Date: Mon, 20 Jul 1998 11:19:05 +0100 (BST) From: Danius Michaelides To: scwm-discuss@mit.edu Subject: Fvwm module compat progress Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Implemented and tested: Beep, ClickTime, Close, CursorMove, Delete, Desk, DesktopSize, Destroy, EdgeResistance, EdgeScroll, Exec, Focus, GotoPage, HilightColor, Iconify, Lower, Maximize, Move, OpaqueMoveSize, Quit, Raise, RaiseLower, Refresh, RefreshWindow, Resize, Restart, Scroll, Send_ConfigInfo, Send_WindowList, set_mask, SetAnimation, Stick, WarpToWindow, WindowsDesk, WindowShade, XORValue Implemented but not tested (or tested with problems): Echo, ExecUseSHELL, Recapture, Currently implementing: Current, Next, None, Prev (these all perform a command on a window derived from a list of windows which match certain conditions, eg: Next [visible *xterm*] focus ) Unimplemented: AddButtonStyle, AddModuleConfig, AddTitleStyle, AddToDecor, AddToFunc, AddToMenu, AnimatedMove, BorderStyle, ButtonStyle, ChangeDecor, ColorLimit, ColormapFocus, CursorStyle, DestroyDecor, DestroyFunc, DestroyMenu, DestroyModuleConfig, IconFont, FlipFocus, Function, GlobalOpts, IconPath, Key, KillModule, Menu, Menustyle, Module, ModulePath, Mouse, Nop, PipeRead, PixmapPath, PopUp, QuitScreen, Read, SendToModule, SetEnv, SetMenuDelay, Style, Title, TitleStyle, UpdateDecor, Wait, WindowFont, WindowId, WindowList, + Most of these are configuration type commands, some of which i'm not too sure about the best way to implement. For example: Key Meta_L A N Next [visible *xterm*] focus Should this become: (bind-key 'all "Meta_L" (lambda()(eval-fvwm-command "Next [visible *xterm*] focus"))) Or should we have a function fvwm-command-translate, which translates the command part into native scwm? The reason i ask, is because i think this will be closely linked with the .fvwm2rc to .scwmrc translator. Thoughts? Danius From owner-scwm-discuss@mit.edu Mon Jul 20 11:22:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31489 for scwm-discuss-outgoing; Mon, 20 Jul 1998 11:22:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31484 for ; Mon, 20 Jul 1998 11:22:52 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA14954; Mon, 20 Jul 98 11:22:27 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31476; Mon, 20 Jul 1998 11:22:45 -0400 Message-Id: <199807201522.LAA31476@huis-clos.mit.edu> To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: Fvwm module compat progress In-Reply-To: Your message of "Mon, 20 Jul 1998 11:19:05 BST." Date: Mon, 20 Jul 1998 11:22:45 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk danius@duff.org writes: > Implemented and tested: > > Beep, ClickTime, Close, CursorMove, Delete, Desk, DesktopSize, Destroy, > EdgeResistance, EdgeScroll, Exec, Focus, GotoPage, HilightColor, Iconify, > Lower, Maximize, Move, OpaqueMoveSize, Quit, Raise, RaiseLower, Refresh, > RefreshWindow, Resize, Restart, Scroll, Send_ConfigInfo, Send_WindowList, > set_mask, SetAnimation, Stick, WarpToWindow, WindowsDesk, WindowShade, > XORValue > That's awesome! Send me a patch whenever you feel ready (patches in smaller chunks will be easier to incorporate). Also, please take a look at the patch submission guidelines I sent you in another message. (For others who care, my personal patch preferences are `diff -uwb', patch included as plain text, not as mime attachment, and if the change is large, a suggested ChangeLog entry). > Implemented but not tested (or tested with problems): > Echo, ExecUseSHELL, Recapture, > > Currently implementing: > Current, Next, None, Prev > `Current'? Is this a new one? What does it do? > (these all perform a command on a window derived from a list of > windows which match certain conditions, eg: > Next [visible *xterm*] focus > ) > We have similar things in the (app scwm winlist) and (app scwm fvwm-compat) modules. Let me know if these are not up to the funtionality the fvwm versions need. In fact, let me know if any of the scwm primitives do not provide enough functionality to emulate the fvwm equivalents. > Unimplemented: > > AddButtonStyle, AddModuleConfig, AddTitleStyle, AddToDecor, AddToFunc, > AddToMenu, AnimatedMove, BorderStyle, ButtonStyle, ChangeDecor, > ColorLimit, ColormapFocus, CursorStyle, DestroyDecor, DestroyFunc, > DestroyMenu, DestroyModuleConfig, IconFont, FlipFocus, Function, > GlobalOpts, IconPath, Key, KillModule, Menu, Menustyle, Module, > ModulePath, Mouse, Nop, PipeRead, PixmapPath, PopUp, QuitScreen, Read, > SendToModule, SetEnv, SetMenuDelay, Style, Title, TitleStyle, UpdateDecor, > Wait, WindowFont, WindowId, WindowList, + > Some of these will probably be tricky to get right. I see that there are several new commands since we forked from fvwm, in particular, I note AnimatedMove, ColorLimit, CursorStyle, SetEnv and SetMenuDelay which I've not seen before. AnimatedMove should be doable beacuse we've independently implemented that stuff in scwm, and SetEnv (if it does what I think) should be doable with Guile primitives. However, I think CursortStyle, ColorLimit and SetMenuDelay will probably all require new code in scwm. > Most of these are configuration type commands, some of which i'm not > too sure about the best way to implement. For example: > > Key Meta_L A N Next [visible *xterm*] focus > > Should this become: > (bind-key 'all "Meta_L" > (lambda()(eval-fvwm-command "Next [visible *xterm*] focus"))) > > Or should we have a function fvwm-command-translate, which translates > the command part into native scwm? The reason i ask, is because i > think this will be closely linked with the .fvwm2rc to .scwmrc > translator. > I think the best thing would be to do it this way for now (i.e. include eval-fvwm-command in the bindings). However, if you feel comfortable doing the translation to Scheme code, that would be fine too; we could reuse this work for the translator (which I have recently started on). However, it is somewhat tricky; for instance, it would be necessary to properly manage the window context for cases like this. - Maciej From owner-scwm-discuss@mit.edu Mon Jul 20 11:39:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31720 for scwm-discuss-outgoing; Mon, 20 Jul 1998 11:39:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31716; Mon, 20 Jul 1998 11:39:33 -0400 Message-Id: <199807201539.LAA31716@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Anynymous CVS Date: Mon, 20 Jul 1998 11:39:33 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I will probably set this up tonight. I have one question, though. I'm not sure I want the master repository to be in the chrooted jail that anoncvs lives in. Is there a way to keep a second an-disk copy of the repository reasonably in sync? I guess there must be something similar for remote anoncvs mirrors to work. Can anyone point me at the right thing? (Please no wide-ranging discussions of hardware security holes this time :-) - Maciej From owner-scwm-discuss@mit.edu Mon Jul 20 11:44:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31841 for scwm-discuss-outgoing; Mon, 20 Jul 1998 11:44:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31838 for ; Mon, 20 Jul 1998 11:44:48 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24703; Mon, 20 Jul 98 11:43:58 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA17577; Mon, 20 Jul 1998 18:44:02 +0300 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anynymous CVS References: <199807201539.LAA31716@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Jul 1998 18:44:02 +0300 In-Reply-To: Maciej Stachowiak's message of "Mon, 20 Jul 1998 11:39:33 EDT" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I will probably set this up tonight. > > I have one question, though. I'm not sure I want the master repository > to be in the chrooted jail that anoncvs lives in. Is there a way to > keep a second an-disk copy of the repository reasonably in sync? I > guess there must be something similar for remote anoncvs mirrors to > work. Can anyone point me at the right thing? (Please no wide-ranging > discussions of hardware security holes this time :-) The anon cvs server's running chrooted, right? You're personnally accessing the repository via :ext:, with ssh, right? So your normal access won't be chrooted, right? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jul 20 11:48:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31952 for scwm-discuss-outgoing; Mon, 20 Jul 1998 11:48:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31940; Mon, 20 Jul 1998 11:48:12 -0400 Message-Id: <199807201548.LAA31940@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Anynymous CVS In-reply-to: Your message of "20 Jul 1998 18:44:02 +0300." Date: Mon, 20 Jul 1998 11:48:12 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > I will probably set this up tonight. > > > > I have one question, though. I'm not sure I want the master repository > > to be in the chrooted jail that anoncvs lives in. Is there a way to > > keep a second an-disk copy of the repository reasonably in sync? I > > guess there must be something similar for remote anoncvs mirrors to > > work. Can anyone point me at the right thing? (Please no wide-ranging > > discussions of hardware security holes this time :-) > > The anon cvs server's running chrooted, right? You're personnally > accessing the repository via :ext:, with ssh, right? So your normal > access won't be chrooted, right? > What I mean is, I don't want anyone breaking the anoncvs to be able to much with the master repository. In theory, file perms should protect against this, but I think recent security discussions have well-demonstrated the difference between theory and practice, when it comes to security. So I would like the master repo to be outside the chroot, and the anon version be a mirror, inside the chroot. I'll search all the cvs docs I can find, but would appreciate advice on achieving this. - Maciej From owner-scwm-discuss@mit.edu Mon Jul 20 12:01:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32137 for scwm-discuss-outgoing; Mon, 20 Jul 1998 12:01:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32134 for ; Mon, 20 Jul 1998 12:01:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26647; Mon, 20 Jul 98 12:01:25 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA13497; Mon, 20 Jul 1998 09:00:59 -0700 (PDT) To: Maciej Stachowiak Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: Anynymous CVS References: <199807201548.LAA31940@huis-clos.mit.edu> From: Greg Badros Date: 20 Jul 1998 09:00:59 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 20 Jul 1998 11:48:12 EDT" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > What I mean is, I don't want anyone breaking the anoncvs to be able to > much with the master repository. In theory, file perms should protect > against this, but I think recent security discussions have > well-demonstrated the difference between theory and practice, when it > comes to security. So I would like the master repo to be outside the > chroot, and the anon version be a mirror, inside the chroot. I'll > search all the cvs docs I can find, but would appreciate advice on > achieving this. Just have a cron job execute a script to copy the repository every hour or two hours to a separate directory. Just: cd /usr/local/repository; tar cf - . | (cd /usr/anoncvs/jail; tar xvpf -) Then set up remote read-only anon cvs to use the /usr/anoncvs/jail CVSROOT. Greg From owner-scwm-discuss@mit.edu Mon Jul 20 12:06:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32199 for scwm-discuss-outgoing; Mon, 20 Jul 1998 12:06:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32196 for ; Mon, 20 Jul 1998 12:06:09 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA00632; Mon, 20 Jul 98 12:05:20 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA12154; Mon, 20 Jul 1998 12:05:24 -0400 (EDT) Message-Id: <199807201605.MAA12154@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anynymous CVS In-Reply-To: Your message of "Mon, 20 Jul 1998 11:39:33 EDT." <199807201539.LAA31716@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 20 Jul 1998 12:05:23 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I have one question, though. I'm not sure I want the master repository > to be in the chrooted jail that anoncvs lives in. Is there a way to > keep a second an-disk copy of the repository reasonably in sync? Well, there are two ways to deal with this. 1) CVS has a wide variety of hooks in it that permit actions to be taken on commits and other events. These can be general shell scripts, which can do anything, including copying a file. 2) You could just run a synchronization program every N hours, too. (If the repository copy is on a different machine, I would use "rsync", which is Damned Cool.) Perry From owner-scwm-discuss@mit.edu Mon Jul 20 12:48:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32680 for scwm-discuss-outgoing; Mon, 20 Jul 1998 12:48:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32677 for ; Mon, 20 Jul 1998 12:48:48 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA10167; Mon, 20 Jul 98 12:48:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA17945; Mon, 20 Jul 1998 19:47:58 +0300 To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Anynymous CVS References: <199807201605.MAA12154@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Jul 1998 19:47:58 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 20 Jul 1998 12:05:23 -0400" Message-Id: Lines: 37 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Maciej Stachowiak writes: > > I have one question, though. I'm not sure I want the master repository > > to be in the chrooted jail that anoncvs lives in. Is there a way to > > keep a second an-disk copy of the repository reasonably in sync? > > Well, there are two ways to deal with this. > > 1) CVS has a wide variety of hooks in it that permit actions to be > taken on commits and other events. These can be general shell scripts, > which can do anything, including copying a file. > > 2) You could just run a synchronization program every N hours, > too. (If the repository copy is on a different machine, I would use > "rsync", which is Damned Cool.) I thought of that, but what if someone's doing a checkout from the anon repository while the copy's occuring in the true repository? There's got to be a way to do the copy when it's safe to do it on both sides. An hourly rsync job which turns off access to the anon repo, waits for any existing cvs actions to complete, & then copies files might get partially updated files from the true repo. I suppose you might be able to fit such a job as a post commit action in the CVS scripts, but would you want commit to have to wait for activity on the anon repo to complete? Didn't the BSD guys do something along these lines? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Jul 20 13:07:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00142 for scwm-discuss-outgoing; Mon, 20 Jul 1998 13:07:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00139 for ; Mon, 20 Jul 1998 13:07:47 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA15771; Mon, 20 Jul 98 13:07:20 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13657; Mon, 20 Jul 1998 10:06:51 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: perry@piermont.com, Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Anynymous CVS References: <199807201605.MAA12154@jekyll.piermont.com> From: Greg Badros Date: 20 Jul 1998 10:06:51 -0700 In-Reply-To: hjstein@bfr.co.il's message of "20 Jul 1998 19:47:58 +0300" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I suppose you might be able to fit such a job as a post commit action > in the CVS scripts, but would you want commit to have to wait for > activity on the anon repo to complete? Post commit (loginfo admin file) could set a lock, do the mirror of changed files (using find . -newer .lastchangetime, or something like that, + tar) and then remove the lock file and touch the new .lastchangetime file. Greg From owner-scwm-discuss@mit.edu Mon Jul 20 13:08:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00161 for scwm-discuss-outgoing; Mon, 20 Jul 1998 13:08:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00156 for ; Mon, 20 Jul 1998 13:08:24 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA17458; Mon, 20 Jul 98 13:07:34 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA12354; Mon, 20 Jul 1998 13:07:30 -0400 (EDT) Message-Id: <199807201707.NAA12354@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Anynymous CVS In-Reply-To: Your message of "20 Jul 1998 19:47:58 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 20 Jul 1998 13:07:30 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > I thought of that, but what if someone's doing a checkout from the > anon repository while the copy's occuring in the true repository? > > There's got to be a way to do the copy when it's safe to do it on both > sides. CVS features locking under the covers. It isn't hard to get access to it. I believe it is even documented. Perry From owner-scwm-discuss@mit.edu Mon Jul 20 14:32:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01111 for scwm-discuss-outgoing; Mon, 20 Jul 1998 14:32:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01108 for ; Mon, 20 Jul 1998 14:32:38 -0400 Received: from h-205-217-246-113.netscape.com by MIT.EDU with SMTP id AA11051; Mon, 20 Jul 98 14:31:47 EDT Received: (from friedman@localhost) by piglet.splode.com (8.8.8/8.8.8) id LAA22508; Mon, 20 Jul 1998 11:32:16 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Noah Friedman To: mstachow@mit.edu Cc: scwm-discuss@mit.edu Subject: Re: Anonymous CVS supported? Reply-To: Noah Friedman In-Reply-To: Thu, 16 Jul 1998 23:14:53 EDT References: <199807170301.XAA04654@jekyll.piermont.com> <199807170314.XAA29779@huis-clos.mit.edu> Date: Mon, 20 Jul 1998 11:32:15 -0700 (PDT) Message-Id: <19980720113215.605230.FMU660@piglet.splode.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk >> > OK, I read over the instructions people posted. If people can give me >> > some vague assurance that there's no way read-only anonymous CVS >> > access can compromise the machine's security >> >> There is no such assurance. CVS hasn't been well enough beaten on, >> IMHO. There is stuff you can do to make it better, though. > >If you can suggest ways to mitigate the risk (or where I can look such >things up), I'd appreciate it. What mozilla.org does is to launch a wrapper program from inetd that does a chroot to a "jail" wherein the read-only CVS repository lives, before doing an exec of the real cvs program. The chrooted jail has its own cvs and related executables, a couple of shared libraries, and /tmp directory for cvs scratch space. (The jail wrapper also imposes a limit on the number of simultaneous pserver connections to try to contain heavy load on the server.) I can provide sources for the jail shell and more details on setup if you want them. From owner-scwm-discuss@mit.edu Mon Jul 20 14:35:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01227 for scwm-discuss-outgoing; Mon, 20 Jul 1998 14:35:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01224 for ; Mon, 20 Jul 1998 14:35:52 -0400 Received: from h-205-217-246-113.netscape.com by MIT.EDU with SMTP id AA11833; Mon, 20 Jul 98 14:35:02 EDT Received: (from friedman@localhost) by piglet.splode.com (8.8.8/8.8.8) id LAA22512; Mon, 20 Jul 1998 11:35:30 -0700 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Noah Friedman To: mstachow@mit.edu Cc: scwm-discuss@mit.edu Subject: Anynymous CVS Reply-To: Noah Friedman In-Reply-To: Mon, 20 Jul 1998 11:39:33 EDT References: <199807201539.LAA31716@huis-clos.mit.edu> Date: Mon, 20 Jul 1998 11:35:30 -0700 (PDT) Message-Id: <19980720113530.86702.FMU660@piglet.splode.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk >I have one question, though. I'm not sure I want the master repository >to be in the chrooted jail that anoncvs lives in. Is there a way to >keep a second an-disk copy of the repository reasonably in sync? I >guess there must be something similar for remote anoncvs mirrors to >work. Can anyone point me at the right thing? (Please no wide-ranging >discussions of hardware security holes this time :-) mozilla.org uses rsync to do this. We worried for a while about honoring CVS and/or RCS locks so we didn't try to copy a file that was in the middle of being written, but after implementing the first pass we never saw any problems even with 100s of developers working on the source every day, so we stopped worrying about it. From owner-scwm-discuss@mit.edu Mon Jul 20 14:41:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01420 for scwm-discuss-outgoing; Mon, 20 Jul 1998 14:41:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01414; Mon, 20 Jul 1998 14:41:09 -0400 Message-Id: <199807201841.OAA01414@huis-clos.mit.edu> To: Noah Friedman cc: scwm-discuss@mit.edu Subject: Re: Anynymous CVS In-reply-to: Your message of "Mon, 20 Jul 1998 11:35:30 PDT." <19980720113530.86702.FMU660@piglet.splode.com> Date: Mon, 20 Jul 1998 14:41:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk friedman@mozilla.org writes: > >I have one question, though. I'm not sure I want the master repository > >to be in the chrooted jail that anoncvs lives in. Is there a way to > >keep a second an-disk copy of the repository reasonably in sync? I > >guess there must be something similar for remote anoncvs mirrors to > >work. Can anyone point me at the right thing? (Please no wide-ranging > >discussions of hardware security holes this time :-) > > mozilla.org uses rsync to do this. We worried for a while about honoring > CVS and/or RCS locks so we didn't try to copy a file that was in the middle > of being written, but after implementing the first pass we never saw any > problems even with 100s of developers working on the source every day, so > we stopped worrying about it. As a language hacker, it pains me to accept incorrect semantics just because users are highly unlikely to see the breakage, but I guess even in that hugely unlikely case, you can always update again. Can you please send me the mozilla.org chroot script and other details of the mozilla.org anoncvs setup, as mentioned in a previous message? (Just to me personally, I assume the list doesn't care). Thanks, Maciej From owner-scwm-discuss@mit.edu Mon Jul 20 14:55:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01613 for scwm-discuss-outgoing; Mon, 20 Jul 1998 14:55:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA01610 for ; Mon, 20 Jul 1998 14:55:08 -0400 Received: by tis.bellhow.com; id OAA02445; Mon, 20 Jul 1998 14:54:23 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma002431; Mon, 20 Jul 98 14:54:12 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA12773 for ; Mon, 20 Jul 1998 14:54:07 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: 19980720 snapshot cassowary build problem Date: Mon, 20 Jul 1998 18:50:30 GMT Organization: Bell & Howell PSC Message-ID: <35b48d3d.344916643@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA01611 Sender: owner-scwm-discuss@mit.edu Precedence: bulk ./configure --prefix=$HOME --with-guile-prefix=$HOME && make && make install scwm.o: In function `scwm_main': /home/users10/smithd/src/scwm-19980720/scwm/scwm.c:274: undefined reference to `init_cassowary_scm' Here is the diff that I used to build. Why is init_cassowary_scm called twice anyway? Dale *** scwm/scwm.c~ Sun Jul 19 17:22:57 1998 --- scwm/scwm.c Mon Jul 20 14:38:52 1998 *************** *** 211,218 **** #ifdef USE_CASSOWARY ClSimplexSolver solver; - #endif void init_cassowary_scm(); /* * scwm_main - main routine for scwm --- 211,218 ---- #ifdef USE_CASSOWARY ClSimplexSolver solver; void init_cassowary_scm(); + #endif /* * scwm_main - main routine for scwm *************** *** 271,277 **** --- 271,279 ---- setlinebuf(stdout); init_font(); init_decor(); + #ifdef USE_CASSOWARY init_cassowary_scm(); + #endif init_callbacks(); init_add_window(); init_image(); *************** *** 1585,1588 **** /* tab-width: 8 */ /* c-basic-offset: 2 */ /* End: */ - --- 1587,1589 ---- -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Mon Jul 20 15:57:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01987 for scwm-discuss-outgoing; Mon, 20 Jul 1998 15:57:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01984 for ; Mon, 20 Jul 1998 15:57:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03130; Mon, 20 Jul 98 15:56:10 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA13977; Mon, 20 Jul 1998 12:56:03 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: 19980720 snapshot cassowary build problem References: <35b48d3d.344916643@mailhost> From: Greg Badros Date: 20 Jul 1998 12:56:03 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Mon, 20 Jul 1998 18:50:30 GMT" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > ./configure --prefix=$HOME --with-guile-prefix=$HOME && make && make install > > scwm.o: In function `scwm_main': > /home/users10/smithd/src/scwm-19980720/scwm/scwm.c:274: undefined reference to `init_cassowary_scm' > > Here is the diff that I used to build. Why is init_cassowary_scm called twice anyway? I'll fix scwm.c in the repository-- those changes were never intended to make it into the snapshot. init_cassowary_scm is not called twice -- the first is a prototype. Thanks for alerting me to this. Greg From owner-scwm-discuss@mit.edu Mon Jul 20 15:58:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02015 for scwm-discuss-outgoing; Mon, 20 Jul 1998 15:58:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02012 for ; Mon, 20 Jul 1998 15:58:24 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05518; Mon, 20 Jul 98 15:57:57 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA13980; Mon, 20 Jul 1998 12:57:36 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: 19980720 snapshot cassowary build problem References: <35b48d3d.344916643@mailhost> From: Greg Badros Date: 20 Jul 1998 12:57:36 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Mon, 20 Jul 1998 18:50:30 GMT" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Here is the diff that I used to build. Why is init_cassowary_scm called twice anyway? Sorry, you're right -- it is called twice (I was looking at your diff, not the code). There's an uninteresting reason why that has to do w/ details of how I'm developing the cassowary extension. Thanks again for catching this. Greg From owner-scwm-discuss@mit.edu Tue Jul 21 04:42:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA19599 for scwm-discuss-outgoing; Tue, 21 Jul 1998 04:42:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA19596 for ; Tue, 21 Jul 1998 04:42:43 -0400 Received: from king.ki.informatik.uni-frankfurt.de by MIT.EDU with SMTP id AA01874; Tue, 21 Jul 98 04:42:07 EDT Received: (from marko@localhost) by king.ki.informatik.uni-frankfurt.de (8.7.1/8.7.1) id KAA09734; Tue, 21 Jul 1998 10:41:33 +0200 (MESZ) Date: Tue, 21 Jul 1998 10:41:33 +0200 (MESZ) Message-Id: <199807210841.KAA09734@king.ki.informatik.uni-frankfurt.de> From: Marko Schuetz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: schauss@cs.uni-frankfurt.de, arne@ki.informatik.uni-frankfurt.de, klose@informatik.uni-frankfurt.de, mann@cs.uni-frankfurt.de, sep@software-ag.de, m_schnei@cs.uni-frankfurt.de, scwm-discuss@mit.edu, casbah@ntlug.org Subject: Fwd: ICFP Functional Programming Contest X-Mailer: VM 6.34 under Emacs 20.2.1 Reply-To: marko@cs.uni-frankfurt.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk http://www.ai.mit.edu/extra/icfp-contest/ ICFP Functional Programming Contest Welcome to the ICFP'98 functional programming contest! We now have a FAQ for the contest, where we're collecting questions of general interest that we've received, and our answers. Convinced your favorite functional programming language provides unbeatable productivity? Does it enable painless exploitation of parallel processors? Perhaps it's just the case that functional programming languages attract better programmers than other languages... and you and your friends are the best of the best. If so, we've provided you the opportunity to prove it! The ICFP steering committee has designed a programming contest to be conducted in conjunction with ICFP'98. All programmers are invited to enter the contest; we especially encourage students to enter teams. We've designed the programming contest for direct, head-to-head comparison of language technology and programming skill. We have a range of prizes for the winners: cash awards, free conference registrations to ICFP'98 in Baltimore, famous texts on functional languages donated and autographed by the authors, and, of course, unlimited bragging rights. The details of the contest follow. We request interested applicants to register before the contest starts on Thursday, August 27, 1998. Team composition Players may enter alone or as a team. Teams may be of any size -- but we'll offer the friendly advice that the organisational overhead of having more than three or four members on a team will tend to be self-limiting. Anyone is eligible to enter, save members of the ICFP steering committee. We especially encourage students to enter the contest. (And we even have special prizes reserved for possible student winners; see below.) Contest Overview On Thursday, August 27, 1998, a challenge task will be posted on the Internet. Teams will have 72 hours to implement a program to perform this task and submit this program to the contest judges. The judges will perform a competition among the submitted programs on a four-processor 150MHz Pentium-Pro box with 128 mbytes of memory running Linux SMP. Although the precise task chosen will not be revealed until the contest begins, performance matters. Algorithm cleverness matters. We have specifically chosen a parallel machine for the contest so that programs may exploit parallelism. Programming languages that help programmers to rapidly construct complex systems may allow contestants to attempt particularly sophisticated implementations in the 72 hours allotted for programming. This programming contest is being conducted by ICFP, which implies a context of functional programming. However, rather than debate the definition of a "functional programming language," we will allow submitted programs to be written in any language whatsoever, as long as it has an implementation for Linux x86. Prizes The ICFP steering committee has generously authorised a range of prizes to reward and recognise the contest winners: money, wisdom, peer recognition, and varying degrees of satisfaction. First Prize The team winning first prize in the competition will be awarded Money: $1000 in cash. Wisdom: Each member of the team will receive autographed copies of well-known texts in functional programming languages. (See below.) Peer recognition: The team's student members will receive free registration to ICFP'98 in September (up to a limit of three registrations). Deep satisfaction: Finally, the contest judges agree to state at least once during the presentation of the awards that the winning team's programming language is "the superior programming tool of choice for discriminating hackers." Second Prize The team winning second prize in the competition will be awarded Wisdom: Each member of the team will receive autographed copies of well-known texts in functional programming languages. (See below.) Peer recognition: The team's student members will receive free registration to ICFP'98 in September (up to a limit of three registrations). Mild satisfaction: The contest judges agree to state at least once during the presentation of the awards that the winning team's programming language is "a fine programming tool for many applications." Judge's Prize Finally, the Judges' Prize is to be awarded, not on the basis of the competition, but solely at the whim and discretion of the judges. Novel algorithms, interesting languages, beautiful code, arresting user interfaces, use of parallelism -- these things may well count for something in the judges' eyes. The team winning the Judges' Prize will be awarded Wisdom: Each member of the team will receive autographed copies of well-known texts in functional programming languages. (See below.) Peer recognition: The team's student members will receive free registration to ICFP'98 in September (up to a limit of three registrations). Artistic satisfaction: The contest judges agree to state at least once during the presentation of the awards that the winning team is comprised of a group of "extremely cool hackers." Prize books We are currently collecting books on functional programming donated by their authors as prizes for the contest. All books will be autographed by the authors. Matthias Felleisen and Dan Friedman have generously donated copies of The Little Schemer and The Little MLer, and Gerald Sussman, Julie Sussman, and Hal Abelson have also agreed to donate copies of The Structure and Interpretation of Computer Programs. The authors of the Standard ML reference (Harper, MacQueen, Milner, and Tofte) have agreed to donate copies of the reference. Other texts are being solicited; we will post them here when we have commitments from the authors. Details The contest begins 17:00 EST, Thursday, August 27, 1998, when the task description will be linked to this web page, e-mailed to all registered contestants, and posted to a set of relevant newsgroups. Contestants may submit implementations using a submission form. No submissions will be accepted after 17:00 EST, Sunday, August 30, 1998. You may, however, submit multiple times; the judges will use the last submission received before the contest deadline. While we are still developing the submission process, it will probably work roughly as follows. Contestants will submit the program as a gzip'd tar file. This tar file should contain (1) an executable driver program runme, (2) a text file Readme containing general remarks, and (3) a directory src/ containing source code. The tar file may also contain an optional support/ directory containing support libraries, binaries, and other data required by the application at run time. The driver program will be invoked with the support/ directory's parent as its working directory; it may access the files it contains as "support/..." Note that if the chosen language implementation does not permit building a standalone binary executable, it is permissible for the runme driver program to be a shell script that starts up the program using binaries contained in the support/ directory. The Readme file may contain general remarks, such as a description of how the program works, or the programming language(s) used for implementation; it must be signed with the team members' names and email addresses. Registration We have a form that you may use to register for the contest. It is not strictly necessary to register in advance. However, it helps the contest organizers plan the event, and by registering the email addresses of your team members, you ensure that we can email the task description directly to your team with zero delay when the contest starts. Good luck & have fun! Olin Shivers / shivers@ai.mit.edu Marc Feeley / feeley@IRO.UMontreal.CA From owner-scwm-discuss@mit.edu Tue Jul 21 06:52:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA20123 for scwm-discuss-outgoing; Tue, 21 Jul 1998 06:52:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA20120 for ; Tue, 21 Jul 1998 06:52:34 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16201; Tue, 21 Jul 98 06:51:35 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA23013; Tue, 21 Jul 1998 13:51:23 +0300 To: scwm-discuss@mit.edu Subject: (list-windows) always nil during init. How to simulate InitFunction? Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 21 Jul 1998 13:51:16 +0300 In-Reply-To: hjstein@bfr.co.il's message of "09 Jul 1998 20:27:22 +0300" Message-Id: Lines: 57 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm trying to do (list-windows) within my .scwmrc file, but no matter what windows currently exist, it always returns nil. It's ok once scwm has finished startup, BTW. Is (list-windows) not the way to get a list of existing windows during startup? If so, what's the appropriate way to get a list of existing windows from within the .scwmrc file? I need it because I wanted to do something similar to fvwm's InitFunction. In fvwm I run goodstuff from within InitFunction, and goodstuff runs xclock & xbiff. When I restart fvwm, it doesn't start up a second xclock & xbiff. What I want is that an xclock & xbiff come up in the right places when scwm is started, and they aren't re-run every time I do (restart "scwm"). I realize I could put them into my .xinitrc, but that'd screw up my fvwm setup. So, what I did at the end of my .scwmrc is put: (define (find-window-by-name window-name) (let ((wlist (list-windows #:only (lambda (w) (string=? (window-title w) window-name))))) (if (not (null? wlist)) (car wlist) #f))) (define (window-bottom window-name) (let ((window (find-window-by-name window-name))) (if (window? window) (map + (window-position window) (window-size window)) `(129 63)))) (if (not (window? (find-window-by-name "xclock"))) (execute (string-append "xclock -bg Grey20 -fg Orchid -hd Orchid -hl Orchid -geometry 60x60+0+" (number->string (cadr (window-bottom "Fvwm Pager")))))) (if (not (window? (find-window-by-name "xbiff"))) (execute (string-append "xbiff -bg Grey20 -fg Orchid -geometry +0+" (number->string (cadr (window-bottom "xclock")))))) The idea is to check the window list for existing xclocks & xbiffs, and only start up new ones if none exist. Also, the xclock should be placed so that the top is aligned with the bottom of the fvwm2 pager, and the xbiff's top should align with the xclock's bottom. Of course, both of these actions (checking for existence and placing relative to other windows) break because (list-windows) always returns nil during startup. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 21 11:38:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21203 for scwm-discuss-outgoing; Tue, 21 Jul 1998 11:38:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA21197 for ; Tue, 21 Jul 1998 11:37:59 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09685; Tue, 21 Jul 98 11:37:23 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA15967; Tue, 21 Jul 1998 08:36:58 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: From: Greg Badros Date: 21 Jul 1998 08:36:58 -0700 In-Reply-To: hjstein@bfr.co.il's message of "21 Jul 1998 13:51:16 +0300" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I'm trying to do (list-windows) within my .scwmrc file, but no matter > what windows currently exist, it always returns nil. It's ok once > scwm has finished startup, BTW. Is (list-windows) not the way to get > a list of existing windows during startup? If so, what's the > appropriate way to get a list of existing windows from within the > .scwmrc file? We can try to make the list-windows primitive work earlier on. I'm not sure how tricky that'd be. We definitely need to better define what sorts of things are not going to be functional during startup, if any (ideally we could make everything have reasonable behaviour). The other way to check is look for the process owned by you with the given name. I do something like: (system (string-append "ps auxww | grep -q \"^gjb .*xemacs -f gnus\" || " HOME "/.xclients &")) which uses the existence of the xemacs -f gnus process to indicate that the standard set of X clients started by the ~/.xclients script is already running (it doesn't do finer-grained checking of individual windows). We'll try to get list-windows working earlier at some point. Incidentally, the placing of windows relative to each other is something that the constraints framework is most excellent at. Stay tuned for directions on how to try out my embedded Cassowary constraint solver. Greg From owner-scwm-discuss@mit.edu Tue Jul 21 11:58:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21329 for scwm-discuss-outgoing; Tue, 21 Jul 1998 11:58:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA21326 for ; Tue, 21 Jul 1998 11:58:24 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15680; Tue, 21 Jul 98 11:57:47 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA25221; Tue, 21 Jul 1998 18:57:22 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 21 Jul 1998 18:57:22 +0300 In-Reply-To: Greg Badros's message of "21 Jul 1998 08:36:58 -0700" Message-Id: Lines: 40 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > The other way to check is look for the process owned by you with the > given name. I do something like: > > (system > (string-append "ps auxww | grep -q \"^gjb .*xemacs -f gnus\" || " > HOME "/.xclients &")) > > which uses the existence of the xemacs -f gnus process to indicate that > the standard set of X clients started by the ~/.xclients script is > already running (it doesn't do finer-grained checking of individual > windows). Well, things such as running ps to see if the process is around works for seeing whether or not to spawn another one, but not for positioning the existing one. Which leads me to another problem - I can't necessarily position the xbiff after spawning xclock (when xbiff positions based on xclock) because xclock may not yet have mapped its window. How can I wait for a window to come up? Can I do it with a timeout (so as to avoid hanging the window manager)? > We'll try to get list-windows working earlier at some point. > > Incidentally, the placing of windows relative to each other is something > that the constraints framework is most excellent at. Stay tuned for > directions on how to try out my embedded Cassowary constraint solver. Yes, this'd solve the problem. What if I want to position some windows using constraints initially, but then want to drop the constraints? Can I do that with an #:other-proc? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 21 12:04:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21413 for scwm-discuss-outgoing; Tue, 21 Jul 1998 12:04:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA21410 for ; Tue, 21 Jul 1998 12:04:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18349; Tue, 21 Jul 98 12:03:49 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA16029; Tue, 21 Jul 1998 09:03:44 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: From: Greg Badros Date: 21 Jul 1998 09:03:43 -0700 In-Reply-To: hjstein@bfr.co.il's message of "21 Jul 1998 18:57:22 +0300" Message-Id: Lines: 36 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Which leads me to another problem - I can't necessarily position the > xbiff after spawning xclock (when xbiff positions based on xclock) > because xclock may not yet have mapped its window. How can I wait for > a window to come up? Can I do it with a timeout (so as to avoid > hanging the window manager)? We probably need a hook that gets called after a mapping. I'm not sure when #:other-proc gets called, but something similar should work. These kinds of issues need to be thought through carefully to figure out if they belong in some general event framework or a callback framework. One distinction we talked about making was between user-generated events, and window-manager initiated actions (e.g., a keypress vs. a window mapping). If there's any simple answer for scwm, it is: "yes, you'll be able to do that" if you can't already. Generalizing behaviour and letting users creativity drive useful features is definitely high on our list! > > Incidentally, the placing of windows relative to each other is something > > that the constraints framework is most excellent at. Stay tuned for > > directions on how to try out my embedded Cassowary constraint solver. > > Yes, this'd solve the problem. > > What if I want to position some windows using constraints initially, > but then want to drop the constraints? Can I do that with an > #:other-proc? There will probably be easier ways to manage using one-shot constraints. These are some of the design and user-interface issues that my work intends to answer (and I'm willing to take all the help I can get!) Greg From owner-scwm-discuss@mit.edu Tue Jul 21 12:31:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22702 for scwm-discuss-outgoing; Tue, 21 Jul 1998 12:31:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22699 for ; Tue, 21 Jul 1998 12:31:53 -0400 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA25343; Tue, 21 Jul 98 12:31:11 EDT Received: from mizar (root@ppp12-nas0.vi.nettuno.it [193.207.146.221]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id SAA16405 for ; Tue, 21 Jul 1998 18:30:35 +0200 (MDT) Received: by mizar id m0yybsn-0008SRC (Debian Smail-3.2 1996-Jul-4 #2); Tue, 21 Jul 1998 14:50:45 +0159 (CEST) Message-Id: <19980721145104.58837@mizar> Date: Tue, 21 Jul 1998 14:51:04 +0200 From: Francesco Tapparo To: scwm-discuss@mit.edu Subject: strange scwm problem Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm experiencing some strange behaviour from scwm (scwm-0.7a): if I put the file below as .scwmrc, I obtain a SIGSEGV, but if I comment the (app scwm winlist) at the beginning, all goes right. I've a prova.xpm pixmap in the home directory, and I'm using the guile 1998-06-26 snapshot. Is this a bug in scwm or a bug in me? :-> =============BEGIN OF FILE====================================== ;;-------------------------------;; ;; import the scwm modules ;; (use-modules (app scwm base) ; (app scwm winops) (app scwm winlist) ; (app scwm wininfo) (app scwm style) (app scwm face)) ;(define (vertical-toggle-maximize) ; (toggle-maximize 0 (%y 100))) ;(define quit-verify ; (menu ; (list ; (menuitem "Really quit scwm?" #f) ; menu-title ; (menuitem "Yes" #:action quit) ; (menuitem "No" #:action #f) ; menu-separator ; (menuitem "Restart scwm" #:action (lambda () (restart "scwm")))))) (define util-menu (menu (list (menuitem "xterm" #:action (lambda () (execute "xterm")) #:image-left "/home/cesco/prova.xpm") ; (menuitem "Exit scwm" #:action quit-verify)))) ))) (define (popup-util) (popup-menu util-menu)) (bind-mouse 'root 1 popup-util) ====================END OF FILE============================================= From owner-scwm-discuss@mit.edu Tue Jul 21 12:43:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22899 for scwm-discuss-outgoing; Tue, 21 Jul 1998 12:43:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22896 for ; Tue, 21 Jul 1998 12:43:10 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28440; Tue, 21 Jul 98 12:42:33 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA16064; Tue, 21 Jul 1998 09:40:43 -0700 (PDT) To: f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: strange scwm problem References: <19980721145104.58837@mizar> From: Greg Badros Date: 21 Jul 1998 09:40:42 -0700 In-Reply-To: Francesco Tapparo's message of "Tue, 21 Jul 1998 14:51:04 +0200" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francesco Tapparo writes: > I'm experiencing some strange behaviour from scwm (scwm-0.7a): > if I put the file below as .scwmrc, I obtain a SIGSEGV, but if I comment > the (app scwm winlist) at the beginning, all goes right. > I've a prova.xpm pixmap in the home directory, and I'm using the guile > 1998-06-26 snapshot. Do you have a backtrace of the crash available? Thanks, Greg From owner-scwm-discuss@mit.edu Tue Jul 21 13:50:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23649 for scwm-discuss-outgoing; Tue, 21 Jul 1998 13:50:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23646 for ; Tue, 21 Jul 1998 13:50:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16054; Tue, 21 Jul 98 13:49:08 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA26027; Tue, 21 Jul 1998 20:49:04 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: contraint based placment From: hjstein@bfr.co.il (Harvey J. Stein) Date: 21 Jul 1998 20:49:04 +0300 In-Reply-To: Greg Badros's message of "21 Jul 1998 09:03:43 -0700" Message-Id: Lines: 12 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I was wondering - is the constraint based placer basically 2d or 2.5d? In other words, will it be easy, for example, to set up a group of windows to raise & lower together, so they appear as if they're one window? I'm calling this 2.5d because I'm thinking of the desktop as a 2 dimensional plane & the window stacking as window placement in a 3rd dimension (a discrete one). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 21 13:58:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23714 for scwm-discuss-outgoing; Tue, 21 Jul 1998 13:58:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23711 for ; Tue, 21 Jul 1998 13:58:01 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18087; Tue, 21 Jul 98 13:56:59 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA16153; Tue, 21 Jul 1998 10:56:59 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: contraint based placment References: From: Greg Badros Date: 21 Jul 1998 10:56:59 -0700 In-Reply-To: hjstein@bfr.co.il's message of "21 Jul 1998 20:49:04 +0300" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I was wondering - is the constraint based placer basically 2d or > 2.5d? In other words, will it be easy, for example, to set up a group > of windows to raise & lower together, so they appear as if they're one > window? I'm calling this 2.5d because I'm thinking of the desktop as > a 2 dimensional plane & the window stacking as window placement in a > 3rd dimension (a discrete one). Initially, the only variables I'm exposing to the solver are the window position and size (x,y,width,height). The effect you want will probably be possible in the reasonably near future, but not directly within the solver yet. I hope to replace more ad-hoc solutions with cleaner solution within the constraint framework in time, after some hard thinking, and after the need shows itself. Your comments and questions are excellent, and very much the kind of feedback and requests I'm looking forward. Keep 'em coming! Thanks, Greg From owner-scwm-discuss@mit.edu Tue Jul 21 14:05:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24122 for scwm-discuss-outgoing; Tue, 21 Jul 1998 14:05:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA24118 for ; Tue, 21 Jul 1998 14:05:41 -0400 Received: by tis.bellhow.com; id OAA05897; Tue, 21 Jul 1998 14:04:41 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005850; Tue, 21 Jul 98 14:04:10 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA13208 for ; Tue, 21 Jul 1998 14:04:10 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Wierd decorations Date: Tue, 21 Jul 1998 18:00:33 GMT Organization: Bell & Howell PSC Message-ID: <35b7d631.429129014@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA24120 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi All, I have noticed lately (7/20, 7/21) that the window frame corners are looking weird. I don't exactly know how to describe it. How's this: The inner shading of the corners is not be drawn or is being drawn in the wrong place and being overwritten by buttons 1 and 2. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 21 14:56:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24556 for scwm-discuss-outgoing; Tue, 21 Jul 1998 14:56:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24553 for ; Tue, 21 Jul 1998 14:56:51 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07335; Tue, 21 Jul 98 14:55:49 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA16326; Tue, 21 Jul 1998 11:55:52 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Wierd decorations References: <35b7d631.429129014@mailhost> From: Greg Badros Date: 21 Jul 1998 11:55:51 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 21 Jul 1998 18:00:33 GMT" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Hi All, > > I have noticed lately (7/20, 7/21) that the window frame corners are > looking weird. I don't exactly know how to describe it. How's this: > The inner shading of the corners is not be drawn or is being drawn in > the wrong place and being overwritten by buttons 1 and 2. Thanks for the bug report... lots of stuff is changing (I've not done anything directly related to this.... Maciej?) so these kinds of bugs are likely, and it's great to hear about them as soon as you notice something different (as you're doing). Thanks! Greg From owner-scwm-discuss@mit.edu Tue Jul 21 16:08:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26723 for scwm-discuss-outgoing; Tue, 21 Jul 1998 16:08:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26701; Tue, 21 Jul 1998 16:08:31 -0400 Message-Id: <199807212008.QAA26701@huis-clos.mit.edu> To: dale.smith@bellhow.com (Dale Smith) cc: scwm-discuss@mit.edu Subject: Re: Wierd decorations In-reply-to: Your message of "Tue, 21 Jul 1998 18:00:33 GMT." <35b7d631.429129014@mailhost> Date: Tue, 21 Jul 1998 16:08:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com writes: > Hi All, > > I have noticed lately (7/20, 7/21) that the window frame corners are > looking weird. I don't exactly know how to describe it. How's this: > The inner shading of the corners is not be drawn or is being drawn in > the wrong place and being overwritten by buttons 1 and 2. > I've noticed this as well. It was probably either me or Greg who broke it, since we made a lot of big changes lately. Thing is, I don't think I've changed anything that could break this way, and Greg (looking at a later message) doesn't think he did anything that could do this eaither. I imagine one or the other of us will take a look soon. Thanks for the bug report. Greg: trivially reproducable by running with -f sample.scmwrc/system.scwmrc and looking at the corners. From owner-scwm-discuss@mit.edu Tue Jul 21 16:47:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA27220 for scwm-discuss-outgoing; Tue, 21 Jul 1998 16:47:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA27217 for ; Tue, 21 Jul 1998 16:47:21 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA10477; Tue, 21 Jul 98 16:46:15 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA26821; Tue, 21 Jul 1998 23:46:16 +0300 To: Maciej Stachowiak Cc: dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: Wierd decorations References: <199807212008.QAA26701@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 21 Jul 1998 23:46:16 +0300 In-Reply-To: Maciej Stachowiak's message of "Tue, 21 Jul 1998 16:08:30 EDT" Message-Id: Lines: 476 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > dale.smith@bellhow.com writes: > > Hi All, > > > > I have noticed lately (7/20, 7/21) that the window frame corners are > > looking weird. I don't exactly know how to describe it. How's this: > > The inner shading of the corners is not be drawn or is being drawn in > > the wrong place and being overwritten by buttons 1 and 2. > > > > I've noticed this as well. It was probably either me or Greg who broke > it, since we made a lot of big changes lately. Thing is, I don't think > I've changed anything that could break this way, and Greg (looking at > a later message) doesn't think he did anything that could do this > eaither. I imagine one or the other of us will take a look soon. I've noticed weird window decorations since I started using scwm. I can easily reproduce it, too. All I have to do is re-eval the (window-style "*" ...) form in my .scwmrc & the pager, xbiff & xclock suddenly get weird borders. The middle shading color takes over large sections of the borders, sections unaffected by hilighting (when the windows gain focus). Here's my .scwmrc, if anyone wants to experiment. Just use this .scwmrc, then start scwmrc, & then eval the (window-style "*" ...) form. ;;-------------------------------;; ;; import the scwm modules ;; (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm style) (app scwm face) ;; (app scwm fvwm-compat) (app scwm fvwm-module)) ;;-------------------------------;; ;; set some basic styles info ;; (set-opaque-move-size! 100) (set-desk-size! 2 3) ;;; Use alternative auto-placement fcn. (set-smart-placement-is-really-smart! #t) ;;; (set-edge-resistance! time distance) ;;; Wait TIME seconds when mouse is at the edge of the viewport before ;;; scrolling. ;;; The mouse must move DISTANCE pixels when dragging a window past ;;; the edge of the viewport before the window actually moves. (set-edge-resistance! 250 0) ;;; How much (in pixels) to scroll viewport in x & y dir when ;;; encountering the edge. (set-edge-scroll! (%x 100) (%y 100)) ;;; Whether or not to wrap around when scrolling the view #t/#f for X dir ;;; & #t/#f for Y dir. (set-edge-wrap! #f #f) ;;; # of ms to wait for a 2nd click before deciding a click is a click ;;; and not a double click. (set-click-time! 150) (define font12 (make-font "-adobe-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*")) (define font14 (make-font "-adobe-helvetica-bold-r-*-*-14-*-*-*-*-*-*-*")) (define lucida (make-font "-*-lucidatypewriter-bold-r-*-sans-12-*-*-*-*-*-*-*")) (define lucida2 (make-font "lucidasanstypewriter-12")) (define helvetica (make-font "-adobe-helvetica-*-r-*-*-12-*-*-*-*-*-*-*")) (menu-style #:fg "Wheat" #:bg "DimGrey" #:stipple "SlateGrey" #:font font14 #:mwm #f) (title-style #:font font12 #:justify 'left) (set-icon-font! font12) (set-hilight-foreground! "Wheat") (set-hilight-background! "rgbi:.02/.04/.7") (set-rubber-band-mask! 127) (define HOME (getenv "HOME")) (define USER (getenv "USER")) (define user-image-load-path (list (string-append HOME "/pixmaps") (string-append HOME "/bitmaps"))) ;;-------------------------------;; ;; set some paths ;; ;; ;; these are OK for my system, but may need to be changed for ;; yours. This should probably be eventually autoconfed or something. ;;; set path to use for image searches (set! image-load-path (append user-image-load-path '("/usr/X11/lib/X11/mini-icons" "/usr/X11/include/X11/pixmaps" "/usr/lib/icons" "/usr/local/X11/include/X11/pixmaps" "/usr/local/lib/icons" "/usr/local/icons") image-load-path)) ;;-------------------------------;; ;; set some window styles ;; (window-style "*" #:fg "Wheat" #:bg "DimGrey" #:icon "unknown1.xpm" #:icon-box (list (x- 70) 1 69 (y- 141)) #:border-width 5 #:handle-width 5 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:int-override #t #:decorate-transient #t #:PPosition-hint #f #:lenience #t) (define desk-widget (make-style #:plain-border #t #:sticky #t #:winlist-skip #t #:border-width 1 #:focus 'none)) (define (stack-windows . w) (let* ((size (apply window-size w)) (desired-lr (map inexact->exact (map * '(.6 .6) (display-size)))) (needed-tl (map - desired-lr size))) (apply move-to (append needed-tl w)))) (window-style "*lock" #:use-style desk-widget) (window-style "xload" #:no-titlebar #t #:use-style desk-widget) (window-style "xscreensaver" #:no-titlebar #t #:use-style desk-widget) (window-style "xbiff" #:no-titlebar #t #:use-style desk-widget) (window-style "*xclock" #:no-titlebar #t #:use-style desk-widget) (window-style "xcalc" #:icon "xcalc.xpm") (window-style "xman" #:icon "xman.xpm") (window-style "xmag" #:icon "mag_glass.xpm") (window-style "Emacs" #:icon "gnu-animal.xpm") (window-style "XTerm" #:icon "xterm.xpm") (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) (window-style "Netscape: Error" #:sticky #t #:other-proc stack-windows) (window-style "Netscape: Find" #:other-proc stack-windows) ;;-------------------------------;; ;; define some useful menus ;; (define (vertical-toggle-maximize) (toggle-maximize 0 (%y 100))) (define (horizontal-toggle-maximize) (toggle-maximize (%x 100) 0)) (define (full-toggle-maximize) (toggle-maximize (%x 100) (%y 100))) (define window-ops-menu (menu (list (menuitem "Window Ops" #f) menu-title (menuitem "Move" #:action interactive-move) (menuitem "Resize" #:action interactive-resize) (menuitem "Raise" #:action raise-window) (menuitem "Lower" #:action lower-window) (menuitem "Print" #:action print-window) (menuitem "(Un)Window-Shade" #:action toggle-window-shade) (menuitem "(De)Iconify" #:action toggle-iconify) (menuitem "(Un)Maximize" #:action vertical-toggle-maximize) (menuitem "(Un)Stick" #:action toggle-stick) (menuitem "(Un)Keep On Top" #:action toggle-on-top) menu-separator (menuitem "Close" #:action close-window) (menuitem "Delete" #:action delete-window) (menuitem "Destroy" #:action destroy-window) menu-separator (menuitem "Refresh Screen" #:action refresh)))) (define (popup-ops) (popup-menu window-ops-menu)) (define quit-verify (menu (list (menuitem "Really quit scwm?" #f) menu-title (menuitem "Yes" #:action quit) (menuitem "No" #:action #f) menu-separator (menuitem "Restart scwm" #:action (lambda () (restart "scwm"))) (menuitem "Restart fvwm" #:action (lambda () (restart "fvwm")))))) (define desk-menu (menu (list (menuitem "Desk 1" #:action (lambda () (set-current-desk! 0))) (menuitem "Desk 2" #:action (lambda () (set-current-desk! 1))) (menuitem "Desk 3" #:action (lambda () (set-current-desk! 2))) (menuitem "Desk 4" #:action (lambda () (set-current-desk! 3)))))) (define (moronconnect n) (string-append "startnet-bigpackets -moronchap" (number->string n) " auth +chap name hjstein remotename Morannon mtu 296 mru 296")) (define (menuexelist . l) (map (lambda (item) (menuitem item #:action (exe item))) l)) (define netapps-menu (menu (menuexelist "zircon" "xarchie" "xgopher"))) (define startnet-menu (menu (list (menuitem "moronchap2" #:action (exe (moronconnect 2))) (menuitem "moronchap3" #:action (exe (moronconnect 3))) (menuitem "moronchap4" #:action (exe (moronconnect 4))) (menuitem "blinkyquiet" #:action (exe "startnet-bigpackets -blinkyquiet mtu 296 mru 296 10.0.2.15:128.253.154.32")) (menuitem "netvision" #:action (exe "startnet-bigpackets -fastnquiet")) menu-separator (menuitem "killnet" #:action (exe "killnet"))))) (define rlogin-menu (menu (append (map (lambda (name dest) (menuitem name #:action (exe (string-append "startxterm " dest ".bfr.co.il")))) '("Blinky+x" "Blinky" "Casper" "Vermis" "Cruella" "Blaster+x" "Blaster") '("blinky" "-x blinky" "-x casper" "-x vermis" "-x cruella" "blaster" "-x blaster")) (list menu-separator) (map (lambda (name) (menuitem name #:action (exe (string-append "startxterm blinky.bfr.co.il " name ".bloomberg.com")))) '("Randy" "Morty" "Shalom" "aldev3" "aldev4" "aldev5")) (list (menuitem "iladm" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24")) menu-separator (menuitem "dg1" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 dg1")) (menuitem "dg1a" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 dg1a")) (menuitem "park1" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 park1")) (menuitem "park2" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 park2")) (menuitem "park3" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 park3")) (menuitem "dgintel1" #:action (exe "startxterm blinky.bfr.co.il 160.43.144.24 dgintel1")) (menuitem "Purdy" #:action (exe "startxterm -T 'purdy' -e telnet purdy.bloomberg.com")))))) (define xblp-menu (menu (append (map (lambda (name) (menuitem (string-append "xblp " name) #:action (exe (string-append "start-xblp " name)))) (map symbol->string '(vermis cruella casper fritz udun homer))) (list "Restart xblp" #:action (exe "xblp"))))) (define util-menu (menu `(,(menuitem "Utilities" #f) ,menu-title ,@(menuexelist "xterm" "emacs") ,(menuitem "netscape" #:action (exe "netscape -install")) ,menu-separator ,(menuitem "Net start/kill" #:action 'startnet-menu) ,(menuitem "Net apps" #:action 'netapps-menu) ,(menuitem "Rlogin" #:action 'rlogin-menu) ,(menuitem "xblp" #:action 'xblp-menu) ,(menuitem "top" #:action (run-in-xterm "-T Top -n Top -e top")) ,(menuitem "xcalc" #:action (lambda () (execute "xcalc"))) ,(menuitem "xmag" #:action (lambda () (execute "xmag"))) ,menu-separator ,(menuitem "Desks" #:action 'desk-menu) ,menu-separator ,(menuitem "Exit scwm" #:action quit-verify)))) (define (popup-util) (popup-menu util-menu)) (define (make-small-window-ops-menu w) (menu (list ;; (menuitem "Window Ops2" #f) ;; menu-title (menuitem "Move" #:action interactive-move) (menuitem "Resize" #:action interactive-resize) (menuitem "Raise" #:action raise-window) (menuitem "Lower" #:action lower-window) (menuitem "Iconify" #:action iconify) menu-separator (menuitem "More..." #:action (menu (list (menuitem (if (maximized? w) "Unmaximize" "Maximize") #:action vertical-toggle-maximize) (menuitem (if (sticky? w) "Unstick" "Stick") #:action toggle-stick) (menuitem (if (window-shaded? w) "UnWindow-Shade" "Window-Shade") #:action toggle-window-shade) (menuitem (if (kept-on-top? w) "UnKeep On Top" "Keep On Top") #:action toggle-on-top)))) menu-separator (menuitem "Close" #:action close-window) (menuitem "Destroy" #:action destroy-window)))) (define (popup-small-ops) (popup-menu (make-small-window-ops-menu (get-window)))) ;; now set some mouse and key bindings ;; (define (move-or-lower) (case (mouse-event-type) ((motion) (interactive-move)) (else (lower-window)))) (define (my-move-or-raise) (case (mouse-event-type) ((motion) (interactive-move)) (else (raise-window)))) ;; first our root menus (bind-mouse 'root 1 popup-util) (bind-mouse 'root 2 popup-ops) (bind-mouse 'root 3 (lambda () (show-window-list-menu #:show-geometry #t))) (bind-mouse 'root "M-3" (lambda () (popup-menu desk-menu))) ;; window buttons (bind-mouse 'button-1 1 popup-small-ops) (bind-mouse 'button-2 1 vertical-toggle-maximize) (bind-mouse 'button-2 2 horizontal-toggle-maximize) (bind-mouse 'button-2 3 full-toggle-maximize) (bind-mouse 'button-4 1 iconify) ;; operations on parts of the window (bind-mouse '(frame sidebar) 2 popup-small-ops) (bind-mouse 'frame 1 resize-or-raise) (bind-mouse 'sidebar 1 resize-or-raise) (set-animation! '#(0 .01 .03 .08 .18 .3 .45 .60 .75 .85 .90 .94 .97 .99 1)) (define (move-or-shade) (case (mouse-event-type) ((double-click) (toggle-window-shade-animated)) ((motion) (move-or-raise)) (else (if (window-shaded?) (toggle-window-shade-animated) (move-or-raise))))) (bind-mouse 'title 1 move-or-shade) (bind-mouse 'title 3 lower-window) ;; key bindings for the menus (bind-key 'all "M-F1" popup-util) (bind-key 'all "M-F2" popup-ops) ;; in case of emergency, hit Control-Meta-Q ;;;(bind-key 'all "C-M-q" quit) ;; Restart (bind-key 'all "C-M-S-r" (lambda () (restart "scwm"))) ;; some stuff for icons (define (move-or-deiconify) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (deiconify)))) (bind-mouse 'icon 1 move-or-deiconify) (bind-mouse 'icon 2 deiconify) (bind-mouse '(window title icon frame sidebar) "M-1" move-or-lower) (bind-mouse '(window title icon frame sidebar) "M-3" move-or-raise) ;; move the pointer with the keyboard (bind-key 'all "M-Left" (lambda () (move-pointer (%x -1) 0))) (bind-key 'all "M-Right" (lambda () (move-pointer (%x 1) 0))) (bind-key 'all "M-Up" (lambda () (move-pointer 0 (%y -1)))) (bind-key 'all "M-Down" (lambda () (move-pointer 0 (%y 1)))) ;; move the viewport with the keyboard (bind-key 'all "C-M-Left" (lambda () (move-viewport (%x -100) 0))) (bind-key 'all "C-M-Right" (lambda () (move-viewport (%x 100) 0))) (bind-key 'all "C-M-Up" (lambda () (move-viewport 0 (%y -100)))) (bind-key 'all "C-M-Down" (lambda () (move-viewport 0 (%y 100)))) ;; rotate the current window with the keyboard ;;(bind-key 'all "M-Tab" ;; (lambda () ;; (next-window #:only visible? #:except iconified?))) ;;;(unbind-key 'all "M-Tab") (bind-key 'all "M-S-Tab" (lambda () (prev-window #:only visible? #:except iconified?))) ;;; Pager. (window-style "FvwmPager" #:no-titlebar #t #:use-style desk-widget) (define fvwm-pager-path "/usr/X11R6/lib/X11/fvwm95-2/FvwmPager") (define fvwm-pager (run-fvwm-module ;; path to the module fvwm-pager-path ;; your .fvwm2rc (does not need to exist for most modules) "~/.fvwmrc" ;; list of configuration lines '("*FvwmPagerBack grey20" "*FvwmPagerFore Orchid" "*FvwmPagerHilight Black" "*FvwmPagerDeskTopScale 50" "*FvwmPagerLabel 0 Top" "*FvwmPagerLabel 1 Bottom" "*FvwmPagerGeometry +0+0" "*FvwmPagerSmallFont 5x8") '("0" "1"))) (define (find-window-by-name window-name) (let ((wlist (list-windows #:only (lambda (w) (string=? (window-title w) window-name))))) (if (not (null? wlist)) (car wlist) #f))) (define (window-bottom window-name) (let ((window (find-window-by-name window-name))) (if (window? window) (map + (window-position window) (window-size window)) `(159 80)))) (if (not (window? (find-window-by-name "xclock"))) (execute (string-append "xclock -bg Grey20 -fg Orchid -hd Orchid -hl Orchid -geometry 60x60+0+" (number->string (cadr (window-bottom "Fvwm Pager")))))) (if (not (window? (find-window-by-name "xbiff"))) (execute (string-append "xbiff -bg Grey20 -fg Orchid -geometry +0+" (number->string (cadr (window-bottom "xclock")))))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Jul 21 16:58:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA27344 for scwm-discuss-outgoing; Tue, 21 Jul 1998 16:58:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA27341 for ; Tue, 21 Jul 1998 16:58:13 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20632; Tue, 21 Jul 98 16:57:34 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16540; Tue, 21 Jul 1998 13:56:53 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , dale.smith@bellhow.com (Dale Smith), scwm-discuss@mit.edu Subject: Re: Wierd decorations References: <199807212008.QAA26701@huis-clos.mit.edu> From: Greg Badros Date: 21 Jul 1998 13:56:52 -0700 In-Reply-To: hjstein@bfr.co.il's message of "21 Jul 1998 23:46:16 +0300" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I've noticed weird window decorations since I started using scwm. I > can easily reproduce it, too. All I have to do is re-eval the Yep, me too.... my stable scwm from a couple weeks ago that I use as my wm while developing the new test versions of scwm has some decorations that are improperly drawn... I'll get to this this afternoon, I hope. Greg From owner-scwm-discuss@mit.edu Tue Jul 21 17:12:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27629 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:12:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27625; Tue, 21 Jul 1998 17:12:17 -0400 Message-Id: <199807212112.RAA27625@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? In-reply-to: Your message of "21 Jul 1998 13:51:16 +0300." Date: Tue, 21 Jul 1998 17:12:17 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > I'm trying to do (list-windows) within my .scwmrc file, but no matter > what windows currently exist, it always returns nil. It's ok once > scwm has finished startup, BTW. Is (list-windows) not the way to get > a list of existing windows during startup? If so, what's the > appropriate way to get a list of existing windows from within the > .scwmrc file? > > I need it because I wanted to do something similar to fvwm's > InitFunction. In fvwm I run goodstuff from within InitFunction, and > goodstuff runs xclock & xbiff. When I restart fvwm, it doesn't start > up a second xclock & xbiff. > > What I want is that an xclock & xbiff come up in the right places when > scwm is started, and they aren't re-run every time I do (restart > "scwm"). > The scwmrc file gets parsed before any windows get captured. IMO this is correct because all the styles need to be set up before scwm attempts to capture the windows. So (list-windows) will always return the empty list while reading .scwmrc. However, I can see the need to take particular actions _after_ all the windows have been captured. To that end, I have added `startup-hook' in the CVS sources to which you can add procedures of no arguments to get run after the windows are captured. This will get run on both a fresh start and a restart. I will still look into making `restarted?' know the difference between a restart from scwm and one from fvwm. I can see two possible semantics for this function: * Return true only if we got restarted from scwm just now, and there was no other wm running before, nor did we just have a raw X with no wm running. * Return true if scwm has ever run on this display before. So, for example, if it crashes or you kill it and then you run it again, `restarted?' will still return true. It is my guess that most users prefer behavior #2, but I am willing to listen to user input on this point. (BTW, sorry about not getting anoncvs running yet, I didn't have much time for it yesterday - hopefully this evening I will get to it). - Maciej From owner-scwm-discuss@mit.edu Tue Jul 21 17:19:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27725 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:19:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27716; Tue, 21 Jul 1998 17:19:13 -0400 Message-Id: <199807212119.RAA27716@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? In-reply-to: Your message of "21 Jul 1998 09:03:43 PDT." Date: Tue, 21 Jul 1998 17:19:13 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Which leads me to another problem - I can't necessarily position the > > xbiff after spawning xclock (when xbiff positions based on xclock) > > because xclock may not yet have mapped its window. How can I wait for > > a window to come up? Can I do it with a timeout (so as to avoid > > hanging the window manager)? > > We probably need a hook that gets called after a mapping. I'm not sure > when #:other-proc gets called, but something similar should work. These > kinds of issues need to be thought through carefully to figure out if > they belong in some general event framework or a callback framework. > One distinction we talked about making was between user-generated > events, and window-manager initiated actions (e.g., a keypress vs. a > window mapping). > #:other-proc gets called after the window is placed and entered into the window list, but I am not sure if it is yet mapped. IMO, that doesn't matter, because it's scwm structure will (a) be in the window list and (b) have the position and height filled out at that time. > If there's any simple answer for scwm, it is: "yes, you'll be able to do > that" if you can't already. Generalizing behaviour and letting users > creativity drive useful features is definitely high on our list! > I second this statement. We'd like to never have to say "you can't do that", but for now we sometimes have to say "not yet". - Maciej From owner-scwm-discuss@mit.edu Tue Jul 21 17:25:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27823 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:25:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA27820 for ; Tue, 21 Jul 1998 17:25:48 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28881; Tue, 21 Jul 98 17:25:09 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA16589; Tue, 21 Jul 1998 14:24:49 -0700 (PDT) To: Maciej Stachowiak Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: <199807212112.RAA27625@huis-clos.mit.edu> From: Greg Badros Date: 21 Jul 1998 14:24:48 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 21 Jul 1998 17:12:17 EDT" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I will still look into making `restarted?' know the difference between > a restart from scwm and one from fvwm. > > I can see two possible semantics for this function: > > * Return true only if we got restarted from scwm just now, and there > was no other wm running before, nor did we just have a raw X with no > wm running. > > * Return true if scwm has ever run on this display before. So, for > example, if it crashes or you kill it and then you run it again, > `restarted?' will still return true. I think the "restarted?" primitive is bogus. It's the wrong abstraction. The right question to ask isn't whether scwm has been restarted, but are things about the current state. (e.g., Harvey's question about is there a window with this name, and so forth). I can't envision caring about whether scwm has ben run on the display before or what process exec'd this scwm process or whatever. Even if I did, the functionality of string properties already exists and can do this for those who can't get at the specific information that they are interested in yet. E.g., I can set a GJB_SCWM_STARTED property on the root window of an X screen if I want to, then check for that. We don't need a primitive, IMO, and I think it should disappear -- its existence encourages asking the wrong kinds of questions. Greg From owner-scwm-discuss@mit.edu Tue Jul 21 17:52:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA28444 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:52:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA28437; Tue, 21 Jul 1998 17:52:31 -0400 Message-Id: <199807212152.RAA28437@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? In-reply-to: Your message of "21 Jul 1998 14:24:48 PDT." Date: Tue, 21 Jul 1998 17:52:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I will still look into making `restarted?' know the difference between > > a restart from scwm and one from fvwm. > > > > I can see two possible semantics for this function: > > > > * Return true only if we got restarted from scwm just now, and there > > was no other wm running before, nor did we just have a raw X with no > > wm running. > > > > * Return true if scwm has ever run on this display before. So, for > > example, if it crashes or you kill it and then you run it again, > > `restarted?' will still return true. > > I think the "restarted?" primitive is bogus. It's the wrong > abstraction. The right question to ask isn't whether scwm has been > restarted, but are things about the current state. (e.g., Harvey's > question about is there a window with this name, and so forth). I can't > envision caring about whether scwm has ben run on the display before or > what process exec'd this scwm process or whatever. Even if I did, the > functionality of string properties already exists and can do this for > those who can't get at the specific information that they are interested > in yet. E.g., I can set a GJB_SCWM_STARTED property on the root window > of an X screen if I want to, then check for that. We don't need a > primitive, IMO, and I think it should disappear -- its existence > encourages asking the wrong kinds of questions. > I would tend to agree that `restarted?' is almost never the right question to ask, however, I think we need it for the scwmrc->fvwmrc translator to work right. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 21 17:54:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA28482 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:54:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA28479 for ; Tue, 21 Jul 1998 17:54:08 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA05115; Tue, 21 Jul 98 17:53:29 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id OAA23669 for ; Tue, 21 Jul 1998 14:53:08 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-21476>; Tue, 21 Jul 1998 14:11:07 -0700 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? In-Reply-To: Your message of "21 Jul 1998 18:57:22 +0300." Date: Tue, 21 Jul 1998 14:11:06 -0600 From: Ken Pizzini Message-Id: <19980721211107Z276516-21476+39@pulsar.halcyon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit X-Mime-Autoconverted: from 8bit to quoted-printable by smtp3.nwnexus.com id OAA23669 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA28480 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Which leads me to another problem - I can't necessarily position the > xbiff after spawning xclock (when xbiff positions based on xclock) > because xclock may not yet have mapped its window. How can I wait for > a window to come up? Can I do it with a timeout (so as to avoid > hanging the window manager)? There is an X11R6 contrib program called "xrunclient" which may help: : The xrunclient program is used to launch an X client pro­ : gram from .xinitrc or a similar script. It waits until : the client creates a top level window before exiting [snip] So I think you can get what you're after by installing that utility and adding this analog to the "execute" function: (define-public (run command) (system (string-append "xrunclient " command))) or this analog of the "exe" function: (define-public (runL command) (lambda () (system (string-append "xrunclient " command)))) HTH, --Ken Pizzini From owner-scwm-discuss@mit.edu Tue Jul 21 17:58:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA28614 for scwm-discuss-outgoing; Tue, 21 Jul 1998 17:58:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA28608; Tue, 21 Jul 1998 17:58:27 -0400 Message-Id: <199807212158.RAA28608@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: startup-hook Date: Tue, 21 Jul 1998 17:58:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk OK, scwm wouldn't run for me at all for a bit there, but this should now work, and the window list is definitely accesible there: [root@localhost scwm]# scwm/scwm -e "(add-hook! startup-hook (lambda () (write (list-all-windows)) (newline)))" (# # # # # #) - Maciej From owner-scwm-discuss@mit.edu Tue Jul 21 18:05:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA28862 for scwm-discuss-outgoing; Tue, 21 Jul 1998 18:05:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA28858 for ; Tue, 21 Jul 1998 18:05:07 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07088; Tue, 21 Jul 98 18:04:27 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA16639; Tue, 21 Jul 1998 15:04:07 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: <199807212152.RAA28437@huis-clos.mit.edu> From: Greg Badros Date: 21 Jul 1998 15:04:06 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 21 Jul 1998 17:52:31 EDT" Message-Id: Lines: 9 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I would tend to agree that `restarted?' is almost never the right > question to ask, however, I think we need it for the scwmrc->fvwmrc > translator to work right. As a C primitive? G From owner-scwm-discuss@mit.edu Tue Jul 21 18:07:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA28924 for scwm-discuss-outgoing; Tue, 21 Jul 1998 18:07:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA28921 for ; Tue, 21 Jul 1998 18:07:45 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07686; Tue, 21 Jul 98 18:07:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA16648; Tue, 21 Jul 1998 15:06:39 -0700 (PDT) To: Ken Pizzini Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: <19980721211107Z276516-21476+39@pulsar.halcyon.com> From: Greg Badros Date: 21 Jul 1998 15:06:39 -0700 In-Reply-To: Ken Pizzini's message of "Tue, 21 Jul 1998 14:11:06 -0600" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > There is an X11R6 contrib program called "xrunclient" which may > help: Good idea. There's also one by the name of xtoolwait. Greg From owner-scwm-discuss@mit.edu Tue Jul 21 22:36:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30728 for scwm-discuss-outgoing; Tue, 21 Jul 1998 22:36:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30718; Tue, 21 Jul 1998 22:36:37 -0400 Message-Id: <199807220236.WAA30718@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? In-reply-to: Your message of "21 Jul 1998 15:04:06 PDT." Date: Tue, 21 Jul 1998 22:36:37 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I would tend to agree that `restarted?' is almost never the right > > question to ask, however, I think we need it for the scwmrc->fvwmrc > > translator to work right. > > As a C primitive? > `restarted?' per se does not need to be a C primitive, but the code that sets whatever properties it checks does, so it may as well be. OTOH, I guess there are orthogonal uses for that code (indicating the current desktop) so maybe `restarted?' can be punted sensibly once the xproperty changes I suggested are done. - Maciej From owner-scwm-discuss@mit.edu Tue Jul 21 22:40:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30846 for scwm-discuss-outgoing; Tue, 21 Jul 1998 22:40:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA30843 for ; Tue, 21 Jul 1998 22:40:31 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23573; Tue, 21 Jul 98 22:39:50 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA17889; Tue, 21 Jul 1998 19:39:30 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: (list-windows) always nil during init. How to simulate InitFunction? References: <199807220236.WAA30718@huis-clos.mit.edu> From: Greg Badros Date: 21 Jul 1998 19:39:29 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 21 Jul 1998 22:36:37 EDT" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > `restarted?' per se does not need to be a C primitive, but the code > that sets whatever properties it checks does, so it may as well > be. OTOH, I guess there are orthogonal uses for that code (indicating > the current desktop) so maybe `restarted?' can be punted sensibly once > the xproperty changes I suggested are done. But even what we have now is good enough, isn't it? (Though I'm definitely in favor of the changes you suggested). BTW, IMPORTANT FAVOR: Can you look at the HandleScwmExec() code ASAP -- it's causing me lots of problems and I don't understand an oodle of it. It was causing some problems for me a day or two ago (no response from Emacs or scwmrepl), and I changed a line: last_offset+=last_offset+1 to ++last_offset thinking the former was a bug. It fixed things for me, but now something else seems to be going wrong, and it's holding me up. Can you document what the hell is going on in there? Thanks very much, Greg From owner-scwm-discuss@mit.edu Tue Jul 21 23:25:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA31481 for scwm-discuss-outgoing; Tue, 21 Jul 1998 23:25:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA31477; Tue, 21 Jul 1998 23:25:49 -0400 Message-Id: <199807220325.XAA31477@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: New fvwm2 module interface Date: Tue, 21 Jul 1998 23:25:48 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk If use use tomorrow's snapshot, or the CVS version, you should know: I changed the fvwm2 module interface in a non-backwards-compatible way. I could have done it backwards compatibly if I'd resisted the urge to add 2's into the function names, but it was a good idea to reorder the arguments to run-fvwm2-module anyway now that more of them are optional, so I thought, hey, if I'm breaking things, I should go whole-hog and make sure people look at the docs when things break for them. The new interface is documented thoroguhly in a comment at the top of fvwm-module.scm, and I changed the distributed scwmrc's to use it. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 22 01:15:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA32628 for scwm-discuss-outgoing; Wed, 22 Jul 1998 01:15:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA32625 for ; Wed, 22 Jul 1998 01:15:13 -0400 Received: from pcnet1.pcnet.com by MIT.EDU with SMTP id AA10679; Wed, 22 Jul 98 01:14:32 EDT Received: (from proteus@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id BAA25621; Wed, 22 Jul 1998 01:15:08 -0400 (EDT) Message-Id: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: <199807220236.WAA30718@huis-clos.mit.edu> Date: Wed, 22 Jul 1998 01:01:00 -0400 (EDT) Reply-To: Bob Woodside Organization: Woodsway Consulting From: Bob Woodside To: Maciej Stachowiak Subject: Re: (list-windows) always nil during init. How to simulate InitF Cc: scwm-discuss@mit.edu, Greg Badros Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 22-Jul-98 Maciej Stachowiak wrote: > > gjb@cs.washington.edu writes: >> Maciej Stachowiak writes: >> >> > I would tend to agree that `restarted?' is almost never the right >> > question to ask, however, I think we need it for the scwmrc->fvwmrc >> > translator to work right. >> >> As a C primitive? >> > > `restarted?' per se does not need to be a C primitive, but the code > that sets whatever properties it checks does, so it may as well > be. OTOH, I guess there are orthogonal uses for that code (indicating > the current desktop) so maybe `restarted?' can be punted sensibly once > the xproperty changes I suggested are done. Er, I'm not sure I follow what's wanted, but you've already got the primitives - C and Scheme - that are needed for Fvwm compatibility/conversion. It's just that it's sort of bogus, as it is in Fvwm. As currently implemented, all the Restarting flag means is that *some* window manager that sets the XA_WM_DESKTOP property has had its hands on the root window before we started up - it could have been any number of WM's, and Fvwm/Scwm can't tell the difference. So, for compatibility, what's needed? Well, Fvwm only uses the flag for two things. First, it's used to decide whether to drive the InitFunction or the RestartFunction. Second, it's used during placement of newly captured windows on startup: I'm not sure that piece of logic in Fvwm is really useful, and I see no corollary in Scwm - i.e., that particular bit of convolutia looks to have been eliminated in some of the code cleanup you guys did. So, it seems to me that all you need for compatibility is the ability for someone to execute the equivalent of RestartFunction if Restarted? And it looks as though you have that. Now, to do more, the idea of setting window properties seems a more generally useful way to go. Greg said that asking if Restarted? is usually the wrong question, I think this is true for two reasons. First, there's no consistent meaning of the terms Restart, Quit, or Exit among window managers. Second, what you really care about is the state of existing windows. I'm not really sure tacking some arbitrary property onto the root window is all that useful. Attaching an SCWM_STATE_STUFF property to app windows that you've managed, on the other hand, could be terribly useful. It could, for example, allow you to restore the state a window was in when last Scwm had control of it, even if the user had switched to another WM (or even three others) in between. Let's say, for example, that the user likes for Netscape to appear on Desk 2, Page 2 when Scwm is running the show, but for some strange reason switches to another WM for a while, one that doesn't have virtual desktops, and then switches back to Scwm. You could use the SCWM properties to decide to place the window back where it used to be (*not* necessarily the starting position specified in the .scwmrc, nor the position where the other WM left it). You could use it to remember a window's icon position across a Restart. (And, of course, the presence of an SCWM property or properties on a window would implicitly answer the question of whether Scwm had ever been running.) Another interesting wrinkle - if Fvwm and Scwn agreed to talk to each other, and Fvwm were to use the same technique - would be the possibility of Scwm's picking up any Fvwm properties that it chose to honor, absent the corollary Scwm properties, and vice-versa. (There are certainly precedents for such a thing in attempting to honor MWM and OLWM hints, though those are set by the apps.) From owner-scwm-discuss@mit.edu Wed Jul 22 01:21:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA32711 for scwm-discuss-outgoing; Wed, 22 Jul 1998 01:21:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA32708 for ; Wed, 22 Jul 1998 01:21:27 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29540; Wed, 22 Jul 98 01:20:20 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA18088; Tue, 21 Jul 1998 22:20:24 -0700 (PDT) To: scwm-discuss@mit.edu Subject: We have DOCUMENTATION! From: Greg Badros Date: 21 Jul 1998 22:20:24 -0700 Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Well after Maciej's hard work adding docstrings to almost all of the primitives (I did one file -- he did the rest! Nice split, IMO!), and my hard work in getting a prototype docstring extractor which generates DocBook DTD compliant SGML, we have some documentation pages for all the C primitives defined in SCWM. See: http://www.cs.washington.edu/research/constraints/cassowary/scwm-doc/book01.htm The scwm.sgml is in that directory, and also available from the repository. There is also a text version in doc/primitives.txt (generated using the same extractor, but not docbook). Feedback is welcome, but I *am* aware that there are no links (any DocBook gurus out there that could give me a lesson, please do -- I just started looking at the DocBook reference today). We still need to document scheme-level procedures, but the extraction should be very similar. Greg From owner-scwm-discuss@mit.edu Wed Jul 22 05:52:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA01975 for scwm-discuss-outgoing; Wed, 22 Jul 1998 05:52:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id FAA01972 for ; Wed, 22 Jul 1998 05:52:45 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id LAA12920 for scwm-discuss@huis-clos.mit.edu; Wed, 22 Jul 1998 11:51:41 +0200 (CEST) Received: (qmail 1935 invoked by uid 115); 22 Jul 1998 09:45:10 -0000 To: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 22 Jul 1998 11:45:03 +0200 In-Reply-To: Greg Badros's message of "15 Jul 1998 10:26:48 -0700" Message-ID: Lines: 37 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 15 Jul 1998 10:26:48 -0700 >>>>> Greg Badros said: [this is a bit dated - I'm just catching up] Greg> I also suggest using \< to expand into <, and \& to expand Greg> into & (instead of < and & which I think are a lot less Greg> readable). It is more readable, but adding another escape makes a big mess. What if I want to have a literal "\&" in the docs? Would backslashes have to be escaped always, or just before "<" and "&"? The former brings execcive leaning toothpicks, the latter is kinda ugly. Greg> We could also forbid spaces from following `<' or '&', and if Greg> we see a space, just take that to mean that we want the literal Greg> character This is certainly convenient. Greg> (since those characters will almost always be separated from Greg> adjacent identifiers by spaces when they are used for Greg> themselves instead of markup). Hmm, I usually write "X From owner-scwm-discuss@mit.edu Wed Jul 22 10:04:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA03002 for scwm-discuss-outgoing; Wed, 22 Jul 1998 10:04:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA02999 for ; Wed, 22 Jul 1998 10:04:40 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA27240; Wed, 22 Jul 98 10:03:28 EDT Received: from mcfeely.concentric.net (mcfeely [206.173.118.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id KAA23774; Wed, 22 Jul 1998 10:03:32 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by mcfeely.concentric.net (8.8.8) id KAA28104; Wed, 22 Jul 1998 10:03:30 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id KAA05256; Wed, 22 Jul 1998 10:03:05 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "21 Jul 1998 22:20:24 -0700" Date: 22 Jul 1998 10:03:05 -0400 Message-Id: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 21 Jul 1998 22:20:24 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "We have DOCUMENTATION!": >> Well after Maciej's hard work adding docstrings to almost all of the >> primitives (I did one file -- he did the rest! Nice split, IMO!), and >> my hard work in getting a prototype docstring extractor which generates >> DocBook DTD compliant SGML, we have some documentation pages for all the >> C primitives defined in SCWM. >> >> The scwm.sgml is in that directory, and also available from the >> repository. There is also a text version in doc/primitives.txt >> (generated using the same extractor, but not docbook). >> >> Feedback is welcome, but I *am* aware that there are no links (any >> DocBook gurus out there that could give me a lesson, please do -- I >> just started looking at the DocBook reference today). I'll write a scheme procedure `documentation', taking a function name and returning the appropriate block from primitives.txt. I'll add the appropriate Emacs interface too. In light of this, I would appreciate 1. that the present file format is preserved: descriptions are separated by "^J^J(". BTW, the documentation of `clever-place-window' and some others is formatted funny. 2. the file primitives.txt is installed, say in ${prefix}/info. 3. there seems to be some information in *sgml which did not trickle down to *txt, like where the primitive was defined. I think it should. >> We still need to document scheme-level procedures, but the extraction >> should be very similar. ... and should go to the same file (which should be renamed scwm-procs.txt) Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Sex is like air. It's only a big deal if you can't get any. From owner-scwm-discuss@mit.edu Wed Jul 22 11:24:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA03653 for scwm-discuss-outgoing; Wed, 22 Jul 1998 11:24:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA03650 for ; Wed, 22 Jul 1998 11:24:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20151; Wed, 22 Jul 98 11:23:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA18720; Wed, 22 Jul 1998 08:23:12 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: From: Greg Badros Date: 22 Jul 1998 08:23:12 -0700 In-Reply-To: Sam Steingold's message of "22 Jul 1998 10:03:05 -0400" Message-Id: Lines: 51 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> Feedback is welcome, but I *am* aware that there are no links (any > >> DocBook gurus out there that could give me a lesson, please do -- I > >> just started looking at the DocBook reference today). > > I'll write a scheme procedure `documentation', taking a function name > and returning the appropriate block from primitives.txt. I'll add the > appropriate Emacs interface too. In light of this, I would appreciate > > 1. that the present file format is preserved: descriptions are separated > by "^J^J(". BTW, the documentation of `clever-place-window' and some > others is formatted funny. Sure. Perhaps a different separator would be better for you? ^L? Let me know. I'll be sure to remove leading spaces-- it may be worth your doing a reformat paragraph though, excluding the first line (which I can separate from the rest by a blank line -- the first line is intended to be a one-sentence synopsis, as in Emacs docstrings (this convention wasn't enunciated by me when Maciej did the docing, so a quick pass through the documentation is still needed. > > 2. the file primitives.txt is installed, say in ${prefix}/info. Ok.... perhaps a better name? > > 3. there seems to be some information in *sgml which did not trickle > down to *txt, like where the primitive was defined. I think it > should. Ok (again, they're created by the same program as two separate outputs -- the .sgml is *not* used to produce the .txt). > > >> We still need to document scheme-level procedures, but the extraction > >> should be very similar. > > ... and should go to the same file (which should be renamed scwm-procs.txt) That'll do. > > Thanks. Thank *you*! Greg From owner-scwm-discuss@mit.edu Wed Jul 22 11:27:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA03710 for scwm-discuss-outgoing; Wed, 22 Jul 1998 11:27:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA03707 for ; Wed, 22 Jul 1998 11:27:10 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10615; Wed, 22 Jul 98 11:26:24 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA18723; Wed, 22 Jul 1998 08:25:51 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: From: Greg Badros Date: 22 Jul 1998 08:25:51 -0700 In-Reply-To: Robert Bihlmeyer's message of "22 Jul 1998 11:45:03 +0200" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> I also suggest using \< to expand into <, and \& to expand > Greg> into & (instead of < and & which I think are a lot less > Greg> readable). > > It is more readable, but adding another escape makes a big mess. > > What if I want to have a literal "\&" in the docs? Would backslashes > have to be escaped always, or just before "<" and "&"? The former > brings execcive leaning toothpicks, the latter is kinda ugly. Yep. I concur. I went with just trying to be smart about substitutions. We'll see where the problems crop up, but another escape is bad news. > Greg> We could also forbid spaces from following `<' or '&', and if > Greg> we see a space, just take that to mean that we want the literal > Greg> character > > This is certainly convenient. > > Greg> (since those characters will almost always be separated from > Greg> adjacent identifiers by spaces when they are used for > Greg> themselves instead of markup). > > Hmm, I usually write "X "X<Y" of course. I think "X < Y" is a lot more readable, anyway, so it's better to encourage that, IMHO. And, like you say, if you must have what you want, you can get there from here. Thanks for the comments! Greg From owner-scwm-discuss@mit.edu Wed Jul 22 11:59:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04106 for scwm-discuss-outgoing; Wed, 22 Jul 1998 11:59:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA04103 for ; Wed, 22 Jul 1998 11:59:10 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA29863; Wed, 22 Jul 98 11:57:58 EDT Received: from marconi.concentric.net (marconi [206.173.115.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id LAA24964; Wed, 22 Jul 1998 11:57:49 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by marconi.concentric.net (8.8.8) id LAA22976; Wed, 22 Jul 1998 11:58:00 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id LAA05734; Wed, 22 Jul 1998 11:57:53 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "22 Jul 1998 08:23:12 -0700" Date: 22 Jul 1998 11:57:52 -0400 Message-Id: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 22 Jul 1998 08:23:12 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> Sam Steingold writes: >> > 1. that the present file format is preserved: descriptions are separated >> > by "^J^J(". BTW, the documentation of `clever-place-window' and some >> > others is formatted funny. >> >> Sure. Perhaps a different separator would be better for you? ^L? >> Let me know. ^L is fine. Please put it in. This way we will be able to have multi-paragraph docs with lines starting with "(func" in them. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Don't ascribe to malice what can be adequately explained for by stupidity. From owner-scwm-discuss@mit.edu Wed Jul 22 12:26:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA04429 for scwm-discuss-outgoing; Wed, 22 Jul 1998 12:26:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA04423; Wed, 22 Jul 1998 12:26:06 -0400 Message-Id: <199807221626.MAA04423@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! In-reply-to: Your message of "22 Jul 1998 08:23:12 PDT." Date: Wed, 22 Jul 1998 12:26:05 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Sam Steingold writes: > > > > > I'll write a scheme procedure `documentation', taking a function name > > and returning the appropriate block from primitives.txt. I'll add the > > appropriate Emacs interface too. In light of this, I would appreciate > > > > 1. that the present file format is preserved: descriptions are separated > > by "^J^J(". BTW, the documentation of `clever-place-window' and some > > others is formatted funny. > That would be great. > I'll be sure to remove leading spaces-- it may be worth your doing a > reformat paragraph though, excluding the first line (which I can > separate from the rest by a blank line -- the first line is intended to > be a one-sentence synopsis, as in Emacs docstrings (this convention > wasn't enunciated by me when Maciej did the docing, so a quick pass > through the documentation is still needed. Yeah, I didn't know that. How about using the first sentence (splitting on the first period) instead of the first line? Or is it that way intentionally, to ensure you make the first sentence short enough? :-) > > > > > 2. the file primitives.txt is installed, say in ${prefix}/info. > > Ok.... perhaps a better name? > I'd also suggest a different location, ${prefix}/info should be for .info files only. How about ${prefix}/share/scwm ? I think that is analogous to where emacs puts it's extracted docstrings. > > > > 3. there seems to be some information in *sgml which did not trickle > > down to *txt, like where the primitive was defined. I think it > > should. > > Ok (again, they're created by the same program as two separate outputs > -- the .sgml is *not* used to produce the .txt). > > > > > >> We still need to document scheme-level procedures, but the extraction > > >> should be very similar. > > > > ... and should go to the same file (which should be renamed scwm-procs.txt) > > That'll do. > > > > > Thanks. > > Thank *you*! > At the risk of starting a mutual admiration society, thanks to both of you for helping the documentation system workable. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 22 14:55:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05304 for scwm-discuss-outgoing; Wed, 22 Jul 1998 14:55:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA05301 for ; Wed, 22 Jul 1998 14:55:41 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA10941; Wed, 22 Jul 98 14:54:53 EDT Received: from newman.concentric.net (newman [206.173.118.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id OAA16628; Wed, 22 Jul 1998 14:54:33 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by newman.concentric.net (8.8.8) id OAA12165; Wed, 22 Jul 1998 14:54:16 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id OAA06269; Wed, 22 Jul 1998 14:42:53 -0400 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807221626.MAA04423@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Wed, 22 Jul 1998 12:26:05 EDT" Date: 22 Jul 1998 14:42:52 -0400 Message-Id: Lines: 93 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. `&' is replaced with "&" in scwm-procedures.txt. 2. I *really* wish there were a file guile-procedures.txt. 3. The thing works, I put it into flux.scm; C-h C-s in emacs. Please try it. >>>> In message <199807221626.MAA04423@huis-clos.mit.edu> >>>> Sent on Wed, 22 Jul 1998 12:26:05 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> gjb@cs.washington.edu writes: >> > Sam Steingold writes: >> >> That would be great. >> >> > I'll be sure to remove leading spaces-- it may be worth your doing a >> > reformat paragraph though, excluding the first line (which I can >> > separate from the rest by a blank line -- the first line is intended to >> > be a one-sentence synopsis, as in Emacs docstrings (this convention >> > wasn't enunciated by me when Maciej did the docing, so a quick pass >> > through the documentation is still needed. >> >> Yeah, I didn't know that. How about using the first sentence >> (splitting on the first period) instead of the first line? Or is it >> that way intentionally, to ensure you make the first sentence short >> enough? :-) a. there should be a blank line between the function signature and the documentation; b. the first line in the documentation should be a complete sentence summary; c. the second line should be blank. d. please, *please*, *PLEASE* spell-check the docs. ispell-buffer in emacs 20.3 can spell-check just the comments in the file. if you are not running the pretest, please use ispell-region instead. spelling errors in documentation reflect poorly on the developers. :-) E.g.: current: --------------------------------------------------------------------- (send-key-press key #&optional win key-press? key-release? propagate?) Send a synthetic press of KEY. The usual key specification format (with modifiers) is used. The event is sent to window WIN if specified; otherwise the window to be used defaults to the window context in the usual way. By default, both a press and a release are sent. However, the boolean parameters KEY-PRESS? and KEY-RELEASE? allow you to specify which are sent individually. PROPAGATE? indicates wether the propagate flag is set on the event; the default is #f. You shouldn't have to worry about this unless you know what it means. [From scwm/events.c:1821] --------------------------------------------------------------------- proposed (note corrected spelling :-): --------------------------------------------------------------------- (send-key-press key #&optional win key-press? key-release? propagate?) Send a synthetic press of KEY. The usual key specification format (with modifiers) is used. The event is sent to window WIN if specified; otherwise the window to be used defaults to the window context in the usual way. By default, both a press and a release are sent. However, the boolean parameters KEY-PRESS? and KEY-RELEASE? allow you to specify which are sent individually. PROPAGATE? indicates whether the propagate flag is set on the event; the default is #f. You shouldn't have to worry about this unless you know what it means. [From scwm/events.c:1821] --------------------------------------------------------------------- `a' and `c' can be arranged by `extract-docs'; `b' and `d' have to be taken care of by the programmer. >> > > 2. the file primitives.txt is installed, say in ${prefix}/info. >> > >> > Ok.... perhaps a better name? >> > >> >> I'd also suggest a different location, ${prefix}/info should be for >> .info files only. How about ${prefix}/share/scwm ? I think that is >> analogous to where emacs puts it's extracted docstrings. we should also find a way to put the location of the file as well as that of the similar guile file into the `doc-files' variable in flux.scm. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Live free or die. From owner-scwm-discuss@mit.edu Wed Jul 22 15:22:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05723 for scwm-discuss-outgoing; Wed, 22 Jul 1998 15:22:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA05720 for ; Wed, 22 Jul 1998 15:22:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23853; Wed, 22 Jul 98 15:21:18 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA19103; Wed, 22 Jul 1998 12:21:23 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807221626.MAA04423@huis-clos.mit.edu> From: Greg Badros Date: 22 Jul 1998 12:21:23 -0700 In-Reply-To: Sam Steingold's message of "22 Jul 1998 14:42:52 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 1. `&' is replaced with "&" in scwm-procedures.txt. I'll fix this. > 2. I *really* wish there were a file guile-procedures.txt. Me too... hopefully our quick turnaround time on documenting all of scwm will convince them of the worthiness of this documentation extraction system and they'll start using it too. > 3. The thing works, I put it into flux.scm; C-h C-s in emacs. Please > try it. Will do. Greg From owner-scwm-discuss@mit.edu Wed Jul 22 16:44:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06679 for scwm-discuss-outgoing; Wed, 22 Jul 1998 16:44:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06672; Wed, 22 Jul 1998 16:44:18 -0400 Message-Id: <199807222044.QAA06672@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! In-reply-to: Your message of "22 Jul 1998 12:21:23 PDT." Date: Wed, 22 Jul 1998 16:44:18 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Sam Steingold writes: > > > 2. I *really* wish there were a file guile-procedures.txt. > > Me too... hopefully our quick turnaround time on documenting all of scwm > will convince them of the worthiness of this documentation extraction > system and they'll start using it too. > I just sent mail on this very topic. > > 3. The thing works, I put it into flux.scm; C-h C-s in emacs. Please > > try it. > > Will do. > One it has stabilized, it should go somewhere more official than flux.scm, I'd be in favor of either base.scm or a new docs.scm module. Once all the guile stuff has stabilized enough to use with Guile, hopefully it can all migrate into the Guile distribution. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 22 17:01:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA06997 for scwm-discuss-outgoing; Wed, 22 Jul 1998 17:01:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA06992 for ; Wed, 22 Jul 1998 17:01:19 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA21718; Wed, 22 Jul 98 17:00:00 EDT Received: from mcfeely.concentric.net (mcfeely [206.173.118.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id RAA09477; Wed, 22 Jul 1998 17:00:03 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by mcfeely.concentric.net (8.8.8) id QAA25749; Wed, 22 Jul 1998 16:59:53 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id QAA06440; Wed, 22 Jul 1998 16:37:19 -0400 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807221626.MAA04423@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "22 Jul 1998 12:21:23 -0700" Date: 22 Jul 1998 16:37:18 -0400 Message-Id: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 22 Jul 1998 12:21:23 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> Sam Steingold writes: >> >> > 3. The thing works, I put it into flux.scm; C-h C-s in emacs. >> > Please try it. >> Will do. Thanks. While you are at it, please check the new apropos too: C-h C-a -> *Apropos* buffer with mouse-2 clickable items (click --> scwm-documentation). It workd for me in emacs 20.3 (pretest). What about XEmacs? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. OK, so you're a Ph.D. Just don't touch anything. From owner-scwm-discuss@mit.edu Wed Jul 22 17:08:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07127 for scwm-discuss-outgoing; Wed, 22 Jul 1998 17:08:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07122; Wed, 22 Jul 1998 17:08:06 -0400 Message-Id: <199807222108.RAA07122@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! In-reply-to: Your message of "22 Jul 1998 16:37:18 EDT." Date: Wed, 22 Jul 1998 17:08:06 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > Thanks. While you are at it, please check the new apropos too: C-h C-a > -> *Apropos* buffer with mouse-2 clickable items (click --> > scwm-documentation). It workd for me in emacs 20.3 (pretest). > What about XEmacs? > This concept is so cool, it hurts. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 22 17:12:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07209 for scwm-discuss-outgoing; Wed, 22 Jul 1998 17:12:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07203; Wed, 22 Jul 1998 17:12:41 -0400 Message-Id: <199807222112.RAA07203@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! In-reply-to: Your message of "22 Jul 1998 14:42:52 EDT." Date: Wed, 22 Jul 1998 17:12:40 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > d. please, *please*, *PLEASE* spell-check the docs. ispell-buffer in > emacs 20.3 can spell-check just the comments in the file. if you are > not running the pretest, please use ispell-region instead. spelling > errors in documentation reflect poorly on the developers. :-) > I'll try to start using ispell. However, is there any way to get the doc extractor to do some sort of non-interactive spell checking of the docs and warn if there are problems? - Maciej From owner-scwm-discuss@mit.edu Wed Jul 22 17:32:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA10415 for scwm-discuss-outgoing; Wed, 22 Jul 1998 17:32:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA10412 for ; Wed, 22 Jul 1998 17:32:02 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA29726; Wed, 22 Jul 98 17:30:47 EDT Received: from marconi.concentric.net (marconi [206.173.115.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id RAA25964; Wed, 22 Jul 1998 17:30:30 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by marconi.concentric.net (8.8.8) id RAA29696; Wed, 22 Jul 1998 17:30:44 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA06539; Wed, 22 Jul 1998 17:22:21 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807222112.RAA07203@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Wed, 22 Jul 1998 17:12:40 EDT" Date: 22 Jul 1998 17:22:20 -0400 Message-Id: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199807222112.RAA07203@huis-clos.mit.edu> >>>> Sent on Wed, 22 Jul 1998 17:12:40 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> sds@goems.com writes: >> > >> > d. please, *please*, *PLEASE* spell-check the docs. ispell-buffer in >> > emacs 20.3 can spell-check just the comments in the file. if you are >> > not running the pretest, please use ispell-region instead. spelling >> > errors in documentation reflect poorly on the developers. :-) >> > >> >> I'll try to start using ispell. However, is there any way to get the >> doc extractor to do some sort of non-interactive spell checking of the >> docs and warn if there are problems? All unix systems include /usr/bin/spell since times immemorial. It should be easy to call it on the resulting file. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Only a fool has no doubts. From owner-scwm-discuss@mit.edu Wed Jul 22 17:32:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA10422 for scwm-discuss-outgoing; Wed, 22 Jul 1998 17:32:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA10419 for ; Wed, 22 Jul 1998 17:32:07 -0400 Received: from uhura.concentric.net by MIT.EDU with SMTP id AA29634; Wed, 22 Jul 98 17:31:18 EDT Received: from marconi.concentric.net (marconi [206.173.115.71]) by uhura.concentric.net (8.8.8/(98/05/18 5.10)) id RAA25985; Wed, 22 Jul 1998 17:30:33 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by marconi.concentric.net (8.8.8) id RAA29712; Wed, 22 Jul 1998 17:30:46 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA06547; Wed, 22 Jul 1998 17:28:27 -0400 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807222044.QAA06672@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Wed, 22 Jul 1998 16:44:18 EDT" Date: 22 Jul 1998 17:28:26 -0400 Message-Id: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199807222044.QAA06672@huis-clos.mit.edu> >>>> Sent on Wed, 22 Jul 1998 16:44:18 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> >> One it has stabilized, it should go somewhere more official than >> flux.scm, I'd be in favor of either base.scm or a new docs.scm >> module. Once all the guile stuff has stabilized enough to use with >> Guile, hopefully it can all migrate into the Guile distribution. Of course. My vision is a standard guile function `documentation' controlled by a variable `doc-files'. The only think scwm will have to do is to push the path to scwm-procedures.txt into this variable. IMHO, as soon as the guile people adopt Greg's `extract-docs', they can grab `documentation' from flux.scm. That means *right now*. :-) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. main(a){a="main(a){a=%c%s%c;printf(a,34,a,34);}";printf(a,34,a,34);} From owner-scwm-discuss@mit.edu Wed Jul 22 18:12:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA10955 for scwm-discuss-outgoing; Wed, 22 Jul 1998 18:12:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA10951 for ; Wed, 22 Jul 1998 18:12:43 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA08043; Wed, 22 Jul 98 18:11:54 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA22337; Wed, 22 Jul 1998 18:11:17 -0400 (EDT) Message-Id: <199807222211.SAA22337@jekyll.piermont.com> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! In-Reply-To: Your message of "22 Jul 1998 17:22:20 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 22 Jul 1998 18:11:17 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > All unix systems include /usr/bin/spell since times immemorial. > It should be easy to call it on the resulting file. Spell isn't as cool as ispell, though. Perry From owner-scwm-discuss@mit.edu Wed Jul 22 18:18:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA11056 for scwm-discuss-outgoing; Wed, 22 Jul 1998 18:18:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA11053 for ; Wed, 22 Jul 1998 18:18:25 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09293; Wed, 22 Jul 98 18:17:36 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA19384; Wed, 22 Jul 1998 15:17:11 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807222044.QAA06672@huis-clos.mit.edu> From: Greg Badros Date: 22 Jul 1998 15:17:11 -0700 In-Reply-To: Sam Steingold's message of "22 Jul 1998 17:28:26 -0400" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > Of course. > > My vision is a standard guile function `documentation' controlled by a > variable `doc-files'. The only think scwm will have to do is to push > the path to scwm-procedures.txt into this variable. > > IMHO, as soon as the guile people adopt Greg's `extract-docs', they can > grab `documentation' from flux.scm. That means *right now*. :-) I can't wait! Greg From owner-scwm-discuss@mit.edu Wed Jul 22 19:05:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA11373 for scwm-discuss-outgoing; Wed, 22 Jul 1998 19:05:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA11370 for ; Wed, 22 Jul 1998 19:05:13 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA15910; Wed, 22 Jul 98 19:03:56 EDT Received: from newman.concentric.net (newman [206.173.118.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id TAA03564; Wed, 22 Jul 1998 19:03:59 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d04.phe-pa.concentric.net [209.31.155.112]) by newman.concentric.net (8.8.8) id TAA27956; Wed, 22 Jul 1998 19:03:41 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA06834; Wed, 22 Jul 1998 18:58:11 -0400 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807222211.SAA22337@jekyll.piermont.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: "Perry E. Metzger"'s message of "Wed, 22 Jul 1998 18:11:17 -0400" Date: 22 Jul 1998 18:58:10 -0400 Message-Id: Lines: 17 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199807222211.SAA22337@jekyll.piermont.com> >>>> Sent on Wed, 22 Jul 1998 18:11:17 -0400 >>>> Honorable "Perry E. Metzger" writes >>>> on the subject of "Re: We have DOCUMENTATION!": >> Sam Steingold writes: >> > All unix systems include /usr/bin/spell since times immemorial. >> > It should be easy to call it on the resulting file. >> >> Spell isn't as cool as ispell, though. ispell cannot run in batch mode, can it? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Sex is like air. It's only a big deal if you can't get any. From owner-scwm-discuss@mit.edu Wed Jul 22 19:27:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA11661 for scwm-discuss-outgoing; Wed, 22 Jul 1998 19:27:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA11658 for ; Wed, 22 Jul 1998 19:27:16 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18866; Wed, 22 Jul 98 19:26:00 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA19519; Wed, 22 Jul 1998 16:25:26 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: We have DOCUMENTATION! References: <199807222211.SAA22337@jekyll.piermont.com> From: Greg Badros Date: 22 Jul 1998 16:25:26 -0700 In-Reply-To: Sam Steingold's message of "22 Jul 1998 18:58:10 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <199807222211.SAA22337@jekyll.piermont.com> > >>>> Sent on Wed, 22 Jul 1998 18:11:17 -0400 > >>>> Honorable "Perry E. Metzger" writes > >>>> on the subject of "Re: We have DOCUMENTATION!": > >> Sam Steingold writes: > >> > All unix systems include /usr/bin/spell since times immemorial. > >> > It should be easy to call it on the resulting file. > >> > >> Spell isn't as cool as ispell, though. > > ispell cannot run in batch mode, can it? I'm fooling around with open2 and ispell -a -- should have something working before I go home today. Greg From owner-scwm-discuss@mit.edu Thu Jul 23 04:52:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA14787 for scwm-discuss-outgoing; Thu, 23 Jul 1998 04:52:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA14784 for ; Thu, 23 Jul 1998 04:52:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA18822; Thu, 23 Jul 98 04:51:31 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA04365; Thu, 23 Jul 1998 11:51:02 +0300 To: scwm-discuss@mit.edu Subject: Guile 1.2 support revisited. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 23 Jul 1998 11:51:02 +0300 In-Reply-To: Greg Badros's message of "22 Jul 1998 16:25:26 -0700" Message-Id: Lines: 36 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I was originally concerned with guile 1.2 support because: 1. At one point I had tried to install a guile snapshot & it failed to compile, so 2. I installed guile 1.2 & was hesitant to install another snapshot. Since then I was using a guile snapshot in the office & guile 1.2 at home. I had found scwm to be far more unstable with guile 1.2 than with the snapshot. For example, bringing my .scwmrc into emacs, and evaling (with ^x^j) the following form: (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) typically worked fine in the office (with the guile-snap), but would cause scwm to hang at home (with guile 1.2). With guile 1.2 it would never complete the command, would keep sucking up more & more memory, etc. This could have been due to different scwm versions as opposed to different guile versions, but I'm pretty sure I was running scwm-0.7a both at home & in the office at the time. May I be so bold as to suggest that if it's lots of work to make scwm robust under guile 1.2, then support should either be dropped for 1.2 or documentation/web pages/etc should say that scwm is less robust and has less features under 1.2 & that guile-snap usage is encouraged? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 23 08:56:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15935 for scwm-discuss-outgoing; Thu, 23 Jul 1998 08:56:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA15932 for ; Thu, 23 Jul 1998 08:56:25 -0400 Received: from online.no by MIT.EDU with SMTP id AA11490; Thu, 23 Jul 98 08:55:30 EDT Received: from terje.nextel.no (terje.nextel.no [193.212.0.25]) by online.no (8.8.8/8.8.7) with ESMTP id OAA06488 for ; Thu, 23 Jul 1998 14:55:05 +0200 (MET DST) Received: (from ts@localhost) by terje.nextel.no (8.8.8/8.7.3) id OAA03520; Thu, 23 Jul 1998 14:55:05 +0200 (MET DST) From: Terje Sannum To: scwm-discuss@mit.edu Subject: plain-border trouble Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 23 Jul 1998 14:55:05 +0200 Message-Id: Lines: 32 X-Mailer: Gnus v5.6.24/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I want my windows to have no borders and a plain flat titlebar (twm look). I've tried to do this with this style: (define std-decor (make-decor)) (with-decor std-decor (title-style #:font window-title-font #:justify 'left #:relief 'flat) (button-style 1 #:relief 'flat #:pixmap "iconify.xpm") (button-style 2 #:relief 'flat #:pixmap "resize.xpm") (button-style 3 #:relief 'flat #:pixmap "close.xpm") (set-hilight-background! "salmon") ) (define std-style (make-style #:border-width 0 #:plain-border #t #:use-decor std-decor)) This does not work as I expected. The top resize bar is not removed and is now drawn in the title bar instead of the border. Plain-border seems to only remove the shading of the handles. Setting a border-width of 10 shows that this is also the same for the other handles. Is this a bug or am I missing something here? Another thing: If I set a border width of 0 and don't set plain-border I get a lot of these messages: [Scwm][ScwmErrorHandler]: <> *** internal error *** [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 0 All this is with scwm-19980722 and guile-980707 (on Solaris 2.6/X11R6.4). -- \\\\ Terje Sannum //// Now playing: Solar Enemy / dirtyvsuniverse From owner-scwm-discuss@mit.edu Thu Jul 23 09:42:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16177 for scwm-discuss-outgoing; Thu, 23 Jul 1998 09:42:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA16174 for ; Thu, 23 Jul 1998 09:42:22 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA22648; Thu, 23 Jul 98 09:41:25 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id JAA19355; Thu, 23 Jul 1998 09:40:59 -0400 (EDT) Message-Id: <199807231340.JAA19355@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. In-Reply-To: Your message of "23 Jul 1998 11:51:02 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 Jul 1998 09:40:59 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > May I be so bold as to suggest that if it's lots of work to make scwm > robust under guile 1.2, then support should either be dropped for 1.2 > or documentation/web pages/etc should say that scwm is less robust and > has less features under 1.2 & that guile-snap usage is encouraged? 1.2 is the only released version of guile. As it turns out, it is the version I'm using with 0.7a, and it works fine, except for my persisting double click issue... Perry From owner-scwm-discuss@mit.edu Thu Jul 23 09:45:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16220 for scwm-discuss-outgoing; Thu, 23 Jul 1998 09:45:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA16217 for ; Thu, 23 Jul 1998 09:45:29 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA23535; Thu, 23 Jul 98 09:44:33 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA11816; Thu, 23 Jul 1998 16:44:03 +0300 To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. References: <199807231340.JAA19355@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 23 Jul 1998 16:44:03 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Thu, 23 Jul 1998 09:40:59 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > May I be so bold as to suggest that if it's lots of work to make scwm > > robust under guile 1.2, then support should either be dropped for 1.2 > > or documentation/web pages/etc should say that scwm is less robust and > > has less features under 1.2 & that guile-snap usage is encouraged? > > 1.2 is the only released version of guile. I know, which is why I was so adamant about 1.2 support earlier & which is why I was hesitant to make the above suggestion. > As it turns out, it is the version I'm using with 0.7a, and it > works fine, except for my persisting double click issue... Do you regularly eval things in an emacs buffer &/or run an *scwm* buffer? If not, maybe that's the only thing that's still buggy under 1.2. I did say "*if* it's lots of work...". -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 23 10:27:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA16525 for scwm-discuss-outgoing; Thu, 23 Jul 1998 10:27:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA16522 for ; Thu, 23 Jul 1998 10:27:43 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA06393; Thu, 23 Jul 98 10:26:46 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id KAA19487; Thu, 23 Jul 1998 10:26:19 -0400 (EDT) Message-Id: <199807231426.KAA19487@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. In-Reply-To: Your message of "23 Jul 1998 16:44:03 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 23 Jul 1998 10:26:19 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > As it turns out, it is the version I'm using with 0.7a, and it > > works fine, except for my persisting double click issue... > > Do you regularly eval things in an emacs buffer &/or run an *scwm* > buffer? If not, maybe that's the only thing that's still buggy under > 1.2. I did say "*if* it's lots of work...". No, I don't do it regularly. That might be the difference here. I'm hoping guile 1.3 comes out soon anyway. .pm From owner-scwm-discuss@mit.edu Thu Jul 23 11:41:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16925 for scwm-discuss-outgoing; Thu, 23 Jul 1998 11:41:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA16922 for ; Thu, 23 Jul 1998 11:41:33 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10654; Thu, 23 Jul 98 11:40:03 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20361; Thu, 23 Jul 1998 08:40:00 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: plain-border trouble References: From: Greg Badros Date: 23 Jul 1998 08:39:59 -0700 In-Reply-To: Terje Sannum's message of "23 Jul 1998 14:55:05 +0200" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > I want my windows to have no borders and a plain flat titlebar (twm > look). I've tried to do this with this style: > > (define std-decor (make-decor)) > (with-decor std-decor > (title-style #:font window-title-font #:justify 'left #:relief 'flat) > (button-style 1 #:relief 'flat #:pixmap "iconify.xpm") > (button-style 2 #:relief 'flat #:pixmap "resize.xpm") > (button-style 3 #:relief 'flat #:pixmap "close.xpm") > (set-hilight-background! "salmon") > ) > > (define std-style > (make-style #:border-width 0 #:plain-border #t #:use-decor std-decor)) > > This does not work as I expected. The top resize bar is not removed > and is now drawn in the title bar instead of the border. Plain-border > seems to only remove the shading of the handles. Setting a > border-width of 10 shows that this is also the same for the other > handles. Is this a bug or am I missing something here? Sounds like it's more than just *a* bug, but plenty of them. The window decorating code will be revisited thoroughly at some point, hopefully not too far off. The legacy fvwm2 drawing code has lots of places where things don't interact very well with the more flexible scwm options. > > Another thing: If I set a border width of 0 and don't set plain-border > I get a lot of these messages: > > [Scwm][ScwmErrorHandler]: <> *** internal error *** > [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 0 Remember, you can use X-error-describe as a filter to make these errors more readable. Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Thu Jul 23 16:40:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18404 for scwm-discuss-outgoing; Thu, 23 Jul 1998 16:40:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA18401 for ; Thu, 23 Jul 1998 16:40:33 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA25192; Thu, 23 Jul 98 16:39:31 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id VAA20566 for ; Thu, 23 Jul 1998 21:35:59 +0100 Date: Thu, 23 Jul 1998 21:35:59 +0100 (BST) From: Danius Michaelides To: scwm-discuss@mit.edu Subject: winskiplist Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi scwm-ers, Whilst working on the fvwm module stuff, i've noticed that windows that shouldnt, show up on FvwmIconMan. Looking at the code for the module, i see that it checks the WINDOWLISTSKIP flag. And it seems that the fWindowListSkip bit is always clear in the marshal_fvwm2_config_info function. But as far as (winlist-skip?) is concerned everything is fine.. So there seems to be an inconsistency in the datastructures. Danius From owner-scwm-discuss@mit.edu Thu Jul 23 17:32:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18695 for scwm-discuss-outgoing; Thu, 23 Jul 1998 17:32:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18689 for ; Thu, 23 Jul 1998 17:31:58 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA11981; Thu, 23 Jul 98 17:30:31 EDT Received: from mcfeely.concentric.net (mcfeely [206.173.118.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id RAA18320; Thu, 23 Jul 1998 17:30:38 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d20.phe-pa.concentric.net [209.31.155.80]) by mcfeely.concentric.net (8.8.8) id RAA15067; Thu, 23 Jul 1998 17:30:35 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA16330; Thu, 23 Jul 1998 17:14:12 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: New fvwm2 module interface References: <199807220325.XAA31477@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Tue, 21 Jul 1998 23:25:48 EDT" Date: 23 Jul 1998 17:14:11 -0400 Message-Id: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199807220325.XAA31477@huis-clos.mit.edu> >>>> Sent on Tue, 21 Jul 1998 23:25:48 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "New fvwm2 module interface": >> If use use tomorrow's snapshot, or the CVS version, you should know: >> >> I changed the fvwm2 module interface in a non-backwards-compatible >> way. I could have done it backwards compatibly if I'd resisted the >> urge to add 2's into the function names, but it was a good idea to >> reorder the arguments to run-fvwm2-module anyway now that more of them >> are optional, so I thought, hey, if I'm breaking things, I should go >> whole-hog and make sure people look at the docs when things break for >> them. >> >> The new interface is documented thoroguhly in a comment at the top of >> fvwm-module.scm, and I changed the distributed scwmrc's to use it. doesn't look like it. I think you forgot to document the change. when I run (define fvwm-pager (run-fvwm-module "/usr/X11/lib/X11/fvwm2/FvwmPager" ;; your .fvwm2rc (does not need to exist for most modules) "/dev/null" ;; list of configuration lines '("*FvwmPagerBack grey76" "*FvwmPagerFore black" "*FvwmPagerHilight grey90" "*FvwmPagerDeskTopScale 100" "*FvwmPagerGeometry 100x50+250-0" "*FvwmPagerLabel 0 Desk" ;; "*FvwmPagerLabel 1 Bottom" "*FvwmPagerSmallFont 5x7") ;; the range of desks to display '("0" "0"))) scwm dies. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Stupidity, like virtue, is its own reward. From owner-scwm-discuss@mit.edu Thu Jul 23 19:42:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20239 for scwm-discuss-outgoing; Thu, 23 Jul 1998 19:42:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20234; Thu, 23 Jul 1998 19:42:54 -0400 Message-Id: <199807232342.TAA20234@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: New fvwm2 module interface In-reply-to: Your message of "23 Jul 1998 17:14:11 EDT." Date: Thu, 23 Jul 1998 19:42:53 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199807220325.XAA31477@huis-clos.mit.edu> > >>>> Sent on Tue, 21 Jul 1998 23:25:48 EDT > >>>> Honorable Maciej Stachowiak writes > >>>> on the subject of "New fvwm2 module interface": > >> > >> The new interface is documented thoroguhly in a comment at the top of > >> fvwm-module.scm, and I changed the distributed scwmrc's to use it. > > doesn't look like it. I think you forgot to document the change. > Whoops, the actual problem is that my commit did not work for some reason. Unfortunately, I got a bad case of food posoning yesterday, and have not been able to check my mail until now. I think things should be fixed now. > when I run > > > (define fvwm-pager > (run-fvwm-module > "/usr/X11/lib/X11/fvwm2/FvwmPager" > ;; your .fvwm2rc (does not need to exist for most modules) > "/dev/null" > ;; list of configuration lines > '("*FvwmPagerBack grey76" > "*FvwmPagerFore black" > "*FvwmPagerHilight grey90" > "*FvwmPagerDeskTopScale 100" > "*FvwmPagerGeometry 100x50+250-0" > "*FvwmPagerLabel 0 Desk" > ;; "*FvwmPagerLabel 1 Bottom" > "*FvwmPagerSmallFont 5x7") > ;; the range of desks to display > '("0" "0"))) > > scwm dies. > That's due to a separate bug which I also just commited a change for. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 19:46:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20303 for scwm-discuss-outgoing; Thu, 23 Jul 1998 19:46:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20296; Thu, 23 Jul 1998 19:46:15 -0400 Message-Id: <199807232346.TAA20296@huis-clos.mit.edu> To: Danius Michaelides cc: scwm-discuss@mit.edu Subject: Re: winskiplist In-reply-to: Your message of "Thu, 23 Jul 1998 21:35:59 BST." Date: Thu, 23 Jul 1998 19:46:15 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk danius@duff.org writes: > Hi scwm-ers, > > Whilst working on the fvwm module stuff, i've noticed that windows > that shouldnt, show up on FvwmIconMan. Looking at the code for the > module, i see that it checks the WINDOWLISTSKIP flag. And it seems > that the fWindowListSkip bit is always clear in the marshal_fvwm2_config_info > function. But as far as (winlist-skip?) is concerned everything is > fine.. So there seems to be an inconsistency in the datastructures. > When I originally wrote the window list stuff, I made it use a Scheme-level object property instead of the internal winlist flag bit. In light of the current plans to support the fvwm2 module protocol as thoroughly as possible, I guess this was a wrong decision, since modules depend on this bit. I'll try to fix it ASAP. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 19:59:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20537 for scwm-discuss-outgoing; Thu, 23 Jul 1998 19:59:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA20534 for ; Thu, 23 Jul 1998 19:59:41 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04268; Thu, 23 Jul 98 19:58:40 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA21680; Thu, 23 Jul 1998 16:58:14 -0700 (PDT) To: Maciej Stachowiak Cc: Danius Michaelides , scwm-discuss@mit.edu Subject: Re: winskiplist References: <199807232346.TAA20296@huis-clos.mit.edu> From: Greg Badros Date: 23 Jul 1998 16:58:13 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 23 Jul 1998 19:46:15 EDT" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > danius@duff.org writes: > > Hi scwm-ers, > > > > Whilst working on the fvwm module stuff, i've noticed that windows > > that shouldnt, show up on FvwmIconMan. Looking at the code for the > > module, i see that it checks the WINDOWLISTSKIP flag. And it seems > > that the fWindowListSkip bit is always clear in the marshal_fvwm2_config_info > > function. But as far as (winlist-skip?) is concerned everything is > > fine.. So there seems to be an inconsistency in the datastructures. > > > > When I originally wrote the window list stuff, I made it use a > Scheme-level object property instead of the internal winlist flag bit. > In light of the current plans to support the fvwm2 module protocol as > thoroughly as possible, I guess this was a wrong decision, since > modules depend on this bit. I'll try to fix it ASAP. Not necessary -- we have to be able to get at scheme properties from the C-level... why not make it do the right thing and query the scheme property? Greg From owner-scwm-discuss@mit.edu Thu Jul 23 20:04:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20598 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:04:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20590; Thu, 23 Jul 1998 20:04:09 -0400 Message-Id: <199807240004.UAA20590@huis-clos.mit.edu> To: perry@piermont.com cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Automated Doc Extraction: A Premature Retrospective In-reply-to: Your message of "Thu, 23 Jul 1998 09:47:35 EDT." <199807231347.JAA19364@jekyll.piermont.com> Date: Thu, 23 Jul 1998 20:04:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I noticed belatedly that I adressed the initial post to `scwmm-discuss' among other places, a misspelling of `scwm-discuss'. I have corrected it here and would appreciate if others would do the same when replying on this thread. perry@piermont.com writes: > > Maciej Stachowiak writes: > > * The manual has no proper organization of any kind yet. You only get > > an alphabetical list of all the procedures, or a list by file where > > they are defined. It should be possible to impose a better organization > > I think that this is absolutely fine for a hyperlinked reference > work. Alphabetical is what you *want* in such a thing. > Well, for one thing, we also want this to be able to turn into nice printed output. For another, alphabetical is _one_ thing you want (same purpose as the index), but you probably also want more of a conceptual organization. > However, what one might be able to do is add a "category hint" of some > sort or other to each docstring if it is desired to do "alphabetical > by category" or some such. > We have documentation of concepts in the source already, I think a good plan would be to attach procedure documentation to the nearest concept and put them on one page. Obviously there must be ways to break that convention for the sake of code organization. > For the tutorial manual or what have you, it will probably be > reasonable to hyperlink general descriptions to the reference manual > for detailed information. That's what I expect. > > In fact, Guile's lack of good documentation has been a serious > > impediment to my attempts to evangelize Guile for all sorts of uses, > > I strongly agree with this. I myself have not used it in several > projects because figuring things out without a good document is just > "too hard". > I've been using it long enough now that the source is sufficient documentation for most things, but there are unfortunately very few people in that category. One thing I thought of since when I posted last night is that for Guile, it is as important, if not more important, to document the C API as well as the Scheme API. This was not a concern for scwm. However, just by adding C function signatures as well as Scheme ones to the documentation output, you can document (in a reference sense) almost all of the scm_ API for free just by documenting the Scheme primitives. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 20:10:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20739 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:10:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20731; Thu, 23 Jul 1998 20:10:24 -0400 Message-Id: <199807240010.UAA20731@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. In-reply-to: Your message of "Thu, 23 Jul 1998 09:40:59 EDT." <199807231340.JAA19355@jekyll.piermont.com> Date: Thu, 23 Jul 1998 20:10:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Harvey J. Stein writes: > > May I be so bold as to suggest that if it's lots of work to make scwm > > robust under guile 1.2, then support should either be dropped for 1.2 > > or documentation/web pages/etc should say that scwm is less robust and > > has less features under 1.2 & that guile-snap usage is encouraged? > > 1.2 is the only released version of guile. As it turns out, it is the > version I'm using with 0.7a, and it works fine, except for my > persisting double click issue... > Any luck narrowing down what that is? I might be able to get access to a NetBSD machine in two weeks or so, si I'll check things out then if you still have no leads. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 20:18:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20864 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:18:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20857; Thu, 23 Jul 1998 20:18:06 -0400 Message-Id: <199807240018.UAA20857@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. In-reply-to: Your message of "23 Jul 1998 11:51:02 +0300." Date: Thu, 23 Jul 1998 20:18:06 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > I was originally concerned with guile 1.2 support because: > > 1. At one point I had tried to install a guile snapshot & it failed > to compile, so > 2. I installed guile 1.2 & was hesitant to install another snapshot. > > Since then I was using a guile snapshot in the office & guile 1.2 at > home. > > I had found scwm to be far more unstable with guile 1.2 than with the > snapshot. > It may be that our 1.2 support is deficient in some ways. However, current snapshots are probably less buggu > For example, bringing my .scwmrc into emacs, and evaling (with ^x^j) > the following form: > > (window-style "Netscape: Question" #:sticky #t #:other-proc stack-windows) > > typically worked fine in the office (with the guile-snap), but would > cause scwm to hang at home (with guile 1.2). With guile 1.2 it would > never complete the command, would keep sucking up more & more memory, > etc. > > This could have been due to different scwm versions as opposed to > different guile versions, but I'm pretty sure I was running scwm-0.7a > both at home & in the office at the time. > > May I be so bold as to suggest that if it's lots of work to make scwm > robust under guile 1.2, then support should either be dropped for 1.2 > or documentation/web pages/etc should say that scwm is less robust and > has less features under 1.2 & that guile-snap usage is encouraged? > AFAIK, all the main developers are using fairly recent snapshots. This means that various odd corners of the code are a lot more likely to be worked out with snapshots than with 1.2. Guile snapshots do also support more of the features we use. So if we have not documented clearly enought that snapshots may work better, we should do so. However, maintaining the 1.2 support that exists is not a great burden, so I think we should try to keep it until 1.3 is out, whenever that may be. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 20:21:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20967 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:21:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA20964 for ; Thu, 23 Jul 1998 20:21:38 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA06750; Thu, 23 Jul 98 20:20:10 EDT Received: from mcfeely.concentric.net (mcfeely [206.173.118.83]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id UAA08202; Thu, 23 Jul 1998 20:20:17 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts007d20.phe-pa.concentric.net [209.31.155.80]) by mcfeely.concentric.net (8.8.8) id UAA03179; Thu, 23 Jul 1998 20:20:15 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id UAA16951; Thu, 23 Jul 1998 20:04:10 -0400 To: scwm-discuss@mit.edu Subject: documentation Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 23 Jul 1998 20:04:10 -0400 Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk scwm.el now supports emacs20.3 hypertext help. You need the current pretest to try it out, or hold your breath for the release. In light of this, please 1. When you write a doc for the object `foo' and want to refer to object `bar', you should enclose `bar' in "`'" (like I am writing). Then you will be able to click mouse2 (or hit RET) on the word `bar' in the *Help* buffer displaying documentation for `foo' to get a *Help* buffer with documentation for `bar'. 2. Please add doc strings to the scheme procedures you write. These doc strings are displayed by `procedure-documentation' (guile built-in), and are shown in *Help*, so the same hyper-link rules from item 1 apply. Thanks. Also, `make install` complains: Making install in doc make[1]: Entering directory `/usr/src/scwm/doc' make[1]: *** No rule to make target `install'. Stop. make[1]: Leaving directory `/usr/src/scwm/doc' make: *** [install-recursive] Error 1 whoever will be addressing this, will have to set `doc-files' in flux.scm to the location of the scwm-procedures.txt. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. We are born naked, wet, and hungry. Then things get worse. From owner-scwm-discuss@mit.edu Thu Jul 23 20:27:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA21125 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:27:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA21121 for ; Thu, 23 Jul 1998 20:27:01 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07375; Thu, 23 Jul 98 20:25:33 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA21719; Thu, 23 Jul 1998 17:25:37 -0700 (PDT) To: Maciej Stachowiak Cc: perry@piermont.com, guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Automated Doc Extraction: A Premature Retrospective References: <199807240004.UAA20590@huis-clos.mit.edu> From: Greg Badros Date: 23 Jul 1998 17:25:37 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 23 Jul 1998 20:04:09 EDT" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > However, what one might be able to do is add a "category hint" of some > > sort or other to each docstring if it is desired to do "alphabetical > > by category" or some such. > > > > We have documentation of concepts in the source already, I think a > good plan would be to attach procedure documentation to the nearest > concept and put them on one page. Obviously there must be ways to > break that convention for the sake of code organization. I'll probably get to integrating concept documentation into the manual sometime tomorrow or over the weekend. I've added links, and a more brief by-file chapter with links to the alphabetical functions (I'll be checking in shortly). Greg From owner-scwm-discuss@mit.edu Thu Jul 23 20:56:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA21618 for scwm-discuss-outgoing; Thu, 23 Jul 1998 20:56:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA21615 for ; Thu, 23 Jul 1998 20:56:08 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA11194; Thu, 23 Jul 98 20:55:06 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA21729; Thu, 23 Jul 1998 17:54:42 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: documentation References: From: Greg Badros Date: 23 Jul 1998 17:54:41 -0700 In-Reply-To: Sam Steingold's message of "23 Jul 1998 20:04:10 -0400" Message-Id: Lines: 48 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > scwm.el now supports emacs20.3 hypertext help. You need the current > pretest to try it out, or hold your breath for the release. > In light of this, please > > 1. When you write a doc for the object `foo' and want to refer to object > `bar', you should enclose `bar' in "`'" (like I am writing). Then > you will be able to click mouse2 (or hit RET) on the word `bar' in > the *Help* buffer displaying documentation for `foo' to get a *Help* > buffer with documentation for `bar'. I'm not sure what you mean by "object" `foo'. If you mean another scheme procedure, that's fine, and supported. But that's the only thing I expect to be between ` and '. The conventions are arguments in all caps, and scheme procedures in between ` and '. If we need something else we can add it, but it might not be between ` and '. > 2. Please add doc strings to the scheme procedures you write. These doc > strings are displayed by `procedure-documentation' (guile built-in), > and are shown in *Help*, so the same hyper-link rules from item 1 > apply. It'd be great if someone on the list who is reasonably skilled with technical writing could volunteer to at least make a first pass at the module files that are not documented. We'll have to discuss conventions a bit more, and one of us should do a sample file to solidify the conventions. > > Thanks. > > Also, `make install` complains: > Making install in doc > make[1]: Entering directory `/usr/src/scwm/doc' > make[1]: *** No rule to make target `install'. Stop. > make[1]: Leaving directory `/usr/src/scwm/doc' > make: *** [install-recursive] Error 1 > > whoever will be addressing this, will have to set `doc-files' in flux.scm > to the location of the scwm-procedures.txt. Ok, I fixed this in Makefile.am (after finally reading the Automake manual), so it's $prefix/share, I also just added some primitives to expose the install directories to the scheme level. I'll try to test it all before I go home. Greg From owner-scwm-discuss@mit.edu Thu Jul 23 21:02:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA21798 for scwm-discuss-outgoing; Thu, 23 Jul 1998 21:02:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA21791; Thu, 23 Jul 1998 21:02:41 -0400 Message-Id: <199807240102.VAA21791@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: documentation In-reply-to: Your message of "23 Jul 1998 17:54:41 PDT." Date: Thu, 23 Jul 1998 21:02:41 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Sam Steingold writes: > > > > 2. Please add doc strings to the scheme procedures you write. These doc > > strings are displayed by `procedure-documentation' (guile built-in), > > and are shown in *Help*, so the same hyper-link rules from item 1 > > apply. > > It'd be great if someone on the list who is reasonably skilled with > technical writing could volunteer to at least make a first pass at the > module files that are not documented. We'll have to discuss > conventions a bit more, and one of us should do a sample file to > solidify the conventions. > I'm probably going to try to move the documentation comments many of them already have into docstrings at some point. If anyone good a tech writing could look at _any_ of our docs and suggest improvements, that would be grand. I'm not a writer, I just play one on the internet. This brings up the point of new documentable entities though. Just as we need to be able to document hooks and variables and concepts in the C code, in the Scheme code we will have to individually document certain special variables, and we will need to be able to document style flags separately from window-style. (There are so many that doing it as one monolithic thing would be too painful, and they can be declared outside the (app scwm style module anyway). - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 21:16:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA22233 for scwm-discuss-outgoing; Thu, 23 Jul 1998 21:16:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA22225; Thu, 23 Jul 1998 21:16:08 -0400 Message-Id: <199807240116.VAA22225@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: winskiplist In-reply-to: Your message of "23 Jul 1998 16:58:13 PDT." Date: Thu, 23 Jul 1998 21:16:08 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > > When I originally wrote the window list stuff, I made it use a > > Scheme-level object property instead of the internal winlist flag bit. > > In light of the current plans to support the fvwm2 module protocol as > > thoroughly as possible, I guess this was a wrong decision, since > > modules depend on this bit. I'll try to fix it ASAP. > > Not necessary -- we have to be able to get at scheme properties from the > C-level... why not make it do the right thing and query the scheme property? > You are correct that it is not necessary. We have two options for implementing this, either add Scheme-level procedures implemented in C that get and set this flag, and let the C code work transparently, or let the C code check the Scheme property and OR it in when marshalling the flag word for modules. Since we will probably want to keep at least some flags as C bitfield bits for performance and compactness reasons, I figured the latter might be an easier implementation strategy. But either could work. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 23 21:23:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA22370 for scwm-discuss-outgoing; Thu, 23 Jul 1998 21:23:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA22367 for ; Thu, 23 Jul 1998 21:23:12 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14776; Thu, 23 Jul 98 21:22:10 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA21793; Thu, 23 Jul 1998 18:21:45 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: winskiplist References: <199807240116.VAA22225@huis-clos.mit.edu> From: Greg Badros Date: 23 Jul 1998 18:21:45 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 23 Jul 1998 21:16:08 EDT" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > You are correct that it is not necessary. We have two options for > implementing this, either add Scheme-level procedures implemented in C > that get and set this flag, and let the C code work transparently, or > let the C code check the Scheme property and OR it in when marshalling > the flag word for modules. Since we will probably want to keep at > least some flags as C bitfield bits for performance and compactness > reasons, I figured the latter might be an easier implementation > strategy. But either could work. My take was that since the window-list is an exclusively scheme-level construct, that it shouldn't rely on a C bitfield of the window struct to do the right thing. I think of it as more a backward compatibility (to fvwm2 modules) issue. I hope to do some rough memory profiling in the next day or two which might give us a better idea on when to be conservative/aggressive with the data in these structs. The ScwmWindow struct needs to be revisited and pruned down for sure! Greg From owner-scwm-discuss@mit.edu Fri Jul 24 01:01:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA25410 for scwm-discuss-outgoing; Fri, 24 Jul 1998 01:01:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA25407 for ; Fri, 24 Jul 1998 01:01:20 -0400 Received: from pcnet1.pcnet.com by MIT.EDU with SMTP id AA09549; Fri, 24 Jul 98 01:00:17 EDT Received: (from proteus@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id BAA15892; Fri, 24 Jul 1998 01:00:39 -0400 (EDT) Message-Id: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Fri, 24 Jul 1998 00:46:30 -0400 (EDT) Reply-To: Bob Woodside Organization: Woodsway Consulting From: Bob Woodside To: Greg Badros Subject: Re: winskiplist Cc: scwm-discuss@mit.edu, Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 24-Jul-98 Greg Badros wrote: > Maciej Stachowiak writes: > >> ...we will probably want to keep at least some flags as C bitfield bits >> for performance and compactness.... But either could work. > > My take was that since the window-list is an exclusively scheme-level > construct, Er, not really. The Scheme window-list is a Scheme representation of an underlying chain of ScwmWindow structures that are manipulated by C code. (There's no need for the Scheme programmer's model to view it this way, but the window manager designer needs to view it both ways.) > that it shouldn't rely on a C bitfield of the window struct to do the right > thing. I think of it as more a backward compatibility (to fvwm2 modules) > issue. Yes, it is. I think that for compatibility purposes you should probably keep the flags that are currently common to both Fvwm and Scwm as C bitfield bits in the ScwmWindow struct. As for any new constructs, there's still nothing wrong with using bitfields as appropriate. Don't think in terms of religious dogma (Scheme = Godly, C = Satanic), think pragmatically: which layer of code is going to access a flag most often, Scheme or C? Which will yield greater efficiency? From owner-scwm-discuss@mit.edu Fri Jul 24 01:31:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA25642 for scwm-discuss-outgoing; Fri, 24 Jul 1998 01:31:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA25639 for ; Fri, 24 Jul 1998 01:31:49 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA12670; Fri, 24 Jul 98 01:30:45 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id BAA21720; Fri, 24 Jul 1998 01:30:24 -0400 (EDT) Message-Id: <199807240530.BAA21720@jekyll.piermont.com> To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: Guile 1.2 support revisited. In-Reply-To: Your message of "Thu, 23 Jul 1998 20:10:24 EDT." <199807240010.UAA20731@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 24 Jul 1998 01:30:23 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > 1.2 is the only released version of guile. As it turns out, it is the > > version I'm using with 0.7a, and it works fine, except for my > > persisting double click issue... > > Any luck narrowing down what that is? No. I've been too busy to hack on it, unfortunately. > I might be able to get access to > a NetBSD machine in two weeks or so, si I'll check things out then if > you still have no leads. Thanks! Perry From owner-scwm-discuss@mit.edu Fri Jul 24 09:19:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA28293 for scwm-discuss-outgoing; Fri, 24 Jul 1998 09:19:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA28290 for ; Fri, 24 Jul 1998 09:19:16 -0400 Received: from darius.concentric.net by MIT.EDU with SMTP id AA15456; Fri, 24 Jul 98 09:17:41 EDT Received: from newman.concentric.net (newman [206.173.118.71]) by darius.concentric.net (8.8.8/(98/04/23 5.10)) id JAA25357; Fri, 24 Jul 1998 09:17:46 -0400 (EDT) [1-800-745-2747 The Concentric Network] Received: from mute.eaglets.com (ts008d06.phe-pa.concentric.net [209.31.155.114]) by newman.concentric.net (8.8.8) id JAA25322; Fri, 24 Jul 1998 09:17:33 -0400 (EDT) Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id JAA17642; Fri, 24 Jul 1998 09:12:38 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: documentation References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "23 Jul 1998 17:54:41 -0700" Date: 24 Jul 1998 09:12:37 -0400 Message-Id: Lines: 31 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 23 Jul 1998 17:54:41 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: documentation": >> Sam Steingold writes: >> >> > scwm.el now supports emacs20.3 hypertext help. You need the current >> > pretest to try it out, or hold your breath for the release. >> > In light of this, please >> > >> > 1. When you write a doc for the object `foo' and want to refer to object >> > `bar', you should enclose `bar' in "`'" (like I am writing). Then >> > you will be able to click mouse2 (or hit RET) on the word `bar' in >> > the *Help* buffer displaying documentation for `foo' to get a *Help* >> > buffer with documentation for `bar'. >> >> I'm not sure what you mean by "object" `foo'. If you mean another >> scheme procedure, that's fine, and supported. But that's the only thing >> I expect to be between ` and '. The conventions are arguments in all >> caps, and scheme procedures in between ` and '. If we need something >> else we can add it, but it might not be between ` and '. An object is something which is mentioned by `apropos-internal' and this can have `documentation'. I am trying to say that any symbol between ` and ' is clickable and clicking will call `scwm-documentation' on it. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A computer scientist is someone who fixes things that aren't broken. From owner-scwm-discuss@mit.edu Fri Jul 24 11:12:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28808 for scwm-discuss-outgoing; Fri, 24 Jul 1998 11:12:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28805 for ; Fri, 24 Jul 1998 11:12:54 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA12721; Fri, 24 Jul 98 11:11:17 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA25821; Fri, 24 Jul 1998 11:11:14 -0400 (EDT) Message-Id: <199807241511.LAA25821@jekyll.piermont.com> To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: documentation In-Reply-To: Your message of "Thu, 23 Jul 1998 21:02:41 EDT." <199807240102.VAA21791@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 24 Jul 1998 11:11:14 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I'm probably going to try to move the documentation comments many of > them already have into docstrings at some point. If anyone good a tech > writing could look at _any_ of our docs and suggest improvements, that > would be grand. I'm not a writer, I just play one on the internet. The NetBSD project benefits a lot from having a gnats database set up for accepting trouble reports, documentation updates, etc. in such a way that they are not lost. I strongly suggest that setting up gnats for scwm would be a good way of making it easy for people (even people not on the mailing list!) to send in fixes. > > This brings up the point of new documentable entities though. Just as > we need to be able to document hooks and variables and concepts in the > C code, in the Scheme code we will have to individually document > certain special variables, and we will need to be able to document > style flags separately from window-style. (There are so many that > doing it as one monolithic thing would be too painful, and they can be > declared outside the (app scwm style module anyway). > > - Maciej From owner-scwm-discuss@mit.edu Fri Jul 24 11:36:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29105 for scwm-discuss-outgoing; Fri, 24 Jul 1998 11:36:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29102 for ; Fri, 24 Jul 1998 11:36:23 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19124; Fri, 24 Jul 98 11:34:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23418; Fri, 24 Jul 1998 08:34:52 -0700 (PDT) To: Bob Woodside Cc: scwm-discuss@mit.edu, Maciej Stachowiak Subject: Re: winskiplist References: From: Greg Badros Date: 24 Jul 1998 08:34:51 -0700 In-Reply-To: Bob Woodside's message of "Fri, 24 Jul 1998 00:46:30 -0400 (EDT)" Message-Id: Lines: 47 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Bob Woodside writes: > On 24-Jul-98 Greg Badros wrote: > > Maciej Stachowiak writes: > > > >> ...we will probably want to keep at least some flags as C bitfield bits > >> for performance and compactness.... But either could work. > > > > My take was that since the window-list is an exclusively scheme-level > > construct, > > Er, not really. The Scheme window-list is a Scheme representation > of an underlying chain of ScwmWindow structures that are manipulated by > C code. (There's no need for the Scheme programmer's model to view it this > way, but the window manager designer needs to view it both ways.) I don't mean the list of all ScwmWindow structures--I just am referring to the user-level feature that produces a menu of the window list. That is written exclusively in Scheme in terms of a C primitive that exposes the C-level list of scheme window objects. > > that it shouldn't rely on a C bitfield of the window struct to do the right > > thing. I think of it as more a backward compatibility (to fvwm2 modules) > > issue. > > Yes, it is. I think that for compatibility purposes you should > probably keep the flags that are currently common to both Fvwm and Scwm as > C bitfield bits in the ScwmWindow struct. Compatibility is only in the interface to fvwm modules. No patches will work for both scwm and fvwm2 any longer since we're using bitfields. What compatibility purposes do you mean? > As for any new constructs, there's still nothing wrong with using > bitfields as appropriate. Don't think in terms of religious dogma (Scheme = > Godly, C = Satanic), think pragmatically: which layer of code is going to > access a flag most often, Scheme or C? Which will yield greater efficiency? Right-- that was my point -- the window list menu is only accessed from the scheme level, so why should it rely on a C level bitfield? Asking the micro-level efficiency question is premature---the right questions during development are what is a cleaner design and is more maintainable, extensible, and reliable. Only after profiling for performance will we perform that kind of efficiency tuning. (Distinct from choosing good algorithms, etc., which is a part of the design.) Greg From owner-scwm-discuss@mit.edu Fri Jul 24 11:39:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29149 for scwm-discuss-outgoing; Fri, 24 Jul 1998 11:39:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29146 for ; Fri, 24 Jul 1998 11:39:23 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19959; Fri, 24 Jul 98 11:37:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23421; Fri, 24 Jul 1998 08:37:54 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: documentation References: From: Greg Badros Date: 24 Jul 1998 08:37:54 -0700 In-Reply-To: Sam Steingold's message of "24 Jul 1998 09:12:37 -0400" Message-Id: Lines: 36 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 23 Jul 1998 17:54:41 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: documentation": > >> Sam Steingold writes: > >> > >> > scwm.el now supports emacs20.3 hypertext help. You need the current > >> > pretest to try it out, or hold your breath for the release. > >> > In light of this, please > >> > > >> > 1. When you write a doc for the object `foo' and want to refer to object > >> > `bar', you should enclose `bar' in "`'" (like I am writing). Then > >> > you will be able to click mouse2 (or hit RET) on the word `bar' in > >> > the *Help* buffer displaying documentation for `foo' to get a *Help* > >> > buffer with documentation for `bar'. > >> > >> I'm not sure what you mean by "object" `foo'. If you mean another > >> scheme procedure, that's fine, and supported. But that's the only thing > >> I expect to be between ` and '. The conventions are arguments in all > >> caps, and scheme procedures in between ` and '. If we need something > >> else we can add it, but it might not be between ` and '. > > An object is something which is mentioned by `apropos-internal' and this > can have `documentation'. I am trying to say that any symbol between ` > and ' is clickable and clicking will call `scwm-documentation' on it. Ahh... gotcha. For now, though, in the markup, I think it's in our best interest to use `foo' to mean a procedure foo, exclusively. Otherwise, I'd need a reliable way to determine whether `foo' referred to a procedure, symbol, or whatever, so I could output the right docbook tag. That's hard to do w/o seeing all of the guile procedure names at document-extraction time. Greg From owner-scwm-discuss@mit.edu Fri Jul 24 11:40:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29172 for scwm-discuss-outgoing; Fri, 24 Jul 1998 11:40:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29169 for ; Fri, 24 Jul 1998 11:40:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20214; Fri, 24 Jul 98 11:38:53 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23424; Fri, 24 Jul 1998 08:38:56 -0700 (PDT) To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: documentation References: <199807241511.LAA25821@jekyll.piermont.com> From: Greg Badros Date: 24 Jul 1998 08:38:56 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 24 Jul 1998 11:11:14 -0400" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > The NetBSD project benefits a lot from having a gnats database set up > for accepting trouble reports, documentation updates, etc. in such a > way that they are not lost. I strongly suggest that setting up gnats > for scwm would be a good way of making it easy for people (even people > not on the mailing list!) to send in fixes. I'm in favor of this, too, and would've suggested it sooner had I any experience using gnats. Perry, if we do choose to use gnats, could you lend us your expertise? Thanks for the suggestion, Greg From owner-scwm-discuss@mit.edu Fri Jul 24 12:06:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29432 for scwm-discuss-outgoing; Fri, 24 Jul 1998 12:06:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29429 for ; Fri, 24 Jul 1998 12:06:52 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA26677; Fri, 24 Jul 98 12:05:15 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id RAA21440; Fri, 24 Jul 1998 17:05:15 +0100 Date: Fri, 24 Jul 1998 17:05:15 +0100 (BST) From: Danius Michaelides To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: winskiplist In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 24 Jul 1998, Greg Badros wrote: > > bitfields as appropriate. Don't think in terms of religious dogma (Scheme = > > Godly, C = Satanic), think pragmatically: which layer of code is going to > > access a flag most often, Scheme or C? Which will yield greater efficiency? > > Right-- that was my point -- the window list menu is only accessed from > the scheme level, so why should it rely on a C level bitfield? Asking > the micro-level efficiency question is premature---the right questions > during development are what is a cleaner design and is more maintainable, > extensible, and reliable. Only after profiling for performance will we > perform that kind of efficiency tuning. (Distinct from choosing good > algorithms, etc., which is a part of the design.) Are we talking about the window list menu or just the window list? I hope its the latter. My point was that there appeared to be a bit flag for window-skip in the C data structure ScwmWindow, but it held incorrect information; it appears to not be in use. The thing is that we >are< wanting to access this value from the C level. Where is the scheme level flag for window skiplist stored? Danius From owner-scwm-discuss@mit.edu Fri Jul 24 12:15:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29507 for scwm-discuss-outgoing; Fri, 24 Jul 1998 12:15:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29504 for ; Fri, 24 Jul 1998 12:15:30 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28590; Fri, 24 Jul 98 12:13:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA23480; Fri, 24 Jul 1998 09:13:29 -0700 (PDT) To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: winskiplist References: From: Greg Badros Date: 24 Jul 1998 09:13:29 -0700 In-Reply-To: Danius Michaelides's message of "Fri, 24 Jul 1998 17:05:15 +0100 (BST)" Message-Id: Lines: 39 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Danius Michaelides writes: > Are we talking about the window list menu or just the window list? I > hope its the latter. My point was that there appeared to be a bit flag > for window-skip in the C data structure ScwmWindow, but it held incorrect > information; it appears to not be in use. > > The thing is that we >are< wanting to access this value from the C level. > Where is the scheme level flag for window skiplist stored? Right. We're kind of talking about both. The scheme level flag is in in an object property. This is from winlist.scm: (define*-public (winlist-skip #&optional (w (get-window))) (if w (set-object-property! w 'winlist-skip #t))) (define*-public (winlist-skip? #&optional (w (get-window))) (if w (object-property w 'winlist-skip) #f)) My point only was that the window list menu is the only thing that cares about the flag in scwm proper (i.e., excluding the fvwm-compat stuff), and object-properties work fine there. To make the fvwm-compat work-- i.e., to get the window-skip flag correct in the packets sent out to modules, we do need access to the flag. There are two ways to provide this: 1) revert the flag to the C level so that we then have primitives to get and set the flag from the scheme level (this was what Maciej initially said he'd have to do); or 2) before sending the packet out, query the window property and set the field just for the fvwm-compat stuff. I only wanted to point out that the second may be a viable design alternative (I haven't looked at the module code in a while, and don't know how expensive querying an object property is from C). Greg From owner-scwm-discuss@mit.edu Fri Jul 24 12:17:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29552 for scwm-discuss-outgoing; Fri, 24 Jul 1998 12:17:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29549 for ; Fri, 24 Jul 1998 12:17:20 -0400 Received: from [206.1.51.15] by MIT.EDU with SMTP id AA29064; Fri, 24 Jul 98 12:15:44 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA26023; Fri, 24 Jul 1998 12:14:11 -0400 (EDT) Message-Id: <199807241614.MAA26023@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Maciej Stachowiak , scwm-discuss@mit.edu Subject: gnats (was Re: documentation) In-Reply-To: Your message of "24 Jul 1998 08:38:56 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 24 Jul 1998 12:14:11 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > The NetBSD project benefits a lot from having a gnats database set up > > for accepting trouble reports, documentation updates, etc. in such a > > way that they are not lost. I strongly suggest that setting up gnats > > for scwm would be a good way of making it easy for people (even people > > not on the mailing list!) to send in fixes. > > I'm in favor of this, too, and would've suggested it sooner had I any > experience using gnats. Perry, if we do choose to use gnats, could you > lend us your expertise? I don't have that much expertise, but sure, no prob. Perry From owner-scwm-discuss@mit.edu Sat Jul 25 13:45:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA04916 for scwm-discuss-outgoing; Sat, 25 Jul 1998 13:45:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA04913 for ; Sat, 25 Jul 1998 13:45:51 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezow09707; Sat, 25 Jul 1998 17:44:11 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA04217; Sat, 25 Jul 1998 12:45:57 -0400 To: Maciej Stachowiak Subject: crash Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 25 Jul 1998 12:45:57 -0400 Message-ID: Lines: 11 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I got a crash: scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. I don't think I can reproduce it though. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. The difference between genius and stupidity is that genius has its limits. From owner-scwm-discuss@mit.edu Sat Jul 25 14:29:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05145 for scwm-discuss-outgoing; Sat, 25 Jul 1998 14:29:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA05142 for ; Sat, 25 Jul 1998 14:29:02 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezoz17418; Sat, 25 Jul 1998 18:27:20 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id OAA00993; Sat, 25 Jul 1998 14:26:53 -0400 To: Maciej Stachowiak Subject: crash in fvwm2 module Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 25 Jul 1998 14:26:53 -0400 Message-ID: Lines: 108 Sender: owner-scwm-discuss@mit.edu Precedence: bulk scwm starts fine, then I evaluate (register-fvwm2-module-config "FvwmPager" "*FvwmPagerBack grey76" "*FvwmPagerFore black" "*FvwmPagerHilight navyblue" "*FvwmPagerFont none" "*FvwmPagerDeskTopScale 40" "*FvwmPagerLabel 0 Top" ;; "*FvwmPagerLabel 1 Bottom" "*FvwmPagerSmallFont 5x8") (define fvwm2-pager (run-fvwm2-module "FvwmPager" '("0" "0"))) and get a crash: scwm: Unknown # object: #\< Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2* [# (# 0 # ...)] 3* (let ((to-module-write #) (mask #)) (if (logior type mask) (send-mini-icon-packet window to-module-write))) 4 (if (logior type mask) (send-mini-icon-packet window to-module-write)) ... 5 (let* ((props #) (body #)) (fvwm2-module-send-packet M_MINI_ICON body ...)) 6* [string-append ... 7* [longs->string 16777225 33554679 ...] 8 [apply # ... 9* [map #string (int)> (16777225 33554679 0 ...)] 10* [long->string (width . 16)] 11* (let* ((s #) (intx #)) (string-set! s 3 ...) ...) 12* (if (> int 2147483647) (- int 4294967296) ...) 13* [> (width . 16) 2147483647] ERROR: In procedure > in expression (> int 2147483647): ERROR: Wrong type argument in position 2: (width . 16) Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2* [# (# 0 # ...)] 3* (let ((to-module-write #) (mask #)) (if (logior type mask) (send-mini-icon-packet window to-module-write))) 4 (if (logior type mask) (send-mini-icon-packet window to-module-write)) ... 5 (let* ((props #) (body #)) (fvwm2-module-send-packet M_MINI_ICON body ...)) 6* [string-append ... 7* [longs->string 16777225 33554679 ...] 8 [apply # ... 9* [map #string (int)> (16777225 33554679 0 ...)] 10* [long->string (width . 16)] 11* (let* ((s #) (intx #)) (string-set! s 3 ...) ...) 12* (if (> int 2147483647) (- int 4294967296) ...) 13* [> (width . 16) 2147483647] ERROR: In procedure > in expression (> int 2147483647): ERROR: Wrong type argument in position 2: (width . 16) Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2* [# (# 0 # ...)] 3* (let ((to-module-write #) (mask #)) (if (logior type mask) (send-mini-icon-packet window to-module-write))) 4 (if (logior type mask) (send-mini-icon-packet window to-module-write)) ... 5 (let* ((props #) (body #)) (fvwm2-module-send-packet M_MINI_ICON body ...)) 6* [string-append ... 7* [longs->string 20971522 33554692 ...] 8 [apply # ... 9* [map #string (int)> (20971522 33554692 0 ...)] 10* [long->string (width . 16)] 11* (let* ((s #) (intx #)) (string-set! s 3 ...) ...) 12* (if (> int 2147483647) (- int 4294967296) ...) 13* [> (width . 16) 2147483647] ERROR: In procedure > in expression (> int 2147483647): ERROR: Wrong type argument in position 2: (width . 16) Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2* [# (# 0 # ...)] 3* (let ((to-module-write #) (mask #)) (if (logior type mask) (send-mini-icon-packet window to-module-write))) 4 (if (logior type mask) (send-mini-icon-packet window to-module-write)) ... 5 (let* ((props #) (body #)) (fvwm2-module-send-packet M_MINI_ICON body ...)) 6* [string-append ... 7* [longs->string 20971522 33554692 ...] 8 [apply # ... 9* [map #string (int)> (20971522 33554692 0 ...)] 10* [long->string (width . 14)] 11* (let* ((s #) (intx #)) (string-set! s 3 ...) ...) 12* (if (> int 2147483647) (- int 4294967296) ...) 13* [> (width . 14) 2147483647] ERROR: In procedure > in expression (> int 2147483647): ERROR: Wrong type argument in position 2: (width . 14) Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2*Killed -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. In every non-trivial program there is at least one bug. From owner-scwm-discuss@mit.edu Sat Jul 25 15:13:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05370 for scwm-discuss-outgoing; Sat, 25 Jul 1998 15:13:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA05367 for ; Sat, 25 Jul 1998 15:13:10 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA08767; Sat, 25 Jul 98 15:11:50 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA04211; Sat, 25 Jul 1998 12:11:27 -0700 (PDT) To: Maciej Stachowiak Subject: Re: crash References: From: Greg Badros Date: 25 Jul 1998 12:11:27 -0700 In-Reply-To: Sam Steingold's message of "25 Jul 1998 12:45:57 -0400" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > I got a crash: > > scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. > > I don't think I can reproduce it though. Which version? 0.7a or a snapshot? Do you have a backtrace? Thanks, Greg From owner-scwm-discuss@mit.edu Sat Jul 25 15:49:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05565 for scwm-discuss-outgoing; Sat, 25 Jul 1998 15:49:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA05562 for ; Sat, 25 Jul 1998 15:49:43 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA09489; Sat, 25 Jul 98 15:47:50 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezpf20724; Sat, 25 Jul 1998 19:47:57 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA01123; Sat, 25 Jul 1998 15:47:42 -0400 To: Greg Badros Cc: Maciej Stachowiak Subject: Re: crash References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "25 Jul 1998 12:11:27 -0700" Date: 25 Jul 1998 15:47:40 -0400 Message-Id: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 25 Jul 1998 12:11:27 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: crash": >> Sam Steingold writes: >> >> > I got a crash: >> > >> > scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. >> > >> > I don't think I can reproduce it though. >> >> Which version? 0.7a or a snapshot? snapshot. >> Do you have a backtrace? unfortunately, no. if I did, I would have posted it. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Apathy Club meeting this Friday. If you want to come, you're not invited. From owner-scwm-discuss@mit.edu Sat Jul 25 15:52:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05583 for scwm-discuss-outgoing; Sat, 25 Jul 1998 15:52:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA05580 for ; Sat, 25 Jul 1998 15:52:34 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11737; Sat, 25 Jul 98 15:51:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA04247; Sat, 25 Jul 1998 12:50:44 -0700 (PDT) To: Maciej Stachowiak Subject: Re: crash References: From: Greg Badros Date: 25 Jul 1998 12:50:43 -0700 In-Reply-To: Sam Steingold's message of "25 Jul 1998 15:47:40 -0400" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 25 Jul 1998 12:11:27 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: crash": > >> Sam Steingold writes: > >> > >> > I got a crash: > >> > > >> > scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. > >> > > >> > I don't think I can reproduce it though. > >> > >> Which version? 0.7a or a snapshot? > snapshot. I'm messing with the interactive move and resize code quite a bit these days, so there could be some bugs in more recent snapshots... I've never had that assertion fail yet, though. Please do update me if it happens again. BTW, we now have opaque resizing. I'm not committing my changes until I have written a more general rubberbanding technique that works for both interactive moves and resizes (the old code was a disaster!) Greg From owner-scwm-discuss@mit.edu Sat Jul 25 16:17:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05804 for scwm-discuss-outgoing; Sat, 25 Jul 1998 16:17:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05801 for ; Sat, 25 Jul 1998 16:17:10 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA14578; Sat, 25 Jul 98 16:15:51 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezph21896; Sat, 25 Jul 1998 20:15:26 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id QAA01345; Sat, 25 Jul 1998 16:14:42 -0400 To: Greg Badros Cc: Maciej Stachowiak Subject: Re: crash References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "25 Jul 1998 12:50:43 -0700" Date: 25 Jul 1998 16:14:41 -0400 Message-Id: Lines: 123 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 25 Jul 1998 12:50:43 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: crash": >> Sam Steingold writes: >> > >> > I got a crash: >> > >> > scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. >> > >> > I don't think I can reproduce it though. I can - I am getting this all the time! >> > >> Which version? 0.7a or a snapshot? >> > snapshot. >> BTW, we now have opaque resizing. I'm not committing my changes until I >> have written a more general rubberbanding technique that works for both >> interactive moves and resizes (the old code was a disaster!) Cool!!! #0 0x4017e781 in __kill () #1 0x4017e5af in raise (sig=6) at ../sysdeps/posix/raise.c:27 #2 0x4017f7bf in abort () at ../sysdeps/generic/abort.c:83 #3 0x401793d6 in __assert_fail (assertion=0x806b7f7 "psw->frame == w", file=0x806b7f0 "move.c", line=528, function=0x806b7e0 "InteractiveMove") at assert.c:54 #4 0x80602a6 in InteractiveMove (w=33554940, psw=0x80c9a40, FinalX=0xbffff38c, FinalY=0xbffff388, eventp=0xbffff390) at move.c:528 #5 0x80678d9 in interactive_move (win=9588) at window.c:2000 #6 0x400dddde in scm_deval (x=1076590792, env=1076604848) at eval.c:2559 #7 0x400dea81 in scm_dapply (proc=1076587832, arg1=10612, args=1076604848) at eval.c:3017 #8 0x400d99e4 in scm_apply (proc=1076587832, arg1=10612, args=10612) at eval.c:2837 #9 0x8051fe1 in scwm_body_apply (body_data=0xbffff69c) at callbacks.c:80 #10 0x40109f65 in scm_internal_lazy_catch (tag=9076, body=0x8051fcc , body_data=0xbffff69c, handler=0x8051fe4 , handler_data=0x0) at throw.c:328 #11 0x805203a in cwssdr_body (data=0xbffff670) at callbacks.c:110 #12 0x40109dcc in scm_internal_catch (tag=9076, body=0x8052020 , body_data=0xbffff670, handler=0x401006b4 , handler_data=0xbffff648) at throw.c:236 #13 0x40100818 in scm_internal_cwdr (body=0x8052020 , body_data=0xbffff670, handler=0x8051f08 , handler_data=0x806a8df, stack_start=0xbffff698) at root.c:300 #14 0x805206c in scm_internal_stack_cwdr (body=0x8051fcc , body_data=0xbffff69c, handler=0x8051f08 , handler_data=0x806a8df, stack_item=0xbffff698) at callbacks.c:125 #15 0x805209e in scwm_safe_apply (proc=1076587832, args=10612) at callbacks.c:144 #16 0x80520e0 in scwm_safe_call0 (thunk=1076587832) at callbacks.c:167 #17 0x805792f in HandleButtonPress () at events.c:1235 #18 0x8056279 in DispatchEvent () at events.c:183 #19 0x80562aa in HandleEvents () at events.c:205 #20 0x8063300 in scwm_main (argc=3, argv=0xbffffbf0) at scwm.c:836 #21 0x8062869 in scwm_gh_launch_pad (closure=0x80628a0, argc=3, argv=0xbffffbf0) at scwm.c:380 #22 0x400e859c in invoke_main_func (body_data=0xbffffb9c) at init.c:506 #23 0x40109dcc in scm_internal_catch (tag=9076, body=0x400e857c , body_data=0xbffffb9c, handler=0x4010a22c , handler_data=0x0) at throw.c:236 ---Type to continue, or q to quit--- #24 0x400e8553 in scm_boot_guile_1 (base=0xbffffb98, closure=0xbffffb9c) at init.c:482 #25 0x400e8309 in scm_boot_guile (argc=3, argv=0xbffffbf0, main_func=0x806284c , closure=0x80628a0) at init.c:347 #26 0x8062886 in scwm_gh_enter (argc=3, argv=0xbffffbf0, c_main_prog=0x80628a0 ) at scwm.c:387 #27 0x806289b in main (argc=3, argv=0xbffffbf0) at scwm.c:399 f 4 (gdb) p *psw $1 = {next = 0x80c7f88, prev = 0x80c6790, w = 50332019, old_bw = 0, frame = 33554923, Parent = 33554924, title_w = 33554929, sides = {33554936, 33554937, 33554938, 33554939}, corners = {33554925, 33554926, 33554927, 33554928}, nr_left_buttons = 3, nr_right_buttons = 3, left_w = {33554934, 33554932, 33554930, 0, 0}, right_w = {33554935, 33554933, 33554931, 0, 0}, fl = 0x80a0418, icon_w = 33554940, icon_pixmap_w = 0, wShaped = 0, frame_x = 4, frame_y = 60, frame_width = 620, frame_height = 648, pswci = 0x0, boundary_width = 3, corner_width = 19, bw = 1, title_x = 51, title_y = 3, title_height = 16, title_width = 519, icon_x_loc = 551, icon_xl_loc = 522, icon_y_loc = 1, icon_w_width = 75, icon_w_height = 18, icon_t_width = 69, icon_p_height = 0, icon_p_width = 17, name = 0x80a8818 "*inferior-lisp*", icon_name = 0x80908d0 "*inferior-lisp*", attr = {x = 0, y = 0, width = 614, height = 626, border_width = 0, depth = 16, visual = 0x808d1d8, root = 38, class = 1, bit_gravity = 1, win_gravity = 1, backing_store = 0, backing_planes = 4294967295, backing_pixel = 0, save_under = 0, colormap = 35, map_installed = 1, map_state = 0, all_event_masks = 14909565, your_event_mask = 14876720, do_not_propagate_mask = 12, override_redirect = 0, screen = 0x808d180}, hints = {flags = 604, x = 6, y = 78, width = 614, height = 626, min_width = 14, min_height = 26, max_width = 32767, max_height = 32767, width_inc = 6, height_inc = 10, min_aspect = {x = 2, y = 33554837}, max_aspect = {x = 80, y = 8}, base_width = 14, base_height = 26, win_gravity = 1}, wmhints = 0x80c9d30, classhint = { res_name = 0x80c9ce0 "emacs", res_class = 0x80c9cf0 "Emacs"}, Desk = 0, StartDesk = 0, FocusDesk = 0, DeIconifyDesk = 0, transientfor = 0, fStartIconic = 0, fOnTop = 0, fSticky = 0, fWindowListSkip = 0, fSuppressIcon = 0, fNoIconTitle = 0, fLenience = 0, fStickyIcon = 1, fCirculateSkip = 0, fCirculateSkipIcon = 0, fClickToFocus = 0, fSloppyFocus = 1, fShowOnMap = 0, fBorder = 1, fTitle = 1, fMapped = 0, fIconified = 1, fTransient = 0, fRaised = 1, fVisible = 0, fIconOurs = 1, fPixmapOurs = 0, fShapedIcon = 0, fMaximized = 0, fDoesWmTakeFocus = 1, fDoesWmDeleteWindow = 1, fIconMoved = 0, fIconUnmapped = 0, fMapPending = 0, fHintOverride = 0, fMWMButtons = 0, fMWMBorders = 1, fMWMFunctions = 1, fMWMDecor = 1, fDecorateTransient = 1, fWindowShaded = 0, fStartsOnDesk = 0, fRandomPlace = 1, fSmartPlace = 1, fOLDecorHint = 0, fNoPPosition = 0, fForceIcon = 0, mini_icon_image = 1076496960, icon_req_image = 8564, icon_image = 8564, orig_x = 4, orig_y = 60, orig_wd = 620, orig_ht = 648, xdiff = -1, ydiff = -1, mwm_hints = 0x0, ol_hints = 15, functions = 62, cmap_windows = 0x0, number_cmap_windows = 0, ReliefColor = 1076642736, ShadowColor = 1076642784, TextColor = 1076118056, BackColor = 1076642832, buttons = 0, IconBox = {500, 1, 1024, 201}, schwin = 1076303600} (gdb) (gdb) p w $2 = 33554940 (gdb) p *w Cannot access memory at address 0x20001fc. (gdb) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Profanity is the one language all programmers know best. From owner-scwm-discuss@mit.edu Sat Jul 25 16:43:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05963 for scwm-discuss-outgoing; Sat, 25 Jul 1998 16:43:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05960 for ; Sat, 25 Jul 1998 16:43:27 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14403; Sat, 25 Jul 98 16:41:38 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA04309; Sat, 25 Jul 1998 13:41:44 -0700 (PDT) To: Maciej Stachowiak Subject: Re: crash References: From: Greg Badros Date: 25 Jul 1998 13:41:43 -0700 In-Reply-To: Sam Steingold's message of "25 Jul 1998 16:14:41 -0400" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 25 Jul 1998 12:50:43 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: crash": > >> Sam Steingold writes: > >> > >> > I got a crash: > >> > >> > scwm: move.c:505: InteractiveMove: Assertion `psw->frame == w' failed. > >> > >> > I don't think I can reproduce it though. > I can - I am getting this all the time! Hmmm.. > >> > >> Which version? 0.7a or a snapshot? > >> > snapshot. Which night's snapshot? Is the application an Emacs window? How are you invoking InteractiveMove? I'll add some more debug code when I check in so if it happens again we'll get a better error message. BTW, window IDs (e.g., w, in the gdb interaction I snipped) are not pointers, so `print *w' should fail, as it did. My guess is you were moving an icon: try changing the assert to: assert(w == psw->frame || w == icon_w || w == icon_pixmap_w); I think the assert was in error (I need to change my test configuration to use icons some, since I'm prone to introducing bugs there as I don't use them in my primary configuration). Greg From owner-scwm-discuss@mit.edu Sun Jul 26 00:56:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA08812 for scwm-discuss-outgoing; Sun, 26 Jul 1998 00:56:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA08809 for ; Sun, 26 Jul 1998 00:56:35 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12575; Sun, 26 Jul 98 00:54:42 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA27542; Sat, 25 Jul 1998 21:54:49 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Some new features.... From: Greg Badros Date: 25 Jul 1998 21:54:48 -0700 Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Tonight's snapshot will have opaque resizing on by default. In fact, it is the only option for a little while due to some major ripping out of old code. I intend to restore rubberbanding resize (in a much cleaner implementation, of course) soon. It's actually harder to do rubberbanding than opaque because of the lack of an overlay plane on a generic X server. Another nifty new feature is a generalization of the size and position display window. Now you can use `set-message-window-attributes' to set the font and colors for the message window (which is now centered instead of at 0,0) [it used to get its font and colors from some of the menu settings, but it was pretty arbitrary how it worked]. Also, the message window is so named because it can display a message for the newly-implemented primitive `select-window-interactively'; e.g. (select-window-interactively "Select a Window") will return the scheme object for the clicked on window, and while the user selects the window, the message "Select a Window is displayed". (Especially useful when you're programmatically prompting for several windows -- e.g., I use it in scheme/tests/constraints.scm; see scheme/tests/select-window.scm, also). As always, let us know about problems, and see the latest BUG-REPORTING file for a list of things that are helpful to let us know when you come across a non-obvious bug. Thanks! Greg From owner-scwm-discuss@mit.edu Sun Jul 26 01:02:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA08967 for scwm-discuss-outgoing; Sun, 26 Jul 1998 01:02:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA08929 for ; Sun, 26 Jul 1998 01:02:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12763; Sun, 26 Jul 98 00:59:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA27545; Sat, 25 Jul 1998 21:59:55 -0700 (PDT) To: scwm-discuss@mit.edu Subject: A warning, too... From: Greg Badros Date: 25 Jul 1998 21:59:54 -0700 Message-Id: Lines: 4 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Tonight's snapshot probably breaks some of the virtual desktop stuff. It'll be fixed by the next snapshot, hopefully. Greg From owner-scwm-discuss@mit.edu Mon Jul 27 14:53:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA21978 for scwm-discuss-outgoing; Mon, 27 Jul 1998 14:53:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA21975 for ; Mon, 27 Jul 1998 14:53:07 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezwl27985; Mon, 27 Jul 1998 18:51:04 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id LAA05326; Mon, 27 Jul 1998 11:09:29 -0400 To: Maciej Stachowiak Subject: icon move --> window move Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 27 Jul 1998 11:09:28 -0400 Message-ID: Lines: 11 Sender: owner-scwm-discuss@mit.edu Precedence: bulk the current cvs tree: when I move an icon and then de-iconify it, it turns out that the window has moved. is this intended?! how do I turn this off? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Sinners can repent, but stupid is forever. From owner-scwm-discuss@mit.edu Mon Jul 27 15:20:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA22361 for scwm-discuss-outgoing; Mon, 27 Jul 1998 15:20:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA22358 for ; Mon, 27 Jul 1998 15:20:47 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19664; Mon, 27 Jul 98 15:19:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA02195; Mon, 27 Jul 1998 12:18:42 -0700 (PDT) To: Maciej Stachowiak Subject: Re: icon move --> window move References: From: Greg Badros Date: 27 Jul 1998 12:18:41 -0700 In-Reply-To: Sam Steingold's message of "27 Jul 1998 11:09:28 -0400" Message-Id: Lines: 16 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > the current cvs tree: when I move an icon and then de-iconify it, it > turns out that the window has moved. > > is this intended?! Nope. > how do I turn this off? You wait for my bugfix. :-) Thanks for the report. Greg From owner-scwm-discuss@mit.edu Mon Jul 27 19:48:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA25033 for scwm-discuss-outgoing; Mon, 27 Jul 1998 19:48:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id TAA25030 for ; Mon, 27 Jul 1998 19:48:10 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezxf08121; Mon, 27 Jul 1998 23:46:02 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id TAA06734; Mon, 27 Jul 1998 19:18:17 -0400 To: Maciej Stachowiak Subject: opaque resize Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 27 Jul 1998 19:18:16 -0400 Message-ID: Lines: 9 Sender: owner-scwm-discuss@mit.edu Precedence: bulk opaque resize is way cool, but it displays the current size in pixels, not characters, which is important for emacs and xterm. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);} From owner-scwm-discuss@mit.edu Mon Jul 27 21:43:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA25697 for scwm-discuss-outgoing; Mon, 27 Jul 1998 21:43:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA25694 for ; Mon, 27 Jul 1998 21:43:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AB03801; Mon, 27 Jul 98 21:41:01 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA02980; Mon, 27 Jul 1998 18:41:04 -0700 (PDT) To: Maciej Stachowiak Subject: Re: opaque resize References: From: Greg Badros Date: 27 Jul 1998 18:41:04 -0700 In-Reply-To: Sam Steingold's message of "27 Jul 1998 19:18:16 -0400" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > opaque resize is way cool, but it displays the current size in pixels, > not characters, which is important for emacs and xterm. I'll look into it... Greg From owner-scwm-discuss@mit.edu Tue Jul 28 11:58:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32061 for scwm-discuss-outgoing; Tue, 28 Jul 1998 11:58:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA32058 for ; Tue, 28 Jul 1998 11:58:06 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA02108; Tue, 28 Jul 98 11:55:45 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQezzr03731; Tue, 28 Jul 1998 15:55:53 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id LAA10438; Tue, 28 Jul 1998 11:55:20 -0400 To: scwm-discuss@mit.edu Subject: make-decor Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 28 Jul 1998 11:55:19 -0400 Message-Id: Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk current CVS (make-decor "std") ==> Backtrace: 0* [make-decor "std"] ERROR: In procedure make-decor in expression (make-decor "std"): ERROR: Wrong type argument in position 1: (else wl) the only place where (else wl) appears is winlist.scm: 1.1 (mstachow 21-Sep-97): (define (rotate-around w wl) 1.1 (mstachow 21-Sep-97): (append (cond 1.1 (mstachow 21-Sep-97): ((memq w wl) => cdr) 1.1 (mstachow 21-Sep-97): (else wl)) 1.1 (mstachow 21-Sep-97): (cond 1.1 (mstachow 21-Sep-97): ((memq w (reverse wl)) 1.1 (mstachow 21-Sep-97): => (lambda (x) 1.1 (mstachow 21-Sep-97): (reverse (cdr x)))) 1.1 (mstachow 21-Sep-97): (else '())))) (which is obviously beyond suspicion) I am lost! -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. You think Oedipus had a problem -- Adam was Eve's mother. From owner-scwm-discuss@mit.edu Tue Jul 28 15:05:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03287 for scwm-discuss-outgoing; Tue, 28 Jul 1998 15:05:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA03284 for ; Tue, 28 Jul 1998 15:05:15 -0400 Received: by tis.bellhow.com; id PAA04045; Tue, 28 Jul 1998 15:01:28 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma001658; Tue, 28 Jul 98 12:05:08 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA17041 for ; Tue, 28 Jul 1998 12:05:07 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: 7/28 snapshot make-decor weirdness Date: Tue, 28 Jul 1998 16:01:21 GMT Organization: Bell & Howell PSC Message-ID: <35bdf3e1.413279814@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id PAA03285 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Typing ^J on (make-decor) in a scwm buffer: (make-decor) Backtrace: 0* [make-decor] ERROR: In procedure make-decor in expression (make-decor): ERROR: Wrong type argument in position 1: # Also: scwmexec '(make-decor "foo")' Backtrace: 0* [make-decor "foo"] ERROR: In procedure make-decor in expression (make-decor "foo"): ERROR: Wrong type argument in position 1: 4278190080 Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Jul 28 23:53:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA07052 for scwm-discuss-outgoing; Tue, 28 Jul 1998 23:53:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA07047; Tue, 28 Jul 1998 23:53:43 -0400 Message-Id: <199807290353.XAA07047@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Anonymous CVS available Date: Tue, 28 Jul 1998 23:53:43 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Anonymous CVS for scwm is available. This service is offered provisionally and may go away if it ends up loading the machine too much. Instructions (which should appear on the web site soon) follow: cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs login (type `anoncvs' as the password at the `CVS password:' prompt) cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs co scwm You will now get a checked out scwm working directory. Certain autogenerated files will not be present in the repository version. Read the HACKING file for a list of tools you will need to generate them (note to scwm-dev people: maybe in light of anoncvs we should start keeping these in CVS again?). You will need those files to be able to configure and build out of CVS. configuring with --enable-maintainer-mode is strongly reccomended so that if the master files get updated, the autogenerated ones will all be rebuilt on a `make'. To later update to the repository sources, you can do `cvs update' in the checked-out scwm directory. Other CVS operations are beyond the scope of these instructions. The repository for anonymous access only updates from the master repository only every half hour. This may change in the future. - Maciej From owner-scwm-discuss@mit.edu Wed Jul 29 15:23:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA12174 for scwm-discuss-outgoing; Wed, 29 Jul 1998 15:23:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA12171 for ; Wed, 29 Jul 1998 15:23:45 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28651; Wed, 29 Jul 98 15:21:10 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA07719; Wed, 29 Jul 1998 12:21:16 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: make-decor References: From: Greg Badros Date: 29 Jul 1998 12:21:16 -0700 In-Reply-To: Sam Steingold's message of "28 Jul 1998 11:55:19 -0400" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > current CVS > > (make-decor "std") > ==> > > Backtrace: > 0* [make-decor "std"] > > ERROR: In procedure make-decor in expression (make-decor "std"): > ERROR: Wrong type argument in position 1: (else wl) > > the only place where (else wl) appears is > > > > (which is obviously beyond suspicion) > > I am lost! So was I for a bit. Thanks for the bug report-- I've fixed this in my working copy, soon to be committed. The problem was in the mistaken garbage collection of str_fixed, an internal SCM string object that contains the name of the fixed font. The reason for the completely bogus error message is that the make-decor primitive calls the set-window-font! primitive and that is the primitive that actually catches the type error. Since the nesting of the procedures happened in C code, it wasn't available in the backtrace, and the "(else wl)" was just a completely incorrect cue, since the cell where str_fixed once was stored now contained something unrelated. Incidentally, I've been correcting many calls to scm_protect_object to scm_permanent_object when the latter is the actual intention. Greg From owner-scwm-discuss@mit.edu Wed Jul 29 15:53:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA12676 for scwm-discuss-outgoing; Wed, 29 Jul 1998 15:53:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA12673 for ; Wed, 29 Jul 1998 15:53:37 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA22282; Wed, 29 Jul 98 15:51:34 EDT Received: from 192.168.1.1 (root@INS35.tokyo-ap4.dti.ne.jp [210.159.155.35]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id EAA25530 for ; Thu, 30 Jul 1998 04:51:06 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id EAA22962 for ; Thu, 30 Jul 1998 04:51:04 +0900 Message-Id: <199807291951.EAA22962@192.168.1.1> To: scwm-discuss@mit.edu Subject: fix for I18N Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Thu, 30 Jul 1998 04:51:04 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm sorry for not trying newer snapshots. #Recently, scwm is changing too fast ;) I tried snapshot 19980729, found a few problems. These problem seems to occur when you configured with --enable-multibyte. I have not tested these fixes long enough, but it seems working good. BTW, should I send sample scwmrc for multibyte example? -- Eiichiro ITANI diff -Ncr scwm.orig/font.c scwm/font.c *** scwm.orig/font.c Thu Jul 30 04:15:25 1998 --- scwm/font.c Thu Jul 30 04:15:47 1998 *************** *** 112,117 **** --- 112,118 ---- int missings,loadedfonts; int height = 0, ascent = 0; XFontStruct **xfss; + int i; #else XFontStruct *xfs; #endif *************** *** 146,152 **** return answer; } ! fn = strdup(XFIXEDFONTSET); if (NULL == fn) goto allocation; fontset = XCreateFontSet(dpy,fn,&list_names,&missings,&defstrreturn); --- 147,153 ---- return answer; } ! fn = strdup(XFIXEDFONTNAME); if (NULL == fn) goto allocation; fontset = XCreateFontSet(dpy,fn,&list_names,&missings,&defstrreturn); diff -Ncr scwm.orig/move.c scwm/move.c *** scwm.orig/move.c Thu Jul 30 04:15:25 1998 --- scwm/move.c Thu Jul 30 04:15:47 1998 *************** *** 435,446 **** textwidth, textheight, False); } ! NewFontAndColor(gcMsg,XFONT(Scr.msg_window_font)->fid, XCOLOR(Scr.msg_window_fg), XCOLOR(Scr.msg_window_bg)); - #ifdef I18N XmbDrawString(dpy, Scr.MsgWindow, XFONT(Scr.msg_window_font), /* ) */ #else XDrawString(dpy, Scr.MsgWindow, #endif gcMsg, SIZE_HINDENT, FONTY(Scr.msg_window_font) + SIZE_VINDENT, --- 435,449 ---- textwidth, textheight, False); } ! #ifdef I18N ! NewFontAndColor(gcMsg,XFONTID(Scr.msg_window_font), XCOLOR(Scr.msg_window_fg), XCOLOR(Scr.msg_window_bg)); XmbDrawString(dpy, Scr.MsgWindow, XFONT(Scr.msg_window_font), /* ) */ #else + NewFontAndColor(gcMsg,XFONT(Scr.msg_window_font)->fid, + XCOLOR(Scr.msg_window_fg), XCOLOR(Scr.msg_window_bg)); + XDrawString(dpy, Scr.MsgWindow, #endif gcMsg, SIZE_HINDENT, FONTY(Scr.msg_window_font) + SIZE_VINDENT, diff -Ncr scwm.orig/xmisc.c scwm/xmisc.c *** scwm.orig/xmisc.c Thu Jul 30 04:15:25 1998 --- scwm/xmisc.c Thu Jul 30 04:15:47 1998 *************** *** 17,23 **** #include "xmisc.h" #include "screen.h" #include "image.h" ! Window JunkChild, JunkRoot; unsigned int JunkWidth, JunkHeight, JunkBW, JunkDepth, JunkMask; --- 17,23 ---- #include "xmisc.h" #include "screen.h" #include "image.h" ! #include "font.h" Window JunkChild, JunkRoot; unsigned int JunkWidth, JunkHeight, JunkBW, JunkDepth, JunkMask; *************** *** 281,290 **** int ComputeXTextWidth(XFONT_TYPE *pxfs, const char *sz, int cch) { if (cch < 0) cch = strlen(sz); #ifdef I18N - XRectangle dummy,log_ret; XmbTextExtents(XFONT(Scr.msg_window_font), sz, cch, &dummy, &log_ret); return log_ret.width; #else --- 281,293 ---- int ComputeXTextWidth(XFONT_TYPE *pxfs, const char *sz, int cch) { + #ifdef I18N + XRectangle dummy,log_ret; + #endif + if (cch < 0) cch = strlen(sz); #ifdef I18N XmbTextExtents(XFONT(Scr.msg_window_font), sz, cch, &dummy, &log_ret); return log_ret.width; #else From owner-scwm-discuss@mit.edu Wed Jul 29 17:44:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13495 for scwm-discuss-outgoing; Wed, 29 Jul 1998 17:44:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA13492 for ; Wed, 29 Jul 1998 17:44:37 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03678; Wed, 29 Jul 98 17:42:01 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07952; Wed, 29 Jul 1998 14:42:05 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> From: Greg Badros Date: 29 Jul 1998 14:42:05 -0700 In-Reply-To: ITANI Eiichiro's message of "Thu, 30 Jul 1998 04:51:04 +0900" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > I'm sorry for not trying newer snapshots. > #Recently, scwm is changing too fast ;) :-) > > I tried snapshot 19980729, found a few problems. These problem seems to > occur when you configured with --enable-multibyte. > > I have not tested these fixes long enough, but it seems working good. > > BTW, should I send sample scwmrc for multibyte example? Thanks for the patch. A couple of general comments on patches for scwm -- please try to create patches that do not put #ifdef-s throughout regular code. I spent an afternoon partially cleaning up the original I18N patch because it interspersed #ifdefs far too frequently. It's always better to abstract out the useful functionality and condition only the new abstraction using a few #ifdefs, instead of just blinding throwing ifdefs everywhere two code paths diverge. For example, I added a new function ComputeXTextWidth in xmisc.c that permits client code to use that same function independent of the I18N conditional compilation flag. Only that function then has an ifdef in it. That said, thanks again for the patch, and I'll make the appropriate changes soon so that you can test them in the next snapshot. Your contribution is incredibly helpful -- thanks! Greg From owner-scwm-discuss@mit.edu Wed Jul 29 18:31:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13819 for scwm-discuss-outgoing; Wed, 29 Jul 1998 18:31:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA13816 for ; Wed, 29 Jul 1998 18:31:22 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA01162; Wed, 29 Jul 98 18:29:17 EDT Received: from 192.168.1.1 (root@INS35.tokyo-ap4.dti.ne.jp [210.159.155.35]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id HAA01968 for ; Thu, 30 Jul 1998 07:28:50 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id HAA25020 for ; Thu, 30 Jul 1998 07:28:47 +0900 Message-Id: <199807292228.HAA25020@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: Greg Badros's message of "29 Jul 1998 14:42:05 -0700" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Thu, 30 Jul 1998 07:28:47 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Thanks for the patch. A couple of general comments on patches for scwm > -- please try to create patches that do not put #ifdef-s throughout > regular code. I spent an afternoon partially cleaning up the original > I18N patch because it interspersed #ifdefs far too frequently. I'm sorry. It's nearly two months ago, when I first wrote I18N patch. Two months ago is almost like age of dinosaurus, isn't it? :-) > It's always better to abstract out the useful functionality and > condition only the new abstraction using a few #ifdefs, instead of just > blinding throwing ifdefs everywhere two code paths diverge. I'll keep it in my mind. > That said, thanks again for the patch, and I'll make the appropriate > changes soon so that you can test them in the next snapshot. Your > contribution is incredibly helpful -- thanks! Thank you. -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Wed Jul 29 20:45:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA14836 for scwm-discuss-outgoing; Wed, 29 Jul 1998 20:45:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA14833 for ; Wed, 29 Jul 1998 20:45:16 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20119; Wed, 29 Jul 98 20:43:12 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA08161; Wed, 29 Jul 1998 17:42:44 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> <199807292228.HAA25020@192.168.1.1> From: Greg Badros Date: 29 Jul 1998 17:42:43 -0700 In-Reply-To: ITANI Eiichiro's message of "Thu, 30 Jul 1998 07:28:47 +0900" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > Greg Badros writes: > > > Thanks for the patch. A couple of general comments on patches for scwm > > -- please try to create patches that do not put #ifdef-s throughout > > regular code. I spent an afternoon partially cleaning up the original > > I18N patch because it interspersed #ifdefs far too frequently. > > I'm sorry. Please don't apologize... you did us a favor-- I just wanted to point out how it could be an even bigger favor (I'm greedy! :-) ). > Tonight's snapshot will have my version of the I18N changes -- I look forward to knowing if they worked for you. > Thank you. Thank *you*. Greg From owner-scwm-discuss@mit.edu Wed Jul 29 23:49:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA17001 for scwm-discuss-outgoing; Wed, 29 Jul 1998 23:49:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA16998 for ; Wed, 29 Jul 1998 23:49:04 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19521; Wed, 29 Jul 98 23:46:25 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA08530; Wed, 29 Jul 1998 20:43:59 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Wierd decorations References: <35b7d631.429129014@mailhost> From: Greg Badros Date: 29 Jul 1998 20:43:59 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Tue, 21 Jul 1998 18:00:33 GMT" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > I have noticed lately (7/20, 7/21) that the window frame corners are > looking weird. I don't exactly know how to describe it. How's this: > The inner shading of the corners is not be drawn or is being drawn in > the wrong place and being overwritten by buttons 1 and 2. I think I squashed this bug today. Check tomorrow's snapshot. Thanks again for pointing out the problem. Please mention other drawing anomalies as you find them. The code is incredibly hard to test all the cases of, so be sure to post the explicit style that you use to create the faulty decoration. Greg From owner-scwm-discuss@mit.edu Wed Jul 29 23:53:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA17063 for scwm-discuss-outgoing; Wed, 29 Jul 1998 23:53:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA17060 for ; Wed, 29 Jul 1998 23:53:53 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA13698; Wed, 29 Jul 98 23:51:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA08533; Wed, 29 Jul 1998 20:51:19 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: plain-border trouble References: From: Greg Badros Date: 29 Jul 1998 20:51:19 -0700 In-Reply-To: Terje Sannum's message of "23 Jul 1998 14:55:05 +0200" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > This does not work as I expected. The top resize bar is not removed > and is now drawn in the title bar instead of the border. Plain-border > seems to only remove the shading of the handles. Setting a > border-width of 10 shows that this is also the same for the other > handles. Is this a bug or am I missing something here? > > Another thing: If I set a border width of 0 and don't set plain-border > I get a lot of these messages: > > [Scwm][ScwmErrorHandler]: <> *** internal error *** > [Scwm][ScwmErrorHandler]: <> Request 12, Error 2, EventType: 0 > > All this is with scwm-19980722 and guile-980707 (on Solaris 2.6/X11R6.4). I think I fixed this. Please try tomorrow morning's snapshot and let me know what problems you've still got. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 30 00:17:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA17509 for scwm-discuss-outgoing; Thu, 30 Jul 1998 00:17:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA17506 for ; Thu, 30 Jul 1998 00:17:53 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA22785; Thu, 30 Jul 98 00:15:31 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id NAA18008 for ; Thu, 30 Jul 1998 13:15:39 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id NAA27973 for ; Thu, 30 Jul 1998 13:15:37 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id NAA03040; Thu, 30 Jul 1998 13:16:46 +0900 To: scwm-discuss@mit.edu Subject: fix in I18N and Solaris '-R' ld option problem X-Mailer: Mew version 1.93b38 on XEmacs 21.0 (Toggenburg) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980730131645Q.senda@ic.rdc.ricoh.co.jp> Date: Thu, 30 Jul 1998 13:16:45 +0900 X-Dispatcher: imput version 980522 Lines: 169 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I tried to compile scwm-19980728 with --enable-multibyte on Solaris 2.5.1 (X11R6.3 with X_LOCALE compile-option) and FreeBSD 2.2.6R. Here is fixes to work these environments : - X_LOCALE I18N code doesn't care that X11 was compiled with X_LOCALE. - '-R' ld option is needed on Solaris environment Scwm can't find guile libraries when it is in non-standard library path at run-time. 'autoconf' automatically fix in case of x-library path (see configure script at -R check), but do nothing about other libraries path. (This problem is fixed by setting LD_LIBRARY_PATH at run-time. but I don't want to set it.) - xpg4 library is needed to use 'real' locale system in FreeBSD libc in FreeBSD has locale system. but it is a fake code. It is necessary to link xpg4 library to use real locale system. Please check my fixes. --- +--------------------------------------------------------------------+ | SENDA,Shigeya Ricoh Co.,Ltd. | +--------------------------------------------------------------------+ ---------------------------------------------- --- configure.in.orig Thu Jul 23 18:52:15 1998 +++ configure.in Thu Jul 30 11:08:16 1998 @@ -69,7 +69,12 @@ AC_DEFINE(CL_NO_TRACE) AC_MSG_CHECKING(where to expect to find cassowary headers and library) CASSOWARY_INCLUDES="-I${withval}" - CASSOWARY_LIBS="-L${withval} ${withval}/../guile/cassowary_scm.o -lcassowary-scwm" + case "$ac_R_nospace" in + "yes") cas_lib_path="-L${withval} -R ${withval}" ;; + "no") cas_lib_path="-L${withval} -R${withval}" ;; + *) cas_lib_path="-L${withval}" ;; + esac + CASSOWARY_LIBS="$cas_lib_path ${withval}/../guile/cassowary_scm.o -lcassowary-scwm" AC_MSG_RESULT("${withval}") fi @@ -116,6 +121,8 @@ AC_DEFINE(HAVE_LIBXPM) ], , $x_libs) +dnl # check if X11 library was compiled with X_LOCALE definition +AC_CHECK_LIB(X11, _Xsetlocale, [ AC_DEFINE(X_LOCALE) ], [], $x_libs) x_cflags="$X_CFLAGS" x_ldflags="$X_LDFLAGS $X_LIBS" @@ -156,9 +163,9 @@ dnl # Guile checks # if test "x$exec_prefix" = "xNONE"; then - GUILE_LIBS_PRE="-L$ac_default_prefix/lib" + guile_lib_path="$ac_default_prefix/lib" else - GUILE_LIBS_PRE="-L$exec_prefix/lib" + guile_lib_path="$exec_prefix/lib" fi if test "x$prefix" = "xNONE"; then GUILE_INCLUDES="-I$ac_default_prefix/include" @@ -175,12 +182,17 @@ AC_MSG_CHECKING(where to expect to find guile) guile_prefix="${withval}" GUILE_INCLUDES="-I${guile_prefix}/include" - GUILE_LIBS_PRE="-L${guile_prefix}/lib" + guile_lib_path="${guile_prefix}/lib" AC_MSG_RESULT("${guile_prefix}") fi ]) +case "$ac_R_nospace" in +"yes") GUILE_LIBS_PRE="-L${guile_lib_path} -R ${guile_lib_path}" ;; +"no") GUILE_LIBS_PRE="-L${guile_lib_path} -R${guile_lib_path}" ;; +*) GUILE_LIBS_PRE="-L${guile_lib_path}" ;; +esac AC_ARG_WITH(guile-exec-prefix, [ --with-guile-exec-prefix=DIR @@ -341,6 +353,15 @@ [ AC_MSG_RESULT(no); ]) + +I18N_LIB="" +if test x"$enable_multibyte" = x"yes" ; then + # check if system has xpg4 library ( for FreeBSD ) + AC_CHECK_LIB(xpg4, _xpg4_setrunelocale, [ + I18N_LIB="-lxpg4" + ],[]) +fi +AC_SUBST(I18N_LIB) AC_OUTPUT(Makefile \ --- include/config.h.in.orig Tue Jul 28 16:32:33 1998 +++ include/config.h.in Thu Jul 30 09:30:42 1998 @@ -104,6 +104,9 @@ /* Define this if you want multibyte support. */ #undef I18N +/* Define this if you want to compile with X_LOCALE define. */ +#undef X_LOCALE + /* Define this and use C++ compiler if you want to use constraint solver */ #undef USE_CASSOWARY --- scwm/Makefile.in.orig Tue Jul 28 16:32:20 1998 +++ scwm/Makefile.in Thu Jul 30 09:38:01 1998 @@ -78,6 +78,7 @@ VERSION = @VERSION@ XEXT_LIB = @XEXT_LIB@ XPM_LIB = @XPM_LIB@ +I18N_LIB = @I18N_LIB@ lispdir = @lispdir@ scwm_image_load_path = @scwm_image_load_path@ scwm_load_path = @scwm_load_path@ @@ -144,7 +145,7 @@ menu.h shutdown.h string_token.h syscompat.h system.h \ util.h virtual.h window.h xmisc.h -scwm_LDADD = @x_ldflags@ @XEXT_LIB@ @XPM_LIB@ @x_libs@ @GUILE_LIBS@ @CASSOWARY_LIBS@ +scwm_LDADD = @x_ldflags@ @XEXT_LIB@ @XPM_LIB@ @x_libs@ @GUILE_LIBS@ @CASSOWARY_LIBS@ @I18N_LIB@ INCLUDES = @x_cflags@ @GUILE_INCLUDES@ @CASSOWARY_INCLUDES@ --- scwm/scwm.c.orig Tue Jul 28 12:15:59 1998 +++ scwm/scwm.c Thu Jul 30 09:27:19 1998 @@ -79,7 +79,7 @@ #endif #ifdef I18N -#include +#include #endif #define MAXHOSTNAME 255 @@ -422,10 +422,20 @@ gh_eval_str ("(define-module (guile))"); #ifdef I18N + /* setlocale in guile */ + scm_setlocale( gh_lookup("LC_CTYPE"), gh_str02scm("") ); + /* setlocale in X (system native locale or X_LOCALE) */ if ((Lang = setlocale (LC_CTYPE,"")) == (char *)NULL) { scwm_msg(WARN,"main","Can't set specified locale.\n"); Lang = "C"; } + if (! XSupportsLocale()) { + scwm_msg(ERR, "main", "locale not supported by Xlib, locale set to C"); + Lang = setlocale(LC_ALL, "C"); + } + if (! XSetLocaleModifiers("")) + scwm_msg(ERR, "main", "X locale modifiers not supported, using default"); + tmp = index(Lang,'.'); if (tmp) { territory = NEWC(tmp-Lang+1,char); ---------------------------------------------- From owner-scwm-discuss@mit.edu Thu Jul 30 04:56:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA19507 for scwm-discuss-outgoing; Thu, 30 Jul 1998 04:56:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA19504 for ; Thu, 30 Jul 1998 04:56:10 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA00753 for scwm-discuss@huis-clos.mit.edu; Thu, 30 Jul 1998 10:56:06 +0200 (CEST) Received: (qmail 700 invoked by uid 115); 29 Jul 1998 15:13:32 -0000 To: scwm-discuss@mit.edu Subject: Re: Anonymous CVS available References: <199807290353.XAA07047@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Jul 1998 17:13:32 +0200 In-Reply-To: Maciej Stachowiak's message of "Tue, 28 Jul 1998 23:53:43 EDT" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 28 Jul 1998 23:53:43 EDT >>>>> Maciej Stachowiak said: Maciej> Read the HACKING file for a list of tools you will need to Maciej> generate them (note to scwm-dev people: maybe in light of Maciej> anoncvs we should start keeping these in CVS again?). My point is that if you can't wait for the nightly snapshots and need up-to-the-hour sources, you're certainly nerdy enough, so that autoconf and friends are no big obstacles to you. But I may be wrong. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Jul 30 06:02:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA19810 for scwm-discuss-outgoing; Thu, 30 Jul 1998 06:02:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA19804 for ; Thu, 30 Jul 1998 06:02:00 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA11432; Thu, 30 Jul 98 06:02:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA04886; Thu, 30 Jul 1998 13:01:44 +0300 To: scwm-discuss@mit.edu Subject: scwm.el - apropos bug & fix. From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jul 1998 13:01:44 +0300 Message-Id: Lines: 52 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just did a cvs update & built & installed the latest & greatest scwm (using a fairly recent guile snapshot, which calls itself version 1.3a). I tried to use C-h C-a when editing my .scwmrc file (i.e. - from scwm mode), but it failed because with-current-buffer is undefined. Here's a patch to fix it: RCS file: /anoncvs/scwm/utilities/emacs/scwm.el,v retrieving revision 1.34 diff -C4 -r1.34 scwm.el *** scwm.el 1998/07/30 02:34:03 1.34 --- scwm.el 1998/07/30 09:58:47 *************** *** 90,97 **** --- 90,103 ---- (autoload 'help-xref-button "help") ; so the `autoload's are just to (autoload 'help-setup-xref "help")) ; keep the compiler happy (autoload 'Info-find-node "info") (autoload 'inferior-scheme-mode "cmuscheme") + (unless (fboundp 'with-current-buffer) + (defmacro with-current-buffer (name &rest body) + (` (save-excursion + (set-buffer (get-buffer-create (, name))) + (progn (,@ body)))))) + (unless (fboundp 'with-output-to-string) (defmacro with-output-to-string (&rest body) "Execute BODY, return the text it sent to `standard-output', as a string." `(let ((standard-output (get-buffer-create (generate-new-buffer-name *************** *** 107,114 **** --- 113,121 ---- " *temp-buffer*")))) (save-excursion (set-buffer standard-output) (unwind-protect (progn ,@body) (kill-buffer standard-output))))))) + ;;; Code: ;; user variables -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 30 06:42:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA20011 for scwm-discuss-outgoing; Thu, 30 Jul 1998 06:42:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA20008 for ; Thu, 30 Jul 1998 06:42:07 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13888; Thu, 30 Jul 98 06:42:28 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA05386; Thu, 30 Jul 1998 13:42:02 +0300 To: scwm-discuss@mit.edu Subject: hook half solutions References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jul 1998 13:42:02 +0300 In-Reply-To: hjstein@bfr.co.il's message of "30 Jul 1998 13:01:44 +0300" Message-Id: Lines: 52 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I did the following in my .scwmrc: (define (find-window-by-name window-name) (let ((wlist (list-windows #:only (lambda (w) (string=? (window-title w) window-name))))) (if (not (null? wlist)) (car wlist) #f))) (define (window-bottom window-name) (let ((window (find-window-by-name window-name))) (if (window? window) (map + (window-position window) (window-size window)) `(129 63)))) (add-hook! startup-hook (lambda () (display "Startup hook running") (newline) (display "Window list: ") (display (list-windows)) (newline) (if (not (window? (find-window-by-name "xclock"))) (execute (string-append "xclock -bg Grey20 -fg Orchid -hd Orchid -hl Orchid -geometry 60x60+0+" (number->string (cadr (window-bottom "Fvwm Pager")))))) (if (not (window? (find-window-by-name "xbiff"))) (execute (string-append "xbiff -bg Grey20 -fg Orchid -geometry +0+" (number->string (cadr (window-bottom "xclock")))))))) This was an attempt to: 1. Only start xclock & xbiff if they're not currently running, and 2. Position the xclock at the bottom of the fvwm pager window & position xbiff at the bottom of the xclock window. 1 succeeds, but 2 fails. I guess xclock doesn't necesarily have a mapped window by the time execute starts xbiff. I'd think that using a positioning hook to use my own positioning fcn would similarly fail. Other than waiting for constraint based window positioning, is there anything I can do? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 30 06:47:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA20066 for scwm-discuss-outgoing; Thu, 30 Jul 1998 06:47:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA20063 for ; Thu, 30 Jul 1998 06:47:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17469; Thu, 30 Jul 98 06:46:58 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA05483; Thu, 30 Jul 1998 13:47:07 +0300 To: scwm-discuss@mit.edu Subject: startup window position bug. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Jul 1998 13:47:07 +0300 Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Windows still aren't positioning correctly for me at startup. They're starting too low (when positioned with -0, as in: xterm -j -sb -sl 128 -si -geometry 82x48-0-0 -T $XTERMNAME & xterm -j -sb -sl 128 -si -geometry 80x24+0-0 -T $XTERMNAME & The 1st xterm also ends up a little to far to the right (looks like it's off by the window border). This is with "guile 1.3a" (snap 980630), & a cvs update this morning of scwm. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Jul 30 11:02:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21427 for scwm-discuss-outgoing; Thu, 30 Jul 1998 11:02:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA21424 for ; Thu, 30 Jul 1998 11:02:29 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA02922; Thu, 30 Jul 98 11:02:50 EDT Received: from 192.168.1.1 (root@INS218.tokyo-ap4.dti.ne.jp [210.159.156.34]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id AAA13607 for ; Fri, 31 Jul 1998 00:02:23 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id AAA01477 for ; Fri, 31 Jul 1998 00:02:21 +0900 Message-Id: <199807301502.AAA01477@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: fix in I18N and Solaris '-R' ld option problem References: <19980730131645Q.senda@ic.rdc.ricoh.co.jp> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Thu, 30 Jul 1998 13:16:45 +0900" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Fri, 31 Jul 1998 00:02:21 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello, Senda-san. senda@ic.rdc.ricoh.co.jp writes: > - X_LOCALE > I18N code doesn't care that X11 was compiled with X_LOCALE. Yes, I18N part doesn't consider X_LOCALE based system. Cause I don't have such ones. (^^;) #My system is GNU/Linux with glibc and I tested only for this platform. Doesn't it matter including instead of with X_LOCALE not defined systems? It seems okay, but I'm not sure. Anyway, I'm happy to see another Japanese name in this ML. :-) -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Thu Jul 30 11:40:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21985 for scwm-discuss-outgoing; Thu, 30 Jul 1998 11:40:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21975; Thu, 30 Jul 1998 11:40:17 -0400 Message-Id: <199807301540.LAA21975@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: startup window position bug. In-reply-to: Your message of "30 Jul 1998 13:47:07 +0300." Date: Thu, 30 Jul 1998 11:40:17 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Windows still aren't positioning correctly for me at startup. They're > starting too low (when positioned with -0, as in: > > xterm -j -sb -sl 128 -si -geometry 82x48-0-0 -T $XTERMNAME & > xterm -j -sb -sl 128 -si -geometry 80x24+0-0 -T $XTERMNAME & > > The 1st xterm also ends up a little to far to the right (looks like > it's off by the window border). > > This is with "guile 1.3a" (snap 980630), & a cvs update this morning > of scwm. > I have a fix for this but am not done debugging it yet. Basically what needs to happen is for scwm to respect the window gravity when changing the border size or title height. It's tricky to test all the possible combinations though. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 30 12:18:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22451 for scwm-discuss-outgoing; Thu, 30 Jul 1998 12:18:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22448 for ; Thu, 30 Jul 1998 12:18:25 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA21173; Thu, 30 Jul 98 12:18:13 EDT Received: by tis.bellhow.com; id MAA26867; Thu, 30 Jul 1998 12:18:21 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma026808; Thu, 30 Jul 98 12:18:04 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA25009 for ; Thu, 30 Jul 1998 12:18:04 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Wierd decorations Date: Thu, 30 Jul 1998 16:14:11 GMT Organization: Bell & Howell PSC Message-Id: <35c0990f.73152868@mailhost> References: <35b7d631.429129014@mailhost> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA22449 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 29 Jul 1998 20:43:59 -0700, you wrote: >dale.smith@bellhow.com (Dale Smith) writes: > >> I have noticed lately (7/20, 7/21) that the window frame corners are >> looking weird. I don't exactly know how to describe it. How's this: >> The inner shading of the corners is not be drawn or is being drawn in >> the wrong place and being overwritten by buttons 1 and 2. > >I think I squashed this bug today. Check tomorrow's snapshot. Much *much* Better! But... >Thanks again for pointing out the problem. Please mention other drawing >anomalies as you find them. The code is incredibly hard to test all the >cases of, so be sure to post the explicit style that you use to create >the faulty decoration. Windows without a title, have *very* small corners. (the areas for resizing a window) They are about as long as the sides are wide. Maybe one pixel larger. Windows with titles have the corners one pixel longer than the buttons in the title. I have: (window-style "Fvwm Pager" #:sticky #t #:no-titlebar #t) and: (window-style "*" #:fg "Black" #:bg "gray75" #:icon "unknown1.xpm" ; x y width height ; #:icon-box (list (x- 70) 1 69 (y- 141)) #:icon-box (list 1 (y- 69) (y- 141) 69) #:border-width 4 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:int-override #t #:decorate-transient #t #:mwm-border #t #:PPosition-hint #f #:lenience #t ) Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 30 14:56:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA23318 for scwm-discuss-outgoing; Thu, 30 Jul 1998 14:56:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA23315 for ; Thu, 30 Jul 1998 14:56:31 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01038; Thu, 30 Jul 98 14:56:18 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id OAA22857; Thu, 30 Jul 1998 14:56:27 -0400 (EDT) To: scwm-discuss@mit.edu Subject: new release Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 30 Jul 1998 14:56:26 -0400 Message-Id: <87hfzzdv6t.fsf@jekyll.piermont.com> Lines: 6 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is there any chance of an scwm 0.8 release showing up any time soon? I prefer working with "stable" code, and a bunch of the recent changes (like the documentation system) seem like they are worth upgrading to. .pm From owner-scwm-discuss@mit.edu Thu Jul 30 14:59:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA23373 for scwm-discuss-outgoing; Thu, 30 Jul 1998 14:59:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA23368; Thu, 30 Jul 1998 14:59:03 -0400 Message-Id: <199807301859.OAA23368@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: new release In-reply-to: Your message of "30 Jul 1998 14:56:26 EDT." <87hfzzdv6t.fsf@jekyll.piermont.com> Date: Thu, 30 Jul 1998 14:59:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Is there any chance of an scwm 0.8 release showing up any time soon? I > prefer working with "stable" code, and a bunch of the recent changes > (like the documentation system) seem like they are worth upgrading to. > I'm hoping for a release in a bit over a week (a bit overambitiously since there are big changes I have yet to finish). - Maciej From owner-scwm-discuss@mit.edu Thu Jul 30 15:53:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA23942 for scwm-discuss-outgoing; Thu, 30 Jul 1998 15:53:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA23939 for ; Thu, 30 Jul 1998 15:53:09 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA15594; Thu, 30 Jul 98 15:52:51 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfahr09520; Thu, 30 Jul 1998 19:52:53 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA02455; Thu, 30 Jul 1998 15:48:33 -0400 To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Thu, 30 Jul 1998 14:59:03 EDT" Date: 30 Jul 1998 15:48:33 -0400 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199807301859.OAA23368@huis-clos.mit.edu> >>>> Sent on Thu, 30 Jul 1998 14:59:03 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: new release": >> perry@piermont.com writes: >> > >> > Is there any chance of an scwm 0.8 release showing up any time soon? I >> > prefer working with "stable" code, and a bunch of the recent changes >> > (like the documentation system) seem like they are worth upgrading to. >> > >> >> I'm hoping for a release in a bit over a week (a bit overambitiously >> since there are big changes I have yet to finish). Just in case, the list of thing that seem to be broken right now. 1. both move and resize are rubberband not opaque, contrary to the announcements. 2. #:icon-box seems to be ignored; the icons are placed upon each other. 3. there is an uncanny connection between moving the icon and the window. 4. moving icons looks weird (the rubberband moves than stops...) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. char*a="char*a=%c%s%c;main(){printf(a,34,a,34);}";main(){printf(a,34,a,34);} From owner-scwm-discuss@mit.edu Thu Jul 30 16:20:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24231 for scwm-discuss-outgoing; Thu, 30 Jul 1998 16:20:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA24227 for ; Thu, 30 Jul 1998 16:20:07 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AB28367; Thu, 30 Jul 98 16:20:28 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA09785; Thu, 30 Jul 1998 13:20:02 -0700 (PDT) To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 30 Jul 1998 13:20:01 -0700 In-Reply-To: Sam Steingold's message of "30 Jul 1998 15:48:33 -0400" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > Just in case, the list of thing that seem to be broken right now. > > 1. both move and resize are rubberband not opaque, contrary to the > announcements. I've fixed the rubberband feature and interactive-move and interactive-resize now take a second argument that says whether the action should be done opaquely (it currently defaults to #f). I added opaque-interactive-move and opaque-interactive-resize to (app scwm winops) so that it'd be a bit easier. > > 2. #:icon-box seems to be ignored; the icons are placed upon each > other. > > 3. there is an uncanny connection between moving the icon and the > window. > > 4. moving icons looks weird (the rubberband moves than stops...) I'll look into these icon-related things. It'd be nice if someone who actually used icons and cared about them got interested in supporting that code. Since I don't use them, my motivation is low (besides liking to have happy users). Thanks for the list. Greg From owner-scwm-discuss@mit.edu Thu Jul 30 16:47:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24420 for scwm-discuss-outgoing; Thu, 30 Jul 1998 16:47:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA24417 for ; Thu, 30 Jul 1998 16:47:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29669; Thu, 30 Jul 98 16:47:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA10338; Thu, 30 Jul 1998 13:47:23 -0700 (PDT) To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 30 Jul 1998 13:47:22 -0700 In-Reply-To: Sam Steingold's message of "30 Jul 1998 15:48:33 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 2. #:icon-box seems to be ignored; the icons are placed upon each > other. > > 3. there is an uncanny connection between moving the icon and the > window. Can you explain this more? I just tried with interactive moving of the icon and it works for me. > 4. moving icons looks weird (the rubberband moves than stops...) I'm planning on making icons always move opaquely (things work fine for me on opaque moves of icons). Does anyone really want rubberband moving of icons? Make your case, if so. Greg From owner-scwm-discuss@mit.edu Thu Jul 30 16:55:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24513 for scwm-discuss-outgoing; Thu, 30 Jul 1998 16:55:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA24510 for ; Thu, 30 Jul 1998 16:55:37 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08186; Thu, 30 Jul 98 16:55:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA10341; Thu, 30 Jul 1998 13:55:13 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Wierd decorations References: <35b7d631.429129014@mailhost> <35c0990f.73152868@mailhost> From: Greg Badros Date: 30 Jul 1998 13:55:13 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 30 Jul 1998 16:14:11 GMT" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Much *much* Better! But... Good.... but... > Windows without a title, have *very* small corners. (the areas for > resizing a window) They are about as long as the sides are wide. > Maybe one pixel larger. > > Windows with titles have the corners one pixel longer than the buttons > in the title. Ok, this is fixed in my working copy. Should be committed before tomorrow's snapshot. I just made the corner_width be no less than 12 pixels. Something more configurable can happen later, perhaps. Greg From owner-scwm-discuss@mit.edu Thu Jul 30 17:06:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA24679 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:06:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA24676 for ; Thu, 30 Jul 1998 17:06:07 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04573; Thu, 30 Jul 98 17:05:53 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA10373; Thu, 30 Jul 1998 14:05:52 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: hook half solutions References: From: Greg Badros Date: 30 Jul 1998 14:05:52 -0700 In-Reply-To: hjstein@bfr.co.il's message of "30 Jul 1998 13:42:02 +0300" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > 1 succeeds, but 2 fails. I guess xclock doesn't necesarily have a > mapped window by the time execute starts xbiff. You can use xtoolwait to wait for the window to be mapped, perhaps. I think there may be some bugs in the use of the positioning callback that I hope to look into today. Greg From owner-scwm-discuss@mit.edu Thu Jul 30 17:11:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA24731 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:11:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA24728 for ; Thu, 30 Jul 1998 17:11:20 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05833; Thu, 30 Jul 98 17:11:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA10380; Thu, 30 Jul 1998 14:11:15 -0700 (PDT) To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 30 Jul 1998 14:11:15 -0700 In-Reply-To: Sam Steingold's message of "30 Jul 1998 15:48:33 -0400" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 3. there is an uncanny connection between moving the icon and the > window. > > 4. moving icons looks weird (the rubberband moves than stops...) Ok, 4 is fixed (preserving rubberbanding -- it was just an oversight, so I figured why lose generality just cause I screwed up a couple days ago). Still need more information about #3, though, as I fixed that for me a couple of days ago. Greg From owner-scwm-discuss@mit.edu Thu Jul 30 17:12:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA24768 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:12:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA24763 for ; Thu, 30 Jul 1998 17:12:17 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AB06085; Thu, 30 Jul 98 17:11:52 EDT Received: from 192.168.1.1 (root@INS218.tokyo-ap4.dti.ne.jp [210.159.156.34]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id GAA24999 for ; Fri, 31 Jul 1998 06:11:58 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id GAA06992 for ; Fri, 31 Jul 1998 06:11:56 +0900 Message-Id: <199807302111.GAA06992@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> <199807292228.HAA25020@192.168.1.1> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: Greg Badros's message of "29 Jul 1998 17:42:43 -0700" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Fri, 31 Jul 1998 06:11:55 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Tonight's snapshot will have my version of the I18N changes -- I look > forward to knowing if they worked for you. I tried 19980730, just one fix. :) font.c: In function `make_font': font.c:165: `i' undeclared (first use this function) font.c:165: (Each undeclared identifier is reported only once font.c:165: for each function it appears in.) make[1]: *** [font.o] Error 1 --- font.c.orig Fri Jul 31 06:02:45 1998 +++ font.c Fri Jul 31 06:03:03 1998 @@ -112,6 +112,7 @@ int missings,loadedfonts; int height = 0, ascent = 0; XFontStruct **xfss; + int i; #else XFontStruct *xfs; #endif -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Thu Jul 30 17:24:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA25084 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:24:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA25081 for ; Thu, 30 Jul 1998 17:24:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08840; Thu, 30 Jul 98 17:24:37 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA10383; Thu, 30 Jul 1998 14:24:02 -0700 (PDT) To: Maciej Stachowiak , hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: startup window position bug. References: From: Greg Badros Date: 30 Jul 1998 14:24:02 -0700 In-Reply-To: hjstein@bfr.co.il's message of "30 Jul 1998 13:47:07 +0300" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Windows still aren't positioning correctly for me at startup. They're > starting too low (when positioned with -0, as in: > > xterm -j -sb -sl 128 -si -geometry 82x48-0-0 -T $XTERMNAME & > xterm -j -sb -sl 128 -si -geometry 80x24+0-0 -T $XTERMNAME & > > The 1st xterm also ends up a little to far to the right (looks like > it's off by the window border). Maciej, this is in placement.c, around line 570: if (PPosOverride || (psw->hints.flags & USPosition) || (!psw->fNoPPosition && (psw->hints.flags & PPosition)) || ((psw->wmhints) && (psw->wmhints->flags & StateHint) && (psw->wmhints->initial_state == IconicState))) { move_finalize(psw->frame,psw, psw->attr.x, psw->attr.y); The move_finalize should alter the x and y coordinates as appropriate for the window frame (psw->attr.y - (psw->title_height + psw->boundary_width) for y in this case. Since this deals with the window gravity stuff, I figured I'd just point out my take on the fix in case you've already made related changes in your working copy. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Jul 30 17:29:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA25154 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:29:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA25151 for ; Thu, 30 Jul 1998 17:29:32 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA09922; Thu, 30 Jul 98 17:29:18 EDT Received: by tis.bellhow.com; id RAA26146; Thu, 30 Jul 1998 17:29:27 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma026047; Thu, 30 Jul 98 17:28:46 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id RAA06456 for ; Thu, 30 Jul 1998 17:28:46 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: new release Date: Thu, 30 Jul 1998 21:24:54 GMT Organization: Bell & Howell PSC Message-Id: <35c2e3ca.92283056@mailhost> References: <87hfzzdv6t.fsf@jekyll.piermont.com> In-Reply-To: <87hfzzdv6t.fsf@jekyll.piermont.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA25152 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 30 Jul 1998 14:56:26 -0400, you wrote: > >Is there any chance of an scwm 0.8 release showing up any time soon? I >prefer working with "stable" code, and a bunch of the recent changes >(like the documentation system) seem like they are worth upgrading to. Some things I'd like to see: Built-in pager. Gravity fixes. Other misc. decoration fixes. (I haven't mentioned this before because I heard there was going to be a massive re-write). Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Jul 30 17:38:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA25313 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:38:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA25310 for ; Thu, 30 Jul 1998 17:38:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18007; Thu, 30 Jul 98 17:38:52 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA10386; Thu, 30 Jul 1998 14:38:26 -0700 (PDT) To: scwm-discuss@mit.edu Subject: transient-placement-proc From: Greg Badros Date: 30 Jul 1998 14:38:25 -0700 Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk It's a bit unintuitive to have to do: (window-style "Netscape: Find" #:transient-placement-proc (thunk move-next-to-netscape-win)) instead of just: (window-style "Netscape: Find" #:placement-proc (thunk move-next-to-netscape-win)) simply because the window I'm explicitly trying to describe is a transient window. I'd prefer that the transient status of a window be folded into whatever window matching mechanism we end up using (remember, I still really hate that the Class and Resource names are not treated specially). Greg From owner-scwm-discuss@mit.edu Thu Jul 30 17:52:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA25475 for scwm-discuss-outgoing; Thu, 30 Jul 1998 17:52:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA25472 for ; Thu, 30 Jul 1998 17:52:11 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA14099; Thu, 30 Jul 98 17:51:57 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfahz18445; Thu, 30 Jul 1998 21:52:06 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA02649; Thu, 30 Jul 1998 17:51:40 -0400 To: Greg Badros Cc: Maciej Stachowiak , perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "30 Jul 1998 13:20:01 -0700" Date: 30 Jul 1998 17:51:40 -0400 Message-Id: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 30 Jul 1998 13:20:01 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: new release": >> Sam Steingold writes: >> >> > Just in case, the list of thing that seem to be broken right now. >> > >> > 1. both move and resize are rubberband not opaque, contrary to the >> > announcements. >> >> I've fixed the rubberband feature and interactive-move and >> interactive-resize now take a second argument that says whether the >> action should be done opaquely (it currently defaults to #f). I added >> opaque-interactive-move and opaque-interactive-resize to (app scwm >> winops) so that it'd be a bit easier. 1. The documentation for `interactive-move' mentions non-existent `set-opaque-move-size!'. 2. I would like to suggest the following: 2 new variables, `default-opaque-move?' and `default-opaque-resize?', which should be the default `opaque?' argument to `interactive-move' and `interactive-resize'. Adding this shouldn't be hard; I can probably do that. Do you want to do it yourself, or you want me to do it, or you are against the whole thing? I don't want to replace all my `interactive-resize' calls with `opaque-interactive-resize'. Thanks -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. I'm a Lisp variable -- bind me! From owner-scwm-discuss@mit.edu Thu Jul 30 18:06:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25690 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:06:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25680; Thu, 30 Jul 1998 18:06:50 -0400 Message-Id: <199807302206.SAA25680@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: startup window position bug. In-reply-to: Your message of "30 Jul 1998 14:24:02 PDT." Date: Thu, 30 Jul 1998 18:06:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Windows still aren't positioning correctly for me at startup. They're > > starting too low (when positioned with -0, as in: > > > > xterm -j -sb -sl 128 -si -geometry 82x48-0-0 -T $XTERMNAME & > > xterm -j -sb -sl 128 -si -geometry 80x24+0-0 -T $XTERMNAME & > > > > The 1st xterm also ends up a little to far to the right (looks like > > it's off by the window border). > > Maciej, this is in > > placement.c, around line 570: > > if (PPosOverride || > (psw->hints.flags & USPosition) || > (!psw->fNoPPosition && (psw->hints.flags & PPosition)) || > ((psw->wmhints) && > (psw->wmhints->flags & StateHint) && > (psw->wmhints->initial_state == IconicState))) { > move_finalize(psw->frame,psw, psw->attr.x, psw->attr.y); > > > The move_finalize should alter the x and y coordinates as appropriate > for the window frame (psw->attr.y - (psw->title_height + psw->boundary_width) > for y in this case. Since this deals with the window gravity stuff, I > figured I'd just point out my take on the fix in case you've already > made related changes in your working copy. > I believe the right place to fix it is actually before this code ever gets executed (and subesequently after, to keep up with border size changes). I've almost got it working. I'm going to semi-ignore mail for a bit so I can actually get some work done (I'm easily distracted and I get way too much mail), but I will reply on any other issues raised here that I can deal with ASAP. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 30 18:10:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25777 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:10:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA25774 for ; Thu, 30 Jul 1998 18:10:46 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA24043; Thu, 30 Jul 98 18:11:06 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfaia22600; Thu, 30 Jul 1998 22:10:41 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA02731; Thu, 30 Jul 1998 18:10:35 -0400 To: scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "30 Jul 1998 14:11:15 -0700" Date: 30 Jul 1998 18:10:34 -0400 Message-Id: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 30 Jul 1998 14:11:15 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: new release": >> Sam Steingold writes: >> > 4. moving icons looks weird (the rubberband moves than stops...) >> >> Ok, 4 is fixed (preserving rubberbanding -- it was just an oversight, so >> I figured why lose generality just cause I screwed up a couple days ago). Some might prefer opaque icons and rubberband windows. You removed set-opaque-move-size!, so now we cannot distinguish. So we will probably need 4(!) variables - opaque move/resize windows/icons. BTW!!!! prefs-menu.scm - I want it to be usable by the next release. 1. User variables should be marked as such and extracted not only into scwm-documentation.txt, but also into a new var `user-options' which should be a list of all user variables. 2. Other "user option functions", like `set-desk-size!' and `set-edge-scroll!', should also be marked as such. There is no point in having a variable contain them, as they require different arguments, but I want to be able to find them all by just searching through scwm-documentation.txt for a simple regexp. 3. A big problem is that what is really required here is something like Emacs's custom.el. No, I am not going to do anything on that scale. Something pretty minimal will have to do. 4. Something has to be done about `ask-string'... -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A poet who reads his verse in public may have other nasty habits. From owner-scwm-discuss@mit.edu Thu Jul 30 18:17:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25895 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:17:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25885; Thu, 30 Jul 1998 18:16:58 -0400 Message-Id: <199807302216.SAA25885@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: new release In-reply-to: Your message of "30 Jul 1998 17:51:40 EDT." Date: Thu, 30 Jul 1998 18:16:58 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message > >>>> Sent on 30 Jul 1998 13:20:01 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: new release": > >> Sam Steingold writes: > >> > >> > Just in case, the list of thing that seem to be broken right now. > >> > > >> > 1. both move and resize are rubberband not opaque, contrary to the > >> > announcements. > >> > >> I've fixed the rubberband feature and interactive-move and > >> interactive-resize now take a second argument that says whether the > >> action should be done opaquely (it currently defaults to #f). I added > >> opaque-interactive-move and opaque-interactive-resize to (app scwm > >> winops) so that it'd be a bit easier. > > 1. The documentation for `interactive-move' mentions non-existent > `set-opaque-move-size!'. > > 2. I would like to suggest the following: 2 new variables, > `default-opaque-move?' and `default-opaque-resize?', which should be > the default `opaque?' argument to `interactive-move' and > `interactive-resize'. Adding this shouldn't be hard; I can probably > do that. Do you want to do it yourself, or you want me to do it, or > you are against the whole thing? I don't want to replace all my > `interactive-resize' calls with `opaque-interactive-resize'. > I am in the midst of a big API review, one thing I would like to change is to make wireframe-resize and opaque-resize into separate C-level procedures, and add a scheme wrapper something like this (similarly, of course, for move): (define (interactive-resize #&optional (w (get-window)) (opaque? (opaque-threshold-proc w))) (if opaque? (opaque-resize w) (interactive-resize w))) Or something like that. The user can set opaque-threshold-proc. To have moves default to opaque, set it to (lammbda (w) #t), similarly for always wireframe, or you could set it to an arbitrary function of a window (whatever suits your fancy, inlcuding maybe even the old size percentage stuff). I think this is a nice generalization of the old way of doing things. In brief, I think I have this covered. OK, back to work. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 30 18:17:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25923 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:17:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA25916 for ; Thu, 30 Jul 1998 18:17:34 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA18238; Thu, 30 Jul 98 18:17:20 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA23113; Thu, 30 Jul 1998 18:17:18 -0400 (EDT) Message-Id: <199807302217.SAA23113@jekyll.piermont.com> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: transient-placement-proc In-Reply-To: Your message of "30 Jul 1998 14:38:25 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jul 1998 18:17:18 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > It's a bit unintuitive to have to do: > > (window-style "Netscape: Find" > #:transient-placement-proc (thunk move-next-to-netscape-win)) > > instead of just: > > (window-style "Netscape: Find" > #:placement-proc (thunk move-next-to-netscape-win)) I personally find the fact that the window manager doesn't figure out on its own what is transient and what isn't somewhat annoying... .pm From owner-scwm-discuss@mit.edu Thu Jul 30 18:20:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25960 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:20:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA25949 for ; Thu, 30 Jul 1998 18:19:15 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA25373; Thu, 30 Jul 98 18:19:04 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA23121; Thu, 30 Jul 1998 18:18:26 -0400 (EDT) Message-Id: <199807302218.SAA23121@jekyll.piermont.com> To: sds@goems.com Cc: Greg Badros , Maciej Stachowiak , perry@piermont.com, scwm-discuss@mit.edu Subject: Re: new release In-Reply-To: Your message of "30 Jul 1998 17:51:40 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 30 Jul 1998 18:18:25 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 2. I would like to suggest the following: 2 new variables, > `default-opaque-move?' and `default-opaque-resize?', The question mark seems wrong -- it makes the variables look like predicate functions. .pm From owner-scwm-discuss@mit.edu Thu Jul 30 18:21:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA26005 for scwm-discuss-outgoing; Thu, 30 Jul 1998 18:21:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA26000; Thu, 30 Jul 1998 18:21:47 -0400 Message-Id: <199807302221.SAA26000@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: API revisions coming Date: Thu, 30 Jul 1998 18:21:47 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am going to check in some fairly large API revisions later today, which include things like renaming primitives more logically and consistently, and providing getters to correspond to every setter. I will update all shipped Scheme code (including the scwmrcs in CVS) as I go, but people should be forewarned that things may break. I feel bad making a lot of incompatible changes, but better to do it now than to do it later when it affects more people more extensively, or to live with badly named primitives forever. I will check out the comments on this list when I catch up on getting some of my scwm stuff checked in. - Maciej From owner-scwm-discuss@mit.edu Thu Jul 30 20:41:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA15556 for scwm-discuss-outgoing; Thu, 30 Jul 1998 20:41:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA15553 for ; Thu, 30 Jul 1998 20:40:44 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA14390; Thu, 30 Jul 98 20:41:00 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA13631; Thu, 30 Jul 1998 17:40:34 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 30 Jul 1998 17:40:34 -0700 In-Reply-To: Sam Steingold's message of "30 Jul 1998 17:51:40 -0400" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 1. The documentation for `interactive-move' mentions non-existent > `set-opaque-move-size!'. Ok, thanks. > 2. I would like to suggest the following: 2 new variables, > `default-opaque-move?' and `default-opaque-resize?', which should be > the default `opaque?' argument to `interactive-move' and > `interactive-resize'. Adding this shouldn't be hard; I can probably > do that. Do you want to do it yourself, or you want me to do it, or > you are against the whole thing? I don't want to replace all my > `interactive-resize' calls with `opaque-interactive-resize'. That seems reasonable to me. I chose to avoid making the primitive be fully general in taking a callback to choose the default. I'm a bit concerned about global variables being used by primitives, though. Also, not sure about Scheme conventions for boolean global variables. `default-opaque-resize?' sounds like a predicate procedure to me. Maybe we should just switch the default to being opaque, and then make `rubberband-resize' and `rubberband-move' supply the fOpaque == #f. Perhaps reordering the arguments so that the OPAQUE? argument comes first would also be helpful? Greg From owner-scwm-discuss@mit.edu Thu Jul 30 21:01:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15769 for scwm-discuss-outgoing; Thu, 30 Jul 1998 21:01:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA15761 for ; Thu, 30 Jul 1998 21:00:53 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08665; Thu, 30 Jul 98 21:00:16 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA13683; Thu, 30 Jul 1998 18:00:24 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 30 Jul 1998 18:00:23 -0700 In-Reply-To: Sam Steingold's message of "30 Jul 1998 18:10:34 -0400" Message-Id: Lines: 50 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > Some might prefer opaque icons and rubberband windows. > You removed set-opaque-move-size!, so now we cannot distinguish. > So we will probably need 4(!) variables - opaque move/resize > windows/icons. The more general framework w/ the closure gives you that, though. Sounds like Maciej is on top of it, so I'll let him finalize that stuff. > BTW!!!! > prefs-menu.scm - I want it to be usable by the next release. > > 1. User variables should be marked as such and extracted not only > into scwm-documentation.txt, but also into a new var `user-options' > which should be a list of all user variables. > > 2. Other "user option functions", like `set-desk-size!' and > `set-edge-scroll!', should also be marked as such. There is no point > in having a variable contain them, as they require different > arguments, but I want to be able to find them all by just searching > through scwm-documentation.txt for a simple regexp. I'll try to figure something out for this, but it'll be a couple of days, I'd imagine. > 3. A big problem is that what is really required here is something like > Emacs's custom.el. No, I am not going to do anything on that scale. > Something pretty minimal will have to do. Yep. A port of custom would be nice. My understanding of the minimal needs (paraphrasing the above): o marking in C code (via SCWM_USER_VAR macro, perhaps) of user configuration variables o marking in scheme code (via some distinguished comment sequence) of same. o a single distinguished scheme variable that is a list of the user-option variables (this could be done at the scheme level, right?) > 4. Something has to be done about `ask-string'... Just use an executable that the user specifies -- on my system, I have xprompt installed, and it can do good enough for until we get a Widget toolkit integrated (that will not happen by .8). Greg From owner-scwm-discuss@mit.edu Thu Jul 30 21:07:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15833 for scwm-discuss-outgoing; Thu, 30 Jul 1998 21:07:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA15826 for ; Thu, 30 Jul 1998 21:06:41 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA17552; Thu, 30 Jul 98 21:06:52 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id KAA12882 for ; Fri, 31 Jul 1998 10:06:21 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id KAA29249 for ; Fri, 31 Jul 1998 10:06:19 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id KAA19228; Fri, 31 Jul 1998 10:07:29 +0900 To: scwm-discuss@mit.edu Subject: Re: fix in I18N and Solaris '-R' ld option problem In-Reply-To: Your message of "Fri, 31 Jul 1998 00:02:21 +0900" <199807301502.AAA01477@192.168.1.1> References: <199807301502.AAA01477@192.168.1.1> X-Mailer: Mew version 1.93b38 on XEmacs 21.0 (Toggenburg) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980731100729N.senda@ic.rdc.ricoh.co.jp> Date: Fri, 31 Jul 1998 10:07:29 +0900 X-Dispatcher: imput version 980522 Lines: 46 Sender: owner-scwm-discuss@mit.edu Precedence: bulk From: ITANI Eiichiro Subject: Re: fix in I18N and Solaris '-R' ld option problem Date: Fri, 31 Jul 1998 00:02:21 +0900 Message-ID: <199807301502.AAA01477@192.168.1.1> emu> Hello, Senda-san. emu> emu> senda@ic.rdc.ricoh.co.jp writes: emu> Hi, emu> > - X_LOCALE emu> > I18N code doesn't care that X11 was compiled with X_LOCALE. emu> emu> Yes, I18N part doesn't consider X_LOCALE based system. Cause I don't emu> have such ones. (^^;) emu> #My system is GNU/Linux with glibc and I tested only for this platform. emu> emu> Doesn't it matter including instead of with emu> X_LOCALE not defined systems? It seems okay, but I'm not sure. emu> includes internally if X_LOCALE is not defined. Addition of function calls (XSupportsLocale() and XSetLocaleModifier()) is polite way to initialize I18N feature of X. (See "The Definitive Guide to the X Window System - Programmer's Supplement for Release 5"(O'Reilly) or other X document, or X source code (xc/lib/Xt/Initialize.c : _XtDefaultLanguageProc())) + /* setlocale in guile */ + scm_setlocale( gh_lookup("LC_CTYPE"), gh_str02scm("") ); Above addition is just in case. I thought Guile system may need to do something special about locale (in the feature). emu> Anyway, I'm happy to see another Japanese name in this ML. :-) I'm glad to see you. :-) S.Senda From owner-scwm-discuss@mit.edu Fri Jul 31 00:13:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA24777 for scwm-discuss-outgoing; Fri, 31 Jul 1998 00:13:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA24590; Fri, 31 Jul 1998 00:13:08 -0400 Message-Id: <199807310413.AAA24590@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: gravity bug Date: Fri, 31 Jul 1998 00:13:07 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I finally got off my slacking butt and cleaned up my fix for this enough to commit. Not only did it improve the semantics above even what fvwm did, it actually ended up simplifying and shrinking the code, and reducing the size of the window struct. That's the kind of change I like. I'd appreciate if people who were having related problems could test and report back to me. - Maciej From owner-scwm-discuss@mit.edu Fri Jul 31 12:24:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25419 for scwm-discuss-outgoing; Fri, 31 Jul 1998 12:24:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA25416 for ; Fri, 31 Jul 1998 12:24:09 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA28515; Fri, 31 Jul 98 12:23:45 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfakv11281; Fri, 31 Jul 1998 16:23:53 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id KAA03484; Fri, 31 Jul 1998 10:01:03 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "30 Jul 1998 18:00:23 -0700" Date: 31 Jul 1998 10:01:03 -0400 Message-Id: Lines: 69 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 30 Jul 1998 18:00:23 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: new release": >> >> The more general framework w/ the closure gives you that, though. >> Sounds like Maciej is on top of it, so I'll let him finalize that stuff. Absolultely! >> > BTW!!!! >> > prefs-menu.scm - I want it to be usable by the next release. >> > >> > 1. User variables should be marked as such and extracted not only >> > into scwm-documentation.txt, but also into a new var `user-options' >> > which should be a list of all user variables. >> > >> > 2. Other "user option functions", like `set-desk-size!' and >> > `set-edge-scroll!', should also be marked as such. There is no point >> > in having a variable contain them, as they require different >> > arguments, but I want to be able to find them all by just searching >> > through scwm-documentation.txt for a simple regexp. >> >> I'll try to figure something out for this, but it'll be a couple of >> days, I'd imagine. >> >> > 3. A big problem is that what is really required here is something like >> > Emacs's custom.el. No, I am not going to do anything on that scale. >> > Something pretty minimal will have to do. >> >> Yep. A port of custom would be nice. >> >> My understanding of the minimal needs (paraphrasing the above): >> >> o marking in C code (via SCWM_USER_VAR macro, perhaps) of user >> configuration variables >> >> o marking in scheme code (via some distinguished comment sequence) of >> same. >> >> o a single distinguished scheme variable that is a list of the >> user-option variables (this could be done at the scheme level, right?) I don't think so. I would say that user options should be defined by a defcustom-like macro, which will expand into somehting like (define-public var-name value "doc") (set! user-options (cons 'var-name user-options)) while SCWM_USER_VAR should do something similar. (this way we will be able to avoid extracting all variables into some file, we will just set `user-options' to the appropriate value at compile-time (for C-level options) or at load time (for Scheme-level ones). This will mean that the options from the non-loaded modules will not be mentioned in `user-options' - GOOD! >> > 4. Something has to be done about `ask-string'... >> >> Just use an executable that the user specifies -- on my system, I have >> xprompt installed, and it can do good enough for until we get a Widget >> toolkit integrated (that will not happen by .8). I don't have xprompt. where did you get it? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A poet who reads his verse in public may have other nasty habits. From owner-scwm-discuss@mit.edu Fri Jul 31 17:03:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27550 for scwm-discuss-outgoing; Fri, 31 Jul 1998 17:03:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA27547 for ; Fri, 31 Jul 1998 17:03:14 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07463; Fri, 31 Jul 98 17:03:24 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA16091; Fri, 31 Jul 1998 14:02:57 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: new release References: <199807301859.OAA23368@huis-clos.mit.edu> From: Greg Badros Date: 31 Jul 1998 14:02:57 -0700 In-Reply-To: Sam Steingold's message of "31 Jul 1998 10:01:03 -0400" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > I don't think so. I would say that user options should be defined by a > defcustom-like macro, which will expand into somehting like > > (define-public var-name value "doc") > (set! user-options (cons 'var-name user-options)) > > while SCWM_USER_VAR should do something similar. (this way we will be > able to avoid extracting all variables into some file, we will just set > `user-options' to the appropriate value at compile-time (for C-level > options) or at load time (for Scheme-level ones). This will mean that > the options from the non-loaded modules will not be mentioned in > `user-options' - GOOD! Ok... I'll start trying to do something with a SCWM_USER_VAR macro, and let you deal with it on the scheme end (we won't need to scan the scheme files [it'd be easy anyway], right?). > >> > 4. Something has to be done about `ask-string'... > >> > >> Just use an executable that the user specifies -- on my system, I have > >> xprompt installed, and it can do good enough for until we get a Widget > >> toolkit integrated (that will not happen by .8). > > I don't have xprompt. where did you get it? Probably ftp.x.org in the contrib directory. It's first line of usage is: @(#)xprompt.c ver 1.4 (91/09/28 14:23:33) brachman@cs.ubc.ca Try an altavista or ftpsearch, perhaps. I've had it for too long to remember... Greg From owner-scwm-discuss@mit.edu Fri Jul 31 18:27:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA28523 for scwm-discuss-outgoing; Fri, 31 Jul 1998 18:27:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA28520 for ; Fri, 31 Jul 1998 18:27:11 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22628; Fri, 31 Jul 98 18:27:19 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA16318; Fri, 31 Jul 1998 15:26:49 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Window structure rewrite thoughts From: Greg Badros Date: 31 Jul 1998 15:26:48 -0700 Message-Id: Lines: 179 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk The below is from the checked in doc/dev/winstruct notes, with my comments. > Window structure rewrite plans > > > Key goals of the rewrite: > > * End the two-level wrapping of the window structure (the smob has a > pointer to a structure, which has a pointer to the real C window > struct, currently, unlike the 1-level wrapping of fonts, colors, etc). I'm still not convinced that this is a problem. In particular, I like the compile time safety of passing ScwmWindow*'s instead of SCMs. Also, it's faster (no need for redundant run-time type checking), and easier to debug ScwmWindow*'s (how does one interrogate an SCM object under GDB, anyway?). Finally, it's useful to keep a firm dividing line between scheme primitives and the C functions which serve as helpers in implementing those primitives. This is especially important if we want to have any hope of sharing code with other wm projects (e.g., fvwm3). > * Allow named extension structures to be hung off of the main window > struct. This is so that pieces can be added to the window structure as > necessary, while keeping the main structure itself compact. Features > in optional extensions would be able to extend the window structure > with their own data, and perhaps data relating to certain features > could be consigned to extension structures that are not created until > they are needed. For instance, a window would not get the icon data > extension unless the user actually uses visible icons, saving some > memory for those who don't. This will be incredibly useful. Perhaps we should just have primitives that are a nice front-end to XSaveContext and XGetContext, which are pretty highly optimized routines from Xlib (no server interaction) which store void *'s (which would be a SCM or point at an SCM for portability) with a given XWindow (can even hang stuff off of decoration windows this way, instead of adding a SCM other_properties everywhere we *might* want to extend a structure. > * Provide a sane interface for user code to get notified when any > property of a window changes (i.e. `property-change-hook'). You mean literally X "properties", or property in the colloquial sense (which encompasses the former). > > * Ensure that all properties of a window can be set and accessed in a > uniform manner. Always good. > Implementation strategies: > > * Try to always pass windows around as SCMs, not psw's. If possible, > use a Scheme list instead of the current handmade linked list code as > the window list. This would be a huge, pervasive change, however. This is the big part that I'm a bit skeptical of. A Scheme list of the windows would be reasonable, perhaps, but all the operations on the window list should be hidden behind an interface, anyway, so we should be flexible as to the actual implementation. > > * Have a generic interface to getting and setting window properties: > > procedure: window-property WINDOW SYMBOL > > Get the property named SYMBOL for WINDOW. > > procedure: set-window-property! WINDOW SYMBOL VALUE > > Set the property named SYMBOL for WINDOW to VALUE. Colloquial property or X property? Is this the generalization of the xproperty stuff Robert wrote, or just a suggestion for uniform access to the settings for a window? > * Some properties will be represented directly as fields directly in > the C struct; others may be in various extension hooks. C code can > register methods for setting/getting properties to handle those that > are implemented as fields in the C struct. Other properties will live > in the other_properties association list at the end of the window > struct. I like the first part. I still need convincing that a scheme-level a-list is the right way to attach properties to a window struct. > ** Mental note: will it be necessary to let C code be established that > manages certain properties for only _some_ windows, and that can > on-demand rip them out of the other_properties alist and put them in > it's own choice of extension struct? Say a decoration module cares > about some special properties and wants to redirect them to > itself. But windows not managed by that decoration style should treat > those properties as normal Scheme-ish properties. This is just an efficiency issue, right? Worth keeping in mind.... > > * Whenever any property gets changed, whether by user code or within > the C code, trigger property-change-hook with the window, the property > name, and possibly the old value (is this useful?) I think the old value is useful. Standard question about property. We definitely need to pick a different term if you're not talking about "X properties". > > * Many window operations would then just become Scheme-level wrappers > for getting and/or setting special C-implemented properties. But not > all of them. For instance, anything involving animation or > interaction, or that changes more than one property, or that has an > imperative/destructive nature would not fit this category. > > > > Random things to think about while doing this: > > * Various operations may want to save the size and position of the > window. For example, maximizing does this, and so does window-shading > (for the height). Right now they use orthogonal mechanisms and > therefore do not play nice together (maximize, window-shade, > unamiximize, un-window-shade -> the window will be a ridiculous size) Yea... window-shading is a bit tricky for the constraint solver, too: do I consider the new height of the window to be its frame's shaded height? Or does the height of the window stay the same, and it just changes its state to being shaded. > > * There will probably be a lot of hooks looking at window properties > eventually, but most will only care about one property, or only one > window. Will all the duds hurt performance? Is it worthwhile adding a > mechanism to set hooks for a specific property and/or a specific > window? If efficiency is a problem, then the hooks need to say which properties they are interested in when they are registered, and C-level code dispatches to only the scheme procedures that specifically care about a given change. Some of this stuff should, perhaps, hold off until I get a local-propagation constraint solver into the system. Some of the constraint-sy plans subsume lots of these setting-change hooks. Instead of thinking in terms of hooks, you think it terms of "what is the desired behaviour I want" and let the lp-solver do the right thing (in one sense, managing the hooks efficiently on its own). > * How does stacking order fit into this? Is it a property of the > window or should we handle it in some orthogonal way? Certainly it is > not logical to think of `raised' as being a property of the window > which should be set to #t and #f to raise and lower it, especially > since we have a `restack' primitive that allows arbitrarty restacking. I'd like to change the stacking order into a numerical setting on the window -- a Z ordering. This will make it possible to get the current constraint solver to manage the stacking order efficiently and express more specific types of on-top and on-bottom behaviour. E.g., I could say: I want XTerm windows to have a higher z-value (further away) than xclocks, so my xclock will always be on top of an XTerm. But I could give "Alert" windows of some kind an even lower (closer) z-value so they would obscure the xclock. Lots more, of course. > * Ensure the constrain solver's needs at minimum are met, so it can be > implemented using the new window structure facilities witout _any_ > additional special hooks in the core code. This should be a good > example of how advanced an extension we want to support. Good. The constraint solver currently is really cleanly integrated into SCWM... only a half-dozen C functions are called from within Scwm main code, and dummy, non-constraint versions are used if you build scwm normally. However, callbacks are probably not good enough for these "hooks" in the mainline code -- constraint-solver specific code needs to be executed for each pointer motion event in, e.g., an interactive move. Incidentally, once I am able to make a 0.2 release of Cassowary (my constraint solver), I will post directions about how to build scwm w/ constraints so that others can try the alpha version I'm working on. Greg From owner-scwm-discuss@mit.edu Fri Jul 31 19:19:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA28965 for scwm-discuss-outgoing; Fri, 31 Jul 1998 19:19:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA28962 for ; Fri, 31 Jul 1998 19:19:17 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29287; Fri, 31 Jul 98 19:19:26 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA16460; Fri, 31 Jul 1998 16:18:57 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: fvwm2 mini-icon broadcast bug backtrace From: Greg Badros Date: 31 Jul 1998 16:18:57 -0700 Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Whenever a mini-icon broadcast to the fvwm2 pager module is done, I still get: Backtrace: 0* [module-broadcast-mini-icon 8388608 #] 1* [map # ((# 0 # ...))] 2* [# (# 0 # ...)] 3* (let ((to-module-write #) (mask #)) (if (logior type mask) (send-mini-icon-p acket window to-module-write))) 4 (if (logior type mask) (send-mini-icon-packet window to-module-write)) ... 5 (let* ((props #) (body #)) (fvwm2-module-send-packet M_MINI_ICON body ...)) 6* [string-append ... 7* [longs->string 8388622 12583227 ...] 8 [apply # ... 9* [map #string (int)> (8388622 12583227 0 ...)] 10* [long->string (width . 16)] 11* (let* ((s #) (intx #)) (string-set! s 3 ...) ...) 12* (if (> int 2147483647) (- int 4294967296) ...) 13* [> (width . 16) 2147483647] ERROR: In procedure > in expression (> int 2147483647): ERROR: Wrong type argument in position 2: (width . 16) (reproduce by trying to use the fvwm2 pager with a mini-icon -- gjb.scwmrc does this). Greg From owner-scwm-discuss@mit.edu Sat Aug 1 16:40:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA12330 for scwm-discuss-outgoing; Sat, 1 Aug 1998 16:40:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA12325; Sat, 1 Aug 1998 16:40:29 -0400 Message-Id: <199808012040.QAA12325@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Widget sets and scwm Date: Sat, 01 Aug 1998 16:40:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg recently posted that scwm would probably not provide access to a widget set before 0.8. I hate to dispute him, but with the current scwm from CVS, and guile-gtk-0.10 and gtk-1.0.5 from ftp.gtk.org, typing the following to a scwmrepl results in a very interesting window: (use-modules (gtk gtk)) (define w (gtk-window-new 'toplevel)) (define b (gtk-button-new-with-label "Testing guile-gtk under scwm.")) (gtk-container-add w b) (gtk-widget-show b) (gtk-widget-show w) (while (not (= 0 (gtk-events-pending))) (gtk-main-iteration)) (while (not (= 0 (gtk-events-pending))) (gtk-main-iteration)) WARNING: do not try this with an older scwm, scwm will crash. In fact, don't try it with scwm from anoncvs until at least 5PM EDT today to make sure it has time to update. In fact, best not to try it at all, it's not very well tested, and the gtk event loop is not handled nicely yet. - Maciej PS Thanks a lot to Greg for adding the set-X-server-synchronize! primitive, without that I'd never have been able to debug this. From owner-scwm-discuss@mit.edu Sat Aug 1 21:22:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA13480 for scwm-discuss-outgoing; Sat, 1 Aug 1998 21:22:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA13477 for ; Sat, 1 Aug 1998 21:22:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26036; Sat, 1 Aug 98 21:22:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA25034; Sat, 1 Aug 1998 18:22:11 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Widget sets and scwm References: <199808012040.QAA12325@huis-clos.mit.edu> From: Greg Badros Date: 01 Aug 1998 18:22:11 -0700 In-Reply-To: Maciej Stachowiak's message of "Sat, 01 Aug 1998 16:40:27 EDT" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Greg recently posted that scwm would probably not provide access to a > widget set before 0.8. I hate to dispute him, but with the current > scwm from CVS, and guile-gtk-0.10 and gtk-1.0.5 from ftp.gtk.org, > typing the following to a scwmrepl results in a very interesting > window: Hey, for once, I'm glad to be wrong. Gotta love code reuse! Pager, anyone? Greg From owner-scwm-discuss@mit.edu Sun Aug 2 09:08:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA16849 for scwm-discuss-outgoing; Sun, 2 Aug 1998 09:08:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA16846 for ; Sun, 2 Aug 1998 09:08:06 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26885; Sun, 2 Aug 98 09:07:52 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA31125; Sun, 2 Aug 1998 16:07:59 +0300 To: scwm-discuss@mit.edu Subject: extract-docs partially rewritten in scheme. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Aug 1998 16:07:59 +0300 In-Reply-To: Greg Badros's message of "01 Aug 1998 18:22:11 -0700" Message-Id: Lines: 268 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I got sick of having an extract-docs sitting around which is written in perl, so I started writing a scheme version. It seems to be capable at this point of reading scwm/*.c & writing out the scwm-procedures.txt file, except that it needs sorting. Does guile have a built in sort routine? I wouldn't expect generating the sgml to be much more work. ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; (basic-extract-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; Note: ;;; 1. I added (DOC ...) records as an afterthought. They need more ;;; structure. ;;; 2. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things. (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*(.*)")) ; Strip off (spaces /** spaces) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:arg-count procrec) (list-ref procrec 2)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (doc:type rec) (list-ref rec 0)) (define (doc:data rec) (list-ref rec 1)) (define (doc:file rec) (list-ref rec 2)) (define (doc:line rec) (list-ref rec 3)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document extracted from the specified files. (define (output-proclist . files) (for-each list-proc (apply basic-extract-from-files files))) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (list-proc procdocrec) (if (eq? 'SCWM_PROC (doc:type procdocrec)) (let ((procrec (procdoc:decl (doc:data procdocrec))) (docrec (procdoc:doc (doc:data procdocrec)))) (display "(") (display (proc:scheme-name procrec)) (for-each (lambda (arg) (display " ") (display (cadr arg))) (proc:args procrec)) (display ")") (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (display "[From ") (display (doc:file procdocrec)) (display ":") (display (doc:line procdocrec)) (display "]") (newline) (newline) (display #\014) (newline)))) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (basic-extract-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (basic-extract-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (basic-extract-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (loop (counting-read-line p) (cons (list 'SCWM_PROC (list (car doc) (cadr doc)) filename linenum) defs)))) (docstart (loop (counting-read-line p) (cons (list 'DOC (extract-doc p line) filename linenum) defs))) (else (loop (counting-read-line p) defs)))))))) (define (extract-proc-n-doc line p) (let ((proc-string (match-parentheses line p))) (parse-proc proc-string (extract-doc p)))) (define (extract-doc p . line) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? line) (counting-read-line p) (car line)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-proc defstring docstring) (list (parse-def-string defstring) docstring)) (define (parse-def-string defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) defstring))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Aug 2 10:50:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA17263 for scwm-discuss-outgoing; Sun, 2 Aug 1998 10:50:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA17260 for ; Sun, 2 Aug 1998 10:50:55 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA20450; Sun, 2 Aug 98 10:51:18 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA31658; Sun, 2 Aug 1998 17:50:48 +0300 To: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Aug 1998 17:50:48 +0300 In-Reply-To: hjstein@bfr.co.il's message of "02 Aug 1998 16:07:59 +0300" Message-Id: Lines: 20 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I got sick of having an extract-docs sitting around which is written > in perl, so I started writing a scheme version. Are there any docs for the syntax of the embedded documentation? I naively assumed '/**' would start an embedded doc string & '*/' would end it, but this also extracts things like: /*****************************************************************************/ /** Copyright 1988 by Evans & Sutherland Computer Corporation, **/ /** Salt Lake City, Utah **/ for example, as 3 separate doc lines. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Aug 2 11:28:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA17462 for scwm-discuss-outgoing; Sun, 2 Aug 1998 11:28:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA17459 for ; Sun, 2 Aug 1998 11:28:19 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA22677; Sun, 2 Aug 98 11:28:42 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA31826; Sun, 2 Aug 1998 18:28:07 +0300 To: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Aug 1998 18:28:07 +0300 In-Reply-To: hjstein@bfr.co.il's message of "02 Aug 1998 17:50:48 +0300" Message-Id: Lines: 269 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk New version. Fixes bug in extracting DOC strings (was missing 2nd line of docs because of order of argument evaluation). Issue regarding /***... still exists. ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; (basic-extract-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; Note: ;;; 1. I added (DOC ...) records as an afterthought. They need more ;;; structure. ;;; 2. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things. (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*(.*)")) ; Strip off (spaces /** spaces) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:arg-count procrec) (list-ref procrec 2)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (doc:type rec) (list-ref rec 0)) (define (doc:data rec) (list-ref rec 1)) (define (doc:file rec) (list-ref rec 2)) (define (doc:line rec) (list-ref rec 3)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document extracted from the specified files. (define (output-proclist . files) (for-each list-proc (apply basic-extract-from-files files))) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (list-proc procdocrec) (if (eq? 'SCWM_PROC (doc:type procdocrec)) (let ((procrec (procdoc:decl (doc:data procdocrec))) (docrec (procdoc:doc (doc:data procdocrec)))) (display "(") (display (proc:scheme-name procrec)) (for-each (lambda (arg) (display " ") (display (cadr arg))) (proc:args procrec)) (display ")") (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (display "[From ") (display (doc:file procdocrec)) (display ":") (display (doc:line procdocrec)) (display "]") (newline) (newline) (display #\014) (newline)))) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (basic-extract-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (basic-extract-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (basic-extract-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (loop (counting-read-line p) (cons (list 'SCWM_PROC (list (car doc) (cadr doc)) filename linenum) defs)))) (docstart (let ((doc (extract-doc p line))) (loop (counting-read-line p) (cons (list 'DOC doc filename linenum) defs)))) (else (loop (counting-read-line p) defs)))))))) (define (extract-proc-n-doc line p) (let ((proc-string (match-parentheses line p))) (parse-proc proc-string (extract-doc p)))) (define (extract-doc p . line) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? line) (counting-read-line p) (car line)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-proc defstring docstring) (list (parse-def-string defstring) docstring)) (define (parse-def-string defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) defstring))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Aug 2 12:44:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA18005 for scwm-discuss-outgoing; Sun, 2 Aug 1998 12:44:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA18002 for ; Sun, 2 Aug 1998 12:44:56 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28074; Sun, 2 Aug 98 12:45:20 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA25977; Sun, 2 Aug 1998 09:44:47 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Greg Badros Date: 02 Aug 1998 09:44:47 -0700 In-Reply-To: hjstein@bfr.co.il's message of "02 Aug 1998 18:28:07 +0300" Message-Id: Lines: 43 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > New version. Fixes bug in extracting DOC strings (was missing 2nd > line of docs because of order of argument evaluation). Issue > regarding /***... still exists. Cool -- I'm excited to see you've taken the initiative to start a rewrite on the documentation extractor. The guile folks are probably even happier (since it'd be a major faux pas for them to include a perl script with the guile distribution). A couple of notes about what the perl version does that any guile version will need to replicate before it can replace the perl version: o SCWM_PROC (or SCWM_SYMBOL -- but the latter is not done yet) are used to find /** comments for procedures or symbols. /**IDENTIFIER is used for other things, e.g., /**CONCEPT or /**HOOK. Whitespace is currently permitted after the /**, but no more than two *'s. o The extractor needs to do all the warning generation that the current system does -- e.g., if #define FUNC_NAME doesn't exist or doesn't match the name of the function, we need to know about it. Similarly, if the number of arguments defined doesn't match the argument list. Also, I force the all-uppercase words to refer to formal parameters, and `words' to refer to another procedure. And all formal parameter names must be mentioned in that procedure's comment. o It's nice to have an option to use ispell to spellcheck the comments. Not all of us have emacs versions that permit spellchecking of just comments, and doing it from within the extractor provides a bit more flexibility, too. (See how my code does this using `ispell -a'. Unfortunately, as is often the case with prototypes, the best documentation is the Perl code itself (and the output it generates currently). If you have any questions about the perl code, I'm sure I can help with the semantics of the language. (Not sure if your guile version already does any of the above -- I've not looked at it yet). Thanks! Greg From owner-scwm-discuss@mit.edu Sun Aug 2 13:09:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA18165 for scwm-discuss-outgoing; Sun, 2 Aug 1998 13:09:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA18162 for ; Sun, 2 Aug 1998 13:09:22 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA09927; Sun, 2 Aug 98 13:09:08 EDT Received: from 192.168.1.1 (root@INS169.tokyo-ap4.dti.ne.jp [210.159.155.223]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id CAA06634 for ; Mon, 3 Aug 1998 02:09:15 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id CAA04037 for ; Mon, 3 Aug 1998 02:09:13 +0900 Message-Id: <199808021709.CAA04037@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> <199807292228.HAA25020@192.168.1.1> <199807302111.GAA06992@192.168.1.1> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: ITANI Eiichiro's message of "Fri, 31 Jul 1998 06:11:55 +0900" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Mon, 03 Aug 1998 02:09:12 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I wrote: > Greg Badros writes: > > > Tonight's snapshot will have my version of the I18N changes -- I look > > forward to knowing if they worked for you. > > I tried 19980730, just one fix. :) There still were some problems remain :-< Menu didn't work. In drawmenu.c, there still are wrong args calling ComputeXTextWidth. Because I still have not looked hard at recent scwm codes, this is just a dirty hack. I tried this with both --enable-multibyte and no multibyte environment, it seems working. This patch is applicable for 19980802 snapshot at least. Please clean up this code. :-) -- Eiichiro ITANI diff -ru scwm.orig/drawmenu.c scwm/drawmenu.c --- scwm.orig/drawmenu.c Mon Aug 3 01:56:20 1998 +++ scwm/drawmenu.c Mon Aug 3 01:56:39 1998 @@ -120,8 +120,8 @@ void DrawUnderline(Window w, scwm_font *scfont, GC gc, char *sz, int x, int y, int posn) { - int cpixStart = ComputeXTextWidth(scfont->xfs, sz, posn); - int cpixEnd = ComputeXTextWidth(scfont->xfs, sz, posn + 1) - 1; + int cpixStart = ComputeXTextWidth(XFONT_FONTTYPE(scfont), sz, posn); + int cpixEnd = ComputeXTextWidth(XFONT_FONTTYPE(scfont), sz, posn + 1) - 1; XDrawLine(dpy, w, gc, x + cpixStart, y + 2, x + cpixEnd, y + 2); } @@ -358,7 +358,7 @@ int item_height = MENU_ITEM_EXTRA_VERT_SPACE * 2; pmiim->cpixOffsetY = total_height; - text_width = ComputeXTextWidth(scfont->xfs, pmi->szLabel, pmi->cchLabel); + text_width = ComputeXTextWidth(XFONT_FONTTYPE(scfont), pmi->szLabel, pmi->cchLabel); DBUG(__FUNCTION__,"`%s' has width %d (%d chars)\n", pmi->szLabel,text_width,pmi->cchLabel); @@ -368,7 +368,7 @@ } else { /* szLabel we know is not null, but szExtra can be */ if (pmi->szExtra) { - extra_text_width = ComputeXTextWidth(scfont->xfs, + extra_text_width = ComputeXTextWidth(XFONT_FONTTYPE(scfont), pmi->szExtra, pmi->cchExtra); } diff -ru scwm.orig/xmisc.c scwm/xmisc.c --- scwm.orig/xmisc.c Mon Aug 3 01:56:20 1998 +++ scwm/xmisc.c Mon Aug 3 01:56:39 1998 @@ -284,7 +284,7 @@ Takes the font as an XFontStruct or an XFontSet depending on i18n support; the arg passed is XFONT(scmFont) */ int -ComputeXTextWidth(XFONT_TYPE *pxfs, const char *sz, int cch) +ComputeXTextWidth(XFONT_TYPE pxfs, const char *sz, int cch) { if (cch < 0) cch = strlen(sz); diff -ru scwm.orig/xmisc.h scwm/xmisc.h --- scwm.orig/xmisc.h Mon Aug 3 01:56:20 1998 +++ scwm/xmisc.h Mon Aug 3 01:56:39 1998 @@ -38,11 +38,13 @@ #ifdef I18N #define XFONT_TYPE XFontSet +#define XFONT_FONTTYPE(X) ((X)->fontset) #else -#define XFONT_TYPE XFontStruct +#define XFONT_TYPE XFontStruct * +#define XFONT_FONTTYPE(X) ((X)->xfs) #endif -int ComputeXTextWidth(XFONT_TYPE *pxfs, const char *sz, int cch); +int ComputeXTextWidth(XFONT_TYPE pxfs, const char *sz, int cch); #undef ScwmWindow From owner-scwm-discuss@mit.edu Sun Aug 2 13:27:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA18293 for scwm-discuss-outgoing; Sun, 2 Aug 1998 13:27:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA18290 for ; Sun, 2 Aug 1998 13:27:49 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA01355; Sun, 2 Aug 98 13:28:15 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA26027; Sun, 2 Aug 1998 10:27:44 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: fix for I18N References: <199807291951.EAA22962@192.168.1.1> <199807292228.HAA25020@192.168.1.1> <199807302111.GAA06992@192.168.1.1> <199808021709.CAA04037@192.168.1.1> From: Greg Badros Date: 02 Aug 1998 10:27:44 -0700 In-Reply-To: ITANI Eiichiro's message of "Mon, 03 Aug 1998 02:09:12 +0900" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > I wrote: > > > Greg Badros writes: > > > > > Tonight's snapshot will have my version of the I18N changes -- I look > > > forward to knowing if they worked for you. > > > > I tried 19980730, just one fix. :) > > There still were some problems remain :-< > Menu didn't work. > > In drawmenu.c, there still are wrong args calling ComputeXTextWidth. > Because I still have not looked hard at recent scwm codes, this is > just a dirty hack. I tried this with both --enable-multibyte and no > multibyte environment, it seems working. This patch is applicable for > 19980802 snapshot at least. Looks like good changes -- not at all a dirty hack. I've applied and am testing now. Thanks! Greg From owner-scwm-discuss@mit.edu Sun Aug 2 15:48:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18984 for scwm-discuss-outgoing; Sun, 2 Aug 1998 15:48:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA18981 for ; Sun, 2 Aug 1998 15:48:07 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA20880; Sun, 2 Aug 98 15:47:55 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfast06957; Sun, 2 Aug 1998 19:47:52 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA18078; Sun, 2 Aug 1998 15:46:17 -0400 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "02 Aug 1998 09:44:47 -0700" Date: 02 Aug 1998 15:46:17 -0400 Message-Id: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 02 Aug 1998 09:44:47 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: extract-docs partially rewritten in scheme.": >> >> o It's nice to have an option to use ispell to spellcheck the comments. >> Not all of us have emacs versions that permit spellchecking of just >> comments, and doing it from within the extractor provides a bit more >> flexibility, too. (See how my code does this using `ispell -a'. It is (almost) meaningless to fix spelling in the extracted file without fixing the spelling in the source file. I am not sure what the perl script does, but I think that it should fix the errors in the sources. (just my 2c) -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Garbage In, Gospel Out From owner-scwm-discuss@mit.edu Sun Aug 2 22:53:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA22173 for scwm-discuss-outgoing; Sun, 2 Aug 1998 22:53:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA22170 for ; Sun, 2 Aug 1998 22:53:17 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA16257; Sun, 2 Aug 98 22:53:40 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id LAA18549 for ; Mon, 3 Aug 1998 11:53:10 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id LAA02588 for ; Mon, 3 Aug 1998 11:53:08 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id LAA02850; Mon, 3 Aug 1998 11:54:17 +0900 To: scwm-discuss@mit.edu Subject: Great flexibility X-Mailer: Mew version 1.93b38 on XEmacs 21.2 (Aeolus) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980803115417K.senda@ic.rdc.ricoh.co.jp> Date: Mon, 03 Aug 1998 11:54:17 +0900 X-Dispatcher: imput version 980522 Lines: 62 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, It may be obvious to everyone ... By writing following script, I'm really aware that scwm has great flexibility by adopting guile as a scripting language. It is impossible to write a same script in other window managers. S.Senda ;;;;;;;; rlogin menu making from .rhosts file ;;;;;;;;; (define (make-rhosts-menu) (false-if-exception (let* ((rhostfn (string-append HOME "/.rhosts")) (termprog "xterm") (p (open-input-file rhostfn)) (ret '()) (ap (lambda (a) (set! ret (append ret (list a))))) (mm (lambda (h u) (menuitem h #:action (lambda () (execute (string-append termprog " -e rlogin " h " -l " u)))))) ) (ap (menuitem ".rhosts" #f)) (ap menu-title) (do ((l (read-line p 'trim) (read-line p 'trim))) ((eof-object? l) ret) (cond ((string-match "([^ \t]+)[ \t]+([^ \t]+)" l) => (lambda (m) (ap (mm (match:substring m 1) ; machine name (match:substring m 2))) ; user name )))) (ap menu-title) (ap (menuitem "reread .rhosts file" #:action (lambda () (set! rhosts-menu (make-rhosts-menu))))) (menu ret) ))) (define rhosts-menu (make-rhosts-menu)) ..... (define util-menu (menu (list (menuitem "utilities" #f) menu-title ..... (menuitem "from .rhost" #:action 'rhosts-menu) ..... ))) From owner-scwm-discuss@mit.edu Mon Aug 3 07:11:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA24764 for scwm-discuss-outgoing; Mon, 3 Aug 1998 07:11:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA24761 for ; Mon, 3 Aug 1998 07:11:14 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01449 for scwm-discuss@huis-clos.mit.edu; Mon, 3 Aug 1998 13:11:10 +0200 (CEST) Received: (qmail 3328 invoked by uid 115); 3 Aug 1998 08:23:40 -0000 To: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980803115417K.senda@ic.rdc.ricoh.co.jp> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Aug 1998 10:23:39 +0200 In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Mon, 03 Aug 1998 11:54:17 +0900" Message-ID: Lines: 30 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 03 Aug 1998 11:54:17 +0900 >>>>> senda@ic.rdc.ricoh.co.jp said: senda> By writing following script, I'm really aware that scwm has senda> great flexibility by adopting guile as a scripting language. I was equally thrilled when I wrote the piece of code that automatically queried my xlock about availiable modes. There is real power in having a computational complete language under the hood. senda> It is impossible to write a same script in other window senda> managers. To think of the m4 convolutions I went through just to make my .fvwm2rc portable to a few slightly different machines ... [code snipped] What other clever things do people want their wm to do? I'd like to start a brainstorming. This will be really good show-off material. Most wms look somewhat nice. Our strong point is flexibility, rivalled only by few(?) other wms. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 3 07:11:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA24769 for scwm-discuss-outgoing; Mon, 3 Aug 1998 07:11:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA24766 for ; Mon, 3 Aug 1998 07:11:25 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01523 for scwm-discuss@huis-clos.mit.edu; Mon, 3 Aug 1998 13:11:23 +0200 (CEST) Received: (qmail 3312 invoked by uid 115); 3 Aug 1998 08:11:56 -0000 To: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Aug 1998 10:11:54 +0200 In-Reply-To: Sam Steingold's message of "02 Aug 1998 15:46:17 -0400" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 02 Aug 1998 15:46:17 -0400 >>>>> Sam Steingold said: Sam> It is (almost) meaningless to fix spelling in the extracted file Sam> without fixing the spelling in the source file. extract-docs just prints a warning when encountering a word unknown to ispell. Automatic fixing would be to hard, because the word may be valid nevertheless. Greg, wouldn't it be nicer to have the list of known correct words in a separate file (e.g. "utilities/dev/ispell.dict") that is handed to ispell with "-p" rather than in an array in the perl script? This list will probably grow a lot as people will write docstrings. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 3 10:02:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA25524 for scwm-discuss-outgoing; Mon, 3 Aug 1998 10:02:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA25518 for ; Mon, 3 Aug 1998 10:01:57 -0400 Received: from scatterbrain.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA19345; Mon, 3 Aug 98 10:02:21 EDT Received: (from esuci@localhost) by scatterbrain.dcs.warwick.ac.uk (8.8.8/8.8.8) id PAA21867; Mon, 3 Aug 1998 15:01:45 +0100 (BST) Message-Id: <19980803150144.34650@dcs.warwick.ac.uk> Date: Mon, 3 Aug 1998 15:01:44 +0100 From: Michael Stevens To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980803115417K.senda@ic.rdc.ricoh.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Robert Bihlmeyer on Mon, Aug 03, 1998 at 10:23:39AM +0200 X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Mon, Aug 03, 1998 at 10:23:39AM +0200, Robert Bihlmeyer wrote: > What other clever things do people want their wm to do? I'd like to > start a brainstorming. This will be really good show-off material. > Most wms look somewhat nice. Our strong point is flexibility, rivalled > only by few(?) other wms. Ideas: Automatically generate a menu from a given directory - show all executable files in that directory. Possibly a hierarchy of 'a', 'b', 'c' menus if there are a large number of files. Only show menu items for files which are present and executable. Warn if a menu item tries to execute a program which is not present or not executable. Watch to see if (for example) netscape bus errors 30 seconds after you start it (is this possible?) Generate menus in same way as above from /etc/hosts - possibly poll all hosts occasionally to see if they support rsh/ssh/telnet connections, use the appropriate ones, and cache the results. A 'never see this class of window again' menu option for, for example, netscape's more annoying popups - to work without having to write any code, although it would produce easily modifiable code. Some sort of framework to allow applications to request/insist on particular types of decoration (hints? I'm not aware of the details of pre-existing features in this area). That's just 5 minutes thought. -- michael@rmta.org From owner-scwm-discuss@mit.edu Mon Aug 3 11:13:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA25940 for scwm-discuss-outgoing; Mon, 3 Aug 1998 11:13:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA25937 for ; Mon, 3 Aug 1998 11:13:18 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA06883; Mon, 3 Aug 98 11:13:00 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA00789 for ; Mon, 3 Aug 1998 11:12:56 -0400 (EDT) Message-Id: <199808031512.LAA00789@jekyll.piermont.com> To: scwm-discuss@mit.edu Subject: Re: Great flexibility In-Reply-To: Your message of "Mon, 03 Aug 1998 11:54:17 +0900." <19980803115417K.senda@ic.rdc.ricoh.co.jp> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Aug 1998 11:12:56 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk There ought to be a "recipes for scwm" section in the manual with little hacks like this. Even a directory of them would be cool. .pm senda@ic.rdc.ricoh.co.jp writes: > > Hi, > > It may be obvious to everyone ... > > By writing following script, > I'm really aware that scwm has great flexibility by adopting guile as > a scripting language. > > It is impossible to write a same script in other window managers. > > > S.Senda > > > ;;;;;;;; rlogin menu making from .rhosts file ;;;;;;;;; > > (define (make-rhosts-menu) > (false-if-exception > (let* ((rhostfn (string-append HOME "/.rhosts")) > (termprog "xterm") > (p (open-input-file rhostfn)) > (ret '()) > (ap (lambda (a) > (set! ret (append ret (list a))))) > (mm (lambda (h u) > (menuitem h #:action > (lambda () (execute > (string-append termprog " -e rlogin " > h " -l " u)))))) > ) > (ap (menuitem ".rhosts" #f)) > (ap menu-title) > (do ((l (read-line p 'trim) (read-line p 'trim))) > ((eof-object? l) ret) > (cond ((string-match "([^ \t]+)[ \t]+([^ \t]+)" l) > => (lambda (m) > (ap (mm (match:substring m 1) ; machine name > (match:substring m 2))) ; user name > )))) > (ap menu-title) > (ap (menuitem "reread .rhosts file" #:action > (lambda () (set! rhosts-menu (make-rhosts-menu))))) > (menu ret) > ))) > > (define rhosts-menu (make-rhosts-menu)) > > ..... > > (define util-menu > (menu > (list > (menuitem "utilities" #f) > menu-title > ..... > > (menuitem "from .rhost" #:action 'rhosts-menu) > > ..... > ))) > From owner-scwm-discuss@mit.edu Mon Aug 3 12:07:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA26440 for scwm-discuss-outgoing; Mon, 3 Aug 1998 12:07:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA26437 for ; Mon, 3 Aug 1998 12:07:22 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26781; Mon, 3 Aug 98 12:07:42 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA27908; Mon, 3 Aug 1998 09:07:08 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Greg Badros Date: 03 Aug 1998 09:07:08 -0700 In-Reply-To: Robert Bihlmeyer's message of "03 Aug 1998 10:11:54 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg, wouldn't it be nicer to have the list of known correct words in > a separate file (e.g. "utilities/dev/ispell.dict") that is handed to > ispell with "-p" rather than in an array in the perl script? This list > will probably grow a lot as people will write docstrings. Yep, probably. It was just easier to do in Perl initially. Unfortunately, there is no good way to add okay words to the "user dictionary" when you're not running ispell interactively (i.e. when it's just producing warnings about lines that may contain a mispelled word). This can be something that the guile version chooses to improve upon. Greg From owner-scwm-discuss@mit.edu Mon Aug 3 12:13:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA26501 for scwm-discuss-outgoing; Mon, 3 Aug 1998 12:13:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA26498 for ; Mon, 3 Aug 1998 12:13:08 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23564; Mon, 3 Aug 98 12:12:54 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA27911; Mon, 3 Aug 1998 09:09:44 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <199808031512.LAA00789@jekyll.piermont.com> From: Greg Badros Date: 03 Aug 1998 09:09:44 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 03 Aug 1998 11:12:56 -0400" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > There ought to be a "recipes for scwm" section in the manual with > little hacks like this. Even a directory of them would be cool. I agree-- the scheme/flux.scm contains snippets like this. And the scheme/tests/*.scm often have examples of usage of primitives, too. It'd be nice if we had a couple of FAQs -- one for scwm users, and one for scwm developers. If we use docbook for the FAQs, they could be chapters in the growing manual. Any takers?? Greg From owner-scwm-discuss@mit.edu Mon Aug 3 12:49:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA27326 for scwm-discuss-outgoing; Mon, 3 Aug 1998 12:49:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA27319 for ; Mon, 3 Aug 1998 12:49:34 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08713; Mon, 3 Aug 98 12:49:59 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA06136; Mon, 3 Aug 1998 19:49:15 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Aug 1998 19:49:15 +0300 In-Reply-To: Greg Badros's message of "02 Aug 1998 09:44:47 -0700" Message-Id: Lines: 49 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > o SCWM_PROC (or SCWM_SYMBOL -- but the latter is not done yet) are used > to find /** comments for procedures or symbols. /**IDENTIFIER is used > for other things, e.g., /**CONCEPT or /**HOOK. Whitespace is currently > permitted after the /**, but no more than two *'s. But what differentiates comments like: /** Copyright 1988 by Evans & Sutherland Computer Corporation, **/ from embedded documentation? Are you saying that it must be '/**' after SCWM_PROC or '/**IDENTIFIER:' otherwise? > o The extractor needs to do all the warning generation that the current > system does -- e.g., if #define FUNC_NAME doesn't exist or doesn't match > the name of the function, we need to know about it. Similarly, if the > number of arguments defined doesn't match the argument list. Also, I > force the all-uppercase words to refer to formal parameters, and `words' > to refer to another procedure. And all formal parameter names must be > mentioned in that procedure's comment. Do you have a list of things that SCWM_PROC(..) should satisfy? What's #define FUNC_NAME? Are you saying that the 1st arg to SCWM_PROC should be some mutilation of the 2nd, and that the 3rd arg should = the # of args in the 6th argument? What do you mean "force the all-uppercase words..."? Do you also check that all args are of type SCM, or is that not necessary? > o It's nice to have an option to use ispell to spellcheck the comments. > Not all of us have emacs versions that permit spellchecking of just > comments, and doing it from within the extractor provides a bit more > flexibility, too. (See how my code does this using `ispell -a'. What about just having a fcn for extracting all the text from the documentation & running that through ispell? Would that be sufficient functionality? > (Not sure if your guile version already does any of the above -- I've > not looked at it yet). Nope - no checking yet, no sgml output, no ispell. Do you have any general points on sgml generation? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 3 13:05:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA27582 for scwm-discuss-outgoing; Mon, 3 Aug 1998 13:05:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA27579 for ; Mon, 3 Aug 1998 13:05:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06699; Mon, 3 Aug 98 13:04:56 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA27992; Mon, 3 Aug 1998 10:05:00 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Greg Badros Date: 03 Aug 1998 10:05:00 -0700 In-Reply-To: hjstein@bfr.co.il's message of "03 Aug 1998 19:49:15 +0300" Message-Id: Lines: 93 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > o SCWM_PROC (or SCWM_SYMBOL -- but the latter is not done yet) are used > > to find /** comments for procedures or symbols. /**IDENTIFIER is used > > for other things, e.g., /**CONCEPT or /**HOOK. Whitespace is currently > > permitted after the /**, but no more than two *'s. > > But what differentiates comments like: > > /** Copyright 1988 by Evans & Sutherland Computer Corporation, **/ > > from embedded documentation? Are you saying that it must be '/**' > after SCWM_PROC or '/**IDENTIFIER:' otherwise? Yep. This is the regexp I use: if (m%/\*\*\s*(\w[^:]*):\s*(.*?)\s*$%) ^^ space ^^ alphanumeric + _ ^ *? => non-greedy (removes trailing spaces) > > o The extractor needs to do all the warning generation that the current > > system does -- e.g., if #define FUNC_NAME doesn't exist or doesn't match > > the name of the function, we need to know about it. Similarly, if the > > number of arguments defined doesn't match the argument list. Also, I > > force the all-uppercase words to refer to formal parameters, and `words' > > to refer to another procedure. And all formal parameter names must be > > mentioned in that procedure's comment. > > Do you have a list of things that SCWM_PROC(..) should satisfy? Look at the ProcessHeader function of the perl version. There are about five warnings, each one of which is indicative of something that should've been satisfied. > What's #define FUNC_NAME? #define FUNC_NAME is the convention that that macro "FUNC_NAME" should always be the name of the current primitive that the code is a part of, or undefined, if we're not in a primitive. The macro is then used in throwing errors, and it's essential that we check to make sure the right function name is referred to (since the compiler won't help us at all). > Are you saying that the 1st arg to SCWM_PROC should be some mutilation > of the 2nd, and that the 3rd arg should = the # of args in the 6th > argument? What do you mean "force the all-uppercase words..."? Do > you also check that all args are of type SCM, or is that not > necessary? Basically. Except the 3rd + 4th + 5th should be the # of args in the 6th (3rd = # required args, 4th = # optional args, 5th = 0 or 1, based on whether there is a final vararg parameter). I just count how many occurrences of SCM there are in the argument list, and make sure that matches the number of arguments (determined by splitting on commas). It's not perfect, but most other mistakes are caught be the compiler. > > o It's nice to have an option to use ispell to spellcheck the comments. > > Not all of us have emacs versions that permit spellchecking of just > > comments, and doing it from within the extractor provides a bit more > > flexibility, too. (See how my code does this using `ispell -a'. > > What about just having a fcn for extracting all the text from the > documentation & running that through ispell? Would that be sufficient > functionality? As long as line numbers were preserved so we could find where in the original text the spelling mistake is. It's pretty easy to start an ispell -a and talk to it with the words -- the only tricky part was in figuring out what ispell -a considered to be a word -- I now split the text on [\d\W]+ (i.e., separate into words at digits and non-alphanumerics). > > > (Not sure if your guile version already does any of the above -- I've > > not looked at it yet). > > Nope - no checking yet, no sgml output, no ispell. > > Do you have any general points on sgml generation? The perl script doesn't do anything fancy -- it does a full pass over the files to extract all the information, then just starts writing the chapters using that extracted information. The perl source should be sufficient for understanding what I do, but feel free to ask questions about it if you can't figure out some of the more esoteric Perl constructs (which I generally avoid when prototyping in Perl, so hopefully it's not too bad). Good luck-- I know the guile folks will be excited once you get the rewrite working. Greg From owner-scwm-discuss@mit.edu Mon Aug 3 14:49:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00536 for scwm-discuss-outgoing; Mon, 3 Aug 1998 14:49:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00532 for ; Mon, 3 Aug 1998 14:49:50 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA12548; Mon, 3 Aug 98 14:50:10 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA01241; Mon, 3 Aug 1998 14:49:21 -0400 (EDT) Message-Id: <199808031849.OAA01241@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: Great flexibility In-Reply-To: Your message of "03 Aug 1998 09:09:44 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 03 Aug 1998 14:49:20 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > It'd be nice if we had a couple of FAQs -- one for scwm users, and one > for scwm developers. If we use docbook for the FAQs, they could be > chapters in the growing manual. Any takers?? Is there a good docbook document/homepage out there somewhere? Perry From owner-scwm-discuss@mit.edu Mon Aug 3 15:14:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA00840 for scwm-discuss-outgoing; Mon, 3 Aug 1998 15:14:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA00755; Mon, 3 Aug 1998 15:09:08 -0400 Message-Id: <199808031909.PAA00755@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: Great flexibility In-reply-to: Your message of "Mon, 03 Aug 1998 14:49:20 EDT." <199808031849.OAA01241@jekyll.piermont.com> Date: Mon, 03 Aug 1998 15:09:08 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Greg Badros writes: > > > > It'd be nice if we had a couple of FAQs -- one for scwm users, and one > > for scwm developers. If we use docbook for the FAQs, they could be > > chapters in the growing manual. Any takers?? > > Is there a good docbook document/homepage out there somewhere? > The quasi-official homepage is at: http://www.oreilly.com/davenport/ A good intro for hackers especially is at: http://nis-www.lanl.gov/~rosalia/mydocs/docbook-intro.html (but the machine the latter is on seems to be down at the moment) - Maciej From owner-scwm-discuss@mit.edu Mon Aug 3 15:20:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA00933 for scwm-discuss-outgoing; Mon, 3 Aug 1998 15:20:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA00924; Mon, 3 Aug 1998 15:20:35 -0400 Message-Id: <199808031920.PAA00924@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: opaque resize In-reply-to: Your message of "27 Jul 1998 19:18:16 EDT." Date: Mon, 03 Aug 1998 15:20:25 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk (Catching up on replies to old scwm mail) sds@goems.com writes: > opaque resize is way cool, but it displays the current size in pixels, > not characters, which is important for emacs and xterm. > X11 defines a number of minimum size, maximum size and size increment hints which are what usually makes this work right. I am not sure if scwm is supporting them at all properly right now, but we should. This should go on the TODO list (but for post-0.8). - Maciej From owner-scwm-discuss@mit.edu Mon Aug 3 15:29:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01084 for scwm-discuss-outgoing; Mon, 3 Aug 1998 15:29:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01081 for ; Mon, 3 Aug 1998 15:29:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24007; Mon, 3 Aug 98 15:29:35 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA28354; Mon, 3 Aug 1998 12:28:46 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <199808031849.OAA01241@jekyll.piermont.com> From: Greg Badros Date: 03 Aug 1998 12:28:46 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 03 Aug 1998 14:49:20 -0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > > > It'd be nice if we had a couple of FAQs -- one for scwm users, and one > > for scwm developers. If we use docbook for the FAQs, they could be > > chapters in the growing manual. Any takers?? > > Is there a good docbook document/homepage out there somewhere? Here are a couple of useful links: http://www.oreilly.com/davenport/ http://www.ora.com/homepages/dtdparse/docbook/3.0/ http://www.jclark.com/jade/ I thought I remembered something about some tools for FAQ maintainers available on the web, but I couldn't find it in a brief search of my bookmarks. The best thing to do is probably come up with a skeleton ... example listing a couple of questions, and post it for feedback and comments. You could also look around at how other projects manage their FAQs. We might get a bit of leverage out of processing the FAQ chapter to add cross-references to the reference sections. Greg From owner-scwm-discuss@mit.edu Mon Aug 3 15:31:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01136 for scwm-discuss-outgoing; Mon, 3 Aug 1998 15:31:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01129 for ; Mon, 3 Aug 1998 15:31:25 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24553; Mon, 3 Aug 98 15:31:47 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA28363; Mon, 3 Aug 1998 12:31:19 -0700 (PDT) To: Maciej Stachowiak Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: opaque resize References: <199808031920.PAA00924@huis-clos.mit.edu> From: Greg Badros Date: 03 Aug 1998 12:31:18 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 03 Aug 1998 15:20:25 EDT" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > (Catching up on replies to old scwm mail) > > sds@goems.com writes: > > opaque resize is way cool, but it displays the current size in pixels, > > not characters, which is important for emacs and xterm. > > > > X11 defines a number of minimum size, maximum size and size increment > hints which are what usually makes this work right. I am not sure if > scwm is supporting them at all properly right now, but we should. This > should go on the TODO list (but for post-0.8). I fixed this a while back -- it was just a trivial change from not doing the right thing when simplifying and generalizing the Message window stuff. The other problem is with maximization not remembering the real units, and instead always returning to the prior pixel size. That hasn't yet been fixed, and is in the BUGS file. Greg From owner-scwm-discuss@mit.edu Mon Aug 3 16:29:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01848 for scwm-discuss-outgoing; Mon, 3 Aug 1998 16:29:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01844; Mon, 3 Aug 1998 16:29:26 -0400 Message-Id: <199808032029.QAA01844@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: TODO list Date: Mon, 03 Aug 1998 16:29:25 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I recently put the things I'd like to get done before the 0.8 release in the TODO file in CVS, and added some other commentary. If people have particular bug fixes or minor features they'd like to see before 0.8 (or any other comments), let me know. I will also continue going over the scwm mail backlog I have later today and save important things from there. I will also probably put the TODO file on the web later today for convenience. - Maciej From owner-scwm-discuss@mit.edu Mon Aug 3 16:54:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02059 for scwm-discuss-outgoing; Mon, 3 Aug 1998 16:54:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02056 for ; Mon, 3 Aug 1998 16:54:18 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17722; Mon, 3 Aug 98 16:54:36 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA07327; Mon, 3 Aug 1998 23:53:55 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Aug 1998 23:53:55 +0300 In-Reply-To: Greg Badros's message of "03 Aug 1998 10:05:00 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > What's #define FUNC_NAME? > > #define FUNC_NAME is the convention that that macro "FUNC_NAME" should > always be the name of the current primitive that the code is a part of, > or undefined, if we're not in a primitive. The macro is then used in > throwing errors, and it's essential that we check to make sure the right > function name is referred to (since the compiler won't help us at all). That sucks. There's no way around that? Also, is it always the 1st argument of SCWM_PROC with "s_" prepended? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 3 17:01:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02152 for scwm-discuss-outgoing; Mon, 3 Aug 1998 17:01:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA02149 for ; Mon, 3 Aug 1998 17:01:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA19752; Mon, 3 Aug 98 17:01:41 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA28913; Mon, 3 Aug 1998 14:01:08 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Greg Badros Date: 03 Aug 1998 14:01:08 -0700 In-Reply-To: hjstein@bfr.co.il's message of "03 Aug 1998 23:53:55 +0300" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > What's #define FUNC_NAME? > > > > #define FUNC_NAME is the convention that that macro "FUNC_NAME" should > > always be the name of the current primitive that the code is a part of, > > or undefined, if we're not in a primitive. The macro is then used in > > throwing errors, and it's essential that we check to make sure the right > > function name is referred to (since the compiler won't help us at all). > > That sucks. There's no way around that? Also, is it always the 1st > argument of SCWM_PROC with "s_" prepended? Yep. Nope. And yep. More generally, it's whatever SCWM_PROC defines the static variable that names the function to be, which in turn is what SCM_PROC does (which is prepend the s_). The closest thing you can get w/o enforcing this via a tool is __FUNCTION__, but that is: a) a GNU C extension b) the name of the C function, not the name of the Scheme primitive. Greg From owner-scwm-discuss@mit.edu Tue Aug 4 06:05:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA12871 for scwm-discuss-outgoing; Tue, 4 Aug 1998 06:05:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA12868 for ; Tue, 4 Aug 1998 06:05:33 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05252; Tue, 4 Aug 98 06:05:17 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA10664; Tue, 4 Aug 1998 13:05:13 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Embedded documentation syntax strictness. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Aug 1998 13:05:13 +0300 In-Reply-To: Greg Badros's message of "03 Aug 1998 14:01:08 -0700" Message-Id: Lines: 72 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk How strict do you guys want the embedded documentation syntax to be? For example, do you want to enforce: SCWM_PROC(...) /** ... */ #define FUNC_NAME ... Alternatives are: 1. Allow whitespace between the SCWM_PROC, the comment & the FUNC_NAME. 2. Allow the FUNC_NAME to come before the comment. 3. Allow whitespace before the #define. 4. Allow whitespace between the # & the define. 5. Allow whitespace before SCWM_PROC. 6. Allow whitespace between SCWM_PROC & (. 7. Allow other stuff to be interspersed. Case 1. occurs once in the source code & case 2. occurs twice. Case 3 occurs around 4 times. I don't think case 4 occurs. Also, do you want to enforce: /**identifier: ... */ for non proc related embedded documentation, or do you want to also allow /** identifier: ... */ The latter occurs about 5 times. I'd rather be more strict than less strict since a) it's easier to parse (a selfish reason) & b) it enforces a little uniformity on the code making it easier to read. extract-doc on the other hand, allows a fairly flexible format. Also, to what extent should the extractor enforce a particular set of keywords for non SCWM_PROC embedded documentation? extract-docs only allows HOOK & CONCEPT which seems to make it pretty scwm centric. I'd think that arbitrary identifiers should be allowed - it should be clear in the sgml output that you misspelled an identifier since you'll have an extra section, won't you? The alternative is to require an identifier list on the command line, which'd make the extractor a pain to run in general. BTW, I've noticed extract-doc gives a lot of perl warnings when run, such as: hjstein@blinky:~$ perl -w software/scwm/utilities/dev/extract-docs software/scwm/scwm/window.c Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line 177. Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 580. ... I assume these are to be ignored? What about errors like: software/scwm/scwm/window.c:637:****get_window: all-uppercase word `FIXMS' does not match an argument Do you really want to enforce that: a) all args appear at least once in the documentation, b) every occurrence of each arg is in upper case, and c) every upper case word matches an arg? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Aug 4 12:05:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14583 for scwm-discuss-outgoing; Tue, 4 Aug 1998 12:05:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA14580 for ; Tue, 4 Aug 1998 12:05:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12584; Tue, 4 Aug 98 12:05:45 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA06607; Tue, 4 Aug 1998 09:04:54 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: From: Greg Badros Date: 04 Aug 1998 09:04:54 -0700 In-Reply-To: hjstein@bfr.co.il's message of "04 Aug 1998 13:05:13 +0300" Message-Id: Lines: 135 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > How strict do you guys want the embedded documentation syntax to be? As strict as necessary, no stricter. :-) > > For example, do you want to enforce: > > SCWM_PROC(...) > /** ... */ > #define FUNC_NAME ... > > Alternatives are: > 1. Allow whitespace between the SCWM_PROC, the comment & the > FUNC_NAME. > 2. Allow the FUNC_NAME to come before the comment. > 3. Allow whitespace before the #define. > 4. Allow whitespace between the # & the define. > 5. Allow whitespace before SCWM_PROC. > 6. Allow whitespace between SCWM_PROC & (. > 7. Allow other stuff to be interspersed. > > Case 1. occurs once in the source code & case 2. occurs twice. Case 3 > occurs around 4 times. I don't think case 4 occurs. > > Also, do you want to enforce: > > /**identifier: ... */ > > for non proc related embedded documentation, or do you want to also > allow > > /** identifier: ... */ > > The latter occurs about 5 times. All the cases where the perl extract-docs chooses to allow whitespace are reasonable, IMO. My focus was on ease of writing the docs for the code developers. > > I'd rather be more strict than less strict since a) it's easier to > parse (a selfish reason) & b) it enforces a little uniformity on the > code making it easier to read. extract-doc on the other hand, allows > a fairly flexible format. Well, (a) falls apart since the only sensible way to be more strict is to catch the violations of the strictness, which means recognizing that it's close to okay, and warning about it, which means you still need the flexible scanner. (b) is reasonable, but a bit too harsh, IMO. We want the people writing the code to have as easy of a time as possible, and not be bothered by unimportant warnings and conventions if the tool can figure out what to do unambiguously. > > Also, to what extent should the extractor enforce a particular set of > keywords for non SCWM_PROC embedded documentation? extract-docs only > allows HOOK & CONCEPT which seems to make it pretty scwm centric. I'd It warns about other ones, and I just added VAR markers. A more generally framework would be nice, and if I had to do another type marker, I'd probably rework the perl version. > think that arbitrary identifiers should be allowed - it should be > clear in the sgml output that you misspelled an identifier since > you'll have an extra section, won't you? The alternative is to I think it's worth having a command line option to say what the expected markers are and then have extract-docs check. A little bit of redundancy in return for not having to read the SGML output is a good thing. > require an identifier list on the command line, which'd make the > extractor a pain to run in general. Not if you use `make' -- from scwm/doc, just "rm scwm.sgml; make scwm.sgml" and the right thing happens. Adding extra args to extract-docs would be no big deal since they're hidden in the Makefile. > > BTW, I've noticed extract-doc gives a lot of perl warnings when run, such > as: > hjstein@blinky:~$ perl -w software/scwm/utilities/dev/extract-docs software/scwm/scwm/window.c > Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line 177. > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 580. > ... > > I assume these are to be ignored? What Perl version are you using? I'm at 5.004_02, and don't get those warnings. Newer versions have often eliminated spurious warnings as Perl has gotten better at proving properties in the script. > > What about errors like: > > software/scwm/scwm/window.c:637:****get_window: all-uppercase word `FIXMS' does not match an argument These warnings I chose to leave in, but have often moved FIX comments out of the docstrings in the source code. I'd rather have too many warnings in the output than too few. At least until the too many starts being so many too many that it obscures the warnings that I care about (hence the options for controlling the set of warnings -- to reduce problems from false positives obscuring real warnings). > Do you really want to enforce that: > > a) all args appear at least once in the documentation, Yes. > b) every occurrence of each arg is in upper case, and No. I don't think this is enforced. You can talk about a `window' even when there is an arg `window' which is referred to using `WINDOW'. > c) every upper case word matches an arg? Not completely sure. Until it becomes a problem, yes. The one case that I think makes sense to relax things is within an SGML tag. I had a problem with talking about, e.g., the environment variable $HOME (it wasn't $HOME, but it was some environment variable). I got around it by making the $ a part of the identifier and then there was no longer a complaint. I imagine it's a bit harder to get some of these behaviours in guile than it was for me in perl, but I think in the long run it'll be well worth the effort. Thanks! Greg From owner-scwm-discuss@mit.edu Tue Aug 4 14:29:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA15566 for scwm-discuss-outgoing; Tue, 4 Aug 1998 14:29:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA15563 for ; Tue, 4 Aug 1998 14:29:04 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21918; Tue, 4 Aug 98 14:29:29 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id VAA13881; Tue, 4 Aug 1998 21:28:26 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Aug 1998 21:28:26 +0300 In-Reply-To: Greg Badros's message of "04 Aug 1998 09:04:54 -0700" Message-Id: Lines: 114 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > How strict do you guys want the embedded documentation syntax to be? > > As strict as necessary, no stricter. :-) The problem is that the more flexible you make the matching, the more likely you are to inadvertently pick up a comment unintended for documentation extraction. Maybe this isn't/wasn't a big deal for scwm, but it could be a big pain when trying to adapt it to a large existing package (aka guile). For example, I first tried extracting everything otf /** ... */. This grabbed way too many comments. Now I'm grabbing things like /** HOOK: ... *., but one could easily imagine a programmer wanting to have comments which look like: /*************************************/ /** There are 4 cases for food */ /** beer: ... */ /** wine: ... */ ... One really has to walk a thin line between strictness & loosness when dealing with embedded documentation. > > I'd rather be more strict than less strict since a) it's easier to > > parse (a selfish reason) & b) it enforces a little uniformity on the > > code making it easier to read. extract-doc on the other hand, allows > > a fairly flexible format. > > Well, (a) falls apart since the only sensible way to be more strict is > to catch the violations of the strictness, which means recognizing that > it's close to okay, and warning about it, which means you still need the > flexible scanner. Mostly not the case. For example, botched spacing & ordering conditions for the SCWM_PROC stuff would be notified by the missing-doc or missing-func_name error traps, at which point it'd be clear to the user what the problem is. > > require an identifier list on the command line, which'd make the > > extractor a pain to run in general. > > Not if you use `make' -- from scwm/doc, just "rm scwm.sgml; make > scwm.sgml" and the right thing happens. Adding extra args to > extract-docs would be no big deal since they're hidden in the Makefile. I was refering to general quick usage as in 'extract-docs foo.c'. Of course, almost anything can be scripted, but it's nice to have things usable without lots of additional input data/flags. > > BTW, I've noticed extract-doc gives a lot of perl warnings when run, such > > as: > > hjstein@blinky:~$ perl -w software/scwm/utilities/dev/extract-docs software/scwm/scwm/window.c > > Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line 177. > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 580. > > ... > > > > I assume these are to be ignored? > > What Perl version are you using? I'm at 5.004_02, and don't get those > warnings. Newer versions have often eliminated spurious warnings as > Perl has gotten better at proving properties in the script. hjstein@blinky:~$ perl -v This is perl, version 5.004_01 Quite an annoyance. > > Do you really want to enforce that: > > > > a) all args appear at least once in the documentation, > > Yes. > > > b) every occurrence of each arg is in upper case, and > > No. I don't think this is enforced. You can talk about a `window' even > when there is an arg `window' which is referred to using `WINDOW'. Oh, so then it's there must exist an upper case rendition of each arg? > > c) every upper case word matches an arg? > > Not completely sure. Until it becomes a problem, yes. The one case > that I think makes sense to relax things is within an SGML tag. I had a > problem with talking about, e.g., the environment variable $HOME (it > wasn't $HOME, but it was some environment variable). I got around it by > making the $ a part of the identifier and then there was no longer a > complaint. > > I imagine it's a bit harder to get some of these behaviours in guile > than it was for me in perl, but I think in the long run it'll be well > worth the effort. Well, I've relaxed the syntax to match extract-docs, and I have almost all the checks in place. I just basically need to do the sgml generation & package it as a runnable script. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Aug 4 14:49:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA15742 for scwm-discuss-outgoing; Tue, 4 Aug 1998 14:49:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA15739 for ; Tue, 4 Aug 1998 14:49:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27076; Tue, 4 Aug 98 14:49:28 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA08401; Tue, 4 Aug 1998 11:48:40 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: From: Greg Badros Date: 04 Aug 1998 11:48:40 -0700 In-Reply-To: hjstein@bfr.co.il's message of "04 Aug 1998 21:28:26 +0300" Message-Id: Lines: 157 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > > > How strict do you guys want the embedded documentation syntax to be? > > > > As strict as necessary, no stricter. :-) > > The problem is that the more flexible you make the matching, the more > likely you are to inadvertently pick up a comment unintended for > documentation extraction. Maybe this isn't/wasn't a big deal for > scwm, but it could be a big pain when trying to adapt it to a large > existing package (aka guile). > > For example, I first tried extracting everything otf /** ... */. This > grabbed way too many comments. Now I'm grabbing things like /** HOOK: > ... *., but one could easily imagine a programmer wanting to have > comments which look like: > > /*************************************/ > /** There are 4 cases for food */ > /** beer: ... */ > /** wine: ... */ > ... > > One really has to walk a thin line between strictness & loosness when > dealing with embedded documentation. The line that I was trying to walk is trying to pick stuff that looks like what we are interested in. I use: m%/\*\*\s*(\w[^:]*):\s*(.*?)\s*$% Which requires the /**, immediately followed by an alphanumeric identifier, followed by a colon. Plus I warn if the identifier isn't a known one. This seems to be good enough in practice. We could enforce that the identifier be all-uppercase, but I think your example is more contorted than we'll have to deal with. (I have trouble imagining a sane programming using the style above! :-) ). Certainly, you're right-- things aren't *perfect* -- but if they're good enough that we're not having to change the regexps for each new doc string a developer writes, then it's no big deal. Even if we do have to twiddle the regexps to apply extract-docs to a new project (e.g., guile), that's not a big deal (we already will need to parameterize the macro names -- guile shouldn't look for SCWM_PROC, and will need to do something a little bit different with SCM_PROC, unfortunately). > > > > > I'd rather be more strict than less strict since a) it's easier to > > > parse (a selfish reason) & b) it enforces a little uniformity on the > > > code making it easier to read. extract-doc on the other hand, allows > > > a fairly flexible format. > > > > Well, (a) falls apart since the only sensible way to be more strict is > > to catch the violations of the strictness, which means recognizing that > > it's close to okay, and warning about it, which means you still need the > > flexible scanner. > > Mostly not the case. For example, botched spacing & ordering > conditions for the SCWM_PROC stuff would be notified by the > missing-doc or missing-func_name error traps, at which point it'd be > clear to the user what the problem is. If those exceptions are caught and the appropriate warning message is output, that's fine. Note that one of the uses of the extractor is under compilation mode of emacs where we use C-x ` to go to the next error to fix the problem in the doc-comment. The problem shouldn't just be apparent from running the extractor, it should help me get there to fix the problem. > > > > > require an identifier list on the command line, which'd make the > > > extractor a pain to run in general. > > > > Not if you use `make' -- from scwm/doc, just "rm scwm.sgml; make > > scwm.sgml" and the right thing happens. Adding extra args to > > extract-docs would be no big deal since they're hidden in the Makefile. > > I was refering to general quick usage as in 'extract-docs foo.c'. Of > course, almost anything can be scripted, but it's nice to have things > usable without lots of additional input data/flags. I think that is more an issue for your debugging than for common, real-world usage. I had scripts that I used to aid my debugging and testing, but now it's less of an issue. > > > > BTW, I've noticed extract-doc gives a lot of perl warnings when run, such > > > as: > > > hjstein@blinky:~$ perl -w software/scwm/utilities/dev/extract-docs software/scwm/scwm/window.c > > > Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line 177. > > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 565. > > > Use of uninitialized value at software/scwm/utilities/dev/extract-docs line 480, <> chunk 580. > > > ... > > > > > > I assume these are to be ignored? > > > > What Perl version are you using? I'm at 5.004_02, and don't get those > > warnings. Newer versions have often eliminated spurious warnings as > > Perl has gotten better at proving properties in the script. > > hjstein@blinky:~$ perl -v > > This is perl, version 5.004_01 > > Quite an annoyance. Agreed. If I can find an older version of Perl lying around I'll try to change stuff to eliminate the false positive -w warnings. > > > > Do you really want to enforce that: > > > > > > a) all args appear at least once in the documentation, > > > > Yes. > > > > > b) every occurrence of each arg is in upper case, and > > > > No. I don't think this is enforced. You can talk about a `window' even > > when there is an arg `window' which is referred to using `WINDOW'. > > Oh, so then it's there must exist an upper case rendition of each > arg? Right -- I thought that's what you meant by (a). > > > c) every upper case word matches an arg? > > > > Not completely sure. Until it becomes a problem, yes. The one case > > that I think makes sense to relax things is within an SGML tag. I had a > > problem with talking about, e.g., the environment variable $HOME (it > > wasn't $HOME, but it was some environment variable). I got around it by > > making the $ a part of the identifier and then there was no longer a > > complaint. > > > > I imagine it's a bit harder to get some of these behaviours in guile > > than it was for me in perl, but I think in the long run it'll be well > > worth the effort. > > Well, I've relaxed the syntax to match extract-docs, and I have almost > all the checks in place. I just basically need to do the sgml > generation & package it as a runnable script. Excellent! The sgml generation shouldn't be too bad w/ my perl as an outline of what should get output. The most tedious part was figuring out what the docbook output should look like--testing with JADE was pretty slow. Thanks, Greg From owner-scwm-discuss@mit.edu Tue Aug 4 15:04:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA16004 for scwm-discuss-outgoing; Tue, 4 Aug 1998 15:04:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA15977 for ; Tue, 4 Aug 1998 15:03:55 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01066; Tue, 4 Aug 98 15:04:20 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA14095; Tue, 4 Aug 1998 22:03:46 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Aug 1998 22:03:46 +0300 In-Reply-To: Greg Badros's message of "04 Aug 1998 11:48:40 -0700" Message-Id: Lines: 126 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Greg Badros writes: > > > > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > > > > > How strict do you guys want the embedded documentation syntax to be? > > > > > > As strict as necessary, no stricter. :-) > > > > The problem is that the more flexible you make the matching, the more > > likely you are to inadvertently pick up a comment unintended for > > documentation extraction. Maybe this isn't/wasn't a big deal for > > scwm, but it could be a big pain when trying to adapt it to a large > > existing package (aka guile). > > > > For example, I first tried extracting everything otf /** ... */. This > > grabbed way too many comments. Now I'm grabbing things like /** HOOK: > > ... *., but one could easily imagine a programmer wanting to have > > comments which look like: > > > > /*************************************/ > > /** There are 4 cases for food */ > > /** beer: ... */ > > /** wine: ... */ > > ... > > > > One really has to walk a thin line between strictness & loosness when > > dealing with embedded documentation. > > The line that I was trying to walk is trying to pick stuff that looks > like what we are interested in. I use: > > m%/\*\*\s*(\w[^:]*):\s*(.*?)\s*$% > > Which requires the /**, immediately followed by an alphanumeric > identifier, followed by a colon. Plus I warn if the identifier isn't > a known one. This seems to be good enough in practice. We could > enforce that the identifier be all-uppercase, but I think your example > is more contorted than we'll have to deal with. (I have trouble > imagining a sane programming using the style above! :-) ). That sounds ok to me, except that I added whitespace btw /** & the identifier because there are 3 instances of that in the scwm C code: grep -ni '/\*\*.*:' *.c /dev/null add_window.c:781: /**HOOK: before-new-window-hook add_window.c:794: /**HOOK: after-new-window-hook binding.c:77:/**CONCEPT: Key Specifier callbacks.c:295:/**CONCEPT: Hooks callbacks.c:413:/**CONCEPT: Timer Hooks callbacks.c:545:/**CONCEPT: Input Hooks callbacks.c:668: /**HOOK: error-hook color.c:38:/**CONCEPT: Colors decor.c:69:/**CONCEPT: Decors deskpage.c:45:/**CONCEPT: Desks deskpage.c:77:/**CONCEPT: Viewports events.c:445:/**CONCEPT: SCWMEXEC Protocol events.c:1878: /**HOOK: X-PropertyNotify-hook events.c:1887:/**HOOK: X-MappingNotify-hook face.c:38:/**CONCEPT: Faces face.c:507:/**CONCEPT: Face Flags face.c:551:/**CONCEPT: Face Specification flags font.c:49:/**CONCEPT: Fonts image.c:104:/**CONCEPT: Images image.c:211:/**CONCEPT: Image Loaders image.c:631:/**VAR: image-load-path module-interface.c:167: /**HOOK: broadcast-hook module-interface.c:178: /** HOOK: broadcast-config-hook module-interface.c:188: /** HOOK: boradcast-name-hook module-interface.c:198: /** HOOK: boradcast-mini-icon-hook shutdown.c:177: /**HOOK: shutdown-hook shutdown.c:183: /**HOOK: startup-hook window.c:312:/**CONCEPT: Windows window.c:624:/**CONCEPT: The Window Context window.c:2778:/**CONCEPT: Focus Styles window.c:3335: /**HOOK: invalid-interaction-hook window.c:3342: /**HOOK: cannot-grab-hook xproperty.c:64:/**CONCEPT: X Properties So you're saying the C comments need to be fixed? I had assumed I had to allow matching it. Well, that's fine with me... > > > > I'd rather be more strict than less strict since a) it's easier to > > > > parse (a selfish reason) & b) it enforces a little uniformity on the > > > > code making it easier to read. extract-doc on the other hand, allows > > > > a fairly flexible format. > > > > > > Well, (a) falls apart since the only sensible way to be more strict is > > > to catch the violations of the strictness, which means recognizing that > > > it's close to okay, and warning about it, which means you still need the > > > flexible scanner. > > > > Mostly not the case. For example, botched spacing & ordering > > conditions for the SCWM_PROC stuff would be notified by the > > missing-doc or missing-func_name error traps, at which point it'd be > > clear to the user what the problem is. > > If those exceptions are caught and the appropriate warning message is > output, that's fine. Note that one of the uses of the extractor is > under compilation mode of emacs where we use C-x ` to go to the next > error to fix the problem in the doc-comment. The problem shouldn't just > be apparent from running the extractor, it should help me get there to > fix the problem. Of course. > > Well, I've relaxed the syntax to match extract-docs, and I have almost > > all the checks in place. I just basically need to do the sgml > > generation & package it as a runnable script. > > Excellent! The sgml generation shouldn't be too bad w/ my perl as an > outline of what should get output. The most tedious part was figuring > out what the docbook output should look like--testing with JADE was > pretty slow. I still have to find out how to sort using guile. I also don't have a ispell mode, but I do have a plain-text output which should more or less be feedable to ispell & should give back the appropriate info. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Aug 4 15:20:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA16229 for scwm-discuss-outgoing; Tue, 4 Aug 1998 15:20:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA16226 for ; Tue, 4 Aug 1998 15:20:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29975; Tue, 4 Aug 98 15:20:14 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA08946; Tue, 4 Aug 1998 12:20:17 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: From: Greg Badros Date: 04 Aug 1998 12:20:16 -0700 In-Reply-To: hjstein@bfr.co.il's message of "04 Aug 1998 22:03:46 +0300" Message-Id: Lines: 57 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > > like what we are interested in. I use: > > > > m%/\*\*\s*(\w[^:]*):\s*(.*?)\s*$% > > > > That sounds ok to me, except that I added whitespace btw /** & the > identifier because there are 3 instances of that in the scwm C code: That's what the \s* does -- 0 or more occurrences of whitespace. > So you're saying the C comments need to be fixed? I had assumed I had > to allow matching it. Well, that's fine with me... No -- the comments don't need to be fixed. I match them ok, as do you now, so we can rightly leave the comments alone. > > If those exceptions are caught and the appropriate warning message is > > output, that's fine. Note that one of the uses of the extractor is > > under compilation mode of emacs where we use C-x ` to go to the next > > error to fix the problem in the doc-comment. The problem shouldn't just > > be apparent from running the extractor, it should help me get there to > > fix the problem. > > Of course. Good. > > > Well, I've relaxed the syntax to match extract-docs, and I have almost > > > all the checks in place. I just basically need to do the sgml > > > generation & package it as a runnable script. > > > > Excellent! The sgml generation shouldn't be too bad w/ my perl as an > > outline of what should get output. The most tedious part was figuring > > out what the docbook output should look like--testing with JADE was > > pretty slow. > > I still have to find out how to sort using guile. I also don't have a > ispell mode, but I do have a plain-text output which should more or > less be feedable to ispell & should give back the appropriate info. See: http://www.cs.indiana.edu/scheme-repository/home.html and in particular, SLIB, which has a sort module: http://angela.ctrl-c.liu.se/~calle/scheme/slib_toc.html It's also pretty easy to right from scratch (though not as easy as miranda -- one of the most impressive one-liners of any programming language is writing a quicksort in miranda using only primitives in about 75 characters) Greg From owner-scwm-discuss@mit.edu Tue Aug 4 15:50:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA16578 for scwm-discuss-outgoing; Tue, 4 Aug 1998 15:50:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA16575 for ; Tue, 4 Aug 1998 15:50:49 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbad27842; Tue, 4 Aug 1998 19:50:47 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA32423; Tue, 4 Aug 1998 15:49:32 -0400 To: Maciej Stachowiak Subject: interactive move Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 04 Aug 1998 15:49:32 -0400 Message-ID: Lines: 14 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. The documentation for interactive-move mentions nonexistent `set-opaque-move-size!'. 2. Right now my scwm (the current CVS) moved all windows with both rubberband *and* opaquely! What is the status of the wonderful Maciej's predicate (move-window-opaquely? WINDOW)? Thanks. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. You think Oedipus had a problem -- Adam was Eve's mother. From owner-scwm-discuss@mit.edu Tue Aug 4 15:51:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA16602 for scwm-discuss-outgoing; Tue, 4 Aug 1998 15:51:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA16599 for ; Tue, 4 Aug 1998 15:51:34 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08844; Tue, 4 Aug 98 15:51:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA14306; Tue, 4 Aug 1998 22:48:39 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 04 Aug 1998 22:48:39 +0300 In-Reply-To: Greg Badros's message of "04 Aug 1998 12:20:16 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > http://www.cs.indiana.edu/scheme-repository/home.html > > and in particular, SLIB, which has a sort module: > > http://angela.ctrl-c.liu.se/~calle/scheme/slib_toc.html Well, yes, I knew I could get it from slib. I was just wondering about the best way to use slib with guile. I guess I have to (use-modules (ice-9 slib)) & then (require 'sort), but I was wondering if slib was more modularized/if there's a prefered way to use it/... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Aug 4 17:21:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA17170 for scwm-discuss-outgoing; Tue, 4 Aug 1998 17:21:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA17167 for ; Tue, 4 Aug 1998 17:21:01 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04115; Tue, 4 Aug 98 17:20:35 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA11003; Tue, 4 Aug 1998 14:20:04 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: From: Greg Badros Date: 04 Aug 1998 14:20:03 -0700 In-Reply-To: hjstein@bfr.co.il's message of "04 Aug 1998 22:48:39 +0300" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > http://www.cs.indiana.edu/scheme-repository/home.html > > > > and in particular, SLIB, which has a sort module: > > > > http://angela.ctrl-c.liu.se/~calle/scheme/slib_toc.html > > Well, yes, I knew I could get it from slib. I was just wondering > about the best way to use slib with guile. I guess I have to > (use-modules (ice-9 slib)) & then (require 'sort), but I was wondering > if slib was more modularized/if there's a prefered way to use it/... I know nothing about using slib -- maybe the guile@cygnus.com mailing list would know better (or Maciej?). Greg From owner-scwm-discuss@mit.edu Tue Aug 4 17:24:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA17184 for scwm-discuss-outgoing; Tue, 4 Aug 1998 17:24:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA17181 for ; Tue, 4 Aug 1998 17:24:14 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04912; Tue, 4 Aug 98 17:23:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA11135; Tue, 4 Aug 1998 14:24:05 -0700 (PDT) To: Maciej Stachowiak Subject: Re: interactive move References: From: Greg Badros Date: 04 Aug 1998 14:24:04 -0700 In-Reply-To: Sam Steingold's message of "04 Aug 1998 15:49:32 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 1. The documentation for interactive-move mentions nonexistent > `set-opaque-move-size!'. Fixed. > 2. Right now my scwm (the current CVS) moved all windows with both > rubberband *and* opaquely! What is the status of the wonderful > Maciej's predicate (move-window-opaquely? WINDOW)? Weird. I'll do a non-constraint build and see if I can figure out what's going wrong (constraint-builds always move-opaquely because the window selected for movement isn't all that special relative to the other windows, and it'd be prohibitively hard to move all the windows using rubberbands [and not as nice of an effect, anyway]). Greg From owner-scwm-discuss@mit.edu Tue Aug 4 18:14:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA17621 for scwm-discuss-outgoing; Tue, 4 Aug 1998 18:14:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA17618 for ; Tue, 4 Aug 1998 18:14:29 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA24240; Tue, 4 Aug 98 18:14:55 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id SAA25854; Tue, 4 Aug 1998 18:14:25 -0400 (EDT) To: scwm-discuss@mit.edu Subject: ICCCM compliance Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 04 Aug 1998 18:14:24 -0400 Message-Id: <87iuk88ke7.fsf@jekyll.piermont.com> Lines: 5 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Has anyone checked scwm for compliance with the ICCCM (I think I'm missing or adding extra c's there but you all know what I mean...) .pm From owner-scwm-discuss@mit.edu Tue Aug 4 21:20:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA18613 for scwm-discuss-outgoing; Tue, 4 Aug 1998 21:20:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA18610 for ; Tue, 4 Aug 1998 21:20:38 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA11344; Tue, 4 Aug 98 21:20:24 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA14536; Tue, 4 Aug 1998 18:20:34 -0700 (PDT) To: scwm-discuss@mit.edu Subject: report-scwm-bug From: Greg Badros Date: 04 Aug 1998 18:20:33 -0700 Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Perhaps scwm.el could support a report-scwm-bug that packaged up a bunch of the build and machine information, asked for user description, etc., and mailed it to the scwm-discuss list? We could also do this natively (i.e., w/o [X]Emacs) once we have a gtk entry widget. Pretty much like report-[x]emacs-bug would be fine. Greg From owner-scwm-discuss@mit.edu Tue Aug 4 23:02:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA19103 for scwm-discuss-outgoing; Tue, 4 Aug 1998 23:02:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA19100 for ; Tue, 4 Aug 1998 23:02:47 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA23356; Tue, 4 Aug 98 23:02:34 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbbg15334; Wed, 5 Aug 1998 03:02:45 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id XAA06041; Tue, 4 Aug 1998 23:02:41 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: report-scwm-bug References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "04 Aug 1998 18:20:33 -0700" Date: 04 Aug 1998 23:02:40 -0400 Message-Id: Lines: 17 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 04 Aug 1998 18:20:33 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "report-scwm-bug": >> Perhaps scwm.el could support a report-scwm-bug that packaged up a bunch >> of the build and machine information, asked for user description, etc., >> and mailed it to the scwm-discuss list? We could also do this natively >> (i.e., w/o [X]Emacs) once we have a gtk entry widget. Done. Great idea, thanks! M-x scwm-bug -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Why use Windows, when there are Doors? From owner-scwm-discuss@mit.edu Tue Aug 4 23:13:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA19228 for scwm-discuss-outgoing; Tue, 4 Aug 1998 23:13:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA19225 for ; Tue, 4 Aug 1998 23:13:49 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24533; Tue, 4 Aug 98 23:13:36 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA16100; Tue, 4 Aug 1998 20:13:41 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: report-scwm-bug References: From: Greg Badros Date: 04 Aug 1998 20:13:40 -0700 In-Reply-To: Sam Steingold's message of "04 Aug 1998 23:02:40 -0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 04 Aug 1998 18:20:33 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "report-scwm-bug": > >> Perhaps scwm.el could support a report-scwm-bug that packaged up a bunch > >> of the build and machine information, asked for user description, etc., > >> and mailed it to the scwm-discuss list? We could also do this natively > >> (i.e., w/o [X]Emacs) once we have a gtk entry widget. > > Done. Great idea, thanks! > M-x scwm-bug Excellent. Thanks! To all potential bug reporters, please try out the new bug report mechanism -- obviously feel free to write the list directly, too, especially to work out problems with scwm-bug! :-) We'll update system-info-string to add some more useful information, too. We should have the repo keep track of the last change time in a file that is used to provide a snapshot time stamp in the binary so that can be reported, too. (Build time isn't good enough -- we'll need to know when the sources were gotten from the Scwm site). Thanks, Greg From owner-scwm-discuss@mit.edu Tue Aug 4 23:14:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA19240 for scwm-discuss-outgoing; Tue, 4 Aug 1998 23:14:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA19237 for ; Tue, 4 Aug 1998 23:14:22 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA05624; Tue, 4 Aug 98 23:14:48 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id XAA27296; Tue, 4 Aug 1998 23:14:07 -0400 (EDT) Message-Id: <199808050314.XAA27296@jekyll.piermont.com> To: sds@goems.com Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: report-scwm-bug In-Reply-To: Your message of "04 Aug 1998 23:02:40 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 04 Aug 1998 23:14:07 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> Perhaps scwm.el could support a report-scwm-bug that packaged up a bunch > >> of the build and machine information, asked for user description, etc., > >> and mailed it to the scwm-discuss list? We could also do this natively > >> (i.e., w/o [X]Emacs) once we have a gtk entry widget. > > Done. Great idea, thanks! > M-x scwm-bug I'll point out that send-pr from the gnats package already does most of this, and that it has a distinct advantage -- it files the bug in a bug database so it cannot be lost... .pm From owner-scwm-discuss@mit.edu Tue Aug 4 23:17:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA19308 for scwm-discuss-outgoing; Tue, 4 Aug 1998 23:17:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA19305 for ; Tue, 4 Aug 1998 23:17:43 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24968; Tue, 4 Aug 98 23:17:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA16107; Tue, 4 Aug 1998 20:17:37 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: report-scwm-bug References: <199808050314.XAA27296@jekyll.piermont.com> From: Greg Badros Date: 04 Aug 1998 20:17:36 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 04 Aug 1998 23:14:07 -0400" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Sam Steingold writes: > > >> Perhaps scwm.el could support a report-scwm-bug that packaged up a bunch > > >> of the build and machine information, asked for user description, etc., > > >> and mailed it to the scwm-discuss list? We could also do this natively > > >> (i.e., w/o [X]Emacs) once we have a gtk entry widget. > > > > Done. Great idea, thanks! > > M-x scwm-bug > > I'll point out that send-pr from the gnats package already does most > of this, and that it has a distinct advantage -- it files the bug in a > bug database so it cannot be lost... I'm investigating and planning for the use of gnats. But that won't happen by 0.8, and this is a lower overhead way of getting a lot of the utility of improved bug reporting. Gnats is on the administrative TODO list. I like the idea and have heard lots of positives about the package... the number of bug reports is still manageable by hand, so we're spending our time fixing them (and creating new ones, er..., I mean features :-) ) instead for a while. Greg From owner-scwm-discuss@mit.edu Wed Aug 5 09:02:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA22346 for scwm-discuss-outgoing; Wed, 5 Aug 1998 09:02:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA22343 for ; Wed, 5 Aug 1998 09:02:38 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00931; Wed, 5 Aug 98 09:03:00 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA19709; Wed, 5 Aug 1998 16:02:17 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: New extract.scm (with some sgml output). Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 05 Aug 1998 16:02:17 +0300 In-Reply-To: Greg Badros's message of "04 Aug 1998 20:17:36 -0700" Message-Id: Lines: 708 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's my latest extract.scm if you want to try it out, with some example usage. There's still work to do, basically finishing up sgml, making it a runable script & maybe adding a few more warnings, but I thought you'd like to take a look at it. (You'll have to change the definition of testfilelist for this to work for you). guile> (load "extract.scm") guile> (define doc (apply extract-docs-from-files testfilelist)) guile> (define procs (select-type 'SCWM_PROC doc)) guile> (define sorted-procs (sort procs scheme-name-ci (car sorted-procs) (SCWM_PROC ((add_input_hook_x "add-input-hook!" 2 0 0 ((SCM port) (SCM proc))) ("Add an input hook to run PROC on input from PORT." "Whenever input becomes available on PORT, procedure PROC will be called" "with no arguments repeatedly until no unprocessed input remains on" "PORT. PORT must be open, it must be an input port, and it must be a" "file port (this includes pipes and sockets, but not string ports or" "soft ports). A handle suitable for passing to `remove-input-hook!' is" "returned.") "s_add_input_hook_x") "/home/hjstein/software/scwm/scwm/callbacks.c" 559) guile> (proc->list (car sorted-procs)) (add-input-hook! port proc) Add an input hook to run PROC on input from PORT. Whenever input becomes available on PORT, procedure PROC will be called with no arguments repeatedly until no unprocessed input remains on PORT. PORT must be open, it must be an input port, and it must be a file port (this includes pipes and sockets, but not string ports or soft ports). A handle suitable for passing to `remove-input-hook!' is returned. [From /home/hjstein/software/scwm/scwm/callbacks.c:559] guile> (proc->sgml (car sorted-procs)) add-input-hook! Add an input hook to run PROC on input from PORT. (add-input-hook! port proc) Description Add an input hook to run PROC on input from PORT. Whenever input becomes available on PORT, procedure PROC will be called with no arguments repeatedly until no unprocessed input remains on PORT. PORT must be open, it must be an input port, and it must be a file port (this includes pipes and sockets, but not string ports or soft ports). A handle suitable for passing to `remove-input-hook!' is returned. Implementation Notes Defined in /home/hjstein/software/scwm/scwm/callbacks.c at line 559. Then, of course, you can do (for-each proc->sgml sorted-procs) to generate the sgml for the primitives-by-name chapter, or (for-each proc->list sorted-procs) to generate scwm-procedures.txt, and (for-each check-proc doc) to error check the docs. There're also some convenience fcns for doing the above. ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** spaces identifier: & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; Parsing: ;;; (extract-docs-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; ;;; Generating procedures-list documentation: ;;; (output-proclist f1.c f2.c ...) ;;; Extracts docs & output procedures-list stuff. It's just: ;;; (for-each proc->list (apply extract-docs-from-files files)) ;;; ;;; Checking docs are well formed: ;;; (check-docs f1.c f2.c ...) ;;; Extracts docs & verifies stuff (such as number of args = args ;;; in argslist, all args are SCM types, each arg is mentioned in ;;; the documentation, etc. Just runs check-proc on each record ;;; returned by extract-docs-from-files. ;;; ;;; Generating sgml output: ;;; (output-sgml f1.c f2.c ...) ;;; Does various passes on the extract-docs-from-files output to ;;; generate the sgml output. ;;; (someone please write me) ;;; ;;; Note: ;;; 1. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things (if I'm doing this). (if (not (member "/usr/lib" %load-path)) (set! %load-path (cons "/usr/lib" %load-path))) ; HACK for guile to find slib!!!!!!! (use-modules (ice-9 regex) ; For regexp-quote & substitute. (ice-9 slib)) ; For sort. (require 'sort) (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*([^ \t:*]*:.*)")) ; spaces /**[^space or *] (define post-proc-doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]+(.*)")) ; spaces /** space+ (define func-name-match (make-regexp "^[ \t]*#[ \t]*define[ \t]+FUNC_NAME[ \t]+([^ \t]*)[ \t]*$")) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:required-args procrec) (list-ref procrec 2)) (define (proc:optional-args procrec) (list-ref procrec 3)) (define (proc:extra-var-args procrec) (list-ref procrec 4)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (procdoc:funcname procdocrec) (list-ref procdocrec 2)) (define (docitem:type rec) (list-ref rec 0)) (define (docitem:data rec) (list-ref rec 1)) (define (docitem:file rec) (list-ref rec 2)) (define (docitem:line rec) (list-ref rec 3)) (define (doc:identifier rec) (list-ref rec 0)) (define (doc:doc rec) (list-ref rec 1)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document extracted from the specified files. (define (output-proclist . files) (for-each proc->list (sort (select-type 'SCWM_PROC (apply extract-docs-from-files files)) scheme-name-cischeme-ident (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec))) (not (string=? (c-name->scheme-name (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec)))) (complain file line "Scheme name of " (proc:scheme-name procrec) " doesn't match a C name of " (proc:c-name procrec))) ;; Warn about upper case words != arg names? ;; What's this business about the 1st doc line being a "purpose" sentence? ;; What's this business about "leading spaces" being omitted? ;; Check that arg 2+3+4 = length of arg5 (if (not (= (+ (proc:required-args procrec) (proc:optional-args procrec) (proc:extra-var-args procrec)) (length (proc:args procrec)))) (complain file line "Argument count mismatch in " (proc:scheme-name procrec))) ;; Warn about var param != 0 or 1. (if (and (not (= (proc:extra-var-args procrec) 0)) (not (= (proc:extra-var-args procrec) 1))) (complain file line "Var count is not 0 and is not 1")) ;; Check that all args are of type SCM (let loop ((i 1) (args (proc:args procrec))) (cond ((null? args)) ((eq? (caar args) 'SCM) (loop (1+ i) (cdr args))) (else (complain file line "In the declaration for " (proc:scheme-name procrec) ", argument " i " (" (cadar args) ") is not of type SCM")))) ;; Check that the proc is documented: (if (null? docrec) (complain file line "Procedure " (proc:scheme-name procrec) " is not documented")) ;; Check that each arg appears in description: (let next-arg ((argregexp (map (lambda (arg) (delimited-case-insensitive-regexp (c-name->scheme-name (symbol->string (cadr arg))))) (proc:args procrec))) (args (map cadr (proc:args procrec))) (i 1)) (cond ((null? args)) (else (let next-docline ((doc docrec)) (cond ((null? doc) (complain file line "Argument " i " (" (car args) ") of " (proc:scheme-name procrec) " is undocumented")) ((regexp-exec (car argregexp) (car doc))) (else (next-docline (cdr doc))))) (next-arg (cdr argregexp) (cdr args) (+ i 1))))) ;; Check that there's a func_name & it matches the c-name (if funcname (if (not (string=? (string-append "s_" (symbol->string (proc:c-name procrec))) funcname)) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a matching FUNC_NAME")) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a FUNC_NAME")))) (else (complain file line "Internal error - unrecognized doc record type."))))) (define (c-ident->scheme-ident s) (define to-regexp (make-regexp "_to_")) (define (to->-> s) (let ((match (regexp-exec to-regexp s))) (if match (regexp-substitute #f match 'pre "->" 'post) s))) (c-name->scheme-name (to->-> s))) (define (c-name->scheme-name s) (let* ((normname (map (lambda (c) (if (char=? c #\_) #\- c)) (string->list s))) (revname (reverse normname))) (cond ((or (null? revname) (null? (cdr revname))) (list->string normname)) ((and (char=? (car revname) #\p) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\? (cddr revname))))) ((and (char=? (car revname) #\x) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\! (cddr revname))))) (else (list->string normname))))) (define (delimited-case-insensitive-regexp s) (let ((ci-name (regexp-quote s))) (make-regexp (string-append "[ \t]" ci-name "[ \t.,]|" "^" ci-name "[ \t.,]|" "[ \t]" ci-name "$|" "^" ci-name "$") regexp/icase))) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (proc->list procdocrec) (if (eq? 'SCWM_PROC (docitem:type procdocrec)) (let ((procrec (procdoc:decl (docitem:data procdocrec))) (docrec (procdoc:doc (docitem:data procdocrec)))) (display "(") (display (proc:scheme-name procrec)) (for-each (lambda (arg) (display " ") (display (cadr arg))) (proc:args procrec)) (display ")") (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (display "[From ") (display (docitem:file procdocrec)) (display ":") (display (docitem:line procdocrec)) (display "]") (newline) (newline) (display #\014) (newline)))) ;;; Output docs in format suitable for ispell: (define (text-proc procdocrec) (let* ((file (docitem:file procdocrec)) (line (docitem:line procdocrec)) (doc (case (docitem:type procdocrec) ((SCWM_PROC) (procdoc:doc (docitem:data procdocrec)))) ((DOC) (doc:doc (docitem:data procdocrec))) (else (complain file line "Internal error - unrecognized doc record type.") '()))) (for-each (lambda (d) (complain file line d) doc)))) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (extract-docs-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (extract-docs-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (extract-docs-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (cond (doc (loop (counting-read-line p) (cons (list 'SCWM_PROC doc filename linenum) defs))) (else (complain filename linenum "SCWM_PROC not parsable") (loop (counting-read-line p) defs))))) (docstart (let ((doc (parse-doc (extract-doc p line)))) (loop (counting-read-line p) (cons (list 'DOC doc filename linenum) defs)))) (else (loop (counting-read-line p) defs)))))))) (define (next-non-whitespace-line p) (define whitespace-line (make-regexp "^[ \t]*$")) (let ((line (counting-read-line p))) (if (or (eof-object? line) (regexp-exec whitespace-line line)) (next-non-whitespace-line p) line))) (define (extract-proc-n-doc line p) (let* ((proc (parse-proc (match-parentheses line p))) (next (counting-read-line p))) (cond ((not proc) ; Proc not parsable #f) ((eof-object? next) ; No doc & no func (list proc '() #f)) ((regexp-exec post-proc-doc-start-match next) ; Doc is first. (let* ((doc (extract-doc p next post-proc-doc-start-match)) (next (next-non-whitespace-line p)) (match (if next (regexp-exec func-name-match next) #f))) (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f)))) (else (let* ((match (regexp-exec func-name-match next)) ; Func name must be next. (next (next-non-whitespace-line p)) (doc (extract-doc p next post-proc-doc-start-match))) ; Then the docs. (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f))))))) (define (extract-doc p . xargs) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? xargs) (counting-read-line p) (car xargs))) (doc-start-match (if (or (null? xargs) (null? (cdr xargs))) doc-start-match (cadr xargs)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-doc doclist) (define parser (make-regexp "^[ \t]*([^ \t:]*):[ \t]*(.*)$")) (cond ((null? doclist) '(#f '())) (else (let ((match (regexp-exec parser (car doclist)))) (list (match:substring match 1) (cons (match:substring match 2) (cdr doclist))))))) (define (parse-proc defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) #f))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) (define (stringify value) (with-output-to-string (lambda () (write value)))) (define (proc->sgml docitem) (let* ((data (docitem:data docitem)) (proc (procdoc:decl data)) (doc (procdoc:doc data))) (sgml `((refentry (id ,(stringify (proc:c-name proc)))) ((refnamediv) ((refname) ,(proc:scheme-name proc)) ((refpurpose) ,(car doc))) ((refsynopsisdiv) ((synopsis) ,(stringify (cons (string->symbol (proc:scheme-name proc)) (map cadr (proc:args proc)))))) ((refsect1) ((title) "Description") ((para) ,@doc)) ((refsect1) ((title) "Implementation Notes") ((para) "Defined in " ((ulink (url ,(docitem:file docitem))) ((filename) ,(docitem:file docitem))) ,(string-append " at line " (stringify (docitem:line docitem)) "."))))))) (define (sgml form . depth) (if (null? depth) (set! depth '(0))) (cond ((string? form) (display (make-string (car depth) #\space)) (display form) (newline)) ((null? form) '()) (else (display (make-string (car depth) #\space)) (sgml-render-start (car form)) (for-each (lambda (f) (sgml f (+ (car depth) 3))) (cdr form)) (display (make-string (car depth) #\space)) (sgml-render-end (car form))))) (define (sgml-render-start tag) (display "<") (display (car tag)) (for-each (lambda (args) (display " ") (display (car args)) (display "=") (write (cadr args))) (cdr tag)) (display ">\n")) (define (sgml-render-end tag) (display "\n")) (define testfilelist '("/home/hjstein/software/scwm/scwm/Grab.c" "/home/hjstein/software/scwm/scwm/ICCCM.c" "/home/hjstein/software/scwm/scwm/add_window.c" "/home/hjstein/software/scwm/scwm/binding.c" "/home/hjstein/software/scwm/scwm/borders.c" "/home/hjstein/software/scwm/scwm/callbacks.c" "/home/hjstein/software/scwm/scwm/color.c" "/home/hjstein/software/scwm/scwm/colormaps.c" "/home/hjstein/software/scwm/scwm/colors.c" "/home/hjstein/software/scwm/scwm/complex.c" "/home/hjstein/software/scwm/scwm/decor.c" "/home/hjstein/software/scwm/scwm/decorations.c" "/home/hjstein/software/scwm/scwm/deskpage.c" "/home/hjstein/software/scwm/scwm/draw-pie-menu.c" "/home/hjstein/software/scwm/scwm/drawmenu.c" "/home/hjstein/software/scwm/scwm/errors.c" "/home/hjstein/software/scwm/scwm/events.c" "/home/hjstein/software/scwm/scwm/face.c" "/home/hjstein/software/scwm/scwm/focus.c" "/home/hjstein/software/scwm/scwm/font.c" "/home/hjstein/software/scwm/scwm/getopt.c" "/home/hjstein/software/scwm/scwm/getopt1.c" "/home/hjstein/software/scwm/scwm/guile-compat.c" "/home/hjstein/software/scwm/scwm/icons.c" "/home/hjstein/software/scwm/scwm/image.c" "/home/hjstein/software/scwm/scwm/init_scheme_string.c" "/home/hjstein/software/scwm/scwm/menu.c" "/home/hjstein/software/scwm/scwm/menuitem.c" "/home/hjstein/software/scwm/scwm/miscprocs.c" "/home/hjstein/software/scwm/scwm/module-interface.c" "/home/hjstein/software/scwm/scwm/move.c" "/home/hjstein/software/scwm/scwm/placement.c" "/home/hjstein/software/scwm/scwm/resize.c" "/home/hjstein/software/scwm/scwm/screen.c" "/home/hjstein/software/scwm/scwm/scwm.c" "/home/hjstein/software/scwm/scwm/scwmmenu.c" "/home/hjstein/software/scwm/scwm/shutdown.c" "/home/hjstein/software/scwm/scwm/string_token.c" "/home/hjstein/software/scwm/scwm/syscompat.c" "/home/hjstein/software/scwm/scwm/system.c" "/home/hjstein/software/scwm/scwm/util.c" "/home/hjstein/software/scwm/scwm/virtual.c" "/home/hjstein/software/scwm/scwm/window.c" "/home/hjstein/software/scwm/scwm/xmisc.c" "/home/hjstein/software/scwm/scwm/xproperty.c")) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Aug 5 09:13:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA22418 for scwm-discuss-outgoing; Wed, 5 Aug 1998 09:13:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA22415 for ; Wed, 5 Aug 1998 09:13:50 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03831; Wed, 5 Aug 98 09:14:15 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA19765; Wed, 5 Aug 1998 16:13:43 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: New extract.scm (with some sgml output). References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 05 Aug 1998 16:13:43 +0300 In-Reply-To: hjstein@bfr.co.il's message of "05 Aug 1998 16:02:17 +0300" Message-Id: Lines: 16 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Here's my latest extract.scm if you want to try it out, with some > example usage. There's still work to do, basically finishing up sgml, > making it a runable script & maybe adding a few more warnings, but I > thought you'd like to take a look at it. (You'll have to change the > definition of testfilelist for this to work for you). (You'll need to change the "/usr/lib" at the top to the directory in which slib lives on your system, if it's not /usr/lib. I'm still waiting for some answers on guile slib usage from guile@cygnus.com. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Aug 5 20:02:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA25514 for scwm-discuss-outgoing; Wed, 5 Aug 1998 20:02:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id UAA25508 for ; Wed, 5 Aug 1998 20:01:58 -0400 Received: from rukbat.cs.unc.edu (rukbat.cs.unc.edu [152.2.133.170]) by austin.cs.unc.edu (8.8.8/8.8.8) with SMTP id UAA06914 for ; Wed, 5 Aug 1998 20:01:46 -0400 (EDT) Date: Wed, 5 Aug 1998 20:01:46 -0400 (EDT) From: Stephen Tell To: SCWM Discussion List Subject: move-or-raise is really move-and-raise? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk The procedure move-or-raise in scheme/minimal.scm always seems raises the window, even when a move is performed. (0.7a or 19980805 snapshot). Maybe this is what the fvwm2 of the same name does and if so maybe it should stay that way for compatibility. In an effort to be able to move windows without changing their order, I overrode it with this variation, which does what I want: (define (move-or-raise) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (lower-window)) ((click) (raise-window)) )) I have (set-click-to-focus-raises! #f ) in my .scwmrc, and the focus style set to click. Just FYI, under the 19980805 snaphot, these operations produce instances of this message, at times when I didn't want the window raised: [Scwm][HandleButtonPress]: <> Would have raised window xterm, but commented out -- did you want it to raise? Tell Greg! While I'm asking about clicking and so on, is it possible to configure somthing in .scwmrc so that (set-click-to-focus-passes-click! #f ) lets clicks in the titlebar and borders be operated on immediatly, and only focus-passing clicks in the window body are supressed? I thought I might like this mode, but currently its just too annoying. Steve -- Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF Research Associate, Microelectronic Systems Laboratory Computer Science Department, UNC@Chapel Hill. W:919-962-1845 From owner-scwm-discuss@mit.edu Wed Aug 5 20:25:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA25664 for scwm-discuss-outgoing; Wed, 5 Aug 1998 20:25:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA25661 for ; Wed, 5 Aug 1998 20:25:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28127; Wed, 5 Aug 98 20:25:05 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA05210; Wed, 5 Aug 1998 17:24:59 -0700 (PDT) To: Stephen Tell Cc: SCWM Discussion List Subject: Re: move-or-raise is really move-and-raise? References: From: Greg Badros Date: 05 Aug 1998 17:24:58 -0700 In-Reply-To: Stephen Tell's message of "Wed, 5 Aug 1998 20:01:46 -0400 (EDT)" Message-Id: Lines: 48 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stephen Tell writes: > The procedure move-or-raise in scheme/minimal.scm always seems raises the > window, even when a move is performed. (0.7a or 19980805 snapshot). > Maybe this is what the fvwm2 of the same name does and if so maybe it > should stay that way for compatibility. Not if it's a dumb name! :-) We're not *that* intent on compatibility. > In an effort to be able to move windows without changing their order, I > overrode it with this variation, which does what I want: > > (define (move-or-raise) > (case (mouse-event-type) > ((motion) (interactive-move)) > ((double-click) (lower-window)) > ((click) (raise-window)) > )) This looks good, I'll try it out and make the change. > > I have (set-click-to-focus-raises! #f ) in my .scwmrc, and the focus style > set to click. > > Just FYI, under the 19980805 snaphot, these operations produce instances > of this message, at times when I didn't want the window raised: > [Scwm][HandleButtonPress]: <> Would have raised window xterm, but > commented out -- did you want it to raise? Tell Greg! Cool. Debug code actually works! Anyone else ever see the message and want the window to raise? > While I'm asking about clicking and so on, is it possible to configure > somthing in .scwmrc so that > (set-click-to-focus-passes-click! #f ) > lets clicks in the titlebar and borders be operated on immediatly, and > only focus-passing clicks in the window body are supressed? I thought I > might like this mode, but currently its just too annoying. > I'll have to play around with the option -- I don't use click-to-focus, so don't know much about the behaviour, really. Thanks for the bug fix! Greg From owner-scwm-discuss@mit.edu Wed Aug 5 20:31:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA25744 for scwm-discuss-outgoing; Wed, 5 Aug 1998 20:31:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA25740 for ; Wed, 5 Aug 1998 20:31:27 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28807; Wed, 5 Aug 98 20:31:13 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA05215; Wed, 5 Aug 1998 17:31:18 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <87iuk88ke7.fsf@jekyll.piermont.com> From: Greg Badros Date: 05 Aug 1998 17:31:18 -0700 In-Reply-To: "Perry E. Metzger"'s message of "04 Aug 1998 18:14:24 -0400" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Has anyone checked scwm for compliance with the ICCCM (I think I'm > missing or adding extra c's there but you all know what I mean...) Not formally. We strive for ICCCM compliance, but I've not read the spec in a while, so I don't know what we'll need to do to be strictly compliant. Greg From owner-scwm-discuss@mit.edu Wed Aug 5 20:40:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA25837 for scwm-discuss-outgoing; Wed, 5 Aug 1998 20:40:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA25834 for ; Wed, 5 Aug 1998 20:40:22 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29779; Wed, 5 Aug 98 20:40:08 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA05219; Wed, 5 Aug 1998 17:40:15 -0700 (PDT) To: senda@ic.rdc.ricoh.co.jp Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980803115417K.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 05 Aug 1998 17:40:15 -0700 In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Mon, 03 Aug 1998 11:54:17 +0900" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk senda@ic.rdc.ricoh.co.jp writes: > Hi, > > It may be obvious to everyone ... > > By writing following script, > I'm really aware that scwm has great flexibility by adopting guile as > a scripting language. Yep. > It is impossible to write a same script in other window managers. Indeed. Thanks for the cool example... may we include it (or a variant thereof) with scwm? Greg P.S. When anyone posts code snippets, it'd be really nice if you include a release saying that you release it under GPL, or some other terms, just to be safe. One comment saying "Free under GPL" is probably sufficient. Thanks! From owner-scwm-discuss@mit.edu Wed Aug 5 21:36:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA26152 for scwm-discuss-outgoing; Wed, 5 Aug 1998 21:36:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA26146 for ; Wed, 5 Aug 1998 21:36:22 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA05990; Wed, 5 Aug 98 21:36:02 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id KAA13528 for ; Thu, 6 Aug 1998 10:36:12 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id KAA06735 for ; Thu, 6 Aug 1998 10:36:10 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id KAA01036; Thu, 6 Aug 1998 10:37:21 +0900 To: scwm-discuss@mit.edu Subject: Re: Great flexibility In-Reply-To: Your message of "05 Aug 1998 17:40:15 -0700" References: X-Mailer: Mew version 1.93b38 on XEmacs 21.2 (Aeolus) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> Date: Thu, 06 Aug 1998 10:37:20 +0900 X-Dispatcher: imput version 980522 Lines: 30 Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb> gjb> Thanks for the cool example... may we include it (or a variant thereof) gjb> with scwm? gjb> Yes, please. gjb> Greg gjb> gjb> P.S. When anyone posts code snippets, it'd be really nice if you include gjb> a release saying that you release it under GPL, or some other terms, gjb> just to be safe. One comment saying "Free under GPL" is probably gjb> sufficient. Thanks! gjb> I see. I can't imagine people who posts a patch or code to the program released under GPL and insists on strict licence to it. :-) But, I can understand your requirement. P.S. My codes and patches I posted before is 'Free under GPL', of course ! P.S. I still hope that my previous patches to scwm.c and configure.in is merged into future release. S.Senda From owner-scwm-discuss@mit.edu Wed Aug 5 21:57:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA26293 for scwm-discuss-outgoing; Wed, 5 Aug 1998 21:57:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA26290 for ; Wed, 5 Aug 1998 21:57:31 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08319; Wed, 5 Aug 98 21:57:16 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA07250; Wed, 5 Aug 1998 18:57:24 -0700 (PDT) To: senda@ic.rdc.ricoh.co.jp Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 05 Aug 1998 18:57:23 -0700 In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Thu, 06 Aug 1998 10:37:20 +0900" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk senda@ic.rdc.ricoh.co.jp writes: > > I see. > > I can't imagine people who posts a patch or code to the program > released under GPL and insists on strict licence to it. :-) > But, I can understand your requirement. Following in Richard Stallman's footsteps. He's been burned, and we don't want to be. > P.S. > My codes and patches I posted before is 'Free under GPL', of course ! Great! Thanks again! > > P.S. > I still hope that my previous patches to scwm.c and configure.in is > merged into future release. I've got the patches saved, but am waiting to see if Maciej's commit has the changes before I spend time making them (he knows more about the details of configuration than I do). They will make it in, never fear! Greg From owner-scwm-discuss@mit.edu Wed Aug 5 23:18:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26917 for scwm-discuss-outgoing; Wed, 5 Aug 1998 23:18:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA26914 for ; Wed, 5 Aug 1998 23:18:17 -0400 Received: from pcnet1.pcnet.com by MIT.EDU with SMTP id AA17279; Wed, 5 Aug 98 23:18:01 EDT Received: (from proteus@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id XAA28655; Wed, 5 Aug 1998 23:18:48 -0400 (EDT) Message-Id: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Mime-Version: 1.0 In-Reply-To: Date: Wed, 05 Aug 1998 23:04:14 -0400 (EDT) Reply-To: Bob Woodside Organization: Woodsway Consulting From: Bob Woodside To: Greg Badros Subject: Re: move-or-raise is really move-and-raise? Cc: SCWM Discussion List , Stephen Tell Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 06-Aug-98 Greg Badros wrote: > Stephen Tell writes: > >> The procedure move-or-raise in scheme/minimal.scm always seems raises the >> window, even when a move is performed. (0.7a or 19980805 snapshot). >> Maybe this is what the fvwm2 of the same name does and if so maybe it >> should stay that way for compatibility. > > Not if it's a dumb name! :-) We're not *that* intent on compatibility. > At the very least, a misnomer. The version currently in minimal.scwm just mimics the function of the same name in the default sample fvwm2rc, which really should have been called Raise-and-then-maybe-Move-or-maybe- even-Lower. I'd completely forgotten about this, having long since changed my fvwm2rc to use a Move-or-Raise function much like the one Steve offered. This definitely shouldn't be replicated in Scwm. It should be corrected in Fvwm. Let's not try for bug-level compatibility. :-) From owner-scwm-discuss@mit.edu Wed Aug 5 23:25:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA27047 for scwm-discuss-outgoing; Wed, 5 Aug 1998 23:25:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA27035 for ; Wed, 5 Aug 1998 23:25:33 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18686; Wed, 5 Aug 98 23:25:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA08482; Wed, 5 Aug 1998 20:25:24 -0700 (PDT) To: Bob Woodside Cc: SCWM Discussion List , Stephen Tell Subject: Re: move-or-raise is really move-and-raise? References: From: Greg Badros Date: 05 Aug 1998 20:25:23 -0700 In-Reply-To: Bob Woodside's message of "Wed, 05 Aug 1998 23:04:14 -0400 (EDT)" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Bob Woodside writes: > On 06-Aug-98 Greg Badros wrote: > > > > Not if it's a dumb name! :-) We're not *that* intent on compatibility. > > > > At the very least, a misnomer. The version currently in minimal.scwm > just mimics the function of the same name in the default sample fvwm2rc, > which really should have been called Raise-and-then-maybe-Move-or-maybe- > even-Lower. I'd completely forgotten about this, having long since changed > my fvwm2rc to use a Move-or-Raise function much like the one Steve offered. > This definitely shouldn't be replicated in Scwm. It should be corrected in > Fvwm. Glad we agree -- I had just checked in Stephen's fix. > Let's not try for bug-level compatibility. :-) Gosh no! We want Scwm's bugs to be her own! Greg From owner-scwm-discuss@mit.edu Thu Aug 6 03:25:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28422 for scwm-discuss-outgoing; Thu, 6 Aug 1998 03:25:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA28419 for ; Thu, 6 Aug 1998 03:25:50 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA02821 for scwm-discuss@huis-clos.mit.edu; Thu, 6 Aug 1998 09:25:43 +0200 (CEST) Received: (qmail 293 invoked by uid 115); 5 Aug 1998 18:31:54 -0000 To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <87iuk88ke7.fsf@jekyll.piermont.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Aug 1998 20:31:53 +0200 In-Reply-To: "Perry E. Metzger"'s message of "04 Aug 1998 18:14:24 -0400" Message-ID: Lines: 54 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 04 Aug 1998 18:14:24 -0400 >>>>> "Perry E. Metzger" said: Perry> Has anyone checked scwm for compliance with the ICCCM Not that I know of. Just two things from the top of my head: ---- The [WM_HINTS] UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user. The window man ager must make some effort to draw the user's attention to this window while this flag is set. The window manager must also monitor the state of this flag for the entire time the window is in the Normal or Iconic state and must take appro priate action when the state of the flag changes. The flag is otherwise independent of the window's state; in particu lar, the window manager is not required to deiconify the window if the client sets the flag on an Iconic window. ---- Window managers should ensure that they provide some mechanism for their clients to receive events from all keys and all buttons, except for events involving keys whose KeySyms are registered as being for window management functions (for exam ple, a hypothetical WINDOW KeySym) [Not so hypothetical with flying-carpet-keys on most modern PC-keyboards -rb]. In other words, window managers must provide some mechanism by which a client can receive events from every key and but ton (regardless of modifiers) unless and until the X Consor tium registers some KeySyms as being reserved for window management functions. Currently, no KeySyms are registered for window management functions. ---- The first is probably straight-forward to implement. The second needs some kind of quoting mechanism, akin to Emacs's C-q. Probably a primitive that prevents the next key-combo from being interpreted by scwm. There are perhaps number of other issues as well. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Aug 6 04:37:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA29218 for scwm-discuss-outgoing; Thu, 6 Aug 1998 04:37:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA29215 for ; Thu, 6 Aug 1998 04:37:34 -0400 Received: from lilly.ping.de by MIT.EDU with SMTP id AA11806; Thu, 6 Aug 98 04:37:13 EDT Received: (qmail 28466 invoked by uid 10); 6 Aug 1998 08:37:18 -0000 Received: from aibon.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc); 6 Aug 1998 08:37:18 -0000 Received: (qmail 11289 invoked by uid 1013); 6 Aug 1998 08:36:23 -0000 To: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: From: Sascha Ziemann Date: 06 Aug 1998 10:36:23 +0200 In-Reply-To: Greg Badros's message of 15 Jul 1998 10:26:48 -0700 Message-Id: <7upvee8q2g.fsf@olivia.aibon.ping.de> Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: | SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, | (SCM contexts, SCM key)) | /** Remove any bindings attached to KEY in given CONTEXTS. | CONTEXTS is a list of event-contexts (e.g., '(button1 | sidebar)) KEY is a string giving the key-specifier (e.g., | M-Delete for META+Delete). | See also `bind-key'. */ I don't think that the documentation should contain SGML tags. That make the documentation really unreadable. Do you want to wite all < as <? How about equitations or similar things? SGML is a nice language for text transformation but not for handwritten documentation and also not for inline documentation in programs. If you still consider SGML as part of the source, you should at least consider a different syntax for the tags. It is necessary to save people from writing everything twice. Because of this, I would prefer {code-example '(button1 sidebar)} instead of '(button1 sidebar) The first has 15 chars overhead compared to the bottom, which has 29 chars overhead. It was a quite stupid idea of the IBM guy who invented SGML not to follow Knuth's usage of {} for generic markup. -- /* In the beginning was the Word: */ typedef long SCM; From owner-scwm-discuss@mit.edu Thu Aug 6 05:48:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29576 for scwm-discuss-outgoing; Thu, 6 Aug 1998 05:48:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA29573 for ; Thu, 6 Aug 1998 05:48:21 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA18992; Thu, 6 Aug 98 05:48:41 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id MAA27948; Thu, 6 Aug 1998 12:47:59 +0300 To: Sascha Ziemann Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 06 Aug 1998 12:47:59 +0300 In-Reply-To: Sascha Ziemann's message of "06 Aug 1998 10:36:23 +0200" Message-Id: Lines: 70 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sascha Ziemann writes: > Greg Badros writes: > > | SCWM_PROC(unbind_key, "unbind-key", 2, 0, 0, > | (SCM contexts, SCM key)) > | /** Remove any bindings attached to KEY in given CONTEXTS. > | CONTEXTS is a list of event-contexts (e.g., '(button1 > | sidebar)) KEY is a string giving the key-specifier (e.g., > | M-Delete for META+Delete). > | See also `bind-key'. */ > > I don't think that the documentation should contain SGML tags. That > make the documentation really unreadable. Do you want to wite all < as > <? How about equitations or similar things? SGML is a nice language > for text transformation but not for handwritten documentation and also > not for inline documentation in programs. If you still consider SGML > as part of the source, you should at least consider a different syntax > for the tags. It is necessary to save people from writing everything > twice. Because of this, I would prefer > > {code-example '(button1 sidebar)} > > instead of > > '(button1 sidebar) > > The first has 15 chars overhead compared to the bottom, which has 29 > chars overhead. It was a quite stupid idea of the IBM guy who invented > SGML not to follow Knuth's usage of {} for generic markup. I must concur, but for different reasons. WRT comment extraction & sgml markup we have the following possibilities: 1. Write the comments in complete sgml, with all the stupid tag/end tag pairs & all the stupid special character escapes, or 2. Write the comments in partial sgml, or 3. Mark up the comments in some easily parsible, concise, easy to remember generic way. 4. Something I'm not thinking of. If we follow option 1, then we can just extract the comments for the SGML output, but we have to actually parse the SGML comments to *remove* the SGML crap for something like the procedure listings/plain text output. This'd make writing documentation much more painful for the programmer. This is also hellish for the extractor, unless *everything* is output in various forms of SGML & then run through Jade or some other parser to generate html as well as plain text. If we follow 2, then we have to parse the partial SGML comments so that we can do things like escape characters properly & add additional markup for SGML output & remove markup for procedure listings/plain text output. This is marginally less painful for the programmer, but even worse for the extractor, since we can't avoid parsing the comments by just dumping them & running them through the SGML parser. If we follow 3, then by definition it's easy for the programmer & easy for the extractor. And, it's already being done in that `xxx' denotes a cross-link. The only problem is that we're creating a new markup language which we'll require programmers to learn. I wouldn't have much trouble parsing {tag stuff} & `xref', as suggested, & either removing the {tag & } for plaintext output, or converting it to stuff for sgml. I can't comment on possibility 4. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Aug 6 07:31:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA30004 for scwm-discuss-outgoing; Thu, 6 Aug 1998 07:31:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA29997 for ; Thu, 6 Aug 1998 07:31:33 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01764 for scwm-discuss@huis-clos.mit.edu; Thu, 6 Aug 1998 13:31:24 +0200 (CEST) Received: (qmail 431 invoked by uid 115); 6 Aug 1998 08:10:26 -0000 To: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Aug 1998 10:10:25 +0200 In-Reply-To: hjstein@bfr.co.il's message of "04 Aug 1998 22:03:46 +0300" Message-ID: Lines: 17 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 04 Aug 1998 22:03:46 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> I still have to find out how to sort using guile. I also Harvey> don't have a ispell mode, but I do have a plain-text output Harvey> which should more or less be feedable to ispell & should give Harvey> back the appropriate info. You lose the information where the misspelt word was located, don't you? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Aug 6 07:31:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA30003 for scwm-discuss-outgoing; Thu, 6 Aug 1998 07:31:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA29998 for ; Thu, 6 Aug 1998 07:31:33 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01790 for scwm-discuss@huis-clos.mit.edu; Thu, 6 Aug 1998 13:31:25 +0200 (CEST) Received: (qmail 444 invoked by uid 115); 6 Aug 1998 08:15:51 -0000 To: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Aug 1998 10:15:50 +0200 In-Reply-To: Greg Badros's message of "05 Aug 1998 18:57:23 -0700" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 05 Aug 1998 18:57:23 -0700 >>>>> Greg Badros said: Greg> senda@ic.rdc.ricoh.co.jp writes: >> I can't imagine people who posts a patch or code to the program >> released under GPL and insists on strict licence to it. :-) A patch is one thing. Scheme code that runs under scwm is not forced to GPL, IMHO (WordPerfect for Linux is not tainted by using syscalls either). >> But, I can understand your requirement. Greg> Following in Richard Stallman's footsteps. He's been burned, Greg> and we don't want to be. Do we have to sign papers now? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Aug 6 08:17:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA30306 for scwm-discuss-outgoing; Thu, 6 Aug 1998 08:17:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA30303 for ; Thu, 6 Aug 1998 08:17:18 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01587; Thu, 6 Aug 98 08:17:36 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA28873; Thu, 6 Aug 1998 15:16:47 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 06 Aug 1998 15:16:47 +0300 In-Reply-To: Robert Bihlmeyer's message of "06 Aug 1998 10:10:25 +0200" Message-Id: Lines: 43 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 04 Aug 1998 22:03:46 +0300 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> I still have to find out how to sort using guile. I also > Harvey> don't have a ispell mode, but I do have a plain-text output > Harvey> which should more or less be feedable to ispell & should give > Harvey> back the appropriate info. > > You lose the information where the misspelt word was located, don't you? Not if you, for example, the output is of the form: file:line: text file:line: text file:line: text file:line: text although, admittedly, it seems impossible to tell ispell to ignore the beginning of each line. I'll have to ask the guile list about opening pipes in guile. (open-pipe "cmd" mode) will only open 1 way pipes - guile can't both read & write them. I tried one trick: guile> (define p (pipe)) guile> (define q (open-input-pipe (string-append "cat 1<&" (number->string (port->fdes (cdr p)))))) guile> (display "eatme\n" (cdr p)) guile> (display "eatme\n" (cdr p)) guile> (display "eatme\n" (cdr p)) guile> (flush-all-ports) guile> (read-line q) but it didn't seem to work. I guess I'll have to email the guile folks... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Aug 6 09:38:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30665 for scwm-discuss-outgoing; Thu, 6 Aug 1998 09:38:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA30662 for ; Thu, 6 Aug 1998 09:38:25 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA19353; Thu, 6 Aug 98 09:38:44 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id JAA05924; Thu, 6 Aug 1998 09:37:47 -0400 (EDT) Message-Id: <199808061337.JAA05924@jekyll.piermont.com> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: ICCCM compliance In-Reply-To: Your message of "05 Aug 1998 20:31:53 +0200." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 06 Aug 1998 09:37:47 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Window managers should ensure that they provide > some mechanism for their clients to receive events > from all keys and all buttons, except for events > involving keys whose KeySyms are registered as > being for window management functions (for exam > ple, a hypothetical WINDOW KeySym) [Not so hypothetical with > flying-carpet-keys on most modern PC-keyboards -rb]. > > > In other words, window managers must provide some mechanism > by which a client can receive events from every key and but > ton (regardless of modifiers) unless and until the X Consor > tium registers some KeySyms as being reserved for window > management functions. Currently, no KeySyms are registered > for window management functions. I don't think this is particularly important, since no one seems to be following it (or at least, no one has in a long while). Besides, being able to hit c-arrow and have my virtual screens shift is too bloody convenient. :) Perry From owner-scwm-discuss@mit.edu Thu Aug 6 11:53:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31751 for scwm-discuss-outgoing; Thu, 6 Aug 1998 11:53:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA31748 for ; Thu, 6 Aug 1998 11:53:49 -0400 Received: by tis.bellhow.com; id LAA00941; Thu, 6 Aug 1998 11:53:36 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma000841; Thu, 6 Aug 98 11:53:03 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA10397 for ; Thu, 6 Aug 1998 11:53:03 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: BUG: interactive-{move,resize} broke in 8/6/98 snapshot Date: Thu, 06 Aug 1998 15:49:06 GMT Organization: Bell & Howell PSC Message-ID: <35cacb7c.675885111@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA31749 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Arrrrrhhhh!! :) In the 8/6/98 snapshot, interactive-move and interactive-resize look like they are working. You can move or resize the rubberband all over the place. But everything just snaps back into place! Moving a window from the FvwmPager module *does* work though. (Whew!) Should I be using something different than: (menuitem "Move" #:action interactive-move) Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Aug 6 12:16:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32047 for scwm-discuss-outgoing; Thu, 6 Aug 1998 12:16:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32044 for ; Thu, 6 Aug 1998 12:16:46 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA07258; Thu, 6 Aug 98 12:17:05 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbgz24402; Thu, 6 Aug 1998 16:16:36 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA26181; Thu, 6 Aug 1998 12:16:29 -0400 To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808061337.JAA05924@jekyll.piermont.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: "Perry E. Metzger"'s message of "Thu, 06 Aug 1998 09:37:47 -0400" Date: 06 Aug 1998 12:16:28 -0400 Message-Id: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199808061337.JAA05924@jekyll.piermont.com> >>>> Sent on Thu, 06 Aug 1998 09:37:47 -0400 >>>> Honorable "Perry E. Metzger" writes >>>> on the subject of "Re: ICCCM compliance": >> >> I don't think this is particularly important, since no one seems to >> be following it (or at least, no one has in a long while). I (intentionally :-) fail to see logic here. >> Besides, being able to hit c-arrow and have my virtual screens shift >> is too bloody convenient. :) Emacs binds C-arrow to word movement. This is why I leave C-* and M-* and C-M-* alone and bind virtual shifts to H-arrows, and make H (Hyper) the window keys via xmodmap. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. A man paints with his brains and not with his hands. From owner-scwm-discuss@mit.edu Thu Aug 6 12:30:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32228 for scwm-discuss-outgoing; Thu, 6 Aug 1998 12:30:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32225 for ; Thu, 6 Aug 1998 12:29:55 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA11107; Thu, 6 Aug 98 12:30:13 EDT Received: by tis.bellhow.com; id MAA05681; Thu, 6 Aug 1998 12:29:36 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005584; Thu, 6 Aug 98 12:28:56 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA12071 for ; Thu, 6 Aug 1998 12:28:51 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance Date: Thu, 06 Aug 1998 16:24:55 GMT Organization: Bell & Howell PSC Message-Id: <35cbd772.678947564@mailhost> References: <199808061337.JAA05924@jekyll.piermont.com> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA32226 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 06 Aug 1998 12:16:28 -0400, you wrote: >Emacs binds C-arrow to word movement. > >This is why I leave C-* and M-* and C-M-* alone and bind virtual shifts >to H-arrows, and make H (Hyper) the window keys via xmodmap. What do you think the *window-magager* keys are for anyway? :) Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Aug 6 14:12:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00768 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:12:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00760 for ; Thu, 6 Aug 1998 14:11:56 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA24312; Thu, 6 Aug 98 14:11:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13648; Thu, 6 Aug 1998 11:11:06 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <87iuk88ke7.fsf@jekyll.piermont.com> From: Greg Badros Date: 06 Aug 1998 11:11:06 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Aug 1998 20:31:53 +0200" Message-Id: Lines: 50 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 04 Aug 1998 18:14:24 -0400 > >>>>> "Perry E. Metzger" said: > > Perry> Has anyone checked scwm for compliance with the ICCCM > > Not that I know of. Just two things from the top of my head: > > ---- > > The [WM_HINTS] UrgencyHint flag, if set in the flags field, indicates > that the client deems the window contents to be urgent, requiring the > timely response of the user. The window man ager must make some effort > to draw the user's attention to this window while this flag is set. > The window manager must also monitor the state of this flag for the > entire time the window is in the Normal or Iconic state and must take > appro priate action when the state of the flag changes. The flag is > otherwise independent of the window's state; in particu lar, the > window manager is not required to deiconify the window if the client > sets the flag on an Iconic window. We now have a flash-window procedure, and a PropertyNotify hook, so we can (and should) do this at the scheme level. We may need to expose access to the hints field of the window structure, though. > Window managers should ensure that they provide > some mechanism for their clients to receive events > from all keys and all buttons, except for events > involving keys whose KeySyms are registered as > being for window management functions (for exam > ple, a hypothetical WINDOW KeySym) [Not so hypothetical with > flying-carpet-keys on most modern PC-keyboards -rb]. > > > In other words, window managers must provide some mechanism > by which a client can receive events from every key and but > ton (regardless of modifiers) unless and until the X Consor > tium registers some KeySyms as being reserved for window > management functions. Currently, no KeySyms are registered > for window management functions. This is part of the event and binding rewrite. I'll possibly be posting a revision of Maciej's thoughts on the interface later today (or tomorrow). Thanks for the suggestsions.... Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:14:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00819 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:14:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00812 for ; Thu, 6 Aug 1998 14:14:57 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA25076; Thu, 6 Aug 98 14:14:34 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13654; Thu, 6 Aug 1998 11:14:44 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808061337.JAA05924@jekyll.piermont.com> From: Greg Badros Date: 06 Aug 1998 11:14:44 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 12:16:28 -0400" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > This is why I leave C-* and M-* and C-M-* alone and bind virtual shifts > to H-arrows, and make H (Hyper) the window keys via xmodmap. Yea-- I just recently made my numlock key bind to a stick C-S-M, which is what I use for window manager bindings (mostly, anyway). Now I can hit num-lock, use the mouse to drag a window by pointing anywhere in the window and hit num-lock again when I'm done. All so I can keep eating french fries while hacking away! :-) Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:18:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00915 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:18:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00910 for ; Thu, 6 Aug 1998 14:18:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA09749; Thu, 6 Aug 98 14:18:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13651; Thu, 6 Aug 1998 11:12:59 -0700 (PDT) To: perry@piermont.com Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808061337.JAA05924@jekyll.piermont.com> From: Greg Badros Date: 06 Aug 1998 11:12:59 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Thu, 06 Aug 1998 09:37:47 -0400" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I don't think this is particularly important, since no one seems to be > following it (or at least, no one has in a long while). Besides, being > able to hit c-arrow and have my virtual screens shift is too bloody > convenient. :) Yea, but would really be annoying if I sat down at your X terminal and wanted to use my Emacs configuration which has other stuff bound to C-arrow keys. We can almost get quoting in the current code, but the quoted key event would be synthetic, which lots of programs (e.g., XTerm) ignore by default for security reasons (see earlier thread). Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:18:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00921 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:18:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00918 for ; Thu, 6 Aug 1998 14:18:52 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26139; Thu, 6 Aug 98 14:18:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13657; Thu, 6 Aug 1998 11:18:24 -0700 (PDT) To: Sascha Ziemann Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 06 Aug 1998 11:18:24 -0700 In-Reply-To: Sascha Ziemann's message of "06 Aug 1998 10:36:23 +0200" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sascha Ziemann writes: > I don't think that the documentation should contain SGML tags. That > make the documentation really unreadable. Do you want to wite all < as > <? How about equitations or similar things? SGML is a nice language Common cases we handle separately. > for text transformation but not for handwritten documentation and also > not for inline documentation in programs. If you still consider SGML > as part of the source, you should at least consider a different syntax > for the tags. It is necessary to save people from writing everything > twice. Because of this, I would prefer > > {code-example '(button1 sidebar)} > > instead of > > '(button1 sidebar) > > The first has 15 chars overhead compared to the bottom, which has 29 > chars overhead. It was a quite stupid idea of the IBM guy who invented > SGML not to follow Knuth's usage of {} for generic markup. I don't think the second way is any worse than the first way. People often comment what a closing brace delimits, and SGML forces that, and permits better detection of mis-nested entities. In either case, Emacs will be inserting the tags, anyway, so it's not extra typing, and the latter is less error-prone, and at least equally readable, to me. You're exactly right about <, e.g., and we make that as easy as possible. The one place where real markup is gonna hurt readability in the code is tables, but it's worth it for nice formatted documentation, IMHO. I read the code a lot less to learn about primitives now that I can get at the documentation from with scwm-mode of Emacs. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:20:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00972 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:20:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00963; Thu, 6 Aug 1998 14:20:27 -0400 Message-Id: <199808061820.OAA00963@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: Great flexibility In-reply-to: Your message of "06 Aug 1998 10:15:50 +0200." Date: Thu, 06 Aug 1998 14:20:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On 05 Aug 1998 18:57:23 -0700 > >>>>> Greg Badros said: > > Greg> senda@ic.rdc.ricoh.co.jp writes: > > >> I can't imagine people who posts a patch or code to the program > >> released under GPL and insists on strict licence to it. :-) > > A patch is one thing. Scheme code that runs under scwm is not forced > to GPL, IMHO (WordPerfect for Linux is not tainted by using syscalls > either). > I've only followed this discussion in a cursory way (trying to get some work on scwm done...), but IMO example code to run under scwm does not have to be GPL. I am not sure if I have explicitly put this in the docs, but I consider sample.scwmrc for instance to be public domain. However, if something is going to go into one of the shipped Scheme modules or something, I think the authors permission to distribute it under GPL would be a good thing. > >> But, I can understand your requirement. > > Greg> Following in Richard Stallman's footsteps. He's been burned, > Greg> and we don't want to be. > > Do we have to sign papers now? > I don't think it is useful or necessary to require copyright assignment for scwm, so there won't be any signing of papers. - Maciej From owner-scwm-discuss@mit.edu Thu Aug 6 14:23:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01114 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:23:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01109 for ; Thu, 6 Aug 1998 14:23:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27374; Thu, 6 Aug 98 14:22:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13660; Thu, 6 Aug 1998 11:23:02 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 06 Aug 1998 11:23:02 -0700 In-Reply-To: hjstein@bfr.co.il's message of "06 Aug 1998 12:47:59 +0300" Message-Id: Lines: 59 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I must concur, but for different reasons. WRT comment > extraction & sgml markup we have the following possibilities: > > 1. Write the comments in complete sgml, with all the stupid tag/end > tag pairs & all the stupid special character escapes, or > 2. Write the comments in partial sgml, or > 3. Mark up the comments in some easily parsible, concise, easy to > remember generic way. > 4. Something I'm not thinking of. > > If we follow option 1, then we can just extract the comments for the > SGML output, but we have to actually parse the SGML comments to > *remove* the SGML crap for something like the procedure listings/plain > text output. This'd make writing documentation much more painful for > the programmer. This is also hellish for the extractor, unless > *everything* is output in various forms of SGML & then run through > Jade or some other parser to generate html as well as plain text. That's the right thing to do -- docbook->ascii is a legitimate conversion and we might just need to clean it up a bit for scwm.el, but it could replace the tags with visual formatting as appropriate (or we could leave the tags in, and let a fancier emacs mode do some of the final SGML parsing. Or the emacs interface could talk to a netscape, or use W3-mode, or whatever. > > If we follow 2, then we have to parse the partial SGML comments so > that we can do things like escape characters properly & add additional > markup for SGML output & remove markup for procedure listings/plain > text output. This is marginally less painful for the programmer, but > even worse for the extractor, since we can't avoid parsing the > comments by just dumping them & running them through the SGML parser. This is what is currently done, and isn't so bad for the extractor. There are only a couple special cases (that are really important) that we treat differently, otherwise we use tags. > > If we follow 3, then by definition it's easy for the programmer & easy > for the extractor. And, it's already being done in that `xxx' denotes > a cross-link. The only problem is that we're creating a new markup > language which we'll require programmers to learn. I wouldn't have > much trouble parsing {tag stuff} & `xref', as suggested, & either > removing the {tag & } for plaintext output, or converting it to > stuff for sgml. I don't like the idea of trying to re-invent SGML. I was hesitant to suggest any special cases, but we really need them to make documenting easier, and in practice the extractor wasn't complicated much, so I think it was a good tradeoff. > > I can't comment on possibility 4. Me neither. :-) Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:29:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01298 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:29:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01293 for ; Thu, 6 Aug 1998 14:29:06 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28931; Thu, 6 Aug 98 14:28:36 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA13663; Thu, 6 Aug 1998 11:28:44 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 06 Aug 1998 11:28:43 -0700 In-Reply-To: Robert Bihlmeyer's message of "06 Aug 1998 10:15:50 +0200" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > A patch is one thing. Scheme code that runs under scwm is not forced > to GPL, IMHO (WordPerfect for Linux is not tainted by using syscalls > either). No but if we include it with Scwm, it'd be nice to have the scheme code under GPL. > >> But, I can understand your requirement. > > Greg> Following in Richard Stallman's footsteps. He's been burned, > Greg> and we don't want to be. > > Do we have to sign papers now? :-). Might not be a terrible idea, actually... Greg From owner-scwm-discuss@mit.edu Thu Aug 6 14:38:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01466 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:38:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01458 for ; Thu, 6 Aug 1998 14:38:30 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA15367; Thu, 6 Aug 98 14:38:45 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA09287; Thu, 6 Aug 1998 14:37:48 -0400 (EDT) Message-Id: <199808061837.OAA09287@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: ICCCM compliance In-Reply-To: Your message of "06 Aug 1998 11:12:59 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 06 Aug 1998 14:37:47 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > I don't think this is particularly important, since no one seems to be > > following it (or at least, no one has in a long while). Besides, being > > able to hit c-arrow and have my virtual screens shift is too bloody > > convenient. :) > > Yea, but would really be annoying if I sat down at your X terminal and > wanted to use my Emacs configuration which has other stuff bound to > C-arrow keys. Sure, but if the user REALLY wants it, that's the user's business. Perry From owner-scwm-discuss@mit.edu Thu Aug 6 14:54:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01691 for scwm-discuss-outgoing; Thu, 6 Aug 1998 14:54:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01681 for ; Thu, 6 Aug 1998 14:54:23 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20059; Thu, 6 Aug 98 14:54:39 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA14515; Thu, 6 Aug 1998 11:54:02 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: interactive-{move,resize} broke in 8/6/98 snapshot References: <35cacb7c.675885111@mailhost> From: Greg Badros Date: 06 Aug 1998 11:54:02 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 06 Aug 1998 15:49:06 GMT" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > In the 8/6/98 snapshot, interactive-move and interactive-resize look > like they are working. You can move or resize the rubberband all over > the place. But everything just snaps back into place! I'll fix it real soon. > > Moving a window from the FvwmPager module *does* work though. (Whew!) > > Should I be using something different than: > > (menuitem "Move" #:action interactive-move) No, I just screwed up trying to reduce the number of X11 calls. Thanks for testing and catching this so quickly -- it makes the fix obvious. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 15:01:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01903 for scwm-discuss-outgoing; Thu, 6 Aug 1998 15:01:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01900 for ; Thu, 6 Aug 1998 15:01:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07451; Thu, 6 Aug 98 15:00:39 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA14610; Thu, 6 Aug 1998 11:58:09 -0700 (PDT) To: perry@piermont.com Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808061837.OAA09287@jekyll.piermont.com> From: Greg Badros Date: 06 Aug 1998 11:58:08 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Thu, 06 Aug 1998 14:37:47 -0400" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > "Perry E. Metzger" writes: > > > > > I don't think this is particularly important, since no one seems to be > > > following it (or at least, no one has in a long while). Besides, being > > > able to hit c-arrow and have my virtual screens shift is too bloody > > > convenient. :) > > > > Yea, but would really be annoying if I sat down at your X terminal and > > wanted to use my Emacs configuration which has other stuff bound to > > C-arrow keys. > > Sure, but if the user REALLY wants it, that's the user's > business. Not according to the ICCCM, though (someone is looking out for me). And the user can still not have a key bound to the quote-next-key command if they REALLY REALLY want it. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 15:45:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02517 for scwm-discuss-outgoing; Thu, 6 Aug 1998 15:45:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02514 for ; Thu, 6 Aug 1998 15:45:10 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA04589; Thu, 6 Aug 98 15:45:27 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbhm04057; Thu, 6 Aug 1998 19:44:38 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA26802; Thu, 6 Aug 1998 15:44:32 -0400 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 11:23:02 -0700" Date: 06 Aug 1998 15:44:07 -0400 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 11:23:02 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documentation conventions refocusing...": >> >> That's the right thing to do -- docbook->ascii is a legitimate >> conversion and we might just need to clean it up a bit for scwm.el, but >> it could replace the tags with visual formatting as appropriate (or we >> could leave the tags in, and let a fancier emacs mode do some of the >> final SGML parsing. Or the emacs interface could talk to a netscape, or >> use W3-mode, or whatever. Get real, folks! It *is* easy to make scwm.el call w3 or netscape, but IMO it's a stupid thing to do. Both w3 and netscape are *huge*, and launch them for the sake of 10 lines is a waste. Hyperlinks in help are standard with e20.3, scwm.el supports them already, and those runnig the pretest can check it out. I would suggest that files scwm-procedures.txt &Co are kept just that - *.txt, i.e., with all markup stripped. Remember, these files are used by *guile* procedures, and they must output to terminal, and it has to look nice. So these text files should contain preformatted docs. scwm.el hypelinks quoted symbols, like `this', to point to documentation of these symbols. I can highlight things marked with *stars*, or underline underlined _things_, but I don't think we want more than that. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Cannot handle the fatal error due to a fatal error in the fatal error handler. From owner-scwm-discuss@mit.edu Thu Aug 6 15:51:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02589 for scwm-discuss-outgoing; Thu, 6 Aug 1998 15:51:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02586 for ; Thu, 6 Aug 1998 15:51:02 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA06277; Thu, 6 Aug 98 15:51:20 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbhn05929; Thu, 6 Aug 1998 19:50:46 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA26822; Thu, 6 Aug 1998 15:50:40 -0400 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 11:28:43 -0700" Date: 06 Aug 1998 15:50:27 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 11:28:43 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Great flexibility": >> Robert Bihlmeyer writes: >> > Do we have to sign papers now? >> :-). Might not be a terrible idea, actually... Who do we assign copyright? FSF? You? Maciej? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Thu Aug 6 16:11:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02849 for scwm-discuss-outgoing; Thu, 6 Aug 1998 16:11:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02845 for ; Thu, 6 Aug 1998 16:11:47 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA12728; Thu, 6 Aug 98 16:12:03 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id QAA09439; Thu, 6 Aug 1998 16:11:25 -0400 (EDT) Message-Id: <199808062011.QAA09439@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: ICCCM compliance In-Reply-To: Your message of "06 Aug 1998 11:58:08 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 06 Aug 1998 16:11:25 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > Greg Badros writes: > > > "Perry E. Metzger" writes: > > > > > > > I don't think this is particularly important, since no one seems to be > > > > following it (or at least, no one has in a long while). Besides, being > > > > able to hit c-arrow and have my virtual screens shift is too bloody > > > > convenient. :) > > > > > > Yea, but would really be annoying if I sat down at your X terminal and > > > wanted to use my Emacs configuration which has other stuff bound to > > > C-arrow keys. > > > > Sure, but if the user REALLY wants it, that's the user's > > business. > > Not according to the ICCCM, though (someone is looking out for me). Sure enough, but on the other hand, I don't know of a widely used window manager right now that doesn't let you do things like this. fvwm does, as do most others. it isn't something we should reasonably prohibit if we want to be able to emulate the behavior of other window managers. Perry From owner-scwm-discuss@mit.edu Thu Aug 6 16:58:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03289 for scwm-discuss-outgoing; Thu, 6 Aug 1998 16:58:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA03286 for ; Thu, 6 Aug 1998 16:58:49 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26057; Thu, 6 Aug 98 16:59:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16659; Thu, 6 Aug 1998 13:58:11 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 06 Aug 1998 13:58:11 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 15:44:07 -0400" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> That's the right thing to do -- docbook->ascii is a legitimate > >> conversion and we might just need to clean it up a bit for scwm.el, but > >> it could replace the tags with visual formatting as appropriate (or we > >> could leave the tags in, and let a fancier emacs mode do some of the > >> final SGML parsing. Or the emacs interface could talk to a netscape, or > >> use W3-mode, or whatever. > > Get real, folks! It *is* easy to make scwm.el call w3 or netscape, but > IMO it's a stupid thing to do. Both w3 and netscape are *huge*, and > launch them for the sake of 10 lines is a waste. Hyperlinks in help are > standard with e20.3, scwm.el supports them already, and those runnig the > pretest can check it out. But my netscape is running anyway, and viewing tables in it is a big win. > I would suggest that files scwm-procedures.txt &Co are kept just that - > *.txt, i.e., with all markup stripped. Remember, these files are used > by *guile* procedures, and they must output to terminal, and it has to > look nice. So these text files should contain preformatted docs. > > scwm.el hypelinks quoted symbols, like `this', to point to documentation > of these symbols. I can highlight things marked with *stars*, or > underline underlined _things_, but I don't think we want more than that. I like scwm.el as it is now. But I also think that once the html manual is more useful (e.g., when we reformat tables to be real sgml tables) that permitting a link to reference the web page also makes sense. I hacked some emacs functions to let me get at the JDK documentation in an already-running netscape and got a lot of benefit out of it -- very speedy response if the netscape is already going. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 17:00:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03316 for scwm-discuss-outgoing; Thu, 6 Aug 1998 17:00:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03313 for ; Thu, 6 Aug 1998 17:00:32 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26572; Thu, 6 Aug 98 17:00:48 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA16688; Thu, 6 Aug 1998 14:00:11 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 06 Aug 1998 14:00:11 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 15:50:27 -0400" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 06 Aug 1998 11:28:43 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Great flexibility": > >> Robert Bihlmeyer writes: > >> > Do we have to sign papers now? > >> :-). Might not be a terrible idea, actually... > > Who do we assign copyright? > FSF? You? Maciej? The FSF has people sign papers and mail them back to them. I think we should just make the mailing list announcement note that anything posted is donated to the scwm developers and can be used for whatever unless otherwise marked. Then we don't need people saying "this is GPL" and we get a reasonable amount of protection against someone suing us later. I hate that we have to think about this at all, but prudence is warranted here, as it is always. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 18:22:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03890 for scwm-discuss-outgoing; Thu, 6 Aug 1998 18:22:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03887 for ; Thu, 6 Aug 1998 18:22:07 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA15995; Thu, 6 Aug 98 18:22:23 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbhx06066; Thu, 6 Aug 1998 22:21:38 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA27034; Thu, 6 Aug 1998 18:21:34 -0400 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 14:00:11 -0700" Date: 06 Aug 1998 18:21:33 -0400 Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 14:00:11 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Great flexibility": >> I think we should just make the mailing list announcement note that >> anything posted is donated to the scwm developers and can be used >> for whatever unless otherwise marked. This is illegal and unenforceable. People must make a conscious effort to GPL their code. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. XFM: Exit file manager? [Continue] [Cancel] [Abort] From owner-scwm-discuss@mit.edu Thu Aug 6 18:27:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03916 for scwm-discuss-outgoing; Thu, 6 Aug 1998 18:27:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03913 for ; Thu, 6 Aug 1998 18:27:20 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA25590; Thu, 6 Aug 98 18:26:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA17017; Thu, 6 Aug 1998 15:27:05 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 06 Aug 1998 15:27:05 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 18:21:33 -0400" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 06 Aug 1998 14:00:11 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Great flexibility": > > >> I think we should just make the mailing list announcement note that > >> anything posted is donated to the scwm developers and can be used > >> for whatever unless otherwise marked. > > This is illegal and unenforceable. > > People must make a conscious effort to GPL their code. I'm certainly not an expert, but it seems that if someone chooses to post to a mailing list that has an explicit policy regarding those posts, that then we'd be in the clear. I thought code made publicly available is in the public domain, anyway, and we'd just be making that more clear. (I didn't mean to imply that the posted code would fall under GPL -- that seems trickier since that's an explicit license.) Greg From owner-scwm-discuss@mit.edu Thu Aug 6 18:30:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03943 for scwm-discuss-outgoing; Thu, 6 Aug 1998 18:30:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03940 for ; Thu, 6 Aug 1998 18:30:35 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA17201; Thu, 6 Aug 98 18:30:52 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbhx07704; Thu, 6 Aug 1998 22:29:57 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA27038; Thu, 6 Aug 1998 18:29:53 -0400 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 13:58:11 -0700" Date: 06 Aug 1998 18:29:53 -0400 Message-Id: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 13:58:11 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documentation conventions refocusing...": >> >> > I would suggest that files scwm-procedures.txt &Co are kept just that - >> > *.txt, i.e., with all markup stripped. Remember, these files are used >> > by *guile* procedures, and they must output to terminal, and it has to >> > look nice. So these text files should contain preformatted docs. You did not comment on this *crucial* paragraph. We have to separate the (hypertext) *manual* (in info/html/sgml etc) and *function docs* (in plain text). These are two separate, though related, projects. >> I also think that once the html manual is more useful (e.g., when we >> reformat tables to be real sgml tables) that permitting a link to >> reference the web page also makes sense. I hacked some emacs >> functions to let me get at the JDK documentation in an >> already-running netscape and got a lot of benefit out of it -- very >> speedy response if the netscape is already going. "When all you have is a hammer, everything looks like a nail." I am not a big fan of netscape or html, and I think that info is a far superior format for viewing software manuals, especially if you are using Emacs anyway. It is easy to adopt hyperspec.el to our needs, but this is a separate project - this is for *manual*, not for *function docs*. Note that emacs has C-h f and C-h C-f, and they do different things. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. The difference between genius and stupidity is that genius has its limits. From owner-scwm-discuss@mit.edu Thu Aug 6 18:36:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04027 for scwm-discuss-outgoing; Thu, 6 Aug 1998 18:36:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA04024 for ; Thu, 6 Aug 1998 18:36:44 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18343; Thu, 6 Aug 98 18:36:59 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA17024; Thu, 6 Aug 1998 15:36:18 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 06 Aug 1998 15:36:18 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 18:29:53 -0400" Message-Id: Lines: 55 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 06 Aug 1998 13:58:11 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Documentation conventions refocusing...": > >> > >> > I would suggest that files scwm-procedures.txt &Co are kept just that - > >> > *.txt, i.e., with all markup stripped. Remember, these files are used > >> > by *guile* procedures, and they must output to terminal, and it has to > >> > look nice. So these text files should contain preformatted docs. > > You did not comment on this *crucial* paragraph. > > We have to separate the (hypertext) *manual* (in info/html/sgml etc) and > *function docs* (in plain text). These are two separate, though > related, projects. I agree that the plain-text docs are very useful, but don't see why they're so separate. I just view them as another way of getting the same information, and a docbook->ascii converter is probably the right way to get the function docs (e.g., it would do a better job with tables once they are sgml formatted). > > >> I also think that once the html manual is more useful (e.g., when we > >> reformat tables to be real sgml tables) that permitting a link to > >> reference the web page also makes sense. I hacked some emacs > >> functions to let me get at the JDK documentation in an > >> already-running netscape and got a lot of benefit out of it -- very > >> speedy response if the netscape is already going. > > "When all you have is a hammer, everything looks like a nail." Including nails. :-) > I am not a big fan of netscape or html, and I think that info is a far > superior format for viewing software manuals, especially if you are > using Emacs anyway. It is easy to adopt hyperspec.el to our needs, but > this is a separate project - this is for *manual*, not for *function > docs*. Note that emacs has C-h f and C-h C-f, and they do different > things. I much prefer info for it's keyboard-navigability, but I see that as a shortcoming of the browsers, not a fundamental problem with the format. All I was suggesting is that having a binding to go to the info/html manual for a scwm procedure/var/hook makes sense to, as it does in Emacs. And that it could be configurable whether it goes to the info page or to a browser via some remote URL specification mechanism such as what Netscape supports. (Your scwm mode already does have C-h C-f distinct from C-h C-s, it's just that our info documentation is lacking for lack of a docbook->info converter). Greg From owner-scwm-discuss@mit.edu Thu Aug 6 19:12:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA04257 for scwm-discuss-outgoing; Thu, 6 Aug 1998 19:12:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA04254 for ; Thu, 6 Aug 1998 19:12:53 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA23649; Thu, 6 Aug 98 19:13:08 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id AAA01189 for ; Fri, 7 Aug 1998 00:12:35 +0100 Date: Fri, 7 Aug 1998 00:12:35 +0100 (BST) From: Danius Michaelides To: scwm-discuss@mit.edu Subject: winlist skip Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Just visiting the winlist-skip situation. I start an FvwmIconMan in my .scwmrc, and it lists all windows, including those with winlist-skip set. But if i start a new FvwmIconMan from scwmrepl it works fine, and only windows that should are shown. Any ideas? Completely unrelated note question. Whats the current status if the border drawing code? I've noticed that all my windows have a dark border around them (it appears to be the relief shadow colour), which i've not noticed before. My only point of reference is what fvwm2 does and its putting the relief highlight colour two lines in for top and left, and two pixels of relief shadow right and bottom. Currently, with scwm there appears to be the dark line around the whole window, and within that 2 lines of highlight top and left, and only 1 line of shadow bottom and right. Danius (anon-cvs update done at about 7GMT today) From owner-scwm-discuss@mit.edu Thu Aug 6 20:09:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04538 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:09:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04535 for ; Thu, 6 Aug 1998 20:09:52 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA01339; Thu, 6 Aug 98 20:10:07 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbie19978; Fri, 7 Aug 1998 00:09:36 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id UAA27250; Thu, 6 Aug 1998 20:09:31 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 15:27:05 -0700" Date: 06 Aug 1998 20:09:29 -0400 Message-Id: Lines: 69 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 15:27:05 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Great flexibility": >> Sam Steingold writes: >> >> > >>>> In message >> > >>>> Sent on 06 Aug 1998 14:00:11 -0700 >> > >>>> Honorable Greg Badros writes >> > >>>> on the subject of "Re: Great flexibility": >> > >> > >> I think we should just make the mailing list announcement note that >> > >> anything posted is donated to the scwm developers and can be used >> > >> for whatever unless otherwise marked. >> > >> > This is illegal and unenforceable. >> > >> > People must make a conscious effort to GPL their code. >> >> I'm certainly not an expert, but it seems that if someone chooses to >> post to a mailing list that has an explicit policy regarding those >> posts, that then we'd be in the clear. I thought code made publicly >> available is in the public domain, anyway, and we'd just be making that >> more clear. (I didn't mean to imply that the posted code would fall >> under GPL -- that seems trickier since that's an explicit license.) AFAIK, according to the Bern convention on copyright, the author keeps all right reserved unless s/he explicitly makes an effort to put his works under a PD or other public license. Open any book, you will see words "all right reserved" after the (C). Let me repeat: according to the international law, this is gratuitous. Unless otherwise explicitly stated by the author, the rights are *always* reserved. No publicly stated policy can change that. Whatever code I post (hey, forget the code - the message I am typing right now) is (C) by me, and cannot be reproduced without proper attribution and via the media other than the one I used. I mean, you can quote me on this list with proper attribution (you don't need my permission to do that), but you cannot post it to a newsgroup without my permission. The upshot is: whenever you post any code, indicate the licensing (PD, BSD, GPL etc). Otherwise we cannot redistribute it. Once is *NOT* enough. You have to re-state it each time you post. Moreover, just to squash the issue :-), the copyright holder (the author of the entity to which s/he has assigned the copyright) can change the licensing *at any time*. This is the reason for RMS requiring assignment. I signed papers to him. The assignment is *CONDITIONAL* on distribution under the GPL. I agree to assign my copyright to FSF on condition that they distribute it under the GPL; if they try to distribute it under any other conditions, the copyright reverts to me. So, for my ELisp distributed with Emacs to be withdrawn from GPL, FSF must first put it under a different license, so that the copyright reverts to me, and then I have to take it out of the GPL. This system makes Emacs very safely anchored in the GPL. Note that if X sends a patch to the list and says it's GPLed, we take it, and then a week later X has second thoughts and withdraws the patch from GPL, we are legally required to remove the patch. This is an unlikely scenario, but it is wise to know where we stand, isn't it? Disclaimer: I am *not* a lawyer. The above information if true to the best of my knowledge. The source is USENET (and a private conversation with a copyright lawyer; NB: I was *NOT* his client). -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Who is General Failure and why is he reading my hard disk? From owner-scwm-discuss@mit.edu Thu Aug 6 20:12:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04569 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:12:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04566 for ; Thu, 6 Aug 1998 20:12:49 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA09585; Thu, 6 Aug 98 20:12:21 EDT Received: (qmail 16147 invoked by uid 501); 7 Aug 1998 00:12:24 -0000 Message-Id: <19980806171224.A15775@molehill.org> Date: Thu, 6 Aug 1998 17:12:24 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: minor bugs(?) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Barman, three German beers", said Hans drily. Sender: owner-scwm-discuss@mit.edu Precedence: bulk After a long time of half-following the mailing list and wanting to use scwm, I finally have a system where I can install all the necessary versions of things to try it out. I'm using a cvs grab of guile from last night, and was using the 19980805 scwm snapshot, and just updated that with a cvs checkout. I've noticed a couple problems, either scwm bugs or something I'm not understanding. 1. none of the documentation functions work in scwm.el. This seems to be rooted in the fact that neither `apropos' nor `apropos-internal' are defined. fecundity:~% scwmexec '(apropos-internal "")' Backtrace: 0* (apropos-internal "") ERROR: In expression (apropos-internal ""): ERROR: Unbound variable: apropos-internal I can't find anything in either the C or Scheme code which looks like it tries to define either of these. Are these supposed to be guile builtins? Besides scwm-apropos obviously not working, without this scwm-make-obarray fails, so I can't type anything in to get scwm-documentation. 2. I'm using a .scwmrc based on juhp.scwmrc. The functions there bound to A-Tab and A-S-Tab mostly work. When I'm in a screen with another screen below it, and there's a window in the lower screen pressed right up against the top border, that window seems to be counted as visible?. I can see a thin stripe at the very bottom of the top viewport, which may be related. I'm moving screens with (move-screen 0 1) and similar, so I don't think I could be just not moving a whole screen worth. By "against the top border", I mean "where the window pauses when being moved upwards, with a high edge-resistance. The geometry window shows "-1 863" (I use 1190x864), so it looks like edge-resistance is off by one? I tried diff -u -r1.51 move.c --- move.c 1998/08/06 03:24:32 1.51 +++ move.c 1998/08/07 00:07:10 @@ -210,12 +210,12 @@ ((*px + width) < Scr.DisplayWidth + resistance)) *px = Scr.DisplayWidth - width - bw*2; if ((*px < 0) && (*px > -resistance)) - *px = -bw; + *px = 0; if (((*py + height) >= Scr.DisplayHeight) && ((*py + height) < Scr.DisplayHeight + resistance)) *py = Scr.DisplayHeight - height - bw*2; if ((*py < 0) && (*py > -resistance)) - *py = -bw; + *py = 0; } /* and that seems to fix the thin stripe and the bad geometry numbers, but the A-tab behavior is still wrong. Also, windows don't get quite up against the right side, but stay one or two pixels away. 3) when restarting scwm, xterms shrink. It looks like maybe they're being resized so their post-restart size, including the titlebar, is the pre-restart size ignoring the titlebar. Feature request: I'd love a way to control the width of the border between the titlebar and the client window. If I can be any help tracking these down, let me know. From owner-scwm-discuss@mit.edu Thu Aug 6 20:14:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04608 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:14:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04605 for ; Thu, 6 Aug 1998 20:14:46 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA09879; Thu, 6 Aug 98 20:14:20 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbie22376; Fri, 7 Aug 1998 00:14:13 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id UAA27254; Thu, 6 Aug 1998 20:14:09 -0400 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Aug 1998 15:36:18 -0700" Date: 06 Aug 1998 20:14:07 -0400 Message-Id: Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Aug 1998 15:36:18 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documentation conventions refocusing...": >> Sam Steingold writes: >> > "When all you have is a hammer, everything looks like a nail." >> Including nails. :-) !!!! :-) :-) :-) >> All I was suggesting is that having a binding to go to the info/html >> manual for a scwm procedure/var/hook makes sense to, as it does in >> Emacs. And that it could be configurable whether it goes to the info >> page or to a browser via some remote URL specification mechanism such as >> what Netscape supports. (Your scwm mode already does have C-h C-f >> distinct from C-h C-s, it's just that our info documentation is lacking >> for lack of a docbook->info converter). You are right. I misunderstood you. I thought you were suggesting that the output of `documentation' (in guile) should be somehow piped to netscape. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Just because you're paranoid doesn't mean they AREN'T after you. From owner-scwm-discuss@mit.edu Thu Aug 6 20:15:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04638 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:15:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04634 for ; Thu, 6 Aug 1998 20:15:44 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA02111; Thu, 6 Aug 98 20:16:00 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA19621; Thu, 6 Aug 1998 17:15:28 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <19980806103720Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 06 Aug 1998 17:15:27 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 20:09:29 -0400" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > The upshot is: whenever you post any code, indicate the licensing (PD, > BSD, GPL etc). Otherwise we cannot redistribute it. Once is *NOT* > enough. You have to re-state it each time you post. This was my original request, even if my understanding of the related law is (now somewhat less) fuzzy. Thanks for the clarifications -- an officemate who's also dealt with assignment papers for Stallman and the FSF shares your understanding. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 20:22:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04784 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:22:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04781 for ; Thu, 6 Aug 1998 20:22:35 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10651; Thu, 6 Aug 98 20:22:10 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA19926; Thu, 6 Aug 1998 17:22:16 -0700 (PDT) To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: winlist skip References: From: Greg Badros Date: 06 Aug 1998 17:22:16 -0700 In-Reply-To: Danius Michaelides's message of "Fri, 7 Aug 1998 00:12:35 +0100 (BST)" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Danius Michaelides writes: > Just visiting the winlist-skip situation. I start an FvwmIconMan in > my .scwmrc, and it lists all windows, including those with > winlist-skip set. But if i start a new FvwmIconMan from scwmrepl it > works fine, and only windows that should are shown. Any ideas? Where do you start the FvwmIconMan in your .scwmrc? Same behaviour if you start it at the end? Maybe try starting it from your startup-hook. The winlist-skip is now handled via a scheme level object property that doesn't get set until pretty late in the game, which might be the cause of your problem. We'll have to look into it more thoroughly, but knowing what workaround works around the problem will help us track down the problem. > Completely unrelated note question. Whats the current status if the > border drawing code? I've noticed that all my windows have a dark > border around them (it appears to be the relief shadow colour), which > i've not noticed before. My only point of reference is what fvwm2 does > and its putting the relief highlight colour two lines in for top and > left, and two pixels of relief shadow right and bottom. Currently, > with scwm there appears to be the dark line around the whole window, > and within that 2 lines of highlight top and left, and only 1 line of > shadow bottom and right. Not sure, off hand. The decorating code has so many possibilities and options and no clear invariants that it is really difficult to reason about or test, and therefore tricky to change (as is lots of the old fvwm2 code -- thankfully less and less of that exists!). Greg From owner-scwm-discuss@mit.edu Thu Aug 6 20:23:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04837 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:23:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04834 for ; Thu, 6 Aug 1998 20:23:56 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03089; Thu, 6 Aug 98 20:24:12 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA19935; Thu, 6 Aug 1998 17:23:37 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Sascha Ziemann , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 06 Aug 1998 17:23:36 -0700 In-Reply-To: Sam Steingold's message of "06 Aug 1998 20:14:07 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 06 Aug 1998 15:36:18 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Documentation conventions refocusing...": > >> Sam Steingold writes: > >> > "When all you have is a hammer, everything looks like a nail." > >> Including nails. :-) > !!!! :-) :-) :-) > > >> All I was suggesting is that having a binding to go to the info/html > >> manual for a scwm procedure/var/hook makes sense to, as it does in > >> Emacs. And that it could be configurable whether it goes to the info > >> page or to a browser via some remote URL specification mechanism such as > >> what Netscape supports. (Your scwm mode already does have C-h C-f > >> distinct from C-h C-s, it's just that our info documentation is lacking > >> for lack of a docbook->info converter). > > You are right. I misunderstood you. > I thought you were suggesting that the output of `documentation' (in > guile) should be somehow piped to netscape. Gosh no. That'd be insane! :-) Greg From owner-scwm-discuss@mit.edu Thu Aug 6 20:35:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05057 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:35:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05053 for ; Thu, 6 Aug 1998 20:35:23 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04510; Thu, 6 Aug 98 20:35:37 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA20132; Thu, 6 Aug 1998 17:35:02 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> From: Greg Badros Date: 06 Aug 1998 17:35:01 -0700 In-Reply-To: Todd Larason's message of "Thu, 6 Aug 1998 17:12:24 -0700" Message-Id: Lines: 116 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > After a long time of half-following the mailing list and wanting to > use scwm, I finally have a system where I can install all the > necessary versions of things to try it out. > > I'm using a cvs grab of guile from last night, and was using the > 19980805 scwm snapshot, and just updated that with a cvs checkout. > > I've noticed a couple problems, either scwm bugs or something I'm not > understanding. > > 1. none of the documentation functions work in scwm.el. This seems to > be rooted in the fact that neither `apropos' nor `apropos-internal' > are defined. > > fecundity:~% scwmexec '(apropos-internal "")' > > Backtrace: > 0* (apropos-internal "") > > ERROR: In expression (apropos-internal ""): > ERROR: Unbound variable: apropos-internal > > I can't find anything in either the C or Scheme code which looks like > it tries to define either of these. Are these supposed to be guile > builtins? In my June 30th snapshot, apropos-internal is defined in ice-9/session.scm. > Besides scwm-apropos obviously not working, without this > scwm-make-obarray fails, so I can't type anything in to get > scwm-documentation. Though it's far from ideal, I keep a (usually) recent copy of the html manual at: http://www.cs.washington.edu/research/constraints/cassowary/scwm-doc/ > 2. I'm using a .scwmrc based on juhp.scwmrc. The functions there > bound to A-Tab and A-S-Tab mostly work. When I'm in a screen with > another screen below it, and there's a window in the lower screen > pressed right up against the top border, that window seems to be > counted as visible?. > > I can see a thin stripe at the very bottom of the top viewport, which > may be related. > > I'm moving screens with (move-screen 0 1) and similar, so I don't > think I could be just not moving a whole screen worth. > > By "against the top border", I mean "where the window pauses when > being moved upwards, with a high edge-resistance. The geometry window > shows "-1 863" (I use 1190x864), so it looks like edge-resistance is > off by one? > > I tried > diff -u -r1.51 move.c > --- move.c 1998/08/06 03:24:32 1.51 > +++ move.c 1998/08/07 00:07:10 > @@ -210,12 +210,12 @@ > ((*px + width) < Scr.DisplayWidth + resistance)) > *px = Scr.DisplayWidth - width - bw*2; > if ((*px < 0) && (*px > -resistance)) > - *px = -bw; > + *px = 0; > if (((*py + height) >= Scr.DisplayHeight) && > ((*py + height) < Scr.DisplayHeight + resistance)) > *py = Scr.DisplayHeight - height - bw*2; > if ((*py < 0) && (*py > -resistance)) > - *py = -bw; > + *py = 0; > } Weird. I just changed those lines because I get an off by one error in that windows don't butt up against the edge properly. I'll figure out what's really going wrong since my experiment failed. > > /* > > and that seems to fix the thin stripe and the bad geometry numbers, but > the A-tab behavior is still wrong. I'll look into that. Circulate should probably do something more reasonable with windows that are mostly not on the current screen anyway (even 5% of a window probably shouldn't count). > > Also, windows don't get quite up against the right side, but stay one > or two pixels away. That was the problem I was having with the left and top. Crazy. > > 3) when restarting scwm, xterms shrink. It looks like maybe they're > being resized so their post-restart size, including the titlebar, is > the pre-restart size ignoring the titlebar. Okay. I'll see about it. > Feature request: I'd love a way to control the width of the border > between the titlebar and the client window. Noted, but any more options concerning decorations are especially tricky. I experimented yesterday with a squashed titlebar option and, though it went reasonably well, I'm convinced that we need to clean up that code before adding anything else. Too many options that are too hard to test. > If I can be any help tracking these down, let me know. Patches are *always* welcome! :-) Thanks, Greg From owner-scwm-discuss@mit.edu Thu Aug 6 20:45:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05168 for scwm-discuss-outgoing; Thu, 6 Aug 1998 20:45:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05165 for ; Thu, 6 Aug 1998 20:45:02 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA05601; Thu, 6 Aug 98 20:45:18 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbig01649; Fri, 7 Aug 1998 00:44:48 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id UAA27508; Thu, 6 Aug 1998 20:44:42 -0400 To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Thu, 6 Aug 1998 17:12:24 -0700" Date: 06 Aug 1998 20:44:41 -0400 Message-Id: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19980806171224.A15775@molehill.org> >>>> Sent on Thu, 6 Aug 1998 17:12:24 -0700 >>>> Honorable Todd Larason writes >>>> on the subject of "minor bugs(?)": >> After a long time of half-following the mailing list and wanting to >> use scwm, I finally have a system where I can install all the >> necessary versions of things to try it out. Welcome! >> I'm using a cvs grab of guile from last night, and was using the >> 19980805 scwm snapshot, and just updated that with a cvs checkout. >> Besides scwm-apropos obviously not working, without this >> scwm-make-obarray fails, so I can't type anything in to get >> scwm-documentation. My guile (19980625) has both `apropos' and `apropos-internal'. I'll think of something to allow you to use `scwm-documentation' without `scwm-obarray'. But you should investigate further - apropos* are really nice and important functions. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Thu Aug 6 21:22:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05445 for scwm-discuss-outgoing; Thu, 6 Aug 1998 21:22:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA05442 for ; Thu, 6 Aug 1998 21:22:48 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA10478; Thu, 6 Aug 98 21:22:56 EDT Received: (qmail 16938 invoked by uid 501); 7 Aug 1998 01:22:24 -0000 Message-Id: <19980806182224.A16481@molehill.org> Date: Thu, 6 Aug 1998 18:22:24 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Aug 06, 1998 at 05:35:01PM -0700 X-Tom-Swifty: "For the umpteenth time, pass the sauce for the pancakes!" said Tom syrupetitiously. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980806, Greg Badros wrote: > > ERROR: In expression (apropos-internal ""): > > ERROR: Unbound variable: apropos-internal > > > > I can't find anything in either the C or Scheme code which looks like > > it tries to define either of these. Are these supposed to be guile > > builtins? > > In my June 30th snapshot, apropos-internal is defined in ice-9/session.scm. ah ha. I added (ice-9 session) to the use-modules form; I don't know if this should be added to the samples or not, but it was far from obvious to me. I hope I didn't miss some obvious documentation. All the scwm-documentation stuff works now, and is VERY cool. > Though it's far from ideal, I keep a (usually) recent copy of the html > manual at: > > http://www.cs.washington.edu/research/constraints/cassowary/scwm-doc/ Thanks! > Weird. I just changed those lines because I get an off by one error in > that windows don't butt up against the edge properly. I'll figure out > what's really going wrong since my experiment failed. diff -u -r1.51 move.c --- move.c 1998/08/06 03:24:32 1.51 +++ move.c 1998/08/07 01:04:31 @@ -206,16 +206,16 @@ SnapCoordsToEdges(int *px, int *py, int width, int height, int bw, int resistance) { /* Resist moving windows over the edge of the screen! */ - if (((*px + width) >= Scr.DisplayWidth) && - ((*px + width) < Scr.DisplayWidth + resistance)) - *px = Scr.DisplayWidth - width - bw*2; + if (((*px + width + bw*2) >= Scr.DisplayWidth) && + ((*px + width + bw*2) < Scr.DisplayWidth + resistance)) + *px = Scr.DisplayWidth - width - bw*2 + 1; if ((*px < 0) && (*px > -resistance)) - *px = -bw; - if (((*py + height) >= Scr.DisplayHeight) && - ((*py + height) < Scr.DisplayHeight + resistance)) - *py = Scr.DisplayHeight - height - bw*2; + *px = 0; + if (((*py + height + bw*2) >= Scr.DisplayHeight) && + ((*py + height + bw*2) < Scr.DisplayHeight + resistance)) + *py = Scr.DisplayHeight - height - bw*2 + 1; if ((*py < 0) && (*py > -resistance)) - *py = -bw; + *py = 0; } /* looks right to me, and seems to work. the +1s are because Width and Height are 1 based, and coordinates are 0 based. > I'll look into that. Circulate should probably do something more > reasonable with windows that are mostly not on the current screen anyway > (even 5% of a window probably shouldn't count). I'm looking further into this now. From owner-scwm-discuss@mit.edu Thu Aug 6 21:55:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05711 for scwm-discuss-outgoing; Thu, 6 Aug 1998 21:55:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA05708 for ; Thu, 6 Aug 1998 21:55:50 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA21040; Thu, 6 Aug 98 21:53:27 EDT Received: (qmail 17144 invoked by uid 501); 7 Aug 1998 01:53:34 -0000 Message-Id: <19980806185334.A16951@molehill.org> Date: Thu, 6 Aug 1998 18:53:34 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980806182224.A16481@molehill.org>; from Todd Larason on Thu, Aug 06, 1998 at 06:22:24PM -0700 X-Tom-Swifty: "23% " replied Tom promptly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980806, Todd Larason wrote: > > I'll look into that. Circulate should probably do something more > > reasonable with windows that are mostly not on the current screen anyway > > (even 5% of a window probably shouldn't count). > > I'm looking further into this now. > diff -u -r1.10 wininfo.scm --- wininfo.scm 1998/08/06 03:15:29 1.10 +++ wininfo.scm 1998/08/07 01:49:25 @@ -53,7 +53,8 @@ (window-position w) (window-size w) (list 0 0) - (display-size))))) + (list (- (car (display-size)) 1) + (- (cadr (display-size)) 1)))))) (define*-public (visible? #&optional (w (get-window))) (if w (and (on-current-desk? w) This fixes the bug; the 5% idea is a good one...I'll see if I can remember enough scheme to figure out how to do it. From owner-scwm-discuss@mit.edu Thu Aug 6 22:16:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA05946 for scwm-discuss-outgoing; Thu, 6 Aug 1998 22:16:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA05941 for ; Thu, 6 Aug 1998 22:15:56 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23177; Thu, 6 Aug 98 22:15:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA24699; Thu, 6 Aug 1998 19:15:24 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> From: Greg Badros Date: 06 Aug 1998 19:15:23 -0700 In-Reply-To: Todd Larason's message of "Thu, 6 Aug 1998 18:22:24 -0700" Message-Id: Lines: 77 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980806, Greg Badros wrote: > > In my June 30th snapshot, apropos-internal is defined in ice-9/session.scm. > > ah ha. I added (ice-9 session) to the use-modules form; I don't know > if this should be added to the samples or not, but it was far from > obvious to me. I hope I didn't miss some obvious documentation. > > All the scwm-documentation stuff works now, and is VERY cool. Yea-- Sam did a great job integrating w/ Emacs. Perhaps this has changed more recently, but the boot-9.scm has a use-module of (ice-9 session) (though it's after a *fixme* comment...) > > Though it's far from ideal, I keep a (usually) recent copy of the html > > manual at: > > > > http://www.cs.washington.edu/research/constraints/cassowary/scwm-doc/ > > Thanks! > > > Weird. I just changed those lines because I get an off by one error in > > that windows don't butt up against the edge properly. I'll figure out > > what's really going wrong since my experiment failed. > > diff -u -r1.51 move.c > --- move.c 1998/08/06 03:24:32 1.51 > +++ move.c 1998/08/07 01:04:31 > @@ -206,16 +206,16 @@ > SnapCoordsToEdges(int *px, int *py, int width, int height, int bw, int resistance) > { > /* Resist moving windows over the edge of the screen! */ > - if (((*px + width) >= Scr.DisplayWidth) && > - ((*px + width) < Scr.DisplayWidth + resistance)) > - *px = Scr.DisplayWidth - width - bw*2; > + if (((*px + width + bw*2) >= Scr.DisplayWidth) && > + ((*px + width + bw*2) < Scr.DisplayWidth + resistance)) > + *px = Scr.DisplayWidth - width - bw*2 + 1; > if ((*px < 0) && (*px > -resistance)) > - *px = -bw; > - if (((*py + height) >= Scr.DisplayHeight) && > - ((*py + height) < Scr.DisplayHeight + resistance)) > - *py = Scr.DisplayHeight - height - bw*2; > + *px = 0; > + if (((*py + height + bw*2) >= Scr.DisplayHeight) && > + ((*py + height + bw*2) < Scr.DisplayHeight + resistance)) > + *py = Scr.DisplayHeight - height - bw*2 + 1; > if ((*py < 0) && (*py > -resistance)) > - *py = -bw; > + *py = 0; > } > > /* > > looks right to me, and seems to work. the +1s are because Width and Height > are 1 based, and coordinates are 0 based. Well, I just whipped out O'Reilly's X Vol 1 (Xlib) [never fear, it wasn't far -- I was just working on other stuff] and took a peek at p. 25. I think you're really close, but I'm not convinced about the +1's -- consider a window with width=1022, bw=1, at 0,0. This fits exactly on a screen with width 1024, but *px would get 1 instead of 0 with the above patch. I've gotta see what the bw stuff is all about-- I don't have a clear mental model of what the border is used for or what bw is supposed to hold. > > > I'll look into that. Circulate should probably do something more > > reasonable with windows that are mostly not on the current screen anyway > > (even 5% of a window probably shouldn't count). > > I'm looking further into this now. Great-- thanks! And thanks for your fix above-- it should prove very helpful. Greg From owner-scwm-discuss@mit.edu Thu Aug 6 22:20:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06070 for scwm-discuss-outgoing; Thu, 6 Aug 1998 22:20:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA06061 for ; Thu, 6 Aug 1998 22:20:21 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA17464; Thu, 6 Aug 98 22:20:36 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA24786; Thu, 6 Aug 1998 19:20:04 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Event rewrite proposal From: Greg Badros Date: 06 Aug 1998 19:20:04 -0700 Message-Id: Lines: 214 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's a copy of something I'm about to commit under doc/dev/events.gjb Feedback is appreciated! Greg Event Rewrite Proposal for Scwm Greg J. Badros, 6-Aug-1998 (Inspired by conversations w/ Maciej and his "events" proposal in this same directory) Intro: ------ Motivating desires for a more flexible event-binding infrastructure o Elimination of "contexts" and replacing with event maps -- event maps are more fundamental, and unifying o Mode-specific event maps (e.g., when in an interactive move) o Pinnable-menus event maps o Multi-key bindings with prefix keys that change mode map o Maps on a per window basis (e.g., xlogo could permit fewer modifier keys to accompany an "m" keystroke to signify a desire to move the window) o Quoting mechanism for turning off scwm's handling of events o Unifying X-events and user events As you write, event maps and event objects should be exposed to the scheme layer as SMOBs (first class objects). The event maps will contain event objects which are bound to procedures to be invoked. Event maps will be attached to X windows (via Xlib's SaveContext mechanism) and scheme window objects (for top-level, per-window events). Overview: --------- 1 - Event Objects 2 - Event Map Objects 3 - Binding of Event Maps 1 - Event objects: ------------------ (make-key-event KEY-SPECIFIER) e.g.: (make-key-event "F1") KEY-SPECIFIER can be a string where modifiers are prefixes, e.g., "C-S-M-Up" or can be a list of modifier symbols and a keysym string in any order, e.g. '(control shift meta "x") or '("x" control shift meta) The special pseudo-keysyms "KeyPress" and "KeyRelease" will permit events being bound to some combination of modifier keys just being depressed or released. We could also permit modifier symbols 'mod1, 'mod2, etc., to mean specifically that modifier mask bit (as opposed to the more flexible but less predictable symbolic names). (make-mouse-event MOUSE-SPECIFIER) e.g., (make-mouse-event '(1 release)) MOUSE-SPECIFIER is a list of two symbols [or a cons pair -- use '(1 . release) ?]. The car is a number for the button number, the cadr [or cdr] is one of 'motion, 'press, 'release, 'click, or 'double-click. ('click may be the same as 'release, but 'double-click gets manufactured by scwm). The button number 0 means any button. (make-x-event X-EVENT-SPECIFIER) e.g., (make-x-event 'enter-notify) X-EVENT-SPECIFIER is a symbol referring to an X11 event. enter-notify, leave-notify, pointer-motion, property-notify, colormap-notify, focus-in, focus-out, etc. could be supported (see include/X11/X.h for list). Binding procedures to these events could replace some of the ad-hoc mechanisms for property-notification, etc., that we currently have in scwm. Note that make-x-event is the most general case, and the other two procedures can be seen as adding a C-level filter on top of the actual X-event. E.g., (make-mouse-event '(1 release)) is applicable if there is a x-event "ButtonRelease" *and* the button number is 1. 2 - Event Map Objects: ---------------------- Now, on to event map objects. My proposal is similar to yours but instead of managing the installed event-map from Scheme code, I want to attach event map objects to arbitrary X11 windows (e.g., the pager, or a pinned menu, etc.), and have the appropriate grabs and XSelectInput calls happen based on the event map for a given window. First, a means of creating event-maps and populating them with bindings from events to procedures: (make-event-map #&optional PARENT MERGE?) ;; PARENT is an event-map object, or omitted or #f to indicate no parent (I don't think we need to worry about delaying events, but I'm not sure what problem that suggestion was trying to solve). This will permit a form of inheritance of behaviours. Note, though, that this mechanism should not be necessary for the geometry-based chaining that X11 commonly uses. E.g., an event in a window decoration (say, a button on the titlebar) will first dispatch based on the event map (if any) attached to the decoration, then on the event map for that client window, then on the global event map. Each of these event maps would be built with the PARENT argument omitted or #f. A special primitive or symbol can be bound to an event to permit preventing the event from propagating, and instead letting it pass to the application. MERGE? is #t to indicate that the resulting event-map should (for the purposes of event dispatch) treat the PARENT's bindings as equipotent to this new child event (i.e. all of the bindings will be checked when doing dispatch). MERGE? is #f to indicate that only if no binding matched in the child should the parent's bindings be checked. event-map-global ;; the built-in global event-map object -- it is an implicit, ;; non-merged parent of all event-maps (event-map-parents EVENT-MAP) ;; Return list of cons pairs (PARENT-EVENT-MAP . MERGE?) (add-event-map-parent! EVENT-MAP PARENT MERGE?) ;; Permit multiple parents, though only one can be specified at a time (add-event-binding EVENT-MAP EVENT PROC-OR-SYMBOL) (remove-event-binding EVENT-MAP EVENT) ;; Similar to your {add,remove}-event-hook. ;; These add and remove bindings for EVENT objects in the given ;; EVENT-MAP object. ;; PROC-OR-SYMBOL is either a procedure or 'pass to indicate ;; that the event should not be grabbed by the wm and the application ;; should get the event (this is only an issue for event maps attached ;; to client windows). See dispatch-event for details about how ;; the bindings are invoked. (list-event-bindings EVENT-MAP) ;; return a list of all the event bindings added to EVENT-MAP ;; as a cons parent of (EVENT-OBJECT . PROC-OR-SYMOBL) (dispatch-event EVENT-MAP EVENT) ;; EVENT-MAP is an event-map object, EVENT is an event-object ;; All applicable events' procedures should be invoked in the order that ;; they were added to the EVENT-MAP. Parent EVENT-MAPs are handled ;; as discussed above. ;; Each procedure is invoked with four arguments: ;; #1 - the scheme object that the event acted on/in (e.g., for a button ;; decoration, it will be that top-level frame; for a menu it will be ;; the menu object, etc.), or #f if there is no applicable scheme object ;; (e.g., the root window) ;; #2 - the event object that caused this dispatch (i.e. EVENT) ;; #3 - the event map object (i.e. EVENT-MAP) ;; #4 - the window id of the X window that got the event. We can add ;; primitives to query what decoration/menu/whatever a window ID is ;; We may need to do something to help simplify binding simple ;; procedures to an event (maybe something like Emacs's (interactive) ;; declaration), but I think we need all of the above (and maybe more) ;; to get a lot of useful functionality. ;; Only when no bindings are applicable in the child or its chain of ;; parents should the event dispatching mechanism ;; proceed to chain the event dispatch up to the enclosing event-map ;; context. That is, from decoration->frame->global (button decorations ;; perhaps should forward to the titlebar before the frame, but side-bar ;; decorations probably should not). ;; This primitive is what will get internally invoked when Scwm gets ;; an event. Note that Scwm will have to manage selecting the ;; appropriate events and grabbing the appropriate keys based on ;; the event-map objects attached to various windows. ;; Note that my proposed automatic chaining is a restriction (for ;; programming understanding and reasoning purposes) on a more general ;; notion of a procedure to be called when no event binding matches -- ;; the chaining could be made more explicit and put under programmer ;; control using this primitive. 3 - Binding of Event Maps: -------------------------- Event maps can be attached to any X Window by its X Id. We can add primitives that give the window id from a SCWM top-level window and a decoration specifier. (attach-event-map X-WINDOW-ID EVENT-MAP) e.g., (attach-event-map (button-n-of 1 win) button-1-map-for-win) (attach-event-map (title-bar-of win) title-bar-map-for-win) ;; Only one event map is attached per window id -- attaching ;; a new map removes any old one The window style mechanism should be used to attach a set of event maps at startup for a given window style, e.g.: (window-style "*" #:event-maps (list (1 . default-button-1-map) ('title . default-title-map) ('window . default-window-map))) [this avoids a bunch of attach-event-maps from being needed in the new-window-hook -- the attaching of the default event maps needs to be efficient, since it'll happen for each new window and on lots of decorations -- it's only a single XSaveContext call for each attachment, which shouldn't be too bad]. (event-map-for X-WINDOW-ID) ;; Return the currently attach event-map object, if any, or #f (remove-event-map X-WINDOW-ID) ;; detach any event map from X-WINDOW-ID I'll try to come up with an example of using this system but please feel free to poke holes in it or query me about how one might accomplish something you're interested in being able to do. (Or if you think it's redundant, overly-general, inefficient, etc.). Thanks! From owner-scwm-discuss@mit.edu Thu Aug 6 22:25:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06169 for scwm-discuss-outgoing; Thu, 6 Aug 1998 22:25:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA06166 for ; Thu, 6 Aug 1998 22:25:42 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA18085; Thu, 6 Aug 98 22:25:57 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA24829; Thu, 6 Aug 1998 19:25:23 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> From: Greg Badros Date: 06 Aug 1998 19:25:23 -0700 In-Reply-To: Todd Larason's message of "Thu, 6 Aug 1998 18:53:34 -0700" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980806, Todd Larason wrote: > > > I'll look into that. Circulate should probably do something more > > > reasonable with windows that are mostly not on the current screen anyway > > > (even 5% of a window probably shouldn't count). > > > > I'm looking further into this now. > > > diff -u -r1.10 wininfo.scm > --- wininfo.scm 1998/08/06 03:15:29 1.10 > +++ wininfo.scm 1998/08/07 01:49:25 > @@ -53,7 +53,8 @@ > (window-position w) > (window-size w) > (list 0 0) > - (display-size))))) > + (list (- (car (display-size)) 1) > + (- (cadr (display-size)) 1)))))) > > (define*-public (visible? #&optional (w (get-window))) > (if w (and (on-current-desk? w) > > This fixes the bug; Looks good to me -- I made the change and will commit. > the 5% idea is a good one...I'll see if I can > remember enough scheme to figure out how to do it. Let's call it the n% idea -- no magic numbers in scwm! :-) Thanks! Greg From owner-scwm-discuss@mit.edu Fri Aug 7 03:44:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA08531 for scwm-discuss-outgoing; Fri, 7 Aug 1998 03:44:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA08528 for ; Fri, 7 Aug 1998 03:44:27 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA19781; Fri, 7 Aug 98 03:44:05 EDT Received: (qmail 20328 invoked by uid 501); 7 Aug 1998 07:44:14 -0000 Message-Id: <19980807004414.A20202@molehill.org> Date: Fri, 7 Aug 1998 00:44:14 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Aug 06, 1998 at 07:25:23PM -0700 X-Tom-Swifty: "What I do best on a camping trip is sleep", said Tom intently. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980806, Greg Badros wrote: > Looks good to me -- I made the change and will commit. It's wrong. It fixes one off-by-one error with another one. This is completely untested, and I can't easily make diffs now (I'm on a different computer, redhat 4.0 based still, where I've never gotten scwm working well at all), but it should be something like: (define (rectangle-overlap? x1-1 y1-1 w1 h1 x2-1 y2-1 w2 h2) (let ((x1-2 (- (+ x1-1 w1) 1)) (y1-2 (- (+ y1-1 h1) 1)) (x2-2 (- (+ x2-1 w2) 1)) (y2-2 (- (+ y2-1 h2) 1)) (or (and (>= x1-1 x2-1) (<= x1-1 x2-2) (>= y1-1 y2-1) (<= y1-1 y2-2)) (and (>= x1-1 x2-1) (<= x1-1 x2-2) (>= y1-2 y2-1) (<= y1-2 y2-2)) (and (>= x1-2 x2-1) (<= x1-2 x2-2) (>= y1-1 y2-1) (<= y1-1 y2-2)) (and (>= x1-2 x2-1) (<= x1-2 x2-2) (>= y1-2 y2-1) (<= y1-2 y2-2))))) (the change is in the computation for the right/bottom boundaries) and in-viewport-any-desk? goes back to (define*-public (in-viewport-any-desk? #&optional (w (get-window))) (if w (apply rectangle-overlap? (append (window-position w) (window-size w) (list 0 0) (display-size))))) The edge-resistance thing is tying my brain in a knot; I went back to first principles and came up with something that LOOKS right...but experimentally leaves one pixel on the right and bottom. I'll look at it again tomorrow. There may well be other off-by-one errors from window-size and display-size. > > the 5% idea is a good one...I'll see if I can > > remember enough scheme to figure out how to do it. > > Let's call it the n% idea -- no magic numbers in scwm! :-) int intersection_area(int x1_1, int y1_1, int w1, int h1, int x2_1, int y2_1, int w2, int h2) { int x1_2 = x1_1 + w1 - 1; int y1_2 = y1_2 + h1 - 1; int x1, x2, y1, y2, h, w; if (x1_2 < x2_1 /* box 1 to the left of box 2 */ || x2_2 < x1_1 /* box 2 to the left of box 1 */ || y1_2 < y2_1 /* box 1 above box 2 */ || y2_2 < y1_1 /* box 2 above box 1 */) { return 0; } x1 = MAX(x1_1, x2_1); x2 = MIN(x1_2, x2_2); y1 = MAX(y1_1, y2_1); y2 = MIN(y1_2, y2_2); w = x2 - x1 + 1; h = y2 - y1 + 1; return w * h; } Obviously this doesn't need to be C, except that my Scheme skills are way too rusty. w% is something like: (define-public (window-% #&optional (w (get-window))) (if w (/ (apply intersection-area (append (window-position w) (window-size w) (list 0 0) (display-size))) (apply * (append (window-size w)))))) at least, I think that will return the right value. "something like" that, at least. From owner-scwm-discuss@mit.edu Fri Aug 7 04:02:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA08658 for scwm-discuss-outgoing; Fri, 7 Aug 1998 04:02:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA08655 for ; Fri, 7 Aug 1998 04:02:39 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA29794 for scwm-discuss@huis-clos.mit.edu; Fri, 7 Aug 1998 10:02:37 +0200 (CEST) Received: (qmail 939 invoked by uid 115); 6 Aug 1998 12:35:19 -0000 To: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Aug 1998 14:35:17 +0200 In-Reply-To: hjstein@bfr.co.il's message of "06 Aug 1998 12:47:59 +0300" Message-ID: Lines: 105 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 06 Aug 1998 12:47:59 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> Sascha Ziemann writes: >> Because of this, I would prefer >> >> {code-example '(button1 sidebar)} >> >> instead of >> >> '(button1 sidebar) >> >> The first has 15 chars overhead compared to the bottom, which has >> 29 chars overhead. It was a quite stupid idea of the IBM guy who >> invented SGML not to follow Knuth's usage of {} for generic >> markup. You can use shorttags (SGML and DocBook allow this). E.g. your example could be written as '(button1 sidebar) or even I must concur, but for different reasons. WRT comment Harvey> extraction & sgml markup we have the following possibilities: Harvey> 1. Write the comments in complete sgml, with all the stupid Harvey> tag/end tag pairs & all the stupid special character Harvey> escapes, or Harvey> 2. Write the comments in partial sgml, or Harvey> 3. Mark up the comments in some easily parsible, concise, Harvey> easy to remember generic way. Harvey> 4. Something I'm not thinking of. Harvey> If we follow option 1, then we can just extract the comments Harvey> for the SGML output, but we have to actually parse the SGML Harvey> comments to *remove* the SGML crap for something like the Harvey> procedure listings/plain text output. This is easily done with the equivalent of s/<[^>]*>// s/</ This'd make writing Harvey> documentation much more painful for the programmer. Nope. It just gives her the *possiblity* to put markup into her documentation. Nobody wants to force programmers to throw lots of tags into documentation. We'd probably want to keep the sgml markup to a minimum. Harvey> This is also hellish for the extractor, Don't think so - see above. Harvey> unless *everything* is output in various forms of SGML & then Harvey> run through Jade or some other parser to generate html as Harvey> well as plain text. This would be one possible way in the future. It's not available today. Harvey> If we follow 2, then we have to parse the partial SGML Harvey> comments so that we can do things like escape characters Harvey> properly & add additional markup for SGML output & remove Harvey> markup for procedure listings/plain text output. This is Harvey> marginally less painful for the programmer, but even worse Harvey> for the extractor, since we can't avoid parsing the comments Harvey> by just dumping them & running them through the SGML parser. This sounds like a bad compromise where nobody is satisfied. But I don't quite follow what you mean with partial sgml. Not allowing all tags? other constructs? Harvey> 3. Mark up the comments in some easily parsible, concise, Harvey> If we follow 3, then by definition it's easy for the Harvey> programmer & easy for the extractor. And, it's already being Harvey> done in that `xxx' denotes a cross-link. The only problem is Harvey> that we're creating a new markup language which we'll require Harvey> programmers to learn. I think using and solidifying existing style conventions (like writing an argument in all-caps) is a good idea. Still, I can't see the merit of inventing yet another markup style. "{foo bar}" is only marginally harder to parse than "bar" or one of the above shorthands. And it's not that comments should have every second word marked up. Perhaps we should ban all markup from comments for now, and evaluate the specific case if the need arises. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Aug 7 04:50:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA08909 for scwm-discuss-outgoing; Fri, 7 Aug 1998 04:50:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA08906 for ; Fri, 7 Aug 1998 04:50:56 -0400 Received: from lilly.ping.de by MIT.EDU with SMTP id AA23826; Fri, 7 Aug 98 04:50:40 EDT Received: (qmail 31762 invoked by uid 10); 7 Aug 1998 08:50:42 -0000 Received: from aibon.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc); 7 Aug 1998 08:50:42 -0000 Received: (qmail 3992 invoked by uid 1013); 7 Aug 1998 07:35:46 -0000 To: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Sascha Ziemann Date: 07 Aug 1998 09:35:46 +0200 In-Reply-To: Greg Badros's message of 06 Aug 1998 11:18:24 -0700 Message-Id: <7uhfzp5jn1.fsf@olivia.aibon.ping.de> Lines: 51 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: | You're exactly right about <, e.g., and we make that as easy as | possible. The one place where real markup is gonna hurt readability in | the code is tables, but it's worth it for nice formatted documentation, | IMHO. I read the code a lot less to learn about primitives now that I | can get at the documentation from with scwm-mode of Emacs. If you use a self made markup, you can define tables in the TeX way: {tabular ll a & b \\ c & d \\ } Or you can make it even simpler. Because program documentation is something that must be readable in a editor with a width of 80 or 100 columns. So you can ignore even the \\ and use something different for the &. Furthermore it is possible to force people to write a caption: {tabular ll "Example table" a | b ----- c | d } This would make the documentation readable and it would still be possible to create nice SGML for further transformations. Automatic generated documentations is something that must be bullet-proof. Texinfo still creates headlines at the bottom of a page. Looks quite miserable. If you restrict the features of the inline documentation, those problem would not occur. Also you can not give the writer of program documentation the whole freedom of a full SGML, if you do not want him to use it, because this will make inline documentation completely unreadable. With the whole freedom of SGML everybody can markup his code in a different way. This will lead to a documentation that looks different depending on the person who wrote the module. A special program reference documentation markup language would be much better. Perhaps it can be a bit more flexible than the Java stuff, but in general something like that. This would make it possible to use it also in other projects and also without Emacs and scwm.el. There are still some people who do not use Emacs. -- /* In the beginning was the Word: */ typedef long SCM; From owner-scwm-discuss@mit.edu Fri Aug 7 12:34:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA10861 for scwm-discuss-outgoing; Fri, 7 Aug 1998 12:34:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA10858 for ; Fri, 7 Aug 1998 12:34:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06730; Fri, 7 Aug 98 12:33:47 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA11322; Fri, 7 Aug 1998 09:33:43 -0700 (PDT) To: Sascha Ziemann Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> <7uhfzp5jn1.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 07 Aug 1998 09:33:43 -0700 In-Reply-To: Sascha Ziemann's message of "07 Aug 1998 09:35:46 +0200" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sascha Ziemann writes: > A special program reference documentation markup language would be > much better. Perhaps it can be a bit more flexible than the Java > stuff, but in general something like that. This would make it possible > to use it also in other projects and also without Emacs and > scwm.el. There are still some people who do not use Emacs. That's what DocBook is designed to be. I don't think reading sgml markup is that bad in C source comments, but if it is, it'd be easy to write a shell function that pulled up one of the various processed comment formats from the manual (e.g., With Emacs, we already have Sam's C-h C-s to get at the plain-text documentation -- other editors have some kind of extension hooks that make this stuff manageable, and if they don't you should switch editors). When there is a messy tabular embedded SGML-marked-up comment in the C source code, we just need a convenient way to get at that section of the manual. Not hard to do, just not done yet. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 13:57:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA11786 for scwm-discuss-outgoing; Fri, 7 Aug 1998 13:57:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA11780 for ; Fri, 7 Aug 1998 13:57:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA27871; Fri, 7 Aug 98 13:57:00 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA14168; Fri, 7 Aug 1998 10:56:58 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> From: Greg Badros Date: 07 Aug 1998 10:56:54 -0700 In-Reply-To: Todd Larason's message of "Fri, 7 Aug 1998 00:44:14 -0700" Message-Id: Lines: 16 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980806, Greg Badros wrote: > > Looks good to me -- I made the change and will commit. > > It's wrong. It fixes one off-by-one error with another one. Ah nuts. What do I know anyway! :-). I'll let Maciej deal with this since it's his code. IMO, a C primitive is a reasonable way to do the intersection-area. I can imagine it being an often-used function and it's a place where the C will really outperform the Scheme. Plus it's a pretty fundamental abstraction for a graphics system that is dealing with rectangles. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 16:23:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA14093 for scwm-discuss-outgoing; Fri, 7 Aug 1998 16:23:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA14090 for ; Fri, 7 Aug 1998 16:23:05 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA02214; Fri, 7 Aug 98 16:22:51 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16274; Fri, 7 Aug 1998 13:23:01 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Getting started with the constraint solving extension... From: Greg Badros Date: 07 Aug 1998 13:23:00 -0700 Message-Id: Lines: 64 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk For any of you interested in playing the the constraint-solving extension to SCWM, here are some brief instructions on getting started. First, you'll need my Cassowary constraint solving toolkit. It's available from: http://www.cs.washington.edu/research/constraints/cassowary/ I just put release 0.2 up there today. It's C++ code, and it builds using egcs-1.01 or newer, or gcc-2.8.1, and hopefully other C++ compilers that support the STL reasonably well. There's no fancy automake/autoconf stuff with Cassowary, so you'll have to edit the Makefile by hand. So far I've only tried building it on Linux (and Windows95), because those are the only platforms where I've had a C++ compiler recent enough to handle the code (I'll be building egcs-1.1 on a couple other platforms when it is released). After building Cassowary (in the c++/ subdirectory of the distribution), trying running "ClTests" if it seg faults, let me know -- there are definitely bugs in the Cassowary toolkit, but there are fewer and fewer each week. In the c++ directory, make an extra symlink to tell scwm which libcassowary to use: cd cassowary/c++ ln -s libcassowary.a libcassowary-scwm.a If ClTests runs successfully for you (the last test is a benchmark that takes a couple of minutes), then you should build the guile-wrapper in the guile/ subdirectory of Cassowary. There is also a cassowary_scm.sgml and cassowary_scm-procedures.txt for documentation (the latter integrates smoothly w/ scwm.el and scwm-procedures.txt -- just set your doc-files to point at both). Then you need to rebuild scwm w/ constraint-solver support. Do this using a recent dev snapshot by giving --with-cassowary=/path/to/cassowary/c++ as an argument to scwm's configure. Then do a clean build of scwm_cl, but use the makefile.cassowary (which includes the scwm-generated Makefile): cd scwm/scwm make -f makefile.cassowary scwm_cl All the normal scwm files will build with the C compiler, but the couple of .cc files must be built with the same C++ compiler as you used to build Cassowary, and the link step must be done by a C++ compiler, too. You may need to edit makefile.cassowary to specify the C++ compiler/linker. If all has gone well, you should be able to run the new binary "./scwm_cl" just as you would an ordinary scwm binary. Then try evaluating some of the S-expressions from scheme/tests/constraints.scm for a demonstration of some of what the solver and scwm can do together. Please let me know of successes and failures. Consider the constraint code alpha. My main wm now has the constraint solver embedded, but I only turn on the solver (using the scwm-set-master-solver primitive) on my testing X server. The behaviour of scwm_cl w/o ever using the constraint primitives should be nearly identical to scwm w/o constraints. Good luck. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 21:52:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17489 for scwm-discuss-outgoing; Fri, 7 Aug 1998 21:52:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA17486 for ; Fri, 7 Aug 1998 21:52:40 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA14506; Fri, 7 Aug 98 21:52:23 EDT Received: (qmail 28719 invoked by uid 501); 8 Aug 1998 01:52:33 -0000 Message-Id: <19980807185233.A28545@molehill.org> Date: Fri, 7 Aug 1998 18:52:33 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Aug 07, 1998 at 10:56:54AM -0700 X-Tom-Swifty: "X is an integer", Tom declared. Sender: owner-scwm-discuss@mit.edu Precedence: bulk The following refers to an attached patch; I wrote it before I tried to generate the patch. The anoncvs server seems to have a dead lock on it, and 'cvs diff' is refusing to run. On 980807, Greg Badros wrote: > Todd Larason writes: > > > On 980806, Greg Badros wrote: > > > Looks good to me -- I made the change and will commit. > > > > It's wrong. It fixes one off-by-one error with another one. > > Ah nuts. What do I know anyway! :-). I thought it was right too, when I sent it. > IMO, a C primitive > is a reasonable way to do the intersection-area. I can imagine it being > an often-used function and it's a place where the C will really > outperform the Scheme. The patch I'm including includes a scheme version; it seems fast enough for this at least. I've reimplemented rectangle-overlap? in terms of intersection-area; this fixes what looks like a bug to me; the old one would return #f for (rectangle-overlap? 0 0 100 100 10 10 5 5) but #t for (rectangle-overlap? 10 10 5 5 0 0 100 100). I've added a public function percent-visible, which can be used something like: (bind-key 'all "M-Tab" (lambda () (next-window #:only (lambda (w) (> (percent-visible w) 50)) #:except iconified? #:proc jtl-window-list-proc))) Right now, I'm not real happy with percentages less than 50; FocusOn() insists on moving the viewport to include the center of the newly-focussed window, and I don't want my circulate keys moving the viewport. Should another argument be added to control this, or is there any good reason to combine warp-view-to and focus in the first place? I've found and fixed the snap-to-edge problem too - in some cases the height and width being passed in included 2*bw already. The other bug I noticed, with xterms shortening themselves on scwm restart, also affects recapture. It's definately on the capturing side, not the loosing side, but I can't find anything suspicious. From owner-scwm-discuss@mit.edu Fri Aug 7 22:57:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA18081 for scwm-discuss-outgoing; Fri, 7 Aug 1998 22:57:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA18078 for ; Fri, 7 Aug 1998 22:57:35 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03312; Fri, 7 Aug 98 22:58:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA17536; Fri, 7 Aug 1998 19:57:31 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Important note about latest changes.... From: Greg Badros Date: 07 Aug 1998 19:57:30 -0700 Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk My latest commits do a couple things to help us track usage of scwm, and maintain better information about what version you are using. Most importantly, SCWM will now send a UDP packet out to a machine giving only your hostname and version number every time it starts up (just after running your startup-hooks, if any). This is an idea borrowed from GWM. It is EXCEPTIONALLY easy to turn this behaviour off if you so choose for any reason whatsoever. Just set the environment variable SCWM_DO_NOT_LOG_USAGE to anything, or add: (define scwm-do-not-log-usage #t) to execute anywhere in your .scwmrc. Obviously, I'm interested in getting a realistic count of users, but want to make it easy to maintain your privacy should you so choose. I scanned the GWM mailing list from years past to see if there was any discussion about this feature there, and there didn't appear to be any complaints, so I left the default as on. However, to each included *.scwmrc, I added the above define line set to #f, with a big comment saying to change it to #t if you want to avoid the packet being sent. The new file, scwm/log-usage.c is what actually sends the UDP packet, so you can see for yourself that it really is only the hostname and version number. That brings me to my 2nd point. There is a new primitive, (scwm-version-date) that returns the date of the last commit to the repository when you last did a CVS update. This is managed by having a magic "changed.c" file that gets updated on every commit to the repository. Thus, assumming you've made no local changes to your tree, the string that (scwm-version-date) returns uniquely and completely identifies the source code that scwm was built with (not counting built-sources such as include/config.h, of course). This should hopefully make bug tracking a bit more precise -- anon cvs complicated things by no longer making a date refer to a specific snapshot, since the tree changes throughout the day. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 23:16:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA18465 for scwm-discuss-outgoing; Fri, 7 Aug 1998 23:16:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA18462 for ; Fri, 7 Aug 1998 23:16:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04776; Fri, 7 Aug 98 23:17:16 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA17692; Fri, 7 Aug 1998 20:16:45 -0700 (PDT) To: scwm-discuss@mit.edu Subject: New Scwm web location... From: Greg Badros Date: 07 Aug 1998 20:16:45 -0700 Message-Id: Lines: 7 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej just moved the web page to: http://huis-clos.mit.edu/scwm/ Please be sure to update your links. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 23:41:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA18834 for scwm-discuss-outgoing; Fri, 7 Aug 1998 23:41:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA18831 for ; Fri, 7 Aug 1998 23:41:12 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22739; Fri, 7 Aug 98 23:40:55 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA17945; Fri, 7 Aug 1998 20:41:03 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> <19980807185233.A28545@molehill.org> From: Greg Badros Date: 07 Aug 1998 20:41:02 -0700 In-Reply-To: Todd Larason's message of "Fri, 7 Aug 1998 18:52:33 -0700" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > The following refers to an attached patch; I wrote it before I tried to > generate the patch. The anoncvs server seems to have a dead lock on it, > and 'cvs diff' is refusing to run. I assume it's working again now, as I just tried co of the anon repo and it worked for me. Thanks for the patches -- I'll look into them over the weekend. Greg From owner-scwm-discuss@mit.edu Fri Aug 7 23:57:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA18974 for scwm-discuss-outgoing; Fri, 7 Aug 1998 23:57:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA18971 for ; Fri, 7 Aug 1998 23:57:37 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA07651; Fri, 7 Aug 98 23:58:00 EDT Received: (qmail 29727 invoked by uid 501); 8 Aug 1998 03:57:28 -0000 Message-Id: <19980807205728.A29341@molehill.org> Date: Fri, 7 Aug 1998 20:57:28 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> <19980807185233.A28545@molehill.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=9jxsPFA5p3P2qPhR X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Aug 07, 1998 at 08:41:02PM -0700 X-Tom-Swifty: "Ive got to find out why my broker got fired", said Tom as he investigated. Sender: owner-scwm-discuss@mit.edu Precedence: bulk --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii On 980807, Greg Badros wrote: > I assume it's working again now, as I just tried co of the anon repo and > it worked for me. Okay, patch attached now. I reimplemented part of the SnapToEdge function to try to make it more obviously right. I think it's exactly equivalent to the earlier patch I sent for it though. I also renamed some arguments to MoveLoop make it more clear what they're useful for and what they're not. --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff ? diff Index: scheme/wininfo.scm =================================================================== RCS file: /anoncvs/scwm/scheme/wininfo.scm,v retrieving revision 1.10 diff -u -r1.10 wininfo.scm --- wininfo.scm 1998/08/06 03:15:29 1.10 +++ wininfo.scm 1998/08/08 03:44:46 @@ -37,15 +37,25 @@ (on-desk? (current-desk) w)) (define (rectangle-overlap? x1-1 y1-1 w1 h1 x2-1 y2-1 w2 h2) - (let ((x1-2 (+ x1-1 w1)) - (y1-2 (+ y1-1 h1)) - (x2-2 (+ x2-1 w2)) - (y2-2 (+ y2-1 h2))) - (or (and (>= x1-1 x2-1) (<= x1-1 x2-2) (>= y1-1 y2-1) (<= y1-1 y2-2)) - (and (>= x1-1 x2-1) (<= x1-1 x2-2) (>= y1-2 y2-1) (<= y1-2 y2-2)) - (and (>= x1-2 x2-1) (<= x1-2 x2-2) (>= y1-1 y2-1) (<= y1-1 y2-2)) - (and (>= x1-2 x2-1) (<= x1-2 x2-2) (>= y1-2 y2-1) (<= y1-2 y2-2))))) + (> (intersection-area x1-1 y1-1 w1 h1 x2-1 y2-1 w2 h2) 0)) +(define (intersection-area x1-1 y1-1 w1 h1 x2-1 y2-1 w2 h2) + (let ((x1-2 (- (+ x1-1 w1) 1)) + (y1-2 (- (+ y1-1 h1) 1)) + (x2-2 (- (+ x2-1 w2) 1)) + (y2-2 (- (+ y2-1 h2) 1))) + (if (or (< x1-2 x2-1) + (< x2-2 x1-1) + (< y1-2 y2-1) + (< y2-2 y1-1)) + 0 + (let ((x1 (max x1-1 x2-1)) + (x2 (min x1-2 x2-2)) + (y1 (max y1-1 y2-1)) + (y2 (min y1-2 y2-2))) + (let ((w (+ (- x2 x1) 1)) + (h (+ (- y2 y1) 1))) + (* w h)))))) (define*-public (in-viewport-any-desk? #&optional (w (get-window))) (if w (apply rectangle-overlap? @@ -59,6 +69,16 @@ (if w (and (on-current-desk? w) (in-viewport-any-desk? w)))) +(define*-public (percent-visible #&optional (w (get-window))) + (/ (* 100 + (apply intersection-area + (append + (window-position w) + (window-size w) + (list 0 0) + (display-size)))) + (apply * (window-size w)))) + (define*-public (window-geometry-string #&optional (w (get-window))) (if w (let ((i (iconified? w)) (pos (window-position w)) Index: scwm/move.c =================================================================== RCS file: /anoncvs/scwm/scwm/move.c,v retrieving revision 1.51 diff -u -r1.51 move.c --- move.c 1998/08/06 03:24:32 1.51 +++ move.c 1998/08/08 03:44:46 @@ -205,17 +205,36 @@ static void SnapCoordsToEdges(int *px, int *py, int width, int height, int bw, int resistance) { + int pixel_past_last, last_pixel, last_pixel_on_screen; + /* Resist moving windows over the edge of the screen! */ - if (((*px + width) >= Scr.DisplayWidth) && - ((*px + width) < Scr.DisplayWidth + resistance)) + pixel_past_last = *px + bw + width + bw; + last_pixel = pixel_past_last - 1; + last_pixel_on_screen = Scr.DisplayWidth - 1; + + /* *px + width + 2*bw > Scr.DisplayWidth */ + if (last_pixel > last_pixel_on_screen && + last_pixel < last_pixel_on_screen + resistance) { + /* last_pixel = last_pixel_on_screen */ + /* pixel_past_last - 1 = Scr.DisplayWidth - 1 */ + /* *px + bw + width + bw = Scr.DisplayWidth; */ *px = Scr.DisplayWidth - width - bw*2; + } + if ((*px < 0) && (*px > -resistance)) - *px = -bw; - if (((*py + height) >= Scr.DisplayHeight) && - ((*py + height) < Scr.DisplayHeight + resistance)) + *px = 0; + + pixel_past_last = *py + bw + height + bw; + last_pixel = pixel_past_last - 1; + last_pixel_on_screen = Scr.DisplayHeight - 1; + + if (last_pixel > last_pixel_on_screen && + last_pixel < last_pixel_on_screen + resistance) { *py = Scr.DisplayHeight - height - bw*2; + } + if ((*py < 0) && (*py > -resistance)) - *py = -bw; + *py = 0; } /* @@ -236,8 +255,8 @@ */ void -moveLoop(ScwmWindow * psw, int XOffset, int YOffset, int Width, - int Height, int *FinalX, int *FinalY, Bool opaque_move) +moveLoop(ScwmWindow * psw, int XOffset, int YOffset, int OutlineWidth, + int OutlineHeight, int *FinalX, int *FinalY, Bool opaque_move) { Bool finished = False; Bool done; @@ -252,7 +271,7 @@ if (!opaque_move) { - RedrawOutlineAtNewPosition(Scr.Root, xl, yt, Width, Height); + RedrawOutlineAtNewPosition(Scr.Root, xl, yt, OutlineWidth, OutlineHeight); } DisplayPosition(psw, xl + Scr.Vx, yt + Scr.Vy, True); @@ -286,7 +305,8 @@ if (XLookupKeysym(&(Event.xkey), 0) == XK_Escape) { finished = True; } - SnapCoordsToEdges(&xl, &yt, Width, Height, psw->bw, Scr.MoveResistance); + SnapCoordsToEdges(&xl, &yt, psw->frame_width, psw->frame_height, + psw->bw, Scr.MoveResistance); done = True; break; case ButtonPress: @@ -316,7 +336,8 @@ yt += YOffset; /* Resist moving windows over the edge of the screen! */ - SnapCoordsToEdges(&xl, &yt, Width, Height, psw->bw, Scr.MoveResistance); + SnapCoordsToEdges(&xl, &yt, psw->frame_width, psw->frame_height, + psw->bw, Scr.MoveResistance); /* check Paging request once and only once after outline redrawn */ /* redraw after paging if needed - mab */ @@ -335,7 +356,7 @@ yt + psw->icon_p_height); } else { RedrawOutlineAtNewPosition(Scr.Root, psw->icon_x_loc, psw->icon_y_loc, - Width, Height); + OutlineWidth, OutlineHeight); } } else { /* the solver's resolve does the move window */ @@ -382,7 +403,8 @@ if (!opaque_move) RemoveRubberbandOutline(Scr.Root); - SnapCoordsToEdges(&xl, &yt, Width, Height, psw->bw, Scr.MoveResistance); + SnapCoordsToEdges(&xl, &yt, psw->frame_width, psw->frame_height, + psw->bw, Scr.MoveResistance); if (!psw->fIconified) { SuggestMoveWindowTo(psw,xl,yt,True); CassowaryEndEdit(psw); --9jxsPFA5p3P2qPhR-- From owner-scwm-discuss@mit.edu Sat Aug 8 02:19:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA19778 for scwm-discuss-outgoing; Sat, 8 Aug 1998 02:19:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA19775 for ; Sat, 8 Aug 1998 02:19:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA21671; Sat, 8 Aug 98 02:19:44 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id XAA18075; Fri, 7 Aug 1998 23:19:12 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Even easier to turn off... From: Greg Badros Date: 07 Aug 1998 23:19:12 -0700 Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Upon further reflection, I decided to make it even easier to not bother with sending a udp packet to let me know you're using scwm... You must now explicitly ask for the packet to get set. I.e., the default is for Scwm to not send anything from your machine unless you ask it to. Each of the distributed .scwmrcs contains a comment at the top: ;; Uncomment the below to send a single UDP packet to ;; the scwm usage counter machine at startup ;; The single packet just contains the hostname and version number ;; To disable, set environment variable SCWM_DO_NOT_LOG_USAGE ;;(define thank-scwm-authors-with-usage-note #t) ^^ remove the semicolons to uncomment the last comment line if you don't mind having the UDP packet sent so I can get a rough lower bound of the number of users of Scwm. Note that, as the comment states, if the environment variable SCWM_DO_NOT_LOG_USAGE is set (probably in your .xsession), then no thank-you packet will be sent even if thank-scwm-authors-with-usage-note is #t. (The environment variable overrides the scheme variable, but only in the turning-off direction -- there is no way to turn on sending the packet using an environment variable). Greg From owner-scwm-discuss@mit.edu Sat Aug 8 04:21:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA20968 for scwm-discuss-outgoing; Sat, 8 Aug 1998 04:21:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA20949 for ; Sat, 8 Aug 1998 04:21:22 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA17994 for scwm-discuss@huis-clos.mit.edu; Sat, 8 Aug 1998 10:21:16 +0200 (CEST) Received: (qmail 4446 invoked by uid 115); 7 Aug 1998 17:18:59 -0000 To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808062011.QAA09439@jekyll.piermont.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Aug 1998 19:18:56 +0200 In-Reply-To: "Perry E. Metzger"'s message of "Thu, 06 Aug 1998 16:11:25 -0400" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 06 Aug 1998 16:11:25 -0400 >>>>> "Perry E. Metzger" said: Perry> Sure enough, but on the other hand, I don't know of a widely Perry> used window manager right now that doesn't let you do things Perry> like this. Perry> fvwm does, as do most others. it isn't something we should Perry> reasonably prohibit if we want to be able to emulate the Perry> behavior of other window managers. There must be a misunderstanding here. We don't want to take something away from the user. We want to give him the *possibility* to have key combinations used by the wm not intercepted in certain situations. Example: If you normally switch desks with C-PageDown, but some app you just try out can scroll 10 pages at once with C-PageDown. The painful way (but of course the better one in the long run) would be to change either the wm or the app to use another key-combo. I propose that scwm should provide anther way: You press (for example) C-M-q C-PageDown. C-M-q maps to a scwm command that inhibits processing of the next key combination, so C-PageDown gets through to your application. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 8 04:21:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA20966 for scwm-discuss-outgoing; Sat, 8 Aug 1998 04:21:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA20951 for ; Sat, 8 Aug 1998 04:21:23 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA17997 for scwm-discuss@huis-clos.mit.edu; Sat, 8 Aug 1998 10:21:17 +0200 (CEST) Received: (qmail 4564 invoked by uid 115); 7 Aug 1998 17:33:12 -0000 To: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Aug 1998 19:33:07 +0200 In-Reply-To: Greg Badros's message of "06 Aug 1998 19:15:23 -0700" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 06 Aug 1998 19:15:23 -0700 >>>>> Greg Badros said: Greg> Yea-- Sam did a great job integrating w/ Emacs. Indeed. Greg> Perhaps this has changed more recently, but the boot-9.scm has Greg> a use-module of (ice-9 session) (though it's after a *fixme* Greg> comment...) Issuing a "(use-modules ((ice-9 session)))" from scwm.el couldn't hurt. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 8 04:21:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA20969 for scwm-discuss-outgoing; Sat, 8 Aug 1998 04:21:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA20948 for ; Sat, 8 Aug 1998 04:21:21 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA17991 for scwm-discuss@huis-clos.mit.edu; Sat, 8 Aug 1998 10:21:15 +0200 (CEST) Received: (qmail 4426 invoked by uid 115); 7 Aug 1998 17:05:38 -0000 To: scwm-discuss@mit.edu Subject: Re: ICCCM compliance References: <199808061337.JAA05924@jekyll.piermont.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Aug 1998 19:05:34 +0200 In-Reply-To: "Perry E. Metzger"'s message of "Thu, 06 Aug 1998 09:37:47 -0400" Message-ID: Lines: 33 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 06 Aug 1998 09:37:47 -0400 >>>>> "Perry E. Metzger" said: ICCCM> In other words, window managers must provide some mechanism by ICCCM> which a client can receive events from every key and button ICCCM> (regardless of modifiers) unless [...] Perry> I don't think this is particularly important, since no one Perry> seems to be following it (or at least, no one has in a long Perry> while). Well it could sometimes be nice. And I think it's not too hard to implement. BTW, being the only (?) wm sporting ICCCM-compliance is not such a bad thing. Perry> Besides, being able to hit c-arrow and have my virtual Perry> screens shift is too bloody convenient. :) It's not so convenient if you're fond of playing iD games . I have `super' as my "wm-modifier", belonging solely to scwm. It's good to have a space-cadet-keyboard. To think that some people on the gnus list argumented to rip M-tab out of Emacs just because a couple of default wm configurations use it (for you-know-what). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 8 04:21:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA20970 for scwm-discuss-outgoing; Sat, 8 Aug 1998 04:21:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA20961 for ; Sat, 8 Aug 1998 04:21:26 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA18003 for scwm-discuss@huis-clos.mit.edu; Sat, 8 Aug 1998 10:21:19 +0200 (CEST) Received: (qmail 4612 invoked by uid 115); 7 Aug 1998 17:52:15 -0000 To: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Aug 1998 19:52:13 +0200 In-Reply-To: hjstein@bfr.co.il's message of "06 Aug 1998 15:16:47 +0300" Message-ID: Lines: 28 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> On 06 Aug 1998 15:16:47 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> I'll have to ask the guile list about opening pipes in guile. Harvey> (open-pipe "cmd" mode) will only open 1 way pipes - guile Harvey> can't both read & write them. Try something like this (untested, of course ): (let ((to-child (pipe)) (from-child (pipe))) (if (zero? (primitive-fork)) (begin ; child (dup->fdes (car to-child) 0) ; connect pipes to stdin/out/err (dup->fdes (cdr from-child) 1) (dup->fdes (cdr from-child) 2) (execlp "ispell" args)) (let ((input (car from-child)) ; parent (output (cdr to-child))) ; read/write/whatever ))) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 8 04:21:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA20967 for scwm-discuss-outgoing; Sat, 8 Aug 1998 04:21:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA20956 for ; Sat, 8 Aug 1998 04:21:24 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA18000 for scwm-discuss@huis-clos.mit.edu; Sat, 8 Aug 1998 10:21:18 +0200 (CEST) Received: (qmail 4580 invoked by uid 115); 7 Aug 1998 17:38:05 -0000 To: scwm-discuss@mit.edu Subject: Re: Great flexibility References: <199808061820.OAA00963@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Aug 1998 19:38:03 +0200 In-Reply-To: Maciej Stachowiak's message of "Thu, 06 Aug 1998 14:20:27 EDT" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 06 Aug 1998 14:20:27 EDT >>>>> Maciej Stachowiak said: Maciej> I am not sure if I have explicitly put this in the docs, but Maciej> I consider sample.scwmrc for instance to be public domain. Still, that does not make it public domain, since you're not the author of all scwmrc's there. I will put an appropriate statement into mine. Maciej> However, if something is going to go into one of the shipped Maciej> Scheme modules or something, I think the authors permission Maciej> to distribute it under GPL would be a good thing. Yes. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 8 08:08:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA21937 for scwm-discuss-outgoing; Sat, 8 Aug 1998 08:08:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA21934 for ; Sat, 8 Aug 1998 08:08:04 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24208; Sat, 8 Aug 98 08:07:42 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA08507; Sat, 8 Aug 1998 15:07:39 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 15:07:39 +0300 In-Reply-To: Robert Bihlmeyer's message of "07 Aug 1998 19:52:13 +0200" Message-Id: Lines: 99 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> On 06 Aug 1998 15:16:47 +0300 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> I'll have to ask the guile list about opening pipes in guile. > Harvey> (open-pipe "cmd" mode) will only open 1 way pipes - guile > Harvey> can't both read & write them. > > Try something like this (untested, of course ): > > (let ((to-child (pipe)) > (from-child (pipe))) > (if (zero? (primitive-fork)) > (begin ; child > (dup->fdes (car to-child) 0) ; connect pipes to stdin/out/err > (dup->fdes (cdr from-child) 1) > (dup->fdes (cdr from-child) 2) > (execlp "ispell" args)) > (let ((input (car from-child)) ; parent > (output (cdr to-child))) > ; read/write/whatever > ))) > It looks like I'll have to do some sort of fork crap. I did some funky stuff to spawn an ispell that I can both write to & read from, but I've been getting hangs when running on scwm/*.c. Here's the code, in case anyone wants to take a look at it. ;;; ispell crap (define (ispell-start) (system "rm ispell-input") (system "mkfifo ispell-input") (let ((ispell-out (open-input-pipe "ispell -a string (let loop ((s (cddr (string->list s)))) (cond ((null? s) '()) ((char=? (car s) #\space) '()) (else (cons (car s) (loop (cdr s)))))))) (define (ispell-stop ports) (close-port (car ports)) (close-pipe (cdr ports)) (system "rm ispell-input")) (define (ispell-text docs) (let ((p '())) (dynamic-wind (lambda () (set! p (ispell-start))) (lambda () (for-each (lambda (rec) (ispell-complain rec p)) docs)) (lambda () (ispell-stop p))))) (define (ispell-complain rec p) (for-each (lambda (complaint) (complain (docitem:file rec) (docitem:line rec) complaint)) (apply append (map (lambda (line) (ispell-report (ispell-send line p))) (docitem->plaintextlist rec))))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 08:36:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA22104 for scwm-discuss-outgoing; Sat, 8 Aug 1998 08:36:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA22101 for ; Sat, 8 Aug 1998 08:36:31 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25346; Sat, 8 Aug 98 08:36:10 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA08622; Sat, 8 Aug 1998 15:36:17 +0300 Date: Sat, 8 Aug 1998 15:36:17 +0300 Message-Id: <199808081236.PAA08622@blinky.bfr.co.il> From: "Harvey J. Stein" To: guile@cygnus.com Subject: Serious eq? bug? Cc: hjstein@bfr.co.il, scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Consider the following: hjstein@bacall:~$ guile guile> (eq? (string->symbol "-a") '-a) #t guile> (eq? (string->symbol "-b") '-b) #t guile> (eq? (string->symbol "-i") '-i) #f Is this expected behavior for an R4RS scheme which supports complex number? If so, it's a real pain in the ass for command line processing... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 09:08:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA22287 for scwm-discuss-outgoing; Sat, 8 Aug 1998 09:08:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA22284 for ; Sat, 8 Aug 1998 09:08:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26887; Sat, 8 Aug 98 09:08:18 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA08737; Sat, 8 Aug 1998 16:05:17 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: New (almost usable) extract.scm From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 16:05:17 +0300 In-Reply-To: Greg Badros's message of "06 Aug 1998 17:23:36 -0700" Message-Id: Lines: 973 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's an extract.scm that's mostly usable: (with ugly hacks for ispell). hjstein@bacall:~/remote-cvs-pkgs/scwm$ ~/extract.scm Usage: extract.scm [options] file1.c file2.c ... Extracts documentation from specified C source code files. Documentation must be embedded according to SCWM conventions: - Functions declared with the SCWM_PROC macro will be documented. They can be immediately followed by comments of the form /** ... */, which will be assumed to document the preceeding SCWM_PROC. Each SCWM_PROC should be followed by a FUNC_NAME define which matches the C function name given by the SCWM_PROC. - Comments of the form /** chapter_name : section_name ... */ will also be extracted. Options: -c, --check Check documentation for reasonableness. -s file, --sgml file Generate SGML and output to specified file. -p file, --proc file Generate procedure listing and output to specified file. -t file, --text file Generate plain text output to specified file. -a, --annotated-text Output plain text with each line prefixed by file:line_number:. -l, --ispell Run ispell on documentation. Currently hangs when given full SCWM source code set. -h, -? --help Display this info. If no flags are given, the default action is to check the files. hjstein@bacall:~/remote-cvs-pkgs/scwm$ ~/extract.scm scwm/*.c scwm/menu.c:196: Scheme name make-menu redefined. First defined in scwm/scwmmenu.c on line 195. scwm/menu.c:170: Scheme name menu-properties redefined. First defined in scwm/scwmmenu.c on line 169. scwm/menu.c:112: Scheme name menu? redefined. First defined in scwm/scwmmenu.c on line 111. scwm/menu.c:1232: Scheme name popup-menu redefined. First defined in scwm/scwmmenu.c on line 1235. hjstein@bacall:~/remote-cvs-pkgs/scwm$ ~/extract.scm --ispell scwm/*.c scwm/add_window.c:782: Misspelling : app. scwm/add_window.c:782: Misspelling : scwm. scwm/add_window.c:795: Misspelling : viewport. scwm/add_window.c:795: Misspelling : app. scwm/add_window.c:795: Misspelling : scwm. scwm/binding.c:78: Misspelling : Alt. scwm/binding.c:589: Misspelling : sidebar. scwm/binding.c:621: Misspelling : sidebar. scwm/binding.c:648: Misspelling : PROC. scwm/binding.c:648: Misspelling : sidebar. scwm/binding.c:648: Misspelling : PROC. scwm/binding.c:707: Misspelling : PROC. scwm/binding.c:707: Misspelling : sidebar. scwm/binding.c:707: Misspelling : PROC. scwm/binding.c:846: Misspelling : Alt. scwm/binding.c:846: Misspelling : Alt. scwm/callbacks.c:243: Misspelling : FNAME. scwm/callbacks.c:295: Misspelling : scwm. scwm/callbacks.c:295: Misspelling : callbacks. ... Still missing is appropriate treatment of the mixture of SGML tags & special escapes (e.g. - `xref') combined with the lack of escaping special characters in the comments. Currently all comments are SGML escaped & `xref' isn't processed. Also, you might have to change /usr/lib (if slib doesn't live there). Will have to be part of configure. ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** spaces identifier: & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; Parsing: ;;; (extract-docs-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; ;;; Checking docs are well formed: ;;; (check-docs doclist) ;;; Verifies stuff such as number of args = args ;;; in argslist, all args are SCM types, each arg is mentioned in ;;; the documentation, etc. ;;; ;;; Generating procedures-list documentation: ;;; (docs->proclist doclist) ;;; Output procedures-list stuff ;;; ;;; Generating sgml output: ;;; (docs->sgml doclist) ;;; Does various passes on the extract-docs-from-files output to ;;; generate the sgml output. ;;; ;;; Note: ;;; 1. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things (if I'm doing this). ;;; 2. Too much hacking has lead to a need for some code cleanup. ;;; 3. Still can't load slib stuff without stupid hacks that should ;;; have been dealt with when guile installed. (if (not (member "/usr/lib" %load-path)) (set! %load-path (cons "/usr/lib" %load-path))) ; HACK for guile to find slib!!!!!!! (use-modules (ice-9 regex) ; For regexp-quote & substitute. (ice-9 slib)) ; For sort. (require 'sort) (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*([^ \t:*]*:.*)")) ; spaces /**[^space or *] (define post-proc-doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]+(.*)")) ; spaces /** space+ (define func-name-match (make-regexp "^[ \t]*#[ \t]*define[ \t]+FUNC_NAME[ \t]+([^ \t]*)[ \t]*$")) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:required-args procrec) (list-ref procrec 2)) (define (proc:optional-args procrec) (list-ref procrec 3)) (define (proc:extra-var-args procrec) (list-ref procrec 4)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (procdoc:funcname procdocrec) (list-ref procdocrec 2)) (define (docitem:type rec) (list-ref rec 0)) (define (docitem:data rec) (list-ref rec 1)) (define (docitem:file rec) (list-ref rec 2)) (define (vdocitem:decl rec) (procdoc:decl (docitem:data rec))) (define (vdocitem:scheme-name rec) (proc:scheme-name (vdocitem:decl rec))) (define (vdocitem:c-name rec) (proc:c-name (vdocitem:decl rec))) (define (docitem:line rec) (list-ref rec 3)) (define (doc:chapter rec) (list-ref rec 0)) (define (doc:section rec) (list-ref rec 1)) (define (doc:doc rec) (list-ref rec 2)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document. (define (docs->proclist l) (for-each proc->list (sort (select-type 'SCWM_PROC l) scheme-name-ci=2 identical scheme names. (let loop ((spl (group (sort (select-type 'SCWM_PROC docitemlist) scheme-name=2 identical proc names - compiler will catch it. ) ;;; Complains about docitem recs it doesn't like (define (check-docitem procdocrec) (let* ((data (docitem:data procdocrec)) (file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (case (docitem:type procdocrec) ((DOC) ;; Check that DOC has a nonempty chapter name. (if (not (doc:chapter data)) (complain file line "Untagged embedded documentation")) ;; Check that DOC has a nonempty section name. (if (string=? "" (doc:section data)) (complain file line "Empty section heading")) ;; Check that DOC doc has nonempty documentation. (if (null? (doc:doc data)) (complain file line "Empty documentation"))) ;; Check that DOC doc identifier is HOOK or CONCEPT? ((SCWM_PROC) (let ((procrec (procdoc:decl data)) (docrec (procdoc:doc data)) (funcname (procdoc:funcname data))) ;; Check c-name vs scheme-name. (if (and (not (string=? (c-ident->scheme-ident (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec))) (not (string=? (c-name->scheme-name (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec)))) (complain file line "Scheme name of " (proc:scheme-name procrec) " doesn't match a C name of " (proc:c-name procrec))) ;; Warn about upper case words != arg names? ;; What's this business about the 1st doc line being a "purpose" sentence? ;; What's this business about "leading spaces" being omitted? ;; Check that arg 2+3+4 = length of arg5 (if (not (= (+ (proc:required-args procrec) (proc:optional-args procrec) (proc:extra-var-args procrec)) (length (proc:args procrec)))) (complain file line "Argument count mismatch in " (proc:scheme-name procrec))) ;; Warn about var param != 0 or 1. (if (and (not (= (proc:extra-var-args procrec) 0)) (not (= (proc:extra-var-args procrec) 1))) (complain file line "Var count is not 0 and is not 1")) ;; Check that all args are of type SCM (let loop ((i 1) (args (proc:args procrec))) (cond ((null? args)) ((eq? (caar args) 'SCM) (loop (1+ i) (cdr args))) (else (complain file line "In the declaration for " (proc:scheme-name procrec) ", argument " i " (" (cadar args) ") is not of type SCM")))) ;; Check that the proc is documented: (if (null? docrec) (complain file line "Procedure " (proc:scheme-name procrec) " is not documented")) ;; Check that each arg appears in description: (let next-arg ((argregexp (map (lambda (arg) (delimited-case-insensitive-regexp (c-name->scheme-name (symbol->string (cadr arg))))) (proc:args procrec))) (args (map cadr (proc:args procrec))) (i 1)) (cond ((null? args)) (else (let next-docline ((doc docrec)) (cond ((null? doc) (complain file line "Argument " i " (" (car args) ") of " (proc:scheme-name procrec) " is undocumented")) ((regexp-exec (car argregexp) (car doc))) (else (next-docline (cdr doc))))) (next-arg (cdr argregexp) (cdr args) (+ i 1))))) ;; Check that there's a func_name & it matches the c-name (if funcname (if (not (string=? (string-append "s_" (symbol->string (proc:c-name procrec))) funcname)) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a matching FUNC_NAME")) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a FUNC_NAME")))) (else (complain file line "Internal error - unrecognized doc record type."))))) (define (c-ident->scheme-ident s) (define to-regexp (make-regexp "_to_")) (define (to->-> s) (let ((match (regexp-exec to-regexp s))) (if match (regexp-substitute #f match 'pre "->" 'post) s))) (c-name->scheme-name (to->-> s))) (define (c-name->scheme-name s) (let* ((normname (map (lambda (c) (if (char=? c #\_) #\- c)) (string->list s))) (revname (reverse normname))) (cond ((or (null? revname) (null? (cdr revname))) (list->string normname)) ((and (char=? (car revname) #\p) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\? (cddr revname))))) ((and (char=? (car revname) #\x) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\! (cddr revname))))) (else (list->string normname))))) (define (delimited-case-insensitive-regexp s) (let ((ci-name (regexp-quote s))) (make-regexp (string-append "[ \t]" ci-name "[ \t.,]|" "^" ci-name "[ \t.,]|" "[ \t]" ci-name "$|" "^" ci-name "$") regexp/icase))) ;;; ispell crap (define (ispell-start) (system "rm ispell-input") (system "mkfifo ispell-input") (let ((ispell-out (open-input-pipe "ispell -a string (let loop ((s (cddr (string->list s)))) (cond ((null? s) '()) ((char=? (car s) #\space) '()) (else (cons (car s) (loop (cdr s)))))))) (define (ispell-stop ports) (close-port (car ports)) (close-pipe (cdr ports)) (system "rm ispell-input")) (define (ispell-text docs) (let ((p '())) (dynamic-wind (lambda () (set! p (ispell-start))) (lambda () (for-each (lambda (rec) (ispell-complain rec p)) docs)) (lambda () (ispell-stop p))))) (define (ispell-complain rec p) (for-each (lambda (complaint) (complain (docitem:file rec) (docitem:line rec) complaint)) (apply append (map (lambda (line) (ispell-report (ispell-send line p))) (docitem->plaintextlist rec))))) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (proc->list procdocrec) (if (eq? 'SCWM_PROC (docitem:type procdocrec)) (let ((procrec (procdoc:decl (docitem:data procdocrec))) (docrec (procdoc:doc (docitem:data procdocrec)))) (display (function-call-decl procrec)) (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (display "[From ") (display (docitem:file procdocrec)) (display ":") (display (docitem:line procdocrec)) (display "]") (newline) (newline) (display #\014) (newline)))) (define (function-call-decl procrec) (apply string-append "(" (proc:scheme-name procrec) (let loop ((args (map (lambda (a) (c-name->scheme-name (symbol->string (cadr a)))) (proc:args procrec))) (req (proc:required-args procrec)) (opt (proc:optional-args procrec)) (rest (proc:extra-var-args procrec))) (cond ((null? args) '(")")) ((> req 0) (cons " " (cons (car args) (loop (cdr args) (- req 1) opt rest)))) ((and (= req 0) (> opt 0)) (cons " #&optional" (loop args (- req 1) opt rest))) ((and (< req 0) (> opt 0)) (cons " " (cons (car args) (loop (cdr args) req (- opt 1) rest)))) ;; Now know req <= 0 & opt <= 0. ((> rest 0) (cons " . " (cons (car args) (loop (cdr args) req opt 0)))) (else (cons " " (cons (car args) (loop (cdr args) -1 0 0)))))))) ;;; Output doc record in format suitable for ispell: (define (docitem->plaintext procdocrec) (let* ((file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (for-each (lambda (d) (complain file line d)) procdocrec))) (define (docitem->plaintextlist procdocrec) (case (docitem:type procdocrec) ((SCWM_PROC) (procdoc:doc (docitem:data procdocrec))) ((DOC) (doc:doc (docitem:data procdocrec))) (else (complain (procdoc:file procdocrec) (procdoc:line procdorec) "Internal error - unrecognized doc record type.") '()))) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (extract-docs-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (extract-docs-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (extract-docs-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (cond (doc (loop (counting-read-line p) (cons (list 'SCWM_PROC doc filename linenum) defs))) (else (complain filename linenum "SCWM_PROC not parsable") (loop (counting-read-line p) defs))))) (docstart (let ((doc (parse-doc (extract-doc p line)))) (loop (counting-read-line p) (cons (list 'DOC doc filename linenum) defs)))) (else (loop (counting-read-line p) defs)))))))) (define (next-non-whitespace-line p) (define whitespace-line (make-regexp "^[ \t]*$")) (let ((line (counting-read-line p))) (if (or (eof-object? line) (regexp-exec whitespace-line line)) (next-non-whitespace-line p) line))) (define (extract-proc-n-doc line p) (let* ((proc (parse-proc (match-parentheses line p))) (next (counting-read-line p))) (cond ((not proc) ; Proc not parsable #f) ((eof-object? next) ; No doc & no func (list proc '() #f)) ((regexp-exec post-proc-doc-start-match next) ; Doc is first. (let* ((doc (extract-doc p next post-proc-doc-start-match)) (next (next-non-whitespace-line p)) (match (if next (regexp-exec func-name-match next) #f))) (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f)))) (else (let* ((match (regexp-exec func-name-match next)) ; Func name must be next. (next (next-non-whitespace-line p)) (doc (extract-doc p next post-proc-doc-start-match))) ; Then the docs. (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f))))))) (define (extract-doc p . xargs) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? xargs) (counting-read-line p) (car xargs))) (doc-start-match (if (or (null? xargs) (null? (cdr xargs))) doc-start-match (cadr xargs)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-doc doclist) (define parser (make-regexp "^[ \t]*([^ \t:]*):[ \t]*(.*)[ \t]*$")) (cond ((null? doclist) '(#f '())) (else (let ((match (regexp-exec parser (car doclist)))) (list (match:substring match 1) (match:substring match 2) (cdr doclist)))))) (define (parse-proc defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) #f))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) (define (stringify value) (with-output-to-string (lambda () (write value)))) (define (proc->primitives-ssgml docitem) (let* ((data (docitem:data docitem)) (proc (procdoc:decl data)) (doc (procdoc:doc data))) `((refentry (id ,(stringify (proc:c-name proc)))) ((refnamediv) ((refname) ,(proc:scheme-name proc)) ((refpurpose) ,(car doc))) ((refsynopsisdiv) ((synopsis) ,(function-call-decl proc))) ((refsect1) ((title) "Description") ((para) ,@doc)) ((refsect1) ((title) "Implementation Notes") ((para) "Defined in " ((ulink (url ,(docitem:file docitem))) ((filename) ,(docitem:file docitem))) ,(string-append " at line " (stringify (docitem:line docitem)) ".")))))) (define (proclist->primitives-chapter l) (make-chapter "Primitives in Alphabetical Order" (map proc->primitives-ssgml l))) (define (make-chapter name l) `((chapter) ((title) ,name) ,@l)) (define (lexcmp selectors) (lambda (x y) (if (null? selectors) #t (let* ((selector (car selectors)) (sel (list-ref selector 0)) (less (list-ref selector 1)) (eq (list-ref selector 2)) (a (sel x)) (b (sel y))) (or (less a b) (and (eq a b) ((lexcmp (cdr selectors)) x y))))))) (define (proclist->file-chapter procs) (let ((procs (group (sort procs (lexcmp (list (list (lambda (x) (docitem:file x)) stringssgml docs) (let ((docs (group (sort docs (lexcmp (list (list (lambda (x) (doc:chapter (docitem:data x))) string-cissgml docs))) (define (embchapter->ssgml group) (make-chapter (doc:chapter (docitem:data (car group))) (map embsect->ssgml group))) (define (embsect->ssgml item) `((sect1 (id ,(doc:section (docitem:data item)))) ((title) ,(doc:section (docitem:data item))) ((para) ,@(doc:doc (docitem:data item))))) (define (docs->sgml frontpiece docs) (display "\n") (sgml (docs->ssgml frontpiece docs))) (define (docs->ssgml frontpiece docs) (let ((procs (sort (select-type 'SCWM_PROC docs) scheme-name-ciprimitives-chapter procs) ,(proclist->file-chapter procs) ,@(emblist->ssgml embdocs)))) (define (escape s) (list->string (let loop ((s (string->list s))) (cond ((null? s) '()) (else (case (car s) ((#\<) (append '(#\& #\l #\t #\;) (loop (cdr s)))) ((#\>) (append '(#\& #\g #\t #\;) (loop (cdr s)))) ((#\&) (append '(#\& #\a #\m #\p #\;) (loop (cdr s)))) (else (cons (car s) (loop (cdr s)))))))))) ;;; Convert ssgml to sgml: (define (sgml form . depth) (if (null? depth) (set! depth '(0))) (cond ((string? form) (display (make-string (car depth) #\space)) (display (escape form)) (newline)) ((null? form) '()) (else (display (make-string (car depth) #\space)) (sgml-render-start (car form)) (for-each (lambda (f) (sgml f (+ (car depth) 3))) (cdr form)) (display (make-string (car depth) #\space)) (sgml-render-end (car form))))) (define (sgml-render-start tag) (display "<") (display (car tag)) (for-each (lambda (args) (display " ") (display (car args)) (display "=") (write (cadr args))) (cdr tag)) (display ">\n")) (define (sgml-render-end tag) (display "\n")) (define testfilelist '("/home/hjstein/software/scwm/scwm/Grab.c" "/home/hjstein/software/scwm/scwm/ICCCM.c" "/home/hjstein/software/scwm/scwm/add_window.c" "/home/hjstein/software/scwm/scwm/binding.c" "/home/hjstein/software/scwm/scwm/borders.c" "/home/hjstein/software/scwm/scwm/callbacks.c" "/home/hjstein/software/scwm/scwm/color.c" "/home/hjstein/software/scwm/scwm/colormaps.c" "/home/hjstein/software/scwm/scwm/colors.c" "/home/hjstein/software/scwm/scwm/complex.c" "/home/hjstein/software/scwm/scwm/decor.c" "/home/hjstein/software/scwm/scwm/decorations.c" "/home/hjstein/software/scwm/scwm/deskpage.c" "/home/hjstein/software/scwm/scwm/draw-pie-menu.c" "/home/hjstein/software/scwm/scwm/drawmenu.c" "/home/hjstein/software/scwm/scwm/errors.c" "/home/hjstein/software/scwm/scwm/events.c" "/home/hjstein/software/scwm/scwm/face.c" "/home/hjstein/software/scwm/scwm/focus.c" "/home/hjstein/software/scwm/scwm/font.c" "/home/hjstein/software/scwm/scwm/getopt.c" "/home/hjstein/software/scwm/scwm/getopt1.c" "/home/hjstein/software/scwm/scwm/guile-compat.c" "/home/hjstein/software/scwm/scwm/icons.c" "/home/hjstein/software/scwm/scwm/image.c" "/home/hjstein/software/scwm/scwm/init_scheme_string.c" "/home/hjstein/software/scwm/scwm/menu.c" "/home/hjstein/software/scwm/scwm/menuitem.c" "/home/hjstein/software/scwm/scwm/miscprocs.c" "/home/hjstein/software/scwm/scwm/module-interface.c" "/home/hjstein/software/scwm/scwm/move.c" "/home/hjstein/software/scwm/scwm/placement.c" "/home/hjstein/software/scwm/scwm/resize.c" "/home/hjstein/software/scwm/scwm/screen.c" "/home/hjstein/software/scwm/scwm/scwm.c" "/home/hjstein/software/scwm/scwm/scwmmenu.c" "/home/hjstein/software/scwm/scwm/shutdown.c" "/home/hjstein/software/scwm/scwm/string_token.c" "/home/hjstein/software/scwm/scwm/syscompat.c" "/home/hjstein/software/scwm/scwm/system.c" "/home/hjstein/software/scwm/scwm/util.c" "/home/hjstein/software/scwm/scwm/virtual.c" "/home/hjstein/software/scwm/scwm/window.c" "/home/hjstein/software/scwm/scwm/xmisc.c" "/home/hjstein/software/scwm/scwm/xproperty.c")) (define frontpiece `((bookinfo) ((title) ((productname) "SCWM Reference Manual")) ((authorgroup) ((author) ((firstname) "Maciej") ((surname) "Stachowiak") ((affiliation) ((shortaffil) "MIT") ((jobtitle) "M.S. Degree Recipient") ((orgname) "Massachusetts Institute of Technology") ((orgdiv) "Department of Computer Science") ((address) ((city) "Cambridge") ((state) "Massachusetts") ((postcode) "12345") ((country) "U.S.A.") ((email) "mstachow@mit.edu")))) ((author) ((firstname) "Greg") ((surname) "Badros") ((affiliation) ((shortaffil) "UWashington") ((jobtitle) "Graduate Research Assistant") ((orgname) "University of Washington") ((orgdiv) "Department of Computer Science and Engineering") ((address) ((city) "Seattle") ((state) "Washington") ((postcode) "98195") ((country) "U.S.A.") ((email) "gjb@cs.washington.edu"))))) ((releaseinfo) "Release pre-0.8") ((pubdate) "28 July 1998") ((copyright) ((year) "1997–1998") ((holder) "Maciej Stachowiak and Greg J. Badros")))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 09:10:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA22304 for scwm-discuss-outgoing; Sat, 8 Aug 1998 09:10:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA22300 for ; Sat, 8 Aug 1998 09:10:01 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13333; Sat, 8 Aug 98 09:10:19 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA08805; Sat, 8 Aug 1998 16:09:34 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: New (almost usable) extract.scm References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 16:09:34 +0300 In-Reply-To: hjstein@bfr.co.il's message of "08 Aug 1998 16:05:17 +0300" Message-Id: Lines: 1024 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Here's an extract.scm that's mostly usable: (with ugly hacks for > ispell). Whoops! Emailed the old one before the new one finished copying to my mail machine. Here's the new one: #!/bin/sh exec guile -l $0 -- --run-from-shell "$@" !# ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** spaces identifier: & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; Parsing: ;;; (extract-docs-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; ;;; Checking docs are well formed: ;;; (check-docs doclist) ;;; Verifies stuff such as number of args = args ;;; in argslist, all args are SCM types, each arg is mentioned in ;;; the documentation, etc. ;;; ;;; Generating procedures-list documentation: ;;; (docs->proclist doclist) ;;; Output procedures-list stuff ;;; ;;; Generating sgml output: ;;; (docs->sgml doclist) ;;; Does various passes on the extract-docs-from-files output to ;;; generate the sgml output. ;;; ;;; Note: ;;; 1. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things (if I'm doing this). ;;; 2. Too much hacking has lead to a need for some code cleanup. ;;; 3. Still can't load slib stuff without stupid hacks that should ;;; have been dealt with when guile installed. (if (not (member "/usr/lib" %load-path)) (set! %load-path (cons "/usr/lib" %load-path))) ; HACK for guile to find slib!!!!!!! (use-modules (ice-9 regex) ; For regexp-quote & substitute. (ice-9 slib)) ; For sort. (require 'sort) (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*([^ \t:*]*:.*)")) ; spaces /**[^space or *] (define post-proc-doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]+(.*)")) ; spaces /** space+ (define func-name-match (make-regexp "^[ \t]*#[ \t]*define[ \t]+FUNC_NAME[ \t]+([^ \t]*)[ \t]*$")) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:required-args procrec) (list-ref procrec 2)) (define (proc:optional-args procrec) (list-ref procrec 3)) (define (proc:extra-var-args procrec) (list-ref procrec 4)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (procdoc:funcname procdocrec) (list-ref procdocrec 2)) (define (docitem:type rec) (list-ref rec 0)) (define (docitem:data rec) (list-ref rec 1)) (define (docitem:file rec) (list-ref rec 2)) (define (vdocitem:decl rec) (procdoc:decl (docitem:data rec))) (define (vdocitem:scheme-name rec) (proc:scheme-name (vdocitem:decl rec))) (define (vdocitem:c-name rec) (proc:c-name (vdocitem:decl rec))) (define (docitem:line rec) (list-ref rec 3)) (define (doc:chapter rec) (list-ref rec 0)) (define (doc:section rec) (list-ref rec 1)) (define (doc:doc rec) (list-ref rec 2)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document. (define (docs->proclist l) (for-each proc->list (sort (select-type 'SCWM_PROC l) scheme-name-ci=2 identical scheme names. (let loop ((spl (group (sort (select-type 'SCWM_PROC docitemlist) scheme-name=2 identical proc names - compiler will catch it. ) ;;; Complains about docitem recs it doesn't like (define (check-docitem procdocrec) (let* ((data (docitem:data procdocrec)) (file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (case (docitem:type procdocrec) ((DOC) ;; Check that DOC has a nonempty chapter name. (if (not (doc:chapter data)) (complain file line "Untagged embedded documentation")) ;; Check that DOC has a nonempty section name. (if (string=? "" (doc:section data)) (complain file line "Empty section heading")) ;; Check that DOC doc has nonempty documentation. (if (null? (doc:doc data)) (complain file line "Empty documentation"))) ;; Check that DOC doc identifier is HOOK or CONCEPT? ((SCWM_PROC) (let ((procrec (procdoc:decl data)) (docrec (procdoc:doc data)) (funcname (procdoc:funcname data))) ;; Check c-name vs scheme-name. (if (and (not (string=? (c-ident->scheme-ident (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec))) (not (string=? (c-name->scheme-name (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec)))) (complain file line "Scheme name of " (proc:scheme-name procrec) " doesn't match a C name of " (proc:c-name procrec))) ;; Warn about upper case words != arg names? ;; What's this business about the 1st doc line being a "purpose" sentence? ;; What's this business about "leading spaces" being omitted? ;; Check that arg 2+3+4 = length of arg5 (if (not (= (+ (proc:required-args procrec) (proc:optional-args procrec) (proc:extra-var-args procrec)) (length (proc:args procrec)))) (complain file line "Argument count mismatch in " (proc:scheme-name procrec))) ;; Warn about var param != 0 or 1. (if (and (not (= (proc:extra-var-args procrec) 0)) (not (= (proc:extra-var-args procrec) 1))) (complain file line "Var count is not 0 and is not 1")) ;; Check that all args are of type SCM (let loop ((i 1) (args (proc:args procrec))) (cond ((null? args)) ((eq? (caar args) 'SCM) (loop (1+ i) (cdr args))) (else (complain file line "In the declaration for " (proc:scheme-name procrec) ", argument " i " (" (cadar args) ") is not of type SCM")))) ;; Check that the proc is documented: (if (null? docrec) (complain file line "Procedure " (proc:scheme-name procrec) " is not documented")) ;; Check that each arg appears in description: (let next-arg ((argregexp (map (lambda (arg) (delimited-case-insensitive-regexp (c-name->scheme-name (symbol->string (cadr arg))))) (proc:args procrec))) (args (map cadr (proc:args procrec))) (i 1)) (cond ((null? args)) (else (let next-docline ((doc docrec)) (cond ((null? doc) (complain file line "Argument " i " (" (car args) ") of " (proc:scheme-name procrec) " is undocumented")) ((regexp-exec (car argregexp) (car doc))) (else (next-docline (cdr doc))))) (next-arg (cdr argregexp) (cdr args) (+ i 1))))) ;; Check that there's a func_name & it matches the c-name (if funcname (if (not (string=? (string-append "s_" (symbol->string (proc:c-name procrec))) funcname)) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a matching FUNC_NAME")) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a FUNC_NAME")))) (else (complain file line "Internal error - unrecognized doc record type."))))) (define (c-ident->scheme-ident s) (define to-regexp (make-regexp "_to_")) (define (to->-> s) (let ((match (regexp-exec to-regexp s))) (if match (regexp-substitute #f match 'pre "->" 'post) s))) (c-name->scheme-name (to->-> s))) (define (c-name->scheme-name s) (let* ((normname (map (lambda (c) (if (char=? c #\_) #\- c)) (string->list s))) (revname (reverse normname))) (cond ((or (null? revname) (null? (cdr revname))) (list->string normname)) ((and (char=? (car revname) #\p) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\? (cddr revname))))) ((and (char=? (car revname) #\x) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\! (cddr revname))))) (else (list->string normname))))) (define (delimited-case-insensitive-regexp s) (let ((ci-name (regexp-quote s))) (make-regexp (string-append "[ \t'`.,:\"]" ci-name "[ \t'`.,:\"]|" "^" ci-name "[ \t'`.,:\"]|" "[ \t'`.,:\"]" ci-name "$|" "^" ci-name "$") regexp/icase))) ;;; ispell crap (define (ispell-start) (system "rm /tmp/ispell-input 2>/dev/null") (system "mkfifo /tmp/ispell-input 2>/dev/null") (let ((ispell-out (open-input-pipe "ispell -a string (let loop ((s (cddr (string->list s)))) (cond ((null? s) '()) ((char=? (car s) #\space) '()) (else (cons (car s) (loop (cdr s)))))))) (define (ispell-stop ports) (close-port (car ports)) (close-pipe (cdr ports)) (system "rm /tmp/ispell-input 2>/dev/null")) (define (ispell-text docs) (let ((p '())) (dynamic-wind (lambda () (set! p (ispell-start))) (lambda () (for-each (lambda (rec) (ispell-complain rec p)) docs)) (lambda () (ispell-stop p))))) (define (ispell-complain rec p) (for-each (lambda (complaint) (complain (docitem:file rec) (docitem:line rec) complaint)) (apply append (map (lambda (line) (ispell-report (ispell-send line p))) (docitem->plaintextlist rec))))) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (proc->list procdocrec) (if (eq? 'SCWM_PROC (docitem:type procdocrec)) (let ((procrec (procdoc:decl (docitem:data procdocrec))) (docrec (procdoc:doc (docitem:data procdocrec)))) (display (function-call-decl procrec)) (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (displayl "[From " (docitem:file procdocrec) ":" (docitem:line procdocrec) "]\n\n\f\n")))) (define (function-call-decl procrec) (apply string-append "(" (proc:scheme-name procrec) (let loop ((args (map (lambda (a) (c-name->scheme-name (symbol->string (cadr a)))) (proc:args procrec))) (req (proc:required-args procrec)) (opt (proc:optional-args procrec)) (rest (proc:extra-var-args procrec))) (cond ((null? args) '(")")) ((> req 0) (cons " " (cons (car args) (loop (cdr args) (- req 1) opt rest)))) ((and (= req 0) (> opt 0)) (cons " #&optional" (loop args (- req 1) opt rest))) ((and (< req 0) (> opt 0)) (cons " " (cons (car args) (loop (cdr args) req (- opt 1) rest)))) ;; Now know req <= 0 & opt <= 0. ((> rest 0) (cons " . " (cons (car args) (loop (cdr args) req opt 0)))) (else (cons " " (cons (car args) (loop (cdr args) -1 0 0)))))))) ;;; Output doc record in format suitable for ispell: (define (docitem->plaintext procdocrec) (let* ((file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (for-each (lambda (d) (complain file line d)) (docitem->plaintextlist procdocrec)))) (define (docitem->plaintextlist procdocrec) (case (docitem:type procdocrec) ((SCWM_PROC) (procdoc:doc (docitem:data procdocrec))) ((DOC) (doc:doc (docitem:data procdocrec))) (else (complain (procdoc:file procdocrec) (procdoc:line procdorec) "Internal error - unrecognized doc record type.") '()))) (define (docs->text docs) (for-each (lambda (rec) (for-each (lambda (d) (displayl d "\n")) (docitem->plaintextlist rec))) docs)) (define (docs->annotated-text docs) (for-each docitem->plaintext docs)) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (extract-docs-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (extract-docs-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (extract-docs-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (cond (doc (loop (counting-read-line p) (cons (list 'SCWM_PROC doc filename linenum) defs))) (else (complain filename linenum "SCWM_PROC not parsable") (loop (counting-read-line p) defs))))) (docstart (let ((doc (parse-doc (extract-doc p line)))) (loop (counting-read-line p) (cons (list 'DOC doc filename linenum) defs)))) (else (loop (counting-read-line p) defs)))))))) (define (next-non-whitespace-line p) (define whitespace-line (make-regexp "^[ \t]*$")) (let ((line (counting-read-line p))) (if (or (eof-object? line) (regexp-exec whitespace-line line)) (next-non-whitespace-line p) line))) (define (extract-proc-n-doc line p) (let* ((proc (parse-proc (match-parentheses line p))) (next (counting-read-line p))) (cond ((not proc) ; Proc not parsable #f) ((eof-object? next) ; No doc & no func (list proc '() #f)) ((regexp-exec post-proc-doc-start-match next) ; Doc is first. (let* ((doc (extract-doc p next post-proc-doc-start-match)) (next (next-non-whitespace-line p)) (match (if next (regexp-exec func-name-match next) #f))) (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f)))) (else (let* ((match (regexp-exec func-name-match next)) ; Func name must be next. (next (next-non-whitespace-line p)) (doc (extract-doc p next post-proc-doc-start-match))) ; Then the docs. (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f))))))) (define (extract-doc p . xargs) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? xargs) (counting-read-line p) (car xargs))) (doc-start-match (if (or (null? xargs) (null? (cdr xargs))) doc-start-match (cadr xargs)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-doc doclist) (define parser (make-regexp "^[ \t]*([^ \t:]*):[ \t]*(.*)[ \t]*$")) (cond ((null? doclist) '(#f '())) (else (let ((match (regexp-exec parser (car doclist)))) (list (match:substring match 1) (match:substring match 2) (cdr doclist)))))) (define (parse-proc defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) #f))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) (define (stringify value) (with-output-to-string (lambda () (write value)))) (define (proc->primitives-ssgml docitem) (let* ((data (docitem:data docitem)) (proc (procdoc:decl data)) (doc (procdoc:doc data))) `((refentry (id ,(stringify (proc:c-name proc)))) ((refnamediv) ((refname) ,(proc:scheme-name proc)) ((refpurpose) ,(car doc))) ((refsynopsisdiv) ((synopsis) ,(function-call-decl proc))) ((refsect1) ((title) "Description") ((para) ,@doc)) ((refsect1) ((title) "Implementation Notes") ((para) "Defined in " ((ulink (url ,(docitem:file docitem))) ((filename) ,(docitem:file docitem))) ,(string-append " at line " (stringify (docitem:line docitem)) ".")))))) (define (proclist->primitives-chapter l) (make-chapter "Primitives in Alphabetical Order" (map proc->primitives-ssgml l))) (define (make-chapter name l) `((chapter) ((title) ,name) ,@l)) (define (lexcmp selectors) (lambda (x y) (if (null? selectors) #t (let* ((selector (car selectors)) (sel (list-ref selector 0)) (less (list-ref selector 1)) (eq (list-ref selector 2)) (a (sel x)) (b (sel y))) (or (less a b) (and (eq a b) ((lexcmp (cdr selectors)) x y))))))) (define (proclist->file-chapter procs) (let ((procs (group (sort procs (lexcmp (list (list (lambda (x) (docitem:file x)) stringssgml docs) (let ((docs (group (sort docs (lexcmp (list (list (lambda (x) (doc:chapter (docitem:data x))) string-cissgml docs))) (define (embchapter->ssgml group) (make-chapter (doc:chapter (docitem:data (car group))) (map embsect->ssgml group))) (define (embsect->ssgml item) `((sect1 (id ,(doc:section (docitem:data item)))) ((title) ,(doc:section (docitem:data item))) ((para) ,@(doc:doc (docitem:data item))))) (define (docs->sgml frontpiece docs) (display "\n") (sgml (docs->ssgml frontpiece docs))) (define (docs->ssgml frontpiece docs) (let ((procs (sort (select-type 'SCWM_PROC docs) scheme-name-ciprimitives-chapter procs) ,(proclist->file-chapter procs) ,@(emblist->ssgml embdocs)))) (define (escape s) (list->string (let loop ((s (string->list s))) (cond ((null? s) '()) (else (case (car s) ((#\<) (append '(#\& #\l #\t #\;) (loop (cdr s)))) ((#\>) (append '(#\& #\g #\t #\;) (loop (cdr s)))) ((#\&) (append '(#\& #\a #\m #\p #\;) (loop (cdr s)))) (else (cons (car s) (loop (cdr s)))))))))) (define (ispell-escape s) (list->string (let loop ((s (string->list s))) (cond ((null? s) '()) (else (case (car s) ((#\# #\-) (append (list #\\ (car s)) (loop (cdr s)))) (else (cons (car s) (loop (cdr s)))))))))) ;;; Convert ssgml to sgml: (define (sgml form . depth) (if (null? depth) (set! depth '(0))) (cond ((string? form) (display (make-string (car depth) #\space)) (display (escape form)) (newline)) ((null? form) '()) (else (display (make-string (car depth) #\space)) (sgml-render-start (car form)) (for-each (lambda (f) (sgml f (+ (car depth) 3))) (cdr form)) (display (make-string (car depth) #\space)) (sgml-render-end (car form))))) (define (sgml-render-start tag) (displayl "<" (car tag)) (for-each (lambda (args) (displayl " " (car args) "=") (write (cadr args))) (cdr tag)) (display ">\n")) (define (sgml-render-end tag) (displayl "\n")) (define testfilelist '("/home/hjstein/software/scwm/scwm/Grab.c" "/home/hjstein/software/scwm/scwm/ICCCM.c" "/home/hjstein/software/scwm/scwm/add_window.c" "/home/hjstein/software/scwm/scwm/binding.c" "/home/hjstein/software/scwm/scwm/borders.c" "/home/hjstein/software/scwm/scwm/callbacks.c" "/home/hjstein/software/scwm/scwm/color.c" "/home/hjstein/software/scwm/scwm/colormaps.c" "/home/hjstein/software/scwm/scwm/colors.c" "/home/hjstein/software/scwm/scwm/complex.c" "/home/hjstein/software/scwm/scwm/decor.c" "/home/hjstein/software/scwm/scwm/decorations.c" "/home/hjstein/software/scwm/scwm/deskpage.c" "/home/hjstein/software/scwm/scwm/draw-pie-menu.c" "/home/hjstein/software/scwm/scwm/drawmenu.c" "/home/hjstein/software/scwm/scwm/errors.c" "/home/hjstein/software/scwm/scwm/events.c" "/home/hjstein/software/scwm/scwm/face.c" "/home/hjstein/software/scwm/scwm/focus.c" "/home/hjstein/software/scwm/scwm/font.c" "/home/hjstein/software/scwm/scwm/getopt.c" "/home/hjstein/software/scwm/scwm/getopt1.c" "/home/hjstein/software/scwm/scwm/guile-compat.c" "/home/hjstein/software/scwm/scwm/icons.c" "/home/hjstein/software/scwm/scwm/image.c" "/home/hjstein/software/scwm/scwm/init_scheme_string.c" "/home/hjstein/software/scwm/scwm/menu.c" "/home/hjstein/software/scwm/scwm/menuitem.c" "/home/hjstein/software/scwm/scwm/miscprocs.c" "/home/hjstein/software/scwm/scwm/module-interface.c" "/home/hjstein/software/scwm/scwm/move.c" "/home/hjstein/software/scwm/scwm/placement.c" "/home/hjstein/software/scwm/scwm/resize.c" "/home/hjstein/software/scwm/scwm/screen.c" "/home/hjstein/software/scwm/scwm/scwm.c" "/home/hjstein/software/scwm/scwm/scwmmenu.c" "/home/hjstein/software/scwm/scwm/shutdown.c" "/home/hjstein/software/scwm/scwm/string_token.c" "/home/hjstein/software/scwm/scwm/syscompat.c" "/home/hjstein/software/scwm/scwm/system.c" "/home/hjstein/software/scwm/scwm/util.c" "/home/hjstein/software/scwm/scwm/virtual.c" "/home/hjstein/software/scwm/scwm/window.c" "/home/hjstein/software/scwm/scwm/xmisc.c" "/home/hjstein/software/scwm/scwm/xproperty.c")) (define frontpiece `((bookinfo) ((title) ((productname) "SCWM Reference Manual")) ((authorgroup) ((author) ((firstname) "Maciej") ((surname) "Stachowiak") ((affiliation) ((shortaffil) "MIT") ((jobtitle) "M.S. Degree Recipient") ((orgname) "Massachusetts Institute of Technology") ((orgdiv) "Department of Computer Science") ((address) ((city) "Cambridge") ((state) "Massachusetts") ((postcode) "12345") ((country) "U.S.A.") ((email) "mstachow@mit.edu")))) ((author) ((firstname) "Greg") ((surname) "Badros") ((affiliation) ((shortaffil) "UWashington") ((jobtitle) "Graduate Research Assistant") ((orgname) "University of Washington") ((orgdiv) "Department of Computer Science and Engineering") ((address) ((city) "Seattle") ((state) "Washington") ((postcode) "98195") ((country) "U.S.A.") ((email) "gjb@cs.washington.edu"))))) ((releaseinfo) "Release pre-0.8") ((pubdate) "28 July 1998") ((copyright) ((year) "1997–1998") ((holder) "Maciej Stachowiak and Greg J. Badros")))) (define (usage) (displayl "Usage: extract.scm [options] file1.c file2.c ... Extracts documentation from specified C source code files. Documentation must be embedded according to SCWM conventions: - Functions declared with the SCWM_PROC macro will be documented. They can be immediately followed by comments of the form /** ... */, which will be assumed to document the preceeding SCWM_PROC. Each SCWM_PROC should be followed by a FUNC_NAME define which matches the C function name given by the SCWM_PROC. - Comments of the form /** chapter_name : section_name ... */ will also be extracted. Options: -c, --check Check documentation for reasonableness. -s file, --sgml file Generate SGML and output to specified file. -p file, --proc file Generate procedure listing and output to specified file. -t file, --text file Generate plain text output to specified file. -a, --annotated-text Output plain text with each line prefixed by file:line_number:. -l, --ispell Run ispell on documentation. Currently hangs when given full SCWM source code set. -h, -? --help Display this info. If no flags are given, the default action is to check the files. ")) (define (process-arg n func arg rest files actions) ;; (displayl "process-arg\n" ;; "arg : " arg "\n" ;; "rest : " rest "\n" ;; "files : " files "\n" ;; "actions : " actions "\n") (cond ((= n 0) (process-cmd-line rest files (cons (lambda (docs) (func docs)) actions))) ((= n 1) (cond ((null? rest) (displayl arg " flag given without arguments. Ignored.\n") (process-cmd-line rest files actions)) (else (process-cmd-line (cdr rest) files (cons (lambda (docs) (with-output-to-file (car rest) (lambda () (func docs)))) actions))))) (else (displayl "Internal error: process-arg only takes 0 or 1 as arg count\n")))) (define (process-cmd-line args files actions) (call-with-current-continuation (lambda (ret) (cond ((null? args) ;; (displayl "args : " args "\n" ;; "files : " files "\n" ;; "actions : " actions "\n") (if (null? files) (displayl "Error: You must specify at least one file.") (let ((docs (apply extract-docs-from-files (reverse files)))) (if (null? actions) (check-docs docs) (for-each (lambda (act) (act docs)) (reverse actions)))))) (else ;; (displayl "process-cmd-line: processing '" (car args) "'\n") (case (string->symbol (car args)) ((-l --ispell) (process-arg 0 ispell-text (car args) (cdr args) files actions)) ((-c --check) (process-arg 0 check-docs (car args) (cdr args) files actions)) ((-s --sgml) (process-arg 1 (lambda (d) (docs->sgml frontpiece d)) (car args) (cdr args) files actions)) ((-p --proc) (process-arg 1 docs->proclist (car args) (cdr args) files actions)) ((-t --text) (process-arg 1 docs->text (car args) (cdr args) files actions)) ((-a --annotated-text) (process-arg 1 docs->annotated-text (car args) (cdr args) files actions)) ((-h -? --help) (usage) (ret '())) (else ;; (displayl "process-cmd-line: else. (car args) = '" (car args) "'\n") ;; (displayl "(eq? (car args) '-i) = " (eq? (string->symbol (car args)) '-i) "\n") (process-cmd-line (cdr args) (cons (car args) files) actions)))))))) ;;; Arg processing. (cond ((or (null? (command-line)) (null? (cdr (command-line))))) ((null? (cddr (command-line))) (usage) (exit)) (else (process-cmd-line (cddr (command-line)) '() '()) (exit))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 09:40:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA22543 for scwm-discuss-outgoing; Sat, 8 Aug 1998 09:40:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA22540 for ; Sat, 8 Aug 1998 09:40:36 -0400 Received: from netcom9.netcom.com by MIT.EDU with SMTP id AA28556; Sat, 8 Aug 98 09:40:14 EDT Received: (from ttn@localhost) by netcom9.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id GAA27736; Sat, 8 Aug 1998 06:40:21 -0700 (PDT) Date: Sat, 8 Aug 1998 06:40:21 -0700 (PDT) Message-Id: <199808081340.GAA27736@netcom9.netcom.com> From: thi To: hjstein@bfr.co.il Cc: guile@cygnus.com, hjstein@bfr.co.il, scwm-discuss@mit.edu In-Reply-To: <199808081236.PAA08622@blinky.bfr.co.il> (hjstein@bfr.co.il) Subject: Re: Serious eq? bug? Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Harvey J. Stein" writes: > Consider the following: > > hjstein@bacall:~$ guile > guile> (eq? (string->symbol "-a") '-a) > #t > guile> (eq? (string->symbol "-b") '-b) > #t > guile> (eq? (string->symbol "-i") '-i) > #f > > Is this expected behavior for an R4RS scheme which supports complex > number? If so, it's a real pain in the ass for command line > processing... yeah, PITA is exactly right. i had to work around it in thud by using (worse: special-casing) the string representation rather than the symbolic. blech. some more data: (eq? -i '-i) => #f (equal? -i '-i) => #t (eq? '-i '-i) => #f (equal? '-i '-i) => #t thi From owner-scwm-discuss@mit.edu Sat Aug 8 11:47:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA23178 for scwm-discuss-outgoing; Sat, 8 Aug 1998 11:47:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA23175 for ; Sat, 8 Aug 1998 11:47:16 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23568; Sat, 8 Aug 98 11:47:38 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22592; Sat, 8 Aug 1998 08:46:58 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> From: Greg Badros Date: 08 Aug 1998 08:46:58 -0700 In-Reply-To: Robert Bihlmeyer's message of "07 Aug 1998 19:33:07 +0200" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 06 Aug 1998 19:15:23 -0700 > >>>>> Greg Badros said: > > Greg> Yea-- Sam did a great job integrating w/ Emacs. > > Indeed. > > Greg> Perhaps this has changed more recently, but the boot-9.scm has > Greg> a use-module of (ice-9 session) (though it's after a *fixme* > Greg> comment...) > > Issuing a "(use-modules ((ice-9 session)))" from scwm.el couldn't > hurt. Nope. That seems like the right thing. G From owner-scwm-discuss@mit.edu Sat Aug 8 11:54:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA23231 for scwm-discuss-outgoing; Sat, 8 Aug 1998 11:54:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA23228 for ; Sat, 8 Aug 1998 11:54:14 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07056; Sat, 8 Aug 98 11:53:52 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22601; Sat, 8 Aug 1998 08:53:59 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: From: Greg Badros Date: 08 Aug 1998 08:53:58 -0700 In-Reply-To: hjstein@bfr.co.il's message of "08 Aug 1998 15:07:39 +0300" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > It looks like I'll have to do some sort of fork crap. I did some > funky stuff to spawn an ispell that I can both write to & read from, > but I've been getting hangs when running on scwm/*.c. Here's the > code, in case anyone wants to take a look at it. I think your problem may be simpler than that. ispell has a long list of word-splitting characters that cause it to treat a line as containing more than one word, and thus provide more than one response. e.g., ispell -A long-winded * + WIND Note ispell gave responses for "long" and for "winded" (wound? :-) ). In any case, my perl script would get out of sync when I thought I sent only a single word and it responded with two lines of output. Another notable word-split character class is the digits. I use: foreach my $word (split /[\d\W]+/, $text) { # ispell is picky about lots of stuff, so ignore them next if $word =~ /^[-\#]/; next if $word !~ /^\w\w+/; next if $word eq uc($word); Which means I split on non-word characters and digits, and then ignore certain "words" (those starting with "-" and two-letter words), before passing them on the ispell. Perhaps something related is the problem w/ your Guile version? Greg From owner-scwm-discuss@mit.edu Sat Aug 8 13:01:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23604 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:01:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23601 for ; Sat, 8 Aug 1998 13:01:34 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA11861; Sat, 8 Aug 98 13:01:12 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbom15744; Sat, 8 Aug 1998 17:01:21 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id NAA03523; Sat, 8 Aug 1998 13:00:54 -0400 To: "Harvey J. Stein" Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081236.PAA08622@blinky.bfr.co.il> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: "Harvey J. Stein"'s message of "Sat, 8 Aug 1998 15:36:17 +0300" Date: 08 Aug 1998 13:00:53 -0400 Message-Id: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199808081236.PAA08622@blinky.bfr.co.il> >>>> Sent on Sat, 8 Aug 1998 15:36:17 +0300 >>>> Honorable "Harvey J. Stein" writes >>>> on the subject of "Serious eq? bug?": >> Consider the following: >> >> hjstein@bacall:~$ guile >> guile> (eq? (string->symbol "-a") '-a) >> #t >> guile> (eq? (string->symbol "-b") '-b) >> #t >> guile> (eq? (string->symbol "-i") '-i) >> #f >> >> Is this expected behavior for an R4RS scheme which supports complex >> number? If so, it's a real pain in the ass for command line >> processing... I am afraid the problem is deeper than mere eq?. It looks like both -i and '-i are the negative imaginary unit, while i and 'i are ordinary symbols. It would seem wrong to interpret -i as a number. -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Sat Aug 8 13:08:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23663 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:08:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23660 for ; Sat, 8 Aug 1998 13:08:51 -0400 Received: from nms.rz.uni-kiel.de by MIT.EDU with SMTP id AA29723; Sat, 8 Aug 98 13:09:12 EDT Received: from sally.ifm.uni-kiel.de by nms.rz.uni-kiel.de with Local-SMTP (PP); Sat, 8 Aug 1998 19:08:05 +0200 Received: (from hukriede@localhost) by sally.ifm.uni-kiel.de (8.7.5/8.7.3) id TAA12518; Sat, 8 Aug 1998 19:08:03 +0200 (MET DST) Date: Sat, 8 Aug 1998 19:08:03 +0200 (MET DST) From: Wolfgang Hukriede Message-Id: <199808081708.TAA12518@sally.ifm.uni-kiel.de> To: guile@cygnus.com Subject: Re: Serious eq? bug? Cc: hjstein@bfr.co.il, scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Consider the following: > > hjstein@bacall:~$ guile > guile> (eq? (string->symbol "-a") '-a) > #t > guile> (eq? (string->symbol "-b") '-b) > #t > guile> (eq? (string->symbol "-i") '-i) > #f > Is this expected behavior for an R4RS scheme which supports complex > number? Yes. Since (number? '-i) ==> #t > If so, it's a real pain in the ass for command line > processing... You need to compare strings. You will have to use equal? or string=?, because eq? is not usable with strings. Afait, -a and -b aren't portable identifiers either. See the report. From owner-scwm-discuss@mit.edu Sat Aug 8 13:32:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23881 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:32:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23878 for ; Sat, 8 Aug 1998 13:32:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14144; Sat, 8 Aug 98 13:32:02 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA09788; Sat, 8 Aug 1998 20:32:11 +0300 To: Wolfgang Hukriede Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081708.TAA12518@sally.ifm.uni-kiel.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 20:32:11 +0300 In-Reply-To: Wolfgang Hukriede's message of "Sat, 8 Aug 1998 19:08:03 +0200 (MET DST)" Message-Id: Lines: 30 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Wolfgang Hukriede writes: > > Consider the following: > > > > hjstein@bacall:~$ guile > > guile> (eq? (string->symbol "-a") '-a) > > #t > > guile> (eq? (string->symbol "-b") '-b) > > #t > > guile> (eq? (string->symbol "-i") '-i) > > #f > > > Is this expected behavior for an R4RS scheme which supports complex > > number? > > Yes. Since (number? '-i) ==> #t > > > If so, it's a real pain in the ass for command line > > processing... > > You need to compare strings. You will have to use equal? or string=?, > because eq? is not usable with strings. Afait, -a and -b aren't > portable identifiers either. See the report. That's annoying because case uses eq?. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 13:32:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23886 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:32:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23883 for ; Sat, 8 Aug 1998 13:32:42 -0400 Received: from runyon.cygnus.com by MIT.EDU with SMTP id AA01854; Sat, 8 Aug 98 13:33:02 EDT Received: from deneb.cygnus.com (deneb.cygnus.com [205.180.230.82]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA00209; Sat, 8 Aug 1998 10:32:25 -0700 (PDT) Message-Id: <199808081732.KAA00209@cygnus.com> To: "Harvey J. Stein" Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? In-Reply-To: Your message of "Sat, 08 Aug 1998 15:36:17 +0300." <199808081236.PAA08622@blinky.bfr.co.il> Date: Sat, 08 Aug 1998 10:32:25 -0700 From: Per Bothner Sender: owner-scwm-discuss@mit.edu Precedence: bulk > guile> (eq? (string->symbol "-i") '-i) > #f > Is this expected behavior for an R4RS scheme which supports complex > number? Yes. Not only expected, but required. The Subject line is of course misleading. There is nothing the matter with eq?. The issue is the Scheme reader - how should '-i be interpreted? It is clear from R4RS that -i is a number, and hence cannot be eq? to any symbol. > If so, it's a real pain in the ass for command line > processing... How so? Why would you use symbols for command line arguments? That seems completely inappropriate: - Symbol are case-insensitive (in standard Scheme, at least). - Many characters cannot be part of symbols, unless you quote them (which is non-standard), or use string->symbol. - Symbols are atomic, and so you cannot process individual characters (without using symbol->string). - Scheme uses strings for filenames, not symbols. - Symbols are interned, whihc is probably not appropriate to transient commmand-line arguments. A command-line argument-list is a sequence (list or vector) of strings, not symbols. If you want to be able to write '-i instead of "-i", well, I'm sorry, that is not Scheme. If you want a nice terse shell syntax for interactive commands, while still maintaining the power and semantics of Scheme, that is a reasonable goal, which I am happy to discuss. However, don't use the Scheme reader for that. For some of my ideas for a functional shell, see: http://www.cygnus.com/~bothner/Qshell.html --Per Bothner Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner From owner-scwm-discuss@mit.edu Sat Aug 8 13:39:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23973 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:39:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23970 for ; Sat, 8 Aug 1998 13:38:57 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA02470; Sat, 8 Aug 98 13:39:17 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA09837; Sat, 8 Aug 1998 20:38:42 +0300 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 20:38:42 +0300 In-Reply-To: Greg Badros's message of "08 Aug 1998 08:53:58 -0700" Message-Id: Lines: 35 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > It looks like I'll have to do some sort of fork crap. I did some > > funky stuff to spawn an ispell that I can both write to & read from, > > but I've been getting hangs when running on scwm/*.c. Here's the > > code, in case anyone wants to take a look at it. > > I think your problem may be simpler than that. ispell has a long list > of word-splitting characters that cause it to treat a line as containing > more than one word, and thus provide more than one response. e.g., I fixed it. The man page claims that for each input line ispell returns a line for each "word" & terminate with a blank line. So, I was sending lines & reading until a blank line. However, ispell ignores its documentation - it ignores lines starting with '-' & '#' (and maybe other chars, but these were the ones giving me headaches). For example: hjstein@bacall:~$ echo "ispell sucks" | ispell -a @(#) International Ispell Version 3.1.20 10/10/95 * + SUCK hjstein@bacall:~$ echo "# ispell sucks" | ispell -a @(#) International Ispell Version 3.1.20 10/10/95 hjstein@bacall:~$ Thus I'd end up in a deadlock waiting for a blank line to appear. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 13:43:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24040 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:43:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA24037 for ; Sat, 8 Aug 1998 13:43:26 -0400 Received: from nms.rz.uni-kiel.de by MIT.EDU with SMTP id AA15022; Sat, 8 Aug 98 13:43:03 EDT Received: from sally.ifm.uni-kiel.de by nms.rz.uni-kiel.de with Local-SMTP (PP); Sat, 8 Aug 1998 19:43:12 +0200 Received: (from hukriede@localhost) by sally.ifm.uni-kiel.de (8.7.5/8.7.3) id TAA12633; Sat, 8 Aug 1998 19:43:11 +0200 (MET DST) Date: Sat, 8 Aug 1998 19:43:11 +0200 (MET DST) From: Wolfgang Hukriede Message-Id: <199808081743.TAA12633@sally.ifm.uni-kiel.de> To: guile@cygnus.com Subject: Re: Serious eq? bug? Cc: hjstein@bfr.co.il, scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) wrote: > That's annoying because case uses eq? Cond is much nicer anyway. Doubt, I'd ever use "case". Hth, hand, Wolfgang. From owner-scwm-discuss@mit.edu Sat Aug 8 13:44:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24076 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:44:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA24072 for ; Sat, 8 Aug 1998 13:44:52 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15108; Sat, 8 Aug 98 13:44:29 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA09872; Sat, 8 Aug 1998 20:44:37 +0300 To: Per Bothner Cc: "Harvey J. Stein" , guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081732.KAA00209@cygnus.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 20:44:37 +0300 In-Reply-To: Per Bothner's message of "Sat, 08 Aug 1998 10:32:25 -0700" Message-Id: Lines: 44 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Per Bothner writes: > > guile> (eq? (string->symbol "-i") '-i) > > #f > > Is this expected behavior for an R4RS scheme which supports complex > > number? > > Yes. Not only expected, but required. > > The Subject line is of course misleading. There is nothing the > matter with eq?. The issue is the Scheme reader - how should '-i > be interpreted? It is clear from R4RS that -i is a number, > and hence cannot be eq? to any symbol. > > > If so, it's a real pain in the ass for command line > > processing... > > How so? Why would you use symbols for command line arguments? > That seems completely inappropriate: > - Symbol are case-insensitive (in standard Scheme, at least). > - Many characters cannot be part of symbols, unless you quote > them (which is non-standard), or use string->symbol. > - Symbols are atomic, and so you cannot process individual characters > (without using symbol->string). > - Scheme uses strings for filenames, not symbols. > - Symbols are interned, whihc is probably not appropriate to > transient commmand-line arguments. The idea was along the lines of: (case (string->symbol arg) ((-i --ispell) ...) ((-s --sgml) ...) ...) Maybe "pain in the ass" was a little strong. It just took a long time to figure out why the above was failing to detect -i. Now I'll have to go & define a case-equal macro... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 13:47:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA24128 for scwm-discuss-outgoing; Sat, 8 Aug 1998 13:47:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA24125 for ; Sat, 8 Aug 1998 13:47:38 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15449; Sat, 8 Aug 98 13:47:14 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA09902; Sat, 8 Aug 1998 20:47:24 +0300 To: Wolfgang Hukriede Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081743.TAA12633@sally.ifm.uni-kiel.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Aug 1998 20:47:24 +0300 In-Reply-To: Wolfgang Hukriede's message of "Sat, 8 Aug 1998 19:43:11 +0200 (MET DST)" Message-Id: Lines: 104 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Wolfgang Hukriede writes: > hjstein@bfr.co.il (Harvey J. Stein) wrote: > > > That's annoying because case uses eq? > > Cond is much nicer anyway. Doubt, I'd ever use "case". The following would be more complex using cond. It'd look ok with a case-equal: (define (usage) (displayl "Usage: extract.scm [options] file1.c file2.c ... Extracts documentation from specified C source code files. Documentation must be embedded according to SCWM conventions: - Functions declared with the SCWM_PROC macro will be documented. They can be immediately followed by comments of the form /** ... */, which will be assumed to document the preceeding SCWM_PROC. Each SCWM_PROC should be followed by a FUNC_NAME define which matches the C function name given by the SCWM_PROC. - Comments of the form /** chapter_name : section_name ... */ will also be extracted. Options: -c, --check Check documentation for reasonableness. -s file, --sgml file Generate SGML and output to specified file. -p file, --proc file Generate procedure listing and output to specified file. -t file, --text file Generate plain text output to specified file. -a, --annotated-text Output plain text with each line prefixed by file:line_number:. -l, --ispell Run ispell on documentation. Currently hangs when given full SCWM source code set. -h, -? --help Display this info. If no flags are given, the default action is to check the files. ")) (define (process-arg n func arg rest files actions) (cond ((= n 0) (process-cmd-line rest files (cons (lambda (docs) (func docs)) actions))) ((= n 1) (cond ((null? rest) (displayl arg " flag given without arguments. Ignored.\n") (process-cmd-line rest files actions)) (else (process-cmd-line (cdr rest) files (cons (lambda (docs) (with-output-to-file (car rest) (lambda () (func docs)))) actions))))) (else (displayl "Internal error: process-arg only takes 0 or 1 as arg count\n")))) (define (process-cmd-line args files actions) (call-with-current-continuation (lambda (ret) (cond ((null? args) (if (null? files) (displayl "Error: You must specify at least one file.") (let ((docs (apply extract-docs-from-files (reverse files)))) (if (null? actions) (check-docs docs) (for-each (lambda (act) (act docs)) (reverse actions)))))) (else (case (string->symbol (car args)) ((-l --ispell) (process-arg 0 ispell-text (car args) (cdr args) files actions)) ((-c --check) (process-arg 0 check-docs (car args) (cdr args) files actions)) ((-s --sgml) (process-arg 1 (lambda (d) (docs->sgml frontpiece d)) (car args) (cdr args) files actions)) ((-p --proc) (process-arg 1 docs->proclist (car args) (cdr args) files actions)) ((-t --text) (process-arg 1 docs->text (car args) (cdr args) files actions)) ((-a --annotated-text) (process-arg 1 docs->annotated-text (car args) (cdr args) files actions)) ((-h -? --help) (usage) (ret '())) (else (process-cmd-line (cdr args) (cons (car args) files) actions)))))))) ;;; Arg processing. (cond ((or (null? (command-line)) (null? (cdr (command-line))))) ((null? (cddr (command-line))) (usage) (exit)) (else (process-cmd-line (cddr (command-line)) '() '()) (exit))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Aug 8 14:02:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24339 for scwm-discuss-outgoing; Sat, 8 Aug 1998 14:02:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24336 for ; Sat, 8 Aug 1998 14:02:17 -0400 Received: from nms.rz.uni-kiel.de by MIT.EDU with SMTP id AA04202; Sat, 8 Aug 98 14:02:38 EDT Received: from sally.ifm.uni-kiel.de by nms.rz.uni-kiel.de with Local-SMTP (PP); Sat, 8 Aug 1998 20:01:41 +0200 Received: (from hukriede@localhost) by sally.ifm.uni-kiel.de (8.7.5/8.7.3) id UAA12694; Sat, 8 Aug 1998 20:01:40 +0200 (MET DST) Date: Sat, 8 Aug 1998 20:01:40 +0200 (MET DST) From: Wolfgang Hukriede Message-Id: <199808081801.UAA12694@sally.ifm.uni-kiel.de> To: guile@cygnus.com Subject: Re: Serious eq? bug? Cc: hjstein@bfr.co.il, scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) wrote: > The following would be more complex using cond. It'd look ok with a > case-equal: [snipped] Ok. Another approach might be to set up a table ((flagnames action) ...) or even ((flagnames action short-description) ...) or some such. Happy hacking, Wolfgang. From owner-scwm-discuss@mit.edu Sat Aug 8 14:09:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24417 for scwm-discuss-outgoing; Sat, 8 Aug 1998 14:09:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24414 for ; Sat, 8 Aug 1998 14:09:52 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA04857; Sat, 8 Aug 98 14:10:12 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA24347; Sat, 8 Aug 1998 11:09:37 -0700 (PDT) To: Wolfgang Hukriede Cc: guile@cygnus.com, hjstein@bfr.co.il, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081801.UAA12694@sally.ifm.uni-kiel.de> From: Greg Badros Date: 08 Aug 1998 11:09:37 -0700 In-Reply-To: Wolfgang Hukriede's message of "Sat, 8 Aug 1998 20:01:40 +0200 (MET DST)" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Wolfgang Hukriede writes: > hjstein@bfr.co.il (Harvey J. Stein) wrote: > > > The following would be more complex using cond. It'd look ok with a > > case-equal: > [snipped] > > Ok. Another approach might be to set up a table > > ((flagnames action) ...) > > or even > > ((flagnames action short-description) ...) > > or some such. Happy hacking, Wolfgang. Isn't there some getopt package for Guile/scheme? This has to be a solved problem... noone should need to do command line processing by hand any longer! Greg From owner-scwm-discuss@mit.edu Sat Aug 8 14:53:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24653 for scwm-discuss-outgoing; Sat, 8 Aug 1998 14:53:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24650 for ; Sat, 8 Aug 1998 14:53:18 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA20058; Sat, 8 Aug 98 14:52:55 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbot07913; Sat, 8 Aug 1998 18:52:51 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id OAA03932; Sat, 8 Aug 1998 14:52:48 -0400 To: Wolfgang Hukriede Cc: guile@cygnus.com, hjstein@bfr.co.il, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808081708.TAA12518@sally.ifm.uni-kiel.de> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Wolfgang Hukriede's message of "Sat, 8 Aug 1998 19:08:03 +0200 (MET DST)" Date: 08 Aug 1998 14:52:48 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199808081708.TAA12518@sally.ifm.uni-kiel.de> >>>> Sent on Sat, 8 Aug 1998 19:08:03 +0200 (MET DST) >>>> Honorable Wolfgang Hukriede writes >>>> on the subject of "Re: Serious eq? bug?": >> >> (number? '-i) ==> #t Wow! '-i is a number, while '-a, '-b, 'a, 'b and 'i are symbols. And someone seriously calls it "good design"?! What about pi? e? gamma? -- Sam Steingold, running RedHat5.1 GNU/Linux (http://www.linux.org) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, the choice of the GNU (http://www.gnu.org) generation. Single tasking: Just Say No. From owner-scwm-discuss@mit.edu Sat Aug 8 17:00:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA25279 for scwm-discuss-outgoing; Sat, 8 Aug 1998 17:00:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA25275 for ; Sat, 8 Aug 1998 17:00:22 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA17691; Sat, 8 Aug 98 17:00:41 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id WAA03228; Sat, 8 Aug 1998 22:00:05 +0100 Date: Sat, 8 Aug 1998 22:00:03 +0100 (BST) From: Danius Michaelides To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: winlist skip In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 6 Aug 1998, Greg Badros wrote: > Danius Michaelides writes: > > > Just visiting the winlist-skip situation. I start an FvwmIconMan in > > my .scwmrc, and it lists all windows, including those with > > winlist-skip set. But if i start a new FvwmIconMan from scwmrepl it > > works fine, and only windows that should are shown. Any ideas? > > Where do you start the FvwmIconMan in your .scwmrc? Same behaviour if > you start it at the end? Maybe try starting it from your startup-hook. > The winlist-skip is now handled via a scheme level object property that > doesn't get set until pretty late in the game, which might be the cause > of your problem. We'll have to look into it more thoroughly, but > knowing what workaround works around the problem will help us track down > the problem. It doesnt appear to make much difference whether the module is started in the .scwmrc file, or by a startup hook. Windows started in .xinitrc appear to have the winlist-skip set properly, and arent shown by FvwmIconMan. It is the windows that are spawned and swallowed by FvwmButtons (in my case) that appear to cause the problem. I also have to force these windows to start way of screen, otherwise i get ghost window frames. So perhaps theres a problem when windows get reparented by FvwmButtons? Danius From owner-scwm-discuss@mit.edu Sat Aug 8 18:22:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA25629 for scwm-discuss-outgoing; Sat, 8 Aug 1998 18:22:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA25626 for ; Sat, 8 Aug 1998 18:22:29 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA23105; Sat, 8 Aug 98 18:22:47 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA25314; Sat, 8 Aug 1998 15:22:12 -0700 (PDT) To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: winlist skip References: From: Greg Badros Date: 08 Aug 1998 15:22:12 -0700 In-Reply-To: Danius Michaelides's message of "Sat, 8 Aug 1998 22:00:03 +0100 (BST)" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Danius Michaelides writes: > It doesnt appear to make much difference whether the module is started in > the .scwmrc file, or by a startup hook. Windows started in .xinitrc appear > to have the winlist-skip set properly, and arent shown by FvwmIconMan. It > is the windows that are spawned and swallowed by FvwmButtons (in my case) > that appear to cause the problem. You mean only the windows spawned and swallowed by FvwmButtons mistakenly appear in the FvwmIconMan? > I also have to force these windows to start way of screen, otherwise i > get ghost window frames. So perhaps theres a problem when windows get > reparented by FvwmButtons? I'll have to play with FvwmButtons some. Thanks! Greg From owner-scwm-discuss@mit.edu Sun Aug 9 04:13:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA28882 for scwm-discuss-outgoing; Sun, 9 Aug 1998 04:13:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA28879 for ; Sun, 9 Aug 1998 04:13:35 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24231; Sun, 9 Aug 98 04:13:48 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA13408; Sun, 9 Aug 1998 11:13:00 +0300 To: Wolfgang Hukriede Cc: guile@cygnus.com, scwm-discuss@mit.edu Subject: Complex complexities (was Re: Serious eq? bug?) References: <199808081708.TAA12518@sally.ifm.uni-kiel.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Aug 1998 11:13:00 +0300 In-Reply-To: Sam Steingold's message of "08 Aug 1998 14:52:48 -0400" Message-Id: Lines: 70 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <199808081708.TAA12518@sally.ifm.uni-kiel.de> > >>>> Sent on Sat, 8 Aug 1998 19:08:03 +0200 (MET DST) > >>>> Honorable Wolfgang Hukriede writes > >>>> on the subject of "Re: Serious eq? bug?": > >> > >> (number? '-i) ==> #t > > Wow! '-i is a number, while '-a, '-b, 'a, 'b and 'i are symbols. > And someone seriously calls it "good design"?! > What about pi? e? gamma? That's why it took me so long to figure it out... But, it makes sense given that +i & -i are numbers. Then they do have to behave that way: guile> (number? 3) #t guile> (number? '3) #t guile> (number? ''3) #f guile> (number? -i) #t guile> (number? '-i) #t guile> (number? ''-i) #f If you're going to have complex numbers, you either need +/-i to be a number or you need a # escape, as in hjstein@blinky:~$ gcl GCL (GNU Common Lisp) Version(2.2) Sat Feb 17 00:36:29 PST 1996 Licensed under GNU Public Library License Contains Enhancements by W. Schelter Loading init.lsp Hi Finished loading init.lsp >(log -1) #C(0.0 3.1415926535897931) In guile you have: guile> (log -1) 0.0+3.14159265358979i R4RS stipulates: ==> | | + i | - i | + i | - i | + i | - i | + i | - i ==> | / | so that a+bi is a complex number. I personally think that #C(a b) is less surprising. Also, I think it would have been clearer to only allow the a+bi & a-bi forms... I guess I never noticed it before because most other schemes I've used didn't support complex numbers. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Aug 9 05:43:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29260 for scwm-discuss-outgoing; Sun, 9 Aug 1998 05:43:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA29257 for ; Sun, 9 Aug 1998 05:43:22 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05569; Sun, 9 Aug 98 05:42:50 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id MAA13830; Sun, 9 Aug 1998 12:42:51 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Aug 1998 12:42:50 +0300 In-Reply-To: Robert Bihlmeyer's message of "06 Aug 1998 14:35:17 +0200" Message-Id: Lines: 134 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > You can use shorttags (SGML and DocBook allow this). > E.g. your example could be written as > > '(button1 sidebar) > > or even > > > which has as many characters as the {}-notation. Both forms are IIRC > legal SGML. > > Harvey> I must concur, but for different reasons. WRT comment > Harvey> extraction & sgml markup we have the following possibilities: > > Harvey> 1. Write the comments in complete sgml, with all the stupid > Harvey> tag/end tag pairs & all the stupid special character > Harvey> escapes, or > Harvey> 2. Write the comments in partial sgml, or > Harvey> 3. Mark up the comments in some easily parsible, concise, > Harvey> easy to remember generic way. > Harvey> 4. Something I'm not thinking of. > > Harvey> If we follow option 1, then we can just extract the comments > Harvey> for the SGML output, but we have to actually parse the SGML > Harvey> comments to *remove* the SGML crap for something like the > Harvey> procedure listings/plain text output. > > This is easily done with the equivalent of > s/<[^>]*>// > s/</ s/&/&/ Good point. But, with the 2nd above short tag style it gets more complicated. It can also break for tag arguments - I don't know if it's strictly SGML legal, but I've seen quoted strings as tag arguments (as in ) containing <, >, and &. But, I guess these can be modified in the documentation. > Harvey> This'd make writing > Harvey> documentation much more painful for the programmer. > > Nope. It just gives her the *possiblity* to put markup into her > documentation. Nobody wants to force programmers to throw lots of tags > into documentation. We'd probably want to keep the sgml markup to a > minimum. Good point. I'd just hate to see it proliferate - it'd enhance the manuals at the expense of the code comments themselves. > Harvey> unless *everything* is output in various forms of SGML & then > Harvey> run through Jade or some other parser to generate html as > Harvey> well as plain text. > > This would be one possible way in the future. It's not available > today. > > Harvey> If we follow 2, then we have to parse the partial SGML > Harvey> comments so that we can do things like escape characters > Harvey> properly & add additional markup for SGML output & remove > Harvey> markup for procedure listings/plain text output. This is > Harvey> marginally less painful for the programmer, but even worse > Harvey> for the extractor, since we can't avoid parsing the comments > Harvey> by just dumping them & running them through the SGML parser. > > This sounds like a bad compromise where nobody is satisfied. > But I don't quite follow what you mean with partial sgml. Not allowing all > tags? other constructs? This is what's currently being done. We have SGML markup in comments, namely: software/scwm/scwm/deskpage.c:185: For example (set-desk-size 3 3) creates a. software/scwm/scwm/events.c:445: the SCWMEXEC protocol. Also see doc/scwmexec.proto.. software/scwm/scwm/miscprocs.c:380: Return the $PREFIX directory path that scwm was installed with.. software/scwm/scwm/miscprocs.c:389: Return the $EXECPREFIX directory path that scwm was installed with.. (albet it's rare - these are all the examples). We also have non-SGML conventions in the comments: - `foo' is an xref. - Upper case words refer to arguments. We also have non-escaped SGML special characters: software/scwm/scwm/binding.c:933: Return the mapping of physical->logical pointer buttons as a list.. > Perhaps we should ban all markup from comments for now, and evaluate > the specific case if the need arises. I wouldn't disapprove. The sgml bugs me in general because (as has been mentioned previously): - Lack of readability. - Lack of processing tools - no SGML->text, no SGML->info, ... - General inability to achieve goals - It seems to me that SGML is intended to allow markup of text for production of documents in such a way that the text markup *doesn't* include any information regarding the final destination - it's a pure logical markup. However, given the need of embedded graphics, different graphics types for different outputs, etc, it doesn't seem to me that this is an acheivable goal. Linux-doc hit a big snag with this. - Annoying escaping mechanism. - I had major headaches with linux-doc because of the escaping mechanism. I a) couldn't include C code even if I was in a section, and b) escaping rules were a little different inside of sections. A markup that requires modification of code insertions is, IMHO, a poor choice for code documentation. I don't know to what extent the above will hold with docbook. Please tell me if the situation is better than the above. In any case, at this point I'd just like to see a short, simple, accurate description of what exactly the developers want to support in their embedded documentation. Is it Tags + unescaped special characters + `proc' + ARGUMENT, with tags stripped from docs for text output, `proc' & ARGUMENT marked up for SGML output, unescaped specials escaped for SGML output? Are there any particular spacing conventions? What about tags otf ; Sun, 9 Aug 1998 06:41:24 -0400 Received: from Galois.suse.de by MIT.EDU with SMTP id AA03232; Sun, 9 Aug 98 06:41:36 EDT Received: from Frechet.suse.de (Frechet.suse.de [192.168.102.27]) by Galois.suse.de (8.8.8/8.8.8) with ESMTP id MAA05147; Sun, 9 Aug 1998 12:40:56 +0200 Received: (from ke@localhost) by Frechet.suse.de (8.8.8/8.8.8) id MAA02750; Sun, 9 Aug 1998 12:40:56 +0200 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Karl Eichwalder Date: 09 Aug 1998 12:40:55 +0200 In-Reply-To: hjstein@bfr.co.il's message of 09 Aug 1998 12:42:50 +0300 Message-Id: Lines: 60 X-Mailer: Gnus v5.5/Emacs 20.2 X-Emacs: Emacs 20.2 (with raw setting) Mime-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - "Sodani") Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: | Robert Bihlmeyer writes: | | > You can use shorttags (SGML and DocBook allow this). | > E.g. your example could be written as Don't use these shorttag; in the long run they lead to confusions. XML avoids those advanced SGML features intentionally. XML is a subset of the SGML standard (http://www.w3.org/XML/). | - Lack of readability. Using an SGML editor, it's quite readable. The Emacs add-on PSGML does a good job. Writing _text_ I prefere to use a bright gray to make the markup nearly invisible. PSGML has a menu option to hide the markup entirely -- or partially, at your will. | - Lack of processing tools - no SGML->text, no SGML->info, ... Yes, unfortunately there's no SGML->info. But there's a work around for SGML->text (DocBook DTD): use Norman Walsh's DSSSL style sheets to produce HTML and pipe the HTML file through `lynx -dump'. | Linux-doc hit a big snag with this. Don't judge about SGML from looking at Linuxdoc; it's a hack to get a job done. | - Annoying escaping mechanism. | - I had major headaches with linux-doc because of the escaping | mechanism. I a) couldn't include C code even if I was in a | section, and b) escaping rules were a little different | inside of sections. A markup that requires modification | of code insertions is, IMHO, a poor choice for code | documentation. As I said: Linuxdoc is a hack. E.g., it doesn't support the following feature; to include SGML code, you can use a kind of conditional markup: A sentence with SGML markup. ]]> and the parser will spit out the and tags _unmodified_ (= with "<" and ">"). But I guess, that's not the way to write the scwm documentation ;) To draw a conclusion: the writer of embedded documentation should not be bothered with writing generic SGML; maybe, XML is an option (no shorttags are allowed, etc.). Or invent your own simple markup; then, the extractor should convert this markuped text to a DocBook conforming SGML document on the fly. When I say "convert", I mean that the extractor should insert all these silly "tags" to produce a valid SGML document. -- Karl Eichwalder S.u.S.E. GmbH Fax +49-911-3206727 ke@suse.de Gebhardtstrasse 2 Mo & Th 13:00-18:00: http://www.suse.de/~ke/ 90762 Fuerth, Germany Hotline +49-911-3247130 From owner-scwm-discuss@mit.edu Sun Aug 9 12:36:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30925 for scwm-discuss-outgoing; Sun, 9 Aug 1998 12:36:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30922 for ; Sun, 9 Aug 1998 12:35:38 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA27830; Sun, 9 Aug 98 12:34:59 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA03390; Sun, 9 Aug 1998 12:34:52 -0400 (EDT) Message-Id: <199808091634.MAA03390@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Wolfgang Hukriede , guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? In-Reply-To: Your message of "08 Aug 1998 20:32:11 +0300." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 09 Aug 1998 12:34:51 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > > You need to compare strings. You will have to use equal? or string=?, > > because eq? is not usable with strings. Afait, -a and -b aren't > > portable identifiers either. See the report. > > That's annoying because case uses eq?. This is Lisp, however, the language where syntax and functions converge. You can build an alternative to case that used equal? or string=?, and Did The Right Thing. Perry From owner-scwm-discuss@mit.edu Sun Aug 9 15:36:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA31759 for scwm-discuss-outgoing; Sun, 9 Aug 1998 15:36:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA31756 for ; Sun, 9 Aug 1998 15:36:21 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA04723; Sun, 9 Aug 98 15:36:29 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA21293; Sun, 9 Aug 1998 22:35:33 +0300 To: perry@piermont.com Cc: Wolfgang Hukriede , guile@cygnus.com, scwm-discuss@mit.edu Subject: Re: Serious eq? bug? References: <199808091634.MAA03390@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Aug 1998 22:35:33 +0300 In-Reply-To: "Perry E. Metzger"'s message of "Sun, 09 Aug 1998 12:34:51 -0400" Message-Id: Lines: 20 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > > You need to compare strings. You will have to use equal? or string=?, > > > because eq? is not usable with strings. Afait, -a and -b aren't > > > portable identifiers either. See the report. > > > > That's annoying because case uses eq?. > > This is Lisp, however, the language where syntax and functions > converge. You can build an alternative to case that used equal? > or string=?, and Did The Right Thing. Not really, since macros have only recently been standardized, but, yes, I can in the interpreter of concern. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 10 03:53:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA02539 for scwm-discuss-outgoing; Mon, 10 Aug 1998 03:53:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA02529 for ; Mon, 10 Aug 1998 03:53:35 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA03351 for scwm-discuss@huis-clos.mit.edu; Mon, 10 Aug 1998 09:53:07 +0200 (CEST) Received: (qmail 1738 invoked by uid 115); 9 Aug 1998 16:26:29 -0000 To: scwm-discuss@mit.edu Subject: Re: Embedded documentation syntax strictness. References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 09 Aug 1998 18:26:27 +0200 In-Reply-To: hjstein@bfr.co.il's message of "08 Aug 1998 20:38:42 +0300" Message-ID: Lines: 46 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 08 Aug 1998 20:38:42 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> I fixed it. The man page claims that for each input line Harvey> ispell returns a line for each "word" & terminate with a Harvey> blank line. So, I was sending lines & reading until a blank Harvey> line. However, ispell ignores its documentation - it ignores Harvey> lines starting with '-' & '#' (and maybe other chars, but Harvey> these were the ones giving me headaches). My man page seems correct: When in the -a mode, ispell will also accept lines of sin­ gle words prefixed with any of '*', '&', '@', '+', '-', '~', '#', '!', '%', or '^'. [...] * Add to personal dictionary @ Accept word, but leave out of dictionary # Save current personal dictionary ~ Set parameters based on filename + Enter TeX mode - Exit TeX mode ! Enter terse mode % Exit terse mode ^ Spell-check rest of line [...] Ah, another good advice from the man page: "It is recommended that programmatic interfaces prefix every data line with an uparrow to protect them­ selves against future changes in ispell." Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 10 03:53:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA02538 for scwm-discuss-outgoing; Mon, 10 Aug 1998 03:53:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA02527 for ; Mon, 10 Aug 1998 03:53:34 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA03331 for scwm-discuss@huis-clos.mit.edu; Mon, 10 Aug 1998 09:53:06 +0200 (CEST) Received: (qmail 1699 invoked by uid 115); 9 Aug 1998 16:18:27 -0000 To: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Aug 1998 18:18:24 +0200 In-Reply-To: hjstein@bfr.co.il's message of "09 Aug 1998 12:42:50 +0300" Message-ID: Lines: 60 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 09 Aug 1998 12:42:50 +0300 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: [Ripping out tags] Harvey> But, with the 2nd above short tag style it gets more Harvey> complicated. Yes. In fact, I do not recommend the "bar" could be a viable compromise, but even this alternative may not be worth the work to support it. Harvey> It can also break for tag arguments - I don't Harvey> know if it's strictly SGML legal, but I've seen quoted Harvey> strings as tag arguments (as in ) containing <, Harvey> >, and &. You're right about that. It is still managable with s/<[^>"]*("[^"]*"[^>"])*>// but that's already a bit of a pain to look at. Replacement of & stuff will happen after tag ripping it should not be messed up. This still does not handle verbatim environments like the one Karl presented; but I think we can draw the line here. Harvey> I'd just hate to see it proliferate - it'd enhance the Harvey> manuals at the expense of the code comments themselves. That would be bad, yes. I still think, that an occasional does not make the comments unreadable. Harvey> We have SGML markup in comments, namely: [...] Harvey> software/scwm/scwm/miscprocs.c:380: Return the Harvey> $PREFIX directory path that scwm was Harvey> installed with.. This is another thing that can reasonably be picked up by heuristic. Will there ever be words prefixed by a dollar sign not meaning environment variables? I guess not. Harvey> We also have non-escaped SGML special characters: Harvey> software/scwm/scwm/binding.c:933: Return the mapping of Harvey> physical->logical pointer buttons as a list.. '>' is not a special character - or need not be. Only '<' and '&' have to be escaped. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 10 03:53:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA02540 for scwm-discuss-outgoing; Mon, 10 Aug 1998 03:53:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA02535 for ; Mon, 10 Aug 1998 03:53:37 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA03363 for scwm-discuss@huis-clos.mit.edu; Mon, 10 Aug 1998 09:53:09 +0200 (CEST) Received: (qmail 1753 invoked by uid 115); 9 Aug 1998 16:37:49 -0000 To: scwm-discuss@mit.edu Subject: fBorder X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Aug 1998 18:37:47 +0200 Message-ID: Lines: 17 X-Mailer: Gnus v5.6.21/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, what are the exact semantics of fBorder? Should it be set to false whenever I set the border width to zero? What happens now is that it stays true, and the psw->sides[] windows are resized to zero width or height, which is illegal. I suspect that at least one visual artifact stems from this. IMHO setting border width to zero should remove the sides and clear fBorder. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 10 10:57:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA04509 for scwm-discuss-outgoing; Mon, 10 Aug 1998 10:57:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA04506 for ; Mon, 10 Aug 1998 10:57:10 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08541; Mon, 10 Aug 98 10:56:57 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA02145; Mon, 10 Aug 1998 17:56:11 +0300 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 10 Aug 1998 17:56:10 +0300 In-Reply-To: hjstein@bfr.co.il's message of "09 Aug 1998 12:42:50 +0300" Message-Id: Lines: 30 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > In any case, at this point I'd just like to see a short, simple, > accurate description of what exactly the developers want to support in > their embedded documentation. Is it Tags + unescaped special > characters + `proc' + ARGUMENT, with tags stripped from docs for text > output, `proc' & ARGUMENT marked up for SGML output, unescaped > specials escaped for SGML output? Are there any particular spacing > conventions? What about tags otf to support those too? It seems like this is the current practice, and > I still think it's a bit too hacked up & that it's a pain in the ass > for the extracter. Would still like to see one... BTW, I just realized that `proc' is unnecessary. I think it might be better to just mark up every word matching the scheme-name of a subroutine. I can add that pretty easily to my extractor. That should be fine for scwm, although it could break pretty badly for guile - imagine marking up and, or, if, when, not, do, while, ... Maybe it'd be better to: - *only* mark up things otf `proc' & only if they match a scheme-name, and - issue a warning if `proc' doesn't match a scheme-name. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 10 11:38:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04727 for scwm-discuss-outgoing; Mon, 10 Aug 1998 11:38:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA04724 for ; Mon, 10 Aug 1998 11:38:43 -0400 Received: by tis.bellhow.com; id LAA12544; Mon, 10 Aug 1998 11:38:10 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma012178; Mon, 10 Aug 98 11:37:13 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA24772 for ; Mon, 10 Aug 1998 11:37:13 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: BUG: snapshot 1998 08 10 Date: Mon, 10 Aug 1998 15:33:14 GMT Organization: Bell & Howell PSC Message-ID: <35d507b8.1018985613@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA04725 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings! The 8/10/1998 snapshot fails to build. ./configure --prefix=$HOME --with-guile-prefix=$HOME && make && make install ... gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/openwin/include -I/home/users10/smithd/include -g -O2 -c add_window.c add_window.c:99: conflicting types for `CassowaryInitClVarsInPscreen' scwm-constraints.h:38: previous declaration of `CassowaryInitClVarsInPscreen' add_window.c:99: void CassowaryInitClVarsInPscreen(Screen *pscreen) { /* empty */ } scwm-constraints.h:38: void CassowaryInitClVarsInPscreen(struct ScreenInfo *pscreen); I changed `add_window.c' to be as `scwm-constraints.h': void CassowaryInitClVarsInPscreen(struct ScreenInfo *pscreen) { /* empty */ } I also got a couple of M_ERROR redefined warnings: gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/openwin/include -I/home/users10/smithd/include -g -O2 -c log-usage.c In file included from scwm.h:49, from log-usage.c:35: module-types.h:41: warning: `M_ERROR' redefined /usr/include/sys/stream.h:327: warning: this is the location of the previous definition BTW: I have never gotten scwm-bug to work in emacs yet. I started to poke at it, but I have other things (real work? :) ) that I need to do. Basically, `compose-mail' is not in emacs 19.3x. Probably just does the same thing that `mail' does, but I don't know. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Mon Aug 10 12:09:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA04916 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:09:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA04913 for ; Mon, 10 Aug 1998 12:09:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA00561; Mon, 10 Aug 98 12:09:03 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA14503; Mon, 10 Aug 1998 09:08:24 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 10 Aug 1998 09:08:24 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Aug 1998 18:18:24 +0200" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 09 Aug 1998 12:42:50 +0300 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > [Ripping out tags] > > Harvey> But, with the 2nd above short tag style it gets more > Harvey> complicated. > > Yes. In fact, I do not recommend the " unaesthetic in my view, and adds a special case. The first short form > "bar" could be a viable compromise, but even this alternative > may not be worth the work to support it. But keep in mind, our task is to write a source/scheme code extractor that generates DocBook. We have two choices: 1) permit some errors to show through to DocBook; or 2) redundantly do all the DTD reading and parsing of the document that DocBook will do, and catch errors in the markup at the front end. We do #1 now, and I think this is the better way to manage the documentation. DocBook is a source format, so it is reasonable to expect documentors to understand it (and it's pretty easy to understand). The extraction from source is just a convenience to better maintain the documentation, and to raise the level of abstraction in the documentation by making it a bit more scwm/scheme/guile-aware. n > Harvey> We also have non-escaped SGML special characters: > > Harvey> software/scwm/scwm/binding.c:933: Return the mapping of > Harvey> physical->logical pointer buttons as a list.. > > '>' is not a special character - or need not be. Only '<' and '&' have > to be escaped. And neither needs to be with the extractor if followed by a space. It'd be too annoying to have < interspersed. Greg From owner-scwm-discuss@mit.edu Mon Aug 10 12:22:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05068 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:22:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05065 for ; Mon, 10 Aug 1998 12:22:21 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA04509; Mon, 10 Aug 98 12:22:21 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbvt06184; Mon, 10 Aug 1998 16:21:48 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA29522; Mon, 10 Aug 1998 12:21:46 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: snapshot 1998 08 10 References: <35d507b8.1018985613@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of Mon, 10 Aug 1998 15:33:14 GMT Date: 10 Aug 1998 12:21:46 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35d507b8.1018985613@mailhost> >>>> Sent on Mon, 10 Aug 1998 15:33:14 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "BUG: snapshot 1998 08 10": >> BTW: >> I have never gotten scwm-bug to work in emacs yet. I started to poke at it, but I have >> other things (real work? :) ) that I need to do. Basically, `compose-mail' is not in >> emacs 19.3x. Probably just does the same thing that `mail' does, but I don't know. fixed. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Mon Aug 10 12:30:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05152 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:30:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05149 for ; Mon, 10 Aug 1998 12:30:10 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28706; Mon, 10 Aug 98 12:29:24 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA15029; Mon, 10 Aug 1998 09:29:32 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: fBorder References: From: Greg Badros Date: 10 Aug 1998 09:29:31 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Aug 1998 18:37:47 +0200" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > what are the exact semantics of fBorder? Should it be set to false > whenever I set the border width to zero? Ahh.. if only we knew. In some places in the code, yes, it'd be nice if a border_width of zero meant fBorder was false; in others, one would prefer that the two be kept orthogonal. Window decorating needs a big rewrite, and I'm getting a handle on how it should be done by fooling with the decoration code. I think trying to patch up the existing decoration code is futile, and will probably stop happening soon as we prepare for a big rewrite of that code. That'll permit dynamically-loadable decorating primitives. We just need to figure out what the right interface to the window decorations is. > > What happens now is that it stays true, and the psw->sides[] windows > are resized to zero width or height, which is illegal. I suspect that > at least one visual artifact stems from this. > IMHO setting border width to zero should remove the sides and clear > fBorder. Confusing terminology stuff: border width usually refers to the border_width of an X11 window (something the server knows about for each window). It is different from the Scwm boundary_width of the edges. I think this behaviour is improved lately. I've also added a no-side-decorations window style in my working tree, and will try adding a no-top-boundary-decoration window style so that we can get the NextStep look. The problem is that the changes are easy, but the testing is hard. (Main reason for my doing these recent decoration enhancements, though, is not to add the features, but to learn about the code in preparation for the redesign). Greg From owner-scwm-discuss@mit.edu Mon Aug 10 12:36:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05217 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:36:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from lava.obsidian.co.za (lava.obsidian.co.za [196.28.133.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA05210 for ; Mon, 10 Aug 1998 12:36:42 -0400 Received: from ra.obsidian.co.za ([192.168.2.1]) by lava.obsidian.co.za (8.8.5/8.8.5) with ESMTP id SAA11313 for ; Mon, 10 Aug 1998 18:35:54 +0200 Received: from localhost (psheer@localhost) by ra.obsidian.co.za (8.8.7/8.8.7) with SMTP id SAA24651 for ; Mon, 10 Aug 1998 18:38:04 +0200 Date: Mon, 10 Aug 1998 18:38:04 +0200 (SAST) From: Paul Sheer To: scwm-discuss@mit.edu Subject: Windows style Alt-Tabbing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi there The following patch allows for Windows 3.1/95 style alt-tabbing. I was really desperate for this feature. KDE seems to be the only WM that has this. (When I mean alt-tabbing, I mean the proper stack orientated alt-tabbing used by windows, where the focussed window comes to the top of the stack. This is not the same as the pseudo-alt-tabbing employed by fvwm. Press alt-tab and hold down the alt key while tabbing if you don't know what I mean. I don't know if this feature exists in the development versions.) Thanx, bye -paul begin 644 scwm-0.7a.patch.diff.gz M'XL("+D=SS4``W-C=VTM,"XW82YP871C:"YD:69F`*5:>5/C.!;_FWP*#5/% M.,2FH;CNZ MGM[Q>X>4..YT2HR$&$9$[22*W1=*8GOA&\V#8^M=;/FA1P^P([+?Q]CJGO=8Q:9V>GM0:C<;V&^YWHQZ0A7Y\^U4B_3R+&+4X)GU,"2HAHP,G"#1RV M@!>?B_YGNIPP*W)J1)O`D`%M\HOE>63WVKBW)KLULD.(YEG^Q+&(5J\9T(2. M@'[EAJ+UA':-.O-@TY<6T6N%.7.A_K]7JM(5?&<[90*PW/ MC;GATR"!-:)_1IE/>;0D/W-<0M9Q-19\D2ICSF:+VW/JTW>P+^X)"O6K>E^9 M4+7ORH15LW;:;YIU=771FB>]5JO7[.36[+;0F.*)MA2:<.C4#>B^$283S[5! M=M2>U&1,?MY#'6G"$K]H]3K1E!&P@6;3IJ[':63@#$.-21*@UY1,G0@"6D1>L>] M5J?7;>?0:[4Z^A%IX$L:BI#9W`0R)BZG3A)1;5G`3FCZQ_!MBJQ1_%UB%72\W2XJW@N?#? M@B:.K(T-R$IEA7AV.UU`9%'.1P/CT1>DR\)QZQRB!39B(\/TMEU:5NDJ+E&BQ%QI%KD,A.DA;`FW2]?*TDJ!T^T==@L%SN&A@)1XR1('T'0Y?/KU]\^D1T:4.E7?^XB0(#$D M8:A^L!+@Q&/!C.!V9LG"VA9@A[Z\8B"#KR&+P7?6^UU>,7QGX@J6\EJ%_!OK M8]=SRY%#,78-/@O/U&?3-;?,11T41M%'A0*/.RU,T_A*?1+_(@HA(""A[[K^ MB"Z&<'SHIV,3@"+"&9V#$!NX)$]_F%!-]^2,M.>"+8)*UW]Z:)X7EX`M`F&' MXF@@1O%,@$."N\-C-._QX8D.YA?E'I%,R3`,UGT/;*R[$ M(F*0%MG;PV@5+\685$]Z=OD>%R5I]&:Z._5BNB6%C7(H*[ZF'_9#@7QT"(BI M[\GU8/0POC^[?QB;H\'C\'YPW=^("F&GH[9`T=&1WND(.[VB*THGJS6N80.< M/`SP$]FO-03+V!C/6<3MA,<*\-K%,K!\UY8301DZ>1J@4Y)]\=()#/BDR')) M`%UX&28JQCP8FO[&.!CB(:8.Z/\;8A9\@4S/6<`CYH&G@#\_O! M13]=H!QAL\H+L;(A/0Y>^%^M5CI_1=F4IY`2^FNP@0-Y(62A)`Z[:6L-60=G M^R9/QVUY/.X>9PDQI3T^OZX98CDF`\O&9+#&W83C3!^M*+QGEVX4\[IRX(VK MA$/(12,^KR,[1+J)W6KZ,1SJ/&N)NFW*`N?\&M*^?R;(02^TS8?1Q>!R.$(U M"TDZQ_H)'O1/]%,EB<`,;B*JP5!F-8$<:$Z15Q$8`%/45S%+@R)[;H4QB5-/ M@2A>JB47@+,$X0MT0-,D0>IN+"C55?F(D;^L$@.)8X_*K?=,FF>;:"[A4:") M&DL1^G=H%LA(VJ^9MF0IU(.L*B7TK6/LBI!^%)>CLCS0C'A%\JG7II"H.#B;H!EKB$["GZ9ESV] MDM.2U9COOQ%3LNR8!L2U.081*T.LON?'^EXQ261DT#ZXS=OA0-@LKPIDLZ1U M)PD]U[80=M8$,K"(9#O_+);O2-:DE#^]+Y=#*0]$%-6F'\^TQ[.[D6Z:EP^C M\_OAS<@T]5V%+S@[<"98>!<*YVXJ]C0_P,CYD M_7TU<<8`;Z@[WO!OY#76:1NQWVH?=BH1%3Z\,->I&;1(\F_@=B.D#R*P9->?J(BEC5FY3P/;%GZ.SZ^&YT(5Y6YA83^%9B!^0AD0N M4L=SD)U,+.>CRDH$\U42FFC$G)`NDNGGFYLK$^V)*"OGKC3$K5^L[@9?50F/ MM&[O;LZUV,SGZ[OBL_C.91L$S$8\J,`Q^SO2 M0<#"2Y42+P9W@TMS>&F._[S^?'.EI3+*2/R3,J7HS:P(*C47$0MF)E^&U+2B MF5;5&LGIO*951DDK&`4S8]ZKHJ,BMKPS4O4$WN@F_H1&9J@5U5:7%B\I!>8" MCVU05FEJOU(XS-D"T!Z0!26<>AYN@Z53N6YR@Q?V3"56;>;[H,X4I)6(!JJ2 MBM*Q_-57W7RK^9F/JU):EH_CV\'Y\'*(!:0`[Q;76_*VS"@GD>L0)LO8"SJET>`KR"=" MX\R*($!0G4P2O#*%X]0Q]``*9$$]H M78'24(%QY2LGK9Z>X5JGAUWQW=GIX:'>;9>W!7J)QQ6QAB#5V/1MDY9>>XP! M?O(6E.QS'4[VL"`+ET$Z':,EU!/R):[9U8B8BMM)!M29;7!SI:X"L'4W@!/< MX`[KO3%TX[T^2[)?"\2D1^1Q?,HBH@D2=G2`?.$]]@%>_/7%J1C+6OB(,[CQ M`?NSXU'&:*.A3CHJ]&4#V=0B]T`I%]$@K3Z&.(=.+1`E3D^08#,.Q2>#)P0, M`$(]_3HBO47`WPZ\AS.4YS&;:+'[7PINJ!4U"R?&?*<6>?[E?<$BJ M%%@#`PN&81?Z-8T$0ER,QXKG7L:U5)"6!+$["Z@CKKOK1&27:B(`5#WZ?HG$\#,Y!?%T-UHO0>,VCQ=G5U_7'$8588B%]9G8@`CR^9WY5,^!L&$)\E ED4TS.;-B>C5C]&4&V!S_L_7KE-B70^7?"11&_P^:>$:1`B<````` ` end Obsidian Systems . . . . Linux installations, support, networking info@obsidian.co.za . . . . . . . . . . . . Tel (+27 11) 792 6500 http://www.obsidian.co.za . . . . . . . . Fax (+27 11) 792 6522 __ __ __ __ __ __ __ __ / / / // |/ // / / / \ \/ / / /_ / // /| // /_/ / \ / /___//_//_/ |_/ \____/ / \ /_/\_\ From owner-scwm-discuss@mit.edu Mon Aug 10 12:37:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05230 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:37:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from lava.obsidian.co.za (lava.obsidian.co.za [196.28.133.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA05227 for ; Mon, 10 Aug 1998 12:37:31 -0400 Received: from ra.obsidian.co.za ([192.168.2.1]) by lava.obsidian.co.za (8.8.5/8.8.5) with ESMTP id SAA11320 for ; Mon, 10 Aug 1998 18:36:51 +0200 Received: from localhost (psheer@localhost) by ra.obsidian.co.za (8.8.7/8.8.7) with SMTP id SAA24655 for ; Mon, 10 Aug 1998 18:39:01 +0200 Date: Mon, 10 Aug 1998 18:39:01 +0200 (SAST) From: Paul Sheer To: scwm-discuss@mit.edu Subject: Re: Windows style Alt-Tabbing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk BTW I am not on the mailing list. -paul From owner-scwm-discuss@mit.edu Mon Aug 10 12:42:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05335 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:42:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05332 for ; Mon, 10 Aug 1998 12:42:16 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA09859; Mon, 10 Aug 98 12:42:16 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA02684; Mon, 10 Aug 1998 19:41:31 +0300 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 10 Aug 1998 19:41:31 +0300 In-Reply-To: Greg Badros's message of "10 Aug 1998 09:08:24 -0700" Message-Id: Lines: 21 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > Harvey> We also have non-escaped SGML special characters: > > > > Harvey> software/scwm/scwm/binding.c:933: Return the mapping of > > Harvey> physical->logical pointer buttons as a list.. > > > > '>' is not a special character - or need not be. Only '<' and '&' have > > to be escaped. Ok. > And neither needs to be with the extractor if followed by a space. It'd > be too annoying to have < interspersed. So what exactly are the rules? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 10 12:59:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05657 for scwm-discuss-outgoing; Mon, 10 Aug 1998 12:59:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05654 for ; Mon, 10 Aug 1998 12:59:13 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06148; Mon, 10 Aug 98 12:58:27 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA15947; Mon, 10 Aug 1998 09:58:35 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Documentation conventions refocusing... References: <7upvee8q2g.fsf@olivia.aibon.ping.de> From: Greg Badros Date: 10 Aug 1998 09:58:35 -0700 In-Reply-To: hjstein@bfr.co.il's message of "10 Aug 1998 19:41:31 +0300" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Ok. > > > And neither needs to be with the extractor if followed by a space. It'd > > be too annoying to have < interspersed. > > So what exactly are the rules? This is what I do. Other <'s make it into the output as tag beginnings. $markup_usage =~ s%(\s+)<(\s+)%$1<$2%g; $markup_usage =~ s%(\s+)>(\s+)%$1>$2%g; Sorry so brief-- gotta run. G From owner-scwm-discuss@mit.edu Mon Aug 10 13:52:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA06022 for scwm-discuss-outgoing; Mon, 10 Aug 1998 13:52:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA06019 for ; Mon, 10 Aug 1998 13:52:05 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28679; Mon, 10 Aug 98 13:52:04 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA17269; Mon, 10 Aug 1998 10:51:17 -0700 (PDT) To: Paul Sheer Cc: scwm-discuss@mit.edu Subject: Re: Windows style Alt-Tabbing References: From: Greg Badros Date: 10 Aug 1998 10:51:14 -0700 In-Reply-To: Paul Sheer's message of "Mon, 10 Aug 1998 18:38:04 +0200 (SAST)" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Paul Sheer writes: > The following patch allows for Windows 3.1/95 style alt-tabbing. I was > really desperate for this feature. KDE seems to be the only WM that has > this. > > (When I mean alt-tabbing, I mean the proper stack orientated alt-tabbing > used by windows, where the focussed window comes to the top of the stack. > This is not the same as the pseudo-alt-tabbing employed by fvwm. Press > alt-tab and hold down the alt key while tabbing if you don't know what I > mean. I don't know if this feature exists in the development versions.) > > Thanx, bye Thanks! Couple of things: 1) text-patches are better for most dev lists -- it's just easier to get a sense of the patch by looking at the email (if your mailer is going to screw up line breaks, then uuencoding is your only option -- short of switching mailers [which you might want to consider if your mailer is *that* broken]). 2) More recent scwm-s do have a primitive that gives the windows in their stacking order. We'll probably end up providing this functionality in some different way -- I'm not convinced that the patch does exactly the right thing (and if it doesn, it relies on undocumented behaviour about the internal linked-list of windows). It would make more sense to have a last-focussed time attribute with each window, and then just sort on that. 3) What exactly are you doing in the menuing code? A high level description of the intent of those changes would be nice. Thanks for your interest in Scwm! We'll certainly figure out a way to improve the circulation behaviour. Greg From owner-scwm-discuss@mit.edu Mon Aug 10 14:33:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA06275 for scwm-discuss-outgoing; Mon, 10 Aug 1998 14:33:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA06272 for ; Mon, 10 Aug 1998 14:33:23 -0400 Received: from lava.obsidian.co.za by MIT.EDU with SMTP id AA00766; Mon, 10 Aug 98 14:32:33 EDT Received: from ra.obsidian.co.za ([192.168.2.1]) by lava.obsidian.co.za (8.8.5/8.8.5) with ESMTP id UAA12288; Mon, 10 Aug 1998 20:32:38 +0200 Received: from localhost (psheer@localhost) by ra.obsidian.co.za (8.8.7/8.8.7) with SMTP id UAA25059; Mon, 10 Aug 1998 20:34:54 +0200 Date: Mon, 10 Aug 1998 20:34:54 +0200 (SAST) From: Paul Sheer To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Windows style Alt-Tabbing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > 1) text-patches are better for most dev lists -- it's just easier to get > a sense of the patch by looking at the email (if your mailer is going to > screw up line breaks, then uuencoding is your only option -- short of > switching mailers [which you might want to consider if your mailer is > *that* broken]). Yep, I'm looking for a mailer I like. > > 2) More recent scwm-s do have a primitive that gives the windows in > their stacking order. We'll probably end up providing this > functionality in some different way -- I'm not convinced that the patch > does exactly the right thing (and if it doesn, it relies on undocumented > behaviour about the internal linked-list of windows). It would make > more sense to have a last-focussed time attribute with each window, and > then just sort on that. True, but I was desperate to have Alt-Tabbing working TODAY :-) The internal workings of none of your functions is documented - list_all_and_reorder_windows is just a new function. What we DON'T want is the windows in their stacking order. We want windows in their order of last focussed. Behaviourily, the patch does EXACTLY the right thing. I am using it right now and it works beautifully :-) > > 3) What exactly are you doing in the menuing code? A high level > description of the intent of those changes would be nice. zimply put: 1 - tab activates 2 - window linked list is reordered so that the currently focussed window is at the top of the list (list_all_and_reorder_windows is just like list_all_windows but shoots the current window to the top of the list). 3 - menu is drawn and warps to menu item 3 which is the window just before the currently focussed window in the list 4 - use tab to cycle to the window you want in the menu (tab can also wrap from the bottem of the menu to the top) 5 - lifting the alt key focusses on that window. (Its a pretty clean patch. Although I agree there is probably a more generalised may to impliment it. Since the change is small, you might add it anyway, until a more generalised spec is thought up.) Hence Alt-Tab-unAlt goes to the previously focussed window. Alt-Tab-Tab-unAlt goes to the one even before that. Just like windoze. Also found a bug: my patch should read - + if (n_windows) { + focus_window = 0; /* defaults to the first (most recent) window */ + all = malloc (sizeof (ScwmWindow *) * n_windows); Also: Some lisp functions that don't warp should be written, so that normal button-three clicks behave as before. Many thanks -paul (PS proper alt tabbing is really essential for my mental well being!) From owner-scwm-discuss@mit.edu Mon Aug 10 16:46:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA07128 for scwm-discuss-outgoing; Mon, 10 Aug 1998 16:46:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA07125 for ; Mon, 10 Aug 1998 16:46:09 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA06068; Mon, 10 Aug 98 16:45:21 EDT Received: from 192.168.1.1 (root@PPP24.tokyo-ap4.dti.ne.jp [210.170.145.90]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id FAA08609 for ; Tue, 11 Aug 1998 05:45:32 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id FAA13203 for ; Tue, 11 Aug 1998 05:45:30 +0900 Message-Id: <199808102045.FAA13203@192.168.1.1> To: scwm-discuss@mit.edu Subject: I have a few problems... Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Tue, 11 Aug 1998 05:45:29 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, all. I have 3 problems with scwm, and 2 of them are rather critical. I can't see why this happen. It may have something to do with I18N functionality, so I just want to hear other people's experience. Problem 1: Some times, scwm just dies. This seems to happen when window mapped. Mostly, GNOME application's dialog pop-up. But situation looks random. Problem 2: scwm just hangs. scwm eats much CPU time, and never return. I can't specify situation of this. Some time, resizing window, and other time just move pointer one window to other. Problem 3(minor problem): Invoking fvwm2-module, I get message `Error evaling packet: (0 15 "Send_WindowList" 1)'. Some windows are not displayed in Pager, until I resize, or move not displayed window. Have you ever had this kind of problems with recent snapshots? I suppose this may have something to do with I18N codes, or running guile in `setlocale'-ed environment. I changed guile 19980627 up to 19980806 version, but still have these troubles. Sorry for ambiguous information, but my ability to write English is so poor... :-( -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Mon Aug 10 17:31:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07368 for scwm-discuss-outgoing; Mon, 10 Aug 1998 17:31:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA07362 for ; Mon, 10 Aug 1998 17:30:55 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA15888; Mon, 10 Aug 98 17:30:06 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id RAA02826; Mon, 10 Aug 1998 17:30:00 -0400 (EDT) Message-Id: <199808102130.RAA02826@jekyll.piermont.com> To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: I have a few problems... In-Reply-To: Your message of "Tue, 11 Aug 1998 05:45:29 +0900." <199808102045.FAA13203@192.168.1.1> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Aug 1998 17:30:00 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > Problem 1: > Some times, scwm just dies. This seems to happen when window > mapped. Mostly, GNOME application's dialog pop-up. But situation > looks random. > > Problem 2: > scwm just hangs. scwm eats much CPU time, and never return. I > can't specify situation of this. Some time, resizing window, and > other time just move pointer one window to other. I've had both of these things happen. I've also had it die on startup at random. I chalk it all up to the program being very young and very buggy. Given that I signed up to use a very young and very buggy program, I don't mind too much -- I feel it is sort of my responsibility to find the bugs. When a new (0.8) version comes out and there is better internal documentation I'll probably start hunting for them myself. > Sorry for ambiguous information, but my ability to write English is > so poor... :-( Far better than our ability to write Japanese. Perry From owner-scwm-discuss@mit.edu Mon Aug 10 18:13:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA07595 for scwm-discuss-outgoing; Mon, 10 Aug 1998 18:13:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA07592 for ; Mon, 10 Aug 1998 18:13:13 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA11600; Mon, 10 Aug 98 18:13:09 EDT Received: from 192.168.1.1 (root@PPP24.tokyo-ap4.dti.ne.jp [210.170.145.90]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id HAA12447 for ; Tue, 11 Aug 1998 07:12:31 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id HAA14515 for ; Tue, 11 Aug 1998 07:12:29 +0900 Message-Id: <199808102212.HAA14515@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102130.RAA02826@jekyll.piermont.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: "Perry E. Metzger"'s message of "Mon, 10 Aug 1998 17:30:00 -0400" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Tue, 11 Aug 1998 07:12:28 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I've had both of these things happen. I've also had it die on startup > at random. I'm happy to hear this ;-) If these were caused by I18N stuff, I would have to avoid using it in scwm. I'll investigate the source too, when I have time to do. > > Sorry for ambiguous information, but my ability to write English is > > so poor... :-( > > Far better than our ability to write Japanese. FYI, it's far more difficult to write Japanese, than speak. :) -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Mon Aug 10 18:33:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA07725 for scwm-discuss-outgoing; Mon, 10 Aug 1998 18:33:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA07722 for ; Mon, 10 Aug 1998 18:33:28 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA27490; Mon, 10 Aug 98 18:32:34 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id BAA04317; Tue, 11 Aug 1998 01:32:20 +0300 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Mostly working extract.scm Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 11 Aug 1998 01:32:19 +0300 In-Reply-To: Greg Badros's message of "10 Aug 1998 10:51:14 -0700" Message-Id: Lines: 1199 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk This one should mostly work. I added markup of the extracted comments, using for upper case words matching arguments & for things otf `proc'. I also feed the exception words directly to ispell, and added a command line arg for adding additional exception words. I think this version basically does everything it needs to do. #!/bin/sh exec guile -l $0 -- --run-from-shell "$@" !# ;;; extract.scm ;;; Copyright (C) 1998, Harvey J. Stein, hjstein@bfr.co.il ;;; 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 ;;; the Free Software Foundation; either version 2, or (at your option) ;;; any later version. ;;; ;;; This program is distributed in the hope that it will be useful, ;;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;;; GNU General Public License for more details. ;;; ;;; You should have received a copy of the GNU General Public License ;;; along with this software; see the file COPYING.GPL. If not, write to ;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330, ;;; Boston, MA 02111-1307 USA ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_args, ;;; another_number, ;;; another_number, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with /** spaces identifier: & ends with */, but is not ;;; preceeded by a SCWM_PROC. ;;; Usage: ;;; Parsing: ;;; (extract-docs-from-files f1.c f2.c ...) ;;; Returns a list of doc records extracted documentation from the listed ;;; files. Each record is either (DOC doclist-record filename linenumber) ;;; or (SCWM_PROC procdoc-record filename linenumber). ;;; A procdoc-record is a list otf: ;;; (proc-record doclist-record) ;;; A proc-record is a list otf: ;;; (c_name "scheme_name" number_of_args another_number another_number ((SCM arg1) (SCM arg2) ...)) ;;; A doclist-record is a list of strings otf: ;;; (line1 line2 line3 ...) ;;; ;;; Checking docs are well formed: ;;; (check-docs doclist) ;;; Verifies stuff such as number of args = args ;;; in argslist, all args are SCM types, each arg is mentioned in ;;; the documentation, etc. ;;; ;;; Generating procedures-list documentation: ;;; (docs->proclist doclist) ;;; Output procedures-list stuff ;;; ;;; Generating sgml output: ;;; (docs->sgml doclist) ;;; Does various passes on the extract-docs-from-files output to ;;; generate the sgml output. ;;; ;;; Note: ;;; 1. Miscellaneous breaking of abstraction layers needs to be fixed ;;; - need make-proc-record, make-doc-record, ... & need to remove ;;; usage of car/list-ref/cdr/... on these things (if I'm doing this). ;;; 2. Too much hacking has lead to a need for some code cleanup. ;;; 3. Still can't load slib stuff without stupid hacks that should ;;; have been dealt with when guile installed. (if (not (member "/usr/lib" %load-path)) (set! %load-path (cons "/usr/lib" %load-path))) ; HACK for guile to find slib!!!!!!! (use-modules (ice-9 regex) ; For regexp-quote & substitute. (ice-9 slib)) ; For sort. (require 'sort) (define proc-start-match (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\(")) (define doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]*([^ \t:*]*:.*)")) ; spaces /**[^space or *] (define post-proc-doc-start-match (make-regexp "^[ \t]*/\\*\\*[ \t]+(.*)")) ; spaces /** space+ (define func-name-match (make-regexp "^[ \t]*#[ \t]*define[ \t]+FUNC_NAME[ \t]+([^ \t]*)[ \t]*$")) (define doc-end-match (make-regexp "[ \t]*\\*/[ \t]*")) ; Strip off spaces */ spaces (define (proc:c-name procrec) (list-ref procrec 0)) (define (proc:scheme-name procrec) (list-ref procrec 1)) (define (proc:required-args procrec) (list-ref procrec 2)) (define (proc:optional-args procrec) (list-ref procrec 3)) (define (proc:extra-var-args procrec) (list-ref procrec 4)) (define (proc:args procrec) (list-ref procrec 5)) (define (procdoc:decl procdocrec) (list-ref procdocrec 0)) (define (procdoc:doc procdocrec) (list-ref procdocrec 1)) (define (procdoc:funcname procdocrec) (list-ref procdocrec 2)) (define (docitem:type rec) (list-ref rec 0)) (define (docitem:data rec) (list-ref rec 1)) (define (docitem:file rec) (list-ref rec 2)) (define (vdocitem:decl rec) (procdoc:decl (docitem:data rec))) (define (vdocitem:scheme-name rec) (proc:scheme-name (vdocitem:decl rec))) (define (vdocitem:c-name rec) (proc:c-name (vdocitem:decl rec))) (define (vdocitem:args rec) (proc:args (vdocitem:decl rec))) (define (docitem:line rec) (list-ref rec 3)) (define (doc:chapter rec) (list-ref rec 0)) (define (doc:section rec) (list-ref rec 1)) (define (doc:doc rec) (list-ref rec 2)) (define (counting-read-line p) (set-port-line! p (1+ (port-line p))) (read-line p)) ;;; Output procedures-list document. (define (docs->proclist l) (for-each proc->list (sort (select-type 'SCWM_PROC l) scheme-name-ci=2 identical scheme names. (let loop ((spl (group (sort (select-type 'SCWM_PROC docitemlist) scheme-name=2 identical proc names - compiler will catch it. ) ;;; Complains about docitem recs it doesn't like (define (check-docitem procdocrec) (let* ((data (docitem:data procdocrec)) (file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (case (docitem:type procdocrec) ((DOC) ;; Check that DOC has a nonempty chapter name. (if (not (doc:chapter data)) (complain file line "Untagged embedded documentation")) ;; Check that DOC has a nonempty section name. (if (string=? "" (doc:section data)) (complain file line "Empty section heading")) ;; Check that DOC doc has nonempty documentation. (if (null? (doc:doc data)) (complain file line "Empty documentation"))) ;; Check that DOC doc identifier is HOOK or CONCEPT? ((SCWM_PROC) (let ((procrec (procdoc:decl data)) (docrec (procdoc:doc data)) (funcname (procdoc:funcname data))) ;; Check c-name vs scheme-name. (if (and (not (string=? (c-ident->scheme-ident (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec))) (not (string=? (c-name->scheme-name (symbol->string (proc:c-name procrec))) (proc:scheme-name procrec)))) (complain file line "Scheme name of " (proc:scheme-name procrec) " doesn't match a C name of " (proc:c-name procrec))) ;; What's this business about the 1st doc line being a "purpose" sentence? ;; What's this business about "leading spaces" being omitted? ;; Check that arg 2+3+4 = length of arg5 (if (not (= (+ (proc:required-args procrec) (proc:optional-args procrec) (proc:extra-var-args procrec)) (length (proc:args procrec)))) (complain file line "Argument count mismatch in " (proc:scheme-name procrec))) ;; Warn about var param != 0 or 1. (if (and (not (= (proc:extra-var-args procrec) 0)) (not (= (proc:extra-var-args procrec) 1))) (complain file line "Var count is not 0 and is not 1")) ;; Check that all args are of type SCM (let loop ((i 1) (args (proc:args procrec))) (cond ((null? args)) ((eq? (caar args) 'SCM) (loop (1+ i) (cdr args))) (else (complain file line "In the declaration for " (proc:scheme-name procrec) ", argument " i " (" (cadar args) ") is not of type SCM")))) ;; Check that the proc is documented: (if (null? docrec) (complain file line "Procedure " (proc:scheme-name procrec) " is not documented")) ;; Check that each arg appears in upper case in description. (let next-arg ((argregexp (map (lambda (arg) (delimited-regexp (string-upcase! (c-name->scheme-name (symbol->string (cadr arg)))))) (proc:args procrec))) (args (map cadr (proc:args procrec))) (i 1)) (cond ((null? args)) (else (let next-docline ((doc docrec)) (cond ((null? doc) (complain file line "Argument " i " (" (car args) ") of " (proc:scheme-name procrec) " is undocumented")) ((regexp-exec (car argregexp) (car doc))) (else (next-docline (cdr doc))))) (next-arg (cdr argregexp) (cdr args) (+ i 1))))) ;; Check for upper case words that don't match args. (let ((args (map (lambda (arg) (string-upcase! (c-name->scheme-name (symbol->string (cadr arg))))) (proc:args procrec)))) (for-each (lambda (word) (if (and (upper-case? word) (> (string-length word) 1) (not (all-special? word)) (not (member word args))) (complain file line "Documentation for procedure " (proc:scheme-name procrec) " contains upper case word " word " which isn't an argument"))) (apply append (map extract-words docrec)))) ;; Check that there's a func_name & it matches the c-name (if funcname (if (not (string=? (string-append "s_" (symbol->string (proc:c-name procrec))) funcname)) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a matching FUNC_NAME")) (complain file line "Procedure " (proc:scheme-name procrec) " doesn't have a FUNC_NAME")))) (else (complain file line "Internal error - unrecognized doc record type."))))) (define (upper-case? s) (let loop ((i 0) (l (string-length s))) (cond ((>= i l) #t) ((and (not (char-upper-case? (string-ref s i))) (char-lower-case? (string-ref s i))) #f) (else (loop (1+ i) l))))) (define (all-special? s) (let loop ((i 0) (l (string-length s))) (cond ((>= i l) #t) ((and (not (char-upper-case? (string-ref s i))) (not (char-lower-case? (string-ref s i)))) (loop (1+ i) l)) (else #f)))) (define (extract-words s) (define (skip i l result) (cond ((>= i l) result) ((delimiter? (string-ref s i)) (skip (1+ i) l result)) (else (grab i (1+ i) l result)))) (define (grab start end l result) (cond ((>= end l) (cons (substring s start end) result)) ((delimiter? (string-ref s end)) (skip (1+ end) l (cons (substring s start end) result))) (else (grab start (1+ end) l result)))) (skip 0 (string-length s) '())) (define (delimiter? c) (case c ((#\: #\space #\tab #\+ #\= #\\ #\| #\{ #\} #\[ #\] #\' #\` #\" #\: #\; #\. #\/ #\< #\> #\@ #\# #\% #\^ #\& #\* #\( #\) #\,) #t) (else #f))) (define (c-ident->scheme-ident s) (define to-regexp (make-regexp "_to_")) (define (to->-> s) (let ((match (regexp-exec to-regexp s))) (if match (regexp-substitute #f match 'pre "->" 'post) s))) (c-name->scheme-name (to->-> s))) (define (c-name->scheme-name s) (let* ((normname (map (lambda (c) (if (char=? c #\_) #\- c)) (string->list s))) (revname (reverse normname))) (cond ((or (null? revname) (null? (cdr revname))) (list->string normname)) ((and (char=? (car revname) #\p) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\? (cddr revname))))) ((and (char=? (car revname) #\x) (char=? (cadr revname) #\-)) (list->string (reverse (cons #\! (cddr revname))))) (else (list->string normname))))) (define (delimited-case-insensitive-regexp s) (let ((ci-name (regexp-quote s))) (make-regexp (string-append "[ \t'`.,:\"]" ci-name "[ \t'`.,:\"]|" "^" ci-name "[ \t'`.,:\"]|" "[ \t'`.,:\"]" ci-name "$|" "^" ci-name "$") regexp/icase))) (define (delimited-regexp s) (unsafe-delimited-regexp (regexp-quote s))) (define (unsafe-delimited-regexp ci-name) (make-regexp (string-append "[ \t'`.,:\"]" ci-name "[ \t'`.,:\"]|" "^" ci-name "[ \t'`.,:\"]|" "[ \t'`.,:\"]" ci-name "$|" "^" ci-name "$"))) ;;; ispell crap (define (ispell-start) (system "rm /tmp/ispell-input 2>/dev/null") (system "mkfifo /tmp/ispell-input 2>/dev/null") (let ((ispell-out (open-input-pipe "ispell -a string (let loop ((s (cddr (string->list s)))) (cond ((null? s) '()) ((char=? (car s) #\space) '()) (else (cons (car s) (loop (cdr s)))))))) (define (ispell-stop ports) (close-port (car ports)) (close-pipe (cdr ports)) (system "rm /tmp/ispell-input 2>/dev/null")) (define (ispell-docs docs) (let ((p '())) (dynamic-wind (lambda () (set! p (ispell-start)) (ispell-ignore *scwm-ok-words* p)) (lambda () (for-each (lambda (rec) (ispell-complain rec p)) docs)) (lambda () (ispell-stop p))))) (define (ispell-complain rec p) (for-each (lambda (complaint) (complain (docitem:file rec) (docitem:line rec) (car complaint) (cdr complaint))) (apply append (map (lambda (line) (ispell-report (ispell-send line p))) (docitem->plaintextlist rec))))) (define (ispell-escape s) (string-append "^" s)) ;;; Outputs procdocrec in format suitable for a procedures-list document. (define (proc->list procdocrec) (if (eq? 'SCWM_PROC (docitem:type procdocrec)) (let ((procrec (procdoc:decl (docitem:data procdocrec))) (docrec (procdoc:doc (docitem:data procdocrec)))) (display (function-call-decl procrec)) (newline) (for-each (lambda (docline) (display docline) (newline)) docrec) (displayl "[From " (docitem:file procdocrec) ":" (docitem:line procdocrec) "]\n\n\f\n")))) (define (function-call-decl procrec) (apply string-append "(" (proc:scheme-name procrec) (let loop ((args (map (lambda (a) (c-name->scheme-name (symbol->string (cadr a)))) (proc:args procrec))) (req (proc:required-args procrec)) (opt (proc:optional-args procrec)) (rest (proc:extra-var-args procrec))) (cond ((null? args) '(")")) ((> req 0) (cons " " (cons (car args) (loop (cdr args) (- req 1) opt rest)))) ((and (= req 0) (> opt 0)) (cons " #&optional" (loop args (- req 1) opt rest))) ((and (< req 0) (> opt 0)) (cons " " (cons (car args) (loop (cdr args) req (- opt 1) rest)))) ;; Now know req <= 0 & opt <= 0. ((> rest 0) (cons " . " (cons (car args) (loop (cdr args) req opt 0)))) (else (cons " " (cons (car args) (loop (cdr args) -1 0 0)))))))) ;;; Output doc record in format suitable for ispell: (define (docitem->plaintext procdocrec) (let* ((file (docitem:file procdocrec)) (line (docitem:line procdocrec))) (for-each (lambda (d) (complain file line d)) (docitem->plaintextlist procdocrec)))) (define (docitem->plaintextlist procdocrec) (case (docitem:type procdocrec) ((SCWM_PROC) (procdoc:doc (docitem:data procdocrec))) ((DOC) (doc:doc (docitem:data procdocrec))) (else (complain (docitem:file procdocrec) (docitem:line procdocrec) "Internal error - unrecognized doc record type of " (docitem:type procdocrec)) '()))) (define (docs->text docs) (for-each (lambda (rec) (for-each (lambda (d) (displayl d "\n")) (docitem->plaintextlist rec))) docs)) (define (docs->annotated-text docs) (for-each docitem->plaintext docs)) ;;; Extract docs from specified files. Return list of procdoc ;;; records. (define (extract-docs-from-files . files) (let loop ((defs '()) (files files)) (cond ((null? files) (reverse defs)) (else (loop (call-with-input-file (car files) (lambda (p) (extract-docs-from-port p defs))) (cdr files)))))) ;;; Extract docs from specified input port. (define (extract-docs-from-port p . start) (let ((filename (port-filename p))) (let loop ((line (counting-read-line p)) (defs (if (null? start) '() (car start)))) (if (eof-object? line) defs (let* ((proc (regexp-exec proc-start-match line)) (docstart (or proc (regexp-exec doc-start-match line))) (linenum (port-line p))) (cond (proc (let ((doc (extract-proc-n-doc line p))) (cond (doc (loop (counting-read-line p) (cons (list 'SCWM_PROC doc filename linenum) defs))) (else (complain filename linenum "SCWM_PROC not parsable") (loop (counting-read-line p) defs))))) (docstart (let ((doc (parse-doc (extract-doc p line)))) (loop (counting-read-line p) (cons (list 'DOC doc filename linenum) defs)))) (else (loop (counting-read-line p) defs)))))))) (define (next-non-whitespace-line p) (define whitespace-line (make-regexp "^[ \t]*$")) (let ((line (counting-read-line p))) (if (or (eof-object? line) (regexp-exec whitespace-line line)) (next-non-whitespace-line p) line))) (define (extract-proc-n-doc line p) (let* ((proc (parse-proc (match-parentheses line p))) (next (counting-read-line p))) (cond ((not proc) ; Proc not parsable #f) ((eof-object? next) ; No doc & no func (list proc '() #f)) ((regexp-exec post-proc-doc-start-match next) ; Doc is first. (let* ((doc (extract-doc p next post-proc-doc-start-match)) (next (next-non-whitespace-line p)) (match (if next (regexp-exec func-name-match next) #f))) (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f)))) (else (let* ((match (regexp-exec func-name-match next)) ; Func name must be next. (next (next-non-whitespace-line p)) (doc (extract-doc p next post-proc-doc-start-match))) ; Then the docs. (if match (list proc doc (substring (vector-ref match 0) (car (vector-ref match 2)) (cdr (vector-ref match 2)))) (list proc doc #f))))))) (define (extract-doc p . xargs) (define (doclist lines) lines) (define (extract-to-end lines) (if (eof-object? (car lines)) (doclist (reverse lines)) (let ((end (regexp-exec doc-end-match (car lines)))) (if end (doclist (reverse (cons (substring (car lines) 0 (car (vector-ref end 1))) (cdr lines)))) (extract-to-end (cons (counting-read-line p) lines)))))) (let ((line (if (null? xargs) (counting-read-line p) (car xargs))) (doc-start-match (if (or (null? xargs) (null? (cdr xargs))) doc-start-match (cadr xargs)))) (if (eof-object? line) '() (let ((start (regexp-exec doc-start-match line))) (if start (extract-to-end (list (substring line (car (vector-ref start 2)) (cdr (vector-ref start 2))))) '()))))) ;;; FIXME!!! This is dumb, but it probably works well enough. (define (match-parentheses line p) (dumb-match-parentheses line p)) (define (dumb-match-parentheses line p) (let loop ((umc (unmatched-p-count (string->list line))) (lines (list line))) (if (> umc 0) (let ((line (counting-read-line p))) (if (eof-object? line) (apply string-append (reverse lines)) (loop (+ umc (unmatched-p-count (string->list line))) (cons line lines)))) (apply string-append (reverse lines))))) (define (unmatched-p-count l) (let loop ((c 0) (l l)) (cond ((null? l) c) ((char=? (car l) #\() (loop (+ c 1) (cdr l))) ((char=? (car l) #\)) (loop (- c 1) (cdr l))) ((char=? (car l) #\") (loop c (skip-to-next-quote (cdr l)))) (else (loop c (cdr l)))))) (define (skip-to-next-quote l) (cond ((null? l) '()) ((char=? (car l) #\") (cdr l)) ((char=? (car l) #\\) ; Escaped quote. (if (and (not (null? (cdr l))) (char=? (cadr l) #\")) (skip-to-next-quote (cddr l)) l)) (else (skip-to-next-quote (cdr l))))) (define (parse-doc doclist) (define parser (make-regexp "^[ \t]*([^ \t:]*):[ \t]*(.*)[ \t]*$")) (cond ((null? doclist) '(#f '())) (else (let ((match (regexp-exec parser (car doclist)))) (list (match:substring match 1) (match:substring match 2) (cdr doclist)))))) (define (parse-proc defstring) (define parser (make-regexp "^[ \t]*SCWM_PROC[ \t]*\\([ \t]*([^, \t]*)[ \t]*,[ \t]*\"([^, \t]*)\"[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*([^, \t]*)[ \t]*,[ \t]*(\\([^)]*\\)[ \t]*)\\)[ \t]*$")) (let ((match (regexp-exec parser defstring))) (if match (let ((args (list->vector (cdr (split-match match))))) (list (string->symbol (vector-ref args 0)) (vector-ref args 1) (string->number (vector-ref args 2)) (string->number (vector-ref args 3)) (string->number (vector-ref args 4)) (let ((args (with-input-from-string (string-append "(" (replace-occurrences (vector-ref args 5) #\, ")(") ")") read))) (if (equal? args '(())) '() args)))) #f))) (define (replace-occurrences string char repl) (define (my-repl start end char srepl) (cond ((null? end) (list->string (reverse start))) ((char=? (car end) char) (my-repl (append srepl start) (cdr end) char srepl)) (else (my-repl (cons (car end) start) (cdr end) char srepl)))) (my-repl '() (string->list string) char (reverse (string->list repl)))) (define (split-match match) (map (lambda (startnend) (substring (vector-ref match 0) (car startnend) (cdr startnend))) (cdr (vector->list match)))) (define (stringify value) (with-output-to-string (lambda () (write value)))) (define (regexp-orlist l) (cond ((null? l) "") ((null? (cdr l)) (car l)) (else (string-append (car l) "|" (regexp-orlist (cdr l)))))) (define (arglist->argregexpstring l) (let ((r (string-append "(" (regexp-orlist (map (lambda (argspec) (regexp-quote (string-upcase! (c-name->scheme-name (cadr argspec))))) l)) ")"))) (string-append "([ \t'`.,:\"])" r "([ \t'`.,:\"])|" "(^)" r "([ \t'`.,:\"])|" "([ \t'`.,:\"])" r "($)|" "(^)" r "($)"))) (define (arglist->argregexp l) (make-regexp (arglist->argregexpstring l))) (define (proc->primitives-ssgml docitem) (let* ((data (docitem:data docitem)) (proc (procdoc:decl data)) (doc (procdoc:doc data)) (arglist (proc:args proc)) (argregexp (arglist->argregexp arglist))) `((refentry (id ,(proc:scheme-name proc))) ((refnamediv) ((refname) ,(proc:scheme-name proc)) ((refpurpose) ,(car doc))) ((refsynopsisdiv) ((synopsis) ,(function-call-decl proc))) ((refsect1) ((title) "Description") ((para) ,@(if (not (null? arglist)) (map (lambda (d) (markup-args argregexp d)) doc) '()))) ((refsect1) ((title) "Implementation Notes") ((para) "Defined in " ((ulink (url ,(docitem:file docitem))) ((filename) ,(docitem:file docitem))) ,(string-append " at line " (stringify (docitem:line docitem)) ".")))))) (define (markup-args argregexp s) (my-regexp-substitute/global #f argregexp s 'pre 1 "" (lambda (m) (string-downcase! (string-copy (match:good-substring m 2)))) "" 3 'post)) (define (proclist->primitives-chapter l) (make-chapter "Primitives in Alphabetical Order" (map proc->primitives-ssgml l))) (define (make-chapter name l) `((chapter) ((title) ,name) ,@l)) (define (lexcmp selectors) (lambda (x y) (if (null? selectors) #t (let* ((selector (car selectors)) (sel (list-ref selector 0)) (less (list-ref selector 1)) (eq (list-ref selector 2)) (a (sel x)) (b (sel y))) (or (less a b) (and (eq a b) ((lexcmp (cdr selectors)) x y))))))) (define (proclist->file-chapter procs) (let ((procs (group (sort procs (lexcmp (list (list (lambda (x) (docitem:file x)) stringargregexp args) (car doc)))))))))) procs-from-file)))) (define (emblist->ssgml docs) (let ((docs (group (sort docs (lexcmp (list (list (lambda (x) (doc:chapter (docitem:data x))) string-cissgml docs))) (define (embchapter->ssgml group) (make-chapter (doc:chapter (docitem:data (car group))) (map embsect->ssgml group))) (define (embsect->ssgml item) `((sect1 (id ,(doc:section (docitem:data item)))) ((title) ,(doc:section (docitem:data item))) ((para) ,@(doc:doc (docitem:data item))))) (define (docs->sgml frontpiece docs) (display "\n") (sgml (docs->ssgml frontpiece docs))) (define (docs->ssgml frontpiece docs) (let ((procs (sort (select-type 'SCWM_PROC docs) scheme-name-ciprimitives-chapter procs) ,(proclist->file-chapter procs) ,@(emblist->ssgml embdocs)))) (define (sgml-escape s) (list->string (let loop ((s (string->list s))) (cond ((null? s) '()) (else (case (car s) ((#\<) (append '(#\& #\l #\t #\;) (loop (cdr s)))) ((#\>) (append '(#\& #\g #\t #\;) (loop (cdr s)))) ((#\&) (append '(#\& #\a #\m #\p #\;) (loop (cdr s)))) (else (cons (car s) (loop (cdr s)))))))))) (define (my-regexp-substitute/global port rx string . items) ;; If `port' is #f, send output to a string. (if (not port) (call-with-output-string (lambda (p) (apply my-regexp-substitute/global p rx string items))) ;; Otherwise, compile the regexp and match it against the ;; string, looping if 'post is encountered in `items'. (let next-match ((str string)) ;; (displayl "My...: x" str "x\n") (let ((match (regexp-exec rx str))) ;; (displayl "My...: match " match "\n") (if (not match) (display str port) ;; Process all of the items for this match. (for-each (lambda (obj) (cond ((string? obj) (display obj port)) ((integer? obj) (display (match:good-substring match obj) port)) ((procedure? obj) (display (obj match) port)) ((eq? 'pre obj) (display (match:prefix match) port)) ((eq? 'post obj) (next-match (match:suffix match))) (else (error 'wrong-type-arg obj)))) items)))))) (define (match:good-substring match n) (do ((i 0 (1+ i))) ((< n 0) (match:substring match (1- i))) (if (not (equal? (vector-ref match (1+ i)) '(-1 . -1))) (set! n (1- n))))) (define (sgml-markup s) (define proc-regexp (make-regexp "`([^'` \t]*)'")) (my-regexp-substitute/global #f proc-regexp s `pre "" 1 "" `post)) ;;; Convert ssgml to sgml: (define (sgml form . depth) (if (null? depth) (set! depth '(0))) (cond ((string? form) (display (make-string (car depth) #\space)) (display (sgml-markup form)) (newline)) ((null? form) '()) (else (display (make-string (car depth) #\space)) (sgml-render-start (car form)) (for-each (lambda (f) (sgml f (+ (car depth) 3))) (cdr form)) (display (make-string (car depth) #\space)) (sgml-render-end (car form))))) (define (sgml-render-start tag) (displayl "<" (car tag)) (for-each (lambda (args) (displayl " " (car args) "=") (write (cadr args))) (cdr tag)) (display ">\n")) (define (sgml-render-end tag) (displayl "\n")) (define testfilelist '("/home/hjstein/software/scwm/scwm/Grab.c" "/home/hjstein/software/scwm/scwm/ICCCM.c" "/home/hjstein/software/scwm/scwm/add_window.c" "/home/hjstein/software/scwm/scwm/binding.c" "/home/hjstein/software/scwm/scwm/borders.c" "/home/hjstein/software/scwm/scwm/callbacks.c" "/home/hjstein/software/scwm/scwm/color.c" "/home/hjstein/software/scwm/scwm/colormaps.c" "/home/hjstein/software/scwm/scwm/colors.c" "/home/hjstein/software/scwm/scwm/complex.c" "/home/hjstein/software/scwm/scwm/decor.c" "/home/hjstein/software/scwm/scwm/decorations.c" "/home/hjstein/software/scwm/scwm/deskpage.c" "/home/hjstein/software/scwm/scwm/draw-pie-menu.c" "/home/hjstein/software/scwm/scwm/drawmenu.c" "/home/hjstein/software/scwm/scwm/errors.c" "/home/hjstein/software/scwm/scwm/events.c" "/home/hjstein/software/scwm/scwm/face.c" "/home/hjstein/software/scwm/scwm/focus.c" "/home/hjstein/software/scwm/scwm/font.c" "/home/hjstein/software/scwm/scwm/getopt.c" "/home/hjstein/software/scwm/scwm/getopt1.c" "/home/hjstein/software/scwm/scwm/guile-compat.c" "/home/hjstein/software/scwm/scwm/icons.c" "/home/hjstein/software/scwm/scwm/image.c" "/home/hjstein/software/scwm/scwm/init_scheme_string.c" "/home/hjstein/software/scwm/scwm/menu.c" "/home/hjstein/software/scwm/scwm/menuitem.c" "/home/hjstein/software/scwm/scwm/miscprocs.c" "/home/hjstein/software/scwm/scwm/module-interface.c" "/home/hjstein/software/scwm/scwm/move.c" "/home/hjstein/software/scwm/scwm/placement.c" "/home/hjstein/software/scwm/scwm/resize.c" "/home/hjstein/software/scwm/scwm/screen.c" "/home/hjstein/software/scwm/scwm/scwm.c" "/home/hjstein/software/scwm/scwm/scwmmenu.c" "/home/hjstein/software/scwm/scwm/shutdown.c" "/home/hjstein/software/scwm/scwm/string_token.c" "/home/hjstein/software/scwm/scwm/syscompat.c" "/home/hjstein/software/scwm/scwm/system.c" "/home/hjstein/software/scwm/scwm/util.c" "/home/hjstein/software/scwm/scwm/virtual.c" "/home/hjstein/software/scwm/scwm/window.c" "/home/hjstein/software/scwm/scwm/xmisc.c" "/home/hjstein/software/scwm/scwm/xproperty.c")) (define frontpiece `((bookinfo) ((title) ((productname) "SCWM Reference Manual")) ((authorgroup) ((author) ((firstname) "Maciej") ((surname) "Stachowiak") ((affiliation) ((shortaffil) "MIT") ((jobtitle) "M.S. Degree Recipient") ((orgname) "Massachusetts Institute of Technology") ((orgdiv) "Department of Computer Science") ((address) ((city) "Cambridge") ((state) "Massachusetts") ((postcode) "12345") ((country) "U.S.A.") ((email) "mstachow@mit.edu")))) ((author) ((firstname) "Greg") ((surname) "Badros") ((affiliation) ((shortaffil) "UWashington") ((jobtitle) "Graduate Research Assistant") ((orgname) "University of Washington") ((orgdiv) "Department of Computer Science and Engineering") ((address) ((city) "Seattle") ((state) "Washington") ((postcode) "98195") ((country) "U.S.A.") ((email) "gjb@cs.washington.edu"))))) ((releaseinfo) "Release pre-0.8") ((pubdate) "28 July 1998") ((copyright) ((year) "1997–1998") ((holder) "Maciej Stachowiak and Greg J. Badros")))) (define (usage) (displayl "Usage: extract.scm [options] file1.c file2.c ... Extracts documentation from specified C source code files. Documentation must be embedded according to SCWM conventions: - Functions declared with the SCWM_PROC macro will be documented. They can be immediately followed by comments of the form /** ... */, which will be assumed to document the preceeding SCWM_PROC. Each SCWM_PROC should be followed by a FUNC_NAME define which matches the C function name given by the SCWM_PROC. - Comments of the form /** chapter_name : section_name ... */ will also be extracted. Options: -c, --check Check documentation for reasonableness. -s file, --sgml file Generate SGML and output to specified file. -p file, --proc file Generate procedure listing and output to specified file. -t file, --text file Generate plain text output to specified file. -a, --annotated-text Output plain text with each line prefixed by file:line_number:. -l, --ispell Run ispell on documentation. Currently hangs when given full SCWM source code set. -w, --words 'word word ...' More words for ispell to ignore. -h, -? --help Display this info. If no flags are given, the default action is to check the files. ")) (define (process-arg n func arg rest files actions) ;; (displayl "process-arg\n" ;; "arg : " arg "\n" ;; "rest : " rest "\n" ;; "files : " files "\n" ;; "actions : " actions "\n") (cond ((= n 0) (process-cmd-line rest files (cons (lambda (docs) (func docs)) actions))) ((= n 1) (cond ((null? rest) (displayl arg " flag given without arguments. Ignored.\n") (process-cmd-line rest files actions)) (else (process-cmd-line (cdr rest) files (cons (lambda (docs) (with-output-to-file (car rest) (lambda () (func docs)))) actions))))) (else (displayl "Internal error: process-arg only takes 0 or 1 as arg count\n")))) (define (process-cmd-line args files actions) (call-with-current-continuation (lambda (ret) (cond ((null? args) ;; (displayl "args : " args "\n" ;; "files : " files "\n" ;; "actions : " actions "\n") (if (null? files) (displayl "Error: You must specify at least one file.") (let ((docs (apply extract-docs-from-files (reverse files)))) (if (null? actions) (check-docs docs) (for-each (lambda (act) (act docs)) (reverse actions)))))) (else ;; (displayl "process-cmd-line: processing '" (car args) "'\n") (case (string->symbol (car args)) ((-l --ispell) (process-arg 0 ispell-docs (car args) (cdr args) files actions)) ((-c --check) (process-arg 0 check-docs (car args) (cdr args) files actions)) ((-s --sgml) (process-arg 1 (lambda (d) (docs->sgml frontpiece d)) (car args) (cdr args) files actions)) ((-p --proc) (process-arg 1 docs->proclist (car args) (cdr args) files actions)) ((-t --text) (process-arg 1 docs->text (car args) (cdr args) files actions)) ((-a --annotated-text) (process-arg 1 docs->annotated-text (car args) (cdr args) files actions)) ((-w --words) (cond ((null? (cdr args)) (displayl (car args) " flag given without arguments. Ignored.\n") (process-cmd-line (cdr args) files actions)) (else (set! *scwm-ok-words* (append (extract-words (cadr args)) *scwm-ok-words*)) (process-cmd-line (cddr args) files actions)))) ((-h -? --help) (usage) (ret '())) (else ;; (displayl "process-cmd-line: else. (car args) = '" (car args) "'\n") ;; (displayl "(eq? (car args) '-i) = " (eq? (string->symbol (car args)) '-i) "\n") (process-cmd-line (cdr args) (cons (car args) files) actions)))))))) ;;; Arg processing. (cond ((or (null? (command-line)) (null? (cdr (command-line))))) ((null? (cddr (command-line))) (usage) (exit)) (else (process-cmd-line (cddr (command-line)) '() '()) (exit))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Aug 10 19:11:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA07954 for scwm-discuss-outgoing; Mon, 10 Aug 1998 19:11:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA07951 for ; Mon, 10 Aug 1998 19:11:22 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03008; Mon, 10 Aug 98 19:10:33 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA21058; Mon, 10 Aug 1998 16:10:42 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102045.FAA13203@192.168.1.1> From: Greg Badros Date: 10 Aug 1998 16:10:41 -0700 In-Reply-To: ITANI Eiichiro's message of "Tue, 11 Aug 1998 05:45:29 +0900" Message-Id: Lines: 53 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > Hi, all. > > I have 3 problems with scwm, and 2 of them are rather critical. I > can't see why this happen. It may have something to do with I18N > functionality, so I just want to hear other people's experience. > > Problem 1: > Some times, scwm just dies. This seems to happen when window > mapped. Mostly, GNOME application's dialog pop-up. But situation > looks random. My guess is that it is blocking on an I/O requestion -- can you use strace (linux) or truss (solaris, others?) to watch the system calls? Do you use any fvwm2 modules. > > Problem 2: > scwm just hangs. scwm eats much CPU time, and never return. I > can't specify situation of this. Some time, resizing window, and > other time just move pointer one window to other. Same idea-- try watching system calls. It may also be helpful to attach a debugger session to the process (use gdb, then "attach "), and see what it's doing. I've not seen this behaviour. > Problem 3(minor problem): > Invoking fvwm2-module, I get message > `Error evaling packet: (0 15 "Send_WindowList" 1)'. > Some windows are not displayed in Pager, until I resize, or move > not displayed window. I can look into this. > > Have you ever had this kind of problems with recent snapshots? > I suppose this may have something to do with I18N codes, or running > guile in `setlocale'-ed environment. Nah, probably more general stuff that others have seen or will see, so we need to try to get it fixed. > > I changed guile 19980627 up to 19980806 version, but still have these > troubles. > > Sorry for ambiguous information, but my ability to write English is > so poor... :-( Your English is *great*! Far better than my Japanese! :-) Greg From owner-scwm-discuss@mit.edu Mon Aug 10 19:13:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA07985 for scwm-discuss-outgoing; Mon, 10 Aug 1998 19:13:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA07982 for ; Mon, 10 Aug 1998 19:13:26 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA21318; Mon, 10 Aug 98 19:13:23 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA21065; Mon, 10 Aug 1998 16:12:39 -0700 (PDT) To: perry@piermont.com Cc: ITANI Eiichiro , scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102130.RAA02826@jekyll.piermont.com> From: Greg Badros Date: 10 Aug 1998 16:12:38 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 10 Aug 1998 17:30:00 -0400" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > ITANI Eiichiro writes: > > Problem 1: > > Some times, scwm just dies. This seems to happen when window > > mapped. Mostly, GNOME application's dialog pop-up. But situation > > looks random. > > > > Problem 2: > > scwm just hangs. scwm eats much CPU time, and never return. I > > can't specify situation of this. Some time, resizing window, and > > other time just move pointer one window to other. > > I've had both of these things happen. I've also had it die on startup > at random. > > I chalk it all up to the program being very young and very > buggy. Given that I signed up to use a very young and very buggy Young, but hopefully less and less buggy. :-) Just because it's got bugs doesn't mean we don't want to hear about them. Functionality-stopping bugs (e.g, seg faults, hangs, and busy hangs) are the worst kind of bugs and we definitely want to know about these. > program, I don't mind too much -- I feel it is sort of my > responsibility to find the bugs. When a new (0.8) version comes out > and there is better internal documentation I'll probably start hunting > for them myself. Help is *always* *much* appreciated. 0.8 will be out Real Soon Now I hope. Greg From owner-scwm-discuss@mit.edu Mon Aug 10 19:21:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA08106 for scwm-discuss-outgoing; Mon, 10 Aug 1998 19:21:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA08103 for ; Mon, 10 Aug 1998 19:21:04 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA22232; Mon, 10 Aug 98 19:21:01 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id TAA03180; Mon, 10 Aug 1998 19:20:14 -0400 (EDT) Message-Id: <199808102320.TAA03180@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, ITANI Eiichiro , scwm-discuss@mit.edu Subject: Re: I have a few problems... In-Reply-To: Your message of "10 Aug 1998 16:12:38 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 10 Aug 1998 19:20:14 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > I chalk it all up to the program being very young and very > > buggy. Given that I signed up to use a very young and very buggy > > Young, but hopefully less and less buggy. :-) Just because it's got > bugs doesn't mean we don't want to hear about them. > Functionality-stopping bugs (e.g, seg faults, hangs, and busy hangs) are > the worst kind of bugs and we definitely want to know about these. It is hard to reproduce them, so it is hard to report them. Perry From owner-scwm-discuss@mit.edu Mon Aug 10 19:24:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA08158 for scwm-discuss-outgoing; Mon, 10 Aug 1998 19:24:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA08155 for ; Mon, 10 Aug 1998 19:24:05 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22557; Mon, 10 Aug 98 19:24:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA21116; Mon, 10 Aug 1998 16:23:24 -0700 (PDT) To: perry@piermont.com Cc: ITANI Eiichiro , scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102320.TAA03180@jekyll.piermont.com> From: Greg Badros Date: 10 Aug 1998 16:23:24 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 10 Aug 1998 19:20:14 -0400" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > "Perry E. Metzger" writes: > > > I chalk it all up to the program being very young and very > > > buggy. Given that I signed up to use a very young and very buggy > > > > Young, but hopefully less and less buggy. :-) Just because it's got > > bugs doesn't mean we don't want to hear about them. > > Functionality-stopping bugs (e.g, seg faults, hangs, and busy hangs) are > > the worst kind of bugs and we definitely want to know about these. > > It is hard to reproduce them, so it is hard to report them. Understood. I can reproduce the blocking hang w/ fvwm2 modules (if you get a blocking hang w/o fvwm2 modules, I need more information). I also haven't seen the busy hang (the one that sucks cycles), so more information there is appreciated if you figure out how to reproduce it. Thanks! Greg From owner-scwm-discuss@mit.edu Mon Aug 10 19:27:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA08332 for scwm-discuss-outgoing; Mon, 10 Aug 1998 19:27:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA08328 for ; Mon, 10 Aug 1998 19:27:56 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA05012; Mon, 10 Aug 98 19:27:06 EDT Received: by tis.bellhow.com; id TAA02732; Mon, 10 Aug 1998 19:27:19 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma002714; Mon, 10 Aug 98 19:26:49 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id TAA10485 for ; Mon, 10 Aug 1998 19:26:49 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: I have a few problems... Date: Mon, 10 Aug 1998 23:22:50 GMT Organization: Bell & Howell PSC Message-Id: <35d7803e.1049839309@mailhost> References: <199808102045.FAA13203@192.168.1.1> In-Reply-To: <199808102045.FAA13203@192.168.1.1> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id TAA08329 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 11 Aug 1998 05:45:29 +0900, you wrote: >Problem 3(minor problem): > Invoking fvwm2-module, I get message > `Error evaling packet: (0 15 "Send_WindowList" 1)'. > Some windows are not displayed in Pager, until I resize, or move > not displayed window. I saw this once (twice?). Is was sometime last week or so. It's either fixed in later snapshots, or it's Elusive. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Aug 11 07:22:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA12326 for scwm-discuss-outgoing; Tue, 11 Aug 1998 07:22:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA12323 for ; Tue, 11 Aug 1998 07:22:41 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA23671 for scwm-discuss@huis-clos.mit.edu; Tue, 11 Aug 1998 13:21:59 +0200 (CEST) Received: (qmail 4770 invoked by uid 115); 10 Aug 1998 18:22:23 -0000 To: scwm-discuss@mit.edu Subject: Cassowary errors X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 10 Aug 1998 20:22:20 +0200 Message-ID: Lines: 24 X-Mailer: Gnus v5.6.28/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, cassowary-0.2 and today's snapshot: move.o: In function `InteractiveMove': move.o(.text+0x10dd): undefined reference to `CassowaryModifyOpaqueFlag' resize.o: In function `InteractiveResize': resize.o(.text+0x92d): undefined reference to `CassowaryModifyOpaqueFlag' scwm.o: In function `InitVariables': scwm.o(.text+0x521): undefined reference to `CassowaryInitClVarsInPscreen' virtual.o: In function `MoveViewport': virtual.o(.text+0xd47): undefined reference to `ChangeVirtualPosition' The functions are nowhere to be found (apart from stub versions built when not using cassowary). Robbe P.S.: BTW, does "cassowary" mean something? My dictionary is silent on this matter. -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Aug 11 10:49:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA13299 for scwm-discuss-outgoing; Tue, 11 Aug 1998 10:49:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA13296 for ; Tue, 11 Aug 1998 10:49:49 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA18083; Tue, 11 Aug 98 10:48:52 EDT Received: from 192.168.1.1 (root@PPP181.tokyo-ap4.dti.ne.jp [210.170.145.247]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id XAA22763 for ; Tue, 11 Aug 1998 23:49:04 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id XAA23717 for ; Tue, 11 Aug 1998 23:49:02 +0900 Message-Id: <199808111449.XAA23717@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102320.TAA03180@jekyll.piermont.com> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: Greg Badros's message of "10 Aug 1998 16:23:24 -0700" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Tue, 11 Aug 1998 23:49:00 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > It is hard to reproduce them, so it is hard to report them. > > Understood. I can reproduce the blocking hang w/ fvwm2 modules (if you > get a blocking hang w/o fvwm2 modules, I need more information). I also > haven't seen the busy hang (the one that sucks cycles), so more > information there is appreciated if you figure out how to reproduce it. About No.3 problem, I always get "Error evaling packet.." when invoking fvwm2 module. But others are so much random. I've been running scwm from gdb for more than 32 hours, but no hang up... :-( :-) But last time I got this, stack trace went so deep into libguile. -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Tue Aug 11 11:25:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA13513 for scwm-discuss-outgoing; Tue, 11 Aug 1998 11:25:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA13510 for ; Tue, 11 Aug 1998 11:25:16 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA26000; Tue, 11 Aug 98 11:25:05 EDT Received: by tis.bellhow.com; id LAA04189; Tue, 11 Aug 1998 11:24:32 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma003997; Tue, 11 Aug 98 11:23:47 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA26982 for ; Tue, 11 Aug 1998 11:23:46 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: BUG: snapshot 1998 08 10 Date: Tue, 11 Aug 1998 15:19:46 GMT Organization: Bell & Howell PSC Message-Id: <35db5f16.1106887650@mailhost> References: <35d507b8.1018985613@mailhost> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA13511 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 10 Aug 1998 12:21:46 -0400, you wrote: >>>>> In message <35d507b8.1018985613@mailhost> >>>>> Sent on Mon, 10 Aug 1998 15:33:14 GMT >>>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>>> on the subject of "BUG: snapshot 1998 08 10": > >> BTW: > >> I have never gotten scwm-bug to work in emacs yet. I started to poke at it, but I have > >> other things (real work? :) ) that I need to do. Basically, `compose-mail' is not in > >> emacs 19.3x. Probably just does the same thing that `mail' does, but I don't know. > >fixed. Thanks! But not quite. I get a mail buffer without a header, just the info about my machine/installation. Looking at the docs for (mail): mail: an interactive compiled Lisp function in `sendmail'. (mail &optional NOERASE TO SUBJECT IN-REPLY-TO CC REPLYBUFFER ACTIONS) Edit a message to be sent. Prefix arg means resume editing (don't erase). When this function returns, the buffer `*mail*' is selected. The value is t if the message was newly initialized; otherwise, nil. Defining compose mail like this: (defun compose-mail (to) (mail nil to)) Gives me a *mail* buffer with To: scwm-discuss@huis-clos.mit.edu as it probably should. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Tue Aug 11 12:06:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA13758 for scwm-discuss-outgoing; Tue, 11 Aug 1998 12:06:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA13755 for ; Tue, 11 Aug 1998 12:06:27 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA09595; Tue, 11 Aug 98 12:05:30 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfbzk25241; Tue, 11 Aug 1998 16:05:43 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id MAA00756; Tue, 11 Aug 1998 12:05:40 -0400 To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: BUG: snapshot 1998 08 10 References: <35d507b8.1018985613@mailhost> <35db5f16.1106887650@mailhost> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: dale.smith@bellhow.com's message of Tue, 11 Aug 1998 15:19:46 GMT Date: 11 Aug 1998 12:05:39 -0400 Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35db5f16.1106887650@mailhost> >>>> Sent on Tue, 11 Aug 1998 15:19:46 GMT >>>> Honorable dale.smith@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: BUG: snapshot 1998 08 10": >> >> mail: an interactive compiled Lisp function in `sendmail'. >> (mail &optional NOERASE TO SUBJECT IN-REPLY-TO CC REPLYBUFFER ACTIONS) >> >> Edit a message to be sent. Prefix arg means resume editing (don't erase). >> When this function returns, the buffer `*mail*' is selected. >> The value is t if the message was newly initialized; otherwise, nil. Thanks. I should have asked for the doc before commiting my previous fix. Sorry. Fixed now. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Why use Windows, when there are Doors? From owner-scwm-discuss@mit.edu Tue Aug 11 12:39:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14037 for scwm-discuss-outgoing; Tue, 11 Aug 1998 12:39:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA14034 for ; Tue, 11 Aug 1998 12:39:15 -0400 Received: from smtp1.dti.ne.jp by MIT.EDU with SMTP id AA18164; Tue, 11 Aug 98 12:37:56 EDT Received: from 192.168.1.1 (root@PPP181.tokyo-ap4.dti.ne.jp [210.170.145.247]) by smtp.dtinet.or.jp (8.8.4+2.7Wbeta4/3.5Wpl2) with ESMTP id BAA18254 for ; Wed, 12 Aug 1998 01:38:07 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) with ESMTP id BAA24860 for ; Wed, 12 Aug 1998 01:38:05 +0900 Message-Id: <199808111638.BAA24860@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102320.TAA03180@jekyll.piermont.com> <199808111449.XAA23717@192.168.1.1> Mime-Version: 1.0 (generated by tm-edit 7.100) Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro In-Reply-To: ITANI Eiichiro's message of "Tue, 11 Aug 1998 23:49:00 +0900" X-Mailer: Gnus v5.4.64/Emacs 19.34 Date: Wed, 12 Aug 1998 01:38:03 +0900 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I wrote: > But others are so much random. I've been running scwm from gdb for > more than 32 hours, but no hang up... :-( :-) I finally got SEGV. :-) This happened when Communicator 4.5PR1 tried to pop-up file selection dialog. This is stack trace. #0 0x40200eb0 in malloc () #1 0x40200a35 in malloc () #2 0x4010da6f in scm_must_malloc (len=176, what=0x4014aaa6 "inferior root continuation") at gc.c:1424 #3 0x4012dc98 in scm_internal_cwdr (body=0x8052b00 , body_data=0xbffff3b8, handler=0x80529c0 , handler_data=0x806f7ab, stack_start=0xbffff3e0) at root.c:273 #4 0x8052b65 in scm_internal_stack_cwdr (body=0x8052aa0 , body_data=0xbffff3e4, handler=0x80529c0 , handler_data=0x806f7ab, stack_item=0xbffff3e0) at callbacks.c:125 #5 0x8052b9e in scwm_safe_apply (proc=1078386504, args=1078098712) at callbacks.c:144 #6 0x8053009 in apply_hooks (hook=1077620080, args=1078098712) at callbacks.c:379 #7 0x8061dc0 in BroadcastConfig (event_type=32, psw=0x80957d8) at module-interface.c:53 #8 0x8068fe9 in MovePswToCurrentPosition (psw=0x80957d8) at window.c:469 #9 0x806905f in SetScwmWindowPosition (psw=0x80957d8, x=17, y=-16777216, fOpaque=1) at window.c:496 #10 0x804cd69 in SuggestMoveWindowTo (psw=0x80957d8, x=17, y=-16777216, fOpaque=1) at add_window.c:104 #11 0x8068faf in MoveTo (psw=0x80957d8, x=17, y=-16777216) at window.c:459 #12 0x80691bf in move_finalize (w=0, psw=0x80957d8, x=17, y=-16777216) at window.c:550 #13 0x8064042 in PlaceWindow (psw=0x80957d8, Desk=0) at placement.c:604 #14 0x804d923 in AddWindow (w=62954284) at add_window.c:597 #15 0x8058660 in HandleMapRequestKeepRaised (KeepRaised=0) at events.c:860 #16 0x805860a in HandleMapRequest () at events.c:841 #17 0x80576f5 in DispatchEvent () at events.c:184 #18 0x805772a in HandleEvents () at events.c:206 #19 0x8066755 in scwm_main (argc=3, argv=0xbffffaec) at scwm.c:873 #20 0x8065b2d in scwm_gh_launch_pad (closure=0x8065b80, argc=3, argv=0xbffffaec) at scwm.c:407 #21 0x40112b23 in invoke_main_func (body_data=0xbffffa94) at init.c:505 #22 0x401388b5 in scm_internal_catch (tag=9076, body=0x40112b00 , body_data=0xbffffa94, handler=0x40138e30 , handler_data=0x0) at throw.c:236 #23 0x40112ad9 in scm_boot_guile_1 (base=0xbffffa90, closure=0xbffffa94) at init.c:481 #24 0x40112859 in scm_boot_guile (argc=3, argv=0xbffffaec, main_func=0x8065b10 , closure=0x8065b80) at init.c:346 #25 0x8065b59 in scwm_gh_enter (argc=3, argv=0xbffffaec, c_main_prog=0x8065b80 ) at scwm.c:414 #26 0x8065b75 in main (argc=3, argv=0xbffffaec) at scwm.c:426 My system is: Debian/GNU Linux Kernel: 2.0.35 + glibc 2.0.7 + XFree86 3.3.2 Guile: snapshot 19980806 SCWM: snapshot 19980808 $ ldd scwm /lib/nfslock.so.0 => /lib/nfslock.so.0 (0x4000d000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40015000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40021000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40033000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40042000) libguile.so.3 => /usr/local/lib/libguile.so.3 (0x400e5000) libqthreads.so.0 => /usr/local/lib/libqthreads.so.0 (0x40153000) libdl.so.2 => /lib/libdl.so.2 (0x40155000) libreadline.so.2 => /lib/libreadline.so.2 (0x40158000) libImlib.so.1 => /usr/local/lib/libImlib.so.1 (0x40183000) libm.so.6 => /lib/libm.so.6 (0x401a9000) libc.so.6 => /lib/libc.so.6 (0x401c2000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40267000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x402af000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x402b9000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) libncurses.so.3.4 => /lib/libncurses.so.3.4 (0x402ce000) libjpeg.so.6a => /usr/lib/libjpeg.so.6a (0x40313000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40331000) libgif.so.3 => /usr/lib/libgif.so.3 (0x40367000) libpng.so.2 => /usr/lib/libpng.so.2 (0x40370000) libz.so.1 => /usr/lib/libz.so.1 (0x40393000) Oh, I applied small patch scwm to read image through Imlib. So, libImlib, libjpeg, libgif, libpng and libz appear. But it doesn't have anything to do with this problem, I suppose. -- Eiichiro ITANI From owner-scwm-discuss@mit.edu Tue Aug 11 13:32:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA14330 for scwm-discuss-outgoing; Tue, 11 Aug 1998 13:32:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA14327 for ; Tue, 11 Aug 1998 13:31:52 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA01910; Tue, 11 Aug 98 13:30:54 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA04792; Tue, 11 Aug 1998 10:31:04 -0700 (PDT) To: ITANI Eiichiro Cc: scwm-discuss@mit.edu Subject: Re: I have a few problems... References: <199808102320.TAA03180@jekyll.piermont.com> <199808111449.XAA23717@192.168.1.1> <199808111638.BAA24860@192.168.1.1> From: Greg Badros Date: 11 Aug 1998 10:31:03 -0700 In-Reply-To: ITANI Eiichiro's message of "Wed, 12 Aug 1998 01:38:03 +0900" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk ITANI Eiichiro writes: > I wrote: > > > But others are so much random. I've been running scwm from gdb for > > more than 32 hours, but no hang up... :-( :-) > > I finally got SEGV. :-) > > This happened when Communicator 4.5PR1 tried to pop-up file selection > dialog. Cool-- thanks for the backtrace and everything. Greg From owner-scwm-discuss@mit.edu Tue Aug 11 16:49:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA15262 for scwm-discuss-outgoing; Tue, 11 Aug 1998 16:49:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA15259 for ; Tue, 11 Aug 1998 16:49:34 -0400 Received: by tis.bellhow.com; id QAA07823; Tue, 11 Aug 1998 16:48:48 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma007800; Tue, 11 Aug 98 16:48:38 -0400 Received: from wgspc.systems.bellhow.com (wgspc.systems.bellhow.com [192.168.33.121]) by mailhost.bellhow.com (8.8.8/8.8.8) with ESMTP id QAA11312 for ; Tue, 11 Aug 1998 16:48:37 -0400 (EDT) Received: (from smithd@localhost) by wgspc.systems.bellhow.com (8.8.4/8.8.3) id QAA05064; Tue, 11 Aug 1998 16:48:35 -0400 (EDT) Date: Tue, 11 Aug 1998 16:48:35 -0400 (EDT) Message-Id: <199808112048.QAA05064@wgspc.systems.bellhow.com> From: Dale Smith To: scwm-discuss@mit.edu Subject: Wierd "flat spot" on window corner Sender: owner-scwm-discuss@mit.edu Precedence: bulk SunOS wgs 5.5 Generic sun4m sparc sun4m Guile verion: 1.3a Libguile timestamp: Mon Jun 29 14:54:23 EDT 1998 SCWM version: pre-0.8 Restarted: true Display Size: 1144x836 Desk Size: 3x3 Viewport: 0x0 Pointer: 311x363 Current Desk: 0 X vendor: StarNet Communications Corp.; version: 11.0; release: 3208 X Display: Resolution: 3553x3371 Color: TrueColor (depth: 24; bits per RGB: 8) image-load-path: /home/users10/smithd/pixmaps /home/users10/smithd/icons /home/users10/smithd/lib/X11/mini-icons /home/users10/smithd/include/X11/pixmaps /home/users10/smithd/bitmaps /usr/X11/include/X11/pixmaps /usr/local/lib/FVWM/PIXMAPS /usr/include/X11/pixmaps /usr/local/lib/FVWM/bitmaps /usr/include/X11/bitmaps /usr/local/share/emacs/19.33/etc /usr/openwin/include/X11/bitmaps /usr/openwin/include/X11/pixmaps /X11/mini-icons /home/users10/smithd/include/X11/pixmaps /home/users10/smithd/include/X11/bitmaps /home/users10/smithd/lib/X11/mini-icons (trying out scwm-bug) My FvwmPager has a "flat spot" on the right side of the upper right frame corner. This from my .scwmrc: (window-style "*" #:fg "Black" #:bg "gray75" #:icon "unknown1.xpm" #:icon-box (list 1 (y- 69) (y- 141) 69) #:border-width 4 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:int-override #t #:decorate-transient #t #:mwm-border #t #:PPosition-hint #f #:lenience #t ) (window-style "Fvwm Pager" #:sticky #t #:no-titlebar #t) I think it would be a good idea able to post a .xwd (x window dump) type file. I thought a .gif might be better, but I can't seem to get a xwdto??? filter working. Do you guys have access to xwd and xwud? Know any other way to capture what my display looks like so you can see it? Dale From owner-scwm-discuss@mit.edu Tue Aug 11 17:00:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA15346 for scwm-discuss-outgoing; Tue, 11 Aug 1998 17:00:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA15343 for ; Tue, 11 Aug 1998 17:00:37 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA03292; Tue, 11 Aug 98 17:00:24 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA06821; Tue, 11 Aug 1998 13:59:47 -0700 (PDT) To: Dale Smith Cc: scwm-discuss@mit.edu Subject: Re: Wierd "flat spot" on window corner References: <199808112048.QAA05064@wgspc.systems.bellhow.com> From: Greg Badros Date: 11 Aug 1998 13:59:47 -0700 In-Reply-To: Dale Smith's message of "Tue, 11 Aug 1998 16:48:35 -0400 (EDT)" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dale Smith writes: > My FvwmPager has a "flat spot" on the right side of the upper > right frame corner. This from my .scwmrc: I can reproduce it (and it should've been in the BUGS file for a while, since I've known about this problem for a bit). > (window-style "Fvwm Pager" #:sticky #t #:no-titlebar #t) > > I think it would be a good idea able to post a .xwd (x window dump) > type file. I thought a .gif might be better, but I can't seem > to get a xwdto??? filter working. Do you guys have access to > xwd and xwud? Know any other way to capture what my display > looks like so you can see it? I definitely can xwud -- sending one gzipped and uuencoded to me directly is okay (let's not pollute the list with them, though). In this case, I know exactly what you're talking about. Most of the problems will go away when we rewrite the decorating code, so we may not spend much time on individual visual bugs right now (but we always appreciate the reports of the bugs -- I just added it to the BUGS file so that everyone knows we're aware of and can reproduce the problem). Thanks! Greg From owner-scwm-discuss@mit.edu Tue Aug 11 18:21:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA15914 for scwm-discuss-outgoing; Tue, 11 Aug 1998 18:21:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA15911 for ; Tue, 11 Aug 1998 18:21:25 -0400 Received: from sam.via.ecp.fr by MIT.EDU with SMTP id AA22006; Tue, 11 Aug 98 18:21:12 EDT Received: from localhost (sammy@localhost) by sam.via.ecp.fr (8.9.1/8.9.1/Debian/GNU) with SMTP id AAA13190 for ; Wed, 12 Aug 1998 00:20:32 +0200 Date: Wed, 12 Aug 1998 00:20:32 +0200 (CET) From: Samuel Hocevar To: scwm-discuss@mit.edu Subject: Re: Wierd "flat spot" on window corner In-Reply-To: <199808112048.QAA05064@wgspc.systems.bellhow.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 11 Aug 1998, Dale Smith wrote: > I think it would be a good idea able to post a .xwd (x window dump) > type file. I thought a .gif might be better, but I can't seem > to get a xwdto??? filter working. Do you guys have access to > xwd and xwud? Know any other way to capture what my display > looks like so you can see it? Several graphic programs can load xwd output files. I use the Imagemagick package containing the 'convert' utility: xwd -root -display :0 -out test.xwd convert test.xwd test.jpg rm test.xwd Sam. -- for groslourd in {Jip, Nark, Overlord} do /ignore $groslourd ALL; done From owner-scwm-discuss@mit.edu Tue Aug 11 21:52:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17105 for scwm-discuss-outgoing; Tue, 11 Aug 1998 21:52:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA17101 for ; Tue, 11 Aug 1998 21:52:39 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08229; Tue, 11 Aug 98 21:51:33 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA09962; Tue, 11 Aug 1998 18:51:42 -0700 (PDT) To: Dale Smith Cc: scwm-discuss@mit.edu Subject: Re: Wierd "flat spot" on window corner References: <199808112048.QAA05064@wgspc.systems.bellhow.com> From: Greg Badros Date: 11 Aug 1998 18:51:42 -0700 In-Reply-To: Dale Smith's message of "Tue, 11 Aug 1998 16:48:35 -0400 (EDT)" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dale Smith writes: > My FvwmPager has a "flat spot" on the right side of the upper > right frame corner. This from my .scwmrc: Hopefully I fixed this and lots of other related visual bugs are fixed (they all stemmed from the same problem). Please let me know if you see problems with the borders still. Thanks, Greg From owner-scwm-discuss@mit.edu Tue Aug 11 21:59:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17274 for scwm-discuss-outgoing; Tue, 11 Aug 1998 21:59:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA17271 for ; Tue, 11 Aug 1998 21:58:59 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA08918; Tue, 11 Aug 98 21:57:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA09973; Tue, 11 Aug 1998 18:58:09 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Tonights snapshot -- pretest for 0.8 release From: Greg Badros Date: 11 Aug 1998 18:58:09 -0700 Message-Id: Lines: 7 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'd like to hear about any must-have-fixed items in tonights snapshot -- consider it a scwm-0.8 pre-release. Perhaps we can get 0.8 out tomorrow? Thanks, Greg From owner-scwm-discuss@mit.edu Wed Aug 12 08:35:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA20472 for scwm-discuss-outgoing; Wed, 12 Aug 1998 08:35:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA20469 for ; Wed, 12 Aug 1998 08:35:37 -0400 Received: from pilt-s.online.no by MIT.EDU with SMTP id AA05192; Wed, 12 Aug 98 08:34:24 EDT Received: from terje.nextel.no (terje.nextel.no [193.212.0.25]) by online.no (8.8.8/8.8.7) with ESMTP id OAA10726 for ; Wed, 12 Aug 1998 14:34:38 +0200 (MET DST) Received: (from ts@localhost) by terje.nextel.no (8.8.8/8.7.3) id OAA21554; Wed, 12 Aug 1998 14:34:37 +0200 (MET DST) From: Terje Sannum To: scwm-discuss@mit.edu Subject: Window sizeing Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 12 Aug 1998 14:34:37 +0200 Message-Id: Lines: 17 X-Mailer: Gnus v5.6.29/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've just installed the 19980812 snapshot, and have some problems. Scwm seems to size some of the windows wrong. If I start an xterm like this: % xterm -fn 9x15 -geometry 80x24 I get a window of 78x24 characters. For each time I restart scwm that windows shrinks one column. This is not happening if I use the 6x10 font. Some of my other windows (xclock, xload, xmcd) grows some rows when (re)starting scwm. Another thing: Is there a way to get a window by id, or do I have to use a variant of the find-window-by-name defined in flux.scm? -- \\\\ Terje Sannum //// Now playing: Klinik / Blanket of Fog From owner-scwm-discuss@mit.edu Wed Aug 12 09:32:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA20738 for scwm-discuss-outgoing; Wed, 12 Aug 1998 09:32:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA20735 for ; Wed, 12 Aug 1998 09:32:45 -0400 Received: by tis.bellhow.com; id JAA07347; Wed, 12 Aug 1998 09:31:52 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma007333; Wed, 12 Aug 98 09:31:50 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id JAA29392 for ; Wed, 12 Aug 1998 09:31:49 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: set-shadow-factor! Date: Wed, 12 Aug 1998 13:27:49 GMT Organization: Bell & Howell PSC Message-ID: <35d29787.1186872953@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA20736 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Being thrilled with the quality of decorations, I thought I'd play around with some settings. I could *not* use set-shadow-factor!. It refused every argument. Looking at the source, the logic is inverted. Should be: if (!gh_number_p(factor) || ((f=gh_scm2double(factor)) < 0.0)) { instead of: if (gh_number_p(factor) || ((f=gh_scm2double(factor)) < 0.0)) { Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Wed Aug 12 09:38:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA20790 for scwm-discuss-outgoing; Wed, 12 Aug 1998 09:38:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA20787 for ; Wed, 12 Aug 1998 09:38:45 -0400 Received: by tis.bellhow.com; id JAA08459; Wed, 12 Aug 1998 09:37:52 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma008398; Wed, 12 Aug 98 09:37:21 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id JAA29644 for ; Wed, 12 Aug 1998 09:37:21 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: set-shadow-factor! Date: Wed, 12 Aug 1998 13:33:20 GMT Organization: Bell & Howell PSC Message-ID: <35d39909.1187258357@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA20788 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In fact, all the set-xx-! type functions in color.c need to have the test for gh_number_p inverted. Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Wed Aug 12 12:21:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21739 for scwm-discuss-outgoing; Wed, 12 Aug 1998 12:21:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA21736 for ; Wed, 12 Aug 1998 12:21:05 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA25710; Wed, 12 Aug 98 12:20:44 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA12890; Wed, 12 Aug 1998 09:19:59 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: From: Greg Badros Date: 12 Aug 1998 09:19:59 -0700 In-Reply-To: Terje Sannum's message of "12 Aug 1998 14:34:37 +0200" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > I've just installed the 19980812 snapshot, and have some problems. > Scwm seems to size some of the windows wrong. If I start an xterm like > this: > > % xterm -fn 9x15 -geometry 80x24 > > I get a window of 78x24 characters. For each time I restart scwm that > windows shrinks one column. This is not happening if I use the 6x10 > font. Some of my other windows (xclock, xload, xmcd) grows some rows > when (re)starting scwm. Ok... thanks for the report. I'll take a look at it. > Another thing: Is there a way to get a window by id, or do I have to > use a variant of the find-window-by-name defined in flux.scm? See `id->window' Greg From owner-scwm-discuss@mit.edu Wed Aug 12 12:33:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21906 for scwm-discuss-outgoing; Wed, 12 Aug 1998 12:33:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA21881 for ; Wed, 12 Aug 1998 12:33:06 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA28689; Wed, 12 Aug 98 12:32:45 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA12902; Wed, 12 Aug 1998 09:32:08 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: set-shadow-factor! References: <35d39909.1187258357@mailhost> From: Greg Badros Date: 12 Aug 1998 09:32:07 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Wed, 12 Aug 1998 13:33:20 GMT" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > In fact, all the set-xx-! type functions in color.c need to have > the test for gh_number_p inverted. Yep. Fixed now. Thanks! Greg From owner-scwm-discuss@mit.edu Wed Aug 12 18:36:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23841 for scwm-discuss-outgoing; Wed, 12 Aug 1998 18:36:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23819 for ; Wed, 12 Aug 1998 18:35:50 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07166; Wed, 12 Aug 98 18:34:30 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA24024; Wed, 12 Aug 1998 15:34:41 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: From: Greg Badros Date: 12 Aug 1998 15:34:40 -0700 In-Reply-To: Terje Sannum's message of "12 Aug 1998 14:34:37 +0200" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > I've just installed the 19980812 snapshot, and have some problems. > Scwm seems to size some of the windows wrong. If I start an xterm like > this: > > % xterm -fn 9x15 -geometry 80x24 > > I get a window of 78x24 characters. For each time I restart scwm that > windows shrinks one column. This is not happening if I use the 6x10 > font. Some of my other windows (xclock, xload, xmcd) grows some rows > when (re)starting scwm. I've made some changes that fix this bug inasmuch as I was able to reproduce the bug (I never got 78x24, but did get 79x24). Let me know if tomorrow's snapshot still has related problems. If it does, please send me the window-styles that you are using (or just the .scwmrc you are using, if it's an included one). Thanks, Greg From owner-scwm-discuss@mit.edu Wed Aug 12 19:45:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24458 for scwm-discuss-outgoing; Wed, 12 Aug 1998 19:45:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24455 for ; Wed, 12 Aug 1998 19:45:23 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA15830; Wed, 12 Aug 98 19:44:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA26953; Wed, 12 Aug 1998 16:44:10 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806171224.A15775@molehill.org> <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> <19980807185233.A28545@molehill.org> <19980807205728.A29341@molehill.org> From: Greg Badros Date: 12 Aug 1998 16:44:08 -0700 In-Reply-To: Todd Larason's message of "Fri, 7 Aug 1998 20:57:28 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > --9jxsPFA5p3P2qPhR > Content-Type: text/plain; charset=us-ascii > > On 980807, Greg Badros wrote: > > I assume it's working again now, as I just tried co of the anon repo and > > it worked for me. > > Okay, patch attached now. I reimplemented part of the SnapToEdge function > to try to make it more obviously right. I think it's exactly equivalent to > the earlier patch I sent for it though. I just applied this patch. Sorry it took so long to get it. Let me know if you've since made other changes. Thanks, Greg From owner-scwm-discuss@mit.edu Wed Aug 12 21:46:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA25355 for scwm-discuss-outgoing; Wed, 12 Aug 1998 21:46:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA25352 for ; Wed, 12 Aug 1998 21:46:02 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA02041; Wed, 12 Aug 98 21:44:46 EDT Received: (qmail 5531 invoked by uid 501); 13 Aug 1998 01:46:48 -0000 Message-Id: <19980812184647.A5371@molehill.org> Date: Wed, 12 Aug 1998 18:46:47 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> <19980807185233.A28545@molehill.org> <19980807205728.A29341@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Aug 12, 1998 at 04:44:08PM -0700 X-Tom-Swifty: "I wrote the book on that subject", said Tom authoritatively. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980812, Greg Badros wrote: > Todd Larason writes: > > > --9jxsPFA5p3P2qPhR > > Content-Type: text/plain; charset=us-ascii > > > > On 980807, Greg Badros wrote: > > > I assume it's working again now, as I just tried co of the anon repo and > > > it worked for me. > > > > Okay, patch attached now. I reimplemented part of the SnapToEdge function > > to try to make it more obviously right. I think it's exactly equivalent to > > the earlier patch I sent for it though. > > I just applied this patch. Sorry it took so long to get it. Let me > know if you've since made other changes. ? diff Index: scheme/wininfo.scm =================================================================== RCS file: /anoncvs/scwm/scheme/wininfo.scm,v retrieving revision 1.14 diff -u -r1.14 wininfo.scm --- wininfo.scm 1998/08/13 00:23:56 1.14 +++ wininfo.scm 1998/08/13 01:41:16 @@ -86,10 +86,12 @@ (apply intersection-area (append (window-position w) - (window-size w) + (list (car (window-size w)) + (cadr (window-size w))) (list 0 0) (display-size)))) - (apply * (window-size w)))) + (* (car (window-size w)) + (cadr (window-size w))))) (define*-public (window-geometry-string #&optional (w (get-window))) (if w (let ((i (iconified? w)) I'm still seeing windows resizing themselves on restart/recapture, and I can also make it happen with (style-one-window). I'm trying to find a consistent/simple set of styles. My changes seem to always be reductions, and happen both x and y. Decors seem to be involved. That's with a cvs update from just a few minutes ago still. From owner-scwm-discuss@mit.edu Thu Aug 13 02:25:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA26573 for scwm-discuss-outgoing; Thu, 13 Aug 1998 02:25:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA26570 for ; Thu, 13 Aug 1998 02:25:22 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA03311; Thu, 13 Aug 98 02:24:05 EDT Received: (qmail 9821 invoked by uid 501); 13 Aug 1998 06:26:24 -0000 Message-Id: <19980812232623.A6288@molehill.org> Date: Wed, 12 Aug 1998 23:26:23 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: warnings Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I am NOT on drugs!" said Tom in high falsetto. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I get the following warnings which I don't understand...the warnings seem right, and it doesn't look to me like the code would work at all...but presumably it does, and I'm missing something. Could someone spare a 2 bit clue? ../../scwm/scwm/callbacks.c: In function `scm_internal_stack_cwdr': ../../scwm/scwm/callbacks.c:125: warning: passing arg 2 of `scm_internal_catch' from incompatible pointer type ../../scwm/scwm/callbacks.c: In function `scwm_safe_apply': ../../scwm/scwm/callbacks.c:146: warning: passing arg 1 of `scm_internal_stack_cwdr' from incompatible pointer type ../../scwm/scwm/callbacks.c: In function `scwm_safe_apply_message_only': ../../scwm/scwm/callbacks.c:160: warning: passing arg 2 of `scm_internal_catch' from incompatible pointer type ../../scwm/scwm/callbacks.c: In function `scwm_catching_eval_x': ../../scwm/scwm/callbacks.c:207: warning: passing arg 2 of `scm_internal_stack_catch' from incompatible pointer type ../../scwm/scwm/callbacks.c: In function `safe_load': ../../scwm/scwm/callbacks.c:258: warning: passing arg 2 of `scm_internal_catch' from incompatible pointer type ../../scwm/scwm/callbacks.c: In function `scwm_safe_eval_str': ../../scwm/scwm/callbacks.c:272: warning: passing arg 2 of `scm_internal_catch' from incompatible pointer type From owner-scwm-discuss@mit.edu Thu Aug 13 07:22:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA28361 for scwm-discuss-outgoing; Thu, 13 Aug 1998 07:22:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA28358 for ; Thu, 13 Aug 1998 07:22:29 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA10996 for scwm-discuss@huis-clos.mit.edu; Thu, 13 Aug 1998 13:21:23 +0200 (CEST) Received: (qmail 3649 invoked by uid 115); 13 Aug 1998 09:15:58 -0000 To: scwm-discuss@mit.edu Subject: set-edge-scroll-delay! lossage X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Thu_Aug_13_11:15:56_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 13 Aug 1998 11:15:56 +0200 Message-ID: Lines: 114 X-Mailer: Gnus v5.6.31/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Thu_Aug_13_11:15:56_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, I think handling #f rather than some arbitrary large value is a much better interface. Can someone squeeze in this patch before 0.8, so that we can drop supporting the bogus 10000 convention by 0.9? --Multipart_Thu_Aug_13_11:15:56_1998-1 Content-Type: text/plain; charset=US-ASCII Index: scwm/scwm/ChangeLog diff -c scwm/scwm/ChangeLog:1.9 scwm/scwm/ChangeLog:1.10 *** scwm/scwm/ChangeLog:1.9 Mon Aug 10 19:55:12 1998 --- scwm/scwm/ChangeLog Thu Aug 13 11:09:05 1998 *************** *** 1,3 **** --- 1,12 ---- + 1998-08-13 Robert Bihlmeyer + + * deskpage.c (s_set_edge_scroll_delay_x): Change calling + convention. usec == #f now means that scrolling is prohibited. + Warn whenever old usage of usec is detected. + + * virtual.c (FNeedsPaging): "Scrolling prohibited" is now + signalled with a negative time. + Fri Aug 7 20:04:44 1998 Greg Badros * Makefile.am: Added changed.c, log-usage.c, log-usage.h. Index: scwm/scwm/deskpage.c diff -c scwm/scwm/deskpage.c:1.1.1.5 scwm/scwm/deskpage.c:1.2 *** scwm/scwm/deskpage.c:1.1.1.5 Mon Aug 10 19:52:51 1998 --- scwm/scwm/deskpage.c Thu Aug 13 11:09:05 1998 *************** *** 231,248 **** /** Set the edge scroll delay to USEC microseconds. When the mouse pointer hits the edge of the screen, it must stay there for at least the edge scroll delay amount before the desktop will be ! scrolled. If this parameter is greater than 10,000, the viewport will ! not scroll at all at the screen edge (FIXMS: that's a bogus way to ! indicate that.) */ #define FUNC_NAME s_set_edge_scroll_delay_x { ! if (!gh_number_p(usec)) { SCM_ALLOW_INTS; scm_wrong_type_arg(FUNC_NAME, 1, usec); } - - Scr.ScrollResistance = gh_scm2int(usec); - return SCM_UNSPECIFIED; } #undef FUNC_NAME --- 231,254 ---- /** Set the edge scroll delay to USEC microseconds. When the mouse pointer hits the edge of the screen, it must stay there for at least the edge scroll delay amount before the desktop will be ! scrolled. If this parameter is #f, the viewport will not scroll at all ! at the screen edge. */ #define FUNC_NAME s_set_edge_scroll_delay_x { ! if (usec == SCM_BOOL_F) ! Scr.ScrollResistance = -1; ! else if (!gh_number_p(usec)) { SCM_ALLOW_INTS; scm_wrong_type_arg(FUNC_NAME, 1, usec); + } else { + Scr.ScrollResistance = gh_scm2int(usec); + if (Scr.ScrollResistance >= 10000) { + Scr.ScrollResistance = -1; + scwm_msg(WARN, FUNC_NAME, "Possible deprecated use of " + "`set-edge-scroll-delay!' detected. Give #f rather than usec " + ">= 10000 to prohibit scrolling."); + } } return SCM_UNSPECIFIED; } #undef FUNC_NAME Index: scwm/scwm/virtual.c diff -c scwm/scwm/virtual.c:1.1.1.7 scwm/scwm/virtual.c:1.2 *** scwm/scwm/virtual.c:1.1.1.7 Mon Aug 10 19:52:54 1998 --- scwm/scwm/virtual.c Thu Aug 13 11:09:05 1998 *************** *** 35,41 **** { int x, y; ! if ((Scr.ScrollResistance >= 10000) || ((HorWarpSize == 0) && (VertWarpSize == 0))) return False; --- 35,41 ---- { int x, y; ! if ((Scr.ScrollResistance < 0) || ((HorWarpSize == 0) && (VertWarpSize == 0))) return False; --Multipart_Thu_Aug_13_11:15:56_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Thu_Aug_13_11:15:56_1998-1-- From owner-scwm-discuss@mit.edu Thu Aug 13 08:02:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA28655 for scwm-discuss-outgoing; Thu, 13 Aug 1998 08:02:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA28651 for ; Thu, 13 Aug 1998 08:02:39 -0400 Received: from pilt-s.online.no by MIT.EDU with SMTP id AA22612; Thu, 13 Aug 98 08:02:08 EDT Received: from terje.nextel.no (terje.nextel.no [193.212.0.25]) by online.no (8.8.8/8.8.7) with ESMTP id OAA05041; Thu, 13 Aug 1998 14:01:34 +0200 (MET DST) Received: (from ts@localhost) by terje.nextel.no (8.8.8/8.7.3) id OAA25214; Thu, 13 Aug 1998 14:01:33 +0200 (MET DST) From: Terje Sannum To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 13 Aug 1998 14:01:33 +0200 In-Reply-To: Greg Badros's message of "12 Aug 1998 15:34:40 -0700" Message-Id: Lines: 43 X-Mailer: Gnus v5.6.29/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > I've made some changes that fix this bug inasmuch as I was able to > reproduce the bug (I never got 78x24, but did get 79x24). > > Let me know if tomorrow's snapshot still has related problems. If it > does, please send me the window-styles that you are using (or just the > .scwmrc you are using, if it's an included one). The problems with the xterm and emacs seems to be gone, but my xclock, xloads and xmcd gains some rows on (re)start. There are also some problems with the placement of the windows which might be related to this. When I try to place a window in the lower right corner (-geometry -0-0) it ends up with some space to the border (for xterm 2 columns and 1 row). If I move the windows into the border and restart scwm, they are moved back (1 row up and 2 rows to the left). More restarts moves them even more. Here is my window styles: (define window-title-font (load-font "-adobe-helvetica-*-r-*-*-13-*-*-*-*-*-*-*")) (define std-decor (make-decor)) (with-decor std-decor (title-style #:font window-title-font #:justify 'left #:relief 'flat) (button-style 1 #:relief 'flat #:pixmap "iconify.xpm") (button-style 2 #:relief 'flat #:pixmap "resize.xpm") (button-style 3 #:relief 'flat #:pixmap "close.xpm") (set-hilight-background! "salmon") ) (define std-style (make-style #:border-width 0 #:plain-border #t #:use-decor std-decor)) (define sticky-style (make-style #:sticky #t #:winlist-skip #t #:no-titlebar #t #:border-width 0 #:plain-border #t)) The problem is there for both styles. -- \\\\ Terje Sannum //// Now playing: Einst|rzende Neubauten / Tabula Rasa From owner-scwm-discuss@mit.edu Thu Aug 13 10:05:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA29208 for scwm-discuss-outgoing; Thu, 13 Aug 1998 10:05:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from tis.bellhow.com (tis.bellhow.com [38.252.198.21]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA29199 for ; Thu, 13 Aug 1998 10:04:52 -0400 Received: by tis.bellhow.com; id KAA13971; Thu, 13 Aug 1998 10:03:47 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma013934; Thu, 13 Aug 98 10:03:34 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA06172 for ; Thu, 13 Aug 1998 10:03:33 -0400 (EDT) From: dale.smith@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Sticky colors Date: Thu, 13 Aug 1998 13:59:32 GMT Organization: Bell & Howell PSC Message-ID: <35d2f08c.1275197386@mailhost> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA29200 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings List, In my other window manager, Fvwm (not Fvwm2), you can set the colors of sticky windows. Scwm has some lines in the title of sticky windows. How can I configure scwm to change the color of a window based on stickiness? Thanks! Dale -- Dale P. Smith dale.smith@bellhow.com Cleveland Linux Users Group: http://cleveland.lug.net/ From owner-scwm-discuss@mit.edu Thu Aug 13 12:31:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30157 for scwm-discuss-outgoing; Thu, 13 Aug 1998 12:31:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30154 for ; Thu, 13 Aug 1998 12:31:53 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA25868; Thu, 13 Aug 98 12:30:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA19595; Thu, 13 Aug 1998 09:30:34 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: set-edge-scroll-delay! lossage References: From: Greg Badros Date: 13 Aug 1998 09:30:33 -0700 In-Reply-To: Robert Bihlmeyer's message of "13 Aug 1998 11:15:56 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > --Multipart_Thu_Aug_13_11:15:56_1998-1 > Content-Type: text/plain; charset=US-ASCII > > Hi, > > I think handling #f rather than some arbitrary large value is a much > better interface. Can someone squeeze in this patch before 0.8, so > that we can drop supporting the bogus 10000 convention by 0.9? Good plan. I've got it in my working copy and will commit RSN. Thanks! Greg From owner-scwm-discuss@mit.edu Thu Aug 13 12:33:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30168 for scwm-discuss-outgoing; Thu, 13 Aug 1998 12:33:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30165 for ; Thu, 13 Aug 1998 12:33:57 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26345; Thu, 13 Aug 98 12:32:36 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA20048; Thu, 13 Aug 1998 09:32:47 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: warnings References: <19980812232623.A6288@molehill.org> From: Greg Badros Date: 13 Aug 1998 09:32:47 -0700 In-Reply-To: Todd Larason's message of "Wed, 12 Aug 1998 23:26:23 -0700" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I get the following warnings which I don't understand...the warnings seem > right, and it doesn't look to me like the code would work at all...but > presumably it does, and I'm missing something. > > Could someone spare a 2 bit clue? Which guile gives you this? What are your HAVE_SCM_* #defines in include/config.h? Thanks, Greg From owner-scwm-discuss@mit.edu Thu Aug 13 12:36:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30220 for scwm-discuss-outgoing; Thu, 13 Aug 1998 12:36:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30217 for ; Thu, 13 Aug 1998 12:36:43 -0400 Received: from wadjet.cerner.com by MIT.EDU with SMTP id AA01866; Thu, 13 Aug 98 12:36:09 EDT Received: from wadjet.cerner.com (root@localhost) by wadjet.cerner.com (8.7.5/8.7.3) with ESMTP id LAA28900 for ; Thu, 13 Aug 1998 11:35:29 -0500 (CDT) Received: from mailwhq01.cerner.com (mailwhq01.cerner.com [159.140.1.66]) by wadjet.cerner.com (8.7.5/8.7.3) with ESMTP id LAA28892 for ; Thu, 13 Aug 1998 11:35:28 -0500 (CDT) Received: by mailwhq01.cerner.com with Internet Mail Service (5.5.1960.3) id ; Thu, 13 Aug 1998 11:35:35 -0500 Message-Id: From: "Brinkman,Bo" To: "'scwm-discuss@mit.edu'" Subject: Window-shade question Date: Thu, 13 Aug 1998 11:35:35 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-scwm-discuss@mit.edu Precedence: bulk When I have a window shaded, and then I move it the entire window becomes visible. Is this a bug (I have the 19980801 snapshot), or am I just doing something silly in my scwmrc? Bo Brinkman Cerner Corporation 2800 Rockcreek Parkway Kansas City, MO 64117 Phone (816) 201-3671 Email: bbrinkman@cerner.com From owner-scwm-discuss@mit.edu Thu Aug 13 13:00:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA30496 for scwm-discuss-outgoing; Thu, 13 Aug 1998 13:00:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from preforcix.roof.lan (ppp15.junior-net.de [208.163.198.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA30493 for ; Thu, 13 Aug 1998 13:00:23 -0400 Received: (from forcer@localhost) by preforcix.roof.lan (8.9.1/8.9.1) id SAA21391 for scwm-discuss@huis-clos.mit.edu; Thu, 13 Aug 1998 18:59:15 +0200 Message-ID: <19980813185914.A21244@preforcix.roof.lan> Date: Thu, 13 Aug 1998 18:59:14 +0200 From: forcer To: scwm-discuss@mit.edu Subject: Click-to-place bug? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux preforcix 2.0.36 X-URL: http://webserver.de/forcer/ X-Mailer: Mutt 0.93.2i (1998-07-29) Sender: owner-scwm-discuss@mit.edu Precedence: bulk When i use click-to-place style positioning, SCWM positions the window in the upper left corner of the current desk and move with the mouse, regardless where the mouse pointer is. Scwm 0.7a did this correctly (position them it at the pointer and let me place them), but newer snapshots don't. Possibly useful output: Linux preforcix 2.0.36 #2 Thu Aug 13 00:06:35 MET DST 1998 i586 unknown scwm> (system-info-string) Guile verion: 1.2 Libguile timestamp: Sun Aug 9 21:11:04 MET DST 1998 SCWM version: pre-0.8 (actually, it fails with all of 19980804, 19980807, 19980808, 19980813) Restarted: false Display Size: 1600x1280 Desk Size: 3x3 Viewport: 0x0 Pointer: 800x640 Current Desk: 0 X vendor: The XFree86 Project, Inc; version: 11.0; release: 3320 X Display: Resolution: 2952x2956 Color: TrueColor (depth: 16; bits per RGB: 6) image-load-path: /usr/X11R6/lib/X11/mini-icons /usr/X11R6/include/X11/bitmaps /usr/X11R6/include/X11/pixmaps $ ldd scwm libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4000d000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40017000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40028000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40036000) libguile.so.2 => /usr/local/lib/libguile.so.2 (0x400c8000) libdl.so.1 => /lib/libdl.so.1 (0x40125000) libm.so.5 => /lib/libm.so.5 (0x40128000) libc.so.5 => /lib/libc.so.5 (0x40130000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x401f0000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4022e000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40236000) > IMHO relevant part of ~/.scwmrc: (define default-decor (make-decor)) (with-decor default-decor (title-style #:font font12 #:justify 'left) (border-style #:no-inset #t #:hidden-handles #f) (set-hilight-foreground! "white") (set-hilight-background! "darkblue")) (define default-style (make-style #:fg "white" #:bg "darkgray" #:icon "unknown1.xpm" #:icon-box (list (x- 70) 1 69 (y- 141)) #:border-width 4 #:focus 'sloppy #:random-placement #f #:smart-placement #f #:mwm-func-hint #f #:mwm-decor-hint #f #:decorate-transient #f #:PPosition-hint #t #:use-decor default-decor)) (window-style "*" #:mini-icon "mini-x.xpm" #:use-style default-style) Hope this helps, -forcer -- /* A CONS is an object which cares. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Thu Aug 13 13:07:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA30744 for scwm-discuss-outgoing; Thu, 13 Aug 1998 13:07:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA30738 for ; Thu, 13 Aug 1998 13:06:54 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10271; Thu, 13 Aug 98 13:06:22 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA23287; Thu, 13 Aug 1998 10:05:43 -0700 (PDT) To: "Brinkman,Bo" Cc: "'scwm-discuss@mit.edu'" Subject: Re: Window-shade question References: From: Greg Badros Date: 13 Aug 1998 10:05:43 -0700 In-Reply-To: "Brinkman,Bo"'s message of "Thu, 13 Aug 1998 11:35:35 -0500" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Brinkman,Bo" writes: > When I have a window shaded, and then I move it the entire window becomes > visible. Is this a bug (I have the 19980801 snapshot), or am I just doing > something silly in my scwmrc? Bug. It's fixed now in the repo. I also fixed the problem where the outline of the window was the full window, not just the shaded titlebar. Thanks for the report! Greg From owner-scwm-discuss@mit.edu Thu Aug 13 13:18:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA30944 for scwm-discuss-outgoing; Thu, 13 Aug 1998 13:18:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA30941 for ; Thu, 13 Aug 1998 13:18:08 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA07008; Thu, 13 Aug 98 13:16:46 EDT Received: (qmail 25393 invoked by uid 501); 13 Aug 1998 17:19:43 -0000 Message-Id: <19980813101942.B6288@molehill.org> Date: Thu, 13 Aug 1998 10:19:42 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: warnings References: <19980812232623.A6288@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Aug 13, 1998 at 09:32:47AM -0700 X-Tom-Swifty: "I am NOT on drugs!" said Tom in high falsetto. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980813, Greg Badros wrote: > Todd Larason writes: > > Which guile gives you this? What are your HAVE_SCM_* #defines in > include/config.h? That's guile 1.2, as distributed by redhat with gnome 0.13 I think. /* #undef HAVE_SCM_PUTS */ /* #undef HAVE_SCM_READLINE */ /* #undef HAVE_SCM_PARSE_PATH */ /* #undef HAVE_SCM_INTERNAL_SELECT */ /* #undef HAVE_SCM_THE_LAST_STACK_FLUID */ /* #undef HAVE_SCM_INTERNAL_CWDR */ /* #undef HAVE_SCM_INTERNAL_STACK_CATCH */ /* #undef HAVE_SCM_INTERNAL_PARSE_PATH */ #define HAVE_SCM_MAKE_VECTOR_3_ARGS 1 The function prototypes involved look the same in the snapshot from a few days ago, but the warnings don't appear - I didn't think to check the HAVE_SCM_* macros. From owner-scwm-discuss@mit.edu Thu Aug 13 13:59:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31239 for scwm-discuss-outgoing; Thu, 13 Aug 1998 13:59:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31236 for ; Thu, 13 Aug 1998 13:59:25 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA17549; Thu, 13 Aug 98 13:58:04 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA28232; Thu, 13 Aug 1998 10:58:14 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: minor bugs(?) References: <19980806182224.A16481@molehill.org> <19980806185334.A16951@molehill.org> <19980807004414.A20202@molehill.org> <19980807185233.A28545@molehill.org> <19980807205728.A29341@molehill.org> <19980812184647.A5371@molehill.org> From: Greg Badros Date: 13 Aug 1998 10:58:14 -0700 In-Reply-To: Todd Larason's message of "Wed, 12 Aug 1998 18:46:47 -0700" Message-Id: Lines: 38 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > ? diff > Index: scheme/wininfo.scm > =================================================================== > RCS file: /anoncvs/scwm/scheme/wininfo.scm,v > retrieving revision 1.14 > diff -u -r1.14 wininfo.scm > --- wininfo.scm 1998/08/13 00:23:56 1.14 > +++ wininfo.scm 1998/08/13 01:41:16 > @@ -86,10 +86,12 @@ > (apply intersection-area > (append > (window-position w) > - (window-size w) > + (list (car (window-size w)) > + (cadr (window-size w))) > (list 0 0) > (display-size)))) > - (apply * (window-size w)))) > + (* (car (window-size w)) > + (cadr (window-size w))))) > > (define*-public (window-geometry-string #&optional (w (get-window))) > (if w (let ((i (iconified? w)) I'm now using the new window-frame-size primitive which has the same behaviour as the old window-size. Thanks for pointing out the problem. > I'm still seeing windows resizing themselves on restart/recapture, and I > can also make it happen with (style-one-window). I'm trying to find a > consistent/simple set of styles. My changes seem to always be reductions, > and happen both x and y. Decors seem to be involved. That's with a > cvs update from just a few minutes ago still. Ok... I'm looking into this more now. Greg From owner-scwm-discuss@mit.edu Thu Aug 13 14:00:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA31255 for scwm-discuss-outgoing; Thu, 13 Aug 1998 14:00:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA31252 for ; Thu, 13 Aug 1998 14:00:11 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA25468; Thu, 13 Aug 98 13:59:38 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA28235; Thu, 13 Aug 1998 10:59:00 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: From: Greg Badros Date: 13 Aug 1998 10:59:00 -0700 In-Reply-To: Terje Sannum's message of "13 Aug 1998 14:01:33 +0200" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > Greg Badros writes: > > > I've made some changes that fix this bug inasmuch as I was able to > > reproduce the bug (I never got 78x24, but did get 79x24). > > > > Let me know if tomorrow's snapshot still has related problems. If it > > does, please send me the window-styles that you are using (or just the > > .scwmrc you are using, if it's an included one). > > The problems with the xterm and emacs seems to be gone, but my xclock, > xloads and xmcd gains some rows on (re)start. Okay -- thanks for the bug report and the example code so I can repro this. I'm looking into it now. Greg From owner-scwm-discuss@mit.edu Thu Aug 13 14:19:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA31511 for scwm-discuss-outgoing; Thu, 13 Aug 1998 14:19:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA31503 for ; Thu, 13 Aug 1998 14:19:03 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA22850; Thu, 13 Aug 98 14:17:42 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA29538; Thu, 13 Aug 1998 11:17:53 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: Click-to-place bug? References: <19980813185914.A21244@preforcix.roof.lan> From: Greg Badros Date: 13 Aug 1998 11:17:53 -0700 In-Reply-To: forcer's message of "Thu, 13 Aug 1998 18:59:14 +0200" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk forcer writes: > When i use click-to-place style positioning, SCWM positions the window in the > upper left corner of the current desk and move with the mouse, regardless > where the mouse pointer is. > Scwm 0.7a did this correctly (position them it at the pointer and let me place > them), but newer snapshots don't. Thanks for the excellent bug report! I just fixed it in the latest CVS sources which you can get via anon cvs. Let me know if you still see the problem. Greg From owner-scwm-discuss@mit.edu Thu Aug 13 15:07:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA31910 for scwm-discuss-outgoing; Thu, 13 Aug 1998 15:07:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA31904 for ; Thu, 13 Aug 1998 15:06:57 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05272; Thu, 13 Aug 98 15:05:35 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA03527; Thu, 13 Aug 1998 12:05:44 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: From: Greg Badros Date: 13 Aug 1998 12:05:42 -0700 In-Reply-To: Terje Sannum's message of "13 Aug 1998 14:01:33 +0200" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > The problems with the xterm and emacs seems to be gone, but my xclock, > xloads and xmcd gains some rows on (re)start. Try again now, if you would. I tested with your styles and the bug appears to be fixed. > There are also some problems with the placement of the windows which > might be related to this. When I try to place a window in the lower > right corner (-geometry -0-0) it ends up with some space to the > border (for xterm 2 columns and 1 row). If I move the > windows into the border and restart scwm, they are moved back (1 row > up and 2 rows to the left). More restarts moves them even more. I couldn't (before) reproduce this placement problem. Do you still see the problem? Greg From owner-scwm-discuss@mit.edu Thu Aug 13 18:23:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA00143 for scwm-discuss-outgoing; Thu, 13 Aug 1998 18:23:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA00140 for ; Thu, 13 Aug 1998 18:23:12 -0400 Received: from md38-177.mun.compuserve.com by MIT.EDU with SMTP id AA23947; Thu, 13 Aug 98 18:21:47 EDT Received: (from forcer@localhost) by preforcix.roof.lan (8.9.1/8.9.1) id AAA30832 for scwm-discuss@mit.edu; Fri, 14 Aug 1998 00:21:52 +0200 Message-Id: <19980814002150.A30782@preforcix.roof.lan> Date: Fri, 14 Aug 1998 00:21:50 +0200 From: forcer To: scwm-discuss@mit.edu Subject: Re: Click-to-place bug? Mail-Followup-To: scwm-discuss@mit.edu References: <19980813185914.A21244@preforcix.roof.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Greg Badros on Thu, Aug 13, 1998 at 11:17:53AM -0700 X-Operating-System: Linux preforcix 2.0.36 X-Url: http://webserver.de/forcer/ X-Mailer: Mutt 0.93.2i (1998-07-29) Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Aug 13, 1998 at 11:17:53AM -0700, Greg Badros wrote: >forcer writes: > >> When i use click-to-place style positioning, SCWM positions the window in the >> upper left corner of the current desk and move with the mouse, regardless >> where the mouse pointer is. >> Scwm 0.7a did this correctly (position them it at the pointer and let me place >> them), but newer snapshots don't. > >Thanks for the excellent bug report! > >I just fixed it in the latest CVS sources which you can get via anon >cvs. Let me know if you still see the problem. Not the same, but a related one. I downloaded the latest CVS source... Ok, problem is, xterms get placed correctly, as do some other windows. I haven't found any pattern, but smaller windows (like, request windows from Gimp, x11amp) appear too far down right from the cursor... hmm... (if you need my config information again let me know) -- /* A beer delayed is a beer denied. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Fri Aug 14 12:26:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05735 for scwm-discuss-outgoing; Fri, 14 Aug 1998 12:26:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05732 for ; Fri, 14 Aug 1998 12:26:23 -0400 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA27040; Fri, 14 Aug 98 12:26:44 EDT Received: from mizar (root@ppp08-nas0.vi.nettuno.it [193.207.146.217]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id SAA17866 for ; Fri, 14 Aug 1998 18:25:57 +0200 (MDT) Received: by mizar id m0z7JAT-0008RBC (Debian Smail-3.2 1996-Jul-4 #2); Fri, 14 Aug 1998 14:40:57 +0159 (CEST) Message-Id: <19980814144115.34795@mizar> Date: Fri, 14 Aug 1998 14:41:15 +0200 From: Francesco Tapparo To: scwm-discuss@mit.edu Subject: misc. observations Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm the debian scwm package maintainer. I've some little observations about your scwm: 1) scwm look for system.scwmrc in /usr/lib/X11/scwm, but the debian Packages must put the configuration files in /etc. Of course I can use a symlink in /usr/lib/X11/scwm, but this is only an hack, so I patched the configure.in to permit to specify the system.scwmrc location: ==============BEGIN PATCH====================================== --- configure.in Fri Aug 14 13:45:24 1998 +++ configure.in.debian Fri Aug 14 13:45:13 1998 @@ -56,6 +56,7 @@ fi ]) + dnl ## Checks for libraries ## @@ -253,7 +254,25 @@ scwm_load_path=${datadir}/${PACKAGE}-modules scwm_schemedir=${scwm_load_path}/app/scwm -scwmrcdir=${libdir}/X11/${PACKAGE} + +AC_ARG_WITH(scwmrcdir, +[ --with-scwmrcdir=DIR Install configuration files in DIR + [LIBDIR/X11/scwm]], +[ + if test -z "${withval}"; then + AC_MSG_ERROR(missing argument to --with-scwmrcdir) + else + AC_MSG_CHECKING(where conffiles should _reallly_ go) + scwmrcdir="${withval}" + AC_MSG_RESULT("${scwmrcdir}") + fi +], +[ + scwmrcdir="${libdir}/X11/${PACKAGE}" +]) + + + scwm_image_load_path="(\\\"${x_includes}/X11/bitmaps\\\" \\\"${x_includes}/X11/pixmaps\\\" \\\"${orig_x_libs}/X11/mini-icons\\\" \\\"${includedir}/X11/pixmaps\\\" \\\"${includedir}/X11/bitmaps\\\" \\\"${libdir}/X11/mini-icons\\\")" AC_SUBST(scwm_load_path) =========================END PATCH========================== note that the behaviour of the previous patch is not optimal: if I type configure --with-scwmrcdir= (without the dir), it give correctly an error, but if I type configure --with-scwmrcdir (without the = ), autoconf put a yes in place of the directory. I did'nt find a better method. 2) in the configure.in there is a lot of code as the following: AC_ARG_WITH(lispdir, [ --with-lispdir=DIR Install Emacs Lisp files in DIR [PREFIX/share/site-lisp]], [ if test -n "$ac_prev"; then AC_MSG_ERROR(missing argument to --with-lispdir) else do action fi ]) but this code does'nt work: configure --with-lispdir= (without the dir), do'nt give an error, and configure --with-lispdir (without the =), give to the lispdir variable the value "yes". I put an echo $ac_prev, and it seems to be void. I have autoconf 2.12. 3) a little typo, I think: in the Makefiles, there is a line DISTDIR= I think, this is DESTDIR=. I know that this is a very minor problem, but ... 4) I've some problems with scwm.el: start emacs ok M-x load-library: scwm ok M-x scwm-run error: Symbol's function definition is void: second but: start emacs ok M-x load-library-scwm ok M-x run-scheme Loading cmuscheme (compiled)...done M-x scwm-run ok Is this normal? Thank you Francesco From owner-scwm-discuss@mit.edu Fri Aug 14 12:51:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA05981 for scwm-discuss-outgoing; Fri, 14 Aug 1998 12:51:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA05978 for ; Fri, 14 Aug 1998 12:51:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA05909; Fri, 14 Aug 98 12:51:02 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA05215; Fri, 14 Aug 1998 09:51:11 -0700 (PDT) To: f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: misc. observations References: <19980814144115.34795@mizar> From: Greg Badros Date: 14 Aug 1998 09:51:11 -0700 In-Reply-To: Francesco Tapparo's message of "Fri, 14 Aug 1998 14:41:15 +0200" Message-Id: Lines: 71 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francesco Tapparo writes: > I'm the debian scwm package maintainer. I've some little observations about > your scwm: > > 1) scwm look for system.scwmrc in /usr/lib/X11/scwm, but the debian Packages > must put the configuration files in /etc. Of course I can use a symlink in > /usr/lib/X11/scwm, but this is only an hack, so I patched the configure.in > to permit to specify the system.scwmrc location: Ok, thanks. I'll apply the patch. > note that the behaviour of the previous patch is not optimal: if I type > configure --with-scwmrcdir= (without the dir), it give correctly an error, but > if I type configure --with-scwmrcdir (without the = ), autoconf put a yes in > place of the directory. I did'nt find a better method. I'll add some extra error checking. > > 2) in the configure.in there is a lot of code as the following: > AC_ARG_WITH(lispdir, > [ --with-lispdir=DIR Install Emacs Lisp files in DIR > [PREFIX/share/site-lisp]], > [ > if test -n "$ac_prev"; then > AC_MSG_ERROR(missing argument to --with-lispdir) > else > do action > fi > ]) > > but this code does'nt work: configure --with-lispdir= (without the dir), > do'nt give an error, and configure --with-lispdir (without the =), give to > the lispdir variable the value "yes". I put an echo $ac_prev, and it seems > to be void. I have autoconf 2.12. We should probably check test -n "$ac_prev" -a \! "$ac_prev" = "yes" -a \! "$ac_prev" = "no" Thanks for the heads-up. I will fix. > 3) a little typo, I think: in the Makefiles, there is a line > > DISTDIR= > > I think, this is DESTDIR=. I know that this is a very minor problem, but ... We never actually set DISTDIR -- this is an automake thing, I believe. > > 4) I've some problems with scwm.el: > > start emacs ok > M-x load-library: scwm ok > M-x scwm-run error: Symbol's function definition is void: second > > but: > start emacs ok > M-x load-library-scwm ok > M-x run-scheme Loading cmuscheme (compiled)...done > M-x scwm-run ok > > Is this normal? I let Sam comment on this one as he is the resident Emacs guru. Thanks for your patch and comments. And *thanks* for maintaining scwm for Debian GNU/Linux! Greg From owner-scwm-discuss@mit.edu Fri Aug 14 13:23:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA06315 for scwm-discuss-outgoing; Fri, 14 Aug 1998 13:23:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA06312 for ; Fri, 14 Aug 1998 13:23:44 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA13606; Fri, 14 Aug 98 13:23:26 EDT Received: (qmail 30695 invoked by uid 501); 14 Aug 1998 17:27:47 -0000 Message-Id: <19980814102746.A30595@molehill.org> Date: Fri, 14 Aug 1998 10:27:46 -0700 From: Todd Larason To: Greg Badros , f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: misc. observations References: <19980814144115.34795@mizar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Aug 14, 1998 at 09:51:11AM -0700 X-Tom-Swifty: "Im no communist", Alger hissed. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980814, Greg Badros wrote: > > 3) a little typo, I think: in the Makefiles, there is a line > > > > DISTDIR= > > > > I think, this is DESTDIR=. I know that this is a very minor problem, but ... > > We never actually set DISTDIR -- this is an automake thing, I believe. It's an automake bug, fixed I think in 1.2a. Ignorable unless you're wanting to use DESTDIR. From owner-scwm-discuss@mit.edu Fri Aug 14 13:46:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA06965 for scwm-discuss-outgoing; Fri, 14 Aug 1998 13:46:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA06959 for ; Fri, 14 Aug 1998 13:45:53 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA18639; Fri, 14 Aug 98 13:45:36 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfckt07988; Fri, 14 Aug 1998 17:45:46 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id NAA15385; Fri, 14 Aug 1998 13:45:44 -0400 To: f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: misc. observations References: <19980814144115.34795@mizar> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Francesco Tapparo's message of "Fri, 14 Aug 1998 14:41:15 +0200" Date: 14 Aug 1998 13:45:44 -0400 Message-Id: Lines: 13 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19980814144115.34795@mizar> >>>> Sent on Fri, 14 Aug 1998 14:41:15 +0200 >>>> Honorable Francesco Tapparo writes >>>> on the subject of "misc. observations": >> M-x scwm-run error: Symbol's function definition is void: second you must be using an old version of scwm.el -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Those who can laugh at themselves will never cease to be amused. From owner-scwm-discuss@mit.edu Fri Aug 14 14:34:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07745 for scwm-discuss-outgoing; Fri, 14 Aug 1998 14:34:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA07742 for ; Fri, 14 Aug 1998 14:34:48 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA01005; Fri, 14 Aug 98 14:35:20 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA08343; Fri, 14 Aug 1998 11:34:24 -0700 (PDT) Newsgroups: comp.os.linux.announce,comp.windows.x.announce,comp.lang.scheme To: scwm-discuss@mit.edu, guile@cygnus.com, scsh@ai.mit.edu, gnome-list@gnome.org Subject: Scwm-0.8 Released! From: Greg Badros Organization: Computer Science, U of Washington, Seattle, WA, USA X-Newsreader: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Date: 14 Aug 1998 11:34:20 -0700 Message-Id: Lines: 82 Posted-To: comp.os.linux.announce,comp.windows.x.announce,comp.lang.scheme Sender: owner-scwm-discuss@mit.edu Precedence: bulk The following message is a courtesy copy of an article that has been posted to comp.os.linux.announce,comp.windows.x.announce,comp.lang.scheme as well. Scwm 0.8 is released. * What Scwm is: Scwm is the Scheme Configurable Window Manager. This is a highly dynamic and extensible window manager for the X Window System (based originally on fvwm2, but now much enhanced) with Guile Scheme as the configuration/extension language. Nearly all decorations can be changed at run-time or per-window, and eventually many decoration styles and additional features will be supported through dynamically loaded code. A powerful protocol is provided for interacting with the window manager while it is running. * Primary Authors: Maciej Stachowiak Greg J. Badros * Where you can find more info: Some information about scwm is available at: http://huis-clos.mit.edu/scwm/ There are also scwm-discuss@huis-clos.mit.edu and scwm-announce@huis-clos.mit.edu mailing lists for disscussion and release announcements repsectively. You can subscribe to either at majordomo@huis-clos.mit.edu * Where you can get it: You can download the latest scwm package from: ftp://huis-clos.mit.edu/pub/scwm/scwm-0.8.tar.gz There is also ftp://huis-clos.mit.edu/pub/scwm/scwm-icons-0.8.tar.gz which has a number of images for use with scwm as icons, textures, buttons, etc. Some of these images are not available otherwise. You will also need to download and install the guile library. You can get the latest release from: ftp://prep.ai.mit.edu/pub/gnu/guile-1.2.tar.gz or any archive that has GNU source packages available. You can get the latest guile snapshot (has more useful features and generally work better) from: ftp://red-bean.com/pub/guile The snapshots are officially alpha but they generally work pretty well. * Here are highlights of what is new with the 0.8 release. There were many changes; see the NEWS file in the distribution for more details. o Fully documented all primitives -- Extracted during the build-process via new extract-docs tool -- DocBook SGML and plaintext formats -- html available online at: http://www.cs.washington.edu/research/constraints/cassowary/scwm-doc/ o Integrated documentation into scwm.el Emacs interaction mode -- apropos and procedure documentation help o Lots of bug fixes, cleaned-up API for consistency, multibyte character support o Squashed titlebar style o Optional alpha-quality integration of Cassowary constraint solver for window layout o Improved window placement configurability, window gravity support, and fvwm2 module support o Access to X properties, X resources, From owner-scwm-discuss@mit.edu Fri Aug 14 15:04:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA08308 for scwm-discuss-outgoing; Fri, 14 Aug 1998 15:04:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA08305 for ; Fri, 14 Aug 1998 15:04:15 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07701; Fri, 14 Aug 98 15:03:58 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA09611; Fri, 14 Aug 1998 12:04:01 -0700 (PDT) To: dale.smith@bellhow.com (Dale Smith) Cc: scwm-discuss@mit.edu Subject: Re: Sticky colors References: <35d2f08c.1275197386@mailhost> From: Greg Badros Date: 14 Aug 1998 12:04:01 -0700 In-Reply-To: dale.smith@bellhow.com's message of "Thu, 13 Aug 1998 13:59:32 GMT" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk dale.smith@bellhow.com (Dale Smith) writes: > Greetings List, > > In my other window manager, Fvwm (not Fvwm2), you can set the colors of sticky > windows. Scwm has some lines in the title of sticky windows. How can I configure > scwm to change the color of a window based on stickiness? Not directly. You can wrap the real "stick" and "unstick" primitives with a wrapper that does the extra work that you want before calling the primitives, and then use your stick-and-change-color and unstick-and-change-color procedures attached to events and decorations. After gaining some experience (and more bug-fixes) with the numeric constraint solver in Scwm, I plan to integrate a local-propagation solver which will deal with discrete constraints such as this. You'll be able to say "I want sticky windows to have a foreground color of yellow", or whatever, and the solver will do all the invocation of primitives to maintain the constraints. Greg From owner-scwm-discuss@mit.edu Fri Aug 14 17:15:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA08925 for scwm-discuss-outgoing; Fri, 14 Aug 1998 17:15:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA08922 for ; Fri, 14 Aug 1998 17:15:11 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfclh17444; Fri, 14 Aug 1998 21:15:08 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA20959; Fri, 14 Aug 1998 17:15:06 -0400 To: Maciej Stachowiak Subject: squashed-title Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 14 Aug 1998 17:15:06 -0400 Message-ID: Lines: 14 Sender: owner-scwm-discuss@mit.edu Precedence: bulk `squashed-title' is way cool! A couple of remarks: 1. I think `make-style' should be documented. 2. with `squashed-title' the is part of the window without a border. (on the top, to the right of the title). I think there should be a border there. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. There's always free cheese in a mousetrap. From owner-scwm-discuss@mit.edu Fri Aug 14 17:41:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA09130 for scwm-discuss-outgoing; Fri, 14 Aug 1998 17:41:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA09127 for ; Fri, 14 Aug 1998 17:41:56 -0400 Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfcli24975; Fri, 14 Aug 1998 21:41:54 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA21606; Fri, 14 Aug 1998 17:41:23 -0400 To: Maciej Stachowiak Subject: opaque move/resize Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 14 Aug 1998 17:41:23 -0400 Message-ID: Lines: 15 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Both move and resize are rubberband by default, and short of rebinding interactive-(move|resize) to opaque-interactive-(move|resize) everywhere the former is used, there is no way to get opqaue move/resize. Some time ago Maciej announced the new UI: a user-defined function which would take one argument, the window, and return a boolean opaque-p. What is the status of this: abandoned? forgotten? Thanks. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. War doesn't determine who's right, just who's left. From owner-scwm-discuss@mit.edu Fri Aug 14 17:50:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA09201 for scwm-discuss-outgoing; Fri, 14 Aug 1998 17:50:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA09198 for ; Fri, 14 Aug 1998 17:50:38 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA13601; Fri, 14 Aug 98 17:50:21 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA13752; Fri, 14 Aug 1998 14:50:34 -0700 (PDT) To: Maciej Stachowiak Subject: Re: squashed-title References: From: Greg Badros Date: 14 Aug 1998 14:50:33 -0700 In-Reply-To: Sam Steingold's message of "14 Aug 1998 17:15:06 -0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > `squashed-title' is way cool! > A couple of remarks: > > 1. I think `make-style' should be documented. Yep. But I think some of the style and decor stuff will probably change pretty dramatically when we do the decoration rewrite. > 2. with `squashed-title' the is part of the window without a border. (on > the top, to the right of the title). I think there should be a > border there. The reason there isn't a border is to avoid dirtying the code. To put the border there we'd need yet another subwindow of the frame that would only exist when squashed titlebars are used. The handful of local test users I have that requested squashed-titlebars weren't offended enough by the lack of the border to make me want to complicate the code (especially in light of the decoration rewrite). As I wrote before, the main reason I even added that feature (and the no-side-decorations object-property) were just to experiment with the decoration code to gain experience for thinking about the big decoration rewrite. Glad you like the squashed titlebars. We'll definitely have fully-featured squashed titlebars after the decoration rewrite. Greg From owner-scwm-discuss@mit.edu Fri Aug 14 18:06:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA09443 for scwm-discuss-outgoing; Fri, 14 Aug 1998 18:06:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA09435 for ; Fri, 14 Aug 1998 18:05:45 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA15990; Fri, 14 Aug 98 18:05:26 EDT Received: by tis.bellhow.com; id SAA28205; Fri, 14 Aug 1998 18:05:40 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma028184; Fri, 14 Aug 98 18:05:09 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id SAA26260 for ; Fri, 14 Aug 1998 18:05:09 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Some emacs.el things Date: Fri, 14 Aug 1998 22:05:09 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35dfb0ff.105793573@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id SAA09437 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings! I'm having some problems with emacs.el and emacs 19.3x. 1. compose-mail. I found a function, message-mail, that is a better fit to compose-mail than (mail nil to). 2. save-current-buffer. The defalias doesn't seem to work for save-excursion. Why? I don't know. Because it's a special form? I just replace all save-current-buffer with save-excursion and it works. 3. I get an error with help-setup-xref. It is being defailis'ed to 'ignore so I just commented it out where it is used. Is this a macro? Does defalias work for macros in 19.xx ? Here is the diff -u of the changes I made. Dale --- src/scwm-19980814/utilities/emacs/scwm.el Tue Aug 11 12:04:09 1998 +++ share/emacs/site-lisp/scwm.el Fri Aug 14 17:48:54 1998 @@ -78,7 +78,7 @@ (or (and (fboundp 'cadr) (fboundp 'unless)) (require 'cl)) ;; this is for those who load this uncompiled. (unless (fboundp 'ignore-errors) (autoload 'ignore-errors "cl" nil nil t)) - (unless (fboundp 'compose-mail) (defun compose-mail (to) (mail nil to))) + (unless (fboundp 'compose-mail) (defalias 'compose-mail 'message-mail)) (unless (fboundp 'apropos-mode) (autoload 'apropos-mode "apropos"))) (eval-when-compile (require 'cl) ; for `gensym' @@ -103,7 +103,7 @@ "Execute the forms in BODY with BUFFER as the current buffer. The value returned is the value of the last form in BODY. See also `with-temp-buffer'." - `(save-current-buffer + `(save-excursion (set-buffer ,buffer) ,@body))) (unless (fboundp 'with-output-to-string) @@ -305,7 +305,7 @@ (defun scwm-documentation (pat) "Query scwm for documentation for the symbol PAT." (interactive (list (scwm-complete-symbol))) - (help-setup-xref (list 'scwm-documentation pat) (interactive-p)) + ;;(help-setup-xref (list 'scwm-documentation pat) (interactive-p)) (with-output-to-temp-buffer "*Help*" (with-current-buffer "*Help*" (with-face 'highlight From owner-scwm-discuss@mit.edu Fri Aug 14 18:36:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA09689 for scwm-discuss-outgoing; Fri, 14 Aug 1998 18:36:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA09685 for ; Fri, 14 Aug 1998 18:36:02 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26929; Fri, 14 Aug 98 18:36:32 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA15192; Fri, 14 Aug 1998 15:35:56 -0700 (PDT) To: Maciej Stachowiak Subject: Re: opaque move/resize References: From: Greg Badros Date: 14 Aug 1998 15:35:56 -0700 In-Reply-To: Sam Steingold's message of "14 Aug 1998 17:41:23 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > Both move and resize are rubberband by default, and short of rebinding > interactive-(move|resize) to opaque-interactive-(move|resize) everywhere > the former is used, there is no way to get opqaue move/resize. > > Some time ago Maciej announced the new UI: a user-defined function which > would take one argument, the window, and return a boolean opaque-p. > What is the status of this: abandoned? forgotten? Maciej was still planning to do this, I believe. It's just he's not around for a bit. I went ahead and implemented basically this interface. I'm testing now, and will check in before I leave today. Greg From owner-scwm-discuss@mit.edu Fri Aug 14 18:37:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA09710 for scwm-discuss-outgoing; Fri, 14 Aug 1998 18:37:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA09707 for ; Fri, 14 Aug 1998 18:37:52 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA27233; Fri, 14 Aug 98 18:38:25 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfclm04697; Fri, 14 Aug 1998 22:37:49 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA21826; Fri, 14 Aug 1998 18:37:47 -0400 To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Some emacs.el things References: <35dfb0ff.105793573@smtp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: smithd@bellhow.com's message of "Fri, 14 Aug 1998 22:05:09 GMT" Date: 14 Aug 1998 18:37:45 -0400 Message-Id: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Meta-remarks: 1. please use `diff -c`. 2. please `quote' lisp symbols (then I can get hold of them easier). 3. please supply a backtrace for each error. >>>> In message <35dfb0ff.105793573@smtp> >>>> Sent on Fri, 14 Aug 1998 22:05:09 GMT >>>> Honorable smithd@bellhow.com (Dale Smith) writes >>>> on the subject of "Some emacs.el things": >> >> 1. compose-mail. I found a function, message-mail, that is a better >> fit to compose-mail than (mail nil to). There are several mail-composing functions in Emacs. `mail', `message-mail' and mh-something are among them. Newer emacsen know of `mail-user-agent', which makes `compose-mail' choose your mailer of choice. >> 2. save-current-buffer. The defalias doesn't seem to work for >> save-excursion. Why? I don't know. Because it's a special form? C-h f is your friend. `save-excursion' is a function. >> I just replace all save-current-buffer with save-excursion and it >> works. This is not a solution. >> 3. I get an error with help-setup-xref. It is being defailis'ed to >> 'ignore so I just commented it out where it is used. This is not a solution either. Emacs 20.3 will be out RSN, and if you like scwm.el now, you will love it with 20.3. `scwm-apropos' and `scwm-documentation' will be the big winners. I think it should work now. Thanks for reporting bugs. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The world is coming to an end. Please log off. From owner-scwm-discuss@mit.edu Sun Aug 16 11:44:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21121 for scwm-discuss-outgoing; Sun, 16 Aug 1998 11:44:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA21118 for ; Sun, 16 Aug 1998 11:44:50 -0400 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA29959; Sun, 16 Aug 98 11:45:21 EDT Received: from mizar (root@ppp23-nas0.vi.nettuno.it [193.207.146.232]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id RAA11434 for ; Sun, 16 Aug 1998 17:44:33 +0200 (MDT) Received: by mizar id m0z84qK-0008SHC (Debian Smail-3.2 1996-Jul-4 #2); Sun, 16 Aug 1998 17:35:20 +0200 (CEST) Message-Id: <19980816173539.39931@mizar> Date: Sun, 16 Aug 1998 17:35:39 +0200 From: Francesco Tapparo To: scwm-discuss@mit.edu Subject: Re: misc. observations Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: scwm-discuss@mit.edu References: <19980814144115.34795@mizar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Sam Steingold on Fri, Aug 14, 1998 at 01:45:44PM -0400 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Fri, Aug 14, 1998 at 01:45:44PM -0400, Sam Steingold wrote: > >>>> In message <19980814144115.34795@mizar> > >>>> Sent on Fri, 14 Aug 1998 14:41:15 +0200 > >>>> Honorable Francesco Tapparo writes > >>>> on the subject of "misc. observations": > >> M-x scwm-run error: Symbol's function definition is void: second > > you must be using an old version of scwm.el > > -- > Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux > Micros**t is not the answer. Micros**t is a question, and the answer is Linux, > (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. > Those who can laugh at themselves will never cease to be amused. > I installed the new scwm-0.8, and the problem is disappeared: thanks. Francesco From owner-scwm-discuss@mit.edu Mon Aug 17 10:10:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA27029 for scwm-discuss-outgoing; Mon, 17 Aug 1998 10:10:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA27026 for ; Mon, 17 Aug 1998 10:10:34 -0400 Received: from pilt-s.online.no by MIT.EDU with SMTP id AA27375; Mon, 17 Aug 98 10:10:56 EDT Received: from terje.nextel.no (terje.nextel.no [193.212.0.25]) by online.no (8.8.8/8.8.7) with ESMTP id QAA22772; Mon, 17 Aug 1998 16:10:19 +0200 (MET DST) Received: (from ts@localhost) by terje.nextel.no (8.8.8/8.7.3) id QAA03292; Mon, 17 Aug 1998 16:10:18 +0200 (MET DST) From: Terje Sannum To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: 17 Aug 1998 16:10:16 +0200 Message-Id: Lines: 70 X-Mailer: Gnus v5.6.29/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > I couldn't (before) reproduce this placement problem. Do you still > see the problem? Yes, it is still there in the 19980816 snapshot. I've done some more testing, and it looks like it has something todo with the use of use-decor (even if it doesn't apply to the style of the window). If I have a scwmrc like the one below, 'xload -geometry 100x100' gives me a 100x103 xload: (use-modules (app scwm base) (app scwm winops) (app scwm style) (app scwm face) (app scwm decor) ) (define std-decor (make-decor)) (with-decor std-decor (title-style #:font "-adobe-helvetica-*-r-*-*-13-*-*-*-*-*-*-*") ) (define std-style (make-style #:use-decor std-decor)) (define sticky-style (make-style #:sticky #t)) (window-style "*" #:use-style std-style) (window-style "xload" #:use-style sticky-style) If I remove the use of use-decor (but still keep the decor definition) like in the scwmrc file below, the command gives me a correct 100x100 xload: (use-modules (app scwm base) (app scwm winops) (app scwm style) (app scwm face) (app scwm decor) ) (define std-decor (make-decor)) (with-decor std-decor (title-style #:font "-adobe-helvetica-*-r-*-*-13-*-*-*-*-*-*-*") ) (define std-style (make-style #:border-width 5)) (define sticky-style (make-style #:sticky #t)) (title-style #:font "-adobe-helvetica-*-r-*-*-13-*-*-*-*-*-*-*") (window-style "*" #:use-style std-style) (window-style "xload" #:use-style sticky-style) Another thing I noticed is that the geometry I get is has something to do with which font I use for the title-style, e.g. if I change that to "-adobe-helvetica-*-r-*-*-10-*-*-*-*-*-*-*" my xload gets the size 100x99. BTW, a small detail: In the 19980816 snapshot there seems to be a newline in the prompt of scwmrepl: % scwmrepl scwm> X <---- cursor turns up here. -- \\\\ Terje Sannum //// Now playing: Klinik / Blanket of Fog From owner-scwm-discuss@mit.edu Mon Aug 17 10:15:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA27053 for scwm-discuss-outgoing; Mon, 17 Aug 1998 10:15:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA27050 for ; Mon, 17 Aug 1998 10:15:31 -0400 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id KAA07619 for ; Mon, 17 Aug 1998 10:21:40 -0400 (EDT) Received: from quirk.struble.c (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id KAA10532 for ; Mon, 17 Aug 1998 10:15:15 -0400 (EDT) Received: (from cstruble@localhost) by quirk.struble.c (8.8.8/8.8.7) id KAA26221 for scwm-discuss@huis-clos.mit.edu; Mon, 17 Aug 1998 10:15:43 -0400 (EDT) (envelope-from cstruble) Message-ID: <19980817101542.A26149@vt.edu> Date: Mon, 17 Aug 1998 10:15:42 -0400 From: Craig Struble To: scwm-discuss@mit.edu Subject: scwm-0.8 nits Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I recently upgraded to scwm-0.8a on my FreeBSD 2.2.6 machine and I'm running into a few things that changed which are strange. First, I had no luck using scwm-0.8a with guile-1.2. It compiled fine, with a few benign warnings, but I ran into all kinds of problems when it came to executing my .scwmrc, after changing to the 0.8a behaviors. Upgrading to a recent guile snapshot fixed those problems. Second, anything with a sticky icon has its icon placed where the top left corner of the window is placed. Moving the icon by hand doesn't even work. You deiconify and iconify again, and poof, the icon is back at the top left corner. Non-sticky icons work fine. Is there any hope of having sticky icons going back to their old behavior, being treated basically like non-sticky ones and put into icon boxes, etc.? Third, the title height seems to be impervious to style/decor changes. I can set a global title height using (title-style #:height 20) globally, but it has no effect if I use the #:height parameter in a window decor or style. It looks like there are comments about this in the code, but I haven't had time to really track it down. In 0.7a, changing the font in the decor also changed the title height, but that also doesn't work in 0.8a. Finally, and I think this has been mentioned before, windows that exist before scwm is run get shrunk by small amounts. Repeatedly restarting scwm makes windows get smaller and smaller. This is really evident if you have xterm windows up and you restart scwm a lot. Anyone else seeing these behaviors? Any easy fixes? See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Mon Aug 17 12:55:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA27769 for scwm-discuss-outgoing; Mon, 17 Aug 1998 12:55:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA27766 for ; Mon, 17 Aug 1998 12:55:18 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA06594; Mon, 17 Aug 98 12:54:47 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA11246; Mon, 17 Aug 1998 09:54:58 -0700 (PDT) To: Terje Sannum Cc: scwm-discuss@mit.edu Subject: Re: Window sizeing References: From: Greg Badros Date: 17 Aug 1998 09:54:58 -0700 In-Reply-To: Terje Sannum's message of "17 Aug 1998 16:10:16 +0200" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Terje Sannum writes: > Greg Badros writes: > > > I couldn't (before) reproduce this placement problem. Do you still > > see the problem? > > Yes, it is still there in the 19980816 snapshot. I've done some more > testing, and it looks like it has something todo with the use of > use-decor (even if it doesn't apply to the style of the window). If I > have a scwmrc like the one below, 'xload -geometry 100x100' gives me a > 100x103 xload: Thanks for the report... I'll look into it. > BTW, a small detail: In the 19980816 snapshot there seems to be > a newline in the prompt of scwmrepl: > > % scwmrepl > scwm> > X <---- cursor turns up here. I'll fix this right now. Greg From owner-scwm-discuss@mit.edu Mon Aug 17 12:56:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA27797 for scwm-discuss-outgoing; Mon, 17 Aug 1998 12:56:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA27791 for ; Mon, 17 Aug 1998 12:56:18 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA23731 for scwm-discuss@huis-clos.mit.edu; Mon, 17 Aug 1998 18:56:03 +0200 (CEST) Received: (qmail 25805 invoked by uid 115); 15 Aug 1998 11:27:57 -0000 To: scwm-discuss@mit.edu Subject: Re: squashed-title References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Aug 1998 13:27:55 +0200 In-Reply-To: Greg Badros's message of "14 Aug 1998 14:50:33 -0700" Message-ID: Lines: 32 X-Mailer: Gnus v5.6.31/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 14 Aug 1998 14:50:33 -0700 >>>>> Greg Badros said: Greg> The reason there isn't a border is to avoid dirtying the code. Greg> To put the border there we'd need yet another subwindow of the Greg> frame that would only exist when squashed titlebars are used. You could put pseudo-frame bevelling on the end of the titlebar. This is of course not clean. Greg> The handful of local test users I have that requested Greg> squashed-titlebars weren't offended enough by the lack of the Greg> border to make me want to complicate the code (especially in Greg> light of the decoration rewrite). #:border-width 0 is the only sane way to use squashed-titlebars, anyway . Greg> Glad you like the squashed titlebars. We'll definitely have Greg> fully-featured squashed titlebars after the decoration rewrite. A critical bug at the moment is that going from squashed to no-squashed does not work: the shape masks seems to stay in place - try maximizing a window after that. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 17 12:56:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA27795 for scwm-discuss-outgoing; Mon, 17 Aug 1998 12:56:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA27789 for ; Mon, 17 Aug 1998 12:56:18 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA23725 for scwm-discuss@huis-clos.mit.edu; Mon, 17 Aug 1998 18:56:03 +0200 (CEST) Received: (qmail 27131 invoked by uid 115); 15 Aug 1998 11:42:10 -0000 To: scwm-discuss@mit.edu Subject: Window placement References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Aug 1998 13:42:07 +0200 In-Reply-To: Greg Badros's message of "13 Aug 1998 12:05:42 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.31/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 13 Aug 1998 12:05:42 -0700 >>>>> Greg Badros said: Greg> I couldn't (before) reproduce this placement problem. Do you Greg> still see the problem? With version "Fri Aug 14 13:52:27 EDT 1998 -- $Revision: 1.73 $", when you set #:border-width to various values (I tried 0 and 4), "xterm -g -0-0" leaves different gaps between the xterm and the lower and right screen borders. This was (it's been some time since I checked the code) because the border-width defaults to 6, then the window is placed at the corner, and afterwards the border-width is reduced (making the window smaller) without re-placing the window. Maciej's work on window gravity didn't seem to change that. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 17 13:02:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA27891 for scwm-discuss-outgoing; Mon, 17 Aug 1998 13:02:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA27888 for ; Mon, 17 Aug 1998 13:02:51 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20376; Mon, 17 Aug 98 13:03:13 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA11272; Mon, 17 Aug 1998 10:02:32 -0700 (PDT) To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: scwm-0.8 nits References: <19980817101542.A26149@vt.edu> From: Greg Badros Date: 17 Aug 1998 10:02:32 -0700 In-Reply-To: Craig Struble's message of "Mon, 17 Aug 1998 10:15:42 -0400" Message-Id: Lines: 53 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig Struble writes: > Hi, I recently upgraded to scwm-0.8a on my FreeBSD 2.2.6 machine > and I'm running into a few things that changed which are strange. > > First, I had no luck using scwm-0.8a with guile-1.2. It compiled > fine, with a few benign warnings, but I ran into all kinds of > problems when it came to executing my .scwmrc, after changing to > the 0.8a behaviors. Upgrading to a recent guile snapshot fixed those > problems. Since we're a bit shorthanded on scwm developers for a bit, I didn't bother testing with guile-1.2; I should've documented this better-- for those who need to use 1.2, your best bet is to stick with scwm-0.7. Perhaps Maciej will want to restore 1.2 compatibility when he returns, but I'm counting on the guile folks to get a 1.3 out in the next two months. > Second, anything with a sticky icon has its icon placed where the > top left corner of the window is placed. Moving the icon by hand > doesn't even work. You deiconify and iconify again, and poof, the > icon is back at the top left corner. Non-sticky icons work fine. > Is there any hope of having sticky icons going back to their old > behavior, being treated basically like non-sticky ones and put into > icon boxes, etc.? I'll add it to the bug list -- the old behaviour is what *we* want to happen, too. > Third, the title height seems to be impervious to style/decor > changes. I can set a global title height using > (title-style #:height 20) > globally, but it has no effect if I use the #:height parameter in > a window decor or style. It looks like there are comments about > this in the code, but I haven't had time to really track it down. > In 0.7a, changing the font in the decor also changed the title > height, but that also doesn't work in 0.8a. I'll look into it. > Finally, and I think this has been mentioned before, windows that > exist before scwm is run get shrunk by small amounts. Repeatedly > restarting scwm makes windows get smaller and smaller. This is > really evident if you have xterm windows up and you restart scwm > a lot. Not sure why this is happening, still. I've tried to fix it, and I've not been able to reproduce it using gjb.scwmrc, but have some other notes from other users about how to recreate this problem, so I'll try. Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Mon Aug 17 13:36:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA28182 for scwm-discuss-outgoing; Mon, 17 Aug 1998 13:36:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA28179 for ; Mon, 17 Aug 1998 13:36:19 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA29399; Mon, 17 Aug 98 13:36:40 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA11376; Mon, 17 Aug 1998 10:35:53 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Window placement References: From: Greg Badros Date: 17 Aug 1998 10:35:52 -0700 In-Reply-To: Robert Bihlmeyer's message of "15 Aug 1998 13:42:07 +0200" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > This was (it's been some time since I checked the code) because the > border-width defaults to 6, then the window is placed at the corner, > and afterwards the border-width is reduced (making the window smaller) > without re-placing the window. Yep, there are some tricky order-dependences and all that code needs to be rethought from first principles, methinks. Greg From owner-scwm-discuss@mit.edu Mon Aug 17 13:35:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA28174 for scwm-discuss-outgoing; Mon, 17 Aug 1998 13:35:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA28171 for ; Mon, 17 Aug 1998 13:35:12 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA16799; Mon, 17 Aug 98 13:34:39 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA11373; Mon, 17 Aug 1998 10:34:51 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: squashed-title References: From: Greg Badros Date: 17 Aug 1998 10:34:51 -0700 In-Reply-To: Robert Bihlmeyer's message of "15 Aug 1998 13:27:55 +0200" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > A critical bug at the moment is that going from squashed to > no-squashed does not work: the shape masks seems to stay in place - > try maximizing a window after that. Yep. I'll look into it when time permits. I've a pape deadline for ICSE coming up that's going to consume much of my time for this week (I'm gonna try to keep up with email, but probably little else). Greg From owner-scwm-discuss@mit.edu Mon Aug 17 16:18:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA28955 for scwm-discuss-outgoing; Mon, 17 Aug 1998 16:18:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA28952 for ; Mon, 17 Aug 1998 16:18:41 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA17210; Mon, 17 Aug 98 16:19:00 EDT Received: by tis.bellhow.com; id QAA25603; Mon, 17 Aug 1998 16:18:22 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma025598; Mon, 17 Aug 98 16:18:20 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id QAA12248 for ; Mon, 17 Aug 1998 16:18:19 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Some emacs.el things Date: Mon, 17 Aug 1998 20:18:19 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35d97f18.355161064@smtp> References: <35dfb0ff.105793573@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id QAA28953 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 14 Aug 1998 18:37:45 -0400, you wrote: >C-h f is your friend. `save-excursion' is a function. In my Gnu Emacs Lisp Reference Manual (27.3 Excursions, p 119) `save-excursion' is listed as a Special Form. > > >> I just replace all save-current-buffer with save-excursion and it > >> works. > >This is not a solution. No it's not, but at least it allowed me to use scwm-documentation! I didn't mean you to make the replacement. I meant that defalias'ing `save-current-buffer' with `save-excursion' didn't work quite right, while actually changing the code *did* work. My guess is that defalias doesn't do the right thing for special forms. At least in 19.xx. >Meta-remarks: >3. please supply a backtrace for each error. Here is my *Backtrace* buffer when I "C-h C-s" on "execute" in my .scwmrc file in scwm-mode with `debug-on-error' set to t: Signaling: (invalid-function #) save-current-buffer(# 1) scwm-documentation("execute") call-interactively(scwm-documentation) From owner-scwm-discuss@mit.edu Mon Aug 17 16:52:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA29146 for scwm-discuss-outgoing; Mon, 17 Aug 1998 16:52:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA29143 for ; Mon, 17 Aug 1998 16:52:08 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA26789; Mon, 17 Aug 98 16:52:28 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfcwh22910; Mon, 17 Aug 1998 20:51:51 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id RAA01450; Mon, 17 Aug 1998 17:57:20 -0400 To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Some emacs.el things References: <35dfb0ff.105793573@smtp> <35d97f18.355161064@smtp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: smithd@bellhow.com's message of "Mon, 17 Aug 1998 20:18:19 GMT" Date: 17 Aug 1998 17:57:20 -0400 Message-Id: Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35d97f18.355161064@smtp> >>>> Sent on Mon, 17 Aug 1998 20:18:19 GMT >>>> Honorable smithd@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: Some emacs.el things": >> On 14 Aug 1998 18:37:45 -0400, you wrote: >> >> >Meta-remarks: >> >3. please supply a backtrace for each error. >> >> Here is my *Backtrace* buffer when I "C-h C-s" on "execute" in my >> .scwmrc file in scwm-mode with `debug-on-error' set to t: >> >> Signaling: (invalid-function #) >> save-current-buffer(# 1) Aha! I hoped that elisp byte compiler expands aliases at compile time. I was wrong. >> scwm-documentation("execute") >> call-interactively(scwm-documentation) Please try this: (unless (fboundp 'save-current-buffer) (defmacro save-current-buffer (&rest body) `(save-excursion ,@body))) it should work; if it does, I will install it. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Programming is like sex: one mistake and you have to support for a lifetime. From owner-scwm-discuss@mit.edu Mon Aug 17 17:08:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29318 for scwm-discuss-outgoing; Mon, 17 Aug 1998 17:08:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29315 for ; Mon, 17 Aug 1998 17:08:46 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA01037; Mon, 17 Aug 98 17:09:04 EDT Received: by tis.bellhow.com; id RAA04538; Mon, 17 Aug 1998 17:08:23 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma004390; Mon, 17 Aug 98 17:07:27 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id RAA13690 for ; Mon, 17 Aug 1998 17:07:26 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Some emacs.el things Date: Mon, 17 Aug 1998 21:07:26 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35da9a10.362065522@smtp> References: <35dfb0ff.105793573@smtp> <35d97f18.355161064@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA29316 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 17 Aug 1998 17:57:20 -0400, you wrote: >Please try this: > >(unless (fboundp 'save-current-buffer) > (defmacro save-current-buffer (&rest body) > `(save-excursion ,@body))) > >it should work; if it does, I will install it. Signaling: (invalid-function (macro . #[(&rest body) "À B‡" [save-excursion body] 2])) save-current-buffer(# 1) scwm-documentation("execute") call-interactively(scwm-documentation) From owner-scwm-discuss@mit.edu Mon Aug 17 18:39:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA29814 for scwm-discuss-outgoing; Mon, 17 Aug 1998 18:39:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA29811 for ; Mon, 17 Aug 1998 18:39:42 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA19879; Mon, 17 Aug 98 18:40:01 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfcwo22099; Mon, 17 Aug 1998 22:39:23 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id SAA01822; Mon, 17 Aug 1998 18:39:22 -0400 To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Some emacs.el things References: <35dfb0ff.105793573@smtp> <35d97f18.355161064@smtp> <35da9a10.362065522@smtp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: smithd@bellhow.com's message of "Mon, 17 Aug 1998 21:07:26 GMT" Date: 17 Aug 1998 18:39:22 -0400 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35da9a10.362065522@smtp> >>>> Sent on Mon, 17 Aug 1998 21:07:26 GMT >>>> Honorable smithd@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: Some emacs.el things": >> :::::::::::::: >> /tmp/mm.a01810 >> :::::::::::::: >> On 17 Aug 1998 17:57:20 -0400, you wrote: >> >> >Please try this: >> > >> >(unless (fboundp 'save-current-buffer) >> > (defmacro save-current-buffer (&rest body) >> > `(save-excursion ,@body))) >> > >> >it should work; if it does, I will install it. >> >> >> Signaling: (invalid-function (macro . #[(&rest body) "@ B" [save-excursion body] 2])) >> save-current-buffer(# 1) >> scwm-documentation("execute") >> call-interactively(scwm-documentation) yep, sure. you have to reload scwm.el after you define the macro. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Why do we want intelligent terminals when there are so many stupid users? From owner-scwm-discuss@mit.edu Mon Aug 17 22:54:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30966 for scwm-discuss-outgoing; Mon, 17 Aug 1998 22:54:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA30963 for ; Mon, 17 Aug 1998 22:54:54 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA29767; Mon, 17 Aug 98 22:54:17 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id WAA11804; Mon, 17 Aug 1998 22:54:26 -0400 (EDT) To: scwm-discuss@mit.edu Subject: bad problems with 0.8a Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Aug 1998 22:54:25 -0400 Message-Id: <87ogtjj8ym.fsf@jekyll.piermont.com> Lines: 9 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm having some serious problems with 0.8a. In particular, for no reason that I can ascertain, move-or-raise no longer works for me at all. I have a .scwmrc derived from the sample system.scwmrc, and I bind button one to move-or-raise in lots of places. In 0.7a it worked fine, but now it fails completely. This is Very Disturbing. Does anyone have any ideas? Perry From owner-scwm-discuss@mit.edu Mon Aug 17 23:03:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA31060 for scwm-discuss-outgoing; Mon, 17 Aug 1998 23:03:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA31057 for ; Mon, 17 Aug 1998 23:03:40 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA24415; Mon, 17 Aug 98 23:03:57 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id XAA11860; Mon, 17 Aug 1998 23:03:11 -0400 (EDT) To: scwm-discuss@mit.edu Subject: update... Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Aug 1998 23:03:11 -0400 Message-Id: <87n293j8k0.fsf@jekyll.piermont.com> Lines: 5 Sender: owner-scwm-discuss@mit.edu Precedence: bulk actually, I've determined that move-or-raise works for move, but never works for raise (?!?!!) .pm From owner-scwm-discuss@mit.edu Mon Aug 17 23:11:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA31176 for scwm-discuss-outgoing; Mon, 17 Aug 1998 23:11:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA31173 for ; Mon, 17 Aug 1998 23:11:41 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01517; Mon, 17 Aug 98 23:11:04 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id XAA11916; Mon, 17 Aug 1998 23:11:20 -0400 (EDT) To: scwm-discuss@mit.edu Subject: opaque move size replacement? Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Aug 1998 23:11:20 -0400 Message-Id: <87lnonj86f.fsf@jekyll.piermont.com> Lines: 9 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I used to have (set-opaque-move-size! 100) in my scwmrc, but it appears to no longer be accepted. Is there a replacement for this interface? .pm From owner-scwm-discuss@mit.edu Tue Aug 18 01:06:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA31706 for scwm-discuss-outgoing; Tue, 18 Aug 1998 01:06:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA31703 for ; Tue, 18 Aug 1998 01:06:24 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA07237; Tue, 18 Aug 98 01:06:39 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA09179; Mon, 17 Aug 1998 22:05:57 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a References: <87ogtjj8ym.fsf@jekyll.piermont.com> From: Greg Badros Date: 17 Aug 1998 22:05:57 -0700 In-Reply-To: "Perry E. Metzger"'s message of "17 Aug 1998 22:54:25 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I'm having some serious problems with 0.8a. In particular, for no > reason that I can ascertain, move-or-raise no longer works for me at > all. I have a .scwmrc derived from the sample system.scwmrc, and I > bind button one to move-or-raise in lots of places. In 0.7a it worked > fine, but now it fails completely. This is Very Disturbing. Does > anyone have any ideas? Can you elucidate on "fails completely"? Can you double check to be sure the scwm/init_scheme_string.c file got built correctly from scheme/minimal.scm? If not, can you try to figure out what went wrong and report back? Thanks! Greg From owner-scwm-discuss@mit.edu Tue Aug 18 01:09:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA31750 for scwm-discuss-outgoing; Tue, 18 Aug 1998 01:09:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA31747 for ; Tue, 18 Aug 1998 01:09:44 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA12534; Tue, 18 Aug 98 01:09:07 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA09775; Mon, 17 Aug 1998 22:09:19 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: opaque move size replacement? References: <87lnonj86f.fsf@jekyll.piermont.com> From: Greg Badros Date: 17 Aug 1998 22:09:19 -0700 In-Reply-To: "Perry E. Metzger"'s message of "17 Aug 1998 23:11:20 -0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I used to have > > (set-opaque-move-size! 100) > > in my scwmrc, but it appears to no longer be accepted. Is there a > replacement for this interface? >From scheme/ChangeLog: * winops.scm: Added vars `opaque-move-percent' and `opaque-resize-percent', procs `window-frame-area' and `display-area', user-procs `resize-opaquely?' and `move-opaquely?', and procs `interactive-move-maybe-opaque', `interactive-resize-maybe-opaque',`move-or-raise-maybe-opaque', `resize-or-raise-maybe-opaque'. Document toggle-maximize. You probably want to start using move-or-raise-maybe-opaque if you want a configurable opaque-ness size (and then set opaque-move-percent). Or just use opaque-interactive-move in your own move-or-raise-opaque function (similar to the one in minimal.scm). Sorry about the changes... there will definitely be more when Maciej gets back to his interface-cleaning-up that is near the top of his task list. Greg From owner-scwm-discuss@mit.edu Tue Aug 18 09:01:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA01429 for scwm-discuss-outgoing; Tue, 18 Aug 1998 09:01:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA01425 for ; Tue, 18 Aug 1998 09:01:44 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA16655; Tue, 18 Aug 98 09:01:56 EDT Received: by tis.bellhow.com; id JAA27599; Tue, 18 Aug 1998 09:01:18 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma027529; Tue, 18 Aug 98 09:00:48 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id JAA26464 for ; Tue, 18 Aug 1998 09:00:43 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Some emacs.el things Date: Tue, 18 Aug 1998 13:00:43 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35dd7a2f.419440032@smtp> References: <35dfb0ff.105793573@smtp> <35d97f18.355161064@smtp> <35da9a10.362065522@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA01426 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 17 Aug 1998 18:39:22 -0400, you wrote: >yep, sure. > >you have to reload scwm.el after you define the macro. I *know* I did it! Really. Did a byte-compile. Exit emacs. Try it again. I'm *sure* I did that. I come in this morning, and it's working. My mind is leaving me. Thanks! It *is* working now. Dale From owner-scwm-discuss@mit.edu Tue Aug 18 10:13:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA01759 for scwm-discuss-outgoing; Tue, 18 Aug 1998 10:13:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA01756 for ; Tue, 18 Aug 1998 10:13:48 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA05694; Tue, 18 Aug 98 10:13:59 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfcyy16856; Tue, 18 Aug 1998 14:13:20 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id KAA03157; Tue, 18 Aug 1998 10:13:17 -0400 To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Some emacs.el things References: <35dfb0ff.105793573@smtp> <35d97f18.355161064@smtp> <35da9a10.362065522@smtp> <35dd7a2f.419440032@smtp> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: smithd@bellhow.com's message of "Tue, 18 Aug 1998 13:00:43 GMT" Date: 18 Aug 1998 10:13:16 -0400 Message-Id: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <35dd7a2f.419440032@smtp> >>>> Sent on Tue, 18 Aug 1998 13:00:43 GMT >>>> Honorable smithd@bellhow.com (Dale Smith) writes >>>> on the subject of "Re: Some emacs.el things": >> >> I *know* I did it! Really. Did a byte-compile. Exit emacs. >> Try it again. I'm *sure* I did that. >> >> I come in this morning, and it's working. My mind is leaving me. Try to make it stay - we need it! :-) >> Thanks! It *is* working now. Thanks for testing! -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A poet who reads his verse in public may have other nasty habits. From owner-scwm-discuss@mit.edu Tue Aug 18 11:31:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA02120 for scwm-discuss-outgoing; Tue, 18 Aug 1998 11:31:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA02117 for ; Tue, 18 Aug 1998 11:31:12 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA29088; Tue, 18 Aug 98 11:31:18 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA14779; Tue, 18 Aug 1998 11:30:30 -0400 (EDT) Message-Id: <199808181530.LAA14779@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a In-Reply-To: Your message of "17 Aug 1998 22:05:57 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Aug 1998 11:30:30 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > I'm having some serious problems with 0.8a. In particular, for no > > reason that I can ascertain, move-or-raise no longer works for me at > > all. I have a .scwmrc derived from the sample system.scwmrc, and I > > bind button one to move-or-raise in lots of places. In 0.7a it worked > > fine, but now it fails completely. This is Very Disturbing. Does > > anyone have any ideas? > > Can you elucidate on "fails completely"? Examination reveals that I can move the windows with a hold down, but a click does not raise them. This has become, er, difficult to deal with. > Can you double check to be > sure the scwm/init_scheme_string.c file got built correctly from > scheme/minimal.scm? It appears to have been build correctly -- at the very least, move-or-raise is defined in the file. Perry From owner-scwm-discuss@mit.edu Tue Aug 18 12:46:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA02526 for scwm-discuss-outgoing; Tue, 18 Aug 1998 12:46:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA02523 for ; Tue, 18 Aug 1998 12:46:11 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA15501; Tue, 18 Aug 98 12:45:28 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA11849; Tue, 18 Aug 1998 09:45:41 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a References: <199808181530.LAA14779@jekyll.piermont.com> From: Greg Badros Date: 18 Aug 1998 09:45:40 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 18 Aug 1998 11:30:30 -0400" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > It appears to have been build correctly -- at the very least, > move-or-raise is defined in the file. I can't seem to reproduce this. Does it fail for you even with: scwm -f /dev/null ? Greg From owner-scwm-discuss@mit.edu Tue Aug 18 12:59:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA02627 for scwm-discuss-outgoing; Tue, 18 Aug 1998 12:59:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA02624 for ; Tue, 18 Aug 1998 12:59:10 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA23317; Tue, 18 Aug 98 12:59:21 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA15196; Tue, 18 Aug 1998 12:58:37 -0400 (EDT) Message-Id: <199808181658.MAA15196@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a In-Reply-To: Your message of "18 Aug 1998 09:45:40 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Aug 1998 12:58:36 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > It appears to have been build correctly -- at the very least, > > move-or-raise is defined in the file. > > I can't seem to reproduce this. Does it fail for you even with: > > scwm -f /dev/null Yes. Fails quite thoroughly. I wonder if this is in any way related to my (still unsolved) problem with double clicks not being recognised. BTW, in the course of testing this, I had to restart scwm several times. It pretty frequently hangs if I exit it and restart it with my .scwmrc, although scwm -f /dev/null does not hang. "go figure..." Perry From owner-scwm-discuss@mit.edu Tue Aug 18 13:07:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02725 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:07:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02721 for ; Tue, 18 Aug 1998 13:07:39 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA20806; Tue, 18 Aug 98 13:06:56 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA11895; Tue, 18 Aug 1998 10:07:09 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a References: <199808181658.MAA15196@jekyll.piermont.com> From: Greg Badros Date: 18 Aug 1998 10:07:09 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 18 Aug 1998 12:58:36 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > > I can't seem to reproduce this. Does it fail for you even with: > > > > scwm -f /dev/null > > Yes. Fails quite thoroughly. > > I wonder if this is in any way related to my (still unsolved) problem > with double clicks not being recognised. Ahh... perhaps. Is it that your usleep function is failing? BSD? I think Maciej was going to handle that problem since he has access to a FreeBSD box.... > BTW, in the course of testing this, I had to restart scwm several > times. It pretty frequently hangs if I exit it and restart it with my > .scwmrc, although scwm -f /dev/null does not hang. "go figure..." Do you start up any fvwm2 modules? There are some known problems with restarts and fvwm2 module interactions causing a hang (that usually can be un-hung by killing the fvwm2 module process(es). Greg From owner-scwm-discuss@mit.edu Tue Aug 18 13:30:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02910 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:30:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02907 for ; Tue, 18 Aug 1998 13:30:24 -0400 Received: from nekhbet.cerner.com by MIT.EDU with SMTP id AA01845; Tue, 18 Aug 98 13:30:34 EDT Received: from nekhbet.cerner.com (root@localhost) by nekhbet.cerner.com with ESMTP id MAA21623 for ; Tue, 18 Aug 1998 12:29:50 -0500 (CDT) Received: from mailwhq01.cerner.com (mailwhq01.cerner.com [159.140.1.66]) by nekhbet.cerner.com with ESMTP id MAA21613 for ; Tue, 18 Aug 1998 12:29:50 -0500 (CDT) Received: by mailwhq01.cerner.com with Internet Mail Service (5.5.1960.3) id ; Tue, 18 Aug 1998 12:29:50 -0500 Message-Id: From: "Brinkman,Bo" To: "'scwm-discuss@mit.edu'" Subject: Solaris Date: Tue, 18 Aug 1998 12:29:49 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-scwm-discuss@mit.edu Precedence: bulk Does anyone know if it is possible to use SCWM with Solaris? :) If you are a student, you can get a copy of Solaris (SPARC, Intel, or both) from www.sun.com/edu/solaris for 10$. I ordered a copy, but I am not sure what I am going to use it for. :) Bo Brinkman Cerner Corporation 2800 Rockcreek Parkway Kansas City, MO 64117 Phone (816) 201-3671 Email: bbrinkman@cerner.com From owner-scwm-discuss@mit.edu Tue Aug 18 13:33:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02950 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:33:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02946 for ; Tue, 18 Aug 1998 13:33:09 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA02679; Tue, 18 Aug 98 13:33:20 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA12546; Tue, 18 Aug 1998 10:32:38 -0700 (PDT) To: "Brinkman,Bo" Cc: "'scwm-discuss@mit.edu'" Subject: Re: Solaris References: From: Greg Badros Date: 18 Aug 1998 10:32:38 -0700 In-Reply-To: "Brinkman,Bo"'s message of "Tue, 18 Aug 1998 12:29:49 -0500" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Brinkman,Bo" writes: > Does anyone know if it is possible to use SCWM with Solaris? :) I've built it for Solaris w/o any memorable difficulty using gcc-2.7.2.1. Greg From owner-scwm-discuss@mit.edu Tue Aug 18 13:36:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA03013 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:36:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA03007 for ; Tue, 18 Aug 1998 13:35:57 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA03403; Tue, 18 Aug 98 13:36:05 EDT Received: by tis.bellhow.com; id NAA28160; Tue, 18 Aug 1998 13:35:26 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma028031; Tue, 18 Aug 98 13:34:45 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id NAA06273 for ; Tue, 18 Aug 1998 13:34:45 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: "'scwm-discuss@mit.edu'" Subject: Re: Solaris Date: Tue, 18 Aug 1998 17:34:45 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35dfbae5.436006123@smtp> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id NAA03008 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 18 Aug 1998 12:29:49 -0500, you wrote: >Does anyone know if it is possible to use SCWM with Solaris? :) >If you are a student, you can get a copy of Solaris (SPARC, Intel, or both) >from www.sun.com/edu/solaris for 10$. I ordered a copy, but I am not sure >what I am going to use it for. :) I use it all the time: uname -a: SunOS wgs 5.5 Generic sun4m sparc sun4m Dale From owner-scwm-discuss@mit.edu Tue Aug 18 13:57:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA03239 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:57:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA03236 for ; Tue, 18 Aug 1998 13:57:40 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA03852; Tue, 18 Aug 98 13:56:57 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA15346; Tue, 18 Aug 1998 13:57:10 -0400 (EDT) Message-Id: <199808181757.NAA15346@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a In-Reply-To: Your message of "18 Aug 1998 10:07:09 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Aug 1998 13:57:10 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Ahh... perhaps. Is it that your usleep function is failing? BSD? I > think Maciej was going to handle that problem since he has access to a > FreeBSD box.... BTW, just to be clear, I run NetBSD... .pm From owner-scwm-discuss@mit.edu Tue Aug 18 13:57:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA03234 for scwm-discuss-outgoing; Tue, 18 Aug 1998 13:57:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA03231 for ; Tue, 18 Aug 1998 13:57:35 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA03810; Tue, 18 Aug 98 13:56:51 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA15338; Tue, 18 Aug 1998 13:56:45 -0400 (EDT) Message-Id: <199808181756.NAA15338@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a In-Reply-To: Your message of "18 Aug 1998 10:07:09 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 18 Aug 1998 13:56:45 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > I wonder if this is in any way related to my (still unsolved) problem > > with double clicks not being recognised. > > Ahh... perhaps. Is it that your usleep function is failing? BSD? I > think Maciej was going to handle that problem since he has access to a > FreeBSD box.... I don't think it is (we have a lot of software that would break if usleep was broken) but I can easily run a test program if you can send one. > > BTW, in the course of testing this, I had to restart scwm several > > times. It pretty frequently hangs if I exit it and restart it with my > > .scwmrc, although scwm -f /dev/null does not hang. "go figure..." > > Do you start up any fvwm2 modules? There are some known problems with > restarts and fvwm2 module interactions causing a hang (that usually can > be un-hung by killing the fvwm2 module process(es). Yes, I do start an fvwm2 module (the pager). Is there any way to automatically get the pager killed when scwm exits? Perhaps a set of on-exit hooks and a signal catcher to assure they are executed? .pm From owner-scwm-discuss@mit.edu Tue Aug 18 14:20:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA03485 for scwm-discuss-outgoing; Tue, 18 Aug 1998 14:20:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA03482 for ; Tue, 18 Aug 1998 14:20:43 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA10230; Tue, 18 Aug 98 14:19:59 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA12947; Tue, 18 Aug 1998 11:20:11 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: bad problems with 0.8a References: <199808181756.NAA15338@jekyll.piermont.com> From: Greg Badros Date: 18 Aug 1998 11:20:07 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Tue, 18 Aug 1998 13:56:45 -0400" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > > I wonder if this is in any way related to my (still unsolved) problem > > > with double clicks not being recognised. > > > > Ahh... perhaps. Is it that your usleep function is failing? BSD? I > > think Maciej was going to handle that problem since he has access to a > > FreeBSD box.... > > I don't think it is (we have a lot of software that would break if > usleep was broken) but I can easily run a test program if you can send > one. I don't have time right now... It's not necessarily that your usleep is broken, just that the way scwm tries to get at your usleep may be broken. I'm afraid it makes the most sense to leave this to Maciej. I'll have time again after I get my paper off to the ICSE submissions folks. If you get motivated and figure it out, please let us know the fix. > > > BTW, in the course of testing this, I had to restart scwm several > > > times. It pretty frequently hangs if I exit it and restart it with my > > > .scwmrc, although scwm -f /dev/null does not hang. "go figure..." > > > > Do you start up any fvwm2 modules? There are some known problems with n> > restarts and fvwm2 module interactions causing a hang (that usually can > > be un-hung by killing the fvwm2 module process(es). > > Yes, I do start an fvwm2 module (the pager). Is there any way to > automatically get the pager killed when scwm exits? Perhaps a set of > on-exit hooks and a signal catcher to assure they are executed? There are on-exit hooks, but they might not be called on a restart. You could add a "(kill-all-fvwm2-modules)" before doing the restart when the option is selected from a menu. The right fix is for us to remove the race condition, but again, things are hectic for me now -- I'm trying to keep up with emails, but little else besides my paper deadline (plus I'm moving a week from yesterday). Greg From owner-scwm-discuss@mit.edu Tue Aug 18 14:23:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA03519 for scwm-discuss-outgoing; Tue, 18 Aug 1998 14:23:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA03516 for ; Tue, 18 Aug 1998 14:23:22 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA16571; Tue, 18 Aug 98 14:23:33 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA02251; Tue, 18 Aug 1998 11:22:52 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199808181822.LAA02251@fielder.cs.washington.edu> Subject: Re: Solaris To: dale.smith@bellhow.com Date: Tue, 18 Aug 1998 11:22:52 -0700 (PDT) Cc: scwm-discuss@mit.edu In-Reply-To: <35dfbae5.436006123@smtp> from "Dale Smith" at Aug 18, 98 05:34:45 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk > >Does anyone know if it is possible to use SCWM with Solaris? :) > >If you are a student, you can get a copy of Solaris (SPARC, Intel, or both) > >from www.sun.com/edu/solaris for 10$. I ordered a copy, but I am not sure > >what I am going to use it for. :) > > I use it all the time: uname -a: SunOS wgs 5.5 Generic sun4m sparc sun4m I'm a happy customer of scwm on Solaris (actually, I'm using the copy that Greg built). Just for the record, here's my uname -a: SunOS fielder 5.5.1 Generic_103640-08 sun4u sparc SUNW,Ultra-1 -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Tue Aug 18 15:05:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03837 for scwm-discuss-outgoing; Tue, 18 Aug 1998 15:05:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA03829 for ; Tue, 18 Aug 1998 15:04:57 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA28452; Tue, 18 Aug 98 15:05:07 EDT Received: from mute.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfczs05025; Tue, 18 Aug 1998 19:04:29 GMT Received: (from sds@localhost) by mute.eaglets.com (8.9.1/8.9.1) id PAA04287; Tue, 18 Aug 1998 15:04:27 -0400 To: "Brinkman,Bo" Cc: "'scwm-discuss@mit.edu'" Subject: Re: Solaris References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: "Brinkman,Bo"'s message of "Tue, 18 Aug 1998 12:29:49 -0500" Date: 18 Aug 1998 15:04:27 -0400 Message-Id: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on Tue, 18 Aug 1998 12:29:49 -0500 >>>> Honorable "Brinkman,Bo" writes >>>> on the subject of "Solaris": >> If you are a student, you can get a copy of Solaris (SPARC, Intel, or both) >> from www.sun.com/edu/solaris for 10$. even if you are not a student, you can get a copy of GNU/Linux for under $2.00 for Intel/Sparc/Alpha. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Wed Aug 19 03:15:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA06789 for scwm-discuss-outgoing; Wed, 19 Aug 1998 03:15:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA06786 for ; Wed, 19 Aug 1998 03:15:51 -0400 From: mal@bewoner.dma.be Received: from dialup246.brussels.skynet.be by MIT.EDU with SMTP id AA03267; Wed, 19 Aug 98 03:14:51 EDT Received: (qmail 15982 invoked by uid 500); 19 Aug 1998 07:24:26 -0000 Date: 19 Aug 1998 07:24:25 -0000 Message-Id: <19980819072425.15980.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Brinkman,Bo" Cc: "'scwm-discuss@mit.edu'" Subject: Solaris In-Reply-To: References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Brinkman,Bo writes: > Does anyone know if it is possible to use SCWM with Solaris? :) Yes. I'm using it on an UltraSparc with Solaris 2.5. It should work quite easily if you compile with gcc. To compile it with the Sunpro compiler you need to tweak some makefiles. I wouldn't advise you to try to compile it with the "free" /usr/ucb/cc since it is quite buggy. Lieven From owner-scwm-discuss@mit.edu Wed Aug 19 08:51:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA08473 for scwm-discuss-outgoing; Wed, 19 Aug 1998 08:51:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA08470 for ; Wed, 19 Aug 1998 08:51:52 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA04739 for scwm-discuss@huis-clos.mit.edu; Wed, 19 Aug 1998 14:51:15 +0200 (CEST) Received: (qmail 1012 invoked by uid 115); 19 Aug 1998 09:08:24 -0000 To: scwm-discuss@mit.edu Subject: Re: Solaris Reply-To: robbe@orcus.priv.at References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 19 Aug 1998 11:08:23 +0200 In-Reply-To: Sam Steingold's message of "18 Aug 1998 15:04:27 -0400" Message-ID: Lines: 28 X-Mailer: Gnus v5.6.31/XEmacs 20.4 - "Emerald" X-Now-Playing: bob marley roots disc1 05-zig zag Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 18 Aug 1998 15:04:27 -0400 >>>>> Sam Steingold said: >>>>> In message >>>>> >>>>> Sent on Tue, 18 Aug 1998 12:29:49 -0500 Honorable "Brinkman,Bo" >>>>> writes on the subject of "Solaris": >>> If you are a student, you can get a copy of Solaris (SPARC, >>> Intel, or both) from www.sun.com/edu/solaris for 10$. Sam> even if you are not a student, you can get a copy of GNU/Linux Sam> for under $2.00 for Intel/Sparc/Alpha. Aaargh, the dreaded OS war! [getting completely off-topic, so heed the reply-to] The $10 are allegedly media and shipping costs. Solaris is obviously such a niche product that they can't sell their research-versions through stores or local distributors - they only ship from US HQ. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Aug 19 13:07:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10072 for scwm-discuss-outgoing; Wed, 19 Aug 1998 13:07:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10069 for ; Wed, 19 Aug 1998 13:07:37 -0400 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA07010; Wed, 19 Aug 98 13:06:41 EDT Received: from mizar (root@ppp21-nas0.vi.nettuno.it [193.207.146.230]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id TAA20116 for ; Wed, 19 Aug 1998 19:06:53 +0200 (MDT) Received: by mizar id m0z97y3-0008SRC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 19 Aug 1998 15:07:39 +0200 (CEST) Message-Id: <19980819150759.38835@mizar> Date: Wed, 19 Aug 1998 15:07:59 +0200 From: Francesco Tapparo To: scwm-discuss@mit.edu Subject: scwm and TrollTeck's QT Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i Sender: owner-scwm-discuss@mit.edu Precedence: bulk Rob Browning warned me that my scwm package was linked to the TrollTeck's QT library. I removed the library from my system, I recompiled and all went OK; so this seems be a configure.in problem, more precisely in the following line: AC_CHECK_LIB(qt, main, GUILE_LIBS="-lqt $GUILE_LIBS",, $GUILE_LIBS_PRE) This line check the existence of the libqt.so library, and this is the name of the TrollTeck QT, if it is installed on the system. I checked in my guile-1.3 snapshot (19980626), and it seems that the libquickthreads library (prolly the true objective of previous check) is installed as libquickthreads, and not libqt. I'm using guile-1.2. Francesco From owner-scwm-discuss@mit.edu Wed Aug 19 13:39:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10261 for scwm-discuss-outgoing; Wed, 19 Aug 1998 13:39:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10258 for ; Wed, 19 Aug 1998 13:39:33 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA13439; Wed, 19 Aug 98 13:39:29 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA15697; Wed, 19 Aug 1998 10:38:32 -0700 (PDT) To: f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: scwm and TrollTeck's QT References: <19980819150759.38835@mizar> From: Greg Badros Date: 19 Aug 1998 10:38:32 -0700 In-Reply-To: Francesco Tapparo's message of "Wed, 19 Aug 1998 15:07:59 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francesco Tapparo writes: > Rob Browning warned me that my scwm package was linked to the TrollTeck's > QT library. I removed the library from my system, I recompiled and all went > OK; so this seems be a configure.in problem, more precisely in the following > line: > > AC_CHECK_LIB(qt, main, GUILE_LIBS="-lqt $GUILE_LIBS",, $GUILE_LIBS_PRE) > > This line check the existence of the libqt.so library, and this is the name > of the TrollTeck QT, if it is installed on the system. I checked in my > guile-1.3 snapshot (19980626), and it seems that the libquickthreads library > (prolly the true objective of previous check) is installed as libquickthreads, > and not libqt. > > I'm using guile-1.2. Hmmm.. I though 1.2 used the name libqt.so -- almost a year ago I asked Jim Blandy and David Keppel (author of QuickThreads library) about this, and everyone agreed that a name change was the best option, but I didn't realize that the change made it into guile-1.2. A little while back I noticed that we were still looking for libqt, but I thought it prudent until guile-1.3 came out. I'll double-check 1.2 uses the new name and then fix the configure.in specification. Thanks for alerting me to this again. Greg From owner-scwm-discuss@mit.edu Wed Aug 19 16:51:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA11021 for scwm-discuss-outgoing; Wed, 19 Aug 1998 16:51:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA11018 for ; Wed, 19 Aug 1998 16:51:15 -0400 Received: from scatterbrain.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA06499; Wed, 19 Aug 98 16:50:19 EDT Received: (from esuci@localhost) by scatterbrain.dcs.warwick.ac.uk (8.8.8/8.8.8) id VAA23857 for scwm-discuss@mit.edu; Wed, 19 Aug 1998 21:50:32 +0100 (BST) Message-Id: <19980819215031.A22785@dcs.warwick.ac.uk> Date: Wed, 19 Aug 1998 21:50:31 +0100 From: Michael Stevens To: scwm-discuss@mit.edu Subject: configure.in patch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi. The following patch to configure.in should hopefully a) fix problems with building scwm when --with-guile-prefix is used - it wasn't setting the run-time search path. It also exits with an error when Xpm or Xmu aren't found, instead of trying to build and failing because the link options aren't defined. You may want to change the AC_MSG_ERROR's to AC_MSG_WARN's to give people the chance to hand-edit the makefiles. It improves things for me, but I'm not 100% it's the Right Way to do these things... Unified diff against configure.in: --- ./configure.old Wed Aug 19 21:25:17 1998 +++ ./configure.in Wed Aug 19 21:43:41 1998 @@ -114,7 +114,8 @@ AC_CHECK_LIB(Xpm, XpmReadFileToPixmap, [ XPM_LIB="-lXpm" AC_DEFINE(HAVE_LIBXPM) -], , $x_libs) +], AC_MSG_ERROR(WARNING: Xpm library not found - scwm may not build correctly) +, $x_libs) dnl # Check for the Xmu library # @@ -122,7 +123,8 @@ AC_CHECK_LIB(Xmu, XmuPrintDefaultErrorMessage, [ XMU_LIB="-lXmu" AC_DEFINE(HAVE_LIBXMU) -], , $x_libs) +], AC_MSG_ERROR(WARNING: Xmu library not found - scwm may not build correctly) +, $x_libs) x_cflags="$X_CFLAGS" @@ -184,7 +186,7 @@ AC_MSG_CHECKING(where to expect to find guile) guile_prefix="${withval}" GUILE_INCLUDES="-I${guile_prefix}/include" - GUILE_LIBS_PRE="-L${guile_prefix}/lib" + GUILE_LIBS_PRE="-L${guile_prefix}/lib -R${guile_prefix}/lib" AC_MSG_RESULT("${guile_prefix}") fi @@ -201,7 +203,7 @@ else AC_MSG_CHECKING(where to expect to find guile binaries) guile_exec_prefix="${withval}" - GUILE_LIBS_PRE="-L${guile_exec_prefix}/lib" + GUILE_LIBS_PRE="-L${guile_exec_prefix}/lib -R${guile_exec_prefix}/lib" AC_MSG_RESULT("${guile_exec_prefix}") fi From owner-scwm-discuss@mit.edu Wed Aug 19 17:21:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA11202 for scwm-discuss-outgoing; Wed, 19 Aug 1998 17:21:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA11199 for ; Wed, 19 Aug 1998 17:21:17 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA17535; Wed, 19 Aug 98 17:21:16 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA19963; Wed, 19 Aug 1998 14:20:09 -0700 (PDT) To: Michael Stevens Cc: scwm-discuss@mit.edu Subject: Re: configure.in patch References: <19980819215031.A22785@dcs.warwick.ac.uk> From: Greg Badros Date: 19 Aug 1998 14:20:08 -0700 In-Reply-To: Michael Stevens's message of "Wed, 19 Aug 1998 21:50:31 +0100" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Michael Stevens writes: > Hi. > The following patch to configure.in should hopefully a) fix problems > with building scwm when --with-guile-prefix is used - it wasn't setting the > run-time search path. It also exits with an error when Xpm or Xmu aren't > found, instead of trying to build and failing because the link options > aren't defined. You may want to change the AC_MSG_ERROR's to AC_MSG_WARN's to > give people the chance to hand-edit the makefiles. Thanks for the patch! It'll make it in when things settle down for me. > > It improves things for me, but I'm not 100% it's the Right Way to do > these things... I don't think *anybody*'s 100% sure when it comes to autoconf and automake! :-) Thanks, Greg From owner-scwm-discuss@mit.edu Wed Aug 19 17:30:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA11302 for scwm-discuss-outgoing; Wed, 19 Aug 1998 17:30:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA11299 for ; Wed, 19 Aug 1998 17:30:35 -0400 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA19637; Wed, 19 Aug 98 17:30:33 EDT Received: from mizar (root@ppp11-nas0.vi.nettuno.it [193.207.146.220]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id XAA02751; Wed, 19 Aug 1998 23:29:45 +0200 (MDT) Received: by mizar id m0z9FeP-0008RVC (Debian Smail-3.2 1996-Jul-4 #2); Wed, 19 Aug 1998 23:19:53 +0159 (CEST) Message-Id: <19980819232013.48376@mizar> Date: Wed, 19 Aug 1998 23:20:13 +0200 From: Francesco Tapparo To: Greg Badros , f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: scwm and TrollTeck's QT Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: Greg Badros , f.tapparo@vi.nettuno.it, scwm-discuss@mit.edu References: <19980819150759.38835@mizar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1i In-Reply-To: ; from Greg Badros on Wed, Aug 19, 1998 at 10:38:32AM -0700 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, Aug 19, 1998 at 10:38:32AM -0700, Greg Badros wrote: > Francesco Tapparo writes: > > > This line check the existence of the libqt.so library, and this is the name > > of the TrollTeck QT, if it is installed on the system. I checked in my > > guile-1.3 snapshot (19980626), and it seems that the libquickthreads library > > (prolly the true objective of previous check) is installed as libquickthreads, > > and not libqt. > > > > I'm using guile-1.2. > > Hmmm.. I though 1.2 used the name libqt.so -- almost a year ago I asked > Jim Blandy and David Keppel (author of QuickThreads library) about this, > and everyone agreed that a name change was the best option, but I didn't > realize that the change made it into guile-1.2. > > A little while back I noticed that we were still looking for libqt, but > I thought it prudent until guile-1.3 came out. I'll double-check 1.2 > uses the new name and then fix the configure.in specification. > > Thanks for alerting me to this again. > Perhaps I've been not very clear: my guile 1.3 snapshot has libquickthreads, my libguile2 (guile 1.2) debian package has not the libqt.so (perhaps it was excluded by the debian maintainer for some reason); so I thought that libquickthreads was only a guile 1.3 thing. Sorry for the misunderstanding Francesco From owner-scwm-discuss@mit.edu Wed Aug 19 18:01:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA11499 for scwm-discuss-outgoing; Wed, 19 Aug 1998 18:01:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA11496 for ; Wed, 19 Aug 1998 18:01:37 -0400 Received: from tolt.cs.washington.edu by MIT.EDU with SMTP id AA26106; Wed, 19 Aug 98 18:01:31 EDT Received: (gjb@localhost) by tolt.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA20047; Wed, 19 Aug 1998 15:00:47 -0700 (PDT) To: f.tapparo@vi.nettuno.it Cc: scwm-discuss@mit.edu Subject: Re: scwm and TrollTeck's QT References: <19980819150759.38835@mizar> <19980819232013.48376@mizar> From: Greg Badros Date: 19 Aug 1998 15:00:47 -0700 In-Reply-To: Francesco Tapparo's message of "Wed, 19 Aug 1998 23:20:13 +0200" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francesco Tapparo writes: > On Wed, Aug 19, 1998 at 10:38:32AM -0700, Greg Badros wrote: > > Francesco Tapparo writes: > > > > > This line check the existence of the libqt.so library, and this is the name > > > of the TrollTeck QT, if it is installed on the system. I checked in my > > > guile-1.3 snapshot (19980626), and it seems that the libquickthreads library > > > (prolly the true objective of previous check) is installed as libquickthreads, > > > and not libqt. > > > > > > I'm using guile-1.2. > > > > Hmmm.. I though 1.2 used the name libqt.so -- almost a year ago I asked > > Jim Blandy and David Keppel (author of QuickThreads library) about this, > > and everyone agreed that a name change was the best option, but I didn't > > realize that the change made it into guile-1.2. > > > > A little while back I noticed that we were still looking for libqt, but > > I thought it prudent until guile-1.3 came out. I'll double-check 1.2 > > uses the new name and then fix the configure.in specification. > > > > Thanks for alerting me to this again. > > > > Perhaps I've been not very clear: my guile 1.3 snapshot has > libquickthreads, my libguile2 (guile 1.2) debian package has not the libqt.so > (perhaps it was excluded by the debian maintainer for some reason); so I > thought that libquickthreads was only a guile 1.3 thing. Ahh... okay. One can build guile w/o threads support, and the debian maintainer might have done that. We'll clean this up much better once guile-1.3 comes out and we completely ignore 1.2 (I've had reports that scwm has trouble w/ guile-1.2, but haven't had time to try it myself, and probably won't). > Sorry for the misunderstanding No problem. Thanks for the clarification. Greg From owner-scwm-discuss@mit.edu Wed Aug 19 18:08:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA11562 for scwm-discuss-outgoing; Wed, 19 Aug 1998 18:08:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA11559 for ; Wed, 19 Aug 1998 18:08:15 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA22858; Wed, 19 Aug 98 18:07:17 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id XAA17835 for ; Wed, 19 Aug 1998 23:07:31 +0100 Date: Wed, 19 Aug 1998 23:07:31 +0100 (BST) From: Danius Michaelides To: scwm-discuss@mit.edu Subject: Focus, FocusOn and Raise Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Currently, calling focus, focuses the window and also raises it. Why is this? FocusOn() has a RaiseWindow() call in it (something which is #ifdefed out in the fvwm source). And! default-winlist-proc has deiconify, focus, raise-window, warp-to-window and then move-pointer. So i'm guessing that the RaiseWindow has slipped its way back into FocusOn(). Same goes for WarpOn()? Danius From owner-scwm-discuss@mit.edu Wed Aug 19 18:50:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA11822 for scwm-discuss-outgoing; Wed, 19 Aug 1998 18:50:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA11819 for ; Wed, 19 Aug 1998 18:50:17 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA00133; Wed, 19 Aug 98 18:49:20 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA09945; Wed, 19 Aug 1998 15:49:23 -0700 (PDT) To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: Focus, FocusOn and Raise References: From: Greg Badros Date: 19 Aug 1998 15:49:22 -0700 In-Reply-To: Danius Michaelides's message of "Wed, 19 Aug 1998 23:07:31 +0100 (BST)" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Danius Michaelides writes: > Currently, calling focus, focuses the window and also raises it. Why > is this? FocusOn() has a RaiseWindow() call in it (something which is > #ifdefed out in the fvwm source). And! default-winlist-proc has > deiconify, focus, raise-window, warp-to-window and then move-pointer. > So i'm guessing that the RaiseWindow has slipped its way back into > FocusOn(). Same goes for WarpOn()? I'll look into it. In a quick peek, it does look wrong. Thanks! Greg From owner-scwm-discuss@mit.edu Thu Aug 20 15:04:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA17018 for scwm-discuss-outgoing; Thu, 20 Aug 1998 15:04:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA17015 for ; Thu, 20 Aug 1998 15:03:57 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11029; Thu, 20 Aug 98 15:03:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA26439; Thu, 20 Aug 1998 12:03:02 -0700 (PDT) To: Danius Michaelides Cc: scwm-discuss@mit.edu Subject: Re: Focus, FocusOn and Raise References: From: Greg Badros Date: 20 Aug 1998 12:03:02 -0700 In-Reply-To: Danius Michaelides's message of "Wed, 19 Aug 1998 23:07:31 +0100 (BST)" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Danius Michaelides writes: > Currently, calling focus, focuses the window and also raises it. Why > is this? FocusOn() has a RaiseWindow() call in it (something which is > #ifdefed out in the fvwm source). And! default-winlist-proc has > deiconify, focus, raise-window, warp-to-window and then move-pointer. > So i'm guessing that the RaiseWindow has slipped its way back into > FocusOn(). Same goes for WarpOn()? Ok, fixed in my working copy, will commit before tonight's snapshot. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Aug 20 15:06:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA17036 for scwm-discuss-outgoing; Thu, 20 Aug 1998 15:06:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA17032 for ; Thu, 20 Aug 1998 15:06:03 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19526; Thu, 20 Aug 98 15:04:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA26442; Thu, 20 Aug 1998 12:05:03 -0700 (PDT) To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: scwm-0.8 nits References: <19980817101542.A26149@vt.edu> From: Greg Badros Date: 20 Aug 1998 12:05:02 -0700 In-Reply-To: Craig Struble's message of "Mon, 17 Aug 1998 10:15:42 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig Struble writes: > Second, anything with a sticky icon has its icon placed where the > top left corner of the window is placed. Moving the icon by hand > doesn't even work. You deiconify and iconify again, and poof, the > icon is back at the top left corner. Non-sticky icons work fine. > Is there any hope of having sticky icons going back to their old > behavior, being treated basically like non-sticky ones and put into > icon boxes, etc.? Try it in tonight's snapshot... I've changed the behaviour and I think it's closer to being "right" but I don't use icons that much so may not be the best judge. Still looking into your other questions. Greg From owner-scwm-discuss@mit.edu Thu Aug 20 15:34:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA17463 for scwm-discuss-outgoing; Thu, 20 Aug 1998 15:34:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA17460 for ; Thu, 20 Aug 1998 15:34:08 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19502; Thu, 20 Aug 98 15:33:56 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA26454; Thu, 20 Aug 1998 12:33:09 -0700 (PDT) To: Michael Stevens Cc: scwm-discuss@mit.edu Subject: Re: configure.in patch References: <19980819215031.A22785@dcs.warwick.ac.uk> From: Greg Badros Date: 20 Aug 1998 12:33:09 -0700 In-Reply-To: Michael Stevens's message of "Wed, 19 Aug 1998 21:50:31 +0100" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Michael Stevens writes: > Hi. > The following patch to configure.in should hopefully a) fix problems > with building scwm when --with-guile-prefix is used - it wasn't setting the > run-time search path. It also exits with an error when Xpm or Xmu aren't > found, instead of trying to build and failing because the link options > aren't defined. You may want to change the AC_MSG_ERROR's to AC_MSG_WARN's to > give people the chance to hand-edit the makefiles. The first fix is taken care of a bit better by using the ac_R_nospace variable as S.Senda's patch does (I just made those changes today). The warning on not finding libXpm is a good thing -- I added it as a AC_MSG_WARN. The lack of libXmu is no big deal, though, and is not worth warning about (and certainly not worth aborting). Thanks for the fix! Greg From owner-scwm-discuss@mit.edu Thu Aug 20 15:35:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA17479 for scwm-discuss-outgoing; Thu, 20 Aug 1998 15:35:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA17476 for ; Thu, 20 Aug 1998 15:35:45 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA27271; Thu, 20 Aug 98 15:34:37 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA26457; Thu, 20 Aug 1998 12:34:45 -0700 (PDT) To: senda@ic.rdc.ricoh.co.jp Cc: scwm-discuss@mit.edu Subject: Re: fix in I18N and Solaris '-R' ld option problem References: <19980730131645Q.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 20 Aug 1998 12:34:45 -0700 In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Thu, 30 Jul 1998 13:16:45 +0900" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk senda@ic.rdc.ricoh.co.jp writes: > Hi, > > I tried to compile scwm-19980728 with --enable-multibyte > on Solaris 2.5.1 (X11R6.3 with X_LOCALE compile-option) and FreeBSD 2.2.6R. > > Here is fixes to work these environments : > > - X_LOCALE > I18N code doesn't care that X11 was compiled with X_LOCALE. > > - '-R' ld option is needed on Solaris environment > Scwm can't find guile libraries when it is in non-standard > library path at run-time. 'autoconf' automatically fix in case of > x-library path (see configure script at -R check), but do > nothing about other libraries path. (This problem is fixed by > setting LD_LIBRARY_PATH at run-time. but I don't want to set it.) > > - xpg4 library is needed to use 'real' locale system in FreeBSD > libc in FreeBSD has locale system. but it is a fake code. It > is necessary to link xpg4 library to use real locale system. > > Please check my fixes. Looked pretty good to me. The only thing I changed was editing acconfig.h instead of include/config.h.in (the latter is auto-generated -- I know it's a maze of configuration files, but that's the price we pay for automake and autoconf support). Please test tonight's snapshot and see if the locale code is working okay for you directly. Thanks! Greg From owner-scwm-discuss@mit.edu Thu Aug 20 17:06:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18050 for scwm-discuss-outgoing; Thu, 20 Aug 1998 17:06:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18047 for ; Thu, 20 Aug 1998 17:06:25 -0400 Received: from silly.dcs.warwick.ac.uk by MIT.EDU with SMTP id AA21576; Thu, 20 Aug 98 17:05:16 EDT Received: (from esuci@localhost) by silly.dcs.warwick.ac.uk (8.8.8/8.8.8) id WAA20297; Thu, 20 Aug 1998 22:05:21 +0100 (BST) Message-Id: <19980820220519.A20142@dcs.warwick.ac.uk> Date: Thu, 20 Aug 1998 22:05:19 +0100 From: Michael Stevens To: Greg Badros , Michael Stevens Cc: scwm-discuss@mit.edu Subject: Re: configure.in patch References: <19980819215031.A22785@dcs.warwick.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Greg Badros on Thu, Aug 20, 1998 at 12:33:09PM -0700 X-Cabal: There is no cabal Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Aug 20, 1998 at 12:33:09PM -0700, Greg Badros wrote: > Michael Stevens writes: > > Hi. > > The following patch to configure.in should hopefully a) fix problems > > with building scwm when --with-guile-prefix is used - it wasn't setting the > > run-time search path. It also exits with an error when Xpm or Xmu aren't > > found, instead of trying to build and failing because the link options > > aren't defined. You may want to change the AC_MSG_ERROR's to AC_MSG_WARN's to > > give people the chance to hand-edit the makefiles. > The first fix is taken care of a bit better by using the ac_R_nospace > variable as S.Senda's patch does (I just made those changes today). Great! I had by doubts about whether it was the right way to do things, as I said. I'm just glad things are fixed. > The warning on not finding libXpm is a good thing -- I added it as a > AC_MSG_WARN. The lack of libXmu is no big deal, though, and is not > worth warning about (and certainly not worth aborting). I added that one in on the principle that I was doing Xpm, it was right next to it, and I figured that if we were asking for a library we probably needed it :). I'm not actually aware of libXmu's function. Thanks for apparently getting _something_ useful out of it, anyway ;) -- "Why do we have to hide from the police, Daddy?" "Because we use vi, son. They use emacs." (Contributed by Iain Scott.) From owner-scwm-discuss@mit.edu Thu Aug 20 17:08:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18061 for scwm-discuss-outgoing; Thu, 20 Aug 1998 17:08:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18058 for ; Thu, 20 Aug 1998 17:08:48 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA22123; Thu, 20 Aug 98 17:07:40 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA28947; Thu, 20 Aug 1998 14:07:49 -0700 (PDT) To: Michael Stevens Cc: scwm-discuss@mit.edu Subject: Re: configure.in patch References: <19980819215031.A22785@dcs.warwick.ac.uk> <19980820220519.A20142@dcs.warwick.ac.uk> From: Greg Badros Date: 20 Aug 1998 14:07:49 -0700 In-Reply-To: Michael Stevens's message of "Thu, 20 Aug 1998 22:05:19 +0100" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Michael Stevens writes: > > The warning on not finding libXpm is a good thing -- I added it as a > > AC_MSG_WARN. The lack of libXmu is no big deal, though, and is not > > worth warning about (and certainly not worth aborting). > > I added that one in on the principle that I was doing Xpm, it was right next > to it, and I figured that if we were asking for a library we probably needed > it :). I'm not actually aware of libXmu's function. > > Thanks for apparently getting _something_ useful out of it, anyway ;) Definitely. Thanks for sending the patch -- it's the most reliable way to get me to look at something. The change for Xpm is nice and there are probably other places where we should do something similar. Greg From owner-scwm-discuss@mit.edu Thu Aug 20 17:43:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18433 for scwm-discuss-outgoing; Thu, 20 Aug 1998 17:43:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18430 for ; Thu, 20 Aug 1998 17:43:48 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23899; Thu, 20 Aug 98 17:43:36 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA29242; Thu, 20 Aug 1998 14:42:51 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: squashed-title References: From: Greg Badros Date: 20 Aug 1998 14:42:50 -0700 In-Reply-To: Robert Bihlmeyer's message of "15 Aug 1998 13:27:55 +0200" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> Glad you like the squashed titlebars. We'll definitely have > Greg> fully-featured squashed titlebars after the decoration rewrite. > > A critical bug at the moment is that going from squashed to > no-squashed does not work: the shape masks seems to stay in place - > try maximizing a window after that. Ok, this is now fixed, but you still have to resize the window before the change takes affect if you set the object property directly. Does anybody have a good pointer to documentation for the XShape extension to X11? The man page stinks, and a web search turned up no useful hits for me. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Aug 20 17:55:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18559 for scwm-discuss-outgoing; Thu, 20 Aug 1998 17:55:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18556 for ; Thu, 20 Aug 1998 17:55:01 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26105; Thu, 20 Aug 98 17:54:48 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id AAA31317 for ; Fri, 21 Aug 1998 00:53:54 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id AAA21067; Fri, 21 Aug 1998 00:53:53 +0300 To: scwm-discuss@mit.edu Subject: toggle-maximize in 0.8a From: abel@bfr.co.il (Alexander L. Belikoff) Date: 21 Aug 1998 00:53:53 +0300 Message-Id: Lines: 28 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi everybody, In 0.8a (built on RedHat 4.2 with a Guile snapshot of 980806) calling toggle-maximize with no arguments (by mistake) crashes the window manager with the following diagnostics: /home/abel/.scwmrc:342:3: While evaluating arguments to popup-menu in expression (popup-menu util-menu): /home/abel/.scwmrc:342:3: Unbound variable: util-menu Backtrace: 0* [popup-util] 1* [popup-menu ... /home/abel/.scwmrc:342:3: While evaluating arguments to popup-menu in expression (popup-menu util-menu): /home/abel/.scwmrc:342:3: Unbound variable: util-menu Backtrace: 0* [toggle-maximize] Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Thu Aug 20 18:52:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA18887 for scwm-discuss-outgoing; Thu, 20 Aug 1998 18:52:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA18884 for ; Thu, 20 Aug 1998 18:52:28 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06456; Thu, 20 Aug 98 18:52:10 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA00643; Thu, 20 Aug 1998 15:51:05 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: toggle-maximize in 0.8a References: From: Greg Badros Date: 20 Aug 1998 15:51:04 -0700 In-Reply-To: abel@bfr.co.il's message of "21 Aug 1998 00:53:53 +0300" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Hi everybody, > > In 0.8a (built on RedHat 4.2 with a Guile snapshot of 980806) calling > toggle-maximize with no arguments (by mistake) crashes the window > manager with the following diagnostics: > > > /home/abel/.scwmrc:342:3: While evaluating arguments to popup-menu in expression (popup-menu util-menu): > /home/abel/.scwmrc:342:3: Unbound variable: util-menu > > Backtrace: > 0* [popup-util] > 1* [popup-menu ... > > /home/abel/.scwmrc:342:3: While evaluating arguments to popup-menu in expression (popup-menu util-menu): > /home/abel/.scwmrc:342:3: Unbound variable: util-menu > > Backtrace: > 0* [toggle-maximize] Is this reproducible for you? I get the expected error message w/o any problems. Do you have any thoughts about why util-menu is involved? Thanks, Greg From owner-scwm-discuss@mit.edu Thu Aug 20 21:37:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA19901 for scwm-discuss-outgoing; Thu, 20 Aug 1998 21:37:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA19898 for ; Thu, 20 Aug 1998 21:37:48 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA00893; Thu, 20 Aug 98 21:36:30 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id KAA17528 for ; Fri, 21 Aug 1998 10:36:46 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id KAA29941 for ; Fri, 21 Aug 1998 10:36:44 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id KAA19960; Fri, 21 Aug 1998 10:37:58 +0900 To: scwm-discuss@mit.edu Subject: Re: fix in I18N and Solaris '-R' ld option problem In-Reply-To: Your message of "20 Aug 1998 12:34:45 -0700" References: X-Mailer: Mew version 1.93b38 on XEmacs 21.2 (Aeolus) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980821103757Q.senda@ic.rdc.ricoh.co.jp> Date: Fri, 21 Aug 1998 10:37:57 +0900 X-Dispatcher: imput version 980522 Lines: 21 Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb> Looked pretty good to me. The only thing I changed was editing gjb> acconfig.h instead of include/config.h.in (the latter is auto-generated gjb> -- I know it's a maze of configuration files, but that's the price we gjb> pay for automake and autoconf support). Oh, it's my careless miss. gjb> Please test tonight's snapshot and see if the locale code is working gjb> okay for you directly. gjb> gjb> Thanks! gjb> Greg gjb> I'll try it. Thanks!!! S.Senda From owner-scwm-discuss@mit.edu Fri Aug 21 06:06:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA22477 for scwm-discuss-outgoing; Fri, 21 Aug 1998 06:06:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from platon.ida.ing.tu-bs.de (platon.ida.ing.tu-bs.de [134.169.29.55]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id GAA22474 for ; Fri, 21 Aug 1998 06:06:37 -0400 Received: from localhost (dirk@localhost) by platon.ida.ing.tu-bs.de (8.9.1/8.9.1) with SMTP id MAA21731 for ; Fri, 21 Aug 1998 12:03:22 +0200 (CEST) Date: Fri, 21 Aug 1998 12:03:07 +0200 (CEST) From: Dirk Herrmann X-Sender: dirk@platon To: scwm-discuss@mit.edu Subject: SCWM configure.in and build-guile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello everybody! When trying to buile scwm-0.8a I run into problems, because some older guile without build-guile is installed on the system, but I want to use a newer version in my own directory tree. I assume this is due to a bug in configure.in, which I had previously reported to Maciej. In the meanwhile, I have experimented a bit with autoconf and guess I could submit a patch next week if you are interested and have not yet solved the problem anyway. Best regards, Dirk Herrmann ---------- Forwarded message ---------- Date: Tue, 11 Aug 1998 12:21:32 +0200 (CEST) From: Dirk Herrmann To: Maciej Stachowiak Subject: SCWM configure.in and build-guile Hi! I was just trying to figure out how you check for guile in the SCWM configuration and realized the following problem: The test for BUILD_GUILE is performed before the --with-guile-prefix and --with-guile-exec-prefix are evaluated. I assume that this could lead to problems when a user points configure to a version of guile that is not in the path: GUILE_LIBS could get it's value from a different version of guile. Sorry that I cannot submit a patch, I'm just learning about autoconf. (This was the reason I looked into configure.in) Best regards, Dirk Herrmann From owner-scwm-discuss@mit.edu Fri Aug 21 09:54:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA23323 for scwm-discuss-outgoing; Fri, 21 Aug 1998 09:54:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA23320 for ; Fri, 21 Aug 1998 09:54:03 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA15233; Fri, 21 Aug 98 09:53:43 EDT Received: by tis.bellhow.com; id JAA27098; Fri, 21 Aug 1998 09:53:03 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma026971; Fri, 21 Aug 98 09:52:34 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id JAA00744; Fri, 21 Aug 1998 09:52:33 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager Date: Fri, 21 Aug 1998 13:52:33 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35e777af.680941462@smtp> References: <35a22b36.693727297@mailhost> <35e5a795.627668379@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA23321 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 20 Aug 1998 16:01:21 -0700, you wrote: >I think we underestimated a couple of the strengths of the design of the >fvwm2 module system. Specifically, as a separate process, fvwm2 modules >cannot (directly, anyway) crash scwm, which is a huge win. There are >some tough issues to resolve before we get a nice extension system, but >the event rewrite will be a huge step in the right direction, and that >isn't too far off. > >What do you mean about "dragging a view around"? I do care about the >big things with the pager.... > >Greg Mouse 1 on the pager goes to that view or desktop. Mouse 2 allows you to drag any window around from view to view. Mouse 3 allows you to drag the view around. I don't have Fvwm2, so this is all about Fvwm 1.x. Dragging the view around is very fast. It's almost as if the highlighted area of the pager is part of the mouse cursor. When you Mouse 3 click the pager, the upper left corner of the view jumps directly to the mouse cursor. With scwm and Fvwm2 pager, clicking Mouse 3 moves the view, but not right to the cursor. I'd guess about 6 - 8 or so pixels off. When you drag, the view moves, but does not move directly and the mouse moves. It's about a 2 or 3 to 1 ratio. You have to move the mouse a lot to move the view a little bit. It's not a proportion, it more like messages are getting dropped. I was just now playing around, and the pager went away. It's not showing up is a ps. Now *that* hasn't before. Must have stressed it too much. Well, at least I have keys bound that move the viewport! Dale From owner-scwm-discuss@mit.edu Fri Aug 21 12:38:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23966 for scwm-discuss-outgoing; Fri, 21 Aug 1998 12:38:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA23963 for ; Fri, 21 Aug 1998 12:38:37 -0400 Received: from [128.95.1.122] by MIT.EDU with SMTP id AA23036; Fri, 21 Aug 98 12:37:02 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA12289; Fri, 21 Aug 1998 09:35:46 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Solaris and FvwmPager References: <35a22b36.693727297@mailhost> <35e5a795.627668379@smtp> <35e777af.680941462@smtp> From: Greg Badros Date: 21 Aug 1998 09:35:46 -0700 In-Reply-To: smithd@bellhow.com's message of "Fri, 21 Aug 1998 13:52:33 GMT" Message-Id: Lines: 47 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On 20 Aug 1998 16:01:21 -0700, you wrote: > > >I think we underestimated a couple of the strengths of the design of the > >fvwm2 module system. Specifically, as a separate process, fvwm2 modules > >cannot (directly, anyway) crash scwm, which is a huge win. There are > >some tough issues to resolve before we get a nice extension system, but > >the event rewrite will be a huge step in the right direction, and that > >isn't too far off. > > > >What do you mean about "dragging a view around"? I do care about the > >big things with the pager.... > > > >Greg > > Mouse 1 on the pager goes to that view or desktop. > Mouse 2 allows you to drag any window around from view to view. > Mouse 3 allows you to drag the view around. > > I don't have Fvwm2, so this is all about Fvwm 1.x. > > Dragging the view around is very fast. It's almost as if the highlighted > area of the pager is part of the mouse cursor. When you Mouse 3 click the > pager, the upper left corner of the view jumps directly to the mouse cursor. > > With scwm and Fvwm2 pager, clicking Mouse 3 moves the view, but not right to > the cursor. I'd guess about 6 - 8 or so pixels off. When you drag, the view > moves, but does not move directly and the mouse moves. It's about a 2 or 3 to 1 > ratio. You have to move the mouse a lot to move the view a little bit. It's > not a proportion, it more like messages are getting dropped. > > I was just now playing around, and the pager went away. It's not showing > up is a ps. Now *that* hasn't before. Must have stressed it too much. Well, > at least I have keys bound that move the viewport! Yea, I just tried it too, and Scwm and my Pager hung, so I had to kill the Pager to get Scwm back listening to me. I think there are some biggish problems with the module communications, but I'm going to leave them for Maciej as he wrote the code. Maybe they only seem like biggish problems because I'd have a lot of ramp-up time to figure out what's going on first. Thanks for the description! Greg From owner-scwm-discuss@mit.edu Fri Aug 21 12:43:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA24012 for scwm-discuss-outgoing; Fri, 21 Aug 1998 12:43:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA24009 for ; Fri, 21 Aug 1998 12:43:43 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04303; Fri, 21 Aug 98 12:43:23 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA12301; Fri, 21 Aug 1998 09:42:21 -0700 (PDT) To: Dirk Herrmann Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile References: From: Greg Badros Date: 21 Aug 1998 09:42:20 -0700 In-Reply-To: Dirk Herrmann's message of "Fri, 21 Aug 1998 12:03:07 +0200 (CEST)" Message-Id: Lines: 9 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dirk Herrmann writes: > In the meanwhile, I have experimented a bit with autoconf and guess I > could submit a patch next week if you are interested and have not > yet solved the problem anyway. Sure, send the patch and we can go from there. Greg From owner-scwm-discuss@mit.edu Fri Aug 21 15:15:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25540 for scwm-discuss-outgoing; Fri, 21 Aug 1998 15:15:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25537 for ; Fri, 21 Aug 1998 15:15:09 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA13359; Fri, 21 Aug 98 15:14:48 EDT Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfdku12323; Fri, 21 Aug 1998 19:14:08 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id PAA31151; Fri, 21 Aug 1998 15:14:02 -0400 To: scwm-discuss@mit.edu Subject: emacs 20.3 is out. Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 21 Aug 1998 15:14:02 -0400 Message-Id: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. GNU Emacs 20.3 is out. if you like scwm.el now, you will love it with the new emacs: mouse2 in *Apropos* and *Help* does nice things. check it out on ftp.gnu.org! [Any sopport for emacsen previous to GNU Emacs 20.3 will be dumped tonight at midnight]. 2. I suggest implementing a variable `scwm-scheme-path' pointing to the path relative to which the scheme files in scwm-procedures.txt are specified, and `scwm-source-path' for the C files. Then I will implement mouse2 in *Help* to bring up the file with the appropriate source code. Note that those using the binary distributions will not be able to see the C sources, but they will still be ably to see the scheme. 3. As you have probably guessed already, the older emacsen support will not be gone, in fact, I greatly appreciate your bug reports! :-) 4. I repeat, the text in `[]' in 1. is a joke. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Those who can laugh at themselves will never cease to be amused. From owner-scwm-discuss@mit.edu Fri Aug 21 17:03:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA26338 for scwm-discuss-outgoing; Fri, 21 Aug 1998 17:03:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA26335 for ; Fri, 21 Aug 1998 17:03:32 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA24710; Fri, 21 Aug 98 17:02:12 EDT Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfdlc16190; Fri, 21 Aug 1998 21:02:26 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id RAA05703; Fri, 21 Aug 1998 17:00:15 -0400 To: scwm-discuss@mit.edu Subject: Re: emacs 20.3 is out. References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Sam Steingold's message of "21 Aug 1998 15:14:02 -0400" Date: 21 Aug 1998 17:00:15 -0400 Message-Id: Lines: 25 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 21 Aug 1998 15:14:02 -0400 >>>> Honorable Sam Steingold writes >>>> on the subject of "emacs 20.3 is out.": >> >> 2. I suggest implementing a variable `scwm-scheme-path' pointing to the >> path relative to which the scheme files in scwm-procedures.txt are >> specified, and `scwm-source-path' for the C files. Then I will >> implement mouse2 in *Help* to bring up the file with the appropriate >> source code. Note that those using the binary distributions will not >> be able to see the C sources, but they will still be ably to see the >> scheme. Implemented. Set (in Emacs) `scwm-source-path' appropriately and click mouse2 on the filename. You need the latest and greatest GNU Emacs 20.3 for that, of course! :-) (I still think it might be a good idea to create the scheme variables, so that packages other than emacs could do the same). -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Don't use force -- get a bigger hammer. From owner-scwm-discuss@mit.edu Fri Aug 21 19:03:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA27406 for scwm-discuss-outgoing; Fri, 21 Aug 1998 19:03:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA27403 for ; Fri, 21 Aug 1998 19:03:45 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA13625; Fri, 21 Aug 98 19:02:24 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id TAA27456; Fri, 21 Aug 1998 19:02:34 -0400 (EDT) Message-Id: <199808212302.TAA27456@jekyll.piermont.com> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: emacs 20.3 is out. In-Reply-To: Your message of "21 Aug 1998 15:14:02 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 21 Aug 1998 19:02:34 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 1. GNU Emacs 20.3 is out. if you like scwm.el now, you will love it > with the new emacs: mouse2 in *Apropos* and *Help* does nice things. > check it out on ftp.gnu.org! [Any sopport for emacsen previous to > GNU Emacs 20.3 will be dumped tonight at midnight]. Any possibility of support for xemacs? Perry From owner-scwm-discuss@mit.edu Fri Aug 21 19:16:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA27603 for scwm-discuss-outgoing; Fri, 21 Aug 1998 19:16:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA27580 for ; Fri, 21 Aug 1998 19:15:56 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14894; Fri, 21 Aug 98 19:14:35 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA29297; Fri, 21 Aug 1998 16:14:45 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: emacs 20.3 is out. References: <199808212302.TAA27456@jekyll.piermont.com> From: Greg Badros Date: 21 Aug 1998 16:14:45 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 21 Aug 1998 19:02:34 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Sam Steingold writes: > > 1. GNU Emacs 20.3 is out. if you like scwm.el now, you will love it > > with the new emacs: mouse2 in *Apropos* and *Help* does nice things. > > check it out on ftp.gnu.org! [Any sopport for emacsen previous to > > GNU Emacs 20.3 will be dumped tonight at midnight]. > > Any possibility of support for xemacs? I second that, as I know Sam knows. I generally have worked with Sam to make sure scwm.el works okay with XEmacs, even if all of the features aren't completely supported. The mouse-support is missing, but I dislike the mouse anyway, and don't have time to deal with figuring out the right way to do it with XEmacs right yet (plus XEmacs 21 is just around the corner). Greg From owner-scwm-discuss@mit.edu Fri Aug 21 19:55:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA27898 for scwm-discuss-outgoing; Fri, 21 Aug 1998 19:55:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA27895 for ; Fri, 21 Aug 1998 19:55:49 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA09326; Fri, 21 Aug 98 19:55:25 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA00545; Fri, 21 Aug 1998 16:54:44 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Scwm Online Documentation From: Greg Badros Date: 21 Aug 1998 16:54:44 -0700 Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk The online documentation now has a lot more to say about the Scheme procedures to augment the complete documentation for C-level primitives. (All the docs are extracted from C and Scheme source code, and converted to HTML using JADE and the DocBook tools). The *new location* of the online documentation is: http://www.cs.washington.edu/homes/gjb/scwm-doc/ Check it out, and let me know about problems you find, or places where the documentation is inaccurate. All suggestions are appreciated! Thanks, Greg From owner-scwm-discuss@mit.edu Fri Aug 21 20:03:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA27958 for scwm-discuss-outgoing; Fri, 21 Aug 1998 20:03:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA27952 for ; Fri, 21 Aug 1998 20:02:59 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19900; Fri, 21 Aug 98 20:01:38 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA00773; Fri, 21 Aug 1998 17:01:48 -0700 (PDT) To: "Jason Kirtland" Cc: Subject: Re: stacking order References: <000101bd9f22$e92eba20$6463a7cc@panopticon.postalmodern.com> From: Greg Badros Date: 21 Aug 1998 17:01:48 -0700 In-Reply-To: "Jason Kirtland"'s message of "Tue, 23 Jun 1998 23:48:12 -0400" Message-Id: Lines: 16 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Jason Kirtland" writes: > This is a long-time pet peeve of mine. When I want to "lower" a window, I > often only want to lower it one notch in the stacking order, not drop it all > the way to the bottom. I was hoping to do something like this, bound to a > button: > > Click: lower one > Long click: drop to bottom (mouse down, wait, mouse up) > See (app scwm stacking)'s lower-by-one procedure. The short/long click distinction isn't really easy to do, but it'll be possible within the rewritten event framework. Greg From owner-scwm-discuss@mit.edu Fri Aug 21 20:24:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28152 for scwm-discuss-outgoing; Fri, 21 Aug 1998 20:24:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28149 for ; Fri, 21 Aug 1998 20:24:13 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA12414; Fri, 21 Aug 98 20:23:50 EDT Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.225]) id QQfdlp20086; Sat, 22 Aug 1998 00:23:09 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id UAA06011; Fri, 21 Aug 1998 20:21:35 -0400 To: scwm-discuss@mit.edu Subject: Re: emacs 20.3 is out. References: <199808212302.TAA27456@jekyll.piermont.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "21 Aug 1998 16:14:45 -0700" Date: 21 Aug 1998 20:21:34 -0400 Message-Id: Lines: 48 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 21 Aug 1998 16:14:45 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: emacs 20.3 is out.": >> "Perry E. Metzger" writes: >> >> > Sam Steingold writes: >> > > 1. GNU Emacs 20.3 is out. if you like scwm.el now, you will love it >> > > with the new emacs: mouse2 in *Apropos* and *Help* does nice things. >> > > check it out on ftp.gnu.org! [Any sopport for emacsen previous to >> > > GNU Emacs 20.3 will be dumped tonight at midnight]. >> > >> > Any possibility of support for xemacs? >> >> I second that, as I know Sam knows. Actually, since XEmacs is based on Emacs 19, I would include it among "emacsen previous to GNU Emacs 20.3" :-) At any rate, it was a joke, and I will continue supporting everything. >> The mouse-support is missing, but I dislike the mouse anyway, and >> don't have time to deal with figuring out the right way to do it >> with XEmacs right yet I pretty sure a couple of hundred lines gleaned from help.el in e20.3 would do. I can try to re-implement all those nice things for xemacs, but the perspective doesn't excite me. Really. >> (plus XEmacs 21 is just around the corner). xemacs 21 doesn't provide the facilities e20.3 does. I have the pretest here with me. it crashes on menu selection (!) I would appreciate if the die-hard xemacs users try e20.3/scwm.el and tell me what they think. If you like the features please contact the xemacs team and ask for `help-xref-button' and `help-setup-xref'. BTW, although I am a die-hard emacs aficionado, I do keep my .emacs xemacs-friendly. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The software said it requires Windows 3.1 or better, so I installed Linux. From owner-scwm-discuss@mit.edu Fri Aug 21 20:34:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28366 for scwm-discuss-outgoing; Fri, 21 Aug 1998 20:34:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28363 for ; Fri, 21 Aug 1998 20:34:57 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA13313; Fri, 21 Aug 98 20:34:33 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA03009; Fri, 21 Aug 1998 17:33:51 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Anyone using constraints yet? From: Greg Badros X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Date: 21 Aug 1998 17:33:51 -0700 Message-Id: Lines: 11 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is anyone using Cassowary in Scwm yet? I've updated the web page to include the readme about how to get started with the constraint solver. See: http://huis-clos.mit.edu/scwm/README-constraints.html Please do let me know about successes and failures with the constraint system. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Aug 21 20:45:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28484 for scwm-discuss-outgoing; Fri, 21 Aug 1998 20:45:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28481 for ; Fri, 21 Aug 1998 20:45:49 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24026; Fri, 21 Aug 98 20:44:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA03016; Fri, 21 Aug 1998 17:44:44 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Event rewrite discussion... From: Greg Badros Date: 21 Aug 1998 17:44:44 -0700 Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I still haven't received any feedback on my event-rewrite proposal. Does that mean everyone loves it? Or does it mean that everyone is happy with the current system? See: http://huis-clos.mit.edu/scwm-discuss.1998/0632.html if you're interested. Thanks, Greg From owner-scwm-discuss@mit.edu Sat Aug 22 17:35:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01187 for scwm-discuss-outgoing; Sat, 22 Aug 1998 17:35:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01184 for ; Sat, 22 Aug 1998 17:35:36 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA12501; Sat, 22 Aug 98 17:34:58 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA16844 for scwm-discuss@mit.edu; Sat, 22 Aug 1998 14:34:16 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199808222134.OAA16844@fielder.cs.washington.edu> Subject: Any way to get contents of cut buffer? To: scwm-discuss@mit.edu Date: Sat, 22 Aug 1998 14:34:15 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Quick question: Is there any way in guile to get the contents of the X cut buffer (or any other X buffers, for that matter) as a string? Just contemplating some ideas... -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Sun Aug 23 01:07:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA02990 for scwm-discuss-outgoing; Sun, 23 Aug 1998 01:07:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA02987 for ; Sun, 23 Aug 1998 01:07:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11223; Sun, 23 Aug 98 01:06:25 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA29129; Sat, 22 Aug 1998 22:05:43 -0700 (PDT) To: csk@cs.washington.edu (Craig Kaplan) Cc: scwm-discuss@mit.edu Subject: Re: Any way to get contents of cut buffer? References: <199808222134.OAA16844@fielder.cs.washington.edu> From: Greg Badros Date: 22 Aug 1998 22:05:42 -0700 In-Reply-To: csk@cs.washington.edu's message of "Sat, 22 Aug 1998 14:34:15 -0700 (PDT)" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk csk@cs.washington.edu (Craig Kaplan) writes: > Quick question: > > Is there any way in guile to get the contents of the X cut buffer > (or any other X buffers, for that matter) as a string? Just contemplating > some ideas... It's on the TODO list to provide a primitive for exactly this capability. Feel free to implement it (suitably generalized as appropriate-- I've not looked into this much yet) and send it in. :-) Greg From owner-scwm-discuss@mit.edu Sun Aug 23 15:54:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA06892 for scwm-discuss-outgoing; Sun, 23 Aug 1998 15:54:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA06889 for ; Sun, 23 Aug 1998 15:54:41 -0400 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA03375; Sun, 23 Aug 1998 15:59:47 -0400 (EDT) Received: from quirk.struble.c (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA02355; Sun, 23 Aug 1998 15:53:15 -0400 (EDT) Received: (from cstruble@localhost) by quirk.struble.c (8.8.8/8.8.7) id PAA06909; Sun, 23 Aug 1998 15:54:35 -0400 (EDT) (envelope-from cstruble) Message-ID: <19980823155434.A6895@vt.edu> Date: Sun, 23 Aug 1998 15:54:34 -0400 From: Craig Struble To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: scwm-0.8 nits References: <19980817101542.A26149@vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Greg Badros on Thu, Aug 20, 1998 at 12:05:02PM -0700 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Aug 20, 1998 at 12:05:02PM -0700, Greg Badros wrote: > Craig Struble writes: > > > Second, anything with a sticky icon has its icon placed where the > > top left corner of the window is placed. Moving the icon by hand > > doesn't even work. You deiconify and iconify again, and poof, the > > icon is back at the top left corner. Non-sticky icons work fine. > > Is there any hope of having sticky icons going back to their old > > behavior, being treated basically like non-sticky ones and put into > > icon boxes, etc.? > > Try it in tonight's snapshot... I've changed the behaviour and I think > it's closer to being "right" but I don't use icons that much so may not > be the best judge. > Seems to be working great now! Now for a feature request: I'd like smart placement to ignore the icons. Maybe constraints would be a better way of handling specialized placement requirements? I haven't looked into them yet. Are there any good examples to play with? > Still looking into your other questions. > Ok, cool. Thanks. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Mon Aug 24 04:03:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA10271 for scwm-discuss-outgoing; Mon, 24 Aug 1998 04:03:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA10268 for ; Mon, 24 Aug 1998 04:03:41 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA04501 for scwm-discuss@huis-clos.mit.edu; Mon, 24 Aug 1998 10:02:08 +0200 (CEST) Received: (qmail 981 invoked by uid 115); 23 Aug 1998 10:56:09 -0000 To: scwm-discuss@mit.edu Subject: Re: Any way to get contents of cut buffer? References: <199808222134.OAA16844@fielder.cs.washington.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Aug 1998 12:56:08 +0200 In-Reply-To: Greg Badros's message of "22 Aug 1998 22:05:42 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.31/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 22 Aug 1998 22:05:42 -0700 >>>>> Greg Badros said: Greg> csk@cs.washington.edu (Craig Kaplan) writes: >> Quick question: >> >> Is there any way in guile to get the contents of the X cut buffer >> (or any other X buffers, for that matter) as a string? Just >> contemplating some ideas... Greg> It's on the TODO list to provide a primitive for exactly this Greg> capability. This is from the top of my head, but aren't cut buffers just X-properties of the root window. So `window-xproperty' should work for you: `(window-xproperty root-window "CUT_BUFFER0")'. The problem here is that I can't find a way to get the root-window id inside of scwm... Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Aug 25 02:26:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA15044 for scwm-discuss-outgoing; Tue, 25 Aug 1998 02:26:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA15041 for ; Tue, 25 Aug 1998 02:26:44 -0400 Received: from sueton.ida.ing.tu-bs.de by MIT.EDU with SMTP id AA13113; Tue, 25 Aug 98 02:25:03 EDT Received: from localhost (dirk@localhost) by sueton.ida.ing.tu-bs.de (8.9.1/8.9.1) with SMTP id IAA24364; Tue, 25 Aug 1998 08:24:57 +0200 (CEST) Date: Tue, 25 Aug 1998 08:24:57 +0200 (CEST) From: Dirk Herrmann X-Sender: dirk@sueton To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello! On 21 Aug 1998, Greg Badros wrote: > Dirk Herrmann writes: > > In the meanwhile, I have experimented a bit with autoconf and guess I > > could submit a patch next week if you are interested and have not > > yet solved the problem anyway. > > Sure, send the patch and we can go from there. Fine, here you go. The patch does basically a reordering: First check for --with-guile-prefix and --with-guile-exec-prefix and use the resulting paths when searching for build-guile. I also changed the meaning of --with-guile-exec-prefix to really point to the guile binaries directory and added options --with-guile-include-prefix and --with-guile-lib-prefix. I tried to somehow keep the original structure, though: first test for programs, later test for libraries. However, this looks a little bit unnatural for the guile tests, since the tests for --with-guile-prefix and --with-guile-exec-prefix are performed with the program checks, while --with-guile-include-prefix and --with-guile-lib-prefix are performed later with the library checks. Maybe the checks for the guile related command line options should be moved together, still keeping the checks for programs and libraries themselves separate. Finally the license issue (in case of doubt): I release my changes under the GPL. (Somehow I feel this sounds quite bombastic for such minor contributions, which for themselves consist mainly of a few characters added to other peoples code, but I know that at FSF they take such things quite serious. Just wanted to avoid any incertainties.) Another thing: Maybe a final guile test could be made into an autoconf macro and contributed to one of the autoconf macro sites? At least at http://home.pages.de/~simons/autoconf-archive/ there was no guile test last time I checked. Best regards, Dirk Herrmann --- configure.in.orig Mon Aug 24 21:55:38 1998 +++ configure.in Mon Aug 24 22:39:17 1998 @@ -27,14 +27,70 @@ AM_PROG_LIBTOOL -AC_CHECK_PROG(BUILD_GUILE, build-guile, yes, no) +dnl # check for build-guile # -if test $BUILD_GUILE = yes; then +GUILE_BIN_DIR="" +GUILE_INCLUDES="" +GUILE_LIBS_PRE="" + +if test "x$exec_prefix" = "xNONE"; then + GUILE_LIBS_PRE="-L$ac_default_prefix/lib" +else + GUILE_LIBS_PRE="-L$exec_prefix/lib" +fi +if test "x$prefix" = "xNONE"; then + GUILE_INCLUDES="-I$ac_default_prefix/include" +else + GUILE_INCLUDES="-I$prefix/include" +fi + +AC_ARG_WITH(guile-prefix, +[ --with-guile-prefix=DIR Expect guile to be installed in DIR [optional]], +[ + if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + AC_MSG_ERROR(missing pathname argument to --with-guile-prefix) + else + AC_MSG_CHECKING(where to expect to find guile) + guile_prefix="${withval}" + GUILE_BIN_DIR="${guile_prefix}/bin" + GUILE_INCLUDES="-I${guile_prefix}/include" + GUILE_LIBS_PRE="-L${guile_prefix}/lib" + + AC_MSG_RESULT("${guile_prefix}") + fi +]) + +AC_ARG_WITH(guile-exec-prefix, +[ --with-guile-exec-prefix=DIR + Expect guile binaries to be installed in DIR + [optional]], +[ + if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + AC_MSG_ERROR(missing pathname argument to --with-guile-exec-prefix) + else + AC_MSG_CHECKING(where to expect to find guile binaries) + guile_exec_prefix="${withval}" + GUILE_BIN_DIR="${guile_exec_prefix}" + + AC_MSG_RESULT("${guile_exec_prefix}") + fi +]) + +if test "x${GUILE_BIN_DIR}" = "x"; then + AC_PATH_PROG(BUILD_GUILE, build-guile, no) +else + AC_PATH_PROG(BUILD_GUILE, build-guile, no, ${GUILE_BIN_DIR}) +fi + +if test $BUILD_GUILE != no; then AC_MSG_CHECKING(whether build-guile works) - if test x`build-guile link >/dev/null 2>&1 || echo no` = xno; then - BUILD_GUILE=no + build_guile_works=yes + if test x`${BUILD_GUILE} link >/dev/null 2>&1 || echo no` = xno; then + build_guile_works=no fi - AC_MSG_RESULT($BUILD_GUILE) + AC_MSG_RESULT($build_guile_works) +else + build_guile_works=no fi dnl ## Find paths ## @@ -164,53 +220,41 @@ dnl # Guile checks # -if test "x$exec_prefix" = "xNONE"; then - GUILE_LIBS_PRE="-L$ac_default_prefix/lib" -else - GUILE_LIBS_PRE="-L$exec_prefix/lib" -fi -if test "x$prefix" = "xNONE"; then - GUILE_INCLUDES="-I$ac_default_prefix/include" -else - GUILE_INCLUDES="-I$prefix/include" -fi - -AC_ARG_WITH(guile-prefix, -[ --with-guile-prefix=DIR Expect guile to be installed in DIR [optional]], +AC_ARG_WITH(guile-include-prefix, +[ --with-guile-include-prefix=DIR + Expect guile header files to be installed in DIR + [optional]], [ if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then - AC_MSG_ERROR(missing pathname argument to --with-guile-prefix) + AC_MSG_ERROR(missing pathname argument to --with-guile-include-prefix) else - AC_MSG_CHECKING(where to expect to find guile) - guile_prefix="${withval}" - GUILE_INCLUDES="-I${guile_prefix}/include" - GUILE_LIBS_PRE="-L${guile_prefix}/lib" + AC_MSG_CHECKING(where to expect guile header files) + guile_include_prefix="${withval}" + GUILE_INCLUDES="${guile_include_prefix}" - AC_MSG_RESULT("${guile_prefix}") + AC_MSG_RESULT("${guile_include_prefix}") fi ]) - -AC_ARG_WITH(guile-exec-prefix, -[ --with-guile-exec-prefix=DIR - Expect guile binaries to be installed in DIR +AC_ARG_WITH(guile-lib-prefix, +[ --with-guile-lib-prefix=DIR + Expect guile libraries to be installed in DIR [optional]], [ if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then - AC_MSG_ERROR(missing pathname argument to --with-guile-exec-prefix) + AC_MSG_ERROR(missing pathname argument to --with-guile-lib-prefix) else - AC_MSG_CHECKING(where to expect to find guile binaries) - guile_exec_prefix="${withval}" - GUILE_LIBS_PRE="-L${guile_exec_prefix}/lib" + AC_MSG_CHECKING(where to expect guile libraries) + guile_lib_prefix="${withval}" + GUILE_LIB_PRE="${guile_lib_prefix}" - AC_MSG_RESULT("${guile_exec_prefix}") + AC_MSG_RESULT("${guile_lib_prefix}") fi ]) - -if test $BUILD_GUILE = yes; then +if test $build_guile_works = yes; then AC_MSG_CHECKING(for guile libraries) - GUILE_LIBS="${GUILE_LIBS_PRE} `build-guile link`" + GUILE_LIBS="${GUILE_LIBS_PRE} `${BUILD_GUILE} link`" AC_MSG_RESULT($GUILE_LIBS) else AC_CHECK_LIB(m, sin, GUILE_LIBS="-lm",, $GUILE_LIBS_PRE) From owner-scwm-discuss@mit.edu Tue Aug 25 03:01:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15466 for scwm-discuss-outgoing; Tue, 25 Aug 1998 03:01:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA15463 for ; Tue, 25 Aug 1998 03:01:04 -0400 From: senda@ic.rdc.ricoh.co.jp Received: from ricohigw.ricoh.co.jp by MIT.EDU with SMTP id AA15775; Tue, 25 Aug 98 02:59:24 EDT Received: from leffe.pdd.ssd.ricoh.co.jp (leffe.pdd.ssd.ricoh.co.jp [133.139.212.2]) by ricohigw.ricoh.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta7) with ESMTP id PAA17096 for ; Tue, 25 Aug 1998 15:59:22 +0900 (JST) Received: from festiva.pdd.ssd.ricoh.co.jp (festiva.pdd.ssd.ricoh.co.jp [133.139.212.32]) by leffe.pdd.ssd.ricoh.co.jp (8.8.5+2.7Wbeta5/3.5Wpl1-97081214) with SMTP id PAA08811 for ; Tue, 25 Aug 1998 15:59:20 +0900 (JST) Received: from localhost by festiva.pdd.ssd.ricoh.co.jp (SMI-8.6/3.6W) id QAA14588; Tue, 25 Aug 1998 16:00:35 +0900 To: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile In-Reply-To: Your message of "Fri, 21 Aug 1998 12:03:07 +0200 (CEST)" References: X-Mailer: Mew version 1.93b38 on XEmacs 21.2 (Aeolus) X-Prom-Mew: Prom-Mew 1.92.11 (procmail reader for Mew) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980825160034J.senda@ic.rdc.ricoh.co.jp> Date: Tue, 25 Aug 1998 16:00:34 +0900 X-Dispatcher: imput version 980522 Lines: 59 Sender: owner-scwm-discuss@mit.edu Precedence: bulk dirk> dirk> I was just trying to figure out how you check for guile in the SCWM dirk> configuration and realized the following problem: dirk> dirk> The test for BUILD_GUILE is performed before the --with-guile-prefix and dirk> --with-guile-exec-prefix are evaluated. I assume that this could lead to dirk> problems when a user points configure to a version of guile that is not in dirk> the path: GUILE_LIBS could get it's value from a different version of dirk> guile. dirk> If you'll try to fix the BUILD_GUILE path problem, I hope you fix the 'guile-snarf' path in scwm/Makefile.in at the same time. Thanks in advance. :-) senda> gjb> Looked pretty good to me. The only thing I changed was editing senda> gjb> acconfig.h instead of include/config.h.in (the latter is auto-generated senda> gjb> -- I know it's a maze of configuration files, but that's the senda> gjb> price we senda> gjb> pay for automake and autoconf support). senda> senda> Oh, it's my careless miss. There is another my careless miss. Sorry. --- configure.in-org Fri Aug 21 07:48:12 1998 +++ configure.in Tue Aug 25 15:51:34 1998 @@ -70,8 +70,8 @@ AC_MSG_CHECKING(where to expect to find cassowary headers and library) CASSOWARY_INCLUDES="-I${withval}" case "$ac_R_nospace" in - "yes") cas_lib_path="-L${withval} -R ${withval}" ;; - "no") cas_lib_path="-L${withval} -R${withval}" ;; + "yes") cas_lib_path="-L${withval} -R${withval}" ;; + "no") cas_lib_path="-L${withval} -R ${withval}" ;; *) cas_lib_path="-L${withval}" ;; esac CASSOWARY_LIBS="$cas_lib_path ${withval}/../guile/cassowary_scm.o -lcassowary-scwm" @@ -199,8 +199,8 @@ ]) case "$ac_R_nospace" in -"yes") GUILE_LIBS_PRE="-L${guile_lib_path} -R ${guile_lib_path}" ;; -"no") GUILE_LIBS_PRE="-L${guile_lib_path} -R${guile_lib_path}" ;; +"yes") GUILE_LIBS_PRE="-L${guile_lib_path} -R${guile_lib_path}" ;; +"no") GUILE_LIBS_PRE="-L${guile_lib_path} -R ${guile_lib_path}" ;; *) GUILE_LIBS_PRE="-L${guile_lib_path}" ;; esac ------ S.Senda (SENDA,Shigeya) From owner-scwm-discuss@mit.edu Tue Aug 25 03:17:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA15544 for scwm-discuss-outgoing; Tue, 25 Aug 1998 03:17:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA15541 for ; Tue, 25 Aug 1998 03:17:54 -0400 Received: from sueton.ida.ing.tu-bs.de by MIT.EDU with SMTP id AA17032; Tue, 25 Aug 98 03:15:52 EDT Received: from localhost (dirk@localhost) by sueton.ida.ing.tu-bs.de (8.9.1/8.9.1) with SMTP id JAA24483 for ; Tue, 25 Aug 1998 09:15:51 +0200 (CEST) Date: Tue, 25 Aug 1998 09:15:51 +0200 (CEST) From: Dirk Herrmann X-Sender: dirk@sueton To: scwm-discuss@mit.edu Subject: Problems with scwm-0.8a Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi! I realized the following problem with scwm: If I reduce the window border width in my .scwmrc, still windows that are to be placed in the corners of the screen seem to be placed based on the default value of 6 (default in system.scwmrc): There is some free space between the screen border and the window border. Best regards, Dirk Herrmann -- This message is best viewed with ISO 8859/1 (latin-1) character encoding. Microsoft .. what do you want to boot today? From owner-scwm-discuss@mit.edu Tue Aug 25 09:19:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA17412 for scwm-discuss-outgoing; Tue, 25 Aug 1998 09:19:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA17409 for ; Tue, 25 Aug 1998 09:19:27 -0400 Received: from sallust.ida.ing.tu-bs.de by MIT.EDU with SMTP id AA23456; Tue, 25 Aug 98 09:17:40 EDT Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.1/8.9.1) with SMTP id PAA29983; Tue, 25 Aug 1998 15:16:54 +0200 (CEST) Date: Tue, 25 Aug 1998 15:16:54 +0200 (CEST) From: Dirk Herrmann X-Sender: dirk@sallust To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Oops! Cut and paste fooled me once again! Please apply these additions to my previous patch: 233c233 < GUILE_INCLUDES="${guile_include_prefix}" --- > GUILE_INCLUDES="-I${guile_include_prefix}" 249c249 < GUILE_LIB_PRE="${guile_lib_prefix}" --- > GUILE_LIB_PRE="-L${guile_lib_prefix}" Sorry for that. Best regards, Dirk Herrmann From owner-scwm-discuss@mit.edu Wed Aug 26 12:22:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA24833 for scwm-discuss-outgoing; Wed, 26 Aug 1998 12:22:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA24830 for ; Wed, 26 Aug 1998 12:22:39 -0400 Received: from sallust.ida.ing.tu-bs.de by MIT.EDU with SMTP id AA14187; Wed, 26 Aug 98 12:20:29 EDT Received: from localhost (dirk@localhost) by sallust.ida.ing.tu-bs.de (8.9.1/8.9.1) with SMTP id SAA11797; Wed, 26 Aug 1998 18:20:11 +0200 (CEST) Date: Wed, 26 Aug 1998 18:20:11 +0200 (CEST) From: Dirk Herrmann X-Sender: dirk@sallust To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi! When reading the man pages for 'test' on our Solaris machine, I realized a couple of portability improvements for scwm's configure.in. Since I somehow developed a little fun in playing with autoconf, I changed the tests as you find enclosed. Feel free to ignore the patches if you think this would cause more harm than it would help. Another thing: Although not very probable, 'yes' and 'no' could be valid directory names. What about changing the tests if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --) else into if test -z "${withval}"; then AC_MSG_ERROR(missing pathname argument to --); elif test ! -d "${withval}"; then AC_MSG_ERROR(invalid pathname argument to --); else or similar? Best regards, Dirk Herrmann --- configure.in.orig3 Tue Aug 25 15:09:40 1998 +++ configure.in Wed Aug 26 17:39:25 1998 @@ -33,12 +33,12 @@ GUILE_INCLUDES="" GUILE_LIBS_PRE="" -if test "x$exec_prefix" = "xNONE"; then +if test "NONE" = "$exec_prefix"; then GUILE_LIBS_PRE="-L$ac_default_prefix/lib" else GUILE_LIBS_PRE="-L$exec_prefix/lib" fi -if test "x$prefix" = "xNONE"; then +if test "NONE" = "$prefix"; then GUILE_INCLUDES="-I$ac_default_prefix/include" else GUILE_INCLUDES="-I$prefix/include" @@ -47,7 +47,7 @@ AC_ARG_WITH(guile-prefix, [ --with-guile-prefix=DIR Expect guile to be installed in DIR [optional]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-guile-prefix) else AC_MSG_CHECKING(where to expect to find guile) @@ -65,7 +65,7 @@ Expect guile binaries to be installed in DIR [optional]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-guile-exec-prefix) else AC_MSG_CHECKING(where to expect to find guile binaries) @@ -76,16 +76,16 @@ fi ]) -if test "x${GUILE_BIN_DIR}" = "x"; then +if test -z "${GUILE_BIN_DIR}"; then AC_PATH_PROG(BUILD_GUILE, build-guile, no) else AC_PATH_PROG(BUILD_GUILE, build-guile, no, ${GUILE_BIN_DIR}) fi -if test $BUILD_GUILE != no; then +if test "no" != "$BUILD_GUILE"; then AC_MSG_CHECKING(whether build-guile works) build_guile_works=yes - if test x`${BUILD_GUILE} link >/dev/null 2>&1 || echo no` = xno; then + if test "no" = `${BUILD_GUILE} link >/dev/null 2>&1 || echo no`; then build_guile_works=no fi AC_MSG_RESULT($build_guile_works) @@ -103,7 +103,7 @@ [ --with-lispdir=DIR Install Emacs Lisp files in DIR [PREFIX/share/site-lisp]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-lispdir) else AC_MSG_CHECKING(where .elc files should go) @@ -118,7 +118,7 @@ AC_ARG_WITH(cassowary, [ --with-cassowary=DIR Use Cassowary constraint solver from DIR ], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-cassowary) else AC_DEFINE(USE_CASSOWARY) @@ -139,7 +139,7 @@ dnl # X Window system checks # -if test "x$x_includes" = "x"; then +if test -z "$x_includes"; then x_includes="/usr/include" fi @@ -225,7 +225,7 @@ Expect guile header files to be installed in DIR [optional]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-guile-include-prefix) else AC_MSG_CHECKING(where to expect guile header files) @@ -241,7 +241,7 @@ Expect guile libraries to be installed in DIR [optional]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-guile-lib-prefix) else AC_MSG_CHECKING(where to expect guile libraries) @@ -252,7 +252,7 @@ fi ]) -if test $build_guile_works = yes; then +if test "yes" = "$build_guile_works"; then AC_MSG_CHECKING(for guile libraries) GUILE_LIBS="${GUILE_LIBS_PRE} `${BUILD_GUILE} link`" AC_MSG_RESULT($GUILE_LIBS) @@ -376,7 +376,7 @@ [ --with-scwmrcdir=DIR Install configuration files in DIR [LIBDIR/X11/scwm]], [ - if test -z "${withval}" -o "${withval}" = "yes" -o "${withval}" = "no"; then + if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then AC_MSG_ERROR(missing pathname argument to --with-scwmrcdir) else AC_MSG_CHECKING(where configuration files should go; e.g., system.scwmrc) @@ -402,7 +402,7 @@ AC_ARG_ENABLE(multibyte, [ --enable-multibyte Handle multibyte strings for window titles, etc], [ - if test $enableval = yes; then + if test "yes" = "$enableval"; then AC_DEFINE(I18N) fi From owner-scwm-discuss@mit.edu Wed Aug 26 13:25:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25330 for scwm-discuss-outgoing; Wed, 26 Aug 1998 13:25:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA25327 for ; Wed, 26 Aug 1998 13:25:15 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA02679; Wed, 26 Aug 98 13:23:20 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA03797; Wed, 26 Aug 1998 10:23:15 -0700 (PDT) To: Dirk Herrmann Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile References: From: Greg Badros Date: 26 Aug 1998 10:23:14 -0700 In-Reply-To: Dirk Herrmann's message of "Wed, 26 Aug 1998 18:20:11 +0200 (CEST)" Message-Id: Lines: 43 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dirk Herrmann writes: > When reading the man pages for 'test' on our Solaris machine, I realized a > couple of portability improvements for scwm's configure.in. Since I > somehow developed a little fun in playing with autoconf, I changed the > tests as you find enclosed. Which portability problems are you addressing? Some of your changes look good, but, e.g., I thought that "-o" was more portable than "||". > > Feel free to ignore the patches if you think this would cause more harm > than it would help. Thanks for the patches -- some of the changes definitely should be made. I'll do so when time permits. > > Another thing: Although not very probable, 'yes' and 'no' could be valid > directory names. What about changing the tests > > if test -z "${withval}" || test "yes" = "${withval}" || test "no" = "${withval}"; then > AC_MSG_ERROR(missing pathname argument to --) > else > > into > > if test -z "${withval}"; then > AC_MSG_ERROR(missing pathname argument to --); > elif test ! -d "${withval}"; then > AC_MSG_ERROR(invalid pathname argument to --); > else > > or similar? No, I think it's better to leave them the way they are -- a common mistake is giving no directory path in which case the $withval is "yes". Does it even make sense to have one of the paths start with something other than ".." or "/"? Thanks! Greg From owner-scwm-discuss@mit.edu Thu Aug 27 04:12:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA29666 for scwm-discuss-outgoing; Thu, 27 Aug 1998 04:12:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA29663 for ; Thu, 27 Aug 1998 04:12:33 -0400 Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.0/3.6W) with SMTP id RAA03198 for ; Thu, 27 Aug 1998 17:10:16 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id RAA25592; Thu, 27 Aug 1998 17:10:16 +0900 To: scwm-discuss@mit.edu Subject: build trouble X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 27 Aug 1998 17:10:15 +0900 Message-ID: Lines: 165 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am having trouble building the development version of scwm today. I installed the latest devel guile today, which may have something to do with my problem? (I recently build scwm-980817 with a guile from March and it is working fine.) % gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.8.1/specs gcc version 2.8.1 Here is the output from "configure" (which I had to extract from the snapshot: please, please bring it back into the repository along with all the "Makefile.in" files). ---- Start of included text -----------------------8<--- cut here ------------- petersen[boron]~/work/scwm/solaris-build% ../configure --prefix /mount/solaris --enable-multibyte loading cache ./config.cache checking for a BSD compatible install... ../install-sh -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... yes checking for working aclocal... missing checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking whether to enable maintainer-specific portions of Makefiles... no checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for POSIXized ISC... no checking how to run the C preprocessor... gcc -E checking for AIX... no checking for minix/config.h... no checking for gcc option to accept ANSI C... none needed checking host system type... sparc-sun-solaris2.6 checking for ranlib... ranlib checking for ld used by GCC... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... -static checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the linker (/usr/ccs/bin/ld) supports shared libraries... yes checking command to parse /usr/ccs/bin/nm -p output... yes checking how to hardcode library paths into programs... immediate checking for /usr/ccs/bin/ld option to reload object files... -r checking dynamic linker characteristics... solaris2.6 ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool checking for build-guile... yes checking whether build-guile works... no checking for X... libraries /usr/local/X11R6.1/lib, headers /usr/local/X11R6.1/include checking whether -R must be followed by a space... no checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... no checking for gethostbyname in -lnsl... yes checking for connect... no checking for connect in -lsocket... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... no checking for emacs... /home/petersen/mount/bin/solaris/emacs checking where .elc files should go... $(datadir)/emacs/site-lisp checking for main in -lm... yes checking for XOpenDisplay in -lX11... yes checking for XShapeCombineMask in -lXext... yes checking for XpmReadFileToPixmap in -lXpm... yes checking for XmuPrintDefaultErrorMessage in -lXmu... yes checking for _Xsetlocale in -lX11... no checking for tgoto in -ltermcap... yes checking for readline in -lreadline... yes checking for add_history in -lreadline... yes checking for sin in -lm... yes checking for main in -lrx... no checking for main in -lqt... no checking for dlopen in -ldl... yes checking for scm_handle_by_message_noexit in -lguile... no configure: error: Can not find Guile 1.2 or later on the system ---- End of included text -------------------------8<--- and here ------------- and the "config.log": ---- Start of included text -----------------------8<--- cut here ------------- configure:3310: checking for scm_handle_by_message_noexit in -lguile configure:3329: gcc -o conftest -g -O2 conftest.c -lguile -L/usr/local/lib -R /usr/local/lib -ldl -lm -lm 1>&5 Undefined first referenced symbol in file socket /mount/lib/solaris/libguile.so getpeername /mount/lib/solaris/libguile.so recv /mount/lib/solaris/libguile.so getprotobyname /mount/lib/solaris/libguile.so inet_lnaof /mount/lib/solaris/libguile.so current_history /mount/lib/solaris/libguile.so getnetent /mount/lib/solaris/libguile.so gethostbyname /mount/lib/solaris/libguile.so rl_redisplay /mount/lib/solaris/libguile.so accept /mount/lib/solaris/libguile.so filename_completion_function /mount/lib/solaris/libguile.so _rl_kill_kbd_macro /mount/lib/solaris/libguile.so setnetent /mount/lib/solaris/libguile.so rl_deprep_term_function /mount/lib/solaris/libguile.so socketpair /mount/lib/solaris/libguile.so send /mount/lib/solaris/libguile.so bind /mount/lib/solaris/libguile.so rl_clear_signals /mount/lib/solaris/libguile.so endnetent /mount/lib/solaris/libguile.so setsockopt /mount/lib/solaris/libguile.so getprotobynumber /mount/lib/solaris/libguile.so h_errno /mount/lib/solaris/libguile.so _rl_init_argument /mount/lib/solaris/libguile.so rl_outstream /mount/lib/solaris/libguile.so getservent /mount/lib/solaris/libguile.so inet_makeaddr /mount/lib/solaris/libguile.so rl_getc_function /mount/lib/solaris/libguile.so free_undo_list /mount/lib/solaris/libguile.so getservbyname /mount/lib/solaris/libguile.so gethostbyaddr /mount/lib/solaris/libguile.so rl_pending_input /mount/lib/solaris/libguile.so getsockopt /mount/lib/solaris/libguile.so add_history /mount/lib/solaris/libguile.so inet_netof /mount/lib/solaris/libguile.so getprotoent /mount/lib/solaris/libguile.so sendto /mount/lib/solaris/libguile.so rl_redisplay_function /mount/lib/solaris/libguile.so rl_instream /mount/lib/solaris/libguile.so getnetbyname /mount/lib/solaris/libguile.so sethostent /mount/lib/solaris/libguile.so inet_ntoa /mount/lib/solaris/libguile.so shutdown /mount/lib/solaris/libguile.so getsockname /mount/lib/solaris/libguile.so rl_clear_message /mount/lib/solaris/libguile.so readline /mount/lib/solaris/libguile.so rl_completion_entry_function /mount/lib/solaris/libguile.so _rl_clean_up_for_exit /mount/lib/solaris/libguile.so endhostent /mount/lib/solaris/libguile.so getnetbyaddr /mount/lib/solaris/libguile.so recvfrom /mount/lib/solaris/libguile.so getservbyport /mount/lib/solaris/libguile.so gethostent /mount/lib/solaris/libguile.so listen /mount/lib/solaris/libguile.so connect /mount/lib/solaris/libguile.so ld: fatal: Symbol referencing errors. No output written to conftest configure: failed program was: #line 3318 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char scm_handle_by_message_noexit(); int main() { scm_handle_by_message_noexit() ; return 0; } ---- End of included text -------------------------8<--- and here ------------- -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Thu Aug 27 13:04:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31875 for scwm-discuss-outgoing; Thu, 27 Aug 1998 13:04:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from hotmail.com (f171.hotmail.com [207.82.251.57]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31872 for ; Thu, 27 Aug 1998 13:04:18 -0400 Received: (qmail 25621 invoked by uid 0); 27 Aug 1998 17:02:11 -0000 Message-ID: <19980827170211.25620.qmail@hotmail.com> Received: from 131.107.3.72 by www.hotmail.com with HTTP; Thu, 27 Aug 1998 10:02:11 PDT X-Originating-IP: [131.107.3.72] From: "eric hanchrow" To: scwm-discuss@mit.edu Subject: How do I prevent Ctrl+Alt+Q from killing my X server? Content-Type: text/plain Date: Thu, 27 Aug 1998 10:02:11 PDT Sender: owner-scwm-discuss@mit.edu Precedence: bulk I confess that I haven't read the scwm documentation, because it appears to be unfinished. And I don't even know if this has anything to do with scwm, but I already asked this question of the debian-users list and the XFree86 list, and nobody there was able to help. I've installed Debian 2.0 from the official Debian 2.0 binary and am using scwm. Things are working well, but while using Emacs, I discovered that Ctrl+Alt+Q immediately kills my X server. This is annoying, because that key sequence has meaning to Emacs. I'd like to tell the server not to die when I type that sequence, but I don't know how. For what it's worth, I've uncommented `DontZap' in /etc/X11/XF86COnfig; that prevents Ctrl+Alt+Backspace from killing the server ... Please respond by email, as I don't regularly read this group. Thanks! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-scwm-discuss@mit.edu Thu Aug 27 14:14:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32195 for scwm-discuss-outgoing; Thu, 27 Aug 1998 14:14:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32192 for ; Thu, 27 Aug 1998 14:14:14 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA16877; Thu, 27 Aug 98 14:12:08 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA09369; Thu, 27 Aug 1998 11:11:42 -0700 (PDT) To: "eric hanchrow" Cc: scwm-discuss@mit.edu Subject: Re: How do I prevent Ctrl+Alt+Q from killing my X server? References: <19980827170211.25620.qmail@hotmail.com> From: Greg Badros Date: 27 Aug 1998 11:11:42 -0700 In-Reply-To: "eric hanchrow"'s message of "Thu, 27 Aug 1998 10:02:11 PDT" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "eric hanchrow" writes: > I confess that I haven't read the scwm documentation, because it > appears to be unfinished. > > And I don't even know if this has anything to do with scwm, but I > already > asked this question of the debian-users list and the XFree86 list, and > nobody there was able to help. > > I've installed Debian 2.0 from the official Debian 2.0 binary and am > using scwm. Things are working well, but while using Emacs, I > discovered that Ctrl+Alt+Q immediately kills my X server. This is It doesn't kill your X server (like the Zap you mention below), it quits scwm: (bind-key 'all "C-M-q" quit) You can comment out or delete that line in your scwmrc. I'll make future versions of the *all* the included scwmrc files use C-M-S-q (as gjb.scwmrc and some others do now) and do a quit-verify instead of a bare quit. Greg From owner-scwm-discuss@mit.edu Fri Aug 28 11:59:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04815 for scwm-discuss-outgoing; Fri, 28 Aug 1998 11:59:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA04812 for ; Fri, 28 Aug 1998 11:59:45 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA22140; Fri, 28 Aug 98 11:57:26 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id LAA25622; Fri, 28 Aug 1998 11:57:26 -0400 (EDT) To: scwm-discuss@mit.edu Subject: usleep declaration broken Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 28 Aug 1998 11:57:25 -0400 Message-Id: <87ogt5jdzu.fsf@jekyll.piermont.com> Lines: 18 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Not that it matters much, because usleep's return is never used by you guys, but your usleep declaration/defintion in syscompat.[ch] is wrong. See the Single Unix Specification (XPG4) for the correct definition: http://www.opengroup.org/onlinepubs/7908799/toc.htm Most specifically http://www.opengroup.org/onlinepubs/7908799/xsh/usleep.html declares it to return an int... Someone should make sure the compat functions all meet XPG... Perry From owner-scwm-discuss@mit.edu Fri Aug 28 12:04:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA04865 for scwm-discuss-outgoing; Fri, 28 Aug 1998 12:04:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA04862 for ; Fri, 28 Aug 1998 12:04:25 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA23574; Fri, 28 Aug 98 12:02:05 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id MAA25633; Fri, 28 Aug 1998 12:02:05 -0400 (EDT) To: scwm-discuss@mit.edu Subject: more usleep problems Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 28 Aug 1998 12:02:05 -0400 Message-Id: <87n28pjds2.fsf@jekyll.piermont.com> Lines: 29 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The compat usleep code you use is Very Very Wrong. In addition to the XPG violation I mentioned a moment ago, have a gander here: #ifndef HAVE_USLEEP void usleep(unsigned long n) { struct timeval value; if (n <= 0) return; value.tv_usec = n % 1000; value.tv_sec = n / 1000; (void) select(1, 0, 0, 0, &value); } #endif /* !HAVE_USLEEP */ %1000 implies that usleep sleeps a number of MILLISECONDS. usleep is defined in terms of MICROSECONDS. Am I crazy here? Perry From owner-scwm-discuss@mit.edu Fri Aug 28 13:17:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05363 for scwm-discuss-outgoing; Fri, 28 Aug 1998 13:17:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05359 for ; Fri, 28 Aug 1998 13:17:16 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24543; Fri, 28 Aug 98 13:15:00 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA12134; Fri, 28 Aug 1998 10:14:48 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: usleep declaration broken References: <87ogt5jdzu.fsf@jekyll.piermont.com> From: Greg Badros Date: 28 Aug 1998 10:14:47 -0700 In-Reply-To: "Perry E. Metzger"'s message of "28 Aug 1998 11:57:25 -0400" Message-Id: Lines: 9 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Someone should make sure the compat functions all meet XPG... Are you volunteering? :-) Thanks for the pointers. Greg From owner-scwm-discuss@mit.edu Fri Aug 28 13:26:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05459 for scwm-discuss-outgoing; Fri, 28 Aug 1998 13:26:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05455 for ; Fri, 28 Aug 1998 13:26:13 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA26978; Fri, 28 Aug 98 13:23:57 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA25867; Fri, 28 Aug 1998 13:23:45 -0400 (EDT) Message-Id: <199808281723.NAA25867@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: usleep declaration broken In-Reply-To: Your message of "28 Aug 1998 10:14:47 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 28 Aug 1998 13:23:45 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > "Perry E. Metzger" writes: > > > Someone should make sure the compat functions all meet XPG... > > Are you volunteering? :-) I suppose I could do it, but the thing I can't do is fix all the places in the code where it appears that milliseconds and microseconds are confused (very very very bad!) > Thanks for the pointers. > > Greg From owner-scwm-discuss@mit.edu Fri Aug 28 13:40:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05603 for scwm-discuss-outgoing; Fri, 28 Aug 1998 13:40:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05600 for ; Fri, 28 Aug 1998 13:40:51 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA18621; Fri, 28 Aug 98 13:38:31 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA12164; Fri, 28 Aug 1998 10:38:27 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: usleep declaration broken References: <199808281723.NAA25867@jekyll.piermont.com> From: Greg Badros Date: 28 Aug 1998 10:38:27 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 28 Aug 1998 13:23:45 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > "Perry E. Metzger" writes: > > > > > Someone should make sure the compat functions all meet XPG... > > > > Are you volunteering? :-) > > I suppose I could do it, but the thing I can't do is fix all the > places in the code where it appears that milliseconds and microseconds > are confused (very very very bad!) In a quick glance, it looks like all of the 8 calls are supposed to be ms_sleep (millisecond sleeps) instead of usleep (microsecond sleep). Do any appear to be looking for microseconds to you? Thanks for your help... this stuff really is ugly, but will be easy to clean up. Thanks! Greg From owner-scwm-discuss@mit.edu Fri Aug 28 13:49:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05698 for scwm-discuss-outgoing; Fri, 28 Aug 1998 13:49:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05695 for ; Fri, 28 Aug 1998 13:49:17 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA03498; Fri, 28 Aug 98 13:47:01 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA26049; Fri, 28 Aug 1998 13:46:54 -0400 (EDT) Message-Id: <199808281746.NAA26049@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: usleep declaration broken In-Reply-To: Your message of "28 Aug 1998 10:38:27 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 28 Aug 1998 13:46:54 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > In a quick glance, it looks like all of the 8 calls are supposed to be > ms_sleep (millisecond sleeps) instead of usleep (microsecond sleep). Do > any appear to be looking for microseconds to you? All of them are using numbers that are so low that I can't reasonably interpret them as microseconds -- no reasonable program attempts to pause for ten millionths of a second, and certainly not a millionth. BTW, a lot of the code appears to poll instead of being event driven. Thanks for fixing this, btw! Let me know when I can get a cvs update -- maybe this will fix my double click issues. Perry > > Thanks for your help... this stuff really is ugly, but will be easy to > clean up. > > Thanks! > > Greg > From owner-scwm-discuss@mit.edu Fri Aug 28 13:55:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05794 for scwm-discuss-outgoing; Fri, 28 Aug 1998 13:55:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05791 for ; Fri, 28 Aug 1998 13:55:30 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05272; Fri, 28 Aug 98 13:53:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA12193; Fri, 28 Aug 1998 10:52:58 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: usleep declaration broken References: <199808281746.NAA26049@jekyll.piermont.com> From: Greg Badros Date: 28 Aug 1998 10:52:58 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 28 Aug 1998 13:46:54 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > In a quick glance, it looks like all of the 8 calls are supposed to be > > ms_sleep (millisecond sleeps) instead of usleep (microsecond sleep). Do > > any appear to be looking for microseconds to you? > > All of them are using numbers that are so low that I can't reasonably > interpret them as microseconds -- no reasonable program attempts to > pause for ten millionths of a second, and certainly not a millionth. > > BTW, a lot of the code appears to poll instead of being event driven. Can you give me an example? It's true the code doesn't use timer callbacks for short delays, but that's not polling (not by my definition anyway -- usleep does block and context switch). > Thanks for fixing this, btw! Let me know when I can get a cvs update > -- maybe this will fix my double click issues. Hopefully will have it done before I go home today. Making the changes are easy... testing is harder! Thanks again for looking into this! Greg From owner-scwm-discuss@mit.edu Fri Aug 28 14:38:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA06047 for scwm-discuss-outgoing; Fri, 28 Aug 1998 14:38:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA06044 for ; Fri, 28 Aug 1998 14:38:30 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA17599; Fri, 28 Aug 98 14:36:13 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA26133; Fri, 28 Aug 1998 14:36:00 -0400 (EDT) Message-Id: <199808281836.OAA26133@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: usleep declaration broken In-Reply-To: Your message of "28 Aug 1998 10:52:58 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 28 Aug 1998 14:35:59 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > BTW, a lot of the code appears to poll instead of being event driven. > > Can you give me an example? It's true the code doesn't use timer > callbacks for short delays, but that's not polling (not by my definition > anyway -- usleep does block and context switch). Well, like the IsClick function (in complex.c) for example. It is a polling function in essense, waiting for an event to occur. One should probably restructure the code so that if the event occurs a callback happens, instead of an event being parsed for. That way, if some other event occurs during the multiple click, the two do not interfere with each other. Events are timestamped for you anyway. I haven't done huge amounts of X programming, but this was drilled into me during my brief stints at it. My concern isn't that the code is taking up CPU, understand -- it is in code that doesn't call an event dispatcher in a loop but tries polling for events. The code in binding.c should probably instead deal with this stuff by having a callback dispatched by the first mouse click event that sets up a one shot timer callback, saves some state, and returns. If another click occurs, it can take down the oneshot -- otherwise, the oneshot does the work. I know it is a bit awkward, but when dealing with events this sort of thing is the right thing, and can avoid ugly race conditions. I have scwm hang on me about once a day for no reason. Code that is purely event driven should *never* hang because if it would need to block on anything it would end up back in the event loop first. The hangs are probably caused by race conditions when playing "tricks" like this... Perry From owner-scwm-discuss@mit.edu Fri Aug 28 16:52:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06594 for scwm-discuss-outgoing; Fri, 28 Aug 1998 16:52:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA06591 for ; Fri, 28 Aug 1998 16:52:11 -0400 Received: from [128.95.1.122] by MIT.EDU with SMTP id AA26136; Fri, 28 Aug 98 16:49:04 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA12966; Fri, 28 Aug 1998 13:47:03 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: usleep declaration broken References: <199808281836.OAA26133@jekyll.piermont.com> From: Greg Badros Date: 28 Aug 1998 13:47:03 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 28 Aug 1998 14:35:59 -0400" Message-Id: Lines: 43 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Well, like the IsClick function (in complex.c) for example. It is a > polling function in essense, waiting for an event to occur. One should > probably restructure the code so that if the event occurs a callback > happens, instead of an event being parsed for. That way, if some other > event occurs during the multiple click, the two do not interfere with > each other. Events are timestamped for you anyway. I haven't done huge > amounts of X programming, but this was drilled into me during my brief > stints at it. > > My concern isn't that the code is taking up CPU, understand -- it is > in code that doesn't call an event dispatcher in a loop but tries > polling for events. > > The code in binding.c should probably instead deal with this stuff by > having a callback dispatched by the first mouse click event that sets > up a one shot timer callback, saves some state, and returns. If > another click occurs, it can take down the oneshot -- otherwise, the > oneshot does the work. This is correct and will be redone by the event rewrite, but I thought you were talking about the other delays for animation purposes, etc. Part of the point of X is that events queue up for you so it's okay if you're away from the main event loop from a bit because you don't lose anything. > I know it is a bit awkward, but when dealing with events this sort of > thing is the right thing, and can avoid ugly race conditions. > > I have scwm hang on me about once a day for no reason. Code that is > purely event driven should *never* hang because if it would need to > block on anything it would end up back in the event loop first. The > hangs are probably caused by race conditions when playing "tricks" > like this... Do you use any fvwm2 modules? My guess is that it's blocking on a read from the fvwm2 module communications and killing the fvwm2 module processes may un-hang scwm. I didn't write that code, but it is on my list of things to try to do better/right unless Maciej can beat me to it (which I'm hoping he does). Greg From owner-scwm-discuss@mit.edu Fri Aug 28 20:06:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07615 for scwm-discuss-outgoing; Fri, 28 Aug 1998 20:06:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA07612 for ; Fri, 28 Aug 1998 20:06:30 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14906; Fri, 28 Aug 98 20:04:07 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA13180; Fri, 28 Aug 1998 17:03:50 -0700 (PDT) To: senda@ic.rdc.ricoh.co.jp Cc: scwm-discuss@mit.edu Subject: Re: SCWM configure.in and build-guile References: <19980825160034J.senda@ic.rdc.ricoh.co.jp> From: Greg Badros Date: 28 Aug 1998 17:03:49 -0700 In-Reply-To: senda@ic.rdc.ricoh.co.jp's message of "Tue, 25 Aug 1998 16:00:34 +0900" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk senda@ic.rdc.ricoh.co.jp writes: > senda> gjb> acconfig.h instead of include/config.h.in (the latter is auto-generated > senda> gjb> -- I know it's a maze of configuration files, but that's the > senda> gjb> price we > senda> gjb> pay for automake and autoconf support). > senda> > senda> Oh, it's my careless miss. > > There is another my careless miss. Fixed. Thanks! Greg From owner-scwm-discuss@mit.edu Fri Aug 28 20:17:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07782 for scwm-discuss-outgoing; Fri, 28 Aug 1998 20:17:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA07779 for ; Fri, 28 Aug 1998 20:17:06 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA16080; Fri, 28 Aug 98 20:14:43 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA13187; Fri, 28 Aug 1998 17:14:37 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Any way to get contents of cut buffer? References: <199808222134.OAA16844@fielder.cs.washington.edu> From: Greg Badros Date: 28 Aug 1998 17:14:37 -0700 In-Reply-To: Robert Bihlmeyer's message of "23 Aug 1998 12:56:08 +0200" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> It's on the TODO list to provide a primitive for exactly this > Greg> capability. > > This is from the top of my head, but aren't cut buffers just > X-properties of the root window. So `window-xproperty' should work for > you: `(window-xproperty root-window "CUT_BUFFER0")'. The problem here > is that I can't find a way to get the root-window id inside of scwm... I'm figuring out how best to deal with this. Either window-operating commands that *could* work on the root window could take a 'root-window argument instead of a window and do the right thing, or a (root-window) primitive could be added which returns a scheme window object that then would be used (but all the other window commands, such as move-window, would need to check for that as a special case, perhaps). I'm leaning towards the former, as it's rare for a root-window to be desired, and would result in less far-reaching change, and break the scheme-level window abstraction (that of a client application window) less. I'll do something about this by early next week. Thanks, Greg From owner-scwm-discuss@mit.edu Sat Aug 29 03:19:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA09597 for scwm-discuss-outgoing; Sat, 29 Aug 1998 03:19:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA09594 for ; Sat, 29 Aug 1998 03:19:48 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA01302 for scwm-discuss@huis-clos.mit.edu; Sat, 29 Aug 1998 09:17:23 +0200 (CEST) Received: (qmail 1052 invoked by uid 115); 28 Aug 1998 18:45:58 -0000 To: scwm-discuss@mit.edu Subject: Re: build trouble References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Aug 1998 20:45:57 +0200 In-Reply-To: Jens-Ulrik Petersen's message of "27 Aug 1998 17:10:15 +0900" Message-ID: Lines: 37 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 27 Aug 1998 17:10:15 +0900 >>>>> Jens-Ulrik Petersen said: juhp> Here is the output from "configure" (which I had to extract juhp> from the snapshot: please, please bring it back into the juhp> repository along with all the "Makefile.in" files). What's wrong with autogen.sh? [configure logs] The missing symbols are all in libguile. There are two solutions: 1. scwm (and other apps linking with libguile) additionally link with the libraries libguile depends on (looks like libreadline and libsocket in your case). This is quite a chore, because it is not easy to determine which libraries this means exactly. (The gnome people have {gtk,gnome,...}-config binaries for this. Ugly, IMHO.) (Libtool saves this information in lib*.la, which is better). 2. libguile gets built with correct dependencies, so that linking with it solely works. This is probably not portable to all platforms, Solaris reportedly being one of the broken ones. The immediate workaround for you is having the libraries into configure. Since this is obviously not a solution, we'll perhaps have to resort to (1) until the issues from (2) are sorted out. Comments? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 29 07:24:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA11040 for scwm-discuss-outgoing; Sat, 29 Aug 1998 07:24:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA11031 for ; Sat, 29 Aug 1998 07:23:59 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01851 for scwm-discuss@huis-clos.mit.edu; Sat, 29 Aug 1998 13:21:33 +0200 (CEST) Received: (qmail 3994 invoked by uid 115); 29 Aug 1998 09:56:38 -0000 To: scwm-discuss@mit.edu Subject: Root-window handling References: <199808222134.OAA16844@fielder.cs.washington.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Aug 1998 11:56:37 +0200 In-Reply-To: Greg Badros's message of "28 Aug 1998 17:14:37 -0700" Message-ID: Lines: 51 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 28 Aug 1998 17:14:37 -0700 >>>>> Greg Badros said: Greg> I'm leaning towards the former, as it's rare for a root-window Greg> to be desired, [...] I thought otherwise, but yes, a special-casing 'root-window (or 'root) in some procedures is perhaps the best solution. I just searched through scwm-procedures.txt, and the vast number of procedures are useless together with the root-window. The procedures that are somewhat useful with 'root-window: * The whole xproperty stuff. I will take these, as I plan to implement Maciej's proposal for the changed xproperties this weekend. * `window-id': There are no primitives yet that operate on window-ids, but it may be handy to give to external programs, e.g.: "wininfo -id" (yes I know, most of these take "-root"). Some borderline stuff: * `send-button-press' and `send-key-press': Is scwm always the only one taking these events on root? scwm sending button-presses to itself so that e.g. the window list is popped up seems rather superflous. * `window-class' and `window-resource': These seem to be undefined for root. * `window-position' and `window-size': Thinkable, but pretty useless. The first would return (0 0) always, the second has a result equal to `(display-size)'. Should procedures like `select-window-interactively' return 'root-window when the user clicks there? This gives nasty backtraces for most primitives, but may be useful with xproperties. `select-window-interactively-with-root-allowed'? (ok, the name is bogus) Or a #:root-allowed keyword to `s-w-i'? BTW, is it too late to rename scwm (scheme) "properties" to something like "attributes"? The name clash with X is especially bad since one can set both type of properties on windows. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 29 07:24:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA11039 for scwm-discuss-outgoing; Sat, 29 Aug 1998 07:24:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA11030 for ; Sat, 29 Aug 1998 07:23:59 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA01848 for scwm-discuss@huis-clos.mit.edu; Sat, 29 Aug 1998 13:21:32 +0200 (CEST) Received: (qmail 2419 invoked by uid 115); 29 Aug 1998 09:18:09 -0000 To: scwm-discuss@mit.edu Subject: Re: build trouble References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Aug 1998 11:18:08 +0200 In-Reply-To: Robert Bihlmeyer's message of "28 Aug 1998 20:45:57 +0200" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 28 Aug 1998 20:45:57 +0200 >>>>> Robert Bihlmeyer said: Robbe> (The gnome people have {gtk,gnome,...}-config binaries for Robbe> this. Ugly, IMHO.) Addendum: I forgot that guile uses "build-guile" for this, and scwm uses it already, if it can be found. Jens: does configure find build-guile? What does "build-guile link" say? Anyway, my comment that this is ugly still holds. Why litter the path with binaries that provide information that is readily accessible with grep? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Aug 29 22:12:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA14243 for scwm-discuss-outgoing; Sat, 29 Aug 1998 22:12:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA14240 for ; Sat, 29 Aug 1998 22:12:32 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA23844; Sat, 29 Aug 98 22:09:55 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id TAA18894 for ; Sat, 29 Aug 1998 19:09:50 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276517-15944>; Sat, 29 Aug 1998 19:10:31 -0700 To: scwm-discuss@mit.edu Subject: Re: Root-window handling In-Reply-To: Robert Bihlmeyer's message of "29 Aug 1998 11:56:37 +0200." Date: Sat, 29 Aug 1998 19:10:27 -0600 From: Ken Pizzini Message-Id: <19980830021031Z276517-15944+123@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk [Re: borderline-useful places to accept 'root-window include:] In message of 29 Aug 1998 11:56:37 +0200, Robert Bihlmeyer wrote: > * `window-position' and `window-size': Thinkable, but pretty useless. > The first would return (0 0) always, the second has a result equal > to `(display-size)'. I think that (window-position 'root-window) would more usefully report the same information as (viewport-position). Just as `window-size', this is redundant with an existing routine; but personally I favor the support of 'root-window in these two. (In fact, I like the feel of (window-size 'root-window) better than (display-size), which, if desired, could be a simple compatability wrapper in scheme for the former. YMMV.) --Ken Pizzini From owner-scwm-discuss@mit.edu Sun Aug 30 07:34:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA17133 for scwm-discuss-outgoing; Sun, 30 Aug 1998 07:34:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA17128 for ; Sun, 30 Aug 1998 07:34:00 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA07500 for scwm-discuss@huis-clos.mit.edu; Sun, 30 Aug 1998 13:31:22 +0200 (CEST) Received: (qmail 1345 invoked by uid 115); 30 Aug 1998 11:30:15 -0000 To: scwm-discuss@mit.edu Subject: Upcoming changes to xproperty.c X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 30 Aug 1998 13:30:14 +0200 Message-ID: Lines: 42 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I'm about to rewrite the handling of X properties. I guess that nobody is using this extensively, yet, so that I can come away without heavy backwards-compatibility measures. Specifically, if you're using one of the functions xproperty? set-window-text-property window-xproperty xproperty->string string->xproperty please tell me, so that I can avoid breaking your code. The gist of the change is, that X properties are no longer special scheme objects, but rather lists. There will be (X-property-set! WIN NAME VALUE #&optional (TYPE "STRING") (FORMAT 8) (ACTION 'replace)) which sets property NAME of type TYPE on window WIN to VALUE. FORMAT gives the size of the elements of VALUE (8, 16, 32). VALUE is a vector of properly sized integers, or a string, if FORMAT is 8. ACTION is 'replace, 'append, or 'prepend and determines what is done if the property already has a value. Return value is unspecified. (X-property-get WIN NAME #&optional (CONSUME? #f)) which queries the property NAME on window WIN. Returns #f, if the propery was not set, or (VALUE TYPE FORMAT) otherwise. The property is deleted, if CONSUME? is #t. Details are subject to change. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Aug 30 16:47:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19126 for scwm-discuss-outgoing; Sun, 30 Aug 1998 16:47:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19123 for ; Sun, 30 Aug 1998 16:47:10 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04983; Sun, 30 Aug 98 16:44:25 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16097; Sun, 30 Aug 1998 13:44:15 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: build trouble References: From: Greg Badros Date: 30 Aug 1998 13:44:14 -0700 In-Reply-To: Robert Bihlmeyer's message of "29 Aug 1998 11:18:08 +0200" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Anyway, my comment that this is ugly still holds. Why litter the path > with binaries that provide information that is readily accessible with > grep? For compatibility, consistency, and ease of use. I don't love the way this works, but it generally works (I'm curious what the problem ends up being). Greg From owner-scwm-discuss@mit.edu Sun Aug 30 16:52:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19185 for scwm-discuss-outgoing; Sun, 30 Aug 1998 16:52:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19181 for ; Sun, 30 Aug 1998 16:52:25 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05517; Sun, 30 Aug 98 16:49:40 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16116; Sun, 30 Aug 1998 13:49:38 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Root-window handling References: <199808222134.OAA16844@fielder.cs.washington.edu> From: Greg Badros Date: 30 Aug 1998 13:49:38 -0700 In-Reply-To: Robert Bihlmeyer's message of "29 Aug 1998 11:56:37 +0200" Message-Id: Lines: 63 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> I'm leaning towards the former, as it's rare for a root-window > Greg> to be desired, [...] > > I thought otherwise, but yes, a special-casing 'root-window (or 'root) > in some procedures is perhaps the best solution. I just searched > through scwm-procedures.txt, and the vast number of procedures are > useless together with the root-window. > > The procedures that are somewhat useful with 'root-window: > > * The whole xproperty stuff. I will take these, as I plan to implement > Maciej's proposal for the changed xproperties this weekend. Cool-- that it'd be great! > * `window-id': There are no primitives yet that operate on window-ids, > but it may be handy to give to external programs, e.g.: "wininfo > -id" (yes I know, most of these take "-root"). Yep. > Some borderline stuff: > > * `send-button-press' and `send-key-press': Is scwm always the only > one taking these events on root? scwm sending button-presses to > itself so that e.g. the window list is popped up seems rather > superflous. > > * `window-class' and `window-resource': These seem to be undefined for > root. > > * `window-position' and `window-size': Thinkable, but pretty useless. > The first would return (0 0) always, the second has a result equal > to `(display-size)'. I think all of these can ignore the root window for now. If we later find a compelling reason that they should handle root, we can always add it later. > Should procedures like `select-window-interactively' return > 'root-window when the user clicks there? This gives nasty backtraces > for most primitives, but may be useful with xproperties. > `select-window-interactively-with-root-allowed'? (ok, the name is > bogus) Or a #:root-allowed keyword to `s-w-i'? Perhaps. In particular we need a better way to distinguish between the root window being selecting, and aborting the selection (which currently isn't supported, I believ). > BTW, is it too late to rename scwm (scheme) "properties" to something > like "attributes"? The name clash with X is especially bad since one > can set both type of properties on windows. I agree and asked Maciej about this a while back and he was quick to point out that Lisp had the term "property" before X did. I think we need to always be explicit and say either X Property or scheme property (I also am trying to make a case distinction -- X Properties being uppercase "P"). Thanks, Greg From owner-scwm-discuss@mit.edu Sun Aug 30 16:57:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19279 for scwm-discuss-outgoing; Sun, 30 Aug 1998 16:57:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19276 for ; Sun, 30 Aug 1998 16:57:14 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05985; Sun, 30 Aug 98 16:54:29 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16125; Sun, 30 Aug 1998 13:54:28 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: Root-window handling References: <19980830021031Z276517-15944+123@pulsar.halcyon.com> From: Greg Badros Date: 30 Aug 1998 13:54:28 -0700 In-Reply-To: Ken Pizzini's message of "Sat, 29 Aug 1998 19:10:27 -0600" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > I think that (window-position 'root-window) would more usefully > report the same information as (viewport-position). Just as > `window-size', this is redundant with an existing routine; but > personally I favor the support of 'root-window in these two. I don't like the window-position reporting the viewport-position because right now windows report their coords in non-virtual (i.e. physical) coords. I'm going to be working with this code to make the virtual desktop stuff work better with the constraint solver, so I'll consider the issue when I'm deeper into the code. > (In fact, I like the feel of (window-size 'root-window) better than > (display-size), which, if desired, could be a simple compatability > wrapper in scheme for the former. YMMV.) My only real issue with this is that so many other places we treat "window" to mean an application window. The root window is special in a lot of ways to X (and not so special in other ways, it's true). Since handling the root-window would be a special case (unless we wrap the root window in a Scheme-level window object), I think we're better off not permitting it as an argument w/o good cause as it'll just complicate the code. Greg From owner-scwm-discuss@mit.edu Sun Aug 30 17:01:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA19387 for scwm-discuss-outgoing; Sun, 30 Aug 1998 17:01:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA19384 for ; Sun, 30 Aug 1998 17:01:21 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06487; Sun, 30 Aug 98 16:58:37 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16128; Sun, 30 Aug 1998 13:58:33 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Upcoming changes to xproperty.c References: From: Greg Badros Date: 30 Aug 1998 13:58:32 -0700 In-Reply-To: Robert Bihlmeyer's message of "30 Aug 1998 13:30:14 +0200" Message-Id: Lines: 46 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > I'm about to rewrite the handling of X properties. I guess that nobody > is using this extensively, yet, so that I can come away without heavy > backwards-compatibility measures. Specifically, if you're using one of > the functions > > xproperty? > set-window-text-property > window-xproperty > xproperty->string > string->xproperty {get,set}-window-text-property, and xproperty->string are all used in flux.scm, wininfo.scm > > please tell me, so that I can avoid breaking your code. > > The gist of the change is, that X properties are no longer special > scheme objects, but rather lists. > > There will be > > (X-property-set! WIN NAME VALUE #&optional (TYPE "STRING") (FORMAT > 8) (ACTION 'replace)) > > which sets property NAME of type TYPE on window WIN to VALUE. FORMAT > gives the size of the elements of VALUE (8, 16, 32). VALUE is a vector > of properly sized integers, or a string, if FORMAT is 8. ACTION is > 'replace, 'append, or 'prepend and determines what is done if the > property already has a value. Return value is unspecified. > > (X-property-get WIN NAME #&optional (CONSUME? #f)) > > which queries the property NAME on window WIN. Returns #f, if the > propery was not set, or (VALUE TYPE FORMAT) otherwise. The property > is deleted, if CONSUME? is #t. > > Details are subject to change. Sounds good! Greg From owner-scwm-discuss@mit.edu Sun Aug 30 17:28:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA19575 for scwm-discuss-outgoing; Sun, 30 Aug 1998 17:28:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA19572 for ; Sun, 30 Aug 1998 17:28:30 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA09558; Sun, 30 Aug 98 17:25:45 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id RAA15798; Sun, 30 Aug 1998 17:25:46 -0400 (EDT) To: scwm-discuss@mit.edu Subject: error in building Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 30 Aug 1998 17:25:45 -0400 Message-Id: <87btp2jh5y.fsf@jekyll.piermont.com> Lines: 13 Sender: owner-scwm-discuss@mit.edu Precedence: bulk gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include -g -O2 -c scwmrepl.c scwmrepl.c: In function `appending_fgets': scwmrepl.c:139: `stdio' undeclared (first use this function) scwmrepl.c:139: (Each undeclared identifier is reported only once scwmrepl.c:139: for each function it appears in.) gmake[2]: *** [scwmrepl.o] Error 1 I believe line 139 should actually use "stdout" instead of "stdio". I don't know how this ever worked... Perry From owner-scwm-discuss@mit.edu Sun Aug 30 18:01:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA19773 for scwm-discuss-outgoing; Sun, 30 Aug 1998 18:01:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA19770 for ; Sun, 30 Aug 1998 18:01:51 -0400 Received: from smtp2.nwnexus.com by MIT.EDU with SMTP id AA21283; Sun, 30 Aug 98 17:59:12 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp2.nwnexus.com (8.8.8/8.8.8) with ESMTP id OAA07847 for ; Sun, 30 Aug 1998 14:58:20 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-15944>; Sun, 30 Aug 1998 14:59:16 -0700 To: scwm-discuss@mit.edu Subject: a key event problem and a scwm function request Date: Sun, 30 Aug 1998 14:59:15 -0600 From: Ken Pizzini Message-Id: <19980830215916Z276516-15944+128@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk [my configuration: scwm-0.8a; linux-2.0.33 for iX86; X11R6.3] I'm puzzled by a problem I'm having. I have the following form in my .scwmrc file: (bind-key 'all "H-S-Tab" (lambda () (prev-window #:only visible? #:except iconified?))) For some reason this only works if I use my Shift_R key; if I use my Shift_L key _nothing_ happens. As long as I'm using my Shift_R key I can use either Hyper_L or Hyper_R just fine. Other keybindings where I use the H-S- prefix work fine with either shift key. Any ideas out there? Hmmm... it probably isn't scwm's fault: I just fired up xev and sure enough I see the events for Hyper_L down, Shift_L down, and then when I press the Tab key *no* additional events are reported. I guess I'm probably stuck with living with this quirk, but if anyone has any clues to offer I'd sure like to hear them... And my other question: what is the simplest way to query an attribute of a window's style? For example, I wish to create a "toggle-squashed" function (I realize this won't work , but I'm writing it with the expectation that it will work someday). But I'm not finding the functional equivalent of "(get-window-style w #:squashed-titlebar)" in the docs. BTW, my request is not specific to #:squashed-titlebar --- for example, in another place I'd like to query #:show-icon, and I suspect that the list may grow as time goes on. Actually, for the specific uses I'm after, something vaugely like (style-one-window w #:toggle-attribute #:squashed-titlebar) would suit me also. Did I manage to miss either of these in the documentation? Or if they don't currently exist, what do y'all think about adding either of them? --Ken Pizzini From owner-scwm-discuss@mit.edu Sun Aug 30 18:24:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA19925 for scwm-discuss-outgoing; Sun, 30 Aug 1998 18:24:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA19922 for ; Sun, 30 Aug 1998 18:23:57 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA16351; Sun, 30 Aug 98 18:21:12 EDT Received: (from perry@localhost) by jekyll.piermont.com (8.8.8/8.6.12) id SAA16754; Sun, 30 Aug 1998 18:21:13 -0400 (EDT) To: scwm-discuss@mit.edu Subject: current problems Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 30 Aug 1998 18:21:12 -0400 Message-Id: <873eaeun53.fsf@jekyll.piermont.com> Lines: 22 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've finally switched to using the anonymous CVS archive to track scwm thanks to the replacement of usleeps with ms_sleeps, I can now successfully double click for the first time (yay!) and my problems with move-or-raise also went away. I am now experiencing the following problems: 1) Brand new, I cannot move any windows within a pixel of the border of the screen (or perhaps two pixels?) -- in fact, starting windows relative to the border places them a pixel or two off, and I can't drag windows between virtual desktops at all any more. !??!? 2) Old problem: I get hangs periodically from scwm, especially when restarting or moving around on the pager. If I stop scwm and restart it manually, this occurs, too, even with no fvwm pager module running any longer (!). I have difficulty, therefore, believing this is solely an fvwm pager problem. This never happened at all, btw, before I upgraded to 0.8a. Perry From owner-scwm-discuss@mit.edu Sun Aug 30 20:16:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20890 for scwm-discuss-outgoing; Sun, 30 Aug 1998 20:16:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA20886 for ; Sun, 30 Aug 1998 20:16:43 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA27417; Sun, 30 Aug 98 20:13:57 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA18500; Sun, 30 Aug 1998 17:13:55 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: error in building References: <87btp2jh5y.fsf@jekyll.piermont.com> From: Greg Badros Date: 30 Aug 1998 17:13:55 -0700 In-Reply-To: "Perry E. Metzger"'s message of "30 Aug 1998 17:25:45 -0400" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/X11R6/include -g -O2 -c scwmrepl.c > scwmrepl.c: In function `appending_fgets': > scwmrepl.c:139: `stdio' undeclared (first use this function) > scwmrepl.c:139: (Each undeclared identifier is reported only once > scwmrepl.c:139: for each function it appears in.) > gmake[2]: *** [scwmrepl.o] Error 1 > > I believe line 139 should actually use "stdout" instead of "stdio". > > I don't know how this ever worked... Me neither. Thanks for doing the clean build and finding this. I'll have to try to do clean builds more often, it seems! :-) Just fixed in the repo. Thanks! Greg From owner-scwm-discuss@mit.edu Sun Aug 30 21:01:26 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA21200 for scwm-discuss-outgoing; Sun, 30 Aug 1998 21:01:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA21197 for ; Sun, 30 Aug 1998 21:01:23 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA01761; Sun, 30 Aug 98 20:58:37 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA18553; Sun, 30 Aug 1998 17:58:37 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: a key event problem and a scwm function request References: <19980830215916Z276516-15944+128@pulsar.halcyon.com> From: Greg Badros Date: 30 Aug 1998 17:58:37 -0700 In-Reply-To: Ken Pizzini's message of "Sun, 30 Aug 1998 14:59:15 -0600" Message-Id: Lines: 56 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > [my configuration: scwm-0.8a; linux-2.0.33 for iX86; X11R6.3] > > I'm puzzled by a problem I'm having. I have the following > form in my .scwmrc file: > (bind-key 'all "H-S-Tab" > (lambda () > (prev-window #:only visible? #:except iconified?))) > > For some reason this only works if I use my Shift_R key; if I use my > Shift_L key _nothing_ happens. As long as I'm using my Shift_R key > I can use either Hyper_L or Hyper_R just fine. Other keybindings > where I use the H-S- prefix work fine with either shift key. Any > ideas out there? Your X modifier mapping is messed up, probably. Read the xmodmap man page. > > Hmmm... it probably isn't scwm's fault: I just fired up xev and > sure enough I see the events for Hyper_L down, Shift_L down, and > then when I press the Tab key *no* additional events are reported. > I guess I'm probably stuck with living with this quirk, but if > anyone has any clues to offer I'd sure like to hear them... Which X server? Can you reproduce this w/o any changes to the modifiers (i.e., w/o running xmodmap). > And my other question: what is the simplest way to query an attribute > of a window's style? For example, I wish to create a "toggle-squashed" > function (I realize this won't work , but I'm writing it with the > expectation that it will work someday). But I'm not finding the > functional equivalent of "(get-window-style w #:squashed-titlebar)" > in the docs. BTW, my request is not specific to #:squashed-titlebar --- > for example, in another place I'd like to query #:show-icon, and I > suspect that the list may grow as time goes on. Actually, for the > specific uses I'm after, something vaugely like > (style-one-window w #:toggle-attribute #:squashed-titlebar) Maciej was doing a rewrite of some of this stuff before his vacation. As it is now, you can often get at the information somehow, but it's not consistent. For squashed-titlebar, you'd use (object-property WIN 'squashed-titlebar). (get-show-icon WIN) doesn't seem to exist, right yet, but I'm sure it's going to be fixed by Maciej as part of his rewrite. > would suit me also. Did I manage to miss either of these in the > documentation? Or if they don't currently exist, what do y'all > think about adding either of them? They'll be there in a couple weeks, I'll bet. Thanks for reminding us of the inconsistency. Greg From owner-scwm-discuss@mit.edu Sun Aug 30 21:03:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA21235 for scwm-discuss-outgoing; Sun, 30 Aug 1998 21:03:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA21232 for ; Sun, 30 Aug 1998 21:03:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11502; Sun, 30 Aug 98 21:00:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA18575; Sun, 30 Aug 1998 18:00:14 -0700 (PDT) To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: current problems References: <873eaeun53.fsf@jekyll.piermont.com> From: Greg Badros Date: 30 Aug 1998 18:00:14 -0700 In-Reply-To: "Perry E. Metzger"'s message of "30 Aug 1998 18:21:12 -0400" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I've finally switched to using the anonymous CVS archive to track scwm > > thanks to the replacement of usleeps with ms_sleeps, I can now > successfully double click for the first time (yay!) and my problems > with move-or-raise also went away. Good! > > I am now experiencing the following problems: > > 1) Brand new, I cannot move any windows within a pixel of the border > of the screen (or perhaps two pixels?) -- in fact, starting windows > relative to the border places them a pixel or two off, and I can't > drag windows between virtual desktops at all any more. !??!? Drag how? From the pager? > 2) Old problem: I get hangs periodically from scwm, especially when > restarting or moving around on the pager. If I stop scwm and restart > it manually, this occurs, too, even with no fvwm pager module running > any longer (!). I have difficulty, therefore, believing this is solely > an fvwm pager problem. This never happened at all, btw, before I > upgraded to 0.8a. When it happens, `strace -p ' to figure out what the scwm and/or fvwm2 processes are doing. Killing the pager process often unhangs scwm for me. We'll look into it, as I've been able to repro this for a while. Greg From owner-scwm-discuss@mit.edu Mon Aug 31 07:25:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA24349 for scwm-discuss-outgoing; Mon, 31 Aug 1998 07:25:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA24344 for ; Mon, 31 Aug 1998 07:25:22 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA10843 for scwm-discuss@huis-clos.mit.edu; Mon, 31 Aug 1998 13:22:09 +0200 (CEST) Received: (qmail 941 invoked by uid 115); 31 Aug 1998 08:07:49 -0000 To: scwm-discuss@mit.edu Subject: Re: a key event problem and a scwm function request References: <19980830215916Z276516-15944+128@pulsar.halcyon.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 31 Aug 1998 10:07:47 +0200 In-Reply-To: Ken Pizzini's message of "Sun, 30 Aug 1998 14:59:15 -0600" Message-ID: Lines: 40 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 30 Aug 1998 14:59:15 -0600 >>>>> Ken Pizzini said: Ken> Hmmm... it probably isn't scwm's fault: I just fired up xev and Ken> sure enough I see the events for Hyper_L down, Shift_L down, and Ken> then when I press the Tab key *no* additional events are Ken> reported. I guess I'm probably stuck with living with this Ken> quirk, but if anyone has any clues to offer I'd sure like to Ken> hear them... You should definitely check your xmodmap or xkb config. Or try running X with another (default) key configuration and see what happens. There may also be the remote possibility, that it is a hardware problem. Because not every key on a normal keyboard is wired separately, weird things can happen, when you hold down multiple keys. (For example, if I press-and-hold-down x, v, and g, keycode 135 is reported, not the normal 42 for g.) OTOH, modifier keys *should* have separate wiring. Ken> And my other question: what is the simplest way to query an Ken> attribute of a window's style? You can't do that right now. Window styles are not saved straight away, but are rather transformed to procedures of the form (lambda (win) (if (condition-met win) (do-thing win))) that are called once at the call of `window-style', and for each new window afterwards. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 31 07:25:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA24354 for scwm-discuss-outgoing; Mon, 31 Aug 1998 07:25:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA24351 for ; Mon, 31 Aug 1998 07:25:32 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA10969 for scwm-discuss@huis-clos.mit.edu; Mon, 31 Aug 1998 13:22:33 +0200 (CEST) Received: (qmail 2091 invoked by uid 115); 31 Aug 1998 11:20:50 -0000 To: scwm-discuss@mit.edu Subject: Re: Root-window handling References: <199808222134.OAA16844@fielder.cs.washington.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 31 Aug 1998 13:20:47 +0200 In-Reply-To: Greg Badros's message of "30 Aug 1998 13:49:38 -0700" Message-ID: Lines: 45 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 30 Aug 1998 13:49:38 -0700 >>>>> Greg Badros said: >> * `window-id': There are no primitives yet that operate on >> window-ids, but it may be handy to give to external programs, >> e.g.: "wininfo -id" (yes I know, most of these take "-root"). Greg> Yep. This (a 3-liner!) will be in CVS in an hour. Greg> I think all of these can ignore the root window for now. That's what I thought, too. Greg> Perhaps. In particular we need a better way to distinguish Greg> between the root window being selecting, and aborting the Greg> selection (which currently isn't supported, I believ). s-w-i beeps and gives #f whenever the root window is clicked on. Greg> I agree and asked Maciej about this a while back and he was Greg> quick to point out that Lisp had the term "property" before X Greg> did. Yes, that's true. I am quite sure, that X (originating at MIT, after all) inherited a great deal of names from Lisp (properties, atoms, ...). Greg> I think we need to always be explicit and say either X Greg> Property or scheme property (I also am trying to make a case Greg> distinction -- X Properties being uppercase "P"). Indeed, I try to be explicit - when talking about them here, and especially in the doc-comments. The uppercase P, I'm not very happy with that. X names its properties in lower case (at least in the man pages I checked). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 31 07:25:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA24355 for scwm-discuss-outgoing; Mon, 31 Aug 1998 07:25:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA24343 for ; Mon, 31 Aug 1998 07:25:22 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA10854 for scwm-discuss@huis-clos.mit.edu; Mon, 31 Aug 1998 13:22:11 +0200 (CEST) Received: (qmail 968 invoked by uid 115); 31 Aug 1998 08:15:26 -0000 To: scwm-discuss@mit.edu Subject: Re: Upcoming changes to xproperty.c References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 31 Aug 1998 10:15:25 +0200 In-Reply-To: Greg Badros's message of "30 Aug 1998 13:58:32 -0700" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 30 Aug 1998 13:58:32 -0700 >>>>> Greg Badros said: Greg> {get,set}-window-text-property, and xproperty->string are all Greg> used in flux.scm, wininfo.scm Thanks, I knew about wininfo, but forgot flux. I'll update these (and scheme/test/properties.scm) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Aug 31 08:35:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA24977 for scwm-discuss-outgoing; Mon, 31 Aug 1998 08:35:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA24974 for ; Mon, 31 Aug 1998 08:35:06 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA29938; Mon, 31 Aug 98 08:32:13 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id IAA20241; Mon, 31 Aug 1998 08:32:08 -0400 (EDT) Message-Id: <199808311232.IAA20241@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: current problems In-Reply-To: Your message of "30 Aug 1998 18:00:14 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 31 Aug 1998 08:32:07 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > 1) Brand new, I cannot move any windows within a pixel of the border > > of the screen (or perhaps two pixels?) -- in fact, starting windows > > relative to the border places them a pixel or two off, and I can't > > drag windows between virtual desktops at all any more. !??!? > > Drag how? From the pager? I can drag things fine in the pager -- I mean using move on the desktop. Perry From owner-scwm-discuss@mit.edu Mon Aug 31 11:34:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA25733 for scwm-discuss-outgoing; Mon, 31 Aug 1998 11:34:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA25730 for ; Mon, 31 Aug 1998 11:34:34 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA01859; Mon, 31 Aug 98 11:31:43 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19281; Mon, 31 Aug 1998 08:31:32 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Root-window handling References: <199808222134.OAA16844@fielder.cs.washington.edu> From: Greg Badros Date: 31 Aug 1998 08:31:32 -0700 In-Reply-To: Robert Bihlmeyer's message of "31 Aug 1998 13:20:47 +0200" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> Perhaps. In particular we need a better way to distinguish > Greg> between the root window being selecting, and aborting the > Greg> selection (which currently isn't supported, I believ). > > s-w-i beeps and gives #f whenever the root window is clicked on. Right. But once we allow s-w-i to abort (using esc, perhaps), then #f should be used for that condition, and 'root-window for clicks on the root window. Greg From owner-scwm-discuss@mit.edu Mon Aug 31 23:03:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA28872 for scwm-discuss-outgoing; Mon, 31 Aug 1998 23:03:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from preforcix.roof.lan (hd52-043.hil.compuserve.com [199.174.232.43]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id XAA28869 for ; Mon, 31 Aug 1998 23:03:11 -0400 Received: (from forcer@localhost) by preforcix.roof.lan (8.9.1/8.9.1) id EAA19429 for scwm-discuss@huis-clos.mit.edu; Tue, 1 Sep 1998 04:59:57 +0200 Message-ID: <19980901045953.A19230@preforcix.roof.lan> Date: Tue, 1 Sep 1998 04:59:53 +0200 From: forcer To: scwm-discuss@mit.edu Subject: Again... scwm click-to-place weirdness Mail-Followup-To: scwm-discuss@huis-clos.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux preforcix 2.0.36 X-URL: http://webserver.de/forcer/ X-Mailer: Mutt 0.93.2i (1998-07-29) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi there... The guy with the long postings is back ;) Seems like my original (second) posting got lost :) I'm using SCWM with click-to-place and experience weird problems... for example, when i open a new xterm the mouse is exactly at the left upper corner as it should be. If i open netscape, the mouse is about the size of the border moved to the top left outside of netscape. With small windows and request windows like Gimp's, the are sometimes very far down left of the pointer, i had it once that they were in a different virtual desktop(!) ... I see no special pattern except that they're always to the lower right of the pointer. The IMHO relevant parts of my .scwmrc: (define font12 (make-font "-adobe-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*")) (define default-decor (make-decor)) (with-decor default-decor (title-style #:font font12 #:justify 'left) (border-style #:no-inset #t #:hidden-handles #f) (set-hilight-foreground! "white") (set-hilight-background! "darkblue")) (define default-style (make-style #:fg "white" #:bg "darkgray" #:icon "unknown1.xpm" #:icon-box (list (x- 70) 1 69 (y- 141)) #:border-width 4 #:focus 'sloppy #:random-placement #f #:smart-placement #f #:mwm-func-hint #f #:mwm-decor-hint #f #:decorate-transient #f #:PPosition-hint #f #:use-decor default-decor)) If anyone could tell me how to better track down this anomaly i'd be more than happy to do so :) Also... i experience (sometimes, getting rarer since 0.7) that scwm just hangs. I can't click on anything anymore, but sloppy focus works, the click-to-place works, and i can type. Also, scwmexec '(restart)' works but doesn't unhang SCWM. strace -p shows it's hanging in a select(), probably waiting for X input. Finally some system infos: Guile 1.3a Scwm Version 0.8 (latest snapshot available at Tue Sep 1 04:58:31 MET) Linux preforcix 2.0.36 #1 Tue Aug 25 22:01:22 MET DST 1998 i586 unknown -forcer -- /* All the simple programs have been written. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Tue Sep 1 00:10:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA29185 for scwm-discuss-outgoing; Tue, 1 Sep 1998 00:10:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA29182 for ; Tue, 1 Sep 1998 00:10:52 -0400 Received: from [202.54.39.140] by MIT.EDU with SMTP id AA29490; Tue, 1 Sep 98 00:07:43 EDT Received: by rakshak.cybercash.co.in; id JAA23081; Tue, 1 Sep 1998 09:38:54 -0400 (EDT) Received: from unknown(164.164.129.10) by rakshak.cybercash.co.in via smap (3.2) id xma023052; Tue, 1 Sep 98 09:38:30 -0400 Received: from spider.cybercash.co.in by cashmail (SMI-8.6/SMI-SVR4) id JAA00940; Tue, 1 Sep 1998 09:32:22 +0530 Date: Tue, 1 Sep 1998 09:32:22 +0530 Message-Id: <199809010402.JAA00940@cashmail> From: pkrishna@cybercash.co.in (Krishna Padmasola) Reply-To: pkrishna@cybercash.co.in (Krishna Padmasola) To: scwm-discuss@mit.edu Subject: problem starting scwm X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I wanted to rty scwm, so I built guile 1.2 and scwm 0.8a. When I try to run it, I get the following message: krishna@sun2:~/fsys2/src/scwm/bin> scwm guile: Stack overflow Exit 2 I am not able to run gdb on it either for the following reason: krishna@sun2:~/fsys2/src/scwm/bin> ldd scwm libXext.so.0 => /usr/openwin/lib/libXext.so.0 libXmu.so.4 => /usr/openwin/lib/libXmu.so.4 libX11.so.4 => /usr/lib/libX11.so.4 libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libguile.so.2 => /fsys2/home/krishna/src/guile/lib/libguile.so.2 libdl.so.1 => /usr/lib/libdl.so.1 libm.so.1 => /usr/lib/libm.so.1 libucb.so.1 => /usr/ucblib/libucb.so.1 libc.so.1 => /usr/lib/libc.so.1 libXt.so.4 => /usr/lib/libXt.so.4 libw.so.1 => /usr/lib/libw.so.1 libintl.so.1 => /usr/lib/libintl.so.1 libresolv.so.1 => /usr/lib/libresolv.so.1 libelf.so.1 => /usr/lib/libelf.so.1 krishna@sun2:~/fsys2/src/scwm/bin> gdb scwm GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.4"... (gdb) r Starting program: /fsys2/home/krishna/src/scwm/bin/scwm ld.so.1: /fsys2/home/krishna/src/scwm/bin/scwm: fatal: libguile.so.2: can't open file: errno=2 Program terminated with signal SIGKILL, Killed. The program no longer exists. If ldd is able to find libguile.so.2, why is loading of the shared lib failing in gdb? Weird! Thanks for any help! -- Krishna Padmasola pkrishna@cybercash.co.in From owner-scwm-discuss@mit.edu Tue Sep 1 11:25:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32570 for scwm-discuss-outgoing; Tue, 1 Sep 1998 11:25:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA32567 for ; Tue, 1 Sep 1998 11:25:25 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA09322; Tue, 1 Sep 98 11:22:23 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23530; Tue, 1 Sep 1998 08:15:07 -0700 (PDT) To: pkrishna@cybercash.co.in (Krishna Padmasola) Cc: scwm-discuss@mit.edu Subject: Re: problem starting scwm References: <199809010402.JAA00940@cashmail> From: Greg Badros Date: 01 Sep 1998 08:15:06 -0700 In-Reply-To: pkrishna@cybercash.co.in's message of "Tue, 1 Sep 1998 09:32:22 +0530" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk pkrishna@cybercash.co.in (Krishna Padmasola) writes: > Hi, > > I wanted to rty scwm, so I built guile 1.2 and scwm 0.8a. > When I try to run it, I get the following message: Try a recent snapshot of guile instead of 1.2; we're waiting for a 1.3 release and hoping that it'll be real soon now, so 1.2 support has been neglected recently. Good luck, and definitely let us know if you have problems with a more recent version of guile. Thanks, Greg > (gdb) r > Starting program: /fsys2/home/krishna/src/scwm/bin/scwm > ld.so.1: /fsys2/home/krishna/src/scwm/bin/scwm: fatal: libguile.so.2: can't open file: errno=2 > You can try running "truss" or "strace" on starting scwm to see what's happening more closely (may not work if you only have the problem loading the shared librarry under gdb). From owner-scwm-discuss@mit.edu Tue Sep 1 19:31:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA02269 for scwm-discuss-outgoing; Tue, 1 Sep 1998 19:31:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA02266 for ; Tue, 1 Sep 1998 19:31:44 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA07783; Tue, 1 Sep 98 19:28:34 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA24386; Tue, 1 Sep 1998 16:28:36 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Big changes that you hopefully will not notice From: Greg Badros Date: 01 Sep 1998 16:28:36 -0700 Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk My recent commits today changed how window and icon positions are stored internally. Before this commit, windows and icons had their positions stored in terms of the viewport location. Positions between 0 and the screen size meant the icon was visible on the currently-displayed viewport. To make things easier for the constraint solver to handle (and arguably more correct), my recent changes make icons' and windows' positions be stored in terms of their virtual position, and their actual onscreen (viewport) position is found by considering the current viewport offset (i.e., Scr.Vx, Scr.Vy). Sticky windows are still stored as a viewport position (which means that the stored position will change when a window is converted to a sticky window if the viewport is not at 0,0.). What does this mean for you? Hopefully, nothing. Realistically, there are likely bugs. Also, there are some changes in behaviour. E.g., `window-position' returns the virtual position now and window-viewport-position returns the viewport position of the window. `move-to' moves a window to a viewport position (as it did before -- the name will likely change in the future but was kept for compatibility tentatively), and move-window moves a window to a specified virtual position. Overall, this change makes explicit some of the viewport vs. virtual positioning issues (documentation has been updated somewhat to clarify these issues). I have done enough testing on my own that I am interested in problems you discover, so please keep the bug reports coming. Thanks, Greg From owner-scwm-discuss@mit.edu Wed Sep 2 03:56:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA04996 for scwm-discuss-outgoing; Wed, 2 Sep 1998 03:56:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA04993 for ; Wed, 2 Sep 1998 03:56:27 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA15940 for scwm-discuss@huis-clos.mit.edu; Wed, 2 Sep 1998 09:53:14 +0200 (CEST) Received: (qmail 14262 invoked by uid 115); 1 Sep 1998 11:27:09 -0000 To: scwm-discuss@mit.edu Subject: X atom primitives X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 01 Sep 1998 13:27:07 +0200 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, as far as I can see, primitives handling X atoms are needed before implementation of some protocols in scheme is possible. The code for the procedures `X-atom->string' and `string->X-atom' will be in the repository soon. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Sep 2 11:35:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06697 for scwm-discuss-outgoing; Wed, 2 Sep 1998 11:35:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06694 for ; Wed, 2 Sep 1998 11:35:30 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA26102; Wed, 2 Sep 98 11:32:13 EDT Received: by tis.bellhow.com; id LAA17395; Wed, 2 Sep 1998 11:32:11 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma017370; Wed, 2 Sep 98 11:32:07 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA20675 for ; Wed, 2 Sep 1998 11:32:07 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Big changes that you hopefully will not notice Date: Wed, 02 Sep 1998 15:32:07 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f36325.182257332@smtp> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA06695 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 01 Sep 1998 16:28:36 -0700, you wrote: >My recent commits today changed how window and icon positions are stored >internally. . . . >Overall, this change makes explicit some of the viewport vs. virtual >positioning issues (documentation has been updated somewhat to clarify >these issues). > >I have done enough testing on my own that I am interested in problems >you discover, so please keep the bug reports coming. When you move a window around with a mouse on a viewport other than 0,0, the red rubber band thing appears for just a flash, and then is gone. The window does get moved to the right place. Move operation appears normal on the 0,0 viewport. A window shade operation make the window disappear. If you move to a different viewport and than back again, the window appears. This is again only on non-0,0 viewports. Dale From owner-scwm-discuss@mit.edu Wed Sep 2 13:02:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA07231 for scwm-discuss-outgoing; Wed, 2 Sep 1998 13:02:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA07228 for ; Wed, 2 Sep 1998 13:02:46 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA18313; Wed, 2 Sep 98 12:59:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA26005; Wed, 2 Sep 1998 09:59:19 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Big changes that you hopefully will not notice References: <35f36325.182257332@smtp> From: Greg Badros Date: 02 Sep 1998 09:59:18 -0700 In-Reply-To: smithd@bellhow.com's message of "Wed, 02 Sep 1998 15:32:07 GMT" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > When you move a window around with a mouse on a viewport other than 0,0, > the red rubber band thing appears for just a flash, and then is gone. > The window does get moved to the right place. Ok, fixed. > > Move operation appears normal on the 0,0 viewport. Good -- this is a good test, as the mistakes will generally be either using FRAME_[XY] instead of FRAME_[XY]_VP (vp == viewport position) or forgetting to add Scr.Vx, Scr.Vy into a viewport x,y pair. At the upper-left (0,0) viewport, these operations are null, so the bug won't manifest itself. Another test case is using a partially offset viewport (e.g., 100,100, instead of a full-screen offset). Then windows won't disappear, they'll just move when they shouldn't've. > A window shade operation make the window disappear. If you move to a different > viewport and than back again, the window appears. This is again only on non-0,0 > viewports. Fixed. And fixed some related bugs, too (resize was surprisingly screwed up, popup menus from decorations was broken, etc). I ended up leaving in a bit of a rush yesterday and seemed to have missed some stuff that I should've found before committing. My apologies and thanks! The current snapshot is a lot more correct on all of these issues (though icons still could use some more testing). Thanks, Greg From owner-scwm-discuss@mit.edu Wed Sep 2 14:03:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA07757 for scwm-discuss-outgoing; Wed, 2 Sep 1998 14:03:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA07754 for ; Wed, 2 Sep 1998 14:03:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06602; Wed, 2 Sep 98 14:00:13 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA26291; Wed, 2 Sep 1998 11:00:14 -0700 (PDT) Cc: scwm-discuss@mit.edu To: Craig Kaplan Subject: cut-buffer revisited... From: Greg Badros Date: 02 Sep 1998 11:00:13 -0700 Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Well, thanks to Robert's recent improvements, you can now write the following: (X-property-get 'root-window "CUT_BUFFER0") to get at the X cut buffer. I just added `X-cut-buffer-string' to flux.scm to better support expressing this abstraction. Unfortunately, the more advanced X selection mechanism is still not supported... the convenience routines are all in Intrinsics. How do people feel about dynamically linking against Intrinsics (i.e., libXt*)? Seems to me as though the shared library is going to be in memory anyway, and the build procedure wouldn't get much more complicated, and Xt is ubiquitous, so it might not be a big deal. Comments and feedback are appreciated as always! Greg From owner-scwm-discuss@mit.edu Thu Sep 3 08:43:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA13668 for scwm-discuss-outgoing; Thu, 3 Sep 1998 08:43:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA13665 for ; Thu, 3 Sep 1998 08:43:26 -0400 Received: from [152.78.71.3] by MIT.EDU with SMTP id AA21544; Thu, 3 Sep 98 08:39:51 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.115.98]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id NAA13266 for ; Thu, 3 Sep 1998 13:37:07 +0100 (BST) Message-Id: <8787.199809031239@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Thu, 3 Sep 1998 13:39:48 +0100 Date: Thu, 3 Sep 1998 13:39:45 +0100 (BST) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Maximise window... To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Scwm seems to maximise the window vertically, but not horizontally... how do I fix this? Also, in the current CVS updates I get, log-usage.c and changed.c are missing from the scwm/Makefile. Mark. From owner-scwm-discuss@mit.edu Thu Sep 3 09:16:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA14099 for scwm-discuss-outgoing; Thu, 3 Sep 1998 09:16:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA14096 for ; Thu, 3 Sep 1998 09:16:09 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id PAA03363 for scwm-discuss@huis-clos.mit.edu; Thu, 3 Sep 1998 15:12:15 +0200 (CEST) Received: (qmail 3523 invoked by uid 115); 3 Sep 1998 12:54:07 -0000 To: scwm-discuss@mit.edu Subject: `focus' does not raise X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Sep 1998 14:54:07 +0200 Message-ID: Lines: 20 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" X-Now-Playing: Tom Waits - Temptation Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, have I missed something? At least in cassowary scwm, `(focus win)' does not raise win anymore. The same is true for `warp-to-window', this can even result in another window getting the focus (because the mouse pointer is warped into this other window that is above the given one. The documentation for these procedures does however, not state that the windows get raised. Intentional? If not, docs need to be fixed, too. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Sep 3 11:21:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA15332 for scwm-discuss-outgoing; Thu, 3 Sep 1998 11:21:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA15329 for ; Thu, 3 Sep 1998 11:21:07 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03178; Thu, 3 Sep 98 11:17:42 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28211; Thu, 3 Sep 1998 08:17:35 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Maximise window... References: <8787.199809031239@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 03 Sep 1998 08:17:34 -0700 In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 13:39:45 +0100 (BST)" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Hi, > Scwm seems to maximise the window vertically, but not horizontally... > how do I fix this? See gjb.scwmrc -- search for maximize. The basic procedure takes a new-width and a new-height; setting these appropriately will give you the behaviour you desire. > > Also, in the current CVS updates I get, log-usage.c and changed.c are > missing from the scwm/Makefile. Makefile.am is in the CVS archive, but Makefile is not -- you need to regenerate it using automake. See HACKING for details. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 11:28:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA15358 for scwm-discuss-outgoing; Thu, 3 Sep 1998 11:28:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA15355 for ; Thu, 3 Sep 1998 11:28:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04098; Thu, 3 Sep 98 11:25:05 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28215; Thu, 3 Sep 1998 08:24:29 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: `focus' does not raise References: From: Greg Badros Date: 03 Sep 1998 08:24:29 -0700 In-Reply-To: Robert Bihlmeyer's message of "03 Sep 1998 14:54:07 +0200" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > have I missed something? At least in cassowary scwm, `(focus win)' > does not raise win anymore. The same is true for `warp-to-window', > this can even result in another window getting the focus (because the > mouse pointer is warped into this other window that is above the given > one. > > The documentation for these procedures does however, not state that > the windows get raised. > > Intentional? Not specifically intentional, but the behaviour sounds right to me. It's certainly easier to add the raising as a side effect from scheme than to somehow counteract the raising of the window if it were implicit. > If not, docs need to be fixed, too. The docs still need to be fixed because the situation was sufficiently contrary to your expectations as to evoke confusion. I added an extra explanation and specifically note that the window won't be raised. Commit will happen after I get through the other morning bug-fixes. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Sep 3 11:35:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA15394 for scwm-discuss-outgoing; Thu, 3 Sep 1998 11:35:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA15389 for ; Thu, 3 Sep 1998 11:35:31 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06079; Thu, 3 Sep 98 11:32:01 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28220; Thu, 3 Sep 1998 08:32:02 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Big changes that you hopefully will not notice References: <35f36325.182257332@smtp> <35f7ade2.266925718@smtp> From: Greg Badros Date: 03 Sep 1998 08:32:02 -0700 In-Reply-To: smithd@bellhow.com's message of "Thu, 03 Sep 1998 15:06:21 GMT" Message-Id: Lines: 42 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > Yes, Much better. > > I did have a problem though. I tied to move a window and it went away. > I did find it in the pager, but when I clicked to that viewport, the missing > window moved again. As if it was always one viewport off, down and to the right. This would happen if a sticky window had coordinates that exceeded the display width and height. I don't presently prevent this, but when a window becomes sticky, it will stay where it is relative to the current viewport. This means that if a window off screen becomes sticky, it'll stay offscreen until moved somewhere on screen. Sticky windows' position is in terms of the viewport coordinates, whereas all other windows' position is in terms of the virtual coordinates (and `window-viewport-position' will convert them to the viewport system). > Also the pager was acting really weird. I couldn't see a pattern. Clicking on > a view in the pager didn't always move to the right viewport. Or it *did*, but the > pager was displaying the wrong viewport. I'll look into it. I've not tested interactions with the pager as much as I should. Have you exercised the icon code much? I (surprisingly, since I often have forgotten about icons) did some icon testing, but don't use them regularly so they are always potential candidate for substantial end-user testing. > I also got these warnings: > > make[2]: Entering directory `/home/users10/smithd/src/scwm-19980903/utilities/scwmexec' > Makefile:250: .deps/scwmexec.P: No such file or directory > gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/openwin/include -g -O2 -c scwmexec.c > scwmexec.c: In function `main': > scwmexec.c:59: warning: passing arg 4 of `scwmexec_exec_full' from incompatible pointer type > scwmexec.c:59: warning: passing arg 5 of `scwmexec_exec_full' from incompatible pointer type Ok, fixed now. Thanks. And thanks. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 12:45:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA15848 for scwm-discuss-outgoing; Thu, 3 Sep 1998 12:45:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA15845 for ; Thu, 3 Sep 1998 12:45:08 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA27982; Thu, 3 Sep 98 12:41:38 EDT Received: by tis.bellhow.com; id MAA27886; Thu, 3 Sep 1998 12:41:41 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma027758; Thu, 3 Sep 98 12:41:09 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA01785 for ; Thu, 3 Sep 1998 12:41:09 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Big changes that you hopefully will not notice Date: Thu, 03 Sep 1998 16:41:09 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f8c2b5.272256063@smtp> References: <35f36325.182257332@smtp> <35f7ade2.266925718@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA15846 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 03 Sep 1998 08:32:02 -0700, you wrote: >Have you exercised the icon code much? I (surprisingly, since I often >have forgotten about icons) did some icon testing, but don't use them >regularly so they are always potential candidate for substantial >end-user testing. I hardly *ever* use icons. I usually use fairly large xterms or emacs's and use the pager to jump around. So go ahead, take a close look at the pager. Don't worry about icons. :) >Ok, fixed now. Thanks. And thanks. Thank *YOU*!! Dale From owner-scwm-discuss@mit.edu Thu Sep 3 13:04:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA16174 for scwm-discuss-outgoing; Thu, 3 Sep 1998 13:04:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA16171 for ; Thu, 3 Sep 1998 13:04:32 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05820; Thu, 3 Sep 98 13:01:02 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA28429; Thu, 3 Sep 1998 10:00:51 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Big changes that you hopefully will not notice References: <35f36325.182257332@smtp> <35f7ade2.266925718@smtp> <35f8c2b5.272256063@smtp> From: Greg Badros Date: 03 Sep 1998 10:00:50 -0700 In-Reply-To: smithd@bellhow.com's message of "Thu, 03 Sep 1998 16:41:09 GMT" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On 03 Sep 1998 08:32:02 -0700, you wrote: > > >Have you exercised the icon code much? I (surprisingly, since I often > >have forgotten about icons) did some icon testing, but don't use them > >regularly so they are always potential candidate for substantial > >end-user testing. > > I hardly *ever* use icons. I usually use fairly large xterms or emacs's > and use the pager to jump around. So go ahead, take a close look at > the pager. Don't worry about icons. :) Well, I can't not worry about them because they have their users. I don't want it to sound like I don't want scwm to support icons -- I do want scwm to support icons and have spent considerable effort (albeit often belatedly, when users point out problems) keeping icons working reasonably well. That feedback is essential to making icons work right, so please do keep it coming. Personally, I prefer windows to just be hidden when iconified, then I use a window list of only icons to deiconify windows when I want to unhide them. Saves screen real-estate, and reduces touching the mouse since I can deiconify any window using the keyboard from the iconified window list. > >Ok, fixed now. Thanks. And thanks. > > Thank *YOU*!! You're welcome. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 13:15:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA16318 for scwm-discuss-outgoing; Thu, 3 Sep 1998 13:15:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA16315 for ; Thu, 3 Sep 1998 13:15:18 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA13327 for scwm-discuss@huis-clos.mit.edu; Thu, 3 Sep 1998 19:11:52 +0200 (CEST) Received: (qmail 3642 invoked by uid 115); 3 Sep 1998 13:23:12 -0000 To: scwm-discuss@mit.edu Subject: Re: cut-buffer revisited... References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Sep 1998 15:23:12 +0200 In-Reply-To: Greg Badros's message of "02 Sep 1998 11:00:13 -0700" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" X-Now-Playing: Endraum - Krumme Schatten im stummen Muster Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 02 Sep 1998 11:00:13 -0700 >>>>> Greg Badros said: Greg> How do people feel about dynamically linking against Intrinsics Greg> (i.e., libXt*)? I would much prefer to put the scheme-Xt-glue into a dynamic library, that in turn depends on libXt.so. This would look much the some in normal scheme usage (just issue `use-modules' - the module is not scheme source, but a dynamic library). This is arguably more work. Providing a fallback for systems without a guile supporting dynaloading would also be good. With this in mind, you could as well implement the normal solution right away. It can become the fallback when the dynamic solution is done. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Sep 3 13:42:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA16514 for scwm-discuss-outgoing; Thu, 3 Sep 1998 13:42:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA16511 for ; Thu, 3 Sep 1998 13:42:35 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17720; Thu, 3 Sep 98 13:39:05 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA28452; Thu, 3 Sep 1998 10:39:08 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Event rewrite proposal, revised From: Greg Badros Date: 03 Sep 1998 10:39:08 -0700 Message-Id: Lines: 264 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk The below is a revision of my event rewrite proposal; mostly section 1 has been simplified and generalized. Section 3, on dispatch, has been elevated to the table of contents, but contains the same text (which was in section 2 previously). Comments and feedback are appreciated. This is pretty explicit, but places where I hand wave are legitimate criticisms. Remember, I'm going to be implementing this stuff, so catching problems or vague areas now would be a *big* help. Thanks, Greg Event Rewrite Proposal for Scwm Greg J. Badros, 6-Aug-1998, revised 2-Sep-1998, 3-Sep-1998 (Inspired by conversations w/ Maciej and his "events" proposal in this same directory) Intro: ------ Motivating desires for a more flexible event-binding infrastructure o Elimination of "contexts" and replacing with event maps -- event maps are more fundamental, and unifying o Mode-specific event maps (e.g., when in an interactive move) o Pinnable-menus event maps o Multi-key bindings with prefix keys that change mode map o Maps on a per window basis (e.g., xlogo could permit fewer modifier keys to accompany an "m" keystroke to signify a desire to move the window) o Quoting mechanism for turning off scwm's handling of events o Unifying X-events and user events As you wrote, event maps and event objects should be exposed to the scheme layer as SMOBs (first class objects). The event maps will contain event objects which are bound to procedures to be invoked. Event maps will be attached to X windows (via Xlib's SaveContext mechanism) and scheme window objects (using their top-level frame window). E.g., an event map can be attached to a titlebar button window, or to the titlebar window, etc. Overview: --------- 1 - Event Objects 2 - Event Map Objects 3 - Dispatch of Events 4 - Binding of Event Maps 1 - Event objects: ------------------ (make-key-event KEYSYM-NAME #&optional MODIFIER-SPECIFIER) e.g.: (make-key-event "F1") (make-key-event "Return" (with-modifier 'control 'shift 'meta)) KEYSYM-NAME is the name of a keysym (e.g., "x", "BackSpace", etc.). It cannot have prefixed modifiers -- a convenience function can provide conversions from (e.g., "C-S-M-Return" to the 2nd example above). [[ The special pseudo-keysyms "KeyPress" and "KeyRelease" permit events being bound to some combination of modifier keys just being depressed or released. (These may not be necessary thanks to make-x-event)]] MODIFIER-SPECIFIER is an cons pair of bitmasks for the modifier bits of the event: (MUST-BE-ON . MUST-BE-OFF). E.g., if bit 2 corresponds to the meta modifier, (4 . 0) would match events with at least the Meta modifier depressed, while (0 . 4) would match only events without the Meta modifier depressed. `with-modifier' and other convenience functions will be provided to simplify the writing of the MODIFIER-SPECIFIER. They will permit using logical modifiers using symbols (e.g., 'control 'meta 'hyper 'super, etc.) and physical modifiers by numbers (e.g., 1 refers to whatever mod1 is). Call the modifiers of the key event: MOD. The event matches the MODIFIER-SPECIFIER iff: ((MOD | OnMask == MOD) && (MOD & ~OffMask == MOD)). (make-mouse-event BUTTON-SPECIFIER X-EVENT-SPECIFIER #&optional MODIFIER-SPECIFIER) e.g., (make-mouse-event 1 'release) (make-mouse-event 3 'double-click (with-modifier 'control 'meta 'shift)) BUTTON-SPECIFIER is the physical number of the button (a level of indirection could easily be provided by variables named e.g., select drag and menu, corresponding to buttons 1 2 and 3). Button number 0 matches any/all buttons. Chorded buttons are not specifiable directly -- the attached proc will have to check the event if they are desired (their complexity for user interaction is worth discouraging). X-EVENT-SPECIFIER is one of 'motion, 'press, 'release, 'click, or 'double-click. ('click may be the same as 'release, but 'double-click gets manufactured by scwm). E.g., the below are valid MOUSE_SPECIFIERs MODIFIER-SPECIFIER is as described above. (make-x-event X-EVENT-SPECIFIER #&optional MODIFIER-SPECIFIER) e.g., (make-x-event 'enter-notify) (make-x-event 'keypress (with-modifer 'control 'shift 'meta)) (make-x-event 'pointer-motion (with-modifier 'hyper)) X-EVENT-SPECIFIER is a symbol referring to an X11 event. keypress, keyrelease, enter-notify, leave-notify, pointer-motion, property-notify, colormap-notify, focus-in, focus-out, etc. could be supported (see include/X11/X.h for list). Binding procedures to these events could replace some of the ad-hoc mechanisms for property-notification, etc., that we currently have in scwm. MODIFIER-SPECIFIER is as described above. It is included mostly for completeness and orthogonality. 'keypress events may test for modifiers using the current state of the modifiers, not the state under which the key was pressed. E.g., if Ctrl-Shift-Meta is depressed, whichever of the three modifier keys that is physically registered last will not be in the modifier bitmask for that keypress, but we might like to bind something (e.g., a help menu) to those three keys being held down. Note that make-x-event is the most primitive case, and the other two procedures can be seen as adding a C-level filter on top of the actual X-event. E.g., (make-mouse-event 1 'release) is applicable if there is a x-event "ButtonRelease" and the button number is 1. 2 - Event Map Objects: ---------------------- Now, on to event map objects. My proposal is similar to yours but instead of managing the installed event-map from Scheme code, I want to attach event map objects to arbitrary X11 windows (e.g., the pager, or a pinned menu, etc.), and have the appropriate grabs and XSelectInput calls happen based on the event map for a given window. First, a means of creating event-maps and populating them with bindings from events to procedures: (make-event-map #&optional PARENT MERGE?) ;; PARENT is an event-map object, or omitted or #f to indicate no parent (I don't think we need to worry about delaying events, but I'm not sure what problem that suggestion was trying to solve). This will permit a form of inheritance of behaviours. Note, though, that this mechanism should not be necessary for the geometry-based chaining that X11 commonly uses. E.g., an event in a window decoration (say, a button on the titlebar) will first dispatch based on the event map (if any) attached to the decoration, then on the event map for that top-level window, then on the global event map. Each of these event maps would be built with the PARENT argument omitted or #f. A special primitive or symbol can be bound to an event to permit preventing the event from propagating, and instead letting it pass to the application. MERGE? is #t to indicate that the resulting event-map should (for the purposes of event dispatch) treat the PARENT's bindings as equipotent to this new child event (i.e. all of the bindings will be checked when doing dispatch). MERGE? is #f to indicate that only if no binding matched in the child should the parent's bindings be checked. event-map-global ;; the built-in global event-map object -- it is an implicit, ;; non-merged parent of all event-maps (event-map-parents EVENT-MAP) ;; Return list of cons pairs (PARENT-EVENT-MAP . MERGE?) (add-event-map-parent! EVENT-MAP PARENT MERGE?) ;; Permit multiple parents, though only one can be specified at a time (add-event-binding EVENT-MAP EVENT PROC-OR-SYMBOL) (remove-event-binding EVENT-MAP EVENT) ;; Similar to your {add,remove}-event-hook. ;; These add and remove bindings for EVENT objects in the given ;; EVENT-MAP object. ;; PROC-OR-SYMBOL is either a procedure or 'pass to indicate ;; that the event should not be grabbed by the wm and the application ;; should get the event (this is only an issue for event maps attached ;; to client windows). See dispatch-event for details about how ;; the bindings are invoked. (list-event-bindings EVENT-MAP) ;; return a list of all the event bindings added to EVENT-MAP ;; as a cons parent of (EVENT-OBJECT . PROC-OR-SYMOBL) 3 - Dispatch of Events ---------------------- (dispatch-event EVENT-MAP EVENT) ;; EVENT-MAP is an event-map object, EVENT is an event-object ;; All applicable events' procedures should be invoked in the order that ;; they were added to the EVENT-MAP. Parent EVENT-MAPs are handled ;; as discussed above. ;; Each procedure is invoked with four arguments: ;; #1 - the scheme object that the event acted on/in (e.g., for a button ;; decoration, it will be that top-level frame; for a menu it will be ;; the menu object, etc.), or #f if there is no applicable scheme object ;; (e.g., the root window) ;; #2 - the event object that caused this dispatch (i.e. EVENT) ;; #3 - the event map object (i.e. EVENT-MAP) ;; #4 - the window id of the X window that got the event. We can add ;; primitives to query what decoration/menu/whatever a window ID is ;; We may need to do something to help simplify binding simple ;; procedures to an event (maybe something like Emacs's (interactive) ;; declaration), but I think we need all of the above (and maybe more) ;; to get a lot of useful functionality. ;; Only when no bindings are applicable in the child or its chain of ;; parents should the event dispatching mechanism ;; proceed to chain the event dispatch up to the enclosing event-map ;; context. That is, from decoration->frame->global (button decorations ;; perhaps should forward to the titlebar before the frame, but side-bar ;; decorations probably should not). ;; This primitive is what will get internally invoked when Scwm gets ;; an event. Note that Scwm will have to manage selecting the ;; appropriate events and grabbing the appropriate keys based on ;; the event-map objects attached to various windows. ;; Note that my proposed automatic chaining is a restriction (for ;; programming understanding and reasoning purposes) on a more general ;; notion of a procedure to be called when no event binding matches -- ;; the chaining could be made more explicit and put under programmer ;; control using this primitive. 4 - Binding of Event Maps: -------------------------- Event maps can be attached to any X Window by its X Id. We can add primitives that give the window id from a SCWM top-level window and a decoration specifier. (attach-event-map X-WINDOW-ID EVENT-MAP) e.g., (attach-event-map (button-n-of 1 win) button-1-map-for-win) (attach-event-map (title-bar-of win) title-bar-map-for-win) ;; Only one event map is attached per window id -- attaching ;; a new map removes any old one The window style mechanism should be used to attach a set of event maps at startup for a given window style, e.g.: (window-style "*" #:event-maps (list (1 . default-button-1-map) ('title . default-title-map) ('window . default-window-map))) [this avoids a bunch of attach-event-maps from being needed in the new-window-hook -- the attaching of the default event maps needs to be efficient, since it'll happen for each new window and on lots of decorations -- it's only a single XSaveContext call for each attachment, which shouldn't be too bad]. (event-map-for X-WINDOW-ID) ;; Return the currently attach event-map object, if any, or #f (remove-event-map X-WINDOW-ID) ;; detach any event map from X-WINDOW-ID I'll try to come up with an example of using this system but please feel free to poke holes in it or query me about how one might accomplish something you're interested in being able to do. (Or if you think it's redundant, overly-general, inefficient, etc.). Thanks! From owner-scwm-discuss@mit.edu Thu Sep 3 14:11:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA16809 for scwm-discuss-outgoing; Thu, 3 Sep 1998 14:11:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA16804 for ; Thu, 3 Sep 1998 14:11:48 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA26753; Thu, 3 Sep 98 14:08:19 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA28485; Thu, 3 Sep 1998 11:08:06 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: cut-buffer revisited... References: From: Greg Badros Date: 03 Sep 1998 11:08:05 -0700 In-Reply-To: Robert Bihlmeyer's message of "03 Sep 1998 15:23:12 +0200" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 02 Sep 1998 11:00:13 -0700 > >>>>> Greg Badros said: > > Greg> How do people feel about dynamically linking against Intrinsics > Greg> (i.e., libXt*)? > > I would much prefer to put the scheme-Xt-glue into a dynamic library, > that in turn depends on libXt.so. This would look much the some in > normal scheme usage (just issue `use-modules' - the module is not > scheme source, but a dynamic library). This seems like the right thing to do. Perhaps the useful functionality of Intrinsics that we care about has already been wrapped by guile-gtk. If it's not, it might make even more sense to add the appropriate selection-related functionality to that library. (I just don't know enough about GTk as yet -- Maciej has more relevant experience there, and he'll be back soon.) > This is arguably more work. Providing a fallback for systems without a > guile supporting dynaloading would also be good. Less work if we can get others to do it or if it's already done! :-) > With this in mind, you could as well implement the normal solution > right away. It can become the fallback when the dynamic solution > is done. I'm going to hold off for Maciej-- the CUT_BUFFER0 support is nice and selection stuff can wait for a bit. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 14:30:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA17007 for scwm-discuss-outgoing; Thu, 3 Sep 1998 14:30:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA17004 for ; Thu, 3 Sep 1998 14:30:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA10222; Thu, 3 Sep 98 14:26:35 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA28507; Thu, 3 Sep 1998 11:26:29 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Maximise window... References: <8802.199809031816@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 03 Sep 1998 11:26:28 -0700 In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 19:16:22 +0100 (BST)" Message-Id: Lines: 45 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm cc'ing scwm-discuss since this stuff may be of more general interest.... Mark Toller writes: > Yup - A regular "which WM do I want to use today?", tried many (KDE, > fvwm/2/95, twm, mwm, twm, enlightenment, afterstep, windowmaker... etc), > and found things I like, and things I disklike with every one :) Then you could be very useful to developers such as ourselves who will try really hard to make users happy. > > I must say that for sheer look and nifty features, enlightenment wins, > but is not finshed/stable enough, and uses a *lot* of resources. > I still launch every app from a xterm - I've been using linux for > years, so I can't justify it. Can you expand on the "nifty features" it's got that we might lack? We're aware of the look niceties of E, but we're more interested in configurable behaviour and usability (though we are planning a flexible decoration system which would permit but not mandate E-like decorations). > KDE is nice, if a little memory hungry, but I'm against the fact that > it uses Qt. Twm/fvwm + variations are OK, but are not as configurable > as I'd like - which is where Scwm rules above all, but again, having > said that, I've been using it for weeks, and haven't reconfigured much > at all! Well, we try to have it pretty darn useful out of the box (using .scwmrc-s besides system.scwmrc, though -- we should probably improve the system.scwmrc to perhaps be one of the others, as it is not nearly as impressive as it can be (IMHO). > How much integration with Gnome are you planning? As much as useful. I'm working right now on porting IceWM's session manager client support to Scwm. Then we'll be Gnome-compliant (modulo bugs, of course). We'll support the hints that Gnome-apps provide (i.e., we'll track Gnome-compliancy), and maybe do more as the Gnome applications become more widely used and more Gnome users choose Scwm. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 15:36:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA17334 for scwm-discuss-outgoing; Thu, 3 Sep 1998 15:36:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA17330 for ; Thu, 3 Sep 1998 15:36:03 -0400 Received: from [152.78.71.3] by MIT.EDU with SMTP id AA23305; Thu, 3 Sep 98 15:32:26 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.115.98]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id UAA20346 for ; Thu, 3 Sep 1998 20:30:07 +0100 (BST) Message-Id: <13453.199809031932@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Thu, 3 Sep 1998 20:32:48 +0100 Date: Thu, 3 Sep 1998 20:32:45 +0100 (BST) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Scwm vs the rest To: scwm-discuss@mit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, [snip] > Can you expand on the "nifty features" it's got that we might lack? > We're aware of the look niceties of E, but we're more interested in > configurable behaviour and usability (though we are planning a > flexible decoration system which would permit but not mandate E-like > decorations). Well, looking at it again, it is more looks than anything else - it is nice to be able to say to people "this is Linux", when they ooh and ahh over a cool looking desktop (get one over on the Windows crowd) :) Having said that... I like the idea of sound integration (using the esound daemon), but I don't like the way it can break other sound apps. Generally though, I only use sounds within apps, such as email, and that can be handled elsewhere. It's other nifty features are essentially it's launchers, control buttons etc, but many of these are again not necessarily WM issues - for instance I will no doubt use gnome and gnome-panel for lauching my apps, and displaying a clock/loadmeter etc... but I would like the WM in use to *know* about such things - i.e. maximise the window without overlapping the gnome-panel. I very rarely use icons for launching apps, or maximising apps - I'd have to find them under my maximised netscape windows first! That's what window-lists are for. I like the way virtual desktops work under E (again, prob. more because of the graphics!) - I personally never use a desktop that is larger than my available screen space (1152x864), and the way (by default?) that scwm scrolls when the mouse hits the edge irritates me - I keep hitting it when I go to scroll Netscapes window (always fully maximised). KDE's main selling point is integration - control panels for fonts, icons, screensaver etc. And of course Kfm, but these are not necessarily WM features... and in the end, I'm a Vim and xterm user, and I like to use whatever screensaver, look and feel per window etc that I wish. > Well, we try to have it pretty darn useful out of the box (using > .scwmrc-s besides system.scwmrc, though -- we should probably improve > the system.scwmrc to perhaps be one of the others, as it is not nearly > as impressive as it can be (IMHO). > >> How much integration with Gnome are you planning? > > As much as useful. I'm working right now on porting IceWM's session > manager client support to Scwm. Then we'll be Gnome-compliant (modulo > bugs, of course). We'll support the hints that Gnome-apps provide > (i.e., we'll track Gnome-compliancy), and maybe do more as the Gnome > applications become more widely used and more Gnome users choose Scwm. Basically the problem is this - while being highly configurable is "the right thing to do", and I'm quite happy hacking around at files left, right and center, some control panel for the most common features is needed. After all, if it's good out of the box, then newbies may use it, but if it's not configurable without hacking around at the .scwmrc files, then new users will probably go with something like KDE. All very tricky, I know - the problem is that while I want total control - i.e. I'll edit the files myself, I also want Linux to be more accessible to new users, without locking them out of class products like SCWM :) A bit of a long winded rant, but there we are, Cheers, Mark. From owner-scwm-discuss@mit.edu Thu Sep 3 16:36:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA17668 for scwm-discuss-outgoing; Thu, 3 Sep 1998 16:36:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA17665 for ; Thu, 3 Sep 1998 16:36:48 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA13919; Thu, 3 Sep 98 16:33:16 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA28596; Thu, 3 Sep 1998 13:33:16 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 03 Sep 1998 13:33:15 -0700 In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 20:32:45 +0100 (BST)" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > I like the way virtual desktops work under E (again, prob. more because > of the graphics!) - I personally never use a desktop that is larger than > my available screen space (1152x864), and the way (by default?) that > scwm scrolls when the mouse hits the edge irritates me - I keep hitting > it when I go to scroll Netscapes window (always fully maximised). Obviously this is configurable, so the irritation is something you don't have to live with. > Basically the problem is this - while being highly configurable is "the > right thing to do", and I'm quite happy hacking around at files left, > right and center, some control panel for the most common features is > needed. After all, if it's good out of the box, then newbies may use > it, but if it's not configurable without hacking around at the .scwmrc > files, then new users will probably go with something like KDE. This is certainly part of the issue. Sam and others have done some good work making things customizable via menus, etc., and we do hope to approach KDE in terms of usability by non-scheme hackers. > All very tricky, I know - the problem is that while I want total > control - i.e. I'll edit the files myself, I also want Linux to be more > accessible to new users, without locking them out of class products > like SCWM :) Right. It is tricky, and we do care about new users, but we're just not there yet. We've got fundamental things still needing rewrites before it's worth investing the time to expose the power in a convenient way. Thanks for your thoughts! Greg From owner-scwm-discuss@mit.edu Thu Sep 3 17:44:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18585 for scwm-discuss-outgoing; Thu, 3 Sep 1998 17:44:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18582 for ; Thu, 3 Sep 1998 17:44:22 -0400 Received: from anusf.anu.edu.au by MIT.EDU with SMTP id AA13631; Thu, 3 Sep 98 17:40:53 EDT Received: from onyx.anu.edu.au (onyx [150.203.5.20]) by anusf.anu.edu.au (8.8.6/8.8.6) with ESMTP id HAA28776 for ; Fri, 4 Sep 1998 07:40:48 +1000 (EST) Received: (from drw900@localhost) by onyx.anu.edu.au (8.8.5/8.8.5) id HAA01194; Fri, 4 Sep 1998 07:40:49 +1000 (EST) To: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Drew Whitehouse In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 20:32:45 +0100 (BST)" X-Mailer: Gnus v5.5/XEmacs 20.3 - "Vatican City" Date: 04 Sep 1998 07:40:49 +1000 Message-Id: Lines: 29 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Mark" == Mark Toller writes: Mark> ......, and the way (by default?) that scwm scrolls when Mark> the mouse hits the edge irritates me - I keep hitting it Mark> when I go to scroll Netscapes window (always fully Mark> maximised). Try putting something like the following in you ~/.scwmrc file. (This drove me mad for while as well.) (set-edge-resistance! 500 500) BTW I also think image matters but I can't stand the E looks. Someday someone will design a window manager look that is derived from clean modern typographic layout/design principles rather than something from hackers scifi/d&d fantasies (no disrespect raster :-). Chuck out all the ugly 3D border dross, think minimal and white space, I even have a name for the theme - gomf (get 'outa my face). Maybe Maciej can co-opt some MIT architecture/design students to design a look, or maybe the folks in the Aesthetics and Computation group at the Media Lab http://acg.media.mit.edu/. Now that would be "cool" :-) -Drew -- ;; mailto:Drew.Whitehouse@anu.edu.au http://anusf.anu.edu.au/~drw900/ ;; Viz programmer, Australian National University Supercomputer Facility From owner-scwm-discuss@mit.edu Thu Sep 3 17:57:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA18788 for scwm-discuss-outgoing; Thu, 3 Sep 1998 17:57:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA18785 for ; Thu, 3 Sep 1998 17:57:12 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA16856; Thu, 3 Sep 98 17:53:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA28739; Thu, 3 Sep 1998 14:53:37 -0700 (PDT) To: Drew Whitehouse Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 03 Sep 1998 14:53:37 -0700 In-Reply-To: Drew Whitehouse's message of "04 Sep 1998 07:40:49 +1000" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Drew Whitehouse writes: > >>>>> "Mark" == Mark Toller writes: > Mark> ......, and the way (by default?) that scwm scrolls when > Mark> the mouse hits the edge irritates me - I keep hitting it > Mark> when I go to scroll Netscapes window (always fully > Mark> maximised). > > Try putting something like the following in you ~/.scwmrc > file. (This drove me mad for while as well.) > > (set-edge-resistance! 500 500) I'm changing system.scwmrc to do something close to this by default. I still think we should make one of the other .scwmrc-s the system.scwmrc, but we'd all need to get behind that configuration. > BTW I also think image matters but I can't stand the E looks. > Someday someone will design a window manager look that is derived from > clean modern typographic layout/design principles rather than > something from hackers scifi/d&d fantasies (no disrespect raster > :-). Chuck out all the ugly 3D border dross, think minimal and white > space, I even have a name for the theme - gomf (get 'outa my > face). Maybe Maciej can co-opt some MIT architecture/design students > to design a look, or maybe the folks in the Aesthetics and Computation > group at the Media Lab http://acg.media.mit.edu/. Now that would be > "cool" :-) >From our perspective, we'd like the choice of look to be decoupled from the window manager itself. Simple, modular plug-ins should let you use the E look with scwm, or whatever you or MIT design students want. We're a ways off of that goal, but it's definitely do-able. Greg From owner-scwm-discuss@mit.edu Thu Sep 3 18:33:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA19259 for scwm-discuss-outgoing; Thu, 3 Sep 1998 18:33:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA19256 for ; Thu, 3 Sep 1998 18:33:54 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14713; Thu, 3 Sep 98 18:30:22 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA28831; Thu, 3 Sep 1998 15:30:22 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> <35fd1184.292431504@smtp> From: Greg Badros Date: 03 Sep 1998 15:30:22 -0700 In-Reply-To: smithd@bellhow.com's message of "Thu, 03 Sep 1998 22:27:55 GMT" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On 03 Sep 1998 14:53:37 -0700, you wrote: > > >From our perspective, we'd like the choice of look to be decoupled from > >the window manager itself. Simple, modular plug-ins should let you use > >the E look with scwm, or whatever you or MIT design students want. > >We're a ways off of that goal, but it's definitely do-able. > > > >Greg > > I think one of the greatest strengths of scwm is it's runtime > configureablility. > > A while ago I had code in my .scwmrc that allowed me to change the look > of scwm from a menu. The code is in one of the example .*rc files I > believe. The great thing there is that it demonstrates how configurable > scwm is *at* *runtime*. Select a menu and you have fvwm, win95, or whatever. > Cool. decor.scwmrc has some of this functionality in it. I haven't run it in a week or two, so things might be slightly broken, of course. It definitely is *way* cool! Greg From owner-scwm-discuss@mit.edu Thu Sep 3 20:09:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA19771 for scwm-discuss-outgoing; Thu, 3 Sep 1998 20:09:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA19767 for ; Thu, 3 Sep 1998 20:09:25 -0400 Received: from md46-177.mun.compuserve.com by MIT.EDU with SMTP id AA11738; Thu, 3 Sep 98 20:05:45 EDT Received: (from forcer@localhost) by preforcix.roof.lan (8.9.1/8.9.1) id CAA31414 for scwm-discuss@mit.edu; Fri, 4 Sep 1998 02:05:19 +0200 Message-Id: <19980904020515.A31158@preforcix.roof.lan> Date: Fri, 4 Sep 1998 02:05:15 +0200 From: forcer To: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest Mail-Followup-To: scwm-discuss@mit.edu References: <13453.199809031932@penelope.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Greg Badros on Thu, Sep 03, 1998 at 01:33:15PM -0700 X-Operating-System: Linux preforcix 2.0.36 X-Url: http://webserver.de/forcer/ X-Mailer: Mutt 0.93.2i (1998-07-29) Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Sep 03, 1998 at 01:33:15PM -0700, Greg Badros wrote: >Mark Toller writes: >> Basically the problem is this - while being highly configurable is "the >> right thing to do", and I'm quite happy hacking around at files left, >> right and center, some control panel for the most common features is >> needed. After all, if it's good out of the box, then newbies may use >> it, but if it's not configurable without hacking around at the .scwmrc >> files, then new users will probably go with something like KDE. > >This is certainly part of the issue. Sam and others have done some good >work making things customizable via menus, etc., and we do hope to >approach KDE in terms of usability by non-scheme hackers. Rather than looking at KDE, i suggest looking at the new app for WindowMaker. I don't use WMaker, but i've seen a screenshot and heard friends talk about it. AFAIK the name is WPrefs, and it allows simple configuration changing by dialogs. If we could have such a tool that spits out a new .scwmrc or even changes an existing one, it would be nice for newbies and ppl who want to edit the config file by hand. This tool doesn't have to be perfect in that it uses all the possible things SCWM is able to do (i guess that's impossible with a simple tool), just some more basic things. Looking at WPrefs might help. Anyways, that is something someone unrelated to the core SCWM can do. And certainly not now as the SCWM interface and possibilities are still in a great flux :) -- /* Monday is an awful way to spend one seventh of your life. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Thu Sep 3 20:57:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA20179 for scwm-discuss-outgoing; Thu, 3 Sep 1998 20:57:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id UAA20176 for ; Thu, 3 Sep 1998 20:57:45 -0400 Received: from orion.kurims.kyoto-u.ac.jp (orion.kurims.kyoto-u.ac.jp [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id JAA06606 for ; Fri, 4 Sep 1998 09:54:17 +0900 (JST) Received: (from petersen@localhost) by orion.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id JAA12735; Fri, 4 Sep 1998 09:54:17 +0900 To: scwm-discuss@mit.edu Subject: Re: build trouble References: X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 04 Sep 1998 09:54:16 +0900 In-Reply-To: Greg Badros's message of "30 Aug 1998 13:44:14 -0700" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.33/XEmacs 21.0 - "Erzgeberg-pre1" Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "GB" == Greg Badros writes: GB> (I'm curious what the problem ends up being). I managed to build the current scwm yesterday (Sparc Solaris/gcc-2.8), after solving my problem with running guile scripts (in particular "build-guile"). Thanks to the people who helped me. -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Fri Sep 4 03:20:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA22101 for scwm-discuss-outgoing; Fri, 4 Sep 1998 03:20:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA22098 for ; Fri, 4 Sep 1998 03:19:53 -0400 From: mal@bewoner.dma.be Received: from dialup34.brussels.skynet.be by MIT.EDU with SMTP id AA22482; Fri, 4 Sep 98 03:16:14 EDT Received: (qmail 22056 invoked by uid 500); 4 Sep 1998 07:31:06 -0000 Date: 4 Sep 1998 07:31:06 -0000 Message-Id: <19980904073106.22055.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: new system-scwmrc X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Perhaps one thing to change is the fact that most action on windows by the mouse put it in one defined state. I find it more useful to toggle the state. I've replaced most of the default mouse operations by things like this. (define (move-or-shade) (case (mouse-event-type) ((double-click) (toggle-window-shade)) (else (move-or-raise)))) (bind-mouse 'title 1 move-or-shade) (define (toggle-upper-lower) (if (raised?) (lower-window) (raise-window))) (bind-mouse 'title 3 toggle-upper-lower) Generally, if you poke at a window you want to change the state of it. Definining operations that are no-ops in certain states seems less than useful. Lieven Marchand ------------------------------------------------------------------------ From owner-scwm-discuss@mit.edu Fri Sep 4 10:12:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA24202 for scwm-discuss-outgoing; Fri, 4 Sep 1998 10:12:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA24199 for ; Fri, 4 Sep 1998 10:12:54 -0400 Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id XAA10195 for ; Fri, 4 Sep 1998 23:09:18 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id XAA01382; Fri, 4 Sep 1998 23:09:18 +0900 To: scwm-discuss@mit.edu Subject: positioning problem of dialog windows X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 04 Sep 1998 23:09:17 +0900 Message-ID: Lines: 13 X-Mailer: Gnus v5.6.33/XEmacs 21.0 - "Erzgeberg-pre1" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maybe you've already fixed this, Greg? but I noticed that the positioning of dialog windows and balloon help popups is strange for me with yesterday's scwm. For example when on a virtual screen away from the root screen, Netscape pops up its dialogs and balloon help on the right edge of the screen. Also XBuffy's popups appear almost off screen on the left: ie mostly on the root screen area. Jens -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Fri Sep 4 11:27:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24538 for scwm-discuss-outgoing; Fri, 4 Sep 1998 11:27:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA24535 for ; Fri, 4 Sep 1998 11:27:41 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA13268; Fri, 4 Sep 98 11:24:04 EDT Received: by tis.bellhow.com; id LAA08041; Fri, 4 Sep 1998 11:24:03 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma007940; Fri, 4 Sep 98 11:23:07 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA28361 for ; Fri, 4 Sep 1998 11:23:06 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Build problems with 9/4 snapshot Date: Fri, 04 Sep 1998 15:23:06 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f200f7.353730046@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA24536 Sender: owner-scwm-discuss@mit.edu Precedence: bulk A couple of problems with the 1998 09 04 snapshot. The file `session-manager.c' either shouldn't be built if you don't have the IceWM (like the cassowary stuff is), or wrapped with `#ifdef HAVE_LIBSM_LIBICE'. I used the ifdef. libtool was complaining about not knowing the `-o' option when linking scwm!! Turns out CXX wasn't defined in the Makefile. I set it to `g++' and the compile finished. I think this is because I'm not using cassowary? (not compiling c++) The first move of a sticky window went to way east, but by moving to it from the window list, it stayed stuck again. Other sticky moved have been ok, just that first one. If I have the time I'm going to see what's going on with the pager. Thanks, Dale From owner-scwm-discuss@mit.edu Fri Sep 4 11:40:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24631 for scwm-discuss-outgoing; Fri, 4 Sep 1998 11:40:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA24628 for ; Fri, 4 Sep 1998 11:40:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17409; Fri, 4 Sep 98 11:36:27 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA14888; Fri, 4 Sep 1998 08:36:12 -0700 (PDT) To: mal@bewoner.dma.be Cc: scwm-discuss@mit.edu Subject: Re: new system-scwmrc References: <19980904073106.22055.qmail@localhost.localdomain> From: Greg Badros Date: 04 Sep 1998 08:36:12 -0700 In-Reply-To: mal@bewoner.dma.be's message of "4 Sep 1998 07:31:06 -0000" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > Perhaps one thing to change is the fact that most action on windows by > the mouse put it in one defined state. I find it more useful to toggle > the state. > > I've replaced most of the default mouse operations by things like > this. > > (define (move-or-shade) > (case (mouse-event-type) > ((double-click) (toggle-window-shade)) > (else (move-or-raise)))) > (bind-mouse 'title 1 move-or-shade) > (define (toggle-upper-lower) > (if (raised?) (lower-window) (raise-window))) > (bind-mouse 'title 3 toggle-upper-lower) > > Generally, if you poke at a window you want to change the state of > it. Definining operations that are no-ops in certain states seems less > than useful. Often, yes. We do have lots of toggling operations, but also some that always do the same thing. UI design ain't easy, and it's even harder if you don't design but you evolve a solution (as the system.scwmrc has). When the core rewrites are done, we'll take a step back and try designing it nicely from first principles. I generally look at the various scwmrc-s as test cases which happen to be way cooler configurations than other wms. Greg From owner-scwm-discuss@mit.edu Fri Sep 4 13:11:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25347 for scwm-discuss-outgoing; Fri, 4 Sep 1998 13:11:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA25343 for ; Fri, 4 Sep 1998 13:11:50 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14806; Fri, 4 Sep 98 13:08:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA16314; Fri, 4 Sep 1998 10:08:00 -0700 (PDT) To: Jens-Ulrik Petersen Cc: scwm-discuss@mit.edu Subject: Re: positioning problem of dialog windows References: From: Greg Badros Date: 04 Sep 1998 10:07:59 -0700 In-Reply-To: Jens-Ulrik Petersen's message of "04 Sep 1998 23:09:17 +0900" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jens-Ulrik Petersen writes: > Maybe you've already fixed this, Greg? but I noticed that the > positioning of dialog windows and balloon help popups is strange for > me with yesterday's scwm. > > For example when on a virtual screen away from the root screen, > Netscape pops up its dialogs and balloon help on the right edge of the > screen. Also XBuffy's popups appear almost off screen on the left: ie > mostly on the root screen area. Whoa... freaky. Yea, my netscape *menus* were pretty out of control-- that's fixed now in the repository, and hopefully the bug I fixed was the same that was causing difficulties for you. I don't have XBuffy (what is it?). I also fixed lots of behaviour of sticky-windows when not in the 0,0 viewport. Thanks! Greg From owner-scwm-discuss@mit.edu Fri Sep 4 13:41:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25555 for scwm-discuss-outgoing; Fri, 4 Sep 1998 13:41:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA25552 for ; Fri, 4 Sep 1998 13:41:47 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA01941; Fri, 4 Sep 98 13:38:10 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA17680; Fri, 4 Sep 1998 10:37:58 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> From: Greg Badros Date: 04 Sep 1998 10:37:57 -0700 In-Reply-To: smithd@bellhow.com's message of "Fri, 04 Sep 1998 15:23:06 GMT" Message-Id: Lines: 53 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > A couple of problems with the 1998 09 04 snapshot. > > The file `session-manager.c' either shouldn't be built if you > don't have the IceWM (like the cassowary stuff is), or wrapped > with `#ifdef HAVE_LIBSM_LIBICE'. I used the ifdef. First a quick minor clarification -- you do not need IceWM to use the (completley untested) session management of scwm. It's meant to work with the GNOME session manager, but I don't have the time or interest to build GNOME just to test the session manager piece (don't get me wrong, I'm very interested in using GNOME after it's matured -- I just am already at my limit of unstable software use). There is some name overloading that confuses the issue -- IceWM and libICE are pretty unrelated. ICE == InterClient Exchange, the primitive communication mechanism on which the session management library libSM is built. As to your report of the build problem, yes, you're correct. Only so much I can get done in a day, so I ignored the issue yesterday. I think I'll have the configure improved by the end of today. Thanks for reminding me, of course -- your quick testing is appreciated immensely! > libtool was complaining about not knowing the `-o' option when > linking scwm!! Turns out CXX wasn't defined in the Makefile. > I set it to `g++' and the compile finished. I think this is > because I'm not using cassowary? (not compiling c++) QUESTION: Anybody know how automake decides whether to use $(LINK) or $(CXXLINK) to build a program? Seems as though scwm should link with $(LINK) unless cassowary is used, but it sounds like CXXLINK is being used more often than it should. > The first move of a sticky window went to way east, but by moving to > it from the window list, it stayed stuck again. Other sticky moved > have been ok, just that first one. This is fixed now, I think. > If I have the time I'm going to see what's going on with the pager. The bug that I've noticed is that changing the viewport makes all the windows flicker to a different position briefly before they get updated in the Pager. I've not had time to track it down yet, though. Thanks, Dale! Greg From owner-scwm-discuss@mit.edu Fri Sep 4 14:05:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA25886 for scwm-discuss-outgoing; Fri, 4 Sep 1998 14:05:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA25880 for ; Fri, 4 Sep 1998 14:05:37 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA00958; Fri, 4 Sep 98 14:01:57 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA14164; Fri, 4 Sep 98 14:01:56 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Thu, 03 Sep 1998 20:21:07 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Thu, 03 Sep 1998 20:21:07 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id UAA22921; Thu, 3 Sep 1998 20:21:41 -0400 To: forcer Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> <19980904020515.A31158@preforcix.roof.lan> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: forcer's message of "Fri, 4 Sep 1998 02:05:15 +0200" Date: 03 Sep 1998 20:21:41 -0400 Message-Id: Lines: 31 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19980904020515.A31158@preforcix.roof.lan> >>>> Sent on Fri, 4 Sep 1998 02:05:15 +0200 >>>> Honorable forcer writes >>>> on the subject of "Re: Scwm vs the rest": >> Rather than looking at KDE, i suggest looking at the new app for >> WindowMaker. I don't use WMaker, but i've seen a screenshot and >> heard friends talk about it. AFAIK the name is WPrefs, and it >> allows simple configuration changing by dialogs. If we could have >> such a tool that spits out a new .scwmrc or even changes an existing >> one, it would be nice for newbies and ppl who want to edit the >> config file by hand. This tool doesn't have to be perfect in that >> it uses all the possible things SCWM is able to do (i guess that's >> impossible with a simple tool), just some more basic things. Looking >> at WPrefs might help. Please take a look at prefs-menu.scm - it has the beginnings. (use-modules (app scwm prefs-menu)) in a menu of your choice: (menuitem "&Preferences" #:action (menu-prefs)) The problem is that we don't have `ask-string' working. If you can write it, I'll do the rest. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Just because you're paranoid doesn't mean they AREN'T after you. From owner-scwm-discuss@mit.edu Fri Sep 4 14:05:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA25890 for scwm-discuss-outgoing; Fri, 4 Sep 1998 14:05:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA25883 for ; Fri, 4 Sep 1998 14:05:46 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Thu, 03 Sep 1998 18:07:10 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Thu, 03 Sep 1998 18:07:10 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id SAA22361; Thu, 3 Sep 1998 18:07:44 -0400 To: Maciej Stachowiak Subject: build error Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 03 Sep 1998 18:07:44 -0400 Message-ID: Lines: 20 Sender: owner-scwm-discuss@mit.edu Precedence: bulk since recently, I have been getting the following: $ make maintainer-clean; $ ./autogen.sh $ ./configure --enable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/ $ make ...... /bin/sh ../libtool --mode=link -o scwm Grab.o ICCCM.o add_window.o binding.o borders.o callbacks.o changed.o color.o colormaps.o colors.o complex.o decor.o decorations.o deskpage.o drawmenu.o errors.o events.o face.o focus.o font.o getopt.o getopt1.o guile-compat.o icons.o image.o init_scheme_string.o log-usage.o menu.o menuitem.o miscprocs.o module-interface.o move.o placement.o resize.o screen.o scwm.o session-manager.o shutdown.o string_token.o syscompat.o system.o util.o virtual.o window.o xmisc.o xproperty.o xrm.o -L/usr/X11R6/lib -lXext -lXmu -lXpm -lX11 -L/usr/local/lib -lguile -ldl -lreadline -ltermcap -lm -lm libtool: unrecognized option `-o' Try `libtool --help' for more information. make[1]: *** [scwm] Error 1 make[1]: Leaving directory `/usr/src/scwm/scwm' make: *** [all-recursive] Error 1 -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Who is General Failure and why is he reading my hard disk? From owner-scwm-discuss@mit.edu Fri Sep 4 14:20:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26075 for scwm-discuss-outgoing; Fri, 4 Sep 1998 14:20:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA26072 for ; Fri, 4 Sep 1998 14:20:18 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05495; Fri, 4 Sep 98 14:16:41 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA17742; Fri, 4 Sep 1998 11:16:38 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> <19980904020515.A31158@preforcix.roof.lan> From: Greg Badros Date: 04 Sep 1998 11:16:38 -0700 In-Reply-To: Sam Steingold's message of "03 Sep 1998 20:21:41 -0400" Message-Id: Lines: 40 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <19980904020515.A31158@preforcix.roof.lan> > >>>> Sent on Fri, 4 Sep 1998 02:05:15 +0200 > >>>> Honorable forcer writes > >>>> on the subject of "Re: Scwm vs the rest": > >> Rather than looking at KDE, i suggest looking at the new app for > >> WindowMaker. I don't use WMaker, but i've seen a screenshot and > >> heard friends talk about it. AFAIK the name is WPrefs, and it > >> allows simple configuration changing by dialogs. If we could have > >> such a tool that spits out a new .scwmrc or even changes an existing > >> one, it would be nice for newbies and ppl who want to edit the > >> config file by hand. This tool doesn't have to be perfect in that > >> it uses all the possible things SCWM is able to do (i guess that's > >> impossible with a simple tool), just some more basic things. Looking > >> at WPrefs might help. > > Please take a look at prefs-menu.scm - it has the beginnings. > > (use-modules (app scwm prefs-menu)) > > in a menu of your choice: > > (menuitem "&Preferences" #:action (menu-prefs)) > > The problem is that we don't have `ask-string' working. > If you can write it, I'll do the rest. As we discussed before, there are numerous little apps that prompt for a string and return that string. I have xprompt and widinput, and I'm sure there are others. e.g., xprompt -re -p "Enter window name:" prompts for a window name and prints the input string to stdout. I think Maciej may be able to get guile-gtk up to the task shortly after his return, too. That way we wouldn't rely on an extra not-included program. Greg From owner-scwm-discuss@mit.edu Fri Sep 4 14:42:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26250 for scwm-discuss-outgoing; Fri, 4 Sep 1998 14:42:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA26245 for ; Fri, 4 Sep 1998 14:42:47 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19017; Fri, 4 Sep 98 14:39:09 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA17948; Fri, 4 Sep 1998 11:39:05 -0700 (PDT) To: Maciej Stachowiak Subject: Re: build error References: From: Greg Badros Date: 04 Sep 1998 11:39:04 -0700 In-Reply-To: Sam Steingold's message of "03 Sep 1998 18:07:44 -0400" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > since recently, I have been getting the following: > > $ make maintainer-clean; > $ ./autogen.sh > $ ./configure --enable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/ > $ make > ...... > /bin/sh ../libtool --mode=link -o scwm Grab.o ICCCM.o add_window.o binding.o borders.o callbacks.o changed.o color.o colormaps.o colors.o complex.o decor.o decorations.o deskpage.o drawmenu.o errors.o events.o face.o focus.o font.o getopt.o getopt1.o guile-compat.o icons.o image.o init_scheme_string.o log-usage.o menu.o menuitem.o miscprocs.o module-interface.o move.o placement.o resize.o screen.o scwm.o session-manager.o shutdown.o string_token.o syscompat.o system.o util.o virtual.o window.o xmisc.o xproperty.o xrm.o -L/usr/X11R6/lib -lXext -lXmu -lXpm -lX11 -L/usr/local/lib -lguile -ldl -lreadline -ltermcap -lm -lm > libtool: unrecognized option `-o' > Try `libtool --help' for more information. > make[1]: *** [scwm] Error 1 > make[1]: Leaving directory `/usr/src/scwm/scwm' > make: *** [all-recursive] Error 1 It's because CXX isn't defined and automake is writing a makefile that is using CXXLINK instead of LINK. One fix is to edit the Makefile to use $(LINK) for the scwm target. Another is to set the env var CXX=g++ (or whatever) before running configure. I'm trying to find the right solution, but am inexperienced with automake. Greg From owner-scwm-discuss@mit.edu Fri Sep 4 14:56:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26453 for scwm-discuss-outgoing; Fri, 4 Sep 1998 14:56:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA26450 for ; Fri, 4 Sep 1998 14:56:36 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA16594; Fri, 4 Sep 98 14:52:59 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA22108; Fri, 4 Sep 98 14:52:58 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Fri, 04 Sep 1998 14:52:22 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Fri, 04 Sep 1998 14:52:21 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA24941; Fri, 4 Sep 1998 14:52:48 -0400 To: Greg Badros Cc: forcer , scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> <19980904020515.A31158@preforcix.roof.lan> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "04 Sep 1998 11:16:38 -0700" Date: 04 Sep 1998 14:52:47 -0400 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 04 Sep 1998 11:16:38 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Scwm vs the rest": >> Sam Steingold writes: >> > >> > The problem is that we don't have `ask-string' working. >> > If you can write it, I'll do the rest. >> >> As we discussed before, there are numerous little apps that prompt for a >> string and return that string. I have xprompt and widinput, and I'm >> sure there are others I have neither. what rpm are they in? >> I think Maciej may be able to get guile-gtk up to the task shortly >> after his return, too. That way we wouldn't rely on an extra >> not-included program. cool. BTW, we also need a variable `user-options' - the list of user option variables. Elements are either symbols (the variables) or consed (set-value! . get-value). Keep in mind that documentation for the variable or set-value! will be displayed when requesting input. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Daddy, why doesn't this magnet pick up this floppy disk? From owner-scwm-discuss@mit.edu Fri Sep 4 15:11:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA26694 for scwm-discuss-outgoing; Fri, 4 Sep 1998 15:11:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA26687 for ; Fri, 4 Sep 1998 15:11:28 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA27212; Fri, 4 Sep 98 15:07:50 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA18014; Fri, 4 Sep 1998 12:07:43 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> <19980904020515.A31158@preforcix.roof.lan> From: Greg Badros Date: 04 Sep 1998 12:07:43 -0700 In-Reply-To: Sam Steingold's message of "04 Sep 1998 14:52:47 -0400" Message-Id: Lines: 43 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 04 Sep 1998 11:16:38 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Scwm vs the rest": > >> Sam Steingold writes: > >> > > >> > The problem is that we don't have `ask-string' working. > >> > If you can write it, I'll do the rest. > >> > >> As we discussed before, there are numerous little apps that prompt for a > >> string and return that string. I have xprompt and widinput, and I'm > >> sure there are others > > I have neither. what rpm are they in? None that I know of. I just put xprompt.tar.gz on ftp://huis-clos.mit.edu/home/ftp/pub/scwm/ (it built really easily on my linux box: xmkmf -a; make clean; make) > >> I think Maciej may be able to get guile-gtk up to the task shortly > >> after his return, too. That way we wouldn't rely on an extra > >> not-included program. > > cool. It could be a bit, of course, so it's probably worth using an xprompt-based `ask-string' for now -- we'll rewrite ask-string later to not rely on xprompt. > > BTW, we also need a variable `user-options' - the list of user option > variables. Elements are either symbols (the variables) or consed > (set-value! . get-value). Keep in mind that documentation for the > variable or set-value! will be displayed when requesting input. Right... I'll try to come up with some nice way to generate this. In the meantime, just use a subset of the user variables in a hard-coded list for testing and development if you feel like moving forward on this. Greg From owner-scwm-discuss@mit.edu Fri Sep 4 20:15:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28128 for scwm-discuss-outgoing; Fri, 4 Sep 1998 20:15:35 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28125 for ; Fri, 4 Sep 1998 20:15:31 -0400 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA26829; Fri, 4 Sep 98 20:11:51 EDT Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.8.8/8.6.4) with SMTP id UAA14435 for ; Fri, 4 Sep 1998 20:12:16 -0400 (EDT) Message-Id: <199809050012.UAA14435@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: scwm-discuss@mit.edu X-Attribution: Eric Subject: questions, ideas, stuff Date: Fri, 04 Sep 1998 20:12:15 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk First, the pressing issue that got me to post. I upgraded my guile snapshot, and scwm-0.7 broke, so I upgraded to 0.8 and my icin placement broke, is there something wrong with the 0.8 iconbox style options that's fixed in a snapshot or did the syntax change? Another question relates to virtual deskstops. Are there any plans to move more of the code handling these to the scheme layer? Or even any objections to it being done? Specifically, what I'd like to be able to do is to allow the same windows to be in different places on different desks, which last time I looked at the desk-changing code didn't seem to be all that easy. (For why this might be useful, imagine a whole lot of desktop widgets, and a tall and narow app, and a short and wide app. In one case you want the widgets arrayed vertically, in the other, horizontally.) With the desk label being stored in a C int, and (if I recall correctly) no per-window scheme hooks being called to switch windows, implementing this doesn't seem easy enough with the current API. I also think that viewport moving should be a little higher level.... but then I'm a converted GWM user. -Eric From owner-scwm-discuss@mit.edu Fri Sep 4 20:42:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28301 for scwm-discuss-outgoing; Fri, 4 Sep 1998 20:42:48 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28298 for ; Fri, 4 Sep 1998 20:42:45 -0400 Received: from benetnash.ffke-campus.mipt.ru by MIT.EDU with SMTP id AA29789; Fri, 4 Sep 98 20:39:04 EDT Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id EAA04857; Sat, 5 Sep 1998 04:40:03 GMT Date: Sat, 5 Sep 1998 04:40:03 GMT Message-Id: <199809050440.EAA04857@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: scwm-discuss@mit.edu In-Reply-To: <199809050012.UAA14435@chopin.chem.cmu.edu> (message from Eric Moore on Fri, 04 Sep 1998 20:12:15 -0400) Subject: icon boxes bug Reply-To: tihonov@ffke-campus-gw.mipt.ru References: <199809050012.UAA14435@chopin.chem.cmu.edu> Sender: owner-scwm-discuss@mit.edu Precedence: bulk X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol Date: Fri, 04 Sep 1998 20:12:15 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk First, the pressing issue that got me to post. I upgraded my guile snapshot, and scwm-0.7 broke, so I upgraded to 0.8 and my icin placement broke, is there something wrong with the 0.8 iconbox style options that's fixed in a snapshot or did the syntax change? Hello. set-icon-box! still works, but only with stiky icons --Oleg From owner-scwm-discuss@mit.edu Fri Sep 4 20:48:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28356 for scwm-discuss-outgoing; Fri, 4 Sep 1998 20:48:40 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA28353 for ; Fri, 4 Sep 1998 20:48:39 -0400 Received: from benetnash.ffke-campus.mipt.ru by MIT.EDU with SMTP id AA00564; Fri, 4 Sep 98 20:45:00 EDT Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id EAA04868; Sat, 5 Sep 1998 04:46:03 GMT Date: Sat, 5 Sep 1998 04:46:03 GMT Message-Id: <199809050446.EAA04868@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: scwm-discuss@mit.edu Subject: test Reply-To: tihonov@ffke-campus-gw.mipt.ru Sender: owner-scwm-discuss@mit.edu Precedence: bulk test From owner-scwm-discuss@mit.edu Fri Sep 4 20:49:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA28379 for scwm-discuss-outgoing; Fri, 4 Sep 1998 20:49:25 -0400 Received: from benetnash.ffke-campus.mipt.ru (benetnash.ffke-campus.mipt.ru [194.85.82.41]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id UAA28375 for ; Fri, 4 Sep 1998 20:49:24 -0400 Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id EAA04871; Sat, 5 Sep 1998 04:46:48 GMT Date: Sat, 5 Sep 1998 04:46:48 GMT Message-Id: <199809050446.EAA04871@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: scwm-discuss@mit.edu Subject: test Reply-to: tihonov@ffke-campus-gw.mipt.ru Sender: owner-scwm-discuss@mit.edu Precedence: bulk test From owner-scwm-discuss@mit.edu Fri Sep 4 21:43:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA28754 for scwm-discuss-outgoing; Fri, 4 Sep 1998 21:43:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA28751 for ; Fri, 4 Sep 1998 21:43:15 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11166; Fri, 4 Sep 98 21:39:33 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA23159; Fri, 4 Sep 1998 18:39:29 -0700 (PDT) To: Eric Moore Cc: scwm-discuss@mit.edu Subject: Re: questions, ideas, stuff References: <199809050012.UAA14435@chopin.chem.cmu.edu> From: Greg Badros Date: 04 Sep 1998 18:39:29 -0700 In-Reply-To: Eric Moore's message of "Fri, 04 Sep 1998 20:12:15 -0400" Message-Id: Lines: 49 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Eric Moore writes: > First, the pressing issue that got me to post. I upgraded my guile > snapshot, and scwm-0.7 broke, so I upgraded to 0.8 and my icin > placement broke, is there something wrong with the 0.8 iconbox style > options that's fixed in a snapshot or did the syntax change? No it probably just is broken in some way, unfortunately. I'll try to test this a bit more as time permits, or you could try using the version out of the CVS repository and test it more thoroughly. > Another question relates to virtual deskstops. Are there any plans to > move more of the code handling these to the scheme layer? Or even any > objections to it being done? Specifically, what I'd like to be able > to do is to allow the same windows to be in different places on > different desks, which last time I looked at the desk-changing code > didn't seem to be all that easy. (For why this might be useful, > imagine a whole lot of desktop widgets, and a tall and narow app, and > a short and wide app. In one case you want the widgets arrayed > vertically, in the other, horizontally.) The virtual desktop metaphor does not restrict the position of the viewport to multiple of the physical display width. Certainly a layer on top of the virtual desktop could enforce that restriction, at which point doing what you want is possible from the scheme level, it seems. I'd have to think about it more to get a grip on how convenient it would be. If there is a specific proposal, please make it, and we'll discuss what can be done to better support what you'd like. > With the desk label being stored in a C int, and (if I recall > correctly) no per-window scheme hooks being called to switch windows, > implementing this doesn't seem easy enough with the current API. I'm a bit confused by your terminology. "switch windows" means what? WRT scheme hooks, it's easy enough to add a layer of indirection on move-viewport calls -- you define `switch-to-my-viewport' or whatever, and it calls whatever hooks it wants on the windows. > I also think that viewport moving should be a little higher level.... > but then I'm a converted GWM user. I'll gladly entertain specific proposals. In general, I think some wrapping of the viewport stuff at a higher level which enforces the commonly used only-even-multiples-of-physical-screen-size positions makes sense, and I'd love to see some contributions along those lines. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 4 22:47:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA29468 for scwm-discuss-outgoing; Fri, 4 Sep 1998 22:47:57 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA29465 for ; Fri, 4 Sep 1998 22:47:54 -0400 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA13545; Fri, 4 Sep 98 22:44:14 EDT Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.8.8/8.6.4) with SMTP id WAA19834 for ; Fri, 4 Sep 1998 22:44:38 -0400 (EDT) Message-Id: <199809050244.WAA19834@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: scwm-discuss@mit.edu Subject: Re: questions, ideas, stuff In-Reply-To: Your message of "04 Sep 1998 18:39:29 PDT." Date: Fri, 04 Sep 1998 22:44:38 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> No it probably just is broken in some way, unfortunately. I'll Greg> try to test this a bit more as time permits, or you could try Greg> using the version out of the CVS repository and test it more Greg> thoroughly. ok, I'll give that a shot. Greg> I'm a bit confused by your terminology. "switch windows" means Greg> what? Well, that'd be because it's bad terminology. I should have said switch desks. eg: (set-current-desk! 2) What I'd like is something like on desk 1, my emacs can be on the right, on desk 2, on the left, and not be on desk 3. I don't exactly have a specific proposal but it could probably just be done if you can have changeDesk call a hook for each window in the winlist. Say, pass in the window and the new desk number, and in a create window hook do something like: (lambda (win) (set-desk-change-hook! win (let ((desk-x (make-vector max-desks (car (window-position win)))) (desk-y (make-vector max-desks (cadr (window-position win))))) (lambda (window desk-to) (vector-set! desk-x (current-desk) (car (window-position window))) (vector-set! desk-y (current-desk) (cadr (window-position window))) (move-window-to-desk desk-to window) (move-to (vector-ref desk-x desk-to) (vector-ref desk-y desk-to) window))))) Requiring a closure like that is kinda suspect, as is the use of a vector (especially since the max number of desks is large :), and I made up the max-desks variable, etc... but it'd do roughly what I want, which is, a new window would appear on all desks, but could be moved independantly on each one. Essentially, changing from "every desk is a unique collection of windows" to "every desk is a unique arrangement of windows". Now, honestly, I'd like to be able to mix the two idioms, and have some windows on some desks but not others, but that requires more scheme than I'm gonna write tonight. The way I'd do it is instead of making it a hook that gets called in addition to the C window movement code, have the C code that gets called to move the viewport or change desks call an SCM function in each window data structure. Then you could make 2 subrs at the C level one for sticky windows (that does nothing :), and one for non-sticky windows that does the appropriate unmapping, mapping, and moving, and I can do whatever sick and disgusting things I like :) Greg> WRT scheme hooks, it's easy enough to add a layer of indirection Greg> on move-viewport calls -- you define `switch-to-my-viewport' or Greg> whatever, and it calls whatever hooks it wants on the windows. Hmm.... That'd work too, but I'd rather see a more scheme-like interface at a lower level, rather than having to duplicate work :) -Eric From owner-scwm-discuss@mit.edu Sat Sep 5 08:05:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA32209 for scwm-discuss-outgoing; Sat, 5 Sep 1998 08:05:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA32196 for ; Sat, 5 Sep 1998 08:05:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA08170 for scwm-discuss@huis-clos.mit.edu; Sat, 5 Sep 1998 14:01:30 +0200 (CEST) Received: (qmail 11971 invoked by uid 115); 5 Sep 1998 08:48:46 -0000 To: scwm-discuss@mit.edu Subject: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Sep 1998 10:48:45 +0200 In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 20:32:45 +0100 (BST)" Message-ID: Lines: 40 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, [splitting my answers to this mail] >>>>> On Thu, 3 Sep 1998 20:32:45 +0100 (BST) >>>>> Mark Toller said: Mark> I like the idea of sound integration (using the esound daemon), Mark> but I don't like the way it can break other sound apps. esound is pretty useless without wider support - just like the other approaches made before (Xaudio, nas, rplay). Not having decided on a common standard for sound transport is a major drawback of X. (Then again, Windoze is pretty lame at that, too; and they do not have to worry about networking stuff.) I'd like to see sound support in scwm. It should interact with both nas (because it's the thing that most resembles a standard), and esound (because it shows signs of development). Simple support is quite possible at the scheme level right now. Just `execute' "esdcat" or something. Hmm, what would be best: (a) provide hooks for every action under the sun: maximize-hook, iconify-hook, focus-change-hook, etc. Sound code would hang onto this. (b) hard-code call-backs into primitives of interest, like "(sound-event 'maximize)" (c) have the sound code advertise the primitives. The advertised versions would call `play-sound' with appropriate parameters. Variant (c) definitely looks best to me. Is somebody interested in doing this? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Sep 5 08:05:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA32210 for scwm-discuss-outgoing; Sat, 5 Sep 1998 08:05:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA32197 for ; Sat, 5 Sep 1998 08:05:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA08175 for scwm-discuss@huis-clos.mit.edu; Sat, 5 Sep 1998 14:01:32 +0200 (CEST) Received: (qmail 12007 invoked by uid 115); 5 Sep 1998 09:08:17 -0000 To: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Sep 1998 11:08:16 +0200 In-Reply-To: Mark Toller's message of "Thu, 3 Sep 1998 20:32:45 +0100 (BST)" Message-ID: Lines: 64 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, [splitting my answers to this mail] >>>>> On Thu, 3 Sep 1998 20:32:45 +0100 (BST) >>>>> Mark Toller said: Mark> It's other nifty features are essentially it's launchers, Mark> control buttons etc, but many of these are again not Mark> necessarily WM issues - for instance I will no doubt use gnome Mark> and gnome-panel for lauching my apps, and displaying a Mark> clock/loadmeter etc... That's the way to go, yes. Mark> but I would like the WM in use to *know* about such things - Mark> i.e. maximise the window without overlapping the gnome-panel. GNOME provides hints for this, I'm just working on support for these. Mark> I personally never use a desktop that is larger than my Mark> available screen space (1152x864), and the way (by default?) Mark> that scwm scrolls when the mouse hits the edge irritates me - I Mark> keep hitting it when I go to scroll Netscapes window (always Mark> fully maximised). Me too. Just put the following (from my scwmrc) into your scwmrc: (set-desk-size! 1 1) ; desktops are good, paging is evil No scrolling, just a couple of desktops. Mark> [...] but if it's not configurable without hacking around at Mark> the .scwmrc files, then new users will probably go with Mark> something like KDE. Yes, Sam is working in this area, but it's quite a long way. When the gtk support gets off the ground, we can also have dialog boxes easily. A main advantage of scwm is, that we can do this sort of stuff *inside* the window manager. AFAIK no other wm has the power to do that. Mark> All very tricky, I know - the problem is that while I want Mark> total control - i.e. I'll edit the files myself, I also want Mark> Linux to be more accessible to new users, without locking them Mark> out of class products like SCWM :) This is hard enough even for files of rather strict format (cf. the admin-tools that are shipped with the various distributions). It becomes damn near impossible with the free-form configuration programs scwm uses. I think the best we can do is a tool like Emacs's "custom": one that emits it's own config-settings, understands and changes just these, and leaves other code alone. All things should be controllable from this tool, of course. Users would have no need to hand-edit the scwmrc, but could if they wanted. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Sep 5 08:05:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA32211 for scwm-discuss-outgoing; Sat, 5 Sep 1998 08:05:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA32198 for ; Sat, 5 Sep 1998 08:05:20 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA08188 for scwm-discuss@huis-clos.mit.edu; Sat, 5 Sep 1998 14:01:34 +0200 (CEST) Received: (qmail 12031 invoked by uid 115); 5 Sep 1998 09:23:21 -0000 To: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Sep 1998 11:23:20 +0200 In-Reply-To: Greg Badros's message of "04 Sep 1998 10:37:57 -0700" Message-ID: Lines: 36 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 04 Sep 1998 10:37:57 -0700 >>>>> Greg Badros said: Greg> It's meant to work with the GNOME session manager, but I don't Greg> have the time or interest to build GNOME just to test the Greg> session manager piece (don't get me wrong, I'm very interested Greg> in using GNOME after it's matured -- I just am already at my Greg> limit of unstable software use). I have a pretty recent gnome-core here, so I can test this, whenever I can transport a new scwm-snapshot home (when my sneaker-net is up again). Greg> Anybody know how automake decides whether to use $(LINK) or Greg> $(CXXLINK) to build a program? I think that CXXLINK is used, when there are .cc files in the EXTRA_SOURCES. We need to have them there, because otherwise automake won't generate c++ rules at all. Since automake can't know whether the .cc files are really linked in (this is decided later, when configure runs) it plays safe and uses CXXLINK. This should not matter. With my autoconf (2.12) AC_PROG_CXX expands to the following among other code: test -n "$CXX" || CXX="gcc" So $CXX should never be empty. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Sep 5 08:05:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA32212 for scwm-discuss-outgoing; Sat, 5 Sep 1998 08:05:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA32200 for ; Sat, 5 Sep 1998 08:05:23 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA08192 for scwm-discuss@huis-clos.mit.edu; Sat, 5 Sep 1998 14:01:35 +0200 (CEST) Received: (qmail 12084 invoked by uid 115); 5 Sep 1998 10:02:42 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 05 Sep 1998 12:02:41 +0200 In-Reply-To: Greg Badros's message of "03 Sep 1998 10:39:08 -0700" Message-ID: Lines: 62 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 03 Sep 1998 10:39:08 -0700 >>>>> Greg Badros said: Greg> MODIFIER-SPECIFIER is an cons pair of bitmasks for the modifier Greg> bits of the event: (MUST-BE-ON . MUST-BE-OFF). E.g., if bit 2 Greg> corresponds to the meta modifier, (4 . 0) would match events Greg> with at least the Meta modifier depressed, while (0 . 4) would Greg> match only events without the Meta modifier depressed. Greg> `with-modifier' and other convenience functions will be Greg> provided to simplify the writing of the MODIFIER-SPECIFIER. Greg> They will permit using logical modifiers using symbols (e.g., Greg> 'control 'meta 'hyper 'super, etc.) and physical modifiers by Greg> numbers (e.g., 1 refers to whatever mod1 is). Call the Greg> modifiers of the key event: MOD. The event matches the Greg> MODIFIER-SPECIFIER iff: Greg> ((MOD | OnMask == MOD) && (MOD & ~OffMask == MOD)). First, I think this makes it too easy to give bits instead of proper (symbolic) modifiers. I can't think of a situation where using the modifier bit directly is not evil. Second, if we save modifier bits internally, we will lose when the user changes the modifier mapping while scwm is running. I think MODIFIER-SPECIFIER should be a list of modifier symbols, (e.g. '(super shift)) which is translated to raw bits every time an event is processed. Can guile symbols have a tilde in them. Then we could express must-off-modifiers like this: ~control [Dispatching] Greg> ;; Each procedure is invoked with four arguments: Greg> ;; #1 - the scheme object that the event acted on/in (e.g., for a button Greg> ;; decoration, it will be that top-level frame; for a menu it will be Greg> ;; the menu object, etc.), or #f if there is no applicable scheme object Greg> ;; (e.g., the root window) Greg> ;; #2 - the event object that caused this dispatch (i.e. EVENT) How do I get to details specific to event-type (e.g. which property changed in a PropertyNotify)? Greg> ;; #3 - the event map object (i.e. EVENT-MAP) Greg> ;; #4 - the window id of the X window that got the event. We can add Greg> ;; primitives to query what decoration/menu/whatever a window ID is [Event maps] Greg> [...] -- the attaching of the default event maps needs to be Greg> efficient, since it'll happen for each new window and on lots Greg> of decorations -- it's only a single XSaveContext call for each Greg> attachment, which shouldn't be too bad]. Perhaps don't store anything at all in the default case. Not having a valid XContext would mean the defaults, then. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Sep 5 15:13:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01696 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:13:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01693 for ; Sat, 5 Sep 1998 15:13:34 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28341; Sat, 5 Sep 98 15:09:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA12721; Sat, 5 Sep 1998 12:09:39 -0700 (PDT) To: Robert Bihlmeyer Cc: petersen@kurims.kyoto-u.ac.jp, sds@goems.com, scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Fri Sep 4 15:11:33 EDT 1998 References: <199809041911.PAA26703@huis-clos.mit.edu> From: Greg Badros Date: 05 Sep 1998 12:09:38 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 10:17:46 +0200" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> On Fri, 4 Sep 1998 15:11:34 -0400 > >>>>> "Greg J. Badros" said: > > Greg> * configure.in: Move the AC_PROG_CXX macro back out of the > Greg> with-cassowary branch so CXX always gets set. Automake appears > Greg> to output a $(CXXLINK) build rule when any source files are > Greg> C++, so we need CXX set. Users w/o a C++ compiler who want to > Greg> use scwm w/o cassowary can build it using e.g., > Greg> CXX=$CC CXXFLAGS=$CFLAGS ./configure > Greg> or, more specifically > Greg> CXX=gcc CXXFLAGS="-Wall -O2" ./configure > > Shouldn't "./configure" without the variable setting suffice? From the > autoconf-2.12 manual: > - Macro: AC_PROG_CXX I didn't use the macro except inside the --with-cassowary branch. I changed it yesterday, though, because automake uses CXXLINK if it sees any C++ source files (in error, I think). Greg From owner-scwm-discuss@mit.edu Sat Sep 5 15:24:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01843 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:24:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01840 for ; Sat, 5 Sep 1998 15:24:36 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA29365; Sat, 5 Sep 98 15:20:47 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA12763; Sat, 5 Sep 1998 12:20:41 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> From: Greg Badros Date: 05 Sep 1998 12:20:39 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 11:23:20 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > This should not matter. With my autoconf (2.12) AC_PROG_CXX expands to > the following among other code: > > test -n "$CXX" || CXX="gcc" > > So $CXX should never be empty. So I guess I was worried over nothing. My changes yesterday then should be fine. Let me know if people are still having difficulties with this. Thanks for the insight! Greg From owner-scwm-discuss@mit.edu Sat Sep 5 15:28:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01914 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:28:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01911 for ; Sat, 5 Sep 1998 15:28:18 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA29725; Sat, 5 Sep 98 15:24:29 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA12786; Sat, 5 Sep 1998 12:24:24 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 05 Sep 1998 12:24:24 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 10:48:45 +0200" Message-Id: Lines: 36 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > I'd like to see sound support in scwm. It should interact with both > nas (because it's the thing that most resembles a standard), and > esound (because it shows signs of development). Simple support is > quite possible at the scheme level right now. Just `execute' "esdcat" > or something. > > Hmm, what would be best: > > (a) provide hooks for every action under the sun: maximize-hook, > iconify-hook, focus-change-hook, etc. Sound code would hang onto > this. > (b) hard-code call-backs into primitives of interest, like > "(sound-event 'maximize)" > (c) have the sound code advertise the primitives. The advertised > versions would call `play-sound' with appropriate parameters. > > Variant (c) definitely looks best to me. Is somebody interested in > doing this? "advertise?" Is that similar to ELisp advice? Are there packages to do this sort of thing available? It seems useful for lots of things (and I know it's useful in Emacs). We definitely don't want hooks for all commands. And hard-coding call-backs isn't much better (in general, I prefer primitives to not invoke callbacks because those calls are more hidden and then the primitive is no longer very primitive since it would be executing arbitrary scheme code). Definitely worth doing something to better support sound, and hopefully more flexibility and customizability while we're at it! Greg From owner-scwm-discuss@mit.edu Sat Sep 5 15:31:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02025 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:31:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02019 for ; Sat, 5 Sep 1998 15:30:59 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA29957; Sat, 5 Sep 98 15:27:10 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA12789; Sat, 5 Sep 1998 12:27:04 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 05 Sep 1998 12:27:01 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 11:08:16 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Mark> All very tricky, I know - the problem is that while I want > Mark> total control - i.e. I'll edit the files myself, I also want > Mark> Linux to be more accessible to new users, without locking them > Mark> out of class products like SCWM :) > > This is hard enough even for files of rather strict format (cf. the > admin-tools that are shipped with the various distributions). It > becomes damn near impossible with the free-form configuration programs > scwm uses. > > I think the best we can do is a tool like Emacs's "custom": one that > emits it's own config-settings, understands and changes just these, > and leaves other code alone. All things should be controllable from > this tool, of course. Users would have no need to hand-edit the > scwmrc, but could if they wanted. Right... and if the basic configuration that uses those customized variables is sufficiently rich and structured, we'll be able to have a wholly-GUI customizable wm for non scheme-hackers. With full Gtk support, this shouldn't be too bad to do, either.... Greg From owner-scwm-discuss@mit.edu Sat Sep 5 15:50:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02292 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:50:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02289 for ; Sat, 5 Sep 1998 15:50:06 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA29237; Sat, 5 Sep 98 15:46:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA12824; Sat, 5 Sep 1998 12:46:10 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 05 Sep 1998 12:46:05 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 12:02:41 +0200" Message-Id: Lines: 89 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > > Greg> MODIFIER-SPECIFIER is an cons pair of bitmasks for the modifier > Greg> bits of the event: (MUST-BE-ON . MUST-BE-OFF). E.g., if bit 2 > Greg> corresponds to the meta modifier, (4 . 0) would match events > Greg> with at least the Meta modifier depressed, while (0 . 4) would > Greg> match only events without the Meta modifier depressed. > Greg> `with-modifier' and other convenience functions will be > Greg> provided to simplify the writing of the MODIFIER-SPECIFIER. > Greg> They will permit using logical modifiers using symbols (e.g., > Greg> 'control 'meta 'hyper 'super, etc.) and physical modifiers by > Greg> numbers (e.g., 1 refers to whatever mod1 is). Call the > Greg> modifiers of the key event: MOD. The event matches the > Greg> MODIFIER-SPECIFIER iff: > Greg> ((MOD | OnMask == MOD) && (MOD & ~OffMask == MOD)). > > First, I think this makes it too easy to give bits instead of proper > (symbolic) modifiers. I can't think of a situation where using the > modifier bit directly is not evil. > > Second, if we save modifier bits internally, we will lose when the > user changes the modifier mapping while scwm is running. > > I think MODIFIER-SPECIFIER should be a list of modifier symbols, (e.g. > '(super shift)) which is translated to raw bits every time an event is > processed. > > Can guile symbols have a tilde in them. Then we could express > must-off-modifiers like this: ~control These are all good points that I overlooked when I made these changes. I'll go back to the symbolic modifiers. I still think permitting less-magical 'mod1 'mod2 symbols is an okay thing even if they're not used commonly (could be helpful in debugging and testing). And yes, Scheme has "~" in the list of extended alphabetic characters, so we can do '~control to mean "control is not depressed". Perhaps if the first symbol is 'exactly then we get the same as the bang in X resources. So: '(exactly control) is like '(control ~shift ~meta ~super ~alt ~hyper ~numlock) We could also do '*numlock to be a don't care: '(exactly control *numlock) would be '(control ~shift ~meta ~super ~alt ~hyper) > > [Dispatching] > Greg> ;; Each procedure is invoked with four arguments: > Greg> ;; #1 - the scheme object that the event acted on/in (e.g., for a button > Greg> ;; decoration, it will be that top-level frame; for a menu it will be > Greg> ;; the menu object, etc.), or #f if there is no applicable scheme object > Greg> ;; (e.g., the root window) > Greg> ;; #2 - the event object that caused this dispatch (i.e. EVENT) > > How do I get to details specific to event-type (e.g. which property > changed in a PropertyNotify)? An excellent point. We should have a fifth argument that is a list containing event-specific details, if any (or #f). e.g., property-notify events might have the fifth arg be '("WM_TITLE" 'PropertyNewValue) ;; the property name changed and one of 'PropertyNewValue or 'PropertyDelete we can figure out what these should be my the X11 man pages for the events. We might also want to add another standard argument containing the time of the X event. > Greg> ;; #3 - the event map object (i.e. EVENT-MAP) > Greg> ;; #4 - the window id of the X window that got the event. We can add > Greg> ;; primitives to query what decoration/menu/whatever a window ID is > > [Event maps] > Greg> [...] -- the attaching of the default event maps needs to be > Greg> efficient, since it'll happen for each new window and on lots > Greg> of decorations -- it's only a single XSaveContext call for each > Greg> attachment, which shouldn't be too bad]. > > Perhaps don't store anything at all in the default case. Not having a > valid XContext would mean the defaults, then. I don't think this is really an issue; XSaveContext doesn't require a round trip (it maintains a hash table local to Xlib), so even five or six XSaveContext-s are no big deal. We could special case the default, but it's a low enough level implementation detail that I'm not that concerned yet. Thanks for your excellent criticisms! Greg From owner-scwm-discuss@mit.edu Sat Sep 5 15:55:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02379 for scwm-discuss-outgoing; Sat, 5 Sep 1998 15:55:09 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA02376 for ; Sat, 5 Sep 1998 15:55:06 -0400 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA02069; Sat, 5 Sep 98 15:51:17 EDT Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.8.8/8.6.4) with SMTP id PAA27517; Sat, 5 Sep 1998 15:51:31 -0400 (EDT) Message-Id: <199809051951.PAA27517@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: questions, ideas, stuff In-Reply-To: Your message of "04 Sep 1998 18:39:29 PDT." Date: Sat, 05 Sep 1998 15:51:30 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ok, so last night I said I'd give the version in hte CVS repository a shot. Where is the CVS repository, or do I need to get a snapshot (no anon access?) I can't find it on the web page or in any of the docs... From owner-scwm-discuss@mit.edu Sat Sep 5 16:06:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02547 for scwm-discuss-outgoing; Sat, 5 Sep 1998 16:06:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02543 for ; Sat, 5 Sep 1998 16:06:03 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03066; Sat, 5 Sep 98 16:02:09 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA13607; Sat, 5 Sep 1998 13:02:00 -0700 (PDT) To: Eric Moore Cc: scwm-discuss@mit.edu Subject: Anon CVS availability [ was Re: questions, ideas, stuff ] References: <199809051951.PAA27517@chopin.chem.cmu.edu> From: Greg Badros Date: 05 Sep 1998 13:01:59 -0700 In-Reply-To: Eric Moore's message of "Sat, 05 Sep 1998 15:51:30 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Eric Moore writes: > Ok, so last night I said I'd give the version in hte CVS repository a shot. > > Where is the CVS repository, or do I need to get a snapshot (no anon access?) > > I can't find it on the web page or in any of the docs... See http://huis-clos.mit.edu/scwm-discuss.1998/0496.html We definitely should make this more obviously visible on the web page. Good luck, and be sure to read ./HACKING in the distribution for details on building using the CVS repository. Greg From owner-scwm-discuss@mit.edu Sat Sep 5 16:22:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02797 for scwm-discuss-outgoing; Sat, 5 Sep 1998 16:22:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02794 for ; Sat, 5 Sep 1998 16:22:35 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04553; Sat, 5 Sep 98 16:18:44 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA13620; Sat, 5 Sep 1998 13:18:39 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> From: Greg Badros Date: 05 Sep 1998 13:18:37 -0700 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 11:23:20 +0200" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 04 Sep 1998 10:37:57 -0700 > >>>>> Greg Badros said: > > Greg> It's meant to work with the GNOME session manager, but I don't > Greg> have the time or interest to build GNOME just to test the > Greg> session manager piece (don't get me wrong, I'm very interested > Greg> in using GNOME after it's matured -- I just am already at my > Greg> limit of unstable software use). > > I have a pretty recent gnome-core here, so I can test this, whenever I > can transport a new scwm-snapshot home (when my sneaker-net is up > again). Great-- this would be a big win! I'll check in postscript versions of the ICE and SM docs so that if you feel like debugging or improving the support you don't have to go search for the specs. Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 6 08:15:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA08774 for scwm-discuss-outgoing; Sun, 6 Sep 1998 08:15:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA08769 for ; Sun, 6 Sep 1998 08:15:33 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA16854 for scwm-discuss@huis-clos.mit.edu; Sun, 6 Sep 1998 14:11:36 +0200 (CEST) Received: (qmail 3028 invoked by uid 115); 6 Sep 1998 11:55:13 -0000 To: scwm-discuss@mit.edu Subject: Gnome, ICE, SM References: <35f200f7.353730046@smtp> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Sep 1998 13:55:11 +0200 In-Reply-To: Greg Badros's message of "05 Sep 1998 13:18:37 -0700" Message-ID: Lines: 31 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 05 Sep 1998 13:18:37 -0700 >>>>> Greg Badros said: Greg> I'll check in postscript versions of the ICE and SM docs so Greg> that if you feel like debugging or improving the support you Greg> don't have to go search for the specs. Thanks, but that was not necessary. I have the X specs here in plain text (preferable to ps for online reading). Say, aren't these specs a bit large to include? I don't know what documents you included specifically - here it looks like this: 53 ICE/ICElib.PS.gz 29 ICE/ice.PS.gz 50 SM/SMlib.PS.gz 25 SM/xsmp.PS.gz 157 total 830 /home/robbe/new/scwm.tgz (before inclusion of ICE/SM-specs) Pointers to ftp://ftp.x.org/.../untarred/xc/doc/hardcopy/{ICE,SM} would probably suffice. Tell me, if you think I'm overly conservative. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Sep 6 08:15:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA08775 for scwm-discuss-outgoing; Sun, 6 Sep 1998 08:15:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA08768 for ; Sun, 6 Sep 1998 08:15:33 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA16851 for scwm-discuss@huis-clos.mit.edu; Sun, 6 Sep 1998 14:11:35 +0200 (CEST) Received: (qmail 2631 invoked by uid 115); 6 Sep 1998 11:24:36 -0000 To: scwm-discuss@mit.edu Subject: Re: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Sep 1998 13:24:34 +0200 In-Reply-To: Greg Badros's message of "05 Sep 1998 12:24:24 -0700" Message-ID: Lines: 36 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 05 Sep 1998 12:24:24 -0700 >>>>> Greg Badros said: Greg> "advertise?" Is that similar to ELisp advice? Argl, yes! I meant advice and mixed that up. Greg> Are there packages to do this sort of thing available? It's not in guile-core or guile-scsh. Is there a guile or scheme repository somewhere? Hmm, looking at the latest cvs logs (sort.scm, quicksort.scm), scwm is becoming this sort of repository ... (The goal, of course, being to have more scm files in scwm than el files in Emacs .) Greg> It seems useful for lots of things (and I know it's useful in Greg> Emacs). Definitely, there are also two functions advised manually in base.scm (look for "gross hack alert!"). Greg> We definitely don't want hooks for all commands. And Greg> hard-coding call-backs isn't much better [...] Indeed. I will write up a simple defadvice macro that should suffice for a while. But, I hope that someone will point to already written code. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Sep 6 12:15:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA09845 for scwm-discuss-outgoing; Sun, 6 Sep 1998 12:15:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA09838 for ; Sun, 6 Sep 1998 12:15:17 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA20705 for scwm-discuss@huis-clos.mit.edu; Sun, 6 Sep 1998 18:11:18 +0200 (CEST) Received: (qmail 3065 invoked by uid 115); 6 Sep 1998 12:15:37 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 06 Sep 1998 14:15:36 +0200 In-Reply-To: Greg Badros's message of "05 Sep 1998 12:46:05 -0700" Message-ID: Lines: 55 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 05 Sep 1998 12:46:05 -0700 >>>>> Greg Badros said: Greg> I still think permitting less-magical 'mod1 'mod2 symbols is an Greg> okay thing even if they're not used commonly (could be helpful Greg> in debugging and testing). That's ok, since users will probably use the less-cryptic 'alt forms. Greg> And yes, Scheme has "~" in the list of extended alphabetic Greg> characters, so we can do '~control to mean "control is not Greg> depressed". Perhaps if the first symbol is 'exactly then we get Greg> the same as the bang in X resources. So: Greg> '(exactly control) is like '(control ~shift ~meta ~super ~alt Greg> ~hyper ~numlock) Greg> We could also do '*numlock to be a don't care: Greg> '(exactly control *numlock) would be '(control ~shift ~meta Greg> ~super ~alt ~hyper) Let me think about this again ... Say I want to have super-m bound to minimize. My first guess would be "m" with '(super). But this would also bind a lot of other combinations (control-super-m, alt-super-m, ...). My intention is better served with '(exactly super). But this does not work when caps-lock or numlock are activated. I'd probably expect the former, but surely not the latter. So '(exactly super *numlock) is needed, not the most intuitive choice. This is the case for almost all key-events - I normally want to bind exactly. What to do? Reverse the logic and imply exact unless some other special symbol is present? Should '*numlock be implied always? Or use the admittedly clean solution, and live with the consequences? Greg> I don't think this is really an issue; XSaveContext doesn't Greg> require a round trip (it maintains a hash table local to Xlib), Greg> so even five or six XSaveContext-s are no big deal. Ok. One question still: Are the event maps copied or referenced? I.e. if the default map changes, will the change propagate to all windows that had the default map attached automatically? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Sep 6 12:15:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA09846 for scwm-discuss-outgoing; Sun, 6 Sep 1998 12:15:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA09842 for ; Sun, 6 Sep 1998 12:15:23 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA20724 for scwm-discuss@huis-clos.mit.edu; Sun, 6 Sep 1998 18:11:24 +0200 (CEST) Received: (qmail 3461 invoked by uid 115); 6 Sep 1998 15:01:13 -0000 To: gnome-list@gnome.org Cc: scwm-discuss@mit.edu Mail-Copies-To: robbe@orcus.priv.at Subject: scwm and GNOME X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Sep 1998 18:56:21 +0200 Message-ID: Lines: 38 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I try to implement support for the "GNOME Window Manger Hints Proposal" in scwm. One problem that has arised is an abstraction clash: The proposal talks about "workspaces". I understand this as a number of not necesserily distinct sets of windows, with of these being called "active". Windows belonging to the "active" set are mapped (visible), while those not belonging to the "active" set are unmapped. fvwm and scwm call these sets "desktops". I will call them workspaces in the following. (Some definition of the workspace term should be in the proposal.) The WIN_WORKSPACE_COUNT property holds the number of workspaces. scwm does not have a fixed number of workspaces. If you put a window on workspace 777, it is there. scwm can be thought to have an unlimited number of workspaces. This does not work well with the GNOME panel's pager applet: The pager ignores nameless workspaces, and has problems if the named workspaces exceed a certain number. Should I limit the number of workspaces in scwm to a number choosen by the user? Another nit with the proposal: It would be cleaner, IMHO, to remove the necessity for ClientMessages (e.g. when a client wants to change WIN_LAYER). The wm can and should listen to PropertyNotify events on the root and all top-level windows, so the client should be able to simply change the property. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Sep 6 13:18:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10217 for scwm-discuss-outgoing; Sun, 6 Sep 1998 13:18:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10214 for ; Sun, 6 Sep 1998 13:18:19 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24484; Sun, 6 Sep 98 13:14:19 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA03436; Sun, 6 Sep 1998 10:14:13 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Gnome, ICE, SM References: <35f200f7.353730046@smtp> From: Greg Badros Date: 06 Sep 1998 10:14:13 -0700 In-Reply-To: Robert Bihlmeyer's message of "06 Sep 1998 13:55:11 +0200" Message-Id: Lines: 36 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > > Greg> I'll check in postscript versions of the ICE and SM docs so > Greg> that if you feel like debugging or improving the support you > Greg> don't have to go search for the specs. > > Thanks, but that was not necessary. I have the X specs here in plain > text (preferable to ps for online reading). > > Say, aren't these specs a bit large to include? I don't know what > documents you included specifically - here it looks like this: > > 53 ICE/ICElib.PS.gz > 29 ICE/ice.PS.gz > 50 SM/SMlib.PS.gz > 25 SM/xsmp.PS.gz > 157 total > > 830 /home/robbe/new/scwm.tgz (before inclusion of ICE/SM-specs) > > Pointers to ftp://ftp.x.org/.../untarred/xc/doc/hardcopy/{ICE,SM} > would probably suffice. Tell me, if you think I'm overly conservative. Probably... but I didn't know about the hardcopy links -- I made the postscript myself. Doh! In any case, I think our packaging-up-distribution script should probably start pruning stuff off anyway before creating the tar.gz file. You're probably right that it's overkill to have them in the repo given that a simple link exists. I'll probably remove them later. Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 6 13:26:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10323 for scwm-discuss-outgoing; Sun, 6 Sep 1998 13:26:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10320 for ; Sun, 6 Sep 1998 13:26:57 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA25350; Sun, 6 Sep 98 13:22:59 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA03534; Sun, 6 Sep 1998 10:22:55 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 06 Sep 1998 10:22:54 -0700 In-Reply-To: Robert Bihlmeyer's message of "06 Sep 1998 13:24:34 +0200" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> "advertise?" Is that similar to ELisp advice? > > Argl, yes! I meant advice and mixed that up. Argl.... is that similar to "argh"? :-) :-) > Greg> Are there packages to do this sort of thing available? > > It's not in guile-core or guile-scsh. Is there a guile or scheme > repository somewhere? There's slib. See http://angela.ctrl-c.liu.se/~calle/scheme/slib_toc.html > Hmm, looking at the latest cvs logs (sort.scm, quicksort.scm), scwm is > becoming this sort of repository ... (The goal, of course, being to > have more scm files in scwm than el files in Emacs .) The quicksort is just in scheme/tests; What can I tell you, I'm a pack rat. The repo serves as both a backup and synchronization (between school/work and home) mechanism for me. > Greg> It seems useful for lots of things (and I know it's useful in > Greg> Emacs). > > Definitely, there are also two functions advised manually in base.scm > (look for "gross hack alert!"). Ahh... yes... that rings a bell-- I had seen that a ways back and wasn't in the state of mind to recognize the construct. > > Greg> We definitely don't want hooks for all commands. And > Greg> hard-coding call-backs isn't much better [...] > > Indeed. I will write up a simple defadvice macro that should suffice > for a while. But, I hope that someone will point to already written > code. I'll ask over on the guile list, too, but rolling our own may be the way to go (keeping the general case in mind). Greg From owner-scwm-discuss@mit.edu Sun Sep 6 13:36:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10462 for scwm-discuss-outgoing; Sun, 6 Sep 1998 13:36:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10453 for ; Sun, 6 Sep 1998 13:36:00 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24072; Sun, 6 Sep 98 13:31:58 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA03556; Sun, 6 Sep 1998 10:31:55 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 06 Sep 1998 10:31:54 -0700 In-Reply-To: Robert Bihlmeyer's message of "06 Sep 1998 14:15:36 +0200" Message-Id: Lines: 70 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> I still think permitting less-magical 'mod1 'mod2 symbols is an > Greg> okay thing even if they're not used commonly (could be helpful > Greg> in debugging and testing). > > That's ok, since users will probably use the less-cryptic 'alt forms. Right. > Greg> And yes, Scheme has "~" in the list of extended alphabetic > Greg> characters, so we can do '~control to mean "control is not > Greg> depressed". Perhaps if the first symbol is 'exactly then we get > Greg> the same as the bang in X resources. So: > > Greg> '(exactly control) is like '(control ~shift ~meta ~super ~alt > Greg> ~hyper ~numlock) > > Greg> We could also do '*numlock to be a don't care: > > Greg> '(exactly control *numlock) would be '(control ~shift ~meta > Greg> ~super ~alt ~hyper) > > Let me think about this again ... > > Say I want to have super-m bound to minimize. My first guess would be > "m" with '(super). But this would also bind a lot of other > combinations (control-super-m, alt-super-m, ...). My intention is > better served with '(exactly super). But this does not work when > caps-lock or numlock are activated. I'd probably expect the former, > but surely not the latter. So '(exactly super *numlock) is needed, not > the most intuitive choice. This is the case for almost all key-events > - I normally want to bind exactly. > > What to do? Reverse the logic and imply exact unless some other > special symbol is present? Should '*numlock be implied always? > > Or use the admittedly clean solution, and live with the consequences? Yea, I was pondering this, too. Maybe we just have another pseudo-modifier for the first position analogous to 'exactly that does the implicit *numlock (and *capslock or whatever other modifiers are silly to force to be off). That one could be 'with, so: (make-key-event "m" '(with super)) Does exactly what you want, and is arguably the most natural to write, but we don't give up the cleanliness of 'exactly. I also updated the text to mention another pseudo-modifier, 'iwith which will add in an implicit *shift, too. > Greg> I don't think this is really an issue; XSaveContext doesn't > Greg> require a round trip (it maintains a hash table local to Xlib), > Greg> so even five or six XSaveContext-s are no big deal. > > Ok. > > One question still: Are the event maps copied or referenced? I.e. if > the default map changes, will the change propagate to all windows that > had the default map attached automatically? Referenced semantics because the actual event object will be attached to the window, and that event object will be modified in place by {add,remove}-event-binding procedures. Again, thanks for bringing up all these great issues. The latest version of the text is in the repository and I urge all interested to read it and provide more comments. The implementation hour is nearing... Greg From owner-scwm-discuss@mit.edu Sun Sep 6 14:54:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA10896 for scwm-discuss-outgoing; Sun, 6 Sep 1998 14:54:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA10893 for ; Sun, 6 Sep 1998 14:54:14 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA00752; Sun, 6 Sep 98 14:50:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA03910; Sun, 6 Sep 1998 11:50:13 -0700 (PDT) To: scwm-discuss@mit.edu, constraints@cs.washington.edu Subject: Cassowary and scwm build with egcs-1.1b From: Greg Badros Date: 06 Sep 1998 11:50:13 -0700 Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Though there are some bugs in egcs-1.1b that the Cassowary constraint library tickles, I did get it to build successfully with the newly-released egcs-1.1b. You need to turn off the -pedantic g++ option, and comment out the last line of ClLinearExpression.cc so it reads: // template class ClGenericLinearExpression; This is just to prevent instantiation of the unused class. (Note that I've not actually tested w/ 0.2, but with my slightly revised version -- differences from the released 0.2 are pretty minimal). I've sent in a bug report to egcs-bugs@cygnus.com, so hopefully some of the compiler problems will be resolved in future releases. Note that you while building you will get warnings like: /scratch/gjb/cassowary/c++/../guile/cassowary_scm.hpp:42: warning: volatile qualifier ignored on asm which I've not yet fully investigated (feel free to send the egcs folks a bug report; I haven't yet). Scwm (latest version from repo) also built successfully w/ egcs-1.1b and constraints turned on. Brief testing seems to indicate that things are working well. Greg From owner-scwm-discuss@mit.edu Sun Sep 6 16:25:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA11900 for scwm-discuss-outgoing; Sun, 6 Sep 1998 16:25:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA11897 for ; Sun, 6 Sep 1998 16:25:41 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA08804; Sun, 6 Sep 98 16:21:40 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id QAA15340 for ; Sun, 6 Sep 1998 16:21:41 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Event rewrite proposal, revised References: <"UeCkw2.0.hX3.9Viyr"@tequila.systemsz.cs.yale.edu> Date: 06 Sep 1998 16:21:34 -0400 Message-Id: <5lpvd956wh.fsf@tequila.systemsz.cs.yale.edu> Lines: 37 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> Yea, I was pondering this, too. Maybe we just have another Greg> pseudo-modifier for the first position analogous to 'exactly that Greg> does the implicit *numlock (and *capslock or whatever other modifiers Greg> are silly to force to be off). That one could be 'with, so: I'd rather have something like: (setq default-modifiers '(~control ~shift ~meta ~super ~alt ~hyper)) and then have these values used as the default if unspecified: '(control) would map to '(control ~shift ~meta ~super ~alt ~hyper)) You could also remove the '~shift' from default-modifiers in order to ignore shift unless explicitely specified. To allow expressing the 'non exact' forms, one could use things like '(control *shift) -> '(control ~meta ~super ~alt ~hyper)) '(control *) -> '(control) '(meta numlock *shift) -> '(~control meta ~super ~alt ~hyper numlock)) This seems to correspond better to my usual way of thinking. I'd also love to have some way to specify that alt and meta should (usually) be considered equivalent (as well as shift and capslock). So that '(meta) catches '(~control ~shift meta ~super ~alt ~hyper) as well as '(~control ~shift ~meta ~super alt ~hyper), while '(meta ~alt) only catches '(~control ~shift meta ~super ~alt ~hyper) Any takers ? Stefan From owner-scwm-discuss@mit.edu Sun Sep 6 16:38:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA12101 for scwm-discuss-outgoing; Sun, 6 Sep 1998 16:38:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA12098 for ; Sun, 6 Sep 1998 16:38:35 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA13295; Sun, 6 Sep 98 16:34:34 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id QAA15380 for ; Sun, 6 Sep 1998 16:34:34 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> Date: 06 Sep 1998 16:34:28 -0400 Message-Id: <5logst56az.fsf@tequila.systemsz.cs.yale.edu> Lines: 28 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Robbe" == Robert Bihlmeyer writes: Greg> We definitely don't want hooks for all commands. And hard-coding Greg> call-backs isn't much better [...] Robbe> Indeed. I will write up a simple defadvice macro that should suffice Robbe> for a while. But, I hope that someone will point to already written Robbe> code. Obviously, you can't put hooks everywhere, but I feel it important not to rely on advice too much: it should (as is the case in Emacs) be considered as a 'last resort' hack. Everywhere where you can expect several people will feel the urge to advise the function, a hook would be preferable. Hooks are more convenient (not restricted to 'before' 'after' and 'around') and it's easier to change one hook called from different places than to advise every one of those places. I'm all for an advice package (it's really handy when you want to become fancy somewhere where the original author didn't expect it), but the hooks should be the only 'normal way' to customize the behavior of a function. Support for hooks should be pervasive and well designed. Emacs for instance lacks a notion of hierarchy of hooks (you could easily add such a thing with a property added to each hook and a little hacking of run-hooks) even though it does provide something similar for the special case of buffer-local hooks. Stefan PS: when I say 'hierarchy' I don't really mean a tree but rather a DAG. From owner-scwm-discuss@mit.edu Sun Sep 6 16:51:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA12288 for scwm-discuss-outgoing; Sun, 6 Sep 1998 16:51:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA12285 for ; Sun, 6 Sep 1998 16:51:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14475; Sun, 6 Sep 98 16:47:32 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA05986; Sun, 6 Sep 1998 13:47:28 -0700 (PDT) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Sound support References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> <5logst56az.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 06 Sep 1998 13:47:28 -0700 In-Reply-To: Stefan Monnier's message of "06 Sep 1998 16:34:28 -0400" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > Obviously, you can't put hooks everywhere, but I feel it important not to rely > on advice too much: it should (as is the case in Emacs) be considered as a > 'last resort' hack. Everywhere where you can expect several people will feel > the urge to advise the function, a hook would be preferable. Hooks are more > convenient (not restricted to 'before' 'after' and 'around') and it's easier to > change one hook called from different places than to advise every one of those > places. > > I'm all for an advice package (it's really handy when you want to become > fancy somewhere where the original author didn't expect it), but the hooks > should be the only 'normal way' to customize the behavior of a function. > Support for hooks should be pervasive and well designed. Emacs for instance > lacks a notion of hierarchy of hooks (you could easily add such a thing with a > property added to each hook and a little hacking of run-hooks) even though it > does provide something similar for the special case of buffer-local hooks. Lacking the hooks, the existence of advice may well prove useful in determining where those hooks *should* be; we can provide advice, then see how we and others have used it usefully and gain some experience before going back and adding hooks extensively. Then the hooks we do add will be more justified. Advice also only penalizes where used. Imagine if every primitive had a before and after hook; then even if those hooks were always empty, the checking of those hook variables would still have to happen and slow things down. (Not to mention the pollution of the namespace -- though I think that's easy to manage using a hooks module and some macros to manipulate symbols in that environment). Also, I still have a distaste for primitives invoking hooks. I see a hook as most useful for asynchronous events, not for things directly invoked. I know smart people disagree with me on this last point, so I'm interested in seeing good arguments against me (or others who may be able to further help me clarify my thinking). Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 6 16:55:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA12345 for scwm-discuss-outgoing; Sun, 6 Sep 1998 16:55:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA12342 for ; Sun, 6 Sep 1998 16:55:09 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11554; Sun, 6 Sep 98 16:51:07 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA06013; Sun, 6 Sep 1998 13:51:05 -0700 (PDT) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"UeCkw2.0.hX3.9Viyr"@tequila.systemsz.cs.yale.edu> <5lpvd956wh.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 06 Sep 1998 13:51:04 -0700 In-Reply-To: Stefan Monnier's message of "06 Sep 1998 16:21:34 -0400" Message-Id: Lines: 48 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Greg" == Greg Badros writes: > Greg> Yea, I was pondering this, too. Maybe we just have another > Greg> pseudo-modifier for the first position analogous to 'exactly that > Greg> does the implicit *numlock (and *capslock or whatever other modifiers > Greg> are silly to force to be off). That one could be 'with, so: > > I'd rather have something like: > > (setq default-modifiers '(~control ~shift ~meta ~super ~alt ~hyper)) > > and then have these values used as the default if unspecified: > > '(control) would map to '(control ~shift ~meta ~super ~alt ~hyper)) > > You could also remove the '~shift' from default-modifiers in order to ignore > shift unless explicitely specified. To allow expressing the 'non exact' > forms, one could use things like > > '(control *shift) -> '(control ~meta ~super ~alt ~hyper)) > '(control *) -> '(control) > '(meta numlock *shift) -> '(~control meta ~super ~alt ~hyper numlock)) I don't understand what your "->" means here. Is this just a "is as if the user had written" arrow? > This seems to correspond better to my usual way of thinking. > I'd also love to have some way to specify that alt and meta should (usually) > be considered equivalent (as well as shift and capslock). So that > > '(meta) catches '(~control ~shift meta ~super ~alt ~hyper) > as well as '(~control ~shift ~meta ~super alt ~hyper), > > while > > '(meta ~alt) only catches '(~control ~shift meta ~super ~alt ~hyper) I'm pretty sure that what you want could easily be built on top of the primitives I wrote about, and am not convinced that the default-modifiers should be recognized by the C primitives. I fully envision a (fairly thin) couple of macros or procedures to aid in creating bindings more usefully and at a higher level of abstraction (e.g., my key-mouse-moves procedure) for the end user. Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 6 17:04:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12500 for scwm-discuss-outgoing; Sun, 6 Sep 1998 17:04:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12494; Sun, 6 Sep 1998 17:04:32 -0400 Message-Id: <199809062104.RAA12494@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: I'm back Date: Sun, 06 Sep 1998 17:04:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi everyone, I'm back from my vaction (have been for two days now actually). I'm trying to catch up on my scwm related mail, especially the most recent stuff. I'm glad to see so much progress has been made while I was away. And I'm glad to be able to participate more actively again. - Maciej From owner-scwm-discuss@mit.edu Sun Sep 6 17:17:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12629 for scwm-discuss-outgoing; Sun, 6 Sep 1998 17:17:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA12626 for ; Sun, 6 Sep 1998 17:17:32 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA16818; Sun, 6 Sep 98 17:13:32 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA06086; Sun, 6 Sep 1998 14:13:30 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: I'm back References: <199809062104.RAA12494@huis-clos.mit.edu> From: Greg Badros Date: 06 Sep 1998 14:13:30 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 06 Sep 1998 17:04:31 EDT" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Hi everyone, I'm back from my vaction (have been for two days now > actually). I'm trying to catch up on my scwm related mail, especially > the most recent stuff. I'm glad to see so much progress has been made > while I was away. And I'm glad to be able to participate more actively > again. We're glad to have you back! Welcome home! Greg From owner-scwm-discuss@mit.edu Sun Sep 6 17:20:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12706 for scwm-discuss-outgoing; Sun, 6 Sep 1998 17:20:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA12702 for ; Sun, 6 Sep 1998 17:20:14 -0400 Received: from smtp5.nwnexus.com by MIT.EDU with SMTP id AA13859; Sun, 6 Sep 98 17:16:12 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp5.nwnexus.com (8.8.8/8.8.8) with ESMTP id OAA19931 for ; Sun, 6 Sep 1998 14:16:04 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276517-15944>; Sun, 6 Sep 1998 14:16:08 -0700 To: scwm-discuss@mit.edu Cc: Subject: Re: Again... scwm click-to-place weirdness In-Reply-To: forcer's message of "Tue, 01 Sep 1998 04:59:53 +0200." <19980901045953.A19230@preforcix.roof.lan> Date: Sun, 06 Sep 1998 14:16:04 -0600 From: Ken Pizzini Message-Id: <19980906211608Z276517-15944+141@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In <19980901045953.A19230@preforcix.roof.lan>, said: > Also... i experience (sometimes, getting rarer since 0.7) that scwm > just hangs. I can't click on anything anymore, but sloppy focus works, > the click-to-place works, and i can type. Also, scwmexec '(restart)' > works but doesn't unhang SCWM. strace -p shows it's hanging in a > select(), probably waiting for X input. I've also periodically experienced what I though were random lock-ups of scwm. In the most recent instance I also saw what at first seemed to be a select() lock. But further prodding showed that I was looking at the problem wrong... what I found was that I had somehow tapped my Scroll Lock key, and as my SCWM set-up does not have any keybindings with the Scroll_Lock modifier set, SCWM did not respond to my mouse or keyboard commands, although applications continued to respond just fine. So..... Is there a way to tell the current version of SCWM that the Scroll_Lock modifier should be ignored when determining whether a key event matches? I realize that in a different thread we have Grey mentioning for the new event rewrite proposal: : I was pondering this, too. Maybe we just have another : pseudo-modifier for the first position analogous to 'exactly that does : the implicit *numlock (and *capslock or whatever other modifiers are : silly to force to be off). That one could be 'with, so: : : (make-key-event "m" '(with super)) So for future version we just need to be sure that *scrolllock will be added to the list of "silly to force" modifiers, but for now do I/we just need to live with the scroll lock oddity? (Now that I've finally discovered this glitch, I'll know to check for it next time scwm stops responding to me, so I can probably live with it until the event rewrite if I need to.) --Ken Pizzini From owner-scwm-discuss@mit.edu Sun Sep 6 17:43:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13055 for scwm-discuss-outgoing; Sun, 6 Sep 1998 17:43:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA13052 for ; Sun, 6 Sep 1998 17:43:35 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA15936; Sun, 6 Sep 98 17:39:34 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07318; Sun, 6 Sep 1998 14:38:07 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu, Subject: Re: Again... scwm click-to-place weirdness References: <19980906211608Z276517-15944+141@pulsar.halcyon.com> From: Greg Badros Date: 06 Sep 1998 14:38:06 -0700 In-Reply-To: Ken Pizzini's message of "Sun, 06 Sep 1998 14:16:04 -0600" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > I've also periodically experienced what I though were random lock-ups > of scwm. In the most recent instance I also saw what at first seemed > to be a select() lock. But further prodding showed that I was looking > at the problem wrong... what I found was that I had somehow tapped my > Scroll Lock key, and as my SCWM set-up does not have any keybindings > with the Scroll_Lock modifier set, SCWM did not respond to my mouse > or keyboard commands, although applications continued to respond just > fine. > > So..... > Is there a way to tell the current version of SCWM that the Scroll_Lock > modifier should be ignored when determining whether a key event matches? Nope. Probably could consider it a bug, but there are lots of them in the current event handling code. > I realize that in a different thread we have Grey mentioning for the > new event rewrite proposal: > : I was pondering this, too. Maybe we just have another > : pseudo-modifier for the first position analogous to 'exactly that does > : the implicit *numlock (and *capslock or whatever other modifiers are > : silly to force to be off). That one could be 'with, so: > : > : (make-key-event "m" '(with super)) > > So for future version we just need to be sure that *scrolllock will be > added to the list of "silly to force" modifiers, but for now do I/we > just need to live with the scroll lock oddity? (Now that I've finally > discovered this glitch, I'll know to check for it next time scwm stops > responding to me, so I can probably live with it until the event rewrite > if I need to.) That seems reasonable. For now, I think living with the scroll-lock oddity is the best short-term plan. In the next two weeks, I'll be doing the event rewrite which will trade that oddity for a bunch of completely different bugs! :-) Hopefully we'll also get a spiffy new event model while I'm at it, though! Greg From owner-scwm-discuss@mit.edu Sun Sep 6 18:19:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13259 for scwm-discuss-outgoing; Sun, 6 Sep 1998 18:19:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA13256 for ; Sun, 6 Sep 1998 18:19:07 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA19139; Sun, 6 Sep 98 18:15:04 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id PAA09090; Sun, 6 Sep 1998 15:15:04 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id PAA04915; Sun, 6 Sep 1998 15:15:02 -0700 To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: What can you do with the constraint solver? From: cwitty@newtonlabs.com (Carl R. Witty) Date: 06 Sep 1998 15:15:02 -0700 Message-Id: Lines: 17 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just downloaded and built Greg's Cassowary constraint solver, so that I could play with it in scwm. Then I started thinking about what I would actually do with it--how I would integrate it into my desktop environment--and I came up blank. I looked at the stuff in constraints.scm, and none of it seemed like something I would really use (and, obviously, most (all?) of it wasn't meant to be). I see that you can do things like glue two windows together, so that one is always immediately to the right of the other, but I can't see why you'd want to. So, does anybody have suggestions for interesting or useful things to do with the constraint solver? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sun Sep 6 18:37:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13445 for scwm-discuss-outgoing; Sun, 6 Sep 1998 18:37:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA13442 for ; Sun, 6 Sep 1998 18:37:19 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24993; Sun, 6 Sep 98 18:33:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA07492; Sun, 6 Sep 1998 15:33:14 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: What can you do with the constraint solver? References: From: Greg Badros Date: 06 Sep 1998 15:33:13 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "06 Sep 1998 15:15:02 -0700" Message-Id: Lines: 61 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > I just downloaded and built Greg's Cassowary constraint solver, so > that I could play with it in scwm. Then I started thinking about what > I would actually do with it--how I would integrate it into my desktop > environment--and I came up blank. Glad to hear you had a successful build at least! :-) > I looked at the stuff in constraints.scm, and none of it seemed like > something I would really use (and, obviously, most (all?) of it wasn't > meant to be). I see that you can do things like glue two windows > together, so that one is always immediately to the right of the other, > but I can't see why you'd want to. > > So, does anybody have suggestions for interesting or useful things to > do with the constraint solver? I commonly work with multiple windows that I want to act together. The most obvious example is an Emacs and an xterm on the same machine. I often have the two window along the left hand side of my screen, and like to have the emacs window and the xterm window consume the entire display width, and stay attached vertically. Thus, when I resize and enlarge my emacs (say its on top), the xterm gets shorter, and vice versa. (Similar to controlling a split in an emacs window). The other things that come to mind immediately is replacing some of the ad-hoc functionality that already exists with new implementations within the unifying framework of constraints (I know, now I'm sounding like the researcher Greg, and not the scwm hacker). E.g., sticky windows are basically a constraint that the window viewport position remains unchanged (i.e., the position of the window within the current viewport). Another one I just got working is the stacking order -- stays-on-top and the requested but non-existent stays-on-bottom can be expressed using a z-value on all the windows, and constraining stays-on-tops to have the lowest (nearest) z value, and stays-on-bottom to have the highest z-value. Additionally, you can get windows to raise and lower together. There are many other uses I've thought of, but the grand point is that the world is your oyster. If you can think up interesting things you want to be able to do (of a window-layout nature), I'm optimistic that I can fit it into the framework. The big thing the solver is currently unable to handle is disjunctions (I want this window either to be adjacent to the left edge of my display or the right edge of my display). I suppose the other grand point is that you're using ad-hoc constraints already, and by recognizing the fundamental nature of some of those constraints we can get a lot of power and extensibility. My hope is that people will do crazy new things with the constraint engine that I hadn't even thought about or planned for. That's where we get the real power in software. I'm anxious to hear others' ideas... and even just simple success storied in building cassowary with scwm and using constraints.scm and constraint-stacking.scm. There is certainly a need for higher level abstractions and a gui for specifying and manipulating constraints. Those are areas about which I'm actively thinking and planning. Greg From owner-scwm-discuss@mit.edu Sun Sep 6 19:53:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA14274 for scwm-discuss-outgoing; Sun, 6 Sep 1998 19:53:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA14271 for ; Sun, 6 Sep 1998 19:53:11 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA02242; Sun, 6 Sep 98 19:49:09 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA07877; Sun, 6 Sep 1998 16:49:09 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Documenting irregular user-option variables From: Greg Badros Date: 06 Sep 1998 16:49:08 -0700 Message-Id: Lines: 38 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm pondering how to document and expose user-option variables for Sam's preferences work. Specifically, Sam, you requested settor and getter function names in lieu of a variable name for irregular user options (i.e., those for which there is no actual variable). That certainly is needed, and I'm wondering how best to mark this in the code to have the requisite information extracted properly into scheme/user-options.scm (new file as of today). As an example, consider the shadow-factor user-option variable. It has a getter and a setter, `set-shadow-factor!' and `shadow-factor'. Are there any good arguments not to standardize setters and getters using this convention? I.e., can we agree that a non-variable user-option named "foo" has setter `set-foo!' and getter `foo' (e.g., (set-foo! 3) and (foo))? Then, in code, I can just add: /**OPTION: shadow-factor */ and check that the setter and getter functions are defined. Then the docs for the option can be the setter function's docs. The use of /**OPTION instead of /**VAR is so that there is a distinction between real variables and these dynamic pseudo-variables with setters and getters. We may choose to mark these up a bit differently (in particular the special references to the setter and getter functions), but both /**OPTION and /**VAR variables will have there information list extracted into scheme/user-options.scm. Maciej, have you considered these dynamic pseudo-variables in your API review? What are your thoughts on their continued existence and evolution? I know there was some talk about magic variables ala Tcl on the guile group a while back, but I don't recall anything being finally resolved. Thoughts and comments are appreciated, as always! Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 6 21:01:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA14647 for scwm-discuss-outgoing; Sun, 6 Sep 1998 21:01:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA14644 for ; Sun, 6 Sep 1998 21:01:09 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA03210; Sun, 6 Sep 98 20:57:04 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id RAA22177; Sun, 6 Sep 1998 17:56:58 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id RAA05314; Sun, 6 Sep 1998 17:56:57 -0700 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 06 Sep 1998 17:56:57 -0700 In-Reply-To: Greg Badros's message of "03 Sep 1998 10:39:08 -0700" Message-Id: Lines: 59 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's some suggestions for making the event mechanism more powerful and flexible (and more emacs-like). 1) Allow attach-event-map to take a list of event-maps; scwm will search through all of the event-maps for a binding for a given event. While not inherently more powerful (you could always construct a single event-map with all of the bindings), I think this could be very convenient (in much the same way as emacs minor modes). 2) Taking the analogy with emacs minor modes a step further, attach-event-map could take a list of (ENABLE . EVENT-MAP) pairs, where ENABLE indicates whether this EVENT-MAP is active, or if it should be skipped. In emacs, the equivalent of ENABLE takes the form of buffer-local variables; I'm not sure what would be the equivalent for scwm, but presumably some kind of per-window flags (do I remember correctly that there's some sort of scwm-level per-window "window properties"?). Alternatively, perhaps ENABLE could be a decor, meaning that the event-map should be enabled only if that decor is being used on this window. Again, this does not inherently add power, only convenience; you could always just switch in a new event-map, instead of enabling and disabling elements of a list of event-maps. And now for a confession...while I think the above features would be "cool", I'm not sure if I would actually use them; I don't really feel a need to have lots of different window behaviors and easily switch between them (however, maybe the author of decor.scwmrc would feel differently :-). Here are some more suggestions that I actually would use. 3) Allow multiple-event sequences. For years I've bemoaned the lack of mouse buttons; I would like to rectify that lack by assigning a meaning to complex sequences of button clicks. (For example, I could bind one action to B1-down B2-down B1-up B2-up, and another to B1-down B2-down B2-up B1-up.) I can approximate this with your proposal (by binding to the button events separately, and building my own little state machine); the part I'm unsure if I can do reliably is to abort if another event happens in the middle. (For example, B1-down B2-down keypress-escape B1-up B2-up should do nothing. No, I wouldn't recommend putting this sort of thing in the default system.scwmrc.) If you do want to allow multiple-event sequences, you could look at Tk to see one (fairly clean) implementation of the concept. 4) Allow grabbing the server and reading events. I can think of a couple of applications for this. It would let people write their own version of interactive-move in scheme, for example (perhaps using different keys for the keyboard shortcuts). Here's another example: I'd like to be able to set window "bookmarks". I would focus on a window, hit Hyper-s ('s' for "set bookmark"), and then press a key; this would set a bookmark on the window labeled by that key. Subsequently, if I hit Hyper-j ('j' for "jump to bookmark") and then press the same key, scwm will jump to that window. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Sep 7 03:55:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA16943 for scwm-discuss-outgoing; Mon, 7 Sep 1998 03:55:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from quasar.newtonlabs.com (quasar.newtonlabs.com [206.125.74.97]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA16940 for ; Mon, 7 Sep 1998 03:55:34 -0400 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [206.125.74.119]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA23330; Mon, 7 Sep 1998 00:51:23 -0700 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21848; Mon, 7 Sep 1998 00:51:52 -0700 Date: Mon, 7 Sep 1998 00:51:52 -0700 Message-Id: <199809070751.AAA21848@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: bug in image.c:path_expand_image_fname() Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tracked down a bug in the path_expand_image_fname() function. In the case where the full name of an image was being passed in, a string got free()d twice. Here's a simple patch: --- ../../orig/scwm-19980906/scwm/image.c Thu Sep 3 14:34:19 1998 +++ image.c Mon Sep 7 00:41:31 1998 @@ -370,7 +370,7 @@ /* absolute path */ if(access(c_name, R_OK)==0) { - c_fname=c_name; + c_fname=strdup(c_name); } else { FREE(c_name); return(SCM_BOOL_F); (A smarter patch could avoid a strdup()/free() pair in this case, but I wasn't motivated enough to write that one.) Carl Witty cwitty@newtonlabs.com Linux nebula 2.0.34 #6 Thu Jul 2 07:12:27 PDT 1998 i686 unknown Guile verion: 1.3a Libguile timestamp: Mon Sep 7 00:12:47 PDT 1998 SCWM version: 0.8a Restarted: true Display Size: 1280x1024 Desk Size: 3x3 Viewport: 0x0 Pointer: 963x310 Current Desk: 0 X vendor: The XFree86 Project, Inc; version: 11.0; release: 3320 X Display: Resolution: 2956x2951 Color: TrueColor (depth: 16; bits per RGB: 6) image-load-path: /usr/X11R6/include/X11/pixmaps usr/X11R6/include/X11/bitmaps /src/icons/icons /src/icons/mini-icons From owner-scwm-discuss@mit.edu Mon Sep 7 05:10:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA17283 for scwm-discuss-outgoing; Mon, 7 Sep 1998 05:10:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA17280 for ; Mon, 7 Sep 1998 05:10:04 -0400 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA10285; Mon, 7 Sep 98 05:05:55 EDT Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id LAA13724 for ; Mon, 7 Sep 1998 11:05:55 +0200 (MET DST) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id LAA13274; Mon, 7 Sep 1998 11:05:42 +0200 (MET DST) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13811.41445.386852.632292@chl> Date: Mon, 7 Sep 1998 11:05:41 +0200 (MET DST) To: scwm-discuss@mit.edu Subject: hooks (was Re: Sound support) In-Reply-To: References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> <5logst56az.fsf@tequila.systemsz.cs.yale.edu> X-Mailer: VM 6.59 under Emacs 20.2.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> ...Imagine if every primitive had a before and after hook;... That should never be the way to do these things. There should be hooks in smart places. Where these place are should be learned over time as you suggest yourself. If a more covering hook-up is needed, there should be generic hooks akin to emacs' pre- and post-command hooks that are invoked all the time, in the apropriate sense. In fact doing such hooks ins't very difficult. One can use and/or extend the existing trace facilty. Tracing works by havings hooks (:-) in the evaluator that look out for symbols having a specific property. If so (and tracing is enabled), it throws to (something that will invoke) the hook function. We would then have all scwm functions above a certain level (ie. those that would correspond to emacs' commands) come with a certain symbol property, and then we would have guile look out for these as well. Would take a bit of cooperaton from the guile folks, but should be doable. As for performance, this could be turned off via the evaluator option interface if not needed. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Mon Sep 7 08:40:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA18079 for scwm-discuss-outgoing; Mon, 7 Sep 1998 08:40:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA18073 for ; Mon, 7 Sep 1998 08:39:55 -0400 Received: from nuc04.t30.physik.tu-muenchen.de by MIT.EDU with SMTP id AA00902; Mon, 7 Sep 98 08:35:35 EDT Received: by nuc04.t30.physik.tu-muenchen.de via sendmail from stdin id (Debian Smail3.2.0.101) for scwm-discuss@mit.edu; Mon, 7 Sep 1998 14:38:06 +0200 (CEST) To: scwm-discuss@mit.edu Subject: Re: Sound support (OT!!!) References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Face: cryptographic genetic Albanian $400 million in gold bullion Serbian Ft. Bragg supercomputer [Hello to all my fans in domestic surveillance] Panama BATF Mail-Copies-To: never Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Url: http://WWW.Physik.TU-Muenchen.DE/~ecl From: Emilio Lopes Date: 07 Sep 1998 14:38:06 +0200 In-Reply-To: Greg Badros's message of "06 Sep 1998 10:22:54 -0700" Message-Id: <8767f0xfm9.fsf_-_@nuc04.t30.physik.tu-muenchen.de> Lines: 14 X-Mailer: Gnus v5.6.23/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros wrote: > Robert Bihlmeyer writes: > > Argl, yes! I meant advice and mixed that up. > Argl.... is that similar to "argh"? :-) :-) Just in Tirol and Bavaria. ;-) [konnte nicht widerstehen, Robbe!] -- Emilio.Lopes@Physik.TU-Muenchen.DE "Iprzrapainumficatristvamondarnegascuativa numhaimtodajucopessoalugamilhsquiurodaviva" From owner-scwm-discuss@mit.edu Mon Sep 7 12:06:51 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19448 for scwm-discuss-outgoing; Mon, 7 Sep 1998 12:06:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19445 for ; Mon, 7 Sep 1998 12:06:44 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24826; Mon, 7 Sep 98 12:02:35 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA13405; Mon, 7 Sep 1998 09:02:30 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 07 Sep 1998 09:02:30 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "06 Sep 1998 17:56:57 -0700" Message-Id: Lines: 159 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > Here's some suggestions for making the event mechanism more powerful > and flexible (and more emacs-like). > > 1) Allow attach-event-map to take a list of event-maps; scwm will > search through all of the event-maps for a binding for a given event. > While not inherently more powerful (you could always construct a > single event-map with all of the bindings), I think this could be very > convenient (in much the same way as emacs minor modes). Well we basically have this in the ability for event-maps to have multiple (possibly merged) parents -- see the description of make-event-map. A simple sugar could permit writing attach-event-maps (note plural) which could take such a list of event maps, but it seems like the relationship of event maps is more related to those maps rather than to the thing they are attached to. I noticed that I was missing remove-event-map-parent! and added that to the description. > > 2) Taking the analogy with emacs minor modes a step further, > attach-event-map could take a list of (ENABLE . EVENT-MAP) pairs, > where ENABLE indicates whether this EVENT-MAP is active, or if it > should be skipped. In emacs, the equivalent of ENABLE takes the form > of buffer-local variables; I'm not sure what would be the equivalent > for scwm, but presumably some kind of per-window flags (do I remember > correctly that there's some sort of scwm-level per-window "window > properties"?). Alternatively, perhaps ENABLE could be a decor, > meaning that the event-map should be enabled only if that decor is > being used on this window. To be able to enable and disable event maps on a per attachment basis seems potentially useful. If we were to do this, then attaching an event map to, say, a button would result in a reference to that event map being stored with the button along with a locally-kept flag saying whether that event map was enabled (and that flag would affect the event-map's parents, too). > Again, this does not inherently add power, only convenience; you could > always just switch in a new event-map, instead of enabling and > disabling elements of a list of event-maps. Right, but I think the better question is how much harder (and less efficient) would doing the same thing with the less-convenient primitives be. Here it seems like if we believe enable flags on event maps are useful, they should be exposed in the primitive engine. > And now for a confession...while I think the above features would be > "cool", I'm not sure if I would actually use them; I don't really feel > a need to have lots of different window behaviors and easily switch > between them (however, maybe the author of decor.scwmrc would feel > differently :-). Even if the end user doesn't find a need for the feature, they may support higher-level abstractions that the scwm developers choose to implement which then might become widely used. I like the idea of enable flags on attachments of events.... others' thoughts? > Here are some more suggestions that I actually would use. Even better.... let's see.... > 3) Allow multiple-event sequences. For years I've bemoaned the lack > of mouse buttons; I would like to rectify that lack by assigning a > meaning to complex sequences of button clicks. (For example, I could > bind one action to B1-down B2-down B1-up B2-up, and another to B1-down > B2-down B2-up B1-up.) I can approximate this with your proposal (by > binding to the button events separately, and building my own little > state machine); the part I'm unsure if I can do reliably is to abort > if another event happens in the middle. (For example, B1-down B2-down > keypress-escape B1-up B2-up should do nothing. No, I wouldn't > recommend putting this sort of thing in the default system.scwmrc.) Ugh... I'm pretty opposed to complex ordered event sequences. (e.g., I don't mind lots of modifiers in my left hand + a simple mouse action with my right hand, but I do mind crazy click sequences in my right hand). In general, of course, I'm not designing the event model strictly around things *I* want, but this is one place where I think that discouraging such bindings is not a bad thing. I think the UI community would concur with me that such things are evil, and we should be happy that they're not easy to do within our event model (though perhaps even happier that they *could* be done). > If you do want to allow multiple-event sequences, you could look at Tk > to see one (fairly clean) implementation of the concept. I'll probably take a look at this just to see if they pulled it off somehow that I can't anticipate. Can you give a more specific pointer (source files, documentation of the implementation, user-level docs)? > 4) Allow grabbing the server and reading events. I can think of a > couple of applications for this. It would let people write their own > version of interactive-move in scheme, for example (perhaps using > different keys for the keyboard shortcuts). Here's another example: This is one place where my philosophy has differed from GWM-- in GWM, you could do stuff like grabbing the server which lets you shoot yourself in the foot from the WOOL (their dialect of Lisp) level. In Scwm, we've generally raised the level of abstraction sufficiently that such dangerous primitives are unnecessary. To then go back and provide those primitives anyway defeats our earlier (well-motivated IMO) efforts. > I'd like to be able to set window "bookmarks". I would focus on a > window, hit Hyper-s ('s' for "set bookmark"), and then press a key; > this would set a bookmark on the window labeled by that key. > Subsequently, if I hit Hyper-j ('j' for "jump to bookmark") and then > press the same key, scwm will jump to that window. Ahhh.. good. Thank you for the explicit example -- these are very helpful to get an idea of your perspective and what you're really looking for. I think this (and the interactive-move from scheme) are both doable with non-grab state-based maps. Maybe we need a special first-level map that has priority over all else? That way, E.g., for interactive-move, that top level map could be set with the mode-specific (mode==interactive-move) bindings which would include a binding to exit the mode (remove the top-level mode-specific map). Similarly for the window bookmarks (an excellent idea, I think) -- interactive-set-window-bookmark would set a mode-specific-map where a key-release event was bound to set-window-bookmark-from-event which would take the key pressed and do the right thing. So, a possible revisions: a top-level map that gets dispatched on first (in a sense, implicitly attached to everything) IMPORTANT RELATED ISSUE: Another point that is worth discussing is how the procedures bound to an event should get their arguments. As it is in the proposal, a new procedure is needed for virtually all event bindings because of the arguments that the procedure gets called with. Emacs gets around this difficulty with the interactive declaration. I think a similar thing for Scwm would be highly useful, but I've little experience with the internals of the Emacs mechanism. w/o such a mechanism, every binding will be stuck with using a lambda expression to convert event arguments to parameters for the procedure intended to be bound to the event. Even if we abstract those patterns, the mapping between the two sets of arguments would occur at the add-event-binding site, instead of at the definition of the procedure itself. Bottom line is, I think an interactive declaration for procedure definitions makes a lot of sense, but it's something that I would probably want to defer to Maciej or another guile/scheme guru. In the short run, the current model will just cause the add-event-binding calls to be more long-winded than we might like. If and when interactive declarations for Scwm work, the event model shouldn't change, we'll just be able to omit the lambda converting the arguments to what the procedure's interactive declaration says it wants. Greg From owner-scwm-discuss@mit.edu Mon Sep 7 12:31:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19754 for scwm-discuss-outgoing; Mon, 7 Sep 1998 12:31:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19749 for ; Mon, 7 Sep 1998 12:30:53 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28398; Mon, 7 Sep 98 12:26:44 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA13416; Mon, 7 Sep 1998 09:26:38 -0700 (PDT) To: Christian Lynbech Cc: scwm-discuss@mit.edu Subject: Re: hooks (was Re: Sound support) References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> <5logst56az.fsf@tequila.systemsz.cs.yale.edu> <13811.41445.386852.632292@chl> From: Greg Badros Date: 07 Sep 1998 09:26:37 -0700 In-Reply-To: Christian Lynbech's message of "Mon, 7 Sep 1998 11:05:41 +0200 (MET DST)" Message-Id: Lines: 49 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Christian Lynbech writes: > >>>>> "Greg" == Greg Badros writes: > > Greg> ...Imagine if every primitive had a before and after hook;... > > That should never be the way to do these things. There should be hooks Right -- my point was that there was the performance issue in the limit (of all commands being hookified), and only in the limit do you get the massive benefits of complete customizability. > in smart places. Where these place are should be learned over time as > you suggest yourself. If a more covering hook-up is needed, there > should be generic hooks akin to emacs' pre- and post-command hooks > that are invoked all the time, in the apropriate sense. > > In fact doing such hooks ins't very difficult. One can use and/or > extend the existing trace facilty. Tracing works by havings hooks (:-) > in the evaluator that look out for symbols having a specific > property. If so (and tracing is enabled), it throws to (something that > will invoke) the hook function. We actually do already have a nice way to define and call hooks from the C code, but they're hard-coded locations, not using properties of symbols. We (in Scwm) could certainly have primitives check for a hook property and invoke it -- this solves the plethora of hooks problem, but doesn't address the performance (perhaps not so bad, but given that startup of my scwm is already too slow, I'm not very willing to give much here) and ability-to-reason-about-a-primitive issues. > We would then have all scwm functions above a certain level (ie. those > that would correspond to emacs' commands) come with a certain symbol > property, and then we would have guile look out for these as > well. Would take a bit of cooperaton from the guile folks, but should > be doable. As for performance, this could be turned off via the > evaluator option interface if not needed. This seems good, but I'm always hesitant to ask Guile folks for extra features since I'm *so* much more interested in just seeing 1.3 released-- I don't want to contribute to the delay in a stable 1.3 release! :-) I think exposing a general property-based hooks mechanism within guile is a good idea, and Scwm would definitely be a user of such a feature if/when it exists. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 7 13:27:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20266 for scwm-discuss-outgoing; Mon, 7 Sep 1998 13:27:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20263 for ; Mon, 7 Sep 1998 13:27:21 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23773; Mon, 7 Sep 98 13:23:10 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13476; Mon, 7 Sep 1998 10:23:09 -0700 (PDT) To: "Carl R. Witty" Cc: scwm-discuss@mit.edu Subject: Re: bug in image.c:path_expand_image_fname() References: <199809070751.AAA21848@nebula.newtonlabs.com> From: Greg Badros Date: 07 Sep 1998 10:23:08 -0700 In-Reply-To: "Carl R. Witty"'s message of "Mon, 7 Sep 1998 00:51:52 -0700" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Carl R. Witty" writes: > I tracked down a bug in the path_expand_image_fname() function. In > the case where the full name of an image was being passed in, a string > got free()d twice. > > Here's a simple patch: > --- ../../orig/scwm-19980906/scwm/image.c Thu Sep 3 14:34:19 1998 > +++ image.c Mon Sep 7 00:41:31 1998 > @@ -370,7 +370,7 @@ > /* absolute path */ > > if(access(c_name, R_OK)==0) { > - c_fname=c_name; > + c_fname=strdup(c_name); > } else { > FREE(c_name); > return(SCM_BOOL_F); > > (A smarter patch could avoid a strdup()/free() pair in this case, but > I wasn't motivated enough to write that one.) Thanks for catching this! I added this guard, instead, before free-ing c_fname: /* c_fname and c_name may be aliased from assignment above -- be sure to free only once */ if (c_fname != c_name) FREE(c_fname); That function is not as obviously-correct as I'd like it to be... thanks for the problem and fix! Greg From owner-scwm-discuss@mit.edu Mon Sep 7 17:27:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22024 for scwm-discuss-outgoing; Mon, 7 Sep 1998 17:27:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA22021 for ; Mon, 7 Sep 1998 17:27:02 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA11839; Mon, 7 Sep 98 17:22:48 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id OAA25037; Mon, 7 Sep 1998 14:22:46 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id OAA09187; Mon, 7 Sep 1998 14:22:44 -0700 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 07 Sep 1998 14:22:44 -0700 In-Reply-To: Greg Badros's message of "07 Sep 1998 09:02:30 -0700" Message-Id: Lines: 167 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Well we basically have this in the ability for event-maps to have > multiple (possibly merged) parents -- see the description of > make-event-map. OK; I missed the possibility of multiple parents. > > 3) Allow multiple-event sequences. For years I've bemoaned the lack > > of mouse buttons; I would like to rectify that lack by assigning a > > meaning to complex sequences of button clicks. (For example, I could > > bind one action to B1-down B2-down B1-up B2-up, and another to B1-down > > B2-down B2-up B1-up.) I can approximate this with your proposal (by > > binding to the button events separately, and building my own little > > state machine); the part I'm unsure if I can do reliably is to abort > > if another event happens in the middle. (For example, B1-down B2-down > > keypress-escape B1-up B2-up should do nothing. No, I wouldn't > > recommend putting this sort of thing in the default system.scwmrc.) > > Ugh... I'm pretty opposed to complex ordered event sequences. (e.g., I > don't mind lots of modifiers in my left hand + a simple mouse action > with my right hand, but I do mind crazy click sequences in my right > hand). In general, of course, I'm not designing the event model > strictly around things *I* want, but this is one place where I think > that discouraging such bindings is not a bad thing. I think the UI > community would concur with me that such things are evil, and we should > be happy that they're not easy to do within our event model (though > perhaps even happier that they *could* be done). > > > If you do want to allow multiple-event sequences, you could look at Tk > > to see one (fairly clean) implementation of the concept. > > I'll probably take a look at this just to see if they pulled it off > somehow that I can't anticipate. Can you give a more specific pointer > (source files, documentation of the implementation, user-level docs)? The relevant user-level documentation is in the bind manpage (man 3tk bind); in particular, the section "multi-event sequences and ignored events" describes how multi-event bindings are matched against events. The implementation is in tkBind.c:Tk_BindEvent(). > > 4) Allow grabbing the server and reading events. I can think of a > > couple of applications for this. It would let people write their own > > version of interactive-move in scheme, for example (perhaps using > > different keys for the keyboard shortcuts). Here's another example: > > This is one place where my philosophy has differed from GWM-- in GWM, > you could do stuff like grabbing the server which lets you shoot > yourself in the foot from the WOOL (their dialect of Lisp) level. In > Scwm, we've generally raised the level of abstraction sufficiently that > such dangerous primitives are unnecessary. To then go back and provide > those primitives anyway defeats our earlier (well-motivated IMO) > efforts. Making scwm "idiot-proof" is definitely a worthy goal, if you can do it without restricting its power. > > I'd like to be able to set window "bookmarks". I would focus on a > > window, hit Hyper-s ('s' for "set bookmark"), and then press a key; > > this would set a bookmark on the window labeled by that key. > > Subsequently, if I hit Hyper-j ('j' for "jump to bookmark") and then > > press the same key, scwm will jump to that window. > > Ahhh.. good. Thank you for the explicit example -- these are very > helpful to get an idea of your perspective and what you're really > looking for. I think this (and the interactive-move from scheme) are > both doable with non-grab state-based maps. Maybe we need a special > first-level map that has priority over all else? That way, E.g., for > interactive-move, that top level map could be set with the mode-specific > (mode==interactive-move) bindings which would include a binding to exit > the mode (remove the top-level mode-specific map). Similarly for the > window bookmarks (an excellent idea, I think) -- interactive-set-window-bookmark > would set a mode-specific-map where a key-release event was bound to > set-window-bookmark-from-event which would take the key pressed and do > the right thing. > > So, a possible revisions: > > a top-level map that gets dispatched on first (in a sense, implicitly > attached to everything) It's been a while since I've looked at these issues, but I don't think you could implement such a top-level map without grabbing the keyboard and pointer (which is what I should have said before; grabbing the server is a different topic). How about a "universal quit", like control-g in emacs? Say, you can only grab the server or pointer if the keyboard is grabbed as well; and hitting the Escape key always terminates any active grabs (server, pointer, or keyboard). (This approach is valid whether the API is defined as a low-level wrapper around XGrabKey, etc., or whether the API is given in terms of switching globally-overriding event maps in and out.) > IMPORTANT RELATED ISSUE: > > Another point that is worth discussing is how the procedures bound to an > event should get their arguments. As it is in the proposal, a new > procedure is needed for virtually all event bindings because of the > arguments that the procedure gets called with. Emacs gets around this > difficulty with the interactive declaration. I think a similar thing > for Scwm would be highly useful, but I've little experience with the > internals of the Emacs mechanism. w/o such a mechanism, every binding > will be stuck with using a lambda expression to convert event arguments > to parameters for the procedure intended to be bound to the event. Even > if we abstract those patterns, the mapping between the two sets of > arguments would occur at the add-event-binding site, instead of at the > definition of the procedure itself. > > Bottom line is, I think an interactive declaration for procedure > definitions makes a lot of sense, but it's something that I would > probably want to defer to Maciej or another guile/scheme guru. In the > short run, the current model will just cause the add-event-binding calls > to be more long-winded than we might like. If and when interactive > declarations for Scwm work, the event model shouldn't change, we'll just > be able to omit the lambda converting the arguments to what the > procedure's interactive declaration says it wants. "interactive" declarations are one possible approach; another is to provide functions like get-triggering-event, get-triggering-event-map, etc. (There's a question whether you would want to provide just get-triggering-event and then accessors for XEvents, or whether you would want get-triggering-event-type, get-triggering-event-window, get-triggering-event-time, etc.) These functions would return some error value (or signal an error?) if they were called when not in an event callback. -------------------- Yet another event-related topic: How do you handle single- vs. double-click? IMHO, it's important that event-maps with a single-click action and no corresponding double-click action have their action taken as soon as the mouse is clicked, without the current (very annoying) pause to see if it was really a double-click. The interesting question is what to do with event-maps that have both a single-click and double-click binding for the same button; either you do both actions on a double-click, or you wait to make sure it wasn't a double-click before you do the single-click action. You also need to worry about drags. Here, I think you really need to provide both choices. My suggestion would be that make-mouse-event could take: 'press Fires as soon as the button is pressed. 'click Fires when the button is pressed and (quickly) released, with minimal motion between press and release. 'drag Fires when the button is pressed and either a) held without moving (for some length of time) or b) moved more than some threshold 'single-click Fires if the button is clicked, after waiting long enough to make sure it wasn't a double-click 'click-and-drag Fires if the button is clicked, then pressed and either held or moved 'double-click Fires if the button is clicked twice in succession So any sequence of button presses, releases, and motion will be resolved as one of the following sequences of event firings: 'press 'drag 'press 'click 'single-click 'press 'click 'click-and-drag 'press 'click 'double-click Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Sep 7 18:11:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22360 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:11:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22356 for ; Mon, 7 Sep 1998 18:11:11 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03290; Mon, 7 Sep 98 18:06:57 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA14043; Mon, 7 Sep 1998 15:06:54 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 07 Sep 1998 15:06:53 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "07 Sep 1998 14:22:44 -0700" Message-Id: Lines: 151 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > > > If you do want to allow multiple-event sequences, you could look at Tk > > > to see one (fairly clean) implementation of the concept. > > > > I'll probably take a look at this just to see if they pulled it off > > somehow that I can't anticipate. Can you give a more specific pointer > > (source files, documentation of the implementation, user-level docs)? > > The relevant user-level documentation is in the bind manpage (man 3tk > bind); in particular, the section "multi-event sequences and ignored > events" describes how multi-event bindings are matched against > events. The implementation is in tkBind.c:Tk_BindEvent(). Ok, thanks. > > So, a possible revisions: > > > > a top-level map that gets dispatched on first (in a sense, implicitly > > attached to everything) > > It's been a while since I've looked at these issues, but I don't think > you could implement such a top-level map without grabbing the keyboard > and pointer (which is what I should have said before; grabbing the > server is a different topic). Sure, yes. Any binding done on the client window area needs an XGrabKey, and all of that will be managed automatically by Scwm w/o exposing the need to do the XGrabKey (this is the primary implementation challenge, I think, and should be okay). > How about a "universal quit", like control-g in emacs? Say, you can > only grab the server or pointer if the keyboard is grabbed as well; > and hitting the Escape key always terminates any active grabs (server, > pointer, or keyboard). (This approach is valid whether the API is > defined as a low-level wrapper around XGrabKey, etc., or whether the > API is given in terms of switching globally-overriding event maps in > and out.) It'd be great, but how does that keybinding get through to scwm if it's hung in a busy loop of scheme code? If we have a way of dispatching on events even when scheme code is running, then that'd be an option. Or if some secondary process had a grabkey on the universal quit binding and could then send, say, SIGUSR1 to scwm to have it reset, that'd do. I've not thought at all about these issues because I've been trying instead to reduce the scheme code that will run when the server is grabbed (and reduce the grabs, as they are a bad thing anyway, IMO). > > Bottom line is, I think an interactive declaration for procedure > > definitions makes a lot of sense, but it's something that I would > > probably want to defer to Maciej or another guile/scheme guru. In the > > short run, the current model will just cause the add-event-binding calls > > to be more long-winded than we might like. If and when interactive > > declarations for Scwm work, the event model shouldn't change, we'll just > > be able to omit the lambda converting the arguments to what the > > procedure's interactive declaration says it wants. > > "interactive" declarations are one possible approach; another is to > provide functions like get-triggering-event, get-triggering-event-map, > etc. (There's a question whether you would want to provide just > get-triggering-event and then accessors for XEvents, or whether you > would want get-triggering-event-type, get-triggering-event-window, > get-triggering-event-time, etc.) These functions would return some > error value (or signal an error?) if they were called when not in an > event callback. I don't like the global state that such primitives would require. I already am not really ecstatic about the get-window mechanism that is used throughout winops.scm, but I guess I've not really solidified my views on this yet. In any case, we'd still need some way of having the procedure behave differently if it were called interactively than if it is called programattically (i.e., bound to an event vs. invoked directly). > Yet another event-related topic: > > How do you handle single- vs. double-click? IMHO, it's important that > event-maps with a single-click action and no corresponding > double-click action have their action taken as soon as the mouse is > clicked, without the current (very annoying) pause to see if it was > really a double-click. The interesting question is what to do with > event-maps that have both a single-click and double-click binding for > the same button; either you do both actions on a double-click, or you > wait to make sure it wasn't a double-click before you do the > single-click action. You also need to worry about drags. Generally, I think the right thing is for user-behaviours of prefix actions to be unobtrusive to the full action. E.g., it would be very bad to have a single click do a "delete-window" and a double-click do a "raise-window". The reverse would be fine (though silly to be so easy to delete a window w/ just a double clikc) as raising a window before killing it has no harm. So, 'click actions would always be invoked before 'double-click. Similarly with 'press and 'motion (I think we need to add a way to specify no buttons, too, for no-button motion [as opposed to a drag]). > Here, I think you really need to provide both choices. My suggestion > would be that make-mouse-event could take: > > 'press Fires as soon as the button is pressed. > 'click Fires when the button is pressed and (quickly) > released, with minimal motion between press and release. Just to clarify what I was thinking, 'click would not require the minimal motion bit. Maybe it should.... > 'drag Fires when the button is pressed and either > a) held without moving (for some length of time) or > b) moved more than some threshold This is 'motion, roughly. I think in general I'm planning more in terms of the actual X events that get fired instead of adding all sorts of scwm-specific rules on top of the X events > 'single-click Fires if the button is clicked, after waiting long > enough to make sure it wasn't a double-click Anything attached to this event type would suffer the same delay as we currently have that no one likes. > 'click-and-drag Fires if the button is clicked, then pressed and > either held or moved This is too multi-event-like to me. :-) > 'double-click Fires if the button is clicked twice in succession w/i some timeout threshold. > > So any sequence of button presses, releases, and motion will be > resolved as one of the following sequences of event firings: > 'press 'drag > 'press 'click 'single-click > 'press 'click 'click-and-drag > 'press 'click 'double-click Interesting thoughts... some of this stuff can be iterated after we gain experience as they are details (that matter a lot, nonetheless) that won't affect the grand design too much. More comments are definitely welcome.... I have to sleep on some of these ideas to flesh out my thinking. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 7 18:20:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22471 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:20:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22467; Mon, 7 Sep 1998 18:20:28 -0400 Message-Id: <199809072220.SAA22467@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: `focus' does not raise In-reply-to: Your message of "03 Sep 1998 14:54:07 +0200." Date: Mon, 07 Sep 1998 18:20:28 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > have I missed something? At least in cassowary scwm, `(focus win)' > does not raise win anymore. The same is true for `warp-to-window', > this can even result in another window getting the focus (because the > mouse pointer is warped into this other window that is above the given > one. > > The documentation for these procedures does however, not state that > the windows get raised. > > Intentional? IMO warp-to-window and focus should not raise the window as a side effect. As Greg pointed out, it is much easier to add this side effect than remove it. One example I can think of where focusing without raising would be very important is if mouse-focus were to be reimplemented as a hook on the X EnterNotify event, which is probably the right way to do it once it is possible. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 18:28:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22648 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:28:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22645 for ; Mon, 7 Sep 1998 18:28:31 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05471; Mon, 7 Sep 98 18:24:16 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA09574; Tue, 8 Sep 1998 00:23:54 +0200 To: Greg Badros Cc: cwitty@newtonlabs.com (Carl R. Witty), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Sep 1998 00:23:54 +0200 In-Reply-To: Greg Badros's message of "07 Sep 1998 15:06:53 -0700" Message-Id: Lines: 48 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > So, 'click actions would always be invoked before 'double-click. > Similarly with 'press and 'motion (I think we need to add a way to > specify no buttons, too, for no-button motion [as opposed to a drag]). That would break my code: (bind-mouse 'button-2 2 (lambda () (case (mouse-event-type) ((double-click) (horizontal-toggle-double-maximize)) (else (horizontal-toggle-maximize))))) because the toggling would get screwed up. It'd also break move-or-shade: (define (move-or-raise) (case (mouse-event-type) ((motion) (interactive-move)) ((click) (raise-window)))) (define (move-or-shade) (case (mouse-event-type) ((double-click) (toggle-window-shade-animated)) ((motion) (move-or-raise)) (else (if (window-shaded?) (toggle-window-shade-animated) (move-or-raise))))) (bind-mouse 'title 1 move-or-shade) If I double-click, I want the shade to roll up or unroll. I *don't* want to change the level of the window relative to the other windows. Doing the singles before the doubles would be worse than the current pause. I thought that one of the points of the event maps was so that it's easy to wait for a double click only when a double click action has been specified. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Sep 7 18:31:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22726 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:31:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22719; Mon, 7 Sep 1998 18:31:26 -0400 Message-Id: <199809072231.SAA22719@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: cut-buffer revisited... In-reply-to: Your message of "03 Sep 1998 15:23:12 +0200." Date: Mon, 07 Sep 1998 18:31:26 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: >>>>>> On 02 Sep 1998 11:00:13 -0700 >>>>>> Greg Badros said: > > Greg> How do people feel about dynamically linking against Intrinsics > Greg> (i.e., libXt*)? > > I would much prefer to put the scheme-Xt-glue into a dynamic library, > that in turn depends on libXt.so. This would look much the some in > normal scheme usage (just issue `use-modules' - the module is not > scheme source, but a dynamic library). > > This is arguably more work. Providing a fallback for systems without a > guile supporting dynaloading would also be good. > > With this in mind, you could as well implement the normal solution > right away. It can become the fallback when the dynamic solution > is done. Can someone please explain to me why handling of selections and cut buffers from the window manager is useful? I have not yet caught up to the relevant discussion on this list (if any). A specific example would be most helpful. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 18:39:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22915 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:39:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22910 for ; Mon, 7 Sep 1998 18:39:30 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06824; Mon, 7 Sep 98 18:35:16 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA15171; Mon, 7 Sep 1998 15:35:07 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: cwitty@newtonlabs.com (Carl R. Witty), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 07 Sep 1998 15:35:07 -0700 In-Reply-To: hjstein@bfr.co.il's message of "08 Sep 1998 00:23:54 +0200" Message-Id: Lines: 77 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > So, 'click actions would always be invoked before 'double-click. > > Similarly with 'press and 'motion (I think we need to add a way to > > specify no buttons, too, for no-button motion [as opposed to a drag]). > > That would break my code: Well, just to be clear, the new event model will break lots of code. It's not intended to be backward compatible at the code level. More importantly, it sounds like it'll make difficult some of the things you want to be able to express.... that is definitely worth discussing. > > (bind-mouse 'button-2 2 > (lambda () (case (mouse-event-type) > ((double-click) > (horizontal-toggle-double-maximize)) > (else (horizontal-toggle-maximize))))) > > because the toggling would get screwed up. Not sure what the semantics of horizontal-toggle-double-maximize is. What do you mean "get screwed up?" (I just don't understand, not trying to criticize.) > It'd also break move-or-shade: > > (define (move-or-raise) > (case (mouse-event-type) > ((motion) (interactive-move)) > ((click) (raise-window)))) Yep, you're definitely right here. Maybe the higher level abstractions make sense. In fact, 'click really is a scwm-created abstraction -- it happens to correspond to ButtonPress followed by ButtonRelease w/o too much motion or time in between. That seems better. If people want what I was calling a click, they'd use 'release, anyway. > (define (move-or-shade) > (case (mouse-event-type) > ((double-click) (toggle-window-shade-animated)) > ((motion) (move-or-raise)) > (else (if (window-shaded?) > (toggle-window-shade-animated) > (move-or-raise))))) > > (bind-mouse 'title 1 move-or-shade) > > If I double-click, I want the shade to roll up or unroll. I *don't* > want to change the level of the window relative to the other windows. Yep. And as you and Carl are pointing out, the 'click as you want it will fix this. > > Doing the singles before the doubles would be worse than the current > pause. Ah, but I still maintain that a real single click should have an unobtrusive action for the double-click as my previous example regarding delete-window and raise-window tries to outline. Said another way, a double-click should only extend the behaviour of a first click. (The problem with my last response was that it needed to extend the behaviour of a drag, too, which was bad). > I thought that one of the points of the event maps was so that it's > easy to wait for a double click only when a double click action has > been specified. I don't think there should ever be a wait for a double-click. Some people need the double-click interval long enough that it would be really, *really* disturbing. Greg From owner-scwm-discuss@mit.edu Mon Sep 7 18:41:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22988 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:41:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22985 for ; Mon, 7 Sep 1998 18:41:49 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA07115; Mon, 7 Sep 98 18:37:35 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA15436; Mon, 7 Sep 1998 15:37:33 -0700 (PDT) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu, Craig Kaplan Subject: Re: cut-buffer revisited... References: <199809072231.SAA22719@huis-clos.mit.edu> From: Greg Badros Date: 07 Sep 1998 15:37:33 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 07 Sep 1998 18:31:26 EDT" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Can someone please explain to me why handling of selections and > cut buffers from the window manager is useful? I have not yet > caught up to the relevant discussion on this list (if any). > A specific example would be most helpful. Well you can easily imagine someone wishing to find the window with a given name, and instead of requiring that they type in the name, you'd like to be able to let the user highlight the name in an xterm and then hit a scwm binding which does find-highlighted-window using the cut buffer. Craig Kaplan originally posed this question and said he had some plans for the feature if we had it. Perhaps you could elucidate your thoughts, Craig? Greg From owner-scwm-discuss@mit.edu Mon Sep 7 18:48:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23120 for scwm-discuss-outgoing; Mon, 7 Sep 1998 18:48:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23116; Mon, 7 Sep 1998 18:48:31 -0400 Message-Id: <199809072248.SAA23116@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised In-reply-to: Your message of "03 Sep 1998 10:39:08 PDT." Date: Mon, 07 Sep 1998 18:48:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Comments and feedback are appreciated. This is pretty explicit, but > places where I hand wave are legitimate criticisms. Remember, I'm going > to be implementing this stuff, so catching problems or vague areas now > would be a *big* help. I have a lot of specific comments, but I will wait until I can grab a copy of the version with the latest updates for those. However, I have some very definite general comments. In my opinion, there need two be two different interfaces to event bindings, an easy one, and a complete one. The easy one should, of course, be built on top of the complete one. I get the impression that this proposal is trying a bit too hard to satisfy both sets of criteria at once. I will be more specific in my later message, but for now, let me give some design criteria that I'd like to inform the two interfaces, and how I think this is relevant to comments I've seen on the proposal. Easy interface: * Ideally, it should not be much more complicated than the current `bind-key' and `bind-mouse' in the simplest form. In particular, if the user wants to do simple things, he or she should not have to worry about binding events in particular event maps, or about the possible complexities of the underlying handling of modifiers. * Example: When the typical person (myself included) wants to bind Control-x, he doesn't want this to also catch Control-Meta-x, but on the other hand he doesn't want the state of NumLock or ScrollLock to come into it at all. The He also likely doesn't want to have to install an event map on the first left button in order to attach a system menu to it; but this latter Complete interface: * Other than making sure that provisions are made for the easy interface, this interface should strive as much as possible for completeness. * For example, users may want more complicated criteria for modifiers than just "on", "off" and "don't care" sets. For instance, fvwm provides the "A" (Any) pseudo-modifier which is true as long as at least one modifier key is on, and, I believe, other OR-ings of modifier keys. Given this, it should be possible at the very least to bind to a keysym regardless of modifiers, and have some way of getting at the modifiers that were down, to allow for arbitrary filtering on the Scheme level. * As another example, event sequences probably should not be handled directly by the low-level layer, but it should provide enough power to write an `event-sequences' package for scwm, possibly even something like the `strokes.el' package for XEmacs. (I don't think sequences of mouse buttons being pressed up and down are very useful, but sequences of keystrokes definitely are - I might want to use a special prefix for rarely used window manager commands so as not to collide with Netscape). * Another thing I thought of that is important is the ability to introspect about the current bindings for the purposes of interactive help, or just plain helping you remember what keys are being used up by the current configuration. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:09:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23618 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:09:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23611; Mon, 7 Sep 1998 19:09:37 -0400 Message-Id: <199809072309.TAA23611@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu, mst95r@ecs.soton.ac.uk Subject: Re: Maximise window... In-reply-to: Your message of "03 Sep 1998 11:26:28 PDT." Date: Mon, 07 Sep 1998 19:09:36 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > KDE is nice, if a little memory hungry, but I'm against the fact that > > it uses Qt. Twm/fvwm + variations are OK, but are not as configurable > > as I'd like - which is where Scwm rules above all, but again, having > > said that, I've been using it for weeks, and haven't reconfigured much > > at all! > > Well, we try to have it pretty darn useful out of the box (using > .scwmrc-s besides system.scwmrc, though -- we should probably improve > the system.scwmrc to perhaps be one of the others, as it is not nearly > as impressive as it can be (IMHO). When I originally wrote system.scwmrc, I wanted it to be a good, simple base for others to base their configurations on, and simple enough that it would not break too often from all of the massive changes that Scwm was planned to undergo. Perhaps the time has come to make it more impressive. Massive rewrites remain, but I think the ones left will break it anwyay. > > How much integration with Gnome are you planning? > > As much as useful. I'm working right now on porting IceWM's session > manager client support to Scwm. Then we'll be Gnome-compliant (modulo > bugs, of course). We'll support the hints that Gnome-apps provide > (i.e., we'll track Gnome-compliancy), and maybe do more as the Gnome > applications become more widely used and more Gnome users choose Scwm. Personally, there are a few things I'd like to see in addition to basic support. In particular, I'd like to get the guile-gtk support working well (I got it basically working before I went on vacation, but there are many rough spots) and hopefully guile-gnome support as well. This should allow any neat scwm applets (`scwmlets'?) written this way to be Gnome compliant. In other words, you'd have on optional Gnome-compliant GUI scripting system for the desktop built into the window manager. Another thing I'd like to explore is providing the option integrating any future GUI config stuff we do with the Gnome control panel. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:14:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23698 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:14:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23688; Mon, 7 Sep 1998 19:13:56 -0400 Message-Id: <199809072313.TAA23688@huis-clos.mit.edu> To: mst95r@ecs.soton.ac.uk cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest In-reply-to: Your message of "Thu, 03 Sep 1998 20:32:45 BST." <13453.199809031932@penelope.ecs.soton.ac.uk> Date: Mon, 07 Sep 1998 19:13:56 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mst95r@ecs.soton.ac.uk writes: > I like the idea of sound integration (using the esound daemon), but I > don't like the way it can break other sound apps. Generally though, I > only use sounds within apps, such as email, and that can be handled > elsewhere. We'd like to support sound eventually, but as you can probably tell, that's one item on a very big to do list. IMO basic sound support could be handled by calling an external sound player program and providing appropriate hooks to attach sounds to. (Of course, that seems to have spawned a whole other discussion thread). > I like the way virtual desktops work under E (again, prob. more because > of the graphics!) That bit will be tricky to emulate (I assume you mean the fact that you can drag the desktop splitter bar and drag windows from one desktop to another). But if we someday manage a clean way to emulate that without having to hack the core window manager, I think scwm will have achieved a disturbing level of configurability. > - I personally never use a desktop that is larger than > my available screen space (1152x864), and the way (by default?) that > scwm scrolls when the mouse hits the edge irritates me - I keep hitting > it when I go to scroll Netscapes window (always fully maximised). That's the default - it is, of course, configurable. But perhaps system.scwmrc should be revised to reflect general user preferences rather than my own preferences. :-) > Basically the problem is this - while being highly configurable is "the > right thing to do", and I'm quite happy hacking around at files left, > right and center, some control panel for the most common features is > needed. After all, if it's good out of the box, then newbies may use > it, but if it's not configurable without hacking around at the .scwmrc > files, then new users will probably go with something like KDE. > > All very tricky, I know - the problem is that while I want total > control - i.e. I'll edit the files myself, I also want Linux to be more > accessible to new users, without locking them out of class products > like SCWM :) > > A bit of a long winded rant, but there we are, My theory on GUI configurability in it's final complete incarnation is that there should be two separate config files, one that contains hand-written customization commands, and another that is machine-generated by the config tool and therefore guaranteed to contain a subset of the commands that the GUI config tool knows how to parse. Thanks for all of your comments, I love detailed user feedback. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:17:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23760 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:17:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23751; Mon, 7 Sep 1998 19:16:53 -0400 Message-Id: <199809072316.TAA23751@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu, mst95r@ecs.soton.ac.uk Subject: Re: Scwm vs the rest In-reply-to: Your message of "03 Sep 1998 13:33:15 PDT." Date: Mon, 07 Sep 1998 19:16:53 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > BTW I also think image matters but I can't stand the E looks. > Someday someone will design a window manager look that is derived from > clean modern typographic layout/design principles rather than > something from hackers scifi/d&d fantasies (no disrespect raster > :-). Chuck out all the ugly 3D border dross, think minimal and white > space, I even have a name for the theme - gomf (get 'outa my > face). > > Maybe Maciej can co-opt some MIT architecture/design students > to design a look, or maybe the folks in the Aesthetics and > Computation group at the Media Lab http://acg.media.mit.edu/. > Now that would be "cool" :-) Actually, I know a former MIT Architecture major (now Film and Media Studies) who has volunteered to design various themes for scwm once it is slightly less perplexing to do so. I don't know if she's big on the "gomf" esthetic, though. As for the Media Lab, there is a long standing mutual disdain between them and the whole rest of the MIT campus, so I'd rather not try to deal with them :-) - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:19:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23829 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:19:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23825; Mon, 7 Sep 1998 19:19:40 -0400 Message-Id: <199809072319.TAA23825@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Whoops Date: Mon, 07 Sep 1998 19:19:40 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Whoops, I think I just mis-attributed some mail I was replying to on this list (the one about a "get out of my face" window manager theme). I can't check in more detail because I am trapped on a crappy computer right now. My apologies to relevant parties. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:31:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24071 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:31:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24065; Mon, 7 Sep 1998 19:31:05 -0400 Message-Id: <199809072331.TAA24065@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest In-reply-to: Your message of "03 Sep 1998 15:30:22 PDT." Date: Mon, 07 Sep 1998 19:31:04 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > I'm changing system.scwmrc to do something close to this by default. I > still think we should make one of the other .scwmrc-s the system.scwmrc, > but we'd all need to get behind that configuration. I think that instead, a new system.scwmrc should be written mostly from scratch, but with input from numerous people on default key bindings, what features it should use/show off, what setting should be made very easily configurable, and so on. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 7 19:33:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24090 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:33:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24087 for ; Mon, 7 Sep 1998 19:33:03 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA13235; Mon, 7 Sep 98 19:28:48 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA15741; Mon, 7 Sep 1998 16:28:49 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199809072328.QAA15741@fielder.cs.washington.edu> Subject: Re: cut-buffer revisited... To: mstachow@mit.edu (Maciej Stachowiak) Date: Mon, 7 Sep 1998 16:28:49 -0700 (PDT) Cc: robbe@orcus.priv.at, scwm-discuss@mit.edu In-Reply-To: <199809072231.SAA22719@huis-clos.mit.edu> from "Maciej Stachowiak" at Sep 7, 98 06:31:26 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Can someone please explain to me why handling of selections and > cut buffers from the window manager is useful? I have not yet > caught up to the relevant discussion on this list (if any). > A specific example would be most helpful. > > - Maciej Well, to be honest, I never explained _why_ I wanted to get the contents of the cut buffer. I just asked if it was possible. Here are some of the ideas that occur to me: - Netscape can accept a command-line argument that causes it to send a command to a _running_ netscape currently attached to a given X display. So I could have a key binding in the window manager that makes netscape go to the page whose URL is currently stored in the X cut buffer. This would allow me to grab a URL from anywhere (xterm, mail, editor, whatever) and throw it at netscape. This was the original motivation. - It could be used to supply a string "argument" to custom scwm key bindings. I can imagine a "change-title-font" key binding that changed the title font of a window to the font name stored in the cut buffer. This would interact nicely with xfontsel. - A low-overhead version of 'scwmexec': grab some scheme code, hit a key and scwm interprets it. Of course, these could all be done another way. Write a standalone program that gets the cut buffer and does the right thing with it, and have the key binding execute that program. But I thought it would be nice to have the ability to do all this from within scwm. I'm probably ignoring some totally obvious way to do these things without involving scwm, so I welcome your comments. -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Mon Sep 7 19:43:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24295 for scwm-discuss-outgoing; Mon, 7 Sep 1998 19:43:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24292 for ; Mon, 7 Sep 1998 19:43:49 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA14341; Mon, 7 Sep 98 19:39:35 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA15903; Mon, 7 Sep 1998 16:39:36 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199809072339.QAA15903@fielder.cs.washington.edu> Subject: Re: Maximise window... To: mstachow@mit.edu (Maciej Stachowiak) Date: Mon, 7 Sep 1998 16:39:36 -0700 (PDT) Cc: scwm-discuss@mit.edu In-Reply-To: <199809072309.TAA23611@huis-clos.mit.edu> from "Maciej Stachowiak" at Sep 7, 98 07:09:36 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Personally, there are a few things I'd like to see in addition to > basic support. In particular, I'd like to get the guile-gtk support > working well (I got it basically working before I went on vacation, > but there are many rough spots) and hopefully guile-gnome support as > well. This should allow any neat scwm applets (`scwmlets'?) written > this way to be Gnome compliant. In other words, you'd have on optional > Gnome-compliant GUI scripting system for the desktop built into the > window manager. I am anxiously awaiting any sort of stable guile-gtk support in scwm. When I have the ability to bind wm events to teeny little GUIs of my own creation, I will attain window manager nirvana. I'm not too concerned about the Gnome side of things. I just want to be able to script little GUIs inside scwm. I'd be willing to help out, but I disclaim myself by saying that my knowledge of the workings of Guile and Gtk is sadly limited. So many cool ideas, so little time. *sigh* -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Mon Sep 7 20:23:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA24522 for scwm-discuss-outgoing; Mon, 7 Sep 1998 20:23:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA24519 for ; Mon, 7 Sep 1998 20:23:17 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA05924; Mon, 7 Sep 98 20:19:02 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id RAA06728; Mon, 7 Sep 1998 17:19:01 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id RAA09595; Mon, 7 Sep 1998 17:18:59 -0700 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 07 Sep 1998 17:18:58 -0700 In-Reply-To: Greg Badros's message of "07 Sep 1998 15:06:53 -0700" Message-Id: Lines: 167 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > > So, a possible revisions: > > > > > > a top-level map that gets dispatched on first (in a sense, implicitly > > > attached to everything) > > > > It's been a while since I've looked at these issues, but I don't think > > you could implement such a top-level map without grabbing the keyboard > > and pointer (which is what I should have said before; grabbing the > > server is a different topic). > > Sure, yes. Any binding done on the client window area needs an > XGrabKey, and all of that will be managed automatically by Scwm w/o > exposing the need to do the XGrabKey (this is the primary implementation > challenge, I think, and should be okay). I believe that any approach which will allow the user to write a version of interactive-move in scheme will require that the keyboard and pointer be grabbed during the move (and that this grab must start with the button- or key-press that starts the move, to avoid race conditions). > > How about a "universal quit", like control-g in emacs? Say, you can > > only grab the server or pointer if the keyboard is grabbed as well; > > and hitting the Escape key always terminates any active grabs (server, > > pointer, or keyboard). (This approach is valid whether the API is > > defined as a low-level wrapper around XGrabKey, etc., or whether the > > API is given in terms of switching globally-overriding event maps in > > and out.) > > It'd be great, but how does that keybinding get through to scwm if it's > hung in a busy loop of scheme code? If we have a way of dispatching on > events even when scheme code is running, then that'd be an option. Or > if some secondary process had a grabkey on the universal quit binding > and could then send, say, SIGUSR1 to scwm to have it reset, that'd do. > I've not thought at all about these issues because I've been trying > instead to reduce the scheme code that will run when the server is > grabbed (and reduce the grabs, as they are a bad thing anyway, IMO). Granted, if you have scheme code running while the keyboard and pointer are grabbed and it loops, you're screwed. On the other hand, if you have scheme code running while the keyboard and pointer are NOT grabbed and it loops, you're still screwed; so I don't see that the grabs make much difference. :-) Do you think you can actually "reduce the grabs" (what does that mean)? Are there grabs in scwm that are just redundant? I would have guessed that any grabs were in there for a reason, and that removing them would reduce functionality (or at least stability). (By that I mean that you might be able to remove a grab if you're willing to accept new race conditions that "wouldn't happen very often".) > > provide functions like get-triggering-event, get-triggering-event-map, > > etc. (There's a question whether you would want to provide just > > get-triggering-event and then accessors for XEvents, or whether you > > would want get-triggering-event-type, get-triggering-event-window, > > get-triggering-event-time, etc.) These functions would return some > > error value (or signal an error?) if they were called when not in an > > event callback. > > I don't like the global state that such primitives would require. I > already am not really ecstatic about the get-window mechanism that is > used throughout winops.scm, but I guess I've not really solidified my > views on this yet. Fair enough. > > Yet another event-related topic: > > > > How do you handle single- vs. double-click? IMHO, it's important that > > event-maps with a single-click action and no corresponding > > double-click action have their action taken as soon as the mouse is > > clicked, without the current (very annoying) pause to see if it was > > really a double-click. The interesting question is what to do with > > event-maps that have both a single-click and double-click binding for > > the same button; either you do both actions on a double-click, or you > > wait to make sure it wasn't a double-click before you do the > > single-click action. You also need to worry about drags. > > Generally, I think the right thing is for user-behaviours of prefix > actions to be unobtrusive to the full action. E.g., it would be very > bad to have a single click do a "delete-window" and a double-click do a > "raise-window". The reverse would be fine (though silly to be so easy > to delete a window w/ just a double clikc) as raising a window before > killing it has no harm. This is probably a good UI design principle, but I'm not sure it's reasonable to enforce it at such a low level; too many people have favorite sets of bindings which could not be implemented with your approach. > > Here, I think you really need to provide both choices. My suggestion > > would be that make-mouse-event could take: > > > > 'press Fires as soon as the button is pressed. > > 'click Fires when the button is pressed and (quickly) > > released, with minimal motion between press and release. > > Just to clarify what I was thinking, 'click would not require the > minimal motion bit. Maybe it should.... I think you should definitely be able to bind a button so that if you press and release, it raises the window, but if you press and move (or press and hold) it moves the window without raising it. > > 'drag Fires when the button is pressed and either > > a) held without moving (for some length of time) or > > b) moved more than some threshold > > This is 'motion, roughly. I think in general I'm planning more in terms > of the actual X events that get fired instead of adding all sorts of > scwm-specific rules on top of the X events > > > 'single-click Fires if the button is clicked, after waiting long > > enough to make sure it wasn't a double-click > > Anything attached to this event type would suffer the same delay as we > currently have that no one likes. Yes, I know. On the other hand, I've been thinking (and performing experiments on myself :-); I absolutely loathe the delay when I'm bringing up a menu, but I really don't mind the delay when I'm calling (move-or-raise); if I single-click to raise a window, it's OK if it takes an extra 200 milliseconds. > > 'click-and-drag Fires if the button is clicked, then pressed and > > either held or moved > > This is too multi-event-like to me. :-) This is an example of pointless orthogonality; I just thought it was cool that you would always get some other event after a 'click. If you don't do anything, you get 'single-click, if you press and release you get 'double-click, and if you press and hold you get 'click-and-drag. (Although I can certainly imagine binding move to 'drag and resize to 'click-and-drag.) > > 'double-click Fires if the button is clicked twice in succession > > w/i some timeout threshold. > > > > > So any sequence of button presses, releases, and motion will be > > resolved as one of the following sequences of event firings: > > 'press 'drag > > 'press 'click 'single-click > > 'press 'click 'click-and-drag > > 'press 'click 'double-click > > Interesting thoughts... some of this stuff can be iterated after we gain > experience as they are details (that matter a lot, nonetheless) that > won't affect the grand design too much. More comments are definitely > welcome.... I have to sleep on some of these ideas to flesh out my > thinking. > > Thanks, > Greg Sure! Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Sep 7 20:55:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA24710 for scwm-discuss-outgoing; Mon, 7 Sep 1998 20:55:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA24707 for ; Mon, 7 Sep 1998 20:55:07 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA24295; Mon, 7 Sep 98 20:50:51 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id RAA09312; Mon, 7 Sep 1998 17:50:46 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id RAA09677; Mon, 7 Sep 1998 17:50:44 -0700 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 07 Sep 1998 17:50:44 -0700 In-Reply-To: Greg Badros's message of "07 Sep 1998 15:35:07 -0700" Message-Id: Lines: 76 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > (define (move-or-shade) > > (case (mouse-event-type) > > ((double-click) (toggle-window-shade-animated)) > > ((motion) (move-or-raise)) > > (else (if (window-shaded?) > > (toggle-window-shade-animated) > > (move-or-raise))))) > > > > (bind-mouse 'title 1 move-or-shade) > > > > If I double-click, I want the shade to roll up or unroll. I *don't* > > want to change the level of the window relative to the other windows. > > Yep. And as you and Carl are pointing out, the 'click as you want it > will fix this. No, it won't; for this to work, you have to wait for a double-click before doing a single-click action. (Otherwise, a double-click would raise first--which is what move-or-raise does on a single-click--and then toggle window-shading, which is what Harvey said he didn't want to happen.) > > Doing the singles before the doubles would be worse than the current > > pause. > > Ah, but I still maintain that a real single click should have an > unobtrusive action for the double-click as my previous example regarding > delete-window and raise-window tries to outline. Said another way, a > double-click should only extend the behaviour of a first click. (The > problem with my last response was that it needed to extend the behaviour > of a drag, too, which was bad). And I still maintain that enforcing this will break the favored bindings of too many people (including some bindings, as Harvey points out, which are the current default behavior of scwm). (By "break" I mean not that they'll have to change their .scwmrc--I don't mind breaking .scwmrc backward compatibility at this point--but that the behavior they are used to and prefer will be almost impossible to achieve.) BTW, I do agree with you that in principle, it would be better to set up your bindings so that it won't hurt if single-click actions are fired before double-click actions; and I'll probably go through and set up my bindings that way, so that when the Great Event Rewrite happens, I'll be all ready for the snappiest possible no-annoying-pauses scwm experience. So I'm really arguing on behalf of the faceless masses. So, how many people have deep emotional attachments to bindings like move-or-raise, or move-or-shade, or Harvey's horizontal maximize, where doing the single-click action followed by the double-click action on a double-click is The Wrong Thing? (Said emotional attachment could arise, for instance, because you carefully handcrafted the bindings and they do exactly what you want them to; or because you just now finally got yourself trained to use the default scwm bindings--being too lazy to write your own--and you *really* don't want to retrain yourself for another set.) Speak up, or I may stop arguing on your behalf. :-) > > I thought that one of the points of the event maps was so that it's > > easy to wait for a double click only when a double click action has > > been specified. > > I don't think there should ever be a wait for a double-click. Some > people need the double-click interval long enough that it would be > really, *really* disturbing. Then those people should never bind anything to 'single-click (and probably, for their sake, the distributed system.scwmrc shouldn't either). Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Sep 7 23:55:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA25683 for scwm-discuss-outgoing; Mon, 7 Sep 1998 23:55:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA25680 for ; Mon, 7 Sep 1998 23:55:27 -0400 Received: from smtp2.nwnexus.com by MIT.EDU with SMTP id AA16207; Mon, 7 Sep 98 23:51:10 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp2.nwnexus.com (8.8.8/8.8.8) with ESMTP id UAA29530 for ; Mon, 7 Sep 1998 20:51:10 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276553-15944>; Mon, 7 Sep 1998 20:52:12 -0700 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised In-Reply-To: Carl R. Witty's message of "07 Sep 1998 17:50:44 PDT." Date: Mon, 07 Sep 1998 20:51:56 -0600 From: Ken Pizzini Message-Id: <19980908035212Z276553-15944+144@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In , cwitty@newtonlabs.com (Carl R. Witty) said: > So, how many people have deep emotional attachments to bindings like > move-or-raise, or move-or-shade, or Harvey's horizontal maximize, > where doing the single-click action followed by the double-click > action on a double-click is The Wrong Thing? (Said emotional > attachment could arise, for instance, because you carefully > handcrafted the bindings and they do exactly what you want them to; or > because you just now finally got yourself trained to use the default > scwm bindings--being too lazy to write your own--and you *really* > don't want to retrain yourself for another set.) Speak up, or I may > stop arguing on your behalf. :-) I'm fond of being able to use these kinds of bindings. I use a fairly spartan window decoration (just a title bar, no buttons, and a 1-pixel wide frame (just enough to see where the boundary is when two like-colored windows overlap)). Most of my favorite bindings are bound to a Hyper-ed key, but once in a while I want to do something via the mouse. I have my five most-desired window ops set up as mouse events on my title bar. I do this by having simple bindings for buttons 2 and 3, and putting three unrelated operations as different click-styles on button 1, via the following function: (define (move-or-maximize-or-raise) (case (mouse-event-type) ((double-click) (toggle-maximize 0 (%y 100))) (else (move-or-raise)))) (And if we had a "click-then-move" event, I'd add it to the above case statement with an "interactive-resize" binding.) I really would prefer that the "raise" action *only* occur on a single-click event. It is an action which is merely an annoyance, should I have erred in my clicking, as I can always re-lower it, but I really do want it to be distinct from the other two actions during normal use. I also want to have these multiple bindings for title-bar mousing to be modifier-free --- if my hands are in a position where I can easily use modifiers, I'll just use my keyboard shortcuts. These bindings are purely for times when I only have one hand free and need to diddle with my window states, and so I need to have the freedom to overload the three buttons with more than three meanings. --Ken Pizzini From owner-scwm-discuss@mit.edu Tue Sep 8 00:26:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA25892 for scwm-discuss-outgoing; Tue, 8 Sep 1998 00:26:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA25889 for ; Tue, 8 Sep 1998 00:26:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA07360; Tue, 8 Sep 98 00:21:47 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA17670; Mon, 7 Sep 1998 21:21:46 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <199809072331.TAA24065@huis-clos.mit.edu> From: Greg Badros Date: 07 Sep 1998 21:21:45 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 07 Sep 1998 19:31:04 EDT" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > I'm changing system.scwmrc to do something close to this by default. I > > still think we should make one of the other .scwmrc-s the system.scwmrc, > > but we'd all need to get behind that configuration. > > I think that instead, a new system.scwmrc should be written mostly > from scratch, but with input from numerous people on default key > bindings, what features it should use/show off, what setting should > be made very easily configurable, and so on. I think "designed from scratch" makes sense. We can piece together the parts from flux, the *.scwmrc's, and write new code as needed. I think that should probably wait until after the event rewrite, though, as enough stuff will change from that that it's worth waiting. (The decoration rewrite probably will be less obtruive, I'd think). Greg From owner-scwm-discuss@mit.edu Tue Sep 8 00:32:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA25952 for scwm-discuss-outgoing; Tue, 8 Sep 1998 00:32:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA25949 for ; Tue, 8 Sep 1998 00:32:09 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA08095; Tue, 8 Sep 98 00:27:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA17673; Mon, 7 Sep 1998 21:27:51 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 07 Sep 1998 21:27:50 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "07 Sep 1998 17:50:44 -0700" Message-Id: Lines: 94 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > > > (define (move-or-shade) > > > (case (mouse-event-type) > > > ((double-click) (toggle-window-shade-animated)) > > > ((motion) (move-or-raise)) > > > (else (if (window-shaded?) > > > (toggle-window-shade-animated) > > > (move-or-raise))))) > > > > > > (bind-mouse 'title 1 move-or-shade) > > > > > > If I double-click, I want the shade to roll up or unroll. I *don't* > > > want to change the level of the window relative to the other windows. > > > > Yep. And as you and Carl are pointing out, the 'click as you want it > > will fix this. > > No, it won't; for this to work, you have to wait for a double-click > before doing a single-click action. (Otherwise, a double-click would > raise first--which is what move-or-raise does on a single-click--and > then toggle window-shading, which is what Harvey said he didn't want > to happen.) You're right, of course -- I missed the use of move-or-raise. I don't like that binding, then, by my earlier reasoning. :-) Compare with the windowsy binding of maximize (where an implicit raise *does* make sense). > > > Doing the singles before the doubles would be worse than the current > > > pause. > > > > Ah, but I still maintain that a real single click should have an > > unobtrusive action for the double-click as my previous example regarding > > delete-window and raise-window tries to outline. Said another way, a > > double-click should only extend the behaviour of a first click. (The > > problem with my last response was that it needed to extend the behaviour > > of a drag, too, which was bad). > > And I still maintain that enforcing this will break the favored > bindings of too many people (including some bindings, as Harvey points > out, which are the current default behavior of scwm). (By "break" I > mean not that they'll have to change their .scwmrc--I don't mind > breaking .scwmrc backward compatibility at this point--but that the > behavior they are used to and prefer will be almost impossible to > achieve.) Well it'd certainly possible to get those bindings via a timer hook, but the user would have to roll-her-own unless we provided some abstraction of that feature (which could be done outside the scope of the main event mechanisms and perhaps be even more general). > > BTW, I do agree with you that in principle, it would be better to set > up your bindings so that it won't hurt if single-click actions are > fired before double-click actions; and I'll probably go through and > set up my bindings that way, so that when the Great Event Rewrite > happens, I'll be all ready for the snappiest possible > no-annoying-pauses scwm experience. So I'm really arguing on behalf > of the faceless masses. They're not so faceless-- I think a number of people on this list agree with you. > > So, how many people have deep emotional attachments to bindings like > move-or-raise, or move-or-shade, or Harvey's horizontal maximize, > where doing the single-click action followed by the double-click > action on a double-click is The Wrong Thing? (Said emotional > attachment could arise, for instance, because you carefully > handcrafted the bindings and they do exactly what you want them to; or > because you just now finally got yourself trained to use the default > scwm bindings--being too lazy to write your own--and you *really* > don't want to retrain yourself for another set.) Speak up, or I may > stop arguing on your behalf. :-) A call to arms.... :-) > > > > I thought that one of the points of the event maps was so that it's > > > easy to wait for a double click only when a double click action has > > > been specified. > > > > I don't think there should ever be a wait for a double-click. Some > > people need the double-click interval long enough that it would be > > really, *really* disturbing. > > Then those people should never bind anything to 'single-click (and > probably, for their sake, the distributed system.scwmrc shouldn't > either). We'll figure something out that makes everyone happy.... software is one of the few places where that is often possible! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 03:28:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA26958 for scwm-discuss-outgoing; Tue, 8 Sep 1998 03:28:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA26955 for ; Tue, 8 Sep 1998 03:28:29 -0400 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA26797; Tue, 8 Sep 98 03:24:04 EDT Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id JAA20303; Tue, 8 Sep 1998 09:24:03 +0200 (MET DST) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id JAA17201; Tue, 8 Sep 1998 09:23:47 +0200 (MET DST) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13812.56192.713091.59133@chl> Date: Tue, 8 Sep 1998 09:23:44 +0200 (MET DST) To: scwm-discuss@mit.edu Subject: Re: hooks (was Re: Sound support) In-Reply-To: References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> <5logst56az.fsf@tequila.systemsz.cs.yale.edu> <13811.41445.386852.632292@chl> X-Mailer: VM 6.59 under Emacs 20.2.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> Christian Lynbech writes: >> >>>>> "Greg" == Greg Badros writes: >> Greg> ...Imagine if every primitive had a before and after hook;... >> >> That should never be the way to do these things. There should be hooks Greg> Right -- my point was that there was the performance issue in the limit Greg> (of all commands being hookified), and only in the limit do you get the Greg> massive benefits of complete customizability. >> in smart places. Where these place are should be learned over time as >> you suggest yourself. If a more covering hook-up is needed, there >> should be generic hooks akin to emacs' pre- and post-command hooks >> that are invoked all the time, in the apropriate sense. >> >> In fact doing such hooks ins't very difficult. One can use and/or >> extend the existing trace facilty. Tracing works by havings hooks (:-) >> in the evaluator that look out for symbols having a specific >> property. If so (and tracing is enabled), it throws to (something that >> will invoke) the hook function. Greg> We actually do already have a nice way to define and call hooks Greg> from the C code, but they're hard-coded locations, not using Greg> properties of symbols. Just to clarify: having (a moderate number of) hardcoded locations is ok, once we have an idea where those should be. The property based thing was more an example of how to do a generic hook that would be run very often (eg. at every apply), as a general catch-all kind of hook. The point was that we should not have hardcoded hooks with *every* scwm function. only a few hardcoded and (possibly) a very generic. Greg> We (in Scwm) could certainly have primitives check for a hook Greg> property and invoke it -- this solves the plethora of hooks Greg> problem, The idea was not to have specific primitives check for a property (which also would sort of bring us back to the hardcoded locations), but rather to modify the (debugging) evaluator to look for more than just the trace property. Its the ENTER_APPLY macro in libguile/eval.c I am thinking of. All applies are routed through here, and thus would give us a very general hook. Greg> but doesn't address the performance Nothing is free, but the hit would be small (compared to what else is being done already) and would be removed completely by turning off the debugging evaluator. Greg> (perhaps not so bad, but Greg> given that startup of my scwm is already too slow, I'm not very Greg> willing to give much here) and Greg> ability-to-reason-about-a-primitive issues. >> We would then have all scwm functions above a certain level (ie. those >> that would correspond to emacs' commands) come with a certain symbol >> property, and then we would have guile look out for these as >> well. Would take a bit of cooperaton from the guile folks, but should >> be doable. As for performance, this could be turned off via the >> evaluator option interface if not needed. Greg> This seems good, but I'm always hesitant to ask Guile folks for extra Greg> features since I'm *so* much more interested in just seeing 1.3 Greg> released-- I don't want to contribute to the delay in a stable 1.3 Greg> release! :-) I agree completely. But we are not really asking for more features, we are more asking for a generalisation of an existing one (ie. to allow additional properties to be checked in ENTER_APPLY, either through compile time macros, or thorugh a real scheme variable). It could even be that we do not need to change the guile source code at all. The evaluator is a strange and mysterious place, so it could be that the necessary power is already there. Hmm, in fact we can already do it now, by hooking into the trace mechanism. This would interact with desires to do normal tracing, but we could a) work around that and b) the guile that runs scwm is special purpose anyway. Here is some code that I developed in conjunction with a profiler i have been working on. After evaluating (command-start), this will print out a line whenever applying a procedure that has the properties 'trace and 'command being true. (it probably wont work in scwm as it stands, depending on how much of the debugging has been compiled in, but it should work in guile). (define (command-start) (debug-enable 'trace) (set! apply-frame-handler command-enter) (set! exit-frame-handler command-exit)) (define (command-stop) (debug-disable 'trace)) ;;enter and exit has been borrowed from the standard guile trace code. (define (command-enter key cont tail) (if (eq? (stack-id cont) 'repl-stack) (let ((frame (last-stack-frame cont))) (check-hook frame #f))) (debug-enable 'trace)) (define (command-exit key cont retval) (if (eq? (stack-id cont) 'repl-stack) (let ((frame (stack-ref (make-stack #t) 9))) (check-hook frame #t))) (debug-enable 'trace)) (define (check-hook frame exit?) (let* ((proc (and (frame-procedure? frame) (frame-procedure frame)))) (if (procedure-property proc 'command) (display "hey, a command! Run hooks...\n")))) ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Tue Sep 8 05:29:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA27953 for scwm-discuss-outgoing; Tue, 8 Sep 1998 05:29:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA27950 for ; Tue, 8 Sep 1998 05:28:56 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15079; Tue, 8 Sep 98 05:24:32 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA12571; Tue, 8 Sep 1998 11:24:13 +0200 To: cwitty@newtonlabs.com (Carl R. Witty) Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Sep 1998 11:24:13 +0200 In-Reply-To: cwitty@newtonlabs.com's message of "07 Sep 1998 17:18:58 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > Granted, if you have scheme code running while the keyboard and > pointer are grabbed and it loops, you're screwed. On the other hand, > if you have scheme code running while the keyboard and pointer are NOT > grabbed and it loops, you're still screwed; so I don't see that the > grabs make much difference. :-) Isn't the difference that if everything is grabbed then control-alt-backspace won't kill X & control-alt-f1 won't switch to a console so you'll have to telnet in & kill it by hand? If you don't have another machine on the same net (as in a home machine), then you'll have to just hit the power switch. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 8 05:29:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA27967 for scwm-discuss-outgoing; Tue, 8 Sep 1998 05:29:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA27964 for ; Tue, 8 Sep 1998 05:29:45 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15114; Tue, 8 Sep 98 05:25:22 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA12555; Tue, 8 Sep 1998 11:21:26 +0200 To: Greg Badros Cc: cwitty@newtonlabs.com (Carl R. Witty), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 08 Sep 1998 11:21:26 +0200 In-Reply-To: Greg Badros's message of "07 Sep 1998 15:35:07 -0700" Message-Id: Lines: 91 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Greg Badros writes: > > > > > So, 'click actions would always be invoked before 'double-click. > > > Similarly with 'press and 'motion (I think we need to add a way to > > > specify no buttons, too, for no-button motion [as opposed to a drag]). > > > > That would break my code: > > Well, just to be clear, the new event model will break lots of code. > It's not intended to be backward compatible at the code level. More > importantly, it sounds like it'll make difficult some of the things you > want to be able to express.... that is definitely worth discussing. I don't mean break as in requiring rewrite. I mean break as in making it almost impossible to code the desired behavior in a reasonable manner. Stuffing in timer hooks to get what I want is *not* reasonable. > > (bind-mouse 'button-2 2 > > (lambda () (case (mouse-event-type) > > ((double-click) > > (horizontal-toggle-double-maximize)) > > (else (horizontal-toggle-maximize))))) > > > > because the toggling would get screwed up. > > Not sure what the semantics of horizontal-toggle-double-maximize is. > What do you mean "get screwed up?" (I just don't understand, not trying > to criticize.) (define (horizontal-toggle-double-maximize) (toggle-maximize (%x 200) 0)) The idea is that click toggles btw current width & viewport width. double click toggles between current width & 2x viewport width. If click always fires before doubleclick then double clicking won't toggle back. It'll have the wrong parity. I guess I could fix this by doing the horizontal-toggle-double-maximize twice in the case of a double click, but I don't consider this reasonable. > > It'd also break move-or-shade: > > > > (define (move-or-raise) > > (case (mouse-event-type) > > ((motion) (interactive-move)) > > ((click) (raise-window)))) > > Yep, you're definitely right here. Maybe the higher level abstractions > make sense. In fact, 'click really is a scwm-created abstraction -- it > happens to correspond to ButtonPress followed by ButtonRelease w/o too > much motion or time in between. That seems better. If people want what > I was calling a click, they'd use 'release, anyway. I think the following would give sufficiently rich & intuitive semantics for everyone: 1. Allow binding of buttonpress, buttonrelease, click & double-click. 2. Buttonpress & buttonrelease always happen immediately (when they're defined). 3. Click is buttonpress followed by buttonrelease in the same context. 4. Doubleclick is two clicks separated by at most some user configurable delay. 5. Click fires off immediately if there's no doubleclick action. If you have event maps then it's easy to see if there's a doubleclick action for the same context, so the above shouldn't be hard to do. The problem with the current implementation is that the event differentiation is in user code, so it's impossible to see if there's a doubleclick action for a given context. > Ah, but I still maintain that a real single click should have an > unobtrusive action for the double-click as my previous example regarding > delete-window and raise-window tries to outline. Said another way, a > double-click should only extend the behaviour of a first click. (The > problem with my last response was that it needed to extend the behaviour > of a drag, too, which was bad). So you're saying that you think it's bad UI design & therefore won't allow scwm to do it? I thought the idea was that scwm would be configurable enough to allow everyone to do whatever they want to do. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 8 07:13:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA28478 for scwm-discuss-outgoing; Tue, 8 Sep 1998 07:13:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA28475 for ; Tue, 8 Sep 1998 07:13:39 -0400 Received: from anusf.anu.edu.au by MIT.EDU with SMTP id AA09786; Tue, 8 Sep 98 07:09:18 EDT Received: from brett.anu.edu.au. (brett [150.203.5.55]) by anusf.anu.edu.au (8.8.6/8.8.6) with ESMTP id VAA20353 for ; Tue, 8 Sep 1998 21:09:13 +1000 (EST) Received: (from drw900@localhost) by brett.anu.edu.au. (8.8.5/8.8.5) id VAA01313; Tue, 8 Sep 1998 21:09:15 +1000 (EST) To: scwm-discuss@mit.edu Subject: Re: Whoops References: <199809072319.TAA23825@huis-clos.mit.edu> From: Drew Whitehouse In-Reply-To: Maciej Stachowiak's message of "Mon, 07 Sep 1998 19:19:40 EDT" Date: 08 Sep 1998 21:09:15 +1000 Message-Id: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: Maciej> Whoops, I think I just mis-attributed some mail I was Maciej> replying to on this list (the one about a "get out of my Maciej> face" window manager theme). I can't check in more detail Maciej> because I am trapped on a crappy computer right now. My Maciej> apologies to relevant parties. No worries ;-) While I'm at it - when you guys get around to looking at allowing customisability of decoration, one possibility might be to use the new canvas widgets that are being written for gtk/gnome at the moment. Then windows could be placed on the canvas which would be on the root window and code be attached to each window that would could the drawing of decoration. This would be ultra configurable. With Raph Levien's gtk_caanvas you could even have full anti-aliased drawing of borders and text labels and maybe even semi-transparent decoration where you could see through to the windows beneath. That would probably be a first, at least for X windows. See http://www.levien.com/gfonted/ and the gnome-libs canvas widget. -Drew -- ;; mailto:Drew.Whitehouse@anu.edu.au http://anusf.anu.edu.au/~drw900/ ;; Viz programmer, Australian National University Supercomputer Facility From owner-scwm-discuss@mit.edu Tue Sep 8 09:46:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA29368 for scwm-discuss-outgoing; Tue, 8 Sep 1998 09:46:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA29362 for ; Tue, 8 Sep 1998 09:45:59 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA08086; Tue, 8 Sep 98 09:41:36 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA00159; Tue, 8 Sep 98 09:41:30 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Tue, 08 Sep 1998 09:41:35 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Tue, 08 Sep 1998 09:41:35 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id JAA12921; Tue, 8 Sep 1998 09:41:34 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Sep 1998 16:49:08 -0700" Date: 08 Sep 1998 09:41:34 -0400 Message-Id: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Sep 1998 16:49:08 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Documenting irregular user-option variables": >> >> /**OPTION: shadow-factor */ I would think this to be an unnecessary constraint. For real options (true variables) we could use /**OPTION: true-variable */ for "pseudo-variables" I would suggest /**OPTION: (set-variable! . get-variable) */ this would seem to make extraction easier. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Tue Sep 8 11:19:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29806 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:19:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29803 for ; Tue, 8 Sep 1998 11:19:16 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA20066; Tue, 8 Sep 98 11:14:48 EDT Received: by tis.bellhow.com; id LAA10884; Tue, 8 Sep 1998 11:14:41 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma010843; Tue, 8 Sep 98 11:14:30 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA14409 for ; Tue, 8 Sep 1998 11:14:30 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot Date: Tue, 08 Sep 1998 15:14:29 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f5496e.80475617@smtp> References: <35f200f7.353730046@smtp> In-Reply-To: <35f200f7.353730046@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA29804 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Fri, 04 Sep 1998 15:23:06 GMT, you wrote: >A couple of problems with the 1998 09 04 snapshot. > >The file `session-manager.c' either shouldn't be built if you >don't have the IceWM (like the cassowary stuff is), or wrapped >with `#ifdef HAVE_LIBSM_LIBICE'. I used the ifdef. > >libtool was complaining about not knowing the `-o' option when >linking scwm!! Turns out CXX wasn't defined in the Makefile. >I set it to `g++' and the compile finished. I think this is >because I'm not using cassowary? (not compiling c++) This stuff works great in the 9/8 snapshot. Thanks! Dale From owner-scwm-discuss@mit.edu Tue Sep 8 11:27:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29899 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:27:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29896 for ; Tue, 8 Sep 1998 11:27:01 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA22914; Tue, 8 Sep 98 11:22:38 EDT Received: by tis.bellhow.com; id LAA12637; Tue, 8 Sep 1998 11:22:39 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma012434; Tue, 8 Sep 98 11:21:41 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id LAA14733 for ; Tue, 8 Sep 1998 11:21:41 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot Date: Tue, 08 Sep 1998 15:21:41 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f649d9.80582942@smtp> References: <35f200f7.353730046@smtp> In-Reply-To: <35f200f7.353730046@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id LAA29897 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Fri, 04 Sep 1998 15:23:06 GMT, you wrote: >If I have the time I'm going to see what's going on with the pager. I found the problem with scrolling the viewport. The args are % of display size, not pixels. The patch below seems to work. I'm not sure if inexact->exact is right thing to do here. Can someone with more wisdom look at this? Dale *** scheme/fvwm-eval.scm Tue Sep 8 11:10:33 1998 --- /home/users10/smithd/share/scwm-modules/app/scwm/fvwm-eval.scm Tue Sep 8 11:10:58 1998 *************** *** 117,123 **** (raise-window))) (define-fvwm-command "Scroll" ! (get-two-numeric-args args move-viewport)) (define-fvwm-command "Send_ConfigInfo" ((caddr fmod))) --- 117,128 ---- (raise-window))) (define-fvwm-command "Scroll" ! (get-two-numeric-args ! args ! (lambda (x y) ! (move-viewport ! (inexact->exact (/ (* x display-width) 100)) ! (inexact->exact (/ (* y display-height) 100)))))) (define-fvwm-command "Send_ConfigInfo" ((caddr fmod))) From owner-scwm-discuss@mit.edu Tue Sep 8 11:28:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29941 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:28:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29938 for ; Tue, 8 Sep 1998 11:28:26 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23472; Tue, 8 Sep 98 11:24:04 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19199; Tue, 8 Sep 1998 08:23:54 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: From: Greg Badros Date: 08 Sep 1998 08:23:54 -0700 In-Reply-To: Sam Steingold's message of "08 Sep 1998 09:41:34 -0400" Message-Id: Lines: 36 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 06 Sep 1998 16:49:08 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Documenting irregular user-option variables": > >> > >> /**OPTION: shadow-factor */ > > I would think this to be an unnecessary constraint. Sure it's unnecessary.... but it could be a good convention in that a given option has an obvious setter and getter function, and we'd get a warning if they weren't written or misspelled or whatever. > > For real options (true variables) we could use > > /**OPTION: true-variable */ > > for "pseudo-variables" I would suggest > > /**OPTION: (set-variable! . get-variable) */ > > this would seem to make extraction easier. And then assume the option name is the getter function name? (Just asking). I suppose we could still provide a warning at extraction time if the setter and the getter didn't look sufficiently related (it is my mission in life to catch all cut and paste errors! :-) ). I'm still not convinced that the restriction isn't useful for software-engineering reasons. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 11:34:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30052 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:34:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30049 for ; Tue, 8 Sep 1998 11:34:37 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19066; Tue, 8 Sep 98 11:30:11 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19208; Tue, 8 Sep 1998 08:29:54 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: cwitty@newtonlabs.com (Carl R. Witty), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 08 Sep 1998 08:29:54 -0700 In-Reply-To: hjstein@bfr.co.il's message of "08 Sep 1998 11:24:13 +0200" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Isn't the difference that if everything is grabbed then > control-alt-backspace won't kill X & control-alt-f1 won't switch to a > console so you'll have to telnet in & kill it by hand? If you don't > have another machine on the same net (as in a home machine), then > you'll have to just hit the power switch. I don't think this is the case -- when the server (which is what I assume you mean by everything) is grabbed, those XFree86 keybindings will still work. Only the server stops redrawing, only that process's window(s) receive events, etc. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 11:44:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30268 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:44:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30265 for ; Tue, 8 Sep 1998 11:44:01 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA29642; Tue, 8 Sep 98 11:39:39 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19211; Tue, 8 Sep 1998 08:39:26 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: cwitty@newtonlabs.com (Carl R. Witty), scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 08 Sep 1998 08:39:26 -0700 In-Reply-To: hjstein@bfr.co.il's message of "08 Sep 1998 11:21:26 +0200" Message-Id: Lines: 105 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I don't mean break as in requiring rewrite. I mean break as in making > it almost impossible to code the desired behavior in a reasonable > manner. Stuffing in timer hooks to get what I want is *not* > reasonable. But it would be if we had a sugar to do that for you, right? Timer hooks may be the right implementation technique instead of a ms_sleep which is a bit too synchronous. > > > (bind-mouse 'button-2 2 > > > (lambda () (case (mouse-event-type) > > > ((double-click) > > > (horizontal-toggle-double-maximize)) > > > (else (horizontal-toggle-maximize))))) > > > > > > because the toggling would get screwed up. > > > > Not sure what the semantics of horizontal-toggle-double-maximize is. > > What do you mean "get screwed up?" (I just don't understand, not trying > > to criticize.) > > (define (horizontal-toggle-double-maximize) > (toggle-maximize (%x 200) 0)) > > The idea is that click toggles btw current width & viewport width. > double click toggles between current width & 2x viewport width. If > click always fires before doubleclick then double clicking won't > toggle back. It'll have the wrong parity. I guess I could fix this > by doing the horizontal-toggle-double-maximize twice in the case of a > double click, but I don't consider this reasonable. Wacky... what is your intended behaviour double-clicking on a singly-maximized window? Revert to original size? > > > It'd also break move-or-shade: > > > > > > (define (move-or-raise) > > > (case (mouse-event-type) > > > ((motion) (interactive-move)) > > > ((click) (raise-window)))) > > > > Yep, you're definitely right here. Maybe the higher level abstractions > > make sense. In fact, 'click really is a scwm-created abstraction -- it > > happens to correspond to ButtonPress followed by ButtonRelease w/o too > > much motion or time in between. That seems better. If people want what > > I was calling a click, they'd use 'release, anyway. > > I think the following would give sufficiently rich & intuitive > semantics for everyone: > > 1. Allow binding of buttonpress, buttonrelease, click & double-click. > 2. Buttonpress & buttonrelease always happen immediately (when > they're defined). > 3. Click is buttonpress followed by buttonrelease in the same > context. > 4. Doubleclick is two clicks separated by at most some user > configurable delay. > 5. Click fires off immediately if there's no doubleclick action. > > If you have event maps then it's easy to see if there's a doubleclick > action for the same context, so the above shouldn't be hard to do. Yes, it is easy, but perhaps harder than you're thinking -- remember there are arbitrarily many parents each with arbitrary many parents, etc. In practice the number of bindings should make this no big deal, but it does require a search of the whole n-ary tree rooted at the current event map. > The problem with the current implementation is that the event > differentiation is in user code, so it's impossible to see if there's > a doubleclick action for a given context. Right -- this is how Scwm differs unfavorably from Fvwm2. > > Ah, but I still maintain that a real single click should have an > > unobtrusive action for the double-click as my previous example regarding > > delete-window and raise-window tries to outline. Said another way, a > > double-click should only extend the behaviour of a first click. (The > > problem with my last response was that it needed to extend the behaviour > > of a drag, too, which was bad). > > So you're saying that you think it's bad UI design & therefore won't > allow scwm to do it? I thought the idea was that scwm would be > configurable enough to allow everyone to do whatever they want to do. Not quite -- I was suggesting it's bad UI design so we'd stick with a mental and implementation model that supports better UI design and more closely reflects the physical model (of X11 which was designed by some brainy folks) for simplicity and elegance of implementation. I like your (collective you) proposal. It needs of allowing a binding to a single click and a double click where the single click action is decidedly unobtrusive, though (i.e., I shouldn't have to pay the price of the 100ms [or whatever] delay to verify that a click isn't a double-click if my single-click action can be safely executed before the double-click action). This goes back to the earlier suggestion (Carl's?) of 'click executing right away, and 'single-click executing only after it'd decidedly not a double-click. Then I can bind my prefix-safe callbacks to 'click, and you can bind your prefix-unsafe (i.e. once not to be invoked in case of a double-click) to 'single-click. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 11:53:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30447 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:53:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30444 for ; Tue, 8 Sep 1998 11:53:39 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03257; Tue, 8 Sep 98 11:49:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19224; Tue, 8 Sep 1998 08:49:11 -0700 (PDT) To: Christian Lynbech Cc: scwm-discuss@mit.edu Subject: Re: hooks (was Re: Sound support) References: <13453.199809031932@penelope.ecs.soton.ac.uk> <"MoNuC3.0.D73.Ardyr"@tequila.systemsz.cs.yale.edu> <5logst56az.fsf@tequila.systemsz.cs.yale.edu> <13811.41445.386852.632292@chl> <13812.56192.713091.59133@chl> From: Greg Badros Date: 08 Sep 1998 08:49:10 -0700 In-Reply-To: Christian Lynbech's message of "Tue, 8 Sep 1998 09:23:44 +0200 (MET DST)" Message-Id: Lines: 84 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Christian Lynbech writes: > Greg> We actually do already have a nice way to define and call hooks > Greg> from the C code, but they're hard-coded locations, not using > Greg> properties of symbols. > > Just to clarify: having (a moderate number of) hardcoded locations is > ok, once we have an idea where those should be. The property based > thing was more an example of how to do a generic hook that would be > run very often (eg. at every apply), as a general catch-all kind of > hook. > > The point was that we should not have hardcoded hooks with *every* > scwm function. only a few hardcoded and (possibly) a very generic. Sounds good. We have the few hardcoded, but right now too few because we're erring on the side of conservatism. (As I've written before, I'm still concerned about the lack of being able to reason about primitives which invoke callbacks left and right, but procedures should be able to invoke hooks as is useful-- maybe we need to expose a call-hooks procedure or primitive for use at the scheme level (the C function is already written for invoking hooks from C code). > Greg> We (in Scwm) could certainly have primitives check for a hook > Greg> property and invoke it -- this solves the plethora of hooks > Greg> problem, > > The idea was not to have specific primitives check for a property > (which also would sort of bring us back to the hardcoded locations), > but rather to modify the (debugging) evaluator to look for more than > just the trace property. Its the ENTER_APPLY macro in libguile/eval.c > I am thinking of. All applies are routed through here, and thus would > give us a very general hook. > > Greg> but doesn't address the performance > > Nothing is free, but the hit would be small (compared to what else is > being done already) and would be removed completely by turning off the > debugging evaluator. My question was as to whether the debugging evaluator solution would be faster than the hard coded one -- are there shortcuts it could take. Though I like the fact that I could regain all the performance back by switching the generalized hook mechanism off, that that can be done implies that the generalized hook stuff couldn't be relied on for regular functionality and would more just be an interim hack in need of replacement by a real hook or advice or something. > Greg> features since I'm *so* much more interested in just seeing 1.3 > Greg> released-- I don't want to contribute to the delay in a stable 1.3 > Greg> release! :-) > > I agree completely. > > But we are not really asking for more features, we are more asking for > a generalisation of an existing one (ie. to allow additional > properties to be checked in ENTER_APPLY, either through compile time > macros, or thorugh a real scheme variable). It could even be that we > do not need to change the guile source code at all. The evaluator is a > strange and mysterious place, so it could be that the necessary power > is already there. > > Hmm, in fact we can already do it now, by hooking into the trace > mechanism. This would interact with desires to do normal tracing, but > we could a) work around that and b) the guile that runs scwm is > special purpose anyway. > > Here is some code that I developed in conjunction with a profiler i > have been working on. After evaluating (command-start), this will > print out a line whenever applying a procedure that has the properties > 'trace and 'command being true. > > (it probably wont work in scwm as it stands, depending on how much of > the debugging has been compiled in, but it should work in guile). We'll have to try this out... your ideas are good, and it's definitely worth opening up communication with the guile folks on this one. As time permits, could you bring it up on the guile list (feel free to quote my messages, if any, as useful). They might also have some good ideas as this is a general issue with guile and scheme extensibility. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 11:56:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30504 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:56:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30501 for ; Tue, 8 Sep 1998 11:56:31 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA27933; Tue, 8 Sep 98 11:52:11 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19227; Tue, 8 Sep 1998 08:52:03 -0700 (PDT) To: Drew Whitehouse Cc: scwm-discuss@mit.edu Subject: Re: Whoops References: <199809072319.TAA23825@huis-clos.mit.edu> From: Greg Badros Date: 08 Sep 1998 08:52:02 -0700 In-Reply-To: Drew Whitehouse's message of "08 Sep 1998 21:09:15 +1000" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Drew Whitehouse writes: > configurable. With Raph Levien's gtk_caanvas you could even have full > anti-aliased drawing of borders and text labels and maybe even > semi-transparent decoration where you could see through to the windows > beneath. That would probably be a first, at least for X windows. This would require an X windows server extension, I think. Otherwise the window with the semi-transparent decoration would have to continually re-merge in the partial contents of the windows behind it which obviously is computationally infeasible. We could have semi-transparent decorations which partially obscured our client window, but not the other top level windows on the same display. > See http://www.levien.com/gfonted/ and the gnome-libs canvas > widget. Cool, thanks for the pointer.... Greg From owner-scwm-discuss@mit.edu Tue Sep 8 11:57:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30550 for scwm-discuss-outgoing; Tue, 8 Sep 1998 11:57:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30546 for ; Tue, 8 Sep 1998 11:57:39 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28364; Tue, 8 Sep 98 11:53:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19233; Tue, 8 Sep 1998 08:53:10 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> <35f5496e.80475617@smtp> From: Greg Badros Date: 08 Sep 1998 08:53:10 -0700 In-Reply-To: smithd@bellhow.com's message of "Tue, 08 Sep 1998 15:14:29 GMT" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On Fri, 04 Sep 1998 15:23:06 GMT, you wrote: > > >A couple of problems with the 1998 09 04 snapshot. > > > >The file `session-manager.c' either shouldn't be built if you > >don't have the IceWM (like the cassowary stuff is), or wrapped > >with `#ifdef HAVE_LIBSM_LIBICE'. I used the ifdef. > > > >libtool was complaining about not knowing the `-o' option when > >linking scwm!! Turns out CXX wasn't defined in the Makefile. > >I set it to `g++' and the compile finished. I think this is > >because I'm not using cassowary? (not compiling c++) > > > This stuff works great in the 9/8 snapshot. Thanks! Great. Thanks for the report! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 12:36:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA30921 for scwm-discuss-outgoing; Tue, 8 Sep 1998 12:36:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA30913 for ; Tue, 8 Sep 1998 12:36:00 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA18056; Tue, 8 Sep 98 12:31:33 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA10283; Tue, 8 Sep 98 12:31:33 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Tue, 08 Sep 1998 12:31:40 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Tue, 08 Sep 1998 12:31:39 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id MAA14159; Tue, 8 Sep 1998 12:31:39 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "08 Sep 1998 08:23:54 -0700" Date: 08 Sep 1998 12:31:39 -0400 Message-Id: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 08 Sep 1998 08:23:54 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documenting irregular user-option variables": >> Sam Steingold writes: >> >> And then assume the option name is the getter function name? ouch! didn't think about it. you are right, your way is the correct one. So the semantics will be as follows: each element of `user-options' is a symbol, its `documentation' will be displayed as "help". if there is a symbol set-!, its value must be a function (and 's value must be a function too) and they will be used as getters/setters. if there is no symbol set-!, the symbol is assumed to be a simple variable. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Microsoft: announce yesterday, code today, think tomorrow. From owner-scwm-discuss@mit.edu Tue Sep 8 12:41:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA31044 for scwm-discuss-outgoing; Tue, 8 Sep 1998 12:41:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA31041 for ; Tue, 8 Sep 1998 12:41:37 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14575; Tue, 8 Sep 98 12:37:16 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA19290; Tue, 8 Sep 1998 09:37:15 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: From: Greg Badros Date: 08 Sep 1998 09:37:15 -0700 In-Reply-To: Sam Steingold's message of "08 Sep 1998 12:31:39 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> Honorable Greg Badros writes > >> And then assume the option name is the getter function name? > > ouch! didn't think about it. > you are right, your way is the correct one. > > So the semantics will be as follows: > each element of `user-options' is a symbol, its `documentation' will be > displayed as "help". if there is a symbol set-!, its value must be > a function (and 's value must be a function too) and they will be > used as getters/setters. if there is no symbol set-!, the symbol is > assumed to be a simple variable. That seems ok with me... I'll make user-options.scm define user-options as a list of lists, each of which looks-like: '(option-var-name "Documentation summary (one sentence)." "Rest of documentation (excluding the first sentence) -- this is longer, possibly, or may be the empty string of the summary is sufficient") (I'm splitting the docs into two strings, and dropping the two setter/getter function symbols since the convention makes it implicit.) Greg From owner-scwm-discuss@mit.edu Tue Sep 8 12:47:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA31136 for scwm-discuss-outgoing; Tue, 8 Sep 1998 12:47:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA31133 for ; Tue, 8 Sep 1998 12:47:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA21708; Tue, 8 Sep 98 12:43:11 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA19297; Tue, 8 Sep 1998 09:43:09 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> <35f649d9.80582942@smtp> From: Greg Badros Date: 08 Sep 1998 09:43:08 -0700 In-Reply-To: smithd@bellhow.com's message of "Tue, 08 Sep 1998 15:21:41 GMT" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On Fri, 04 Sep 1998 15:23:06 GMT, you wrote: > > >If I have the time I'm going to see what's going on with the pager. > > I found the problem with scrolling the viewport. The args are % of > display size, not pixels. The patch below seems to work. I'm not > sure if inexact->exact is right thing to do here. Can someone with > more wisdom look at this? Looks pretty close, except you can use the %x and %y procs from base.scm: (define-public (%x x) "Return the number of pixels that is X percent of the display width." (inexact->exact (truncate (/ (* x display-width) 100)))) (define-public (%y y) "Return the number of pixels that is Y percent of the display height." (inexact->exact (truncate (/ (* y display-height) 100)))) Thanks for the detective work... I'll make the change in the repo today. Please verify that it behaves as your patch does. Thanks! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 13:02:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31323 for scwm-discuss-outgoing; Tue, 8 Sep 1998 13:02:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31320 for ; Tue, 8 Sep 1998 13:02:07 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA26790; Tue, 8 Sep 98 12:57:45 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA15211; Tue, 8 Sep 98 12:57:45 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Tue, 08 Sep 1998 12:57:52 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Tue, 08 Sep 1998 12:57:51 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id MAA14224; Tue, 8 Sep 1998 12:57:51 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "08 Sep 1998 09:37:15 -0700" Date: 08 Sep 1998 12:57:50 -0400 Message-Id: Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 08 Sep 1998 09:37:15 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documenting irregular user-option variables": >> > So the semantics will be as follows: >> > each element of `user-options' is a symbol, its `documentation' will be >> > displayed as "help". if there is a symbol set-!, its value must be >> > a function (and 's value must be a function too) and they will be >> > used as getters/setters. if there is no symbol set-!, the symbol is >> > assumed to be a simple variable. >> >> That seems ok with me... I'll make user-options.scm define user-options >> as a list of lists, each of which looks-like: >> >> '(option-var-name "Documentation summary (one sentence)." "Rest of >> documentation (excluding the first sentence) -- this is longer, >> possibly, or may be the empty string of the summary is sufficient") >> >> (I'm splitting the docs into two strings, and dropping the two >> setter/getter function symbols since the convention makes it implicit.) I would strongly stand for keeping all docs in one place - documentation.txt, accessible with the scheme function `documentation'. One line summary sound nice, but I am not sure how to use it. The name should be descriptive enough, and everything else will come from the full docs. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The program isn't debugged until the last user is dead. From owner-scwm-discuss@mit.edu Tue Sep 8 13:11:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31439 for scwm-discuss-outgoing; Tue, 8 Sep 1998 13:11:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31436 for ; Tue, 8 Sep 1998 13:11:09 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA29615; Tue, 8 Sep 98 13:06:40 EDT Received: by tis.bellhow.com; id NAA05626; Tue, 8 Sep 1998 13:06:41 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma005524; Tue, 8 Sep 98 13:06:14 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id NAA18251 for ; Tue, 8 Sep 1998 13:06:14 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot Date: Tue, 08 Sep 1998 17:06:14 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f762e7.86996724@smtp> References: <35f200f7.353730046@smtp> <35f649d9.80582942@smtp> In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id NAA31437 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 08 Sep 1998 09:43:08 -0700, you wrote: >> Can someone with >> more wisdom look at this? > >Looks pretty close, except you can use the %x and %y procs from base.scm: Cool! Never looked at those before. > Please verify that it behaves as your patch does. If it looks like: (define-fvwm-command "Scroll" (get-two-numeric-args args (lambda (x y) (move-viewport (%x x) (%y y))))) it works great. Thanks! Dale From owner-scwm-discuss@mit.edu Tue Sep 8 13:10:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31428 for scwm-discuss-outgoing; Tue, 8 Sep 1998 13:10:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31425 for ; Tue, 8 Sep 1998 13:10:07 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24100; Tue, 8 Sep 98 13:05:37 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA19395; Tue, 8 Sep 1998 10:05:36 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: From: Greg Badros Date: 08 Sep 1998 10:05:35 -0700 In-Reply-To: Sam Steingold's message of "08 Sep 1998 12:57:50 -0400" Message-Id: Lines: 50 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 08 Sep 1998 09:37:15 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Re: Documenting irregular user-option variables": > >> > So the semantics will be as follows: > >> > each element of `user-options' is a symbol, its `documentation' will be > >> > displayed as "help". if there is a symbol set-!, its value must be > >> > a function (and 's value must be a function too) and they will be > >> > used as getters/setters. if there is no symbol set-!, the symbol is > >> > assumed to be a simple variable. > >> > >> That seems ok with me... I'll make user-options.scm define user-options > >> as a list of lists, each of which looks-like: > >> > >> '(option-var-name "Documentation summary (one sentence)." "Rest of > >> documentation (excluding the first sentence) -- this is longer, > >> possibly, or may be the empty string of the summary is sufficient") > >> > >> (I'm splitting the docs into two strings, and dropping the two > >> setter/getter function symbols since the convention makes it implicit.) > > I would strongly stand for keeping all docs in one place - > documentation.txt, accessible with the scheme function `documentation'. How about scwm-variables.txt to augment scwm-procedures.txt; documentation can already look in multiple files, and I think the separation is worthwhile. > > One line summary sound nice, but I am not sure how to use it. > The name should be descriptive enough, and everything else will come > from the full docs. Mostly following Emacs convention here, but if the docs are in a separate file it won't matter. So do you just want user-options to be a list of variables? (I know you've addressed this before, but our assumptions may have changed). In any case, I think it's better to have it be a list of lists, with cars being the variable symbol, e.g.: (define-public user-options (list '(option-var-name ....) '(another-option-var-name ....) )) That way we can extend the variable w/o changing the code accessing the car of each var-description-list. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 13:17:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31531 for scwm-discuss-outgoing; Tue, 8 Sep 1998 13:17:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31528 for ; Tue, 8 Sep 1998 13:17:13 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA26626; Tue, 8 Sep 98 13:12:52 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA19406; Tue, 8 Sep 1998 10:12:48 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Build problems with 9/4 snapshot References: <35f200f7.353730046@smtp> <35f649d9.80582942@smtp> <35f762e7.86996724@smtp> From: Greg Badros Date: 08 Sep 1998 10:12:47 -0700 In-Reply-To: smithd@bellhow.com's message of "Tue, 08 Sep 1998 17:06:14 GMT" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > On 08 Sep 1998 09:43:08 -0700, you wrote: > > >> Can someone with > >> more wisdom look at this? > > > >Looks pretty close, except you can use the %x and %y procs from base.scm: > > Cool! Never looked at those before. > > > Please verify that it behaves as your patch does. > > > If it looks like: > > (define-fvwm-command "Scroll" > (get-two-numeric-args > args > (lambda (x y) > (move-viewport (%x x) (%y y))))) > > it works great. Then you've already tested my change-- great! I'll make the change in the repository any moment now. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 14:19:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32443 for scwm-discuss-outgoing; Tue, 8 Sep 1998 14:19:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32440 for ; Tue, 8 Sep 1998 14:19:17 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24076; Tue, 8 Sep 98 14:14:53 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA20382; Tue, 8 Sep 1998 11:14:48 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <199809072248.SAA23116@huis-clos.mit.edu> From: Greg Badros Date: 08 Sep 1998 11:14:47 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 07 Sep 1998 18:48:31 EDT" Message-Id: Lines: 114 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I have a lot of specific comments, but I will wait until I can grab a > copy of the version with the latest updates for those. I just updated the one in the repository a tiny bit after discussions about 'single-click and 'double-click. > However, I have some very definite general comments. In my opinion, > there need two be two different interfaces to event bindings, an > easy one, and a complete one. The easy one should, of course, be > built on top of the complete one. I get the impression that this > proposal is trying a bit too hard to satisfy both sets of criteria > at once. I will be more specific in my later message, but for now, > let me give some design criteria that I'd like to inform the two > interfaces, and how I think this is relevant to comments I've seen > on the proposal. I'll wait to see your detailed comments, but my proposal is an attempt to address the complete interface, with niceties only thrown in either when convenient or when the restrictions are useful (e.g., instead of exposing XGrabKey, we manage that). > Easy interface: > > * Ideally, it should not be much more complicated than the current > `bind-key' and `bind-mouse' in the simplest form. In particular, if > the user wants to do simple things, he or she should not have to > worry about binding events in particular event maps, or about the > possible complexities of the underlying handling of modifiers. I think we deal with this fine -- the layer on top of the complete interface can find the appropriate map and add the event binding as needed. Note that event maps basically correspond to contexts as things currently are. > * Example: When the typical person (myself included) wants to bind > Control-x, he doesn't want this to also catch Control-Meta-x, but on > the other hand he doesn't want the state of NumLock or ScrollLock to > come into it at all. The The...? Editing difficultly? This is why we introduced the 'with pseudo-modifer -- exactly the oft-desired semantics. > He also likely > doesn't want to have to install an event map on the first left button > in order to attach a system menu to it; but this latter No, the event map would be the event map that we attached to the "Root context" (using current terminology). The basic event maps for the various contexts will be created by Scwm (though in scheme code for many of them). I should've made this correspondence more clear in my writeup. > Complete interface: > > * Other than making sure that provisions are made for the easy > interface, this interface should strive as much as possible for > completeness. > > * For example, users may want more complicated criteria > for modifiers than just "on", "off" and "don't care" sets. For > instance, fvwm provides the "A" (Any) pseudo-modifier which is true > as long as at least one modifier key is on, and, I believe, other > OR-ings of modifier keys. Given this, it should be possible at > the very least to bind to a keysym regardless of modifiers, and > have some way of getting at the modifiers that were down, to allow > for arbitrary filtering on the Scheme level. The event object contains the modifiers, so we already have that. And binding to a keysym w/o any modifiers is easy -- the MODIFIER-SPECIFIER is the empty list. Disjunctions of modifiers is tougher (and less useful, IMO), but if we really want it, then a middle ground would be to permit an 'any pseudo-modier that lists the set of modifiers that would be permitted to go through the filter, then the called proc can do the remaining processing as it chooses (and appropriate abstraction could be added there, certainly). > * As another example, event sequences probably should not be handled > directly by the low-level layer, but it should provide enough power > to write an `event-sequences' package for scwm, possibly even something > like the `strokes.el' package for XEmacs. (I don't think sequences of > mouse buttons being pressed up and down are very useful, but sequences > of keystrokes definitely are - I might want to use a special prefix > for rarely used window manager commands so as not to collide with > Netscape). I was anticipating keystroke sequences being implemented using procs that install submaps on prefix keybindings (like C-c in emacs). (I don't know much about strokes.el, but one can certainly code a FSM in scheme and attach it to an event-map object to permit that event-map to do fancier things -- that's why the event-map object gets passed to the bound procs). If you have a specific proposal about how to manage submaps in C code, I think it could be useful, but I'm not convinced it's necessary to do in C. > * Another thing I thought of that is important is the ability to > introspect about the current bindings for the purposes of interactive > help, or just plain helping you remember what keys are being used up > by the current configuration. Right. That stuff is easy after the object ctrs are written. I shouldn't have omitted mention that such things will exist, but it's unimportant right now to solidify the details of how to access them. Thanks! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 14:25:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32495 for scwm-discuss-outgoing; Tue, 8 Sep 1998 14:25:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32492 for ; Tue, 8 Sep 1998 14:25:13 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA21543; Tue, 8 Sep 98 14:20:51 EDT Received: by tis.bellhow.com; id OAA25479; Tue, 8 Sep 1998 14:20:42 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma025401; Tue, 8 Sep 98 14:20:25 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id OAA20886 for ; Tue, 8 Sep 1998 14:20:25 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: close-window Date: Tue, 08 Sep 1998 18:20:25 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35f87442.91439182@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA32493 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Shouldn't the `w' in `close-window' be `win'? *** src/scwm-19980908/scheme/winops.scm Sun Sep 6 18:42:01 1998 --- /home/users10/smithd/share/scwm-modules/app/scwm/winops.scm Tue Sep 8 14:12:49 1998 *************** *** 48,54 **** (define*-public (close-window #&optional (win (get-window #t))) "Close WIN either by deleting it or destroying it. WIN is only destroyed if it is not deleteable." ! (if w (if (window-deletable? win) (delete-window win) (destroy-window win)))) --- 48,54 ---- (define*-public (close-window #&optional (win (get-window #t))) "Close WIN either by deleting it or destroying it. WIN is only destroyed if it is not deleteable." ! (if win (if (window-deletable? win) (delete-window win) (destroy-window win)))) From owner-scwm-discuss@mit.edu Tue Sep 8 14:52:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32720 for scwm-discuss-outgoing; Tue, 8 Sep 1998 14:52:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32717 for ; Tue, 8 Sep 1998 14:52:18 -0400 Received: from MIT.MIT.EDU by MIT.EDU with SMTP id AA00916; Tue, 8 Sep 98 14:47:56 EDT Received: from [208.235.77.228] by MIT.MIT.EDU (5.61/4.7) id AA09069; Tue, 8 Sep 98 14:47:54 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Tue, 08 Sep 1998 14:47:30 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Tue, 08 Sep 1998 14:47:30 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA14326; Tue, 8 Sep 1998 14:47:29 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Documenting irregular user-option variables References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "08 Sep 1998 10:05:35 -0700" Date: 08 Sep 1998 14:47:29 -0400 Message-Id: Lines: 31 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 08 Sep 1998 10:05:35 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Re: Documenting irregular user-option variables": >> >> How about scwm-variables.txt to augment scwm-procedures.txt; >> documentation can already look in multiple files, and I think the >> separation is worthwhile. fine. >> So do you just want user-options to be a list of variables? (I know >> you've addressed this before, but our assumptions may have changed). >> In any case, I think it's better to have it be a list of lists, with >> cars being the variable symbol, e.g.: >> >> (define-public user-options (list >> '(option-var-name ....) >> '(another-option-var-name ....) >> )) >> >> That way we can extend the variable w/o changing the code accessing the >> car of each var-description-list. good point. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The world is coming to an end. Please log off. From owner-scwm-discuss@mit.edu Tue Sep 8 14:59:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00017 for scwm-discuss-outgoing; Tue, 8 Sep 1998 14:59:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA00014 for ; Tue, 8 Sep 1998 14:59:30 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA07004 for scwm-discuss@huis-clos.mit.edu; Tue, 8 Sep 1998 20:55:08 +0200 (CEST) Received: (qmail 995 invoked by uid 115); 7 Sep 1998 10:06:27 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"UeCkw2.0.hX3.9Viyr"@tequila.systemsz.cs.yale.edu> <5lpvd956wh.fsf@tequila.systemsz.cs.yale.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Sep 1998 12:06:26 +0200 In-Reply-To: Stefan Monnier's message of "06 Sep 1998 16:21:34 -0400" Message-ID: Lines: 24 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 06 Sep 1998 16:21:34 -0400 >>>>> Stefan Monnier said: Stefan> I'd also love to have some way to specify that alt and meta Stefan> should (usually) be considered equivalent (as well as shift Stefan> and capslock). I'd rather not help spread this Alt-Meta-confusion due to Emacs lossage. Either adapt your key-bindings or instruct X to map the Alt key to the Meta KeySym. They are not the same and there are keyboards that can generate both. Regarding Shift vs. CapsLock: CapsLock is nowadays taken to mean Shift only for alphabetic keys. E.g. turning CapsLock on and typing "1" gives me "1" not "!". Interpreting Return as Shift-Return when CapsLock is on seems counterintuitive to me, then. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 8 14:59:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00013 for scwm-discuss-outgoing; Tue, 8 Sep 1998 14:59:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA00009 for ; Tue, 8 Sep 1998 14:59:28 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA06995 for scwm-discuss@huis-clos.mit.edu; Tue, 8 Sep 1998 20:55:06 +0200 (CEST) Received: (qmail 946 invoked by uid 115); 7 Sep 1998 09:47:18 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 07 Sep 1998 11:47:17 +0200 In-Reply-To: cwitty@newtonlabs.com's message of "06 Sep 1998 17:56:57 -0700" Message-ID: Lines: 48 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 06 Sep 1998 17:56:57 -0700 >>>>> cwitty@newtonlabs.com (Carl R. Witty) said: Carl> 1) Allow attach-event-map to take a list of event-maps; scwm Carl> will search through all of the event-maps for a binding for a Carl> given event. [...] We already have inheritance of keymaps in the proposal. I think this has the same power: instead of a list of modes, one can have a chain of them. Alas, removing one mode from the middle is tricky. I don't know if this case happens often. A related issue: We probably want a #:with-keymap style-option that, if applied multiple times to the same window, merges the keymaps. So we either need merging here (perhaps utilizing inheritance), or offer the possibility for multiple keymaps on one window. Carl> 3) Allow multiple-event sequences. I think this would be doable by binding keymaps to events. Like in Emacs, where a keymap is bound to "C-x". You could bind special keymaps to B1-down to implement your extended button sequences. (Yes, I want to close windows with "C-x 0"!) Carl> 4) Allow grabbing the server and reading events. I can think of Carl> a couple of applications for this. It would let people write Carl> their own version of interactive-move in scheme, for example Carl> (perhaps using different keys for the keyboard shortcuts). It is more useful IMHO to implement interactive-move as a different "mode", with its own keymap that can be changed. Carl> I'd like to be able to set window "bookmarks". I would focus on Carl> a window, hit Hyper-s ('s' for "set bookmark"), and then press Carl> a key; this would set a bookmark on the window labeled by that Carl> key. I see no need for grabbing here. Either you go the same way as in 3), or your bookmarking-function just does a `read-char' or `read-string'. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 8 16:25:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00734 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:25:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from sabik.tdb.uu.se (sabik.tdb.uu.se [130.238.138.70]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA00731 for ; Tue, 8 Sep 1998 16:25:39 -0400 Received: (from m94mni@localhost) by sabik.tdb.uu.se (8.8.8/8.8.8/STUD_1.1) id WAA17658; Tue, 8 Sep 1998 22:21:16 +0200 (MET DST) To: scwm-discuss@mit.edu Subject: Window kill-file [newbie] From: Mikael Nilsson Date: 08 Sep 1998 22:21:14 +0200 Message-ID: Lines: 26 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello there! I just started to look into scwm, and it sure seems like the WM of the future to me! It seems to give new ideas about what is possible with a WM every time I think about it... One of those ideas: would it be possible to specify (i.e. code in guile) that some windows (matching regexp) should be closed immediately when they appear? I think this, in combination with JunkBuster(TM), would be a great way to get rid of some annoying pop-up Netscape windows (Like Geocities). As far as I can see it should be possible, but hey, you people should know the Right way to do it! /Mikael -- /*************************************************************************** * Mikael Nilsson m94mni@student.tdb.uu.se * * Student of Mathematics/Computer Science, University of Uppsala, Sweden * ***************************************************************************/ From owner-scwm-discuss@mit.edu Tue Sep 8 16:30:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00783 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:30:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA00780 for ; Tue, 8 Sep 1998 16:30:19 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA07510; Tue, 8 Sep 98 16:25:54 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id NAA08494; Tue, 8 Sep 1998 13:25:52 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id NAA14072; Tue, 8 Sep 1998 13:25:52 -0700 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 08 Sep 1998 13:25:51 -0700 In-Reply-To: Robert Bihlmeyer's message of "07 Sep 1998 11:47:17 +0200" Message-Id: Lines: 45 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 06 Sep 1998 17:56:57 -0700 > >>>>> cwitty@newtonlabs.com (Carl R. Witty) said: > > Carl> 1) Allow attach-event-map to take a list of event-maps; scwm > Carl> will search through all of the event-maps for a binding for a > Carl> given event. [...] > > We already have inheritance of keymaps in the proposal. I think this > has the same power: instead of a list of modes, one can have a chain > of them. Alas, removing one mode from the middle is tricky. I don't > know if this case happens often. A list also be emulated by having a single empty keymap, with all of the elements of the list as parents. (I didn't think of this before because I missed the possibility of having multiple parents in Greg's proposal.) > Carl> 3) Allow multiple-event sequences. > > I think this would be doable by binding keymaps to events. Like in > Emacs, where a keymap is bound to "C-x". You could bind special > keymaps to B1-down to implement your extended button sequences. (Yes, > I want to close windows with "C-x 0"!) Yes, this sounds like a good API. > Carl> I'd like to be able to set window "bookmarks". I would focus on > Carl> a window, hit Hyper-s ('s' for "set bookmark"), and then press > Carl> a key; this would set a bookmark on the window labeled by that > Carl> key. > > I see no need for grabbing here. Either you go the same way as in > 3), or your bookmarking-function just does a `read-char' or > `read-string'. It may be possible to do this without exposing the grabs to the person writing the bookmark function, but the internal implementation will have to have grabs. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Tue Sep 8 16:51:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00988 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:51:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA00985 for ; Tue, 8 Sep 1998 16:51:31 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA15116; Tue, 8 Sep 98 16:47:07 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA22869; Tue, 8 Sep 1998 13:46:56 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"UeCkw2.0.hX3.9Viyr"@tequila.systemsz.cs.yale.edu> <5lpvd956wh.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 08 Sep 1998 13:46:55 -0700 In-Reply-To: Robert Bihlmeyer's message of "07 Sep 1998 12:06:26 +0200" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 06 Sep 1998 16:21:34 -0400 > >>>>> Stefan Monnier said: > > Stefan> I'd also love to have some way to specify that alt and meta > Stefan> should (usually) be considered equivalent (as well as shift > Stefan> and capslock). > > I'd rather not help spread this Alt-Meta-confusion due to Emacs > lossage. Either adapt your key-bindings or instruct X to map the Alt > key to the Meta KeySym. They are not the same and there are keyboards > that can generate both. ICCCM conventions have all sorts of rules about this stuff (which I believe you, Robert, were the one to point out and fix many months ago). We'll just try to continue to follow those rules. > Regarding Shift vs. CapsLock: CapsLock is nowadays taken to mean Shift > only for alphabetic keys. E.g. turning CapsLock on and typing "1" > gives me "1" not "!". Interpreting Return as Shift-Return when > CapsLock is on seems counterintuitive to me, then. I agree. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 16:56:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01024 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:56:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01018 for ; Tue, 8 Sep 1998 16:55:59 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA18605; Tue, 8 Sep 98 16:51:35 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA22872; Tue, 8 Sep 1998 13:51:32 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 08 Sep 1998 13:51:32 -0700 In-Reply-To: Robert Bihlmeyer's message of "07 Sep 1998 11:47:17 +0200" Message-Id: Lines: 55 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > We already have inheritance of keymaps in the proposal. I think this > has the same power: instead of a list of modes, one can have a chain > of them. Alas, removing one mode from the middle is tricky. I don't > know if this case happens often. It's not that tricky, plus we can have multiple parents, so it can be a flat "chain" that's not a chain at all. > A related issue: We probably want a #:with-keymap style-option that, > if applied multiple times to the same window, merges the keymaps. So > we either need merging here (perhaps utilizing inheritance), or offer > the possibility for multiple keymaps on one window. We can get multiple keymaps on one window trivially by having a null keymap have multiple parents... the cost of this is pretty minimal I think. > > Carl> 3) Allow multiple-event sequences. > > I think this would be doable by binding keymaps to events. Like in > Emacs, where a keymap is bound to "C-x". You could bind special > keymaps to B1-down to implement your extended button sequences. (Yes, > I want to close windows with "C-x 0"!) Right. Maybe some of the magic emacs does with having maps pop into existence is worth investigating at some higher layer of event binding. > Carl> 4) Allow grabbing the server and reading events. I can think of > Carl> a couple of applications for this. It would let people write > Carl> their own version of interactive-move in scheme, for example > Carl> (perhaps using different keys for the keyboard shortcuts). > > It is more useful IMHO to implement interactive-move as a different > "mode", with its own keymap that can be changed. Exactly. That's my original intent. > Carl> I'd like to be able to set window "bookmarks". I would focus on > Carl> a window, hit Hyper-s ('s' for "set bookmark"), and then press > Carl> a key; this would set a bookmark on the window labeled by that > Carl> key. > > I see no need for grabbing here. Either you go the same way as in > 3), or your bookmarking-function just does a `read-char' or > `read-string'. Yep.... Note that these later read-char/read-string are keyboard grabs by Scwm. (There was initial confusion over whether Carl was talking about Server grabs or keyboard grabs -- keyboard grabs are necessary but should be hidden from the user [behind a read-char primitive is sufficient]; server-grabs should be avoided whenever possible). Greg From owner-scwm-discuss@mit.edu Tue Sep 8 16:57:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01059 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:57:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01056 for ; Tue, 8 Sep 1998 16:57:57 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17516; Tue, 8 Sep 98 16:53:34 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA22875; Tue, 8 Sep 1998 13:53:25 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 08 Sep 1998 13:53:25 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "08 Sep 1998 13:25:51 -0700" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > > We already have inheritance of keymaps in the proposal. I think this > > has the same power: instead of a list of modes, one can have a chain > > of them. Alas, removing one mode from the middle is tricky. I don't > > know if this case happens often. > > A list also be emulated by having a single empty keymap, with all of > the elements of the list as parents. (I didn't think of this before > because I missed the possibility of having multiple parents in Greg's > proposal.) Exactly (I should've read ahead before responding to the last message, too). > > I see no need for grabbing here. Either you go the same way as in > > 3), or your bookmarking-function just does a `read-char' or > > `read-string'. > > It may be possible to do this without exposing the grabs to the person > writing the bookmark function, but the internal implementation will > have to have grabs. Right. So two points: 1) we're talking about keyboard grabs which are fine; and 2) it's best to not expose that low of a level of functionality at the scheme level. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 16:58:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01086 for scwm-discuss-outgoing; Tue, 8 Sep 1998 16:58:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01081 for ; Tue, 8 Sep 1998 16:58:58 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19541; Tue, 8 Sep 98 16:54:32 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA22878; Tue, 8 Sep 1998 13:54:30 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: close-window References: <35f87442.91439182@smtp> From: Greg Badros Date: 08 Sep 1998 13:54:30 -0700 In-Reply-To: smithd@bellhow.com's message of "Tue, 08 Sep 1998 18:20:25 GMT" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > Shouldn't the `w' in `close-window' be `win'? Yep, thanks -- must've missed it in my regexp s&r when fixing the docs. Thanks, Greg From owner-scwm-discuss@mit.edu Tue Sep 8 17:11:57 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01348 for scwm-discuss-outgoing; Tue, 8 Sep 1998 17:11:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01344 for ; Tue, 8 Sep 1998 17:11:54 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23571; Tue, 8 Sep 98 17:07:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA22901; Tue, 8 Sep 1998 14:04:06 -0700 (PDT) To: Mikael Nilsson Cc: scwm-discuss@mit.edu Subject: Re: Window kill-file [newbie] References: From: Greg Badros Date: 08 Sep 1998 14:04:06 -0700 In-Reply-To: Mikael Nilsson's message of "08 Sep 1998 22:21:14 +0200" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mikael Nilsson writes: > Hello there! Hi! Always happy to see a new user! > I just started to look into scwm, and it sure seems like the WM of the > future to me! It seems to give new ideas about what is possible with a > WM every time I think about it... Me too! :-) Thanks for the uplifting remarks! > One of those ideas: would it be possible to specify (i.e. code in guile) > that some windows (matching regexp) should be closed immediately when > they appear? I think you're looking for the after-new-window-hook: SCWM_HOOK(after_new_window_hook, "after-new-window-hook"); /** This hook is invoked when a new window has been completely created and placed on the screen. Any window operations may be performed at this time. However, it is recommended that placement-related operations, such as setting the position, desk, viewport location and z-ordering of a window be done in the placement procedure instead. This hook does not typically need to be used directly by the user; `window-style' from the (app scwm style) module provides a convenient interface to setting the relevant parameters when a new window is created. */ Something like: (add-hook! after-new-window-hook (lambda (w) (if (string=? (window-title w) "xlogo") (close-window w)))) See wildcard-matcher in wininfo.scm for a regexp example. Note that I think the wildcard-matcher functionality will change (For a long while, I've not liked the way window titles are used in conjunction with window resource class and names). Enjoy! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 17:26:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01579 for scwm-discuss-outgoing; Tue, 8 Sep 1998 17:26:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01576 for ; Tue, 8 Sep 1998 17:26:20 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28041; Tue, 8 Sep 98 17:21:54 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id AAA14233 for ; Wed, 9 Sep 1998 00:21:47 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id XAA29057; Tue, 8 Sep 1998 23:21:48 +0200 To: scwm-discuss@mit.edu Subject: build problems with current snapshot - fMWMMenus From: abel@bfr.co.il (Alexander L. Belikoff) Date: 08 Sep 1998 23:21:48 +0200 Message-Id: Lines: 19 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk When I try to compile a current snapshot, I get: gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6/include -I/bb/home/abel/opt/include -g -O2 -c move.c move.c: In function `moveLoop': move.c:337: structure has no member named `fMWMMenus' move.c:338: structure has no member named `fMWMMenus' make[1]: *** [move.o] Error 1 Futher examination shows, that the latter is commented out in screen.h. Uncommenting it makes the thing compile fine. -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 8 17:37:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01717 for scwm-discuss-outgoing; Tue, 8 Sep 1998 17:37:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01711 for ; Tue, 8 Sep 1998 17:36:29 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA00572; Tue, 8 Sep 98 17:31:57 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA23830; Tue, 8 Sep 1998 14:31:52 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: build problems with current snapshot - fMWMMenus References: From: Greg Badros Date: 08 Sep 1998 14:31:51 -0700 In-Reply-To: abel@bfr.co.il's message of "08 Sep 1998 23:21:48 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > When I try to compile a current snapshot, I get: > > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/X11R6/include > -I/bb/home/abel/opt/include -g -O2 -c move.c > move.c: In function `moveLoop': > move.c:337: structure has no member named `fMWMMenus' > move.c:338: structure has no member named `fMWMMenus' > make[1]: *** [move.o] Error 1 > > > Futher examination shows, that the latter is commented out in > screen.h. Uncommenting it makes the thing compile fine. I just fixed this 5 minutes ago (by eliminating the use -- my goal was to get rid of the bogus flag fMWMMenus). You were just a bit too fast for me :-) [I do *try* to keep the snapshot in a compilable state, but often my little bug fixes go untested for a couple minutes here or there]. Thanks! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 18:21:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA01987 for scwm-discuss-outgoing; Tue, 8 Sep 1998 18:21:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA01984 for ; Tue, 8 Sep 1998 18:21:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13642; Tue, 8 Sep 98 18:17:18 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id BAA14624 for ; Wed, 9 Sep 1998 01:17:14 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id AAA29536; Wed, 9 Sep 1998 00:17:13 +0200 To: scwm-discuss@mit.edu Subject: window positioning problems in current snapshot References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 09 Sep 1998 00:17:13 +0200 In-Reply-To: Greg Badros's message of "08 Sep 1998 14:31:51 -0700" Message-Id: Lines: 37 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've just moved back to 0.8a after trying the latest snapshot (before your fix). Window positioning seems to be completely insane - windows suddenly jump to random positions, sometimes I find a freshly opened netscape menu located at (0,0) etc. Icon placement however works. I can post my .scwmrc if there is a need. Anyway, I'm using : (set-smart-placement-is-really-smart! #t) (window-style "*" #:fg "black" #:bg "gray55" #:icon "unknown1.xpm" #:sticky-icon #t #:icon-box (list 0 (y- 20) (y- 50) (y- 1)) #:border-width 6 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:mwm-buttons #t #:mwm-border #t #:int-override #t #:decorate-transient #t #:PPosition-hint #f ) Also, a quick question: how do I restrict a number of virtual screens (*not* desks) - one that was DesktopSize in FVWM? Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 8 19:29:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA02370 for scwm-discuss-outgoing; Tue, 8 Sep 1998 19:29:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA02367 for ; Tue, 8 Sep 1998 19:29:52 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28629; Tue, 8 Sep 98 19:25:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA27602; Tue, 8 Sep 1998 16:25:22 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 08 Sep 1998 16:25:22 -0700 In-Reply-To: abel@bfr.co.il's message of "09 Sep 1998 00:17:13 +0200" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > I've just moved back to 0.8a after trying the latest snapshot (before > your fix). Window positioning seems to be completely insane - windows Before which fix? What does your changed.c file contain? > suddenly jump to random positions, sometimes I find a freshly opened > netscape menu located at (0,0) etc. Icon placement however works. > Also, a quick question: how do I restrict a number of virtual screens > (*not* desks) - one that was DesktopSize in FVWM? is `set-desk-size!' what you are looking for? You can use C-h C-a from scwm-mode in emacs w/ "desk" for trying to browse the primitives. Good luck! Greg From owner-scwm-discuss@mit.edu Tue Sep 8 19:33:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA02429 for scwm-discuss-outgoing; Tue, 8 Sep 1998 19:33:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA02426 for ; Tue, 8 Sep 1998 19:33:34 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28324; Tue, 8 Sep 98 19:29:08 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA27609; Tue, 8 Sep 1998 16:29:09 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Multi-key bindings... From: Greg Badros Date: 08 Sep 1998 16:29:09 -0700 Message-Id: Lines: 5 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk It just occurred to me that multi-key bindings are just like generalized menus w/o mapping (i.e. displaying, making visible) the menu window... we really already have multi-key event bindings in a limited sense. Greg From owner-scwm-discuss@mit.edu Tue Sep 8 19:35:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA02484 for scwm-discuss-outgoing; Tue, 8 Sep 1998 19:35:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA02480 for ; Tue, 8 Sep 1998 19:35:38 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28695; Tue, 8 Sep 98 19:31:09 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id CAA15089 for ; Wed, 9 Sep 1998 02:31:09 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id BAA30118; Wed, 9 Sep 1998 01:31:09 +0200 To: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 09 Sep 1998 01:31:08 +0200 In-Reply-To: Greg Badros's message of "08 Sep 1998 16:25:22 -0700" Message-Id: Lines: 25 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > I've just moved back to 0.8a after trying the latest snapshot (before > > your fix). Window positioning seems to be completely insane - windows > > Before which fix? What does your changed.c file contain? Before 'fMWMMenus the undefined' one. I don't have files handy - I've removed the tree. :-( > > > suddenly jump to random positions, sometimes I find a freshly opened > > netscape menu located at (0,0) etc. Icon placement however works. > > Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 8 19:53:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA02721 for scwm-discuss-outgoing; Tue, 8 Sep 1998 19:53:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA02718 for ; Tue, 8 Sep 1998 19:53:20 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03277; Tue, 8 Sep 98 19:48:57 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA27646; Tue, 8 Sep 1998 16:48:52 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 08 Sep 1998 16:48:51 -0700 In-Reply-To: abel@bfr.co.il's message of "09 Sep 1998 01:31:08 +0200" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Greg Badros writes: > > > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > > > I've just moved back to 0.8a after trying the latest snapshot (before > > > your fix). Window positioning seems to be completely insane - windows > > > > Before which fix? What does your changed.c file contain? > > Before 'fMWMMenus the undefined' one. I don't have files handy - I've > removed the tree. :-( Well if you ever see it again, I'll gladly look into it. Last week there were lots of related problems as I substantially and pervasively changed the way window positions were managed, but things seem stable again to me. BTW, I just added the request for changed.c to the BUG-REPORTING file, since it can be really useful for tracking down exactly what version you are using -- it gets its revision number incremented at each commit). Thanks, Greg From owner-scwm-discuss@mit.edu Tue Sep 8 20:05:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA02853 for scwm-discuss-outgoing; Tue, 8 Sep 1998 20:05:59 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA02850 for ; Tue, 8 Sep 1998 20:05:39 -0400 Received: from benetnash.ffke-campus.mipt.ru by MIT.EDU with SMTP id AA05497; Tue, 8 Sep 98 20:01:08 EDT Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id EAA23452; Thu, 10 Sep 1998 04:01:16 +0400 Date: Thu, 10 Sep 1998 04:01:16 +0400 Message-Id: <199809100001.EAA23452@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: gjb@cs.washington.edu Cc: scwm-discuss@mit.edu In-Reply-To: (message from Greg Badros on 08 Sep 1998 16:29:09 -0700) Subject: Re: Multi-key bindings... Reply-To: tihonov@ffke-campus-gw.mipt.ru References: Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello! It just occurred to me that multi-key bindings are just like generalized menus w/o mapping (i.e. displaying, making visible) the menu window... we really already have multi-key event bindings in a limited sense. When you hit some key to invoke menu, you will SEE that menu, then you can hit ESC, if you had poped up menu occasionaly. Emacs has minibuffer to display prefix and C-g to abort complex command. Scwm has neither the former, nor the latter. Some kind of abort character is a click on the root menu (but it is not so good, we'd better have explicit aborting command). And we can make scwm to change mouse pointer while waiting for more input. --Oleg From owner-scwm-discuss@mit.edu Tue Sep 8 20:07:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA02883 for scwm-discuss-outgoing; Tue, 8 Sep 1998 20:07:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA02880 for ; Tue, 8 Sep 1998 20:07:28 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA06078; Tue, 8 Sep 98 20:03:02 EDT Received: (qmail 14321 invoked by uid 501); 9 Sep 1998 00:02:59 -0000 Message-Id: <19980908170257.A14194@molehill.org> Date: Tue, 8 Sep 1998 17:02:57 -0700 From: Todd Larason To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"UeCkw2.0.hX3.9Viyr"@tequila.systemsz.cs.yale.edu> <5lpvd956wh.fsf@tequila.systemsz.cs.yale.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Robert Bihlmeyer on Mon, Sep 07, 1998 at 12:06:26PM +0200 X-Tom-Swifty: "There's a blood-sucking insect in my French cheese", said Tom briefly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980907, Robert Bihlmeyer wrote: > Regarding Shift vs. CapsLock: CapsLock is nowadays taken to mean Shift > only for alphabetic keys. E.g. turning CapsLock on and typing "1" > gives me "1" not "!". Interpreting Return as Shift-Return when > CapsLock is on seems counterintuitive to me, then. X supports both CapsLock and ShiftLock, with the distinction exactly this. From owner-scwm-discuss@mit.edu Tue Sep 8 20:10:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA02941 for scwm-discuss-outgoing; Tue, 8 Sep 1998 20:10:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA02937 for ; Tue, 8 Sep 1998 20:10:04 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06524; Tue, 8 Sep 98 20:05:40 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA27705; Tue, 8 Sep 1998 17:05:28 -0700 (PDT) To: tihonov@ffke-campus-gw.mipt.ru Cc: scwm-discuss@mit.edu Subject: Re: Multi-key bindings... References: <199809100001.EAA23452@benetnash.ffke-campus.mipt.ru> From: Greg Badros Date: 08 Sep 1998 17:05:27 -0700 In-Reply-To: "Oleg S. Tihonov"'s message of "Thu, 10 Sep 1998 04:01:16 +0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Oleg S. Tihonov" writes: > Hello! > > It just occurred to me that multi-key bindings are just like generalized > menus w/o mapping (i.e. displaying, making visible) the menu window... > we really already have multi-key event bindings in a limited sense. > > When you hit some key to invoke menu, you will SEE that menu, then you can hit > ESC, if you had poped up menu occasionaly. Emacs has minibuffer to display > prefix and C-g to abort complex command. Scwm has neither the former, nor > the latter. Some kind of abort character is a click on the root menu (but it > is not so good, we'd better have explicit aborting command). And we can > make scwm to change mouse pointer while waiting for more input. Whoah... I'm not saying we don't need multi-key event bindings because we have menus... I'm just noting that two things seemingly quite disimilar really can be seen as parameterized versions of the same feature. Not sure if it'll matter or if it's worth exploiting the commonality, but it hadn't occurred to me before that such commonality was even there to be exploited. As an extrapolation of the similarities, scwm has the menu to display the "prefix", and "Esc" to abort the complex command. Interesting, I think... Greg From owner-scwm-discuss@mit.edu Tue Sep 8 21:06:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA03721 for scwm-discuss-outgoing; Tue, 8 Sep 1998 21:06:07 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA03715 for ; Tue, 8 Sep 1998 21:05:56 -0400 Received: from benetnash.ffke-campus.mipt.ru by MIT.EDU with SMTP id AA16913; Tue, 8 Sep 98 21:01:27 EDT Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id FAA23573; Thu, 10 Sep 1998 05:01:38 +0400 Date: Thu, 10 Sep 1998 05:01:38 +0400 Message-Id: <199809100101.FAA23573@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: gjb@cs.washington.edu Cc: tihonov@ffke-campus-gw.mipt.ru, scwm-discuss@mit.edu In-Reply-To: (message from Greg Badros on 08 Sep 1998 17:05:27 -0700) Subject: Re: Multi-key bindings... Reply-To: tihonov@ffke-campus-gw.mipt.ru References: <199809100001.EAA23452@benetnash.ffke-campus.mipt.ru> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > When you hit some key to invoke menu, you will SEE that menu, then you can hit > ESC, if you had poped up menu occasionaly. Emacs has minibuffer to display > prefix and C-g to abort complex command. Scwm has neither the former, nor > the latter. Some kind of abort character is a click on the root menu (but it > is not so good, we'd better have explicit aborting command). And we can > make scwm to change mouse pointer while waiting for more input. Whoah... I'm not saying we don't need multi-key event bindings because we have menus... Me too. As an extrapolation of the similarities, scwm has the menu to display the "prefix", and "Esc" to abort the complex command. Interesting, I think... What i wanted to say is that not implementing such abilities for complex keybindings is rather dangerous. --Oleg From owner-scwm-discuss@mit.edu Tue Sep 8 22:53:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA04173 for scwm-discuss-outgoing; Tue, 8 Sep 1998 22:53:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA04170 for ; Tue, 8 Sep 1998 22:53:47 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AB08107; Tue, 8 Sep 98 22:49:20 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id TAA07841; Tue, 8 Sep 1998 19:49:13 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id TAA15317; Tue, 8 Sep 1998 19:49:12 -0700 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 08 Sep 1998 19:49:11 -0700 In-Reply-To: Greg Badros's message of "08 Sep 1998 13:51:32 -0700" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Yep.... Note that these later read-char/read-string are keyboard grabs > by Scwm. (There was initial confusion over whether Carl was talking > about Server grabs or keyboard grabs -- keyboard grabs are necessary but > should be hidden from the user [behind a read-char primitive is > sufficient]; server-grabs should be avoided whenever possible). Yeah...sorry about creating that confusion. (I hadn't looked at this stuff for several years, and I had forgotten about the different kinds of grabs.) Really, the only place I see a server grab as being useful (and necessary) is when you're doing rubber-band outlines (i.e., for non-opaque move, resize, and initial placement). Given that, it's somewhat amusing that my initial example was the wish to write interactive-move in scheme, since interactive-move does require a server grab. I wonder if modern machines/X servers are fast enough to do rubber-banding using a shaped window with save-under? We could get rid of server grabs altogether... Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Sep 9 06:54:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA06740 for scwm-discuss-outgoing; Wed, 9 Sep 1998 06:54:18 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA06734 for ; Wed, 9 Sep 1998 06:53:40 -0400 Received: from benetnash.ffke-campus.mipt.ru by MIT.EDU with SMTP id AA18801; Wed, 9 Sep 98 06:49:07 EDT Received: (from ost@localhost) by benetnash.ffke-campus.mipt.ru (8.8.5/8.8.5) id OAA00179; Wed, 9 Sep 1998 14:49:42 +0400 Date: Wed, 9 Sep 1998 14:49:42 +0400 Message-Id: <199809091049.OAA00179@benetnash.ffke-campus.mipt.ru> X-Authentication-Warning: benetnash.ffke-campus.mipt.ru: ost set sender to ost@benetnash.ffke-campus.mipt.ru using -f From: "Oleg S. Tihonov" To: gjb@cs.washington.edu Cc: scwm-discuss@mit.edu In-Reply-To: (message from Greg Badros on 08 Sep 1998 17:05:27 -0700) Subject: Re: Multi-key bindings... Reply-To: tihonov@ffke-campus-gw.mipt.ru References: <199809100001.EAA23452@benetnash.ffke-campus.mipt.ru> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Whoah... I'm not saying we don't need multi-key event bindings because we have menus... I'm just noting that two things seemingly quite disimilar really can be seen as parameterized versions of the same feature. Not sure if it'll matter or if it's worth exploiting the commonality, but it hadn't occurred to me before that such commonality was even there to be exploited. Oh.. Just recalled -- type (lookup-key global-map [menu-bar]) in emacs and you'll see how your fresh idea can be exploited. :) --Oleg From owner-scwm-discuss@mit.edu Wed Sep 9 10:25:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA08073 for scwm-discuss-outgoing; Wed, 9 Sep 1998 10:25:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA08068; Wed, 9 Sep 1998 10:25:23 -0400 Message-Id: <199809091425.KAA08068@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu, m94mni@student.tdb.uu.se Subject: Re: Window kill-file [newbie] In-reply-to: Your message of "08 Sep 1998 14:04:06 PDT." Date: Wed, 09 Sep 1998 10:25:22 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Mikael Nilsson writes: > > > Hello there! > > Hi! Always happy to see a new user! > Me too. > > > One of those ideas: would it be possible to specify (i.e. code in guile) > > that some windows (matching regexp) should be closed immediately when > > they appear? > > I think you're looking for the after-new-window-hook: > > SCWM_HOOK(after_new_window_hook, "after-new-window-hook"); > /** This hook is invoked when a new window has been completely created > and placed on the screen. Any window operations may be performed at > this time. However, it is recommended that placement-related > operations, such as setting the position, desk, viewport location and > z-ordering of a window be done in the placement procedure instead. > > This hook does not typically need to be used directly by the user; > `window-style' from the (app scwm style) module provides a convenient > interface to setting the relevant parameters when a new window is > created. */ > > Something like: > > (add-hook! after-new-window-hook > (lambda (w) (if (string=? (window-title w) "xlogo") > (close-window w)))) > > See wildcard-matcher in wininfo.scm for a regexp example. Note that I > think the wildcard-matcher functionality will change (For a long while, > I've not liked the way window titles are used in conjunction with window > resource class and names). > > Enjoy! > Or here's a way to do it with window styles which is IMO better: (use-modules (ice-9 regex)) ;; should be a stock guile function, or can you do this w/ regexp-exec? (define (regexp-exact-match? rx str) (let ((match (regexp-exec rx str))) (and match (= (match:start match) 0) (= (match:end match) (string-length str))))) ;; should be a stock scwm function (define (regexp-title regexp) (let ((rgx (make-regexp regexp))) (lambda (win) (regexp-exact-match? rgx (window-title win))))) (window-style (regexp-title "My favorite regexp") #:other-proc close-window) Of course, the user should only have to write the last line of this. The regexp-title procedure should be provided by scwm, at which point it really will be that easy. We definitely need a lot more different convenience functions for matching windows in window styles. A mostly-rewrite of style.scm to achieve thisachieve this and many other useful changes is pretty high on my list. From owner-scwm-discuss@mit.edu Wed Sep 9 10:50:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA08524 for scwm-discuss-outgoing; Wed, 9 Sep 1998 10:50:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA08518 for ; Wed, 9 Sep 1998 10:49:58 -0400 Received: from reohub2.reo.dec.com (reohub2.reo.dec.com [16.37.21.19]) by mail11.digital.com (8.8.8/8.8.8/WV1.0g) with ESMTP id KAA20678 for ; Wed, 9 Sep 1998 10:45:27 -0400 (EDT) Message-Id: <199809091445.KAA20678@mail11.digital.com> Received: by reohub2.reo.dec.com with Internet Mail Service (5.5.1960.3) id ; Wed, 9 Sep 1998 15:45:27 +0100 From: Jeremie Petit To: "'scwm-discuss@huis-clos.mit.edu'" Subject: Scwm compile problems with scwm 09/09 snapshot Date: Wed, 9 Sep 1998 15:45:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello, I'm trying to use scwm, but the last snapshot lead me to the followin problem: when linking scwm, the two following libs were missing: ICE and SM. I also noted the following compile warnings: gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/users1/petit/Apps/DEC/include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -c face.c face.c: In function `print_face': face.c:276: warning: cast from pointer to integer of different size gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/users1/petit/Apps/DEC/include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -c getopt.c getopt.c: In function `_getopt_internal': getopt.c:661: warning: type mismatch in implicit declaration for built-in function `strlen' gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/users1/petit/Apps/DEC/include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -c log-usage.c log-usage.c: In function `SendUsagePacket': log-usage.c:87: warning: passing arg 2 of `connect' from incompatible pointer type gcc -DHAVE_CONFIG_H -I. -I. -I../include -I/usr/users1/petit/Apps/DEC/include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -c xmisc.c xmisc.c: In function `SzExtractTextPropValue': xmisc.c:273: warning: assignment of read-only member `nitems' xmisc.c:279: warning: passing arg 2 of `XmbTextPropertyToTextList' discards `const' from pointer target type == The Linking of scwm that missed the libraries : == /bin/sh ../libtool --mode=link g++ -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -L/usr/users1/petit/Apps/DEC/lib -I/usr/local-gnu/lib -L/usr/local1/lib -o scwm Grab.o ICCCM.o add_window.o binding.o borders.o callbacks.o changed.o color.o colormaps.o colors.o complex.o decor.o decorations.o deskpage.o drawmenu.o errors.o events.o face.o focus.o font.o getopt.o getopt1.o guile-compat.o icons.o image.o init_scheme_string.o log-usage.o menu.o menuitem.o miscprocs.o module-interface.o move.o placement.o resize.o screen.o scwm.o shutdown.o string_token.o syscompat.o system.o util.o virtual.o window.o xmisc.o xproperty.o xrm.o session-manager.o -lXext -lXmu -lXpm -lX11 -ldnet_stub -L/usr/local/lib -lguile -ltermcap -lm -lm g++ -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -L/usr/users1/petit/Apps/DEC/lib -I/usr/local-gnu/lib -L/usr/local1/lib -o scwm Grab.o ICCCM.o add_window.o binding.o borders.o callbacks.o changed.o color.o colormaps.o colors.o complex.o decor.o decorations.o deskpage.o drawmenu.o errors.o events.o face.o focus.o font.o getopt.o getopt1.o guile-compat.o icons.o image.o init_scheme_string.o log-usage.o menu.o menuitem.o miscprocs.o module-interface.o move.o placement.o resize.o screen.o scwm.o shutdown.o string_token.o syscompat.o system.o util.o virtual.o window.o xmisc.o xproperty.o xrm.o session-manager.o -lXext -lXmu -lXpm -lX11 -ldnet_stub -L/usr/local/lib -lguile -ltermcap -lm -lm collect2: ld returned 1 exit status /bin/ld: Unresolved: SmcSetProperties IceAddConnectionWatch SmcOpenConnection SmcGetIceConnection IceConnectionNumber SmcRequestSaveYourselfPhase2 SmcCloseConnection SmcSaveYourselfDone gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -Wp,-MD,.deps/libmain.p -c -DPIC libmain.c libmain.c: In function `scwmexec_exec_full': libmain.c:107: warning: type mismatch in implicit declaration for built-in function `strlen' gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -O3 -I/usr/users1/petit/Apps/DEC/include -I/usr/local-gnu/include -I/usr/local1/include -c scwmexec.c scwmexec.c: In function `main': scwmexec.c:63: warning: type mismatch in implicit declaration for built-in function `strlen' Here are the informations about my system/environment I found revealant: ======================================================================== ==System== OSF1 jekyll.vbe.dec.com V4.0 878 alpha alpha ==guile -v== Guile 1.3a ==scwm -V== Scwm Version 0.8 compiled on Sep 2 1998 at 18:27:52 RCS_ID=$Id: scwm.c,v 1.111 1998/08/21 20:21:33 gjb Exp $ ==changed.c== char *szRepoLastChanged = "Tue Sep 8 20:21:10 EDT 1998 -- $Revision: 1.338 $"; ==scwmpaths.h== /* generated by Makefile -- do not edit */ #define SCWM_PREFIX "/usr/users1/petit/Apps/DEC" #define SCWM_EXEC_PREFIX "/usr/users1/petit/Apps/DEC" #define SCWMDIR "/usr/users1/petit/Apps/DEC/lib/X11/scwm" #define SCWMRC ".scwmrc" #define SCWM_LOAD_PATH "/usr/users1/petit/Apps/DEC/share/scwm-modules" #define SCWM_IMAGE_LOAD_PATH "(\"/usr/include/X11/bitmaps\" \"/usr/include/X11/pixmaps\" \"/X11/mini-icons\" \"/usr/users1/petit/Apps/DEC/include/X11/pixmaps\" \"/usr/users1/petit/Apps/DEC/include/X11/bitmaps\" \"/usr/users1/petit/Apps/DEC/lib/X11/mini-icons\")" ==CONFIG.H== /* include/config.h. Generated automatically by configure. */ /* include/config.h.in. Generated automatically from configure.in by autoheader. */ /* Define if on AIX 3. System headers sometimes define this. We just want to avoid a redefinition error message. */ #ifndef _ALL_SOURCE /* #undef _ALL_SOURCE */ #endif /* Define to empty if the keyword does not work. */ /* #undef const */ /* Define as __inline if that's what the C compiler calls it. */ /* #undef inline */ /* Define if on MINIX. */ /* #undef _MINIX */ /* Define if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define if you need to in order for stat and other things to work. */ /* #undef _POSIX_SOURCE */ /* Define if you have the ANSI C header files. */ #define STDC_HEADERS 1 /* Define if the X Window System is missing or not being used. */ /* #undef X_DISPLAY_MISSING */ /* Package and version macros defined by automake */ #define PACKAGE "scwm" #define VERSION "post0.8a" /* Define this if your Xext library supports the X extension (wether your server does or not will be determined at runtime */ #define HAVE_SHAPE 1 /* Define this if you have libXpm */ #define HAVE_LIBXPM 1 /* Define this if you have libXmu */ #define HAVE_LIBXMU 1 /* Define this if you have libSM and libIce for session manager support */ #define HAVE_LIBSM_LIBICE 1 /* Define this if you have the readline library */ #define HAVE_READLINE 1 /* Define this if your readline also has add_history() */ #define HAVE_HISTORY 1 /* Define this if your libguile has a scm_eval_string that is safe against re-entry by continuations. This should be true of snapshots newer than 970928. */ #define HAVE_SAFE_SCM_EVAL_STRING 1 /* Define this if your libguile exports scm_puts, meaning that scm_gen_puts should no longer be used. This should be true of snapshots newer than 971014. */ #define HAVE_SCM_PUTS 1 /* Define this if your libguile has gh_vector_ref instead of gh_vref, meaning that gh_vref should no longer be used. This should be true of snapshots newer than 971012. */ #define HAVE_GH_VECTOR_REF 1 /* Define this if your libguile has gh_vector_set_x instead of gh_vset, meaning that gh_vset should no longer be used. This should be true of snapshots newer than 971020. */ #define HAVE_GH_VECTOR_SET_X 1 /* Define this if your libguile has readline support. This should be true of snapshots newer than 971023. */ /* #undef HAVE_SCM_READLINE */ /* Define this if your libguile has gh_length and not gh_list_length. This should be true of snapshots newer than 970915. */ #define HAVE_GH_LENGTH 1 /* Define this if your libguile has scm_parse_path. */ #define HAVE_SCM_PARSE_PATH 1 /* Define this if your libguile has scm_parse_path. */ /* #undef HAVE_SCM_INTERNAL_SELECT */ /* Define this if your libguile has scm_the_last_stack_fluid instead of scm_the_last_stack_var. */ #define HAVE_SCM_THE_LAST_STACK_FLUID 1 /* Define this if your libguile has scm_internal_cwdr. */ #define HAVE_SCM_INTERNAL_CWDR 1 /* Define this if your libguile has scm_internal_stack_catch. */ #define HAVE_SCM_INTERNAL_STACK_CATCH 1 /* Define this if your libguile has scm_internal_parse_path, which should be used instead of scm_parse_path from C. */ #define HAVE_SCM_INTERNAL_PARSE_PATH 1 /* Define this if your libguile has a scm_make_vector, which needs three arguments. This should be true only of older versions. */ /* #undef HAVE_SCM_MAKE_VECTOR_3_ARGS */ /* Define this if your system has a header file. */ #define HAVE_GETOPT_H 1 /* Define this if you want multibyte support. */ #define I18N 1 /* Define this if you want to compile with X_LOCALE define. */ /* #undef X_LOCALE */ /* Define this and use C++ compiler if you want to use constraint solver */ /* #undef USE_CASSOWARY */ /* Define tihs if you want to turn debug support off for cassowary */ /* #undef CL_NO_TRACE */ /* Define if you have the gethostname function. */ #define HAVE_GETHOSTNAME 1 /* Define if you have the getopt_long function. */ /* #undef HAVE_GETOPT_LONG */ /* Define if you have the setlinebuf function. */ #define HAVE_SETLINEBUF 1 /* Define if you have the setvbuf function. */ #define HAVE_SETVBUF 1 /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 /* Define if you have the strerror function. */ #define HAVE_STRERROR 1 /* Define if you have the strncasecmp function. */ #define HAVE_STRNCASECMP 1 /* Define if you have the sysconf function. */ #define HAVE_SYSCONF 1 /* Define if you have the uname function. */ #define HAVE_UNAME 1 /* Define if you have the usleep function. */ #define HAVE_USLEEP 1 /* Define if you have the waitpid function. */ #define HAVE_WAITPID 1 /* Define if you have the header file. */ #define HAVE_GETOPT_H 1 /* Define if you have the m library (-lm). */ #define HAVE_LIBM 1 ==END!!== Best Regards. Jérémie Petit From owner-scwm-discuss@mit.edu Wed Sep 9 11:28:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA08990 for scwm-discuss-outgoing; Wed, 9 Sep 1998 11:28:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA08987 for ; Wed, 9 Sep 1998 11:28:07 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03484; Wed, 9 Sep 98 11:23:33 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28927; Wed, 9 Sep 1998 08:23:06 -0700 (PDT) To: tihonov@ffke-campus-gw.mipt.ru Cc: scwm-discuss@mit.edu Subject: Re: Multi-key bindings... References: <199809100001.EAA23452@benetnash.ffke-campus.mipt.ru> <199809100101.FAA23573@benetnash.ffke-campus.mipt.ru> From: Greg Badros Date: 09 Sep 1998 08:23:05 -0700 In-Reply-To: "Oleg S. Tihonov"'s message of "Thu, 10 Sep 1998 05:01:38 +0400" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Oleg S. Tihonov" writes: > > When you hit some key to invoke menu, you will SEE that menu, then you can hit > > ESC, if you had poped up menu occasionaly. Emacs has minibuffer to display > > prefix and C-g to abort complex command. Scwm has neither the former, nor > > the latter. Some kind of abort character is a click on the root menu (but it > > is not so good, we'd better have explicit aborting command). And we can > > make scwm to change mouse pointer while waiting for more input. > > Whoah... I'm not saying we don't need multi-key event bindings because > we have menus... > > Me too. Right, I knew you weren't -- it just sounded as if you were thinking I was suggesting that menus made multi-key event bindings unnecessary, which I wasn't. :-) > > As an extrapolation of the similarities, scwm has the menu to display > the "prefix", and "Esc" to abort the complex command. Interesting, I > think... > > What i wanted to say is that not implementing such abilities for complex > keybindings is rather dangerous. Agreed. Good. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 11:31:21 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA09038 for scwm-discuss-outgoing; Wed, 9 Sep 1998 11:31:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA09035 for ; Wed, 9 Sep 1998 11:31:17 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19237; Wed, 9 Sep 98 11:26:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28930; Wed, 9 Sep 1998 08:26:41 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 09 Sep 1998 08:26:41 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "08 Sep 1998 19:49:11 -0700" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > Really, the only place I see a server grab as being useful (and > necessary) is when you're doing rubber-band outlines (i.e., for > non-opaque move, resize, and initial placement). Given that, it's > somewhat amusing that my initial example was the wish to write > interactive-move in scheme, since interactive-move does require a > server grab. Right -- and as more hardware has an overlay plane, it'll become unnecessary then, too. > I wonder if modern machines/X servers are fast enough to do > rubber-banding using a shaped window with save-under? We could get > rid of server grabs altogether... It'd still be cheaper to move the real window, anyway. The rubber-banding was designed mostly for performance reasons when X servers were slow. I imagine there are some who like it for some visual or UI reason, but I'm not the best person to make that argument as I prefer opaque moves. Note that Scwm + Cassowary (the constraint solver) requires that you use opaque moves since arbitrarily many windows may move/resize when you move/resize a single one interactively. Generalizing the rubberband didn't seem worth the hassle. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 11:50:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA09273 for scwm-discuss-outgoing; Wed, 9 Sep 1998 11:50:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA09270 for ; Wed, 9 Sep 1998 11:50:13 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA26490; Wed, 9 Sep 98 11:45:41 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28940; Wed, 9 Sep 1998 08:45:35 -0700 (PDT) To: Jeremie Petit Cc: "'scwm-discuss@huis-clos.mit.edu'" Subject: Re: Scwm compile problems with scwm 09/09 snapshot References: <199809091445.KAA20678@mail11.digital.com> From: Greg Badros Date: 09 Sep 1998 08:45:35 -0700 In-Reply-To: Jeremie Petit's message of "Wed, 9 Sep 1998 15:45:09 +0100" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jeremie Petit writes: > Hello, > > I'm trying to use scwm, but the last snapshot lead me to the followin > problem: when linking scwm, the two following libs were missing: ICE and SM. > > I also noted the following compile warnings: Great -- thanks... most of these are places where we're not 64-bit clean or just differences in your Alpha's libraries... I can try to build on alphas locally to test some of this stuff. > == The Linking of scwm that missed the libraries : == Hmmm... the link line is missing -lICE -lSM, but config.h has #define HAVE_LIBSM_LIBICE It looks as though I never did the substitution in Makefile.am and configure.in on SM_LIB (the variable set to -lICE -lSM if those libraries exist). I'll fix this in the repository today. Thanks for the *excellent* bug report! Very helpful! Greg From owner-scwm-discuss@mit.edu Wed Sep 9 12:30:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA09563 for scwm-discuss-outgoing; Wed, 9 Sep 1998 12:30:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA09556 for ; Wed, 9 Sep 1998 12:29:52 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Wed, 09 Sep 1998 12:25:08 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Wed, 09 Sep 1998 12:25:08 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id MAA19456; Wed, 9 Sep 1998 12:25:00 -0400 To: Maciej Stachowiak Subject: junk in docs Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 09 Sep 1998 12:25:00 -0400 Message-ID: Lines: 13 Sender: owner-scwm-discuss@mit.edu Precedence: bulk As we discussed before, there shouldn't be hypertext formatting in text documentation file. $ fgrep "$EXEC_PREFIX directory path that scwm was installed with. /usr/local/share/scwm/scwm-procedures.txt:Return the $PREFIX directory path that scwm was installed with. /usr/local/share/scwm/scwm-procedures.txt: createsa virtual world 9 times the -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Those who can't write, write manuals. From owner-scwm-discuss@mit.edu Wed Sep 9 12:38:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA09743 for scwm-discuss-outgoing; Wed, 9 Sep 1998 12:38:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA09740 for ; Wed, 9 Sep 1998 12:38:47 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14817; Wed, 9 Sep 98 12:34:08 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA29060; Wed, 9 Sep 1998 09:34:05 -0700 (PDT) To: Maciej Stachowiak Subject: Re: junk in docs References: From: Greg Badros Date: 09 Sep 1998 09:34:05 -0700 In-Reply-To: Sam Steingold's message of "09 Sep 1998 12:25:00 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > As we discussed before, there shouldn't be hypertext formatting in text > documentation file. But that should wait until we started using db2text of some kind, IMO. I'd rather have the markup there and not loose the structure instead of just throwing the markup away (which it sounds like you're suggesting). It's not too hard to hack something up that removes tags, but I don't think that it's the right solution. In time the docbook tools will get better and we'll try to exploit those improvements as they occur. I prefer slightly less pretty but more explicit docs over possibly-ambiguous text w/o markup. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 13:18:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10278 for scwm-discuss-outgoing; Wed, 9 Sep 1998 13:18:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA10275 for ; Wed, 9 Sep 1998 13:18:14 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.0); Wed, 09 Sep 1998 13:12:31 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.0.2423); Wed, 09 Sep 1998 13:12:30 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id NAA19790; Wed, 9 Sep 1998 13:13:21 -0400 To: Maciej Stachowiak Subject: scwm.el and preferences Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 09 Sep 1998 13:13:21 -0400 Message-ID: Lines: 28 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. scwm.el has changed drastically with regards to evaluation. Functions `scwm-eval-print' and `scwm-eval-to-minibuffer' are gone. The new functions `scwm-eval-last' and `scwm-eval-region' are bound to C-j and C-c C-r respectively. C-x C-j is unbound. The result of evaluation is inserted in the current buffer unless a prefix argument is supplied, in which case it is reported in the minibuffer. Theere is a new variable `scwm-eval-to-minibuffer', which is nil bu default. Set it to a non-nil value in your .emacs if you want the result of the evaluation to go to the minibuffer by default (then you will need a prefix argument to get the result inserted in the current buffer). 2. prefs-menu.scm was re-worked to use the new user-options variable. please try it: (use-modules (app scwm prefs-menu)) ... in a menu of your choice ... (menu-item "Preferences" #:action (menu-prefs #:image-side img #:color-bg-image-side color etc)) As usual, feedback is welcome. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The world is coming to an end. Please log off. From owner-scwm-discuss@mit.edu Wed Sep 9 17:08:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA11893 for scwm-discuss-outgoing; Wed, 9 Sep 1998 17:08:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA11890 for ; Wed, 9 Sep 1998 17:08:45 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06756; Wed, 9 Sep 98 17:04:07 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA29367; Wed, 9 Sep 1998 14:04:07 -0700 (PDT) To: scwm-discuss@mit.edu Subject: scwmexec handles `quit' better From: Greg Badros Date: 09 Sep 1998 14:04:06 -0700 Message-Id: Lines: 6 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just extended/fixed the scwmexec handling to ensure that a response is given, even if the evaluated expression exits scwm. No more Ctrl-G in Emacs to wake it back up! Should also deal with segfaults properly, and other terminations while the given expression is being eval'd. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 17:31:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12171 for scwm-discuss-outgoing; Wed, 9 Sep 1998 17:31:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA12168 for ; Wed, 9 Sep 1998 17:31:34 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA08035; Wed, 9 Sep 98 17:26:58 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA29399; Wed, 9 Sep 1998 14:26:56 -0700 (PDT) To: scwm-discuss@mit.edu Subject: A Favour... From: Greg Badros Date: 09 Sep 1998 14:26:55 -0700 Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm curious about a system-dependent problem I've noted in guile (and thus scwm). If you have a moment, I'd love to hear about the results of the below experiment. I'm trying to gain data regarding the behvaiour of the system call and a SIGINT issued on the controlling tty. Please email me directly, and I'll summarize results. >From an X11 xterm, run: $ guile guile> (system "xterm &") ;; note the xterm that appears guile> [ hit Ctrl-C ] Does the xterm that just appeared now disappear? (i.e. does it get terminated by the SIGINT that you sent via Ctrl-C) Please send me the answer to the above question along with: guile -v # and a last-updated date if tracking the CVS sources ldd `which guile` # I want to know if you are using glibc or not uname -a Thanks! Greg From owner-scwm-discuss@mit.edu Wed Sep 9 18:02:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12447 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:02:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA12441 for ; Wed, 9 Sep 1998 18:02:11 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA26387 for scwm-discuss@huis-clos.mit.edu; Wed, 9 Sep 1998 23:57:37 +0200 (CEST) Received: (qmail 1068 invoked by uid 115); 9 Sep 1998 20:44:10 -0000 To: scwm-discuss@mit.edu Subject: Some Advice References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Wed_Sep__9_22:44:09_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 09 Sep 1998 22:44:09 +0200 In-Reply-To: Greg Badros's message of "06 Sep 1998 10:22:54 -0700" Message-ID: Lines: 93 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Wed_Sep__9_22:44:09_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On 06 Sep 1998 10:22:54 -0700 >>>>> Greg Badros said: Greg> Argl.... is that similar to "argh"? :-) :-) Yes. But I was simultaneously choking myself while inflicting other pain, so that my tongue sticked out - that's the result then. Greg> There's slib. See Greg> http://angela.ctrl-c.liu.se/~calle/scheme/slib_toc.html I checked this out, but it did not seem to have an advice facility. Greg> I'll ask over on the guile list, too, but rolling our own may Greg> be the way to go (keeping the general case in mind). I have not yet manged to get a usable version. Because I will be offline for 10 days starting tomorrow, I'm including my half-bred advice.scm here. May someone with more scheme background improve it. Or use it as an inspiration to write a better version. Or something. Consider the code GPL'd, without warranty, etc., etc. Here we go: --Multipart_Wed_Sep__9_22:44:09_1998-1 Content-Type: text/plain; charset=US-ASCII ; FIXME: around does not work, ; neither does advising lamdas with variable number of arguemnts (defmacro-public defadvice (function param . body) "Advices FUNCTION with BODY. \(defadvice FUNCTION \(CLASS NAME\)\) FUNCTION is the function to advice. If CLASS is 'before, execute BODY before the function proper. If CLASS is 'after, execute BODY after the function proper. If CLASS is 'around, BODY is executed and must call the function proper. NAME is the name of this piece of advice. BODY is the piece of advice itself. Advice is active immediately. This is inspired by the Emacs-Lisp function of the same name but does support only a minimal subset of its features." (if (not (defined? function)) (error "Function not defined:" function)) (let ((source (procedure-source (eval function)))) (if (not (eq? (car source) 'lambda)) (error "Does not evaluate to a lambda expression:" function)) (let ((orig (string->symbol (string-append "ad-Orig-" (symbol->string function)))) (args (cadr source))) (list 'begin (if (not (defined? orig)) `(define ,orig ,function) ()) (case (car param) ((before) `(define ,function (lambda ,args ,@body ,(cons (eval function) args)))) ((after) `(define ,function (lambda ,args ,(cons (eval function) args) ,@body))) ((around) `(define ,function (lambda () (let ((ad-do-it FIXME)) ,@body)))) (else (error "CLASS must be 'before, 'around, or 'after:" (car param)))))))) (defmacro-public ad-unadvise (function) "Removes all advice defined on FUNCTION." (let ((orig (string->symbol (string-append "ad-Orig-" (symbol->string function))))) (if (not (defined? orig)) (error "Function not advised:" function)) `(begin (define ,function ,orig) (undefine ,orig)))) --Multipart_Wed_Sep__9_22:44:09_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Wed_Sep__9_22:44:09_1998-1-- From owner-scwm-discuss@mit.edu Wed Sep 9 18:02:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12446 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:02:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA12437 for ; Wed, 9 Sep 1998 18:02:09 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA26369 for scwm-discuss@huis-clos.mit.edu; Wed, 9 Sep 1998 23:57:34 +0200 (CEST) Received: (qmail 544 invoked by uid 115); 9 Sep 1998 19:58:55 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Sep 1998 21:58:54 +0200 In-Reply-To: Greg Badros's message of "09 Sep 1998 08:26:41 -0700" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 09 Sep 1998 08:26:41 -0700 >>>>> Greg Badros said: Greg> It'd still be cheaper to move the real window, anyway. The Greg> rubber-banding was designed mostly for performance reasons when Greg> X servers were slow. For resizing this is argument is still valid. Try opaque resizing of a Netscape window with a complicated page inside, on a box that is not quite state of the art. But in general, rubber-banding is getting a bit obsolete. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Sep 9 18:02:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12450 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:02:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from pong.Austria.EU.net (pong.ping.at [193.81.13.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA12445 for ; Wed, 9 Sep 1998 18:02:14 -0400 Received: (from uucp@localhost) by pong.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA26396 for scwm-discuss@huis-clos.mit.edu; Wed, 9 Sep 1998 23:57:39 +0200 (CEST) Received: (qmail 1139 invoked by uid 115); 9 Sep 1998 21:46:30 -0000 To: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Sep 1998 23:46:29 +0200 In-Reply-To: Greg Badros's message of "08 Sep 1998 08:39:26 -0700" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 08 Sep 1998 08:39:26 -0700 >>>>> Greg Badros said: Greg> It needs of allowing a binding to a single click and a double Greg> click where the single click action is decidedly unobtrusive, Greg> though (i.e., I shouldn't have to pay the price of the 100ms Greg> [or whatever] delay to verify that a click isn't a double-click Greg> if my single-click action can be safely executed before the Greg> double-click action). Bind action A to 'buttonrelease, action B to 'double-click. If you click, A will be executed immediately. If the click turns out to be a double-click, A will be executed a second time[1], and B will be executed afterwards. Robbe [1] Maybe we want to optimize this away with some clever semantics. OTOH this is probably unnecessary, since this would only make sense for unobtrusive (and fast!) actions. -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Sep 9 18:11:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12635 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:11:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA12632 for ; Wed, 9 Sep 1998 18:11:48 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA21380; Wed, 9 Sep 98 18:07:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA29468; Wed, 9 Sep 1998 15:07:09 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Some Advice References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 09 Sep 1998 15:07:08 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Sep 1998 22:44:09 +0200" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Greg> Argl.... is that similar to "argh"? :-) :-) > > Yes. But I was simultaneously choking myself while inflicting other > pain, so that my tongue sticked out - that's the result then. :-) > Greg> I'll ask over on the guile list, too, but rolling our own may > Greg> be the way to go (keeping the general case in mind). > > I have not yet manged to get a usable version. Because I will be > offline for 10 days starting tomorrow, I'm including my half-bred > advice.scm here. May someone with more scheme background improve it. > Or use it as an inspiration to write a better version. Or something. > > Consider the code GPL'd, without warranty, etc., etc. Here we go: Good -- thanks for the starting point... Maciej is a whiz w/ scheme, too, so perhaps he can get this working (though I imagine he's got a pretty full plate as it is for a while!) Enjoy your vacation (at least away from computers, hopefully a real vacation!) Greg From owner-scwm-discuss@mit.edu Wed Sep 9 18:31:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12928 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:31:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA12922 for ; Wed, 9 Sep 1998 18:30:58 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA27330; Wed, 9 Sep 98 18:26:22 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA29501; Wed, 9 Sep 1998 15:26:16 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 09 Sep 1998 15:26:15 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Sep 1998 21:58:54 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 09 Sep 1998 08:26:41 -0700 > >>>>> Greg Badros said: > > Greg> It'd still be cheaper to move the real window, anyway. The > Greg> rubber-banding was designed mostly for performance reasons when > Greg> X servers were slow. > > For resizing this is argument is still valid. Try opaque resizing of a > Netscape window with a complicated page inside, on a box that is not > quite state of the art. Agreed though only because the client is getting the ConfigureNotify event (i.e., if Netscape didn't reformat the page, it wouldn't be a big deal -- of course, then the window wouldn't resize nicely since the contents wouldn't be re-exposed properly). > But in general, rubber-banding is getting a bit obsolete. I tend to agree, and coupled with being harder to support, it makes it a pretty unattractive alternative. I do like it for the interactive placing and sizing of new windows, but I don't use interactive-placement. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 18:35:22 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA12976 for scwm-discuss-outgoing; Wed, 9 Sep 1998 18:35:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA12973 for ; Wed, 9 Sep 1998 18:35:20 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03274; Wed, 9 Sep 98 18:30:41 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA29504; Wed, 9 Sep 1998 15:30:38 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: Greg Badros Date: 09 Sep 1998 15:30:38 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Sep 1998 23:46:29 +0200" Message-Id: Lines: 39 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 08 Sep 1998 08:39:26 -0700 > >>>>> Greg Badros said: > > Greg> It needs of allowing a binding to a single click and a double > Greg> click where the single click action is decidedly unobtrusive, > Greg> though (i.e., I shouldn't have to pay the price of the 100ms > Greg> [or whatever] delay to verify that a click isn't a double-click > Greg> if my single-click action can be safely executed before the > Greg> double-click action). > > Bind action A to 'buttonrelease, action B to 'double-click. If you > click, A will be executed immediately. If the click turns out to be a > double-click, A will be executed a second time[1], and B will be > executed afterwards. Given this analogy, then, the only difference between the 'click I suggested and 'buttonrelease is that the 'click doesn't get sent a second time on the second click of a 'double-click. > [1] Maybe we want to optimize this away with some clever semantics. > OTOH this is probably unnecessary, since this would only make sense > for unobtrusive (and fast!) actions. I like 'click for first clicks immediately (and not the second of a double) 'single-click for first clicks after the timeout so they are definitely not double-clicks 'double-click for double clicks 'release for every release (twice on a double click). This is the current wording in events.gjb. I think you're basically agreeing, right? The clever semantics is the extra 'click event. Greg From owner-scwm-discuss@mit.edu Wed Sep 9 19:43:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13756 for scwm-discuss-outgoing; Wed, 9 Sep 1998 19:43:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA13753 for ; Wed, 9 Sep 1998 19:43:39 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA14235; Wed, 9 Sep 98 19:39:03 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id QAA21026; Wed, 9 Sep 1998 16:38:45 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id QAA20187; Wed, 9 Sep 1998 16:38:43 -0700 To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: From: cwitty@newtonlabs.com (Carl R. Witty) Date: 09 Sep 1998 16:38:43 -0700 In-Reply-To: Greg Badros's message of "09 Sep 1998 15:26:15 -0700" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Robert Bihlmeyer writes: > > > Hi, > > > > >>>>> On 09 Sep 1998 08:26:41 -0700 > > >>>>> Greg Badros said: > > > > Greg> It'd still be cheaper to move the real window, anyway. The > > Greg> rubber-banding was designed mostly for performance reasons when > > Greg> X servers were slow. > > > > For resizing this is argument is still valid. Try opaque resizing of a > > Netscape window with a complicated page inside, on a box that is not > > quite state of the art. > > Agreed though only because the client is getting the ConfigureNotify > event (i.e., if Netscape didn't reformat the page, it wouldn't be a big > deal -- of course, then the window wouldn't resize nicely since the > contents wouldn't be re-exposed properly). I started to write a window manager several years ago. It used opaque resize (because I was too lazy to write rubber-banding), on a slow machine. To make performance acceptable, I only resized the client window if the mouse hadn't moved for half a second; it worked pretty well. Maybe scwm should do this as well? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Sep 10 10:23:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA18026 for scwm-discuss-outgoing; Thu, 10 Sep 1998 10:23:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA18023 for ; Thu, 10 Sep 1998 10:23:27 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA18985; Thu, 10 Sep 98 10:18:10 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id KAA21841 for ; Thu, 10 Sep 1998 10:16:35 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Event rewrite proposal, revised References: <"egSQU.0.874.cBnzr"@tequila.systemsz.cs.yale.edu> Date: 10 Sep 1998 10:16:28 -0400 Message-Id: <5l4sugqchv.fsf@tequila.systemsz.cs.yale.edu> Lines: 11 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Carl" == Carl R Witty writes: Carl> slow machine. To make performance acceptable, I only resized the Carl> client window if the mouse hadn't moved for half a second; it worked Carl> pretty well. Is it possible to get something inbetween: resize the window immediately, but make sure the application only receives ConfigureNotify events at most every half second ? Stefan "who always uses opaque-resize" From owner-scwm-discuss@mit.edu Thu Sep 10 10:50:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA18260 for scwm-discuss-outgoing; Thu, 10 Sep 1998 10:50:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA18257 for ; Thu, 10 Sep 1998 10:50:03 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA28608; Thu, 10 Sep 98 10:45:17 EDT Received: by tis.bellhow.com; id KAA26113; Thu, 10 Sep 1998 10:45:18 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma025945; Thu, 10 Sep 98 10:44:40 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA23407 for ; Thu, 10 Sep 1998 10:44:40 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: BUG: Windows opening in random viewports. Date: Thu, 10 Sep 1998 14:44:39 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <35fdde41.249645190@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA18258 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm using the 9/10/98 snapshot. Well, not exactly random. Just (0.0). Move to a viewport that is not (0.0). Start a program from a menu or an xterm. The window appears in the current viewport, but appears in the (0.0) viewport in the pager. Move to the (0.0) viewport. The new window is there! If you just move the window around (without switching viewports), it pops to the right viewport in the pager, and stays where you moved it. If you try to drag it using mouse 2 in the pager (without switching viewports), wierd things happen. Sometimes it moves to the right location but in a different viewport. Sometimes it goes away from *any* viewport, but is still in the window list. If you select it using the window list menu, it appears at 0,0 in the 0.0 viewport. Dale From owner-scwm-discuss@mit.edu Thu Sep 10 11:09:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18447 for scwm-discuss-outgoing; Thu, 10 Sep 1998 11:09:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18441 for ; Thu, 10 Sep 1998 11:08:53 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12958; Thu, 10 Sep 98 11:04:10 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA00466; Thu, 10 Sep 1998 08:01:43 -0700 (PDT) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"egSQU.0.874.cBnzr"@tequila.systemsz.cs.yale.edu> <5l4sugqchv.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 10 Sep 1998 08:01:43 -0700 In-Reply-To: Stefan Monnier's message of "10 Sep 1998 10:16:28 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Carl" == Carl R Witty writes: > Carl> slow machine. To make performance acceptable, I only resized the > Carl> client window if the mouse hadn't moved for half a second; it worked > Carl> pretty well. > > Is it possible to get something inbetween: resize the window immediately, > but make sure the application only receives ConfigureNotify events at most > every half second ? Almost anything is possible. This seems pretty easy, too. I like the two ideas a lot and just added a note on the TODO list. Thanks, guys! Greg From owner-scwm-discuss@mit.edu Thu Sep 10 11:51:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18731 for scwm-discuss-outgoing; Thu, 10 Sep 1998 11:51:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18728 for ; Thu, 10 Sep 1998 11:51:28 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA21050; Thu, 10 Sep 98 11:46:41 EDT Received: (qmail 9913 invoked by uid 501); 10 Sep 1998 15:46:39 -0000 Message-Id: <19980910084639.A9801@molehill.org> Date: Thu, 10 Sep 1998 08:46:39 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Tue, Sep 08, 1998 at 04:48:51PM -0700 X-Tom-Swifty: "... and lose a few", said Tom winsomely. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm seeing similar (I think) problems with the cvs tree from last night. visible? and related functions in wininfo.scm don't work reliably at all. The circulate functions seem to keep circulating back to things on the 0,0 viewport. Changing viewports with the keyboard one viewport width/height a time frequently jumps to the viewport in question, then immediately to another one, to the right or below the intended one. Sometimes when that happens a window on the intended viewport moves to 0,0. eventually everything's on the 0,0 viewport and it's usable at least. I wiped my tree and got a fresh set from cvs to make sure I didn't have badold changes, and no better. Do I need to get a different branch? It doesn't look like wininfo.scm was modified at all with window-viewport-location. (and when I try to make the reasonable modifications, things get even worse) On 980908, Greg Badros wrote: > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > Greg Badros writes: > > > > > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > > > > > I've just moved back to 0.8a after trying the latest snapshot (before > > > > your fix). Window positioning seems to be completely insane - windows > > > > > > Before which fix? What does your changed.c file contain? > > > > Before 'fMWMMenus the undefined' one. I don't have files handy - I've > > removed the tree. :-( > > Well if you ever see it again, I'll gladly look into it. Last week > there were lots of related problems as I substantially and pervasively > changed the way window positions were managed, but things seem stable > again to me. > > BTW, I just added the request for changed.c to the BUG-REPORTING file, > since it can be really useful for tracking down exactly what version you > are using -- it gets its revision number incremented at each commit). > > Thanks, > Greg From owner-scwm-discuss@mit.edu Thu Sep 10 11:57:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA18782 for scwm-discuss-outgoing; Thu, 10 Sep 1998 11:57:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA18779 for ; Thu, 10 Sep 1998 11:57:14 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23196; Thu, 10 Sep 98 11:52:29 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA00525; Thu, 10 Sep 1998 08:50:31 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> From: Greg Badros Date: 10 Sep 1998 08:50:31 -0700 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 08:46:39 -0700" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I'm seeing similar (I think) problems with the cvs tree from last > night. > > visible? and related functions in wininfo.scm don't work reliably > at all. The circulate functions seem to keep circulating back to > things on the 0,0 viewport. Changing viewports with the keyboard > one viewport width/height a time frequently jumps to the viewport > in question, then immediately to another one, to the right or > below the intended one. Sometimes when that happens a window on > the intended viewport moves to 0,0. eventually everything's on > the 0,0 viewport and it's usable at least. > > I wiped my tree and got a fresh set from cvs to make sure > I didn't have badold changes, and no better. Do I need to > get a different branch? It doesn't look like wininfo.scm > was modified at all with window-viewport-location. > > (and when I try to make the reasonable modifications, things > get even worse) Yea, this is still fallout from the window positioning rewrite. Thanks for the testing. I'll continue rewriting and testing these cases today and hopefully by end of day many of these problems will be gone. Thanks Greg From owner-scwm-discuss@mit.edu Thu Sep 10 13:45:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA19355 for scwm-discuss-outgoing; Thu, 10 Sep 1998 13:45:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA19352 for ; Thu, 10 Sep 1998 13:45:40 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA11467; Thu, 10 Sep 98 13:40:56 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id UAA04925; Thu, 10 Sep 1998 20:40:54 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id TAA12139; Thu, 10 Sep 1998 19:40:55 +0200 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: A Favour... References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 10 Sep 1998 19:40:55 +0200 In-Reply-To: Greg Badros's message of "09 Sep 1998 14:26:55 -0700" Message-Id: Lines: 44 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > Please send me the answer to the above question along with: > $ guile guile> (system "xterm &") 0 guile> ERROR: User interrupt ABORT: (signal) guile> Terminal disappears. $ guile -v Guile 1.3a Copyright (c) 1995, 1996, 1997 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. $ $ ldd `which guile` libguile.so.3 => /usr/lib/libguile.so.3 libdl.so.1 => /lib/libdl.so.1.7.14 libreadline.so.2 => /usr/lib/libreadline.so.2 libtermcap.so.2 => /lib/libtermcap.so.2.0.8 libm.so.5 => /lib/libm.so.5.0.6 libc.so.5 => /lib/libc.so.5.3.12 $ $ uname -a Linux XXXX 2.0.30 #1 Tue Mar 3 10:50:17 EST 1998 i686 unknown The system is Redhat 4.2, Guile is a 19980806 snapshot. -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Thu Sep 10 14:18:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA19832 for scwm-discuss-outgoing; Thu, 10 Sep 1998 14:18:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA19829 for ; Thu, 10 Sep 1998 14:18:33 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA24125; Thu, 10 Sep 98 14:13:59 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id LAA15646; Thu, 10 Sep 1998 11:13:55 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id LAA24691; Thu, 10 Sep 1998 11:13:54 -0700 To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"egSQU.0.874.cBnzr"@tequila.systemsz.cs.yale.edu> <5l4sugqchv.fsf@tequila.systemsz.cs.yale.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 10 Sep 1998 11:13:53 -0700 In-Reply-To: Stefan Monnier's message of "10 Sep 1998 10:16:28 -0400" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Carl" == Carl R Witty writes: > Carl> slow machine. To make performance acceptable, I only resized the > Carl> client window if the mouse hadn't moved for half a second; it worked > Carl> pretty well. > > Is it possible to get something inbetween: resize the window immediately, > but make sure the application only receives ConfigureNotify events at most > every half second ? I see I wasn't very clear. In a window manager like scwm (and all the other window managers I've looked at in detail), each window on the screen actually has the client window (the Window created by the client) reparented into a Window created by the window manager. What I did was resize the window manager parent window (so that you got feedback on exactly how big the window was), but I only resized the client window after the mouse hadn't moved for half a second. Therefore, while a resize was taking place, parts of the client window coule be cropped by the window manager window, and parts of the window manager window which would normally always be covered by the client window could be exposed. Is this the same thing you were proposing? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Sep 10 14:19:14 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA19865 for scwm-discuss-outgoing; Thu, 10 Sep 1998 14:19:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA19858 for ; Thu, 10 Sep 1998 14:19:09 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11235; Thu, 10 Sep 98 14:14:27 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA00871; Thu, 10 Sep 1998 11:14:22 -0700 (PDT) To: dale.smith@bellhow.com, Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: BUG: Windows opening in random viewports. References: <35fdde41.249645190@smtp> From: Greg Badros Date: 10 Sep 1998 11:14:22 -0700 In-Reply-To: smithd@bellhow.com's message of "Thu, 10 Sep 1998 14:44:39 GMT" Message-Id: Lines: 7 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk This bug and many others related ones are now fixed in the repository, I think. Please try to exercise the code as you have been and keep the nice bug reports coming. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Sep 10 14:26:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA20106 for scwm-discuss-outgoing; Thu, 10 Sep 1998 14:26:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA20103 for ; Thu, 10 Sep 1998 14:26:46 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14193; Thu, 10 Sep 98 14:22:18 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA00893; Thu, 10 Sep 1998 11:22:16 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: Stefan Monnier , scwm-discuss@mit.edu Subject: Re: Event rewrite proposal, revised References: <"egSQU.0.874.cBnzr"@tequila.systemsz.cs.yale.edu> <5l4sugqchv.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 10 Sep 1998 11:22:15 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "10 Sep 1998 11:13:53 -0700" Message-Id: Lines: 42 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > Stefan Monnier writes: > > > >>>>> "Carl" == Carl R Witty writes: > > Carl> slow machine. To make performance acceptable, I only resized the > > Carl> client window if the mouse hadn't moved for half a second; it worked > > Carl> pretty well. > > > > Is it possible to get something inbetween: resize the window immediately, > > but make sure the application only receives ConfigureNotify events at most > > every half second ? > > I see I wasn't very clear. > > In a window manager like scwm (and all the other window managers I've > looked at in detail), each window on the screen actually has the > client window (the Window created by the client) reparented into a > Window created by the window manager. What I did was resize the > window manager parent window (so that you got feedback on exactly how > big the window was), but I only resized the client window after the > mouse hadn't moved for half a second. > > Therefore, while a resize was taking place, parts of the client window > coule be cropped by the window manager window, and parts of the window > manager window which would normally always be covered by the client > window could be exposed. > > Is this the same thing you were proposing? Sounds like what Stefan was proposing. I misinterpreted your initial comments (as you suspected)-- I thought you were saying you did the full resize (frame + client windows) but had the resize track the mouse sluggishly. In any case, postponing resize of the client window to at most once every n seconds seems very doable -- and n should probably be a WM_HINT given by the application (e.g., netscape would hint that n should be higher, while xlogo could hint that n be 0 [no limit]). Of course user can override on a per window basis. Greg From owner-scwm-discuss@mit.edu Thu Sep 10 16:29:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA20927 for scwm-discuss-outgoing; Thu, 10 Sep 1998 16:29:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA20924 for ; Thu, 10 Sep 1998 16:29:55 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA00394; Thu, 10 Sep 98 16:27:00 EDT Received: (qmail 12750 invoked by uid 501); 10 Sep 1998 20:27:03 -0000 Message-Id: <19980910132702.A12667@molehill.org> Date: Thu, 10 Sep 1998 13:27:02 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Sep 10, 1998 at 08:50:31AM -0700 X-Tom-Swifty: "I hate climbing this winding staircase", said Tom coyly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk Your changes took care of the jumping windows, but in-viewport-any-desk? still gave bogus results. In some cases, the window circulation would SEEM to work, but it was an illusion. What it looks like was happening is that circulate would circulate to one of the windows in the 0,0 viewport, presumably give it focus, move the mouse pointer into it, but not warp to it; then focus-follows-mouse would kick in, and give focus to whatever window the mouse ended up in in the current viewport. If you have similar window layouts on the current viewport and the 0,0 viewport, it appears to work. Looking at wininfo.scm, the cause seems pretty clear: (define*-public (in-viewport-any-desk? #&optional (win (get-window))) (if win (apply rectangle-overlap? (append (window-position win) (window-frame-size win) (list 0 0) (map (lambda (p) (- p 1)) (display-size)))))) This compares virtual position and the window size with the 0,0 viewport. My first attempted fix was to change window-position to window-viewport-position. This gave undefined errors, so I added :use-module (app scwm base) in the define-module form. This didn't work either; I'm afraid the various failure modes have blurred together and I don't remember what it did do. I then tried defining in-viewport-any-desk? as: (define*-public (in-viewport-any-desk? #&optional (win (get-window))) (if win (or (sticky? win) (apply rectangle-overlap? (append (window-position win) (window-frame-size win) (viewport-position) (map (lambda (p) (- p 1)) (display-size))))))) which seems reasonable and straightforward; after this, my jumping viewport/jumping window problem returned - moving into a viewport would frequently move immediately to another viewport, and sometimes move one of the windows to +0+0. I'm more interested in understanding what's going on, and why my "fixes" fail, than I am in just getting this working; I'd like to be more useful on this, and it's obvious I'm still not wrapping my mind in quite the right shape. On 980910, Greg Badros wrote: > Todd Larason writes: > > > I'm seeing similar (I think) problems with the cvs tree from last > > night. > > > > visible? and related functions in wininfo.scm don't work reliably > > at all. The circulate functions seem to keep circulating back to > > things on the 0,0 viewport. Changing viewports with the keyboard > > one viewport width/height a time frequently jumps to the viewport > > in question, then immediately to another one, to the right or > > below the intended one. Sometimes when that happens a window on > > the intended viewport moves to 0,0. eventually everything's on > > the 0,0 viewport and it's usable at least. > > > > I wiped my tree and got a fresh set from cvs to make sure > > I didn't have badold changes, and no better. Do I need to > > get a different branch? It doesn't look like wininfo.scm > > was modified at all with window-viewport-location. > > > > (and when I try to make the reasonable modifications, things > > get even worse) > > Yea, this is still fallout from the window positioning rewrite. Thanks > for the testing. I'll continue rewriting and testing these cases today > and hopefully by end of day many of these problems will be gone. > > Thanks > Greg From owner-scwm-discuss@mit.edu Thu Sep 10 17:42:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21316 for scwm-discuss-outgoing; Thu, 10 Sep 1998 17:42:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21312 for ; Thu, 10 Sep 1998 17:42:38 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA26102; Thu, 10 Sep 98 17:40:55 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA02761; Thu, 10 Sep 1998 14:40:53 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> From: Greg Badros Date: 10 Sep 1998 14:40:52 -0700 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 13:27:02 -0700" Message-Id: Lines: 73 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > Your changes took care of the jumping windows, but in-viewport-any-desk? > still gave bogus results. In some cases, the window circulation would > SEEM to work, but it was an illusion. I forgot to commit the change to in-viewport-any-desk? See below. > What it looks like was happening is that circulate would circulate to > one of the windows in the 0,0 viewport, presumably give it focus, move > the mouse pointer into it, but not warp to it; then focus-follows-mouse > would kick in, and give focus to whatever window the mouse ended up in > in the current viewport. If you have similar window layouts on the > current viewport and the 0,0 viewport, it appears to work. > > Looking at wininfo.scm, the cause seems pretty clear: > > (define*-public (in-viewport-any-desk? #&optional (win (get-window))) > (if win (apply rectangle-overlap? > (append > (window-position win) > (window-frame-size win) > (list 0 0) > (map (lambda (p) (- p 1)) (display-size)))))) > > This compares virtual position and the window size with the 0,0 > viewport. Exactly. > My first attempted fix was to change window-position to > window-viewport-position. This gave undefined errors, so I added > :use-module (app scwm base) in the define-module form. This didn't This should've worked -- that's my change (except I also revisited all the window-position calls and added a mess of documentation). Did you make installe from scheme/ after making the change? > work either; I'm afraid the various failure modes have blurred together > and I don't remember what it did do. > > I then tried defining in-viewport-any-desk? as: > > (define*-public (in-viewport-any-desk? #&optional (win (get-window))) > (if win (or (sticky? win) > (apply rectangle-overlap? > (append > (window-position win) > (window-frame-size win) > (viewport-position) > (map (lambda (p) (- p 1)) (display-size))))))) > > which seems reasonable and straightforward; after this, my jumping > viewport/jumping window problem returned - moving into a viewport would > frequently move immediately to another viewport, and sometimes move > one of the windows to +0+0. Not sure why you'd see this behaviour (and please let me know if you see it with my now committed change. > I'm more interested in understanding what's going on, and why my "fixes" > fail, than I am in just getting this working; I'd like to be more useful > on this, and it's obvious I'm still not wrapping my mind in quite the > right shape. My best guess is you ran the wrong binary after the change... the window jumping stuff shouldn't be related to the scheme code very much (if at all). I could be wrong, but please give me a clear explanation of what's happening if my very recent commit doesn't make things better (I fixed several other bugs in the scheme code as well). Greg From owner-scwm-discuss@mit.edu Thu Sep 10 18:03:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA21515 for scwm-discuss-outgoing; Thu, 10 Sep 1998 18:03:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA21512 for ; Thu, 10 Sep 1998 18:03:27 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA22136; Thu, 10 Sep 98 18:02:06 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA02815; Thu, 10 Sep 1998 15:01:57 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> From: Greg Badros Date: 10 Sep 1998 15:01:57 -0700 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 13:27:02 -0700" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I then tried defining in-viewport-any-desk? as: > > (define*-public (in-viewport-any-desk? #&optional (win (get-window))) > (if win (or (sticky? win) > (apply rectangle-overlap? > (append > (window-position win) > (window-frame-size win) > (viewport-position) > (map (lambda (p) (- p 1)) (display-size))))))) > > which seems reasonable and straightforward; after this, my jumping > viewport/jumping window problem returned - moving into a viewport would > frequently move immediately to another viewport, and sometimes move > one of the windows to +0+0. I take it back.. I see some strange behaviour with circulate, too. > I'm more interested in understanding what's going on, and why my "fixes" > fail, than I am in just getting this working; I'd like to be more useful > on this, and it's obvious I'm still not wrapping my mind in quite the > right shape. I still think your first fix (very similar to the one I'm using) should've worked, and I'm looking into what's going wrong with this version now. Greg From owner-scwm-discuss@mit.edu Thu Sep 10 18:47:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA21925 for scwm-discuss-outgoing; Thu, 10 Sep 1998 18:47:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA21921 for ; Thu, 10 Sep 1998 18:47:33 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA13748; Thu, 10 Sep 98 18:46:51 EDT Received: (qmail 14021 invoked by uid 501); 10 Sep 1998 22:46:52 -0000 Message-Id: <19980910154652.A13865@molehill.org> Date: Thu, 10 Sep 1998 15:46:52 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Sep 10, 1998 at 03:01:57PM -0700 X-Tom-Swifty: "You snake!" Tom rattled. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980910, Greg Badros wrote: > I take it back.. I see some strange behaviour with circulate, too. I'm seeing some problems other than the circulate ones. I'm going to try to describe exactly what they are to help narrow it down. fecundity:~% cat proj/scwm/scwm/scwm/changed.c char *szRepoLastChanged = "Thu Sep 10 17:44:05 EDT 1998 -- $Revision: 1.377 $"; scwm> (scwm-version) "post0.8a" scwm> (scwm-version-date ) "Thu Sep 10 17:44:05 EDT 1998 -- $Revision: 1.377 $" I've thrice verified that I have the corresponding scheme files installed as well. For this description, I'm using juhp.scwmrc with (set-edge-scroll! 0 0) replaced with (set-edge-scroll! (%x 100) (%y 100)) (set-edge-resistance! 1500 40) and no other changes. I have three windows open: scwm> (define xemacs-win (get-window)) # scwm> (define xterm1-win (get-window)) # scwm> (define xterm2-win (get-window)) # scwm> (window-position xemacs-win) (1152 0) scwm> (window-position xterm1-win) (1806 0) scwm> (window-position xterm2-win) (1806 349) scwm> (window-size xemacs-win) (584 827 80 57) scwm> (window-size xterm1-win) (484 316 80 24) scwm> (window-size xterm2-win) (484 316 80 24) scwm> (viewport-position) (1152 0) scwm> (display-size) (1152 864) (that is, an 1152x864 screen, the viewport currently on the top center section of a 3x3 desktop, a tall xemacs along the left side of the screen, and two normal sized xterms along the right side. There are no other windows.) A-{Left,Right,Up,Down} are bound to (move-screen -1 0) and so on, as appropriate to move by whole screens. I type A-Left, and am now on an empty screen. Judging by the mouse pointer changes against borders, it appears to be the top left one (0,0), as expected. I now type A-Right, and the correct display appears, then immediately goes blank again. Judging by the mouse pointer changes, I am now on the top right viewport. Using edge scroll, I move back to the top center viewport, and discover that xterm1 is now gone. Using edge sroll again, I move to the top left viewport, and find that xterm1 is now there, at +0+0. From owner-scwm-discuss@mit.edu Thu Sep 10 18:57:18 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22050 for scwm-discuss-outgoing; Thu, 10 Sep 1998 18:57:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22046 for ; Thu, 10 Sep 1998 18:57:17 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AB06963; Thu, 10 Sep 98 18:56:51 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA03080; Thu, 10 Sep 1998 15:56:46 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> <19980910154652.A13865@molehill.org> From: Greg Badros Date: 10 Sep 1998 15:56:45 -0700 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 15:46:52 -0700" Message-Id: Lines: 99 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980910, Greg Badros wrote: > > I take it back.. I see some strange behaviour with circulate, too. > > I'm seeing some problems other than the circulate ones. I'm going to try to > describe exactly what they are to help narrow it down. Ok... I'm currently fixing WarpToWindow as that is perhaps the main culprit. > fecundity:~% cat proj/scwm/scwm/scwm/changed.c > char *szRepoLastChanged = "Thu Sep 10 17:44:05 EDT 1998 -- $Revision: 1.377 $"; > > scwm> (scwm-version) > "post0.8a" > scwm> (scwm-version-date ) > "Thu Sep 10 17:44:05 EDT 1998 -- $Revision: 1.377 $" Ok. > > I've thrice verified that I have the corresponding scheme files installed > as well. > > For this description, I'm using juhp.scwmrc with > (set-edge-scroll! 0 0) > replaced with > > (set-edge-scroll! (%x 100) (%y 100)) > (set-edge-resistance! 1500 40) > > and no other changes. > > > I have three windows open: > > scwm> (define xemacs-win (get-window)) > # > scwm> (define xterm1-win (get-window)) > # > scwm> (define xterm2-win (get-window)) > # > scwm> (window-position xemacs-win) > (1152 0) > scwm> (window-position xterm1-win) > (1806 0) > scwm> (window-position xterm2-win) > (1806 349) > scwm> (window-size xemacs-win) > (584 827 80 57) > scwm> (window-size xterm1-win) > (484 316 80 24) > scwm> (window-size xterm2-win) > (484 316 80 24) > scwm> (viewport-position) > (1152 0) > scwm> (display-size) > (1152 864) > > (that is, an 1152x864 screen, the viewport currently on the top center > section of a 3x3 desktop, a tall xemacs along the left side of the > screen, and two normal sized xterms along the right side. There are no > other windows.) > > A-{Left,Right,Up,Down} are bound to (move-screen -1 0) and so on, as > appropriate to move by whole screens. Very nice description! > > I type A-Left, and am now on an empty screen. Judging by the mouse pointer > changes against borders, it appears to be the top left one (0,0), as > expected. I now type A-Right, and the correct display appears, then > immediately goes blank again. Judging by the mouse pointer changes, > I am now on the top right viewport. > > Using edge scroll, I move back to the top center viewport, and discover > that xterm1 is now gone. Using edge sroll again, I move to the top left > viewport, and find that xterm1 is now there, at +0+0. Can you reproduce this w/ more primitive functions? move-screen is defined in juhp.scwmrc, so I neither wrote it nor want to support it necessarily. In particular, I've not scanned for new misuses of window-position in the .scwmrc files, so all bets are off there, still. Anything defined in scheme/* or sample.scwmrc/gjb.scwmrc is far better for me to test with. Ideally, reproducing with as few levels of abstraction as possible (e.g., with a primitive if the primitive is buggy). I've gotta check in the fix I've got now, and it could conceivably fix things for you... if not I'll delve into juhp.scwmrc first thing in the morning (I've gotta go play tennis -- it's too nice of a day out here in Seattle to be indoors!) Thanks! Greg From owner-scwm-discuss@mit.edu Thu Sep 10 19:21:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA22470 for scwm-discuss-outgoing; Thu, 10 Sep 1998 19:21:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA22467 for ; Thu, 10 Sep 1998 19:21:30 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA12078; Thu, 10 Sep 98 19:21:20 EDT Received: (qmail 14300 invoked by uid 501); 10 Sep 1998 23:21:19 -0000 Message-Id: <19980910162119.A14269@molehill.org> Date: Thu, 10 Sep 1998 16:21:19 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> <19980910154652.A13865@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Sep 10, 1998 at 03:56:45PM -0700 X-Tom-Swifty: "I've grown fat on the contents of charity packages", said Tom carefully. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980910, Greg Badros wrote: > Ok... I'm currently fixing WarpToWindow as that is perhaps the main culprit. That looks like it! 1.378 seems much better - circulate and the move-screen problem are both fixed. And it looks like the resizing-window-on-recapture thing may hve been fixed today, too. At least, that last restart didn't resize any noticably, while others earlier this morning still did. > Can you reproduce this w/ more primitive functions? move-screen is > defined in juhp.scwmrc I'm sorry; if I'd realized move-screen wasn't primitive, I'd have looked deeper before writing. > (I've gotta go play tennis -- it's too nice of a day out here in > Seattle to be indoors!) lucky you! here in Portland too, but I'm inside anyway. From owner-scwm-discuss@mit.edu Fri Sep 11 00:12:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA23980 for scwm-discuss-outgoing; Fri, 11 Sep 1998 00:12:44 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA23977 for ; Fri, 11 Sep 1998 00:12:40 -0400 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA07901; Fri, 11 Sep 98 00:12:38 EDT Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.8.8/8.6.4) with SMTP id AAA08443 for ; Fri, 11 Sep 1998 00:13:00 -0400 (EDT) Message-Id: <199809110413.AAA08443@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: scwm-discuss@mit.edu X-Attribution: Eric Subject: question about scwm philosophy :) Date: Fri, 11 Sep 1998 00:12:59 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk In placement.c, the PlaceWindow code uses a scheme property on the scheme window representation, which strikes me as a good way to do such things, and generally better than before and after hooks... I'm curious why it's not done anywhere else? (I'd like to extend it to some functionality in ChangeDesks and MoveViewportInternal (and/or MovePswToCurrentPosition) so I can do clever things with the virtual desktop :) -Eric From owner-scwm-discuss@mit.edu Fri Sep 11 03:48:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA25589 for scwm-discuss-outgoing; Fri, 11 Sep 1998 03:48:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA25586 for ; Fri, 11 Sep 1998 03:48:42 -0400 Received: from kurims.kurims.kyoto-u.ac.jp by MIT.EDU with SMTP id AA03913; Fri, 11 Sep 98 03:48:36 EDT Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id QAA07546; Fri, 11 Sep 1998 16:48:18 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id QAA01570; Fri, 11 Sep 1998 16:48:19 +0900 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 11 Sep 1998 16:48:19 +0900 In-Reply-To: Robert Bihlmeyer's message of "05 Sep 1998 11:08:16 +0200" Message-Id: Lines: 34 X-Mailer: Gnus v5.6.33/XEmacs 21.0 - "Erzgeberg-pre1" Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Robbe" == Robert Bihlmeyer writes: >>>>> On Thu, 3 Sep 1998 20:32:45 +0100 (BST) >>>>> Mark Toller said: Mark> I personally never use a desktop that is larger than my Mark> available screen space (1152x864), and the way (by default?) Mark> that scwm scrolls when the mouse hits the edge irritates me Mark> - I keep hitting it when I go to scroll Netscapes window Mark> (always fully maximised). Robbe> Me too. Just put the following (from my scwmrc) into your Robbe> scwmrc: Robbe> (set-desk-size! 1 1) ; desktops are good, paging is Robbe> evil Robbe> No scrolling, just a couple of desktops. Actually pages can be invaluable when you have a window larger than the screen: eg very large pictures (or xfig on my old notebook).... Robbe> I think the best we can do is a tool like Emacs's "custom": Robbe> one that emits it's own config-settings, understands and Robbe> changes just these, and leaves other code alone. All things Robbe> should be controllable from this tool, of course. Users Robbe> would have no need to hand-edit the scwmrc, but could if Robbe> they wanted. Sounds right. -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Fri Sep 11 03:55:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA25658 for scwm-discuss-outgoing; Fri, 11 Sep 1998 03:55:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA25655 for ; Fri, 11 Sep 1998 03:55:16 -0400 Received: from kurims.kurims.kyoto-u.ac.jp by MIT.EDU with SMTP id AA04477; Fri, 11 Sep 98 03:55:08 EDT Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id QAA07571; Fri, 11 Sep 1998 16:54:26 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id QAA01572; Fri, 11 Sep 1998 16:54:26 +0900 To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> <19980910154652.A13865@molehill.org> X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 11 Sep 1998 16:54:26 +0900 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 15:46:52 -0700" Message-Id: Lines: 12 X-Mailer: Gnus v5.6.33/XEmacs 21.0 - "Erzgeberg-pre1" Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "TL" == Todd Larason writes: TL> For this description, I'm using juhp.scwmrc with TL> (set-edge-scroll! 0 0) replaced with Wow! Somebody's actually using my config file. Thanks! ;-) Jens -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Fri Sep 11 11:01:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA27598 for scwm-discuss-outgoing; Fri, 11 Sep 1998 11:01:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA27590 for ; Fri, 11 Sep 1998 11:00:51 -0400 Received: from [128.95.1.122] by MIT.EDU with SMTP id AA17026; Fri, 11 Sep 98 10:58:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA09071; Fri, 11 Sep 1998 07:56:53 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: <19980910084639.A9801@molehill.org> <19980910132702.A12667@molehill.org> <19980910154652.A13865@molehill.org> <19980910162119.A14269@molehill.org> From: Greg Badros Date: 11 Sep 1998 07:56:53 -0700 In-Reply-To: Todd Larason's message of "Thu, 10 Sep 1998 16:21:19 -0700" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980910, Greg Badros wrote: > > Ok... I'm currently fixing WarpToWindow as that is perhaps the main culprit. > > That looks like it! 1.378 seems much better - circulate and the move-screen > problem are both fixed. > > And it looks like the resizing-window-on-recapture thing may hve been > fixed today, too. At least, that last restart didn't resize any noticably, > while others earlier this morning still did. Interesting... an unintentional side-effect, if so. Please confirm (others, too?) if this really is the case. (I've never reliably reproduced it, but haven't tried that hard either as I figure Maciej can fix that one as he was just finishing up reworking lots of that code before his vacation). > > Can you reproduce this w/ more primitive functions? move-screen is > > defined in juhp.scwmrc > > I'm sorry; if I'd realized move-screen wasn't primitive, I'd have > looked deeper before writing. Don't be sorry-- something to reproduce is always better than nothing to work with. I just didn't have time at the end of the day yesterday to do the bit of extra digging. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 11 11:09:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA27667 for scwm-discuss-outgoing; Fri, 11 Sep 1998 11:09:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA27662 for ; Fri, 11 Sep 1998 11:09:00 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA21328; Fri, 11 Sep 98 11:08:59 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09099; Fri, 11 Sep 1998 08:08:54 -0700 (PDT) To: Eric Moore Cc: scwm-discuss@mit.edu Subject: Re: question about scwm philosophy :) References: <199809110413.AAA08443@chopin.chem.cmu.edu> From: Greg Badros Date: 11 Sep 1998 08:08:54 -0700 In-Reply-To: Eric Moore's message of "Fri, 11 Sep 1998 00:12:59 -0400" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Eric Moore writes: > In placement.c, the PlaceWindow code uses a scheme property on the > scheme window representation, which strikes me as a good way to do > such things, and generally better than before and after hooks... I'm > curious why it's not done anywhere else? (I'd like to extend it to > some functionality in ChangeDesks and MoveViewportInternal (and/or > MovePswToCurrentPosition) so I can do clever things with the virtual > desktop :) Well, it is done a couple of other places... see constraint-stacking.scm for how I use it to get z-value (stacking-order) constraints to work. There was also some discussion before with Christian Lynbech about using a modified guile debugging evaluator to use properties to manage hooks on all procedures. In some cases there is no particularly good object to attach the property to, so a hook variable needs to be used instead. I guess as a general thing, though, I'm interested in gaining experience with the pros and cons of the various extension mechanisms. There are lots of possibilities, and I've not yet thought hard about which is best in what circumstances. More comments and feedback are always appreciated.... why do you like property-based hooks better than explicit variable hooks? Greg From owner-scwm-discuss@mit.edu Fri Sep 11 11:20:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA27819 for scwm-discuss-outgoing; Fri, 11 Sep 1998 11:20:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA27816 for ; Fri, 11 Sep 1998 11:20:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA21219; Fri, 11 Sep 98 11:20:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09109; Fri, 11 Sep 1998 08:20:16 -0700 (PDT) To: Jens-Ulrik Petersen Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Scwm vs the rest References: <13453.199809031932@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 11 Sep 1998 08:20:16 -0700 In-Reply-To: Jens-Ulrik Petersen's message of "11 Sep 1998 16:48:19 +0900" Message-Id: Lines: 49 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jens-Ulrik Petersen writes: > >>>>> "Robbe" == Robert Bihlmeyer writes: > > >>>>> On Thu, 3 Sep 1998 20:32:45 +0100 (BST) > >>>>> Mark Toller said: > > Mark> I personally never use a desktop that is larger than my > Mark> available screen space (1152x864), and the way (by default?) > Mark> that scwm scrolls when the mouse hits the edge irritates me > Mark> - I keep hitting it when I go to scroll Netscapes window > Mark> (always fully maximised). > > Robbe> Me too. Just put the following (from my scwmrc) into your > Robbe> scwmrc: > > Robbe> (set-desk-size! 1 1) ; desktops are good, paging is > Robbe> evil > > Robbe> No scrolling, just a couple of desktops. > > Actually pages can be invaluable when you have a window larger than the > screen: eg very large pictures (or xfig on my old notebook).... Moving the viewport and moving all the windows on the desk are duals. If you only have one large window, it's just as easy to move that window as it is to move the viewport to see the different parts of that window. (The difference between moving a frame over a large piece of paper vs. moving the paper underneath the stationary frame). When there are multiple windows that you want spread out over more space than your physical display is when the large desks (bigger than the physical display) become a big win, it seems. > Robbe> I think the best we can do is a tool like Emacs's "custom": > Robbe> one that emits it's own config-settings, understands and > Robbe> changes just these, and leaves other code alone. All things > Robbe> should be controllable from this tool, of course. Users > Robbe> would have no need to hand-edit the scwmrc, but could if > Robbe> they wanted. > > Sounds right. Yep. I've been extending the X resource stuff to be a bit more useful and dynamic lately; that mechanism could provide another more familiar (to X11 users) and equally powerful mechanism (though a bit clumsier to implement, perhaps) for controlling user-level customization. Greg From owner-scwm-discuss@mit.edu Fri Sep 11 11:22:08 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA27854 for scwm-discuss-outgoing; Fri, 11 Sep 1998 11:22:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA27851 for ; Fri, 11 Sep 1998 11:22:07 -0400 Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.238]) id QQfgjt29304; Fri, 11 Sep 1998 15:22:06 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id LAA14974; Fri, 11 Sep 1998 11:21:13 -0400 To: Maciej Stachowiak Subject: scwm.el Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 11 Sep 1998 11:21:13 -0400 Message-ID: Lines: 18 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am leaving on a 2 week vacation tonight. If you are experiencing a bug in scwm.el, you still have several hours to report it so that it gets fixed before I leave. :-) Thanks. BTW, make, before compiling scwm.el, emits a warning "Warnings can be ignored. :-)" Although it is true technically, I would prefer that this warning is deleted: there should not be any by this time. The only places where this warning appears are "utilities/emacs/Makefile.in" and "utilities/emacs/Makefile", both are auto-generated, so I am lost as to its origins. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Illiterate? Write today, for free help! From owner-scwm-discuss@mit.edu Fri Sep 11 12:00:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA28247 for scwm-discuss-outgoing; Fri, 11 Sep 1998 12:00:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA28244 for ; Fri, 11 Sep 1998 12:00:12 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06197; Fri, 11 Sep 98 12:00:05 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA09219; Fri, 11 Sep 1998 09:00:06 -0700 (PDT) To: Maciej Stachowiak Subject: Re: scwm.el References: From: Greg Badros Date: 11 Sep 1998 09:00:06 -0700 In-Reply-To: Sam Steingold's message of "11 Sep 1998 11:21:13 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > I am leaving on a 2 week vacation tonight. > If you are experiencing a bug in scwm.el, you still have several hours > to report it so that it gets fixed before I leave. :-) > > Thanks. > > BTW, make, before compiling scwm.el, emits a warning "Warnings can be > ignored. :-)" Although it is true technically, I would prefer that this > warning is deleted: there should not be any by this time. > The only places where this warning appears are > "utilities/emacs/Makefile.in" and "utilities/emacs/Makefile", both are > auto-generated, so I am lost as to its origins. See the subroutine "handle_emacs_lisp" in the automake perl script. Unfortunately, it's a standard part of the automake support. I guess most projects have given up on quieting the byte-compiler. Not everyone has so conscientious of an Emacs lisp guru! :-) Enjoy your vacation! Maybe we'll keep a list of things for you upon your return.... :-) Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 11 13:46:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA28959 for scwm-discuss-outgoing; Fri, 11 Sep 1998 13:46:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA28956 for ; Fri, 11 Sep 1998 13:46:26 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12489; Fri, 11 Sep 98 13:46:20 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA11588; Fri, 11 Sep 1998 10:46:18 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Thanks! RE: A Favour... From: Greg Badros X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Date: 11 Sep 1998 10:46:17 -0700 Message-Id: Lines: 82 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I want to thank all of you for your responses to my little experiment regarding the guile "system" call (really more about your system's "system" call than about guile, as guile uses that function directly). To summarize, Linux, Linux/Glibc, FreeBSD, and NetBSD all lost the xterm when a Ctrl-C was given in the guile repl tty after (system "xterm &"). HP/UX and Sun Solaris did not. Under solaris, here's what the process table looks like after starting xterm: ps -efj UID PID PPID PGID SID C STIME TTY TIME CMD ... gjb 11563 1 11563 11563 1 10:23:41 ? 0:00 xterm gjb 11538 11386 11538 11386 1 10:22:45 pts/11 0:02 guile ... Note that the xterm's process group ID and session ID are separate from the guile that started it. However, on linux, we have: ps auxj PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND ... 1 4674 4648 4412 p9 4648 S 11960 0:00 xterm 4412 4648 4648 4412 p9 4648 S 11960 0:00 guile ... Here the xterm has the same sesion and process group IDs as the guile. It also has the same terminal process group id. When the Ctrl-C is sent to the guile tty, the sigint signal also is going to the xterm (as observed by an strace on that process). My understanding of POSIX.2 (admittedly only from Steven's APitUE) is that system is supposed to ignore SIGINT. In any case, it's clear that enough of the different platforms do not have the behaviour I expect. Can anyone else shed any light on this matter? Any scsh/shell/job-control gurus reading? Why do we care? Many of you probably don't need to, really. I was concerned because all the xterm-s that I started under scwm were dying when I hit C-c on the scwm process (running in a tty for testing) that started them. In any case, I added `scwm-system' to base.scm, and suggest that you use (set! use-scwm-system-proc #t) to make `execute' and `exe' both use `scwm-system' instead of `system'. This is probably only an issue if you run scwm from a tty as I mentioned. See the procedure below. Again, thanks for your help (I was glad to add lots of new names to the THANKS file!). I'd love to hear from anyone who can enlighten me on the specifics of these inconsistencies. Greg (define-public (scwm-system cmd) "Run CMD using /bin/sh -c CMD and return the exit status. The CMD is run synchronously, and Bourne-shell meta characters are interpreted by /bin/sh. E.g., to start CMD in the background, use a trailing \"&\" character. See also guile's `system', but note that it may permit signals on the controlling tty to be seen by children (observed on Linux, Free/NetBSD, but not on Solaris or HP/UX. This may be a bug (not meeting POSIX.2 specifications)." (let ((child-pid (primitive-fork))) (cond ((< child-pid 0) (error "bad fork")) ((> child-pid 0) ;; parent (begin (cdr (waitpid child-pid)))) (else ;; child (begin (setpgid 0 0) (apply execlp (list "/bin/sh" "sh" "-c" cmd))) )))) From owner-scwm-discuss@mit.edu Fri Sep 11 14:05:12 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA29110 for scwm-discuss-outgoing; Fri, 11 Sep 1998 14:05:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA29107 for ; Fri, 11 Sep 1998 14:05:09 -0400 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA27580; Fri, 11 Sep 98 14:05:06 EDT Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.238]) id QQfgke11224; Fri, 11 Sep 1998 18:05:06 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA17482; Fri, 11 Sep 1998 14:04:14 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Thanks! RE: A Favour... References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "11 Sep 1998 10:46:17 -0700" Date: 11 Sep 1998 14:04:13 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 11 Sep 1998 10:46:17 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "Thanks! RE: A Favour...": >> (apply execlp (list "/bin/sh" "sh" "-c" cmd))) this is equivalent to (execlp "/bin/sh" "sh" "-c" cmd) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. If it has syntax, it isn't user friendly. From owner-scwm-discuss@mit.edu Fri Sep 11 14:09:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA29154 for scwm-discuss-outgoing; Fri, 11 Sep 1998 14:09:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA29151 for ; Fri, 11 Sep 1998 14:09:08 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA20413; Fri, 11 Sep 98 14:09:01 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id VAA13146 for ; Fri, 11 Sep 1998 21:08:57 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id UAA19813; Fri, 11 Sep 1998 20:08:58 +0200 To: scwm-discuss@mit.edu Subject: 'empty menu' bug in the latest (and not only) snapshot From: abel@bfr.co.il (Alexander L. Belikoff) Date: 11 Sep 1998 20:08:58 +0200 Message-Id: Lines: 86 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am able to crash SCWM (both the latest snapshot and 0.8a) in a very stable manner by trying to create an empty menu. The current snapshot is: Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 Try a minimal configuration file attached below. Click on the right mouse button to bring up a 'Desktop' menu, select 'Utilities', and then select a menu 'Backgrounds' in the latter. This should crash your scwm with the following message: scwm: system.c:52: safemalloc: Assertion `length >= 1' failed. ============================================================================ ;; -*- scwm -*- ;; $Header: /home/abel/cvs/conf/.scwmrc,v 1.6 1998/08/23 21:54:14 abel ;; Exp $ ;;-------------------------------;; ;; import the scwm modules ;; (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm doc) (app scwm style) (app scwm face)) (define (foo) ()) (define util-menu (menu (list (menuitem "Lock screen" #:image-left "mini-lock.xpm" #:action (lambda () (execute "xlock -nice 0 -mode #random"))) (menuitem "Refresh screen" #:image-left "mini-ray.xpm" #:action refresh) menu-separator (menuitem "Backgrounds" #:action (menu (foo))) ))) (define desktop-menu (menu (list (menuitem "Desktop" #f) menu-title (menuitem "Xterm" #:action (lambda () (execute "xterm"))) (menuitem "Emacs" #:action (lambda () (execute "emacs"))) menu-separator (menuitem "Utilities" #:action 'util-menu) menu-separator (menuitem "Restart" #:action (lambda () (restart "scwm"))) (menuitem "Quit" #:action quit)))) ;; now set some mouse and key bindings ;; ;; first our root menus ;;(bind-mouse 'root 2 popup-ops) (bind-mouse 'root 2 (lambda () (show-window-list-menu #:show-geometry #t))) (bind-mouse 'root 3 (lambda () (popup-menu desktop-menu))) ======================================================================= -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 11 14:12:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA29225 for scwm-discuss-outgoing; Fri, 11 Sep 1998 14:12:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA29222 for ; Fri, 11 Sep 1998 14:12:58 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA21577; Fri, 11 Sep 98 14:12:52 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA11719; Fri, 11 Sep 1998 11:12:51 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Thanks! RE: A Favour... References: From: Greg Badros Date: 11 Sep 1998 11:12:50 -0700 In-Reply-To: Sam Steingold's message of "11 Sep 1998 14:04:13 -0400" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> Sent on 11 Sep 1998 10:46:17 -0700 > >>>> Honorable Greg Badros writes > >>>> on the subject of "Thanks! RE: A Favour...": > >> (apply execlp (list "/bin/sh" "sh" "-c" cmd))) > > this is equivalent to > > (execlp "/bin/sh" "sh" "-c" cmd) Yep. Beats me why I wrote it the other way... :-) Greg From owner-scwm-discuss@mit.edu Fri Sep 11 14:50:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA29598 for scwm-discuss-outgoing; Fri, 11 Sep 1998 14:50:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA29595 for ; Fri, 11 Sep 1998 14:50:08 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04005; Fri, 11 Sep 98 14:50:01 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA11799; Fri, 11 Sep 1998 11:49:46 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: 'empty menu' bug in the latest (and not only) snapshot References: From: Greg Badros Date: 11 Sep 1998 11:49:43 -0700 In-Reply-To: abel@bfr.co.il's message of "11 Sep 1998 20:08:58 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > I am able to crash SCWM (both the latest snapshot and 0.8a) in a very > stable manner by trying to create an empty menu. The current snapshot > is: > > Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 > > Try a minimal configuration file attached below. Click on the right > mouse button to bring up a 'Desktop' menu, select 'Utilities', and > then select a menu 'Backgrounds' in the latter. This should crash your > scwm with the following message: > > scwm: system.c:52: safemalloc: Assertion `length >= 1' failed. Yep. Thanks for the nice bug report with a good small configuration for testing. Note also that you can just send snippets of code to be evaluated using scwmexec if that code uses primitives. In this case, simply (make-menu '()) failed. My fix is to not permit empty menus. In your sample file, you'll now get an error at: > (menuitem "Backgrounds" > #:action (menu (foo))) ;;(menu (foo)) is now invalid since that's just (menu '()) Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 11 14:52:49 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA29638 for scwm-discuss-outgoing; Fri, 11 Sep 1998 14:52:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA29635 for ; Fri, 11 Sep 1998 14:52:48 -0400 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA15180; Fri, 11 Sep 98 14:52:39 EDT Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA17315; Fri, 11 Sep 1998 14:52:09 -0400 Date: Fri, 11 Sep 1998 14:52:09 -0400 (EDT) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 11 Sep 1998, Greg Badros wrote: > Todd Larason writes: > > > On 980910, Greg Badros wrote: > > > Ok... I'm currently fixing WarpToWindow as that is perhaps the main culprit. > > > > That looks like it! 1.378 seems much better - circulate and the move-screen > > problem are both fixed. > > > > And it looks like the resizing-window-on-recapture thing may hve been > > fixed today, too. At least, that last restart didn't resize any noticably, > > while others earlier this morning still did. > > Interesting... an unintentional side-effect, if so. Please confirm > (others, too?) if this really is the case. (I've never reliably > reproduced it, but haven't tried that hard either as I figure Maciej can > fix that one as he was just finishing up reworking lots of that code > before his vacation). > Unfortunately the resize problem is still there for me. Every window shrinks a little tiny bit vertically when reparented by scwm. I'd be willing to send along my (somewhat ugly at this point) .scwmrc to demonstrate the problem. Also I'm seeing some odd window movement behavior with this morning's CVS update. I have 6 workspaces, each with 2x2 desktops. I have C-M-{Left,Right,Up,Down} move around the desktops, and C-S-{Left,Right} move between workspaces. I have Netscape windows spread across the two top desktops in my "Netscape" workspace, an XEmacs window in the upper left desktop in an "Editor" workspace, and Gimp in the upper left desktop of a "Graphics" workspace. If I move from the upper left desktop to the upper right desktop using C-M-Right in my "Netscape" workspace the Netscape windows appear as they should, but the windows in "Editor" and "Gimp" move to upper right desktop in their respective workspaces. Odd indeed (but actually useful in the situation I was in). It was fun to watch in the FvwmPager window. Any clues? See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Fri Sep 11 16:43:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA30357 for scwm-discuss-outgoing; Fri, 11 Sep 1998 16:43:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA30354 for ; Fri, 11 Sep 1998 16:43:18 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11627; Fri, 11 Sep 98 16:43:11 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA12805; Fri, 11 Sep 1998 13:41:53 -0700 (PDT) To: "Craig A. Struble" Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 11 Sep 1998 13:41:52 -0700 In-Reply-To: "Craig A. Struble"'s message of "Fri, 11 Sep 1998 14:52:09 -0400 (EDT)" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Craig A. Struble" writes: > Unfortunately the resize problem is still there for me. Every window > shrinks a little tiny bit vertically when reparented by scwm. I'd be > willing to send along my (somewhat ugly at this point) .scwmrc to > demonstrate the problem. Hang onto the problem... I'm still hopefully that Maciej will get back into development any moment now and fix this -- he was working on the code just before leaving and has a list of related changes (for controlling gravity settings, etc.) that he can make while tracking down the problem. In the meantime I'll try to reproduce it. (Don't lose your .scwmrc that causes it though). > Also I'm seeing some odd window movement behavior with this morning's CVS > update. I have 6 workspaces, each with 2x2 desktops. I have > C-M-{Left,Right,Up,Down} move around the desktops, and C-S-{Left,Right} > move between workspaces. I have Netscape windows spread across the two top > desktops in my "Netscape" workspace, an XEmacs window in the upper left > desktop in an "Editor" workspace, and Gimp in the upper left desktop of a > "Graphics" workspace. If I move from the upper left desktop to the upper > right desktop using C-M-Right in my "Netscape" workspace the Netscape > windows appear as they should, but the windows in "Editor" and "Gimp" move > to upper right desktop in their respective workspaces. Odd indeed (but > actually useful in the situation I was in). It was fun to watch in the > FvwmPager window. Any clues? Yep, I fixed it later this morning (probably changed.c == 1.386 or so). I just added animated-move-window which takes virtual coordinates for the destination position, and does not move the pointer with the window. Also added a bunch of utility functions to the base module: viewport->virtual, virtual->viewport, viewport-size, viewport-{x,y}-position, vx-, vy-. These may be helpful as scheme code evolves to be more aware of the difference between virtual positions and viewport positions. Let me know if the bug doesn't seem fixed after you update again. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 11 17:41:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA30699 for scwm-discuss-outgoing; Fri, 11 Sep 1998 17:41:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA30696 for ; Fri, 11 Sep 1998 17:41:44 -0400 Received: from tor-dev1.nbc.netcom.ca by MIT.EDU with SMTP id AA13030; Fri, 11 Sep 98 17:41:41 EDT Received: (from misaka@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) id RAA28726; Fri, 11 Sep 1998 17:41:34 -0400 (EDT) From: Mishka Gorodnitzky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13817.39182.141401.444937@tor-dev1.nbc.netcom.ca> Date: Fri, 11 Sep 1998 17:41:34 -0400 (EDT) To: scwm-discuss@mit.edu Subject: A pager for scwm? X-Mailer: VM 6.53 under 20.4 "Emerald" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm wondering if there is currently a pager available for scwm. I've noticed that there appears to be support for the fvwm pager module, but yet here's what happens when I try to get it working: | scwm> (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" '("0" "2"))) | | 0* (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" (quote #))) | 1* [define (define fvwm2-pager (#@run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" #)) (#)] | 2* [run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager"] | 3 (let* ((other-args #) (config-file #) (config-info #)) (let-keywords* %%gensym58 () ...)) | 4* (cond ((not #) (let # # ...)) (#t (get-fvwm2-module-config #))) | 5 [get-fvwm2-module-config ... | 6* (basename module-name) | | ERROR: In expression (basename module-name): | ERROR: Unbound variable: basename Presumably because basename isn't defined anywhere. Is this something that should be available via the guile libs? Or am I doing something wrong here? I do have the suggested code snippet from fvwm-module.scm run before this code in my scwmrc ... if that affects the availability of (basename ...). TIA. -- Mishka From owner-scwm-discuss@mit.edu Fri Sep 11 18:02:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30857 for scwm-discuss-outgoing; Fri, 11 Sep 1998 18:02:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30854 for ; Fri, 11 Sep 1998 18:02:51 -0400 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA04196; Fri, 11 Sep 98 18:02:45 EDT Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA23627; Fri, 11 Sep 1998 18:02:39 -0400 Date: Fri, 11 Sep 1998 18:02:39 -0400 (EDT) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 11 Sep 1998, Greg Badros wrote: > > Also I'm seeing some odd window movement behavior with this morning's CVS > > update. I have 6 workspaces, each with 2x2 desktops. I have > > C-M-{Left,Right,Up,Down} move around the desktops, and C-S-{Left,Right} > > move between workspaces. I have Netscape windows spread across the two top > > desktops in my "Netscape" workspace, an XEmacs window in the upper left > > desktop in an "Editor" workspace, and Gimp in the upper left desktop of a > > "Graphics" workspace. If I move from the upper left desktop to the upper > > right desktop using C-M-Right in my "Netscape" workspace the Netscape > > windows appear as they should, but the windows in "Editor" and "Gimp" move > > to upper right desktop in their respective workspaces. Odd indeed (but > > actually useful in the situation I was in). It was fun to watch in the > > FvwmPager window. Any clues? > > Yep, I fixed it later this morning (probably changed.c == 1.386 or so). > I just added animated-move-window which takes virtual coordinates for > the destination position, and does not move the pointer with the > window. > Nope, this doesn't fix the problem. From changed.c: char *szRepoLastChanged = "Fri Sep 11 16:45:14 EDT 1998 -- $Revision: 1.392 $"; Here are my bindings: ;; move the viewport with the keyboard (bind-key 'all "C-M-Left" (lambda () (move-viewport (%x -100) 0))) (bind-key 'all "C-M-Right" (lambda () (move-viewport (%x 100) 0))) (bind-key 'all "C-M-Up" (lambda () (move-viewport 0 (%y -100)))) (bind-key 'all "C-M-Down" (lambda () (move-viewport 0 (%y 100)))) Maybe move-viewport needs to change in base.scm? Right now mine says: (define-public (move-viewport x y) "Move the viewport onto the virtual desktop relatively. Moves X pixels horizontally, to the right if positive, to the left if negative, and Y pixels vertically, down if positive, up if negative." (let ((pos (viewport-position))) (set-viewport-position! (+ x (car pos)) (+ y (cadr pos))))) It appears that windows on all other desktops get shifted by the x and y amounts when move-viewport is used. Also, on another unrelated note, I am getting these messages in my .xsession-errors file: packet: (0 17 "SET_MASK 9227263 " 1) packet: (0 15 "Send_ConfigInfo" 1) packet: (0 15 "Send_WindowList" 1) scwm in free(): warning: junk pointer, too high to make sense. scwm in free(): warning: junk pointer, too low to make sense. Error evaling packet: (0 15 "Send_WindowList" 1) The packet messages make sense, but the free messages which are from FreeBSD's malloc/free implementation suggest potential memory problems and the error evaling the packet makes windows created before scwm was run not show up in the Fvwm pager until they are moved or resized. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Fri Sep 11 18:04:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30870 for scwm-discuss-outgoing; Fri, 11 Sep 1998 18:04:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30867 for ; Fri, 11 Sep 1998 18:04:42 -0400 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA04592; Fri, 11 Sep 98 18:04:30 EDT Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA25222; Fri, 11 Sep 1998 18:04:32 -0400 Date: Fri, 11 Sep 1998 18:04:32 -0400 (EDT) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Mishka Gorodnitzky Cc: scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: <13817.39182.141401.444937@tor-dev1.nbc.netcom.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I saw this message when using scwm-0.8 with guile-1.2 which doesn't implement basename. Updating to a guile-1.3 snapshot fixes it and a number of other strange things you see when using guile-1.2. See ya later, Craig On Fri, 11 Sep 1998, Mishka Gorodnitzky wrote: > > I'm wondering if there is currently a pager available for > scwm. I've noticed that there appears to be support for the fvwm pager > module, but yet here's what happens when I try to get it working: > > | scwm> (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" '("0" "2"))) > | > | 0* (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" (quote #))) > | 1* [define (define fvwm2-pager (#@run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager" #)) (#)] > | 2* [run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager"] > | 3 (let* ((other-args #) (config-file #) (config-info #)) (let-keywords* %%gensym58 () ...)) > | 4* (cond ((not #) (let # # ...)) (#t (get-fvwm2-module-config #))) > | 5 [get-fvwm2-module-config ... > | 6* (basename module-name) > | > | ERROR: In expression (basename module-name): > | ERROR: Unbound variable: basename > > Presumably because basename isn't defined anywhere. Is this something > that should be available via the guile libs? Or am I doing something > wrong here? I do have the suggested code snippet from fvwm-module.scm > run before this code in my scwmrc ... if that affects the availability > of (basename ...). > > TIA. > > > -- Mishka > -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Fri Sep 11 18:11:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31019 for scwm-discuss-outgoing; Fri, 11 Sep 1998 18:11:37 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31016 for ; Fri, 11 Sep 1998 18:11:34 -0400 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA20693; Fri, 11 Sep 98 18:11:32 EDT Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.8.8/8.6.4) with SMTP id SAA03350; Fri, 11 Sep 1998 18:11:53 -0400 (EDT) Message-Id: <199809112211.SAA03350@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: question about scwm philosophy :) In-Reply-To: Your message of "11 Sep 1998 08:08:54 PDT." Date: Fri, 11 Sep 1998 18:11:53 -0400 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: Greg> Well, it is done a couple of other places... [...] well, hadn't looked at the constraints things yet. But fair enough, I stand (happily) corrected :) Greg> In some cases there is no particularly good object to attach the Greg> property to, so a hook variable needs to be used instead. That makes perfect sense :) Greg> I guess as a general thing, though, I'm interested in gaining Greg> experience with the pros and cons of the various extension Greg> mechanisms. There are lots of possibilities, and I've not yet Greg> thought hard about which is best in what circumstances. Greg> More comments and feedback are always appreciated.... why do you Greg> like property-based hooks better than explicit variable hooks? Well, the primary thing I like about the mechanism used for the placement functions is that they allow one to override the functionality that's provided by default, instead of adding processing before or after, thus if I want to write a place-window-not-overlapping-anything-even-if-that-means-putting-it-on-some- other-desk function then I can do that without it getting mapped onto the current desk by the default placement function. And since the default is a scheme function (subr), you can implement before and after hook functionality easily by just calling the default from your replacement function. The other advantage of scheme property hooks is that it's somewhat easier (IMO) to dynamically set them for individual windows, or groups of windows) than hooks. They also, in the case of less heavily hook-ified setups, where the defaults are mostly in use, require less storage, as fields for them don't need to be allocated in each structure. They are slightly slower though (hash table lookup, vs structure member). It does, however, require a somewhat more... promitive level of primitives to be able to replace some functionality, rather than to augment it, and there's some cases where you want to insure that something's always done, in order to make the WM stable. Really, as long as I can override default behaviors, I'm perfectly happy. I do kind of prefer the scheme properties method as it seems cleaner to me. -Eric From owner-scwm-discuss@mit.edu Fri Sep 11 18:25:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31177 for scwm-discuss-outgoing; Fri, 11 Sep 1998 18:25:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31174 for ; Fri, 11 Sep 1998 18:25:41 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23806; Fri, 11 Sep 98 18:25:39 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA13280; Fri, 11 Sep 1998 15:25:31 -0700 (PDT) To: "Craig A. Struble" Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 11 Sep 1998 15:25:29 -0700 In-Reply-To: "Craig A. Struble"'s message of "Fri, 11 Sep 1998 18:02:39 -0400 (EDT)" Message-Id: Lines: 49 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Craig A. Struble" writes: > > Yep, I fixed it later this morning (probably changed.c == 1.386 or so). > > I just added animated-move-window which takes virtual coordinates for > > the destination position, and does not move the pointer with the > > window. > > > Nope, this doesn't fix the problem. From changed.c: I didn't read your earlier message as carefully as I should've because I thought I recognized the problem you were describing as one that I had just seen. I goofed. > > char *szRepoLastChanged = "Fri Sep 11 16:45:14 EDT 1998 -- $Revision: 1.392 $"; Yep, it's still broken there.... I'll try to track this down before I go home... > Also, on another unrelated note, I am getting these messages in my > .xsession-errors file: > > packet: (0 17 "SET_MASK 9227263 > " 1) > packet: (0 15 "Send_ConfigInfo" 1) > packet: (0 15 "Send_WindowList" 1) > scwm in free(): warning: junk pointer, too high to make sense. > scwm in free(): warning: junk pointer, too low to make sense. > Error evaling packet: (0 15 "Send_WindowList" 1) > > The packet messages make sense, but the free messages which are from > FreeBSD's malloc/free implementation suggest potential memory problems and > the error evaling the packet makes windows created before scwm was run not > show up in the Fvwm pager until they are moved or resized. Ick... those messages don't look good can you try to track down what free is causing that warning message? You could instrument the FREE macro if you know what FreeBSD's rules are for printing the message -- then you could do the test in the macro and print the __FILE__ and __LINE__ when the precondition is violated. Let me know if that doesn't make sense... have any of the other FreeBSD users seen this? Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 11 18:48:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31531 for scwm-discuss-outgoing; Fri, 11 Sep 1998 18:48:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31524 for ; Fri, 11 Sep 1998 18:48:30 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA14394; Fri, 11 Sep 98 18:48:24 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA14109; Fri, 11 Sep 1998 15:48:23 -0700 (PDT) To: "Craig A. Struble" Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 11 Sep 1998 15:48:21 -0700 In-Reply-To: "Craig A. Struble"'s message of "Fri, 11 Sep 1998 18:02:39 -0400 (EDT)" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Craig A. Struble" writes: > Nope, this doesn't fix the problem. From changed.c: Ok, now it works for me -- problem was in the C code -- I needed to broadcast a new position for all the windows, not just the ones on the current desk (the pager must try to be kinda smart, but fails since things have changed in scwm). Thanks for the bug report. Greg From owner-scwm-discuss@mit.edu Fri Sep 11 19:01:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA31776 for scwm-discuss-outgoing; Fri, 11 Sep 1998 19:01:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA31773 for ; Fri, 11 Sep 1998 19:01:54 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AB01171; Fri, 11 Sep 98 19:01:52 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA14138; Fri, 11 Sep 1998 16:01:48 -0700 (PDT) To: Eric Moore Cc: scwm-discuss@mit.edu Subject: Re: question about scwm philosophy :) References: <199809112211.SAA03350@chopin.chem.cmu.edu> From: Greg Badros Date: 11 Sep 1998 16:01:47 -0700 In-Reply-To: Eric Moore's message of "Fri, 11 Sep 1998 18:11:53 -0400" Message-Id: Lines: 78 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Eric Moore writes: > >>>>> "Greg" == Greg Badros writes: > > > Greg> Well, it is done a couple of other places... > [...] > > well, hadn't looked at the constraints things yet. But fair > enough, I stand (happily) corrected :) Looking at the menu code again, I realize there are some pretty nifty uses of scheme property-based uses there. > > Greg> In some cases there is no particularly good object to attach the > Greg> property to, so a hook variable needs to be used instead. > > That makes perfect sense :) > > Greg> I guess as a general thing, though, I'm interested in gaining > Greg> experience with the pros and cons of the various extension > Greg> mechanisms. There are lots of possibilities, and I've not yet > Greg> thought hard about which is best in what circumstances. > Greg> More comments and feedback are always appreciated.... why do you > Greg> like property-based hooks better than explicit variable hooks? > > Well, the primary thing I like about the mechanism used for the > placement functions is that they allow one to override the > functionality that's provided by default, instead of adding processing > before or after, thus if I want to write a > place-window-not-overlapping-anything-even-if-that-means-putting-it-on-some- > other-desk function then I can do that without it getting mapped onto > the current desk by the default placement function. And since the > default is a scheme function (subr), you can implement before and > after hook functionality easily by just calling the default from your > replacement function. This is more about permitting overriding instead of just augmenting behaviour. It's not tied specifically to the fact that the hook is implemented through a scheme object property. > The other advantage of scheme property hooks is that it's somewhat > easier (IMO) to dynamically set them for individual windows, or groups > of windows) than hooks. Maciej added a set-window-property! feature to generalize per-window extensions in a similar way to set-object-property! but permitting callbacks when a property is changed. This, I believe, he intends to take over some of the values from the window structure. > They also, in the case of less heavily hook-ified setups, where the > defaults are mostly in use, require less storage, as fields for them > don't need to be allocated in each structure. They are slightly > slower though (hash table lookup, vs structure member). Very true. > It does, however, require a somewhat more... promitive level of > primitives to be able to replace some functionality, rather than to > augment it, and there's some cases where you want to insure that > something's always done, in order to make the WM stable. Right, these are real issues. Along with how to document the random scheme properties that are used for various things. Hooks are something you can hang your hat on (so to speak), whereas the properties are almost too easy to use. Understanding what's happening could be an issue because they are so unstructured. > Really, as long as I can override default behaviors, I'm perfectly > happy. I do kind of prefer the scheme properties method as it seems > cleaner to me. Here we just have to be careful about where to permit overriding behaviours. Thanks for the comments! Greg From owner-scwm-discuss@mit.edu Fri Sep 11 21:07:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA32516 for scwm-discuss-outgoing; Fri, 11 Sep 1998 21:07:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA32513 for ; Fri, 11 Sep 1998 21:07:30 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA19180; Fri, 11 Sep 98 21:07:28 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id SAA30184 for ; Fri, 11 Sep 1998 18:07:26 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15944>; Fri, 11 Sep 1998 18:06:41 -0700 To: scwm-discuss@mit.edu Subject: Re: Thanks! RE: A Favour... In-Reply-To: Your message of "11 Sep 1998 10:46:17 PDT." Date: Fri, 11 Sep 1998 17:25:26 -0600 From: Ken Pizzini Fake-Sender: ken@halcyon.com Message-Id: <19980912010641Z276516-15944+162@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > My understanding of POSIX.2 > (admittedly only from Steven's APitUE) is that system is supposed to > ignore SIGINT. In any case, it's clear that enough of the different > platforms do not have the behaviour I expect. Can anyone else shed any > light on this matter? Any scsh/shell/job-control gurus reading? POSIX.2 specifies that the system() call *itself* is supposed to ignore SIGINT while waiting for its child to terminate. But POSIX.2 does not speicify that it should cause its child to be protected from SIGINT. And in fact for command-line based tools it makes more sense to allow the child command to receive the SIGINT. I suspect that the behavior under Solaris et al. is probably due to different handling of &, rather than different handling of system(). Your scwm-system call is on the right track for how to portably handle this issue with semantics which are better suited to the creation of independent windows. What it lacks is that the parent should ignore SIGINT and SIGQUIT, and block SIGCHLD, while waiting for the child command to terminate. --Ken Pizzini From owner-scwm-discuss@mit.edu Fri Sep 11 21:07:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA32521 for scwm-discuss-outgoing; Fri, 11 Sep 1998 21:07:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA32518 for ; Fri, 11 Sep 1998 21:07:38 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA03733; Fri, 11 Sep 98 21:07:32 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id SAA23191 for ; Fri, 11 Sep 1998 18:07:27 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276517-15944>; Fri, 11 Sep 1998 18:07:12 -0700 To: scwm-discuss@mit.edu Subject: Re: 'empty menu' bug in the latest (and not only) snapshot In-Reply-To: Your message of "11 Sep 1998 11:49:43 PDT." Date: Fri, 11 Sep 1998 17:39:57 -0600 From: Ken Pizzini Fake-Sender: ken@halcyon.com Message-Id: <19980912010712Z276517-15944+163@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > In this case, > simply (make-menu '()) failed. My fix is to not permit empty menus. > > In your sample file, you'll now get an error at: > > > (menuitem "Backgrounds" > > #:action (menu (foo))) > > ;;(menu (foo)) is now invalid since that's just (menu '()) For dynamically-generated menus it'd be nice to be able to accept an empty menu. If this is awkward to do at the C level, then it'd be nice to at least add a scheme-wrapper function (to flux.scm?) which does something "useful" when passed an empty list. (Perhaps adding a one-item menu item "(none)" with a no-op action?) --Ken Pizzini From owner-scwm-discuss@mit.edu Sat Sep 12 09:37:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA03451 for scwm-discuss-outgoing; Sat, 12 Sep 1998 09:37:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA03448 for ; Sat, 12 Sep 1998 09:37:27 -0400 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA11859; Sat, 12 Sep 98 09:37:18 EDT Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA04263; Sat, 12 Sep 1998 09:37:15 -0400 Date: Sat, 12 Sep 1998 09:37:15 -0400 (EDT) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 11 Sep 1998, Greg Badros wrote: > > I didn't read your earlier message as carefully as I should've because I > thought I recognized the problem you were describing as one that I had > just seen. I goofed. > > > > > char *szRepoLastChanged = "Fri Sep 11 16:45:14 EDT 1998 -- $Revision: 1.392 $"; > > Yep, it's still broken there.... I'll try to track this down before I > go home... > Ok, the latest CVS update I got fixed the problem. Thanks for fixing it so fast! > > > > > Also, on another unrelated note, I am getting these messages in my > > .xsession-errors file: > > > > packet: (0 17 "SET_MASK 9227263 > > " 1) > > packet: (0 15 "Send_ConfigInfo" 1) > > packet: (0 15 "Send_WindowList" 1) > > scwm in free(): warning: junk pointer, too high to make sense. > > scwm in free(): warning: junk pointer, too low to make sense. > > Error evaling packet: (0 15 "Send_WindowList" 1) > > > > The packet messages make sense, but the free messages which are from > > FreeBSD's malloc/free implementation suggest potential memory problems and > > the error evaling the packet makes windows created before scwm was run not > > show up in the Fvwm pager until they are moved or resized. > > Ick... those messages don't look good can you try to track down what > free is causing that warning message? You could instrument the FREE > macro if you know what FreeBSD's rules are for printing the message -- > then you could do the test in the macro and print the __FILE__ and > __LINE__ when the precondition is violated. > > Let me know if that doesn't make sense... have any of the other FreeBSD > users seen this? > Well, I did things a different way. FreeBSD allows you to set options to the malloc subsystem in an environment variable. Very convienent for testing. So I made scwm abort as soon as it ran into a problem. Here's what I found. The first free is happening in DestroyScwmDecor() static void DestroyScwmDecor(ScwmDecor * fl) { if (fl->tag) { FREE(fl->tag); /* XXX: Here's the offending free */ fl->tag = NULL; } if (fl->HiReliefGC != NULL) { XFreeGC(dpy, fl->HiReliefGC); fl->HiReliefGC = NULL; } if (fl->HiShadowGC != NULL) { XFreeGC(dpy, fl->HiShadowGC); fl->HiShadowGC = NULL; } } In this case, fl->tag is the string "default". Hmm, trying to destroy the default style? Maybe the string is statically allocated? I didn't look that far into it. I haven't yet gotten to the second free message. Setting the malloc options at runtime is useful, but it doesn't let you get past the first error. :-/ When I figure that one out I'll send it along. Hope that helps for now. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sat Sep 12 10:15:11 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA03660 for scwm-discuss-outgoing; Sat, 12 Sep 1998 10:15:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA03657 for ; Sat, 12 Sep 1998 10:15:07 -0400 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA02211; Sat, 12 Sep 98 10:14:55 EDT Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA04693; Sat, 12 Sep 1998 10:14:58 -0400 Date: Sat, 12 Sep 1998 10:14:58 -0400 (EDT) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sat, 12 Sep 1998, Craig A. Struble wrote: > On 11 Sep 1998, Greg Badros wrote: > > > > I didn't read your earlier message as carefully as I should've because I > > thought I recognized the problem you were describing as one that I had > > just seen. I goofed. > > > > > > > > char *szRepoLastChanged = "Fri Sep 11 16:45:14 EDT 1998 -- $Revision: 1.392 $"; > > > > Yep, it's still broken there.... I'll try to track this down before I > > go home... > > > Ok, the latest CVS update I got fixed the problem. Thanks for fixing it so > fast! > Actually, I spoke too soon. The problems aren't quite gone here. The FvwmPager shows the window in the correct place, but when I actually move from one desktop to another after switching viewports, windows in the other desktops have really been moved the amount the viewport has been moved. So, the pager thinks the windows are in the right place, but really they were moved. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sat Sep 12 16:25:27 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05110 for scwm-discuss-outgoing; Sat, 12 Sep 1998 16:25:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05107 for ; Sat, 12 Sep 1998 16:25:23 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00782; Sat, 12 Sep 98 16:25:05 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id XAA21219 for ; Sat, 12 Sep 1998 23:25:10 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id WAA27816; Sat, 12 Sep 1998 22:25:09 +0200 To: scwm-discuss@mit.edu Subject: iconification problems From: abel@bfr.co.il (Alexander L. Belikoff) Date: 12 Sep 1998 22:25:09 +0200 Message-Id: Lines: 116 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In scwm "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $" some applications don't iconify properly - they just disappear from the screen. These include xxgdb and netscape. Others do work: xterm etc. The system is RedHat 4.2 (libc5), guile - 980806. Here goes a relevant part of my .scwmrc: (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm doc) (app scwm style) (app scwm face)) (set-smart-placement-is-really-smart! #t) (set-edge-resistance! 500 0) (set-edge-scroll! (%x 100) (%y 100)) (set-edge-wrap! #f #f) (menu-style #:fg "Black" #:bg "Grey70" #:stipple "Grey40" ;; #:font (make-font "*helvetica-medium-r-*-120-*") #:font (make-font #"-*-helvetica-medium-r-*-*-*-100-*-*-*-*-*-*") #:mwm #t) ;;(title-style #:font (make-font "*helvetica-bold-r-*-120-*") (title-style #:font (make-font "-*-helvetica-bold-r-*-*-*-100-*-*-*-*-*-*") #:justify 'left) ;(set-icon-font! (make-font "*helvetica-bold-r-*-120-*")) (set-icon-font! (make-font "fixed")) (set-hilight-foreground! "Black") ;; (set-hilight-background! "Gray70") (set-hilight-background! "CadetBlue") (set-rubber-band-mask! 127) (set-desk-size! 2 2) (define HOME (getenv "HOME")) (define USER (getenv "USER")) (define user-image-load-path (list (string-append HOME "/desktop/icons"))) ;;-------------------------------;; ;; set some paths ;; ;; ;;; set path to use for image searches (set! image-load-path (append user-image-load-path '("/usr/X11/lib/X11/mini-icons" "/usr/X11/include/X11/pixmaps" "/usr/lib/icons" "/usr/local/X11/include/X11/pixmaps" "/usr/local/lib/icons" "/usr/local/icons" "/uns/share/include/X11/pixmaps" "/uns/share/include/X11/bitmaps") image-load-path)) ;;-------------------------------;; ;; set some window styles ;; (window-style "*" #:fg "black" #:bg "gray55" #:icon "unknown1.xpm" #:sticky-icon #t #:icon-box (list 0 (y- 20) (y- 50) (y- 1)) #:border-width 6 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:mwm-buttons #t #:mwm-border #t #:int-override #t #:decorate-transient #t #:PPosition-hint #f ) (define desk-widget (make-style #:plain-border #t #:sticky #t #:winlist-skip #t #:border-width 2 #:no-titlebar #t #:focus 'none)) (window-style "xclock" #:use-style desk-widget) (window-style "xbiff" #:use-style desk-widget) (window-style "xrus" #:use-style desk-widget) (window-style "*lock" #:use-style desk-widget) (window-style "xload" #:no-titlebar #t #:use-style desk-widget) (window-style "xscreensaver" #:no-titlebar #t #:use-style desk-widget) (window-style "xcalc" #:icon "xcalc.xpm") (window-style "xman" #:icon "xman.xpm") (window-style "xmag" #:icon "mag_glass.xpm") (window-style "Emacs" #:icon "gnu-animal.xpm") (window-style "XTerm" #:icon "xterm.xpm") Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Sat Sep 12 16:42:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05272 for scwm-discuss-outgoing; Sat, 12 Sep 1998 16:42:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05269 for ; Sat, 12 Sep 1998 16:42:27 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA02575; Sat, 12 Sep 98 16:42:09 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA25018; Sat, 12 Sep 1998 13:42:14 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Thanks! RE: A Favour... References: <19980912002527Z276516-15944+160@pulsar.halcyon.com> From: Greg Badros In-Reply-To: Ken Pizzini's message of "Fri, 11 Sep 1998 17:25:26 -0600" X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Date: 12 Sep 1998 13:42:14 -0700 Message-Id: Lines: 28 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > > My understanding of POSIX.2 > > (admittedly only from Steven's APitUE) is that system is supposed to > > ignore SIGINT. In any case, it's clear that enough of the different > > platforms do not have the behaviour I expect. Can anyone else shed any > > light on this matter? Any scsh/shell/job-control gurus reading? > > POSIX.2 specifies that the system() call *itself* is supposed > to ignore SIGINT while waiting for its child to terminate. > But POSIX.2 does not speicify that it should cause its child to > be protected from SIGINT. And in fact for command-line based > tools it makes more sense to allow the child command to receive > the SIGINT. I suspect that the behavior under Solaris et al. > is probably due to different handling of &, rather than different > handling of system(). > > Your scwm-system call is on the right track for how to portably > handle this issue with semantics which are better suited to > the creation of independent windows. What it lacks is that the > parent should ignore SIGINT and SIGQUIT, and block SIGCHLD, > while waiting for the child command to terminate. Ok, thanks for the clarification. I'll see if I can add those features, too. (Unless you beat me to it?? :-)) Thanks, Greg From owner-scwm-discuss@mit.edu Sat Sep 12 16:42:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05285 for scwm-discuss-outgoing; Sat, 12 Sep 1998 16:42:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05281 for ; Sat, 12 Sep 1998 16:42:52 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17608; Sat, 12 Sep 98 16:42:38 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA25021; Sat, 12 Sep 1998 13:42:34 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: 'empty menu' bug in the latest (and not only) snapshot References: <19980912003958Z276516-15944+161@pulsar.halcyon.com> From: Greg Badros In-Reply-To: Ken Pizzini's message of "Fri, 11 Sep 1998 17:39:57 -0600" X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Date: 12 Sep 1998 13:42:34 -0700 Message-Id: Lines: 26 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > > In this case, > > simply (make-menu '()) failed. My fix is to not permit empty menus. > > > > In your sample file, you'll now get an error at: > > > > > (menuitem "Backgrounds" > > > #:action (menu (foo))) > > > > ;;(menu (foo)) is now invalid since that's just (menu '()) > > For dynamically-generated menus it'd be nice to be able to > accept an empty menu. If this is awkward to do at the C level, > then it'd be nice to at least add a scheme-wrapper function > (to flux.scm?) which does something "useful" when passed an > empty list. (Perhaps adding a one-item menu item "(none)" > with a no-op action?) I think the right thing to do is have the Backgrounds menu item disappear if there are no options in that submenu. It'd certainly be easy to do-- make-menu is already wrapped with the `menu' procedure in base.scm. I'm just not convinced that an empty menu makes sense -- I think it needs to be dealt with at some other level (by the user). Greg From owner-scwm-discuss@mit.edu Sat Sep 12 16:49:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA05476 for scwm-discuss-outgoing; Sat, 12 Sep 1998 16:49:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA05470 for ; Sat, 12 Sep 1998 16:49:39 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03507; Sat, 12 Sep 98 16:49:21 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA25027; Sat, 12 Sep 1998 13:49:20 -0700 (PDT) To: "Craig A. Struble" Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 12 Sep 1998 13:49:20 -0700 In-Reply-To: "Craig A. Struble"'s message of "Sat, 12 Sep 1998 10:14:58 -0400 (EDT)" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Craig A. Struble" writes: > On Sat, 12 Sep 1998, Craig A. Struble wrote: > > > On 11 Sep 1998, Greg Badros wrote: > > > > > > I didn't read your earlier message as carefully as I should've because I > > > thought I recognized the problem you were describing as one that I had > > > just seen. I goofed. > > > > > > > > > > > char *szRepoLastChanged = "Fri Sep 11 16:45:14 EDT 1998 -- $Revision: 1.392 $"; > > > > > > Yep, it's still broken there.... I'll try to track this down before I > > > go home... > > > > > Ok, the latest CVS update I got fixed the problem. Thanks for fixing it so > > fast! > > > Actually, I spoke too soon. The problems aren't quite gone here. The > FvwmPager shows the window in the correct place, but when I actually move > from one desktop to another after switching viewports, windows in the > other desktops have really been moved the amount the viewport has been > moved. > So, the pager thinks the windows are in the right place, but really they > were moved. Nah, this is another problem that I just fixed... the windows didn't actually move-- they're just incorrectly being displayed in the wrong place (when I say "moved" regarding a scheme window object, I mean the position of the frame as stored in the object -- FRAME_X(psw)). Thanks, Greg From owner-scwm-discuss@mit.edu Sat Sep 12 17:02:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA05742 for scwm-discuss-outgoing; Sat, 12 Sep 1998 17:02:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA05737 for ; Sat, 12 Sep 1998 17:02:03 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04947; Sat, 12 Sep 98 17:01:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA25082; Sat, 12 Sep 1998 14:01:46 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: iconification problems References: From: Greg Badros Date: 12 Sep 1998 14:01:45 -0700 In-Reply-To: abel@bfr.co.il's message of "12 Sep 1998 22:25:09 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > In scwm "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $" some > applications don't iconify properly - they just disappear from the > screen. These include xxgdb and netscape. Others do work: xterm etc. What does `icon-position' report for the iconified windows? Also, what is viewport-position? I just added icon-viewport-position to base.scm, as it was accidentally missing. It'd be great if you could narrow it down to either an icon not being displayed, and icon's position being mis-computed, or an icon being displayed in the wrong position. > > The system is RedHat 4.2 (libc5), guile - 980806. > > Here goes a relevant part of my .scwmrc: Is this alone enough to reproduce the problem (i.e., can I use that subpart of your .scwmrc as a complete scwmrc and see the problem?) Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Sun Sep 13 12:25:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11150 for scwm-discuss-outgoing; Sun, 13 Sep 1998 12:25:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11147 for ; Sun, 13 Sep 1998 12:25:42 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11879; Sun, 13 Sep 98 12:25:18 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA01892; Sun, 13 Sep 1998 09:25:16 -0700 (PDT) To: "Craig A. Struble" Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot References: From: Greg Badros Date: 13 Sep 1998 09:25:16 -0700 In-Reply-To: "Craig A. Struble"'s message of "Sat, 12 Sep 1998 09:37:15 -0400 (EDT)" Message-Id: Lines: 41 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Craig A. Struble" writes: > Well, I did things a different way. FreeBSD allows you to set options to > the malloc subsystem in an environment variable. Very convienent for > testing. So I made scwm abort as soon as it ran into a problem. Here's > what I found. The first free is happening in DestroyScwmDecor() > > static void > DestroyScwmDecor(ScwmDecor * fl) > { > if (fl->tag) { > FREE(fl->tag); /* XXX: Here's the offending free */ > fl->tag = NULL; > } > if (fl->HiReliefGC != NULL) { > XFreeGC(dpy, fl->HiReliefGC); > fl->HiReliefGC = NULL; > } > if (fl->HiShadowGC != NULL) { > XFreeGC(dpy, fl->HiShadowGC); > fl->HiShadowGC = NULL; > } > } > > In this case, fl->tag is the string "default". Hmm, trying to destroy the > default style? Maybe the string is statically allocated? I didn't look > that far into it. Yep. Fixed it with a strdup. > I haven't yet gotten to the second free message. Setting the malloc > options at runtime is useful, but it doesn't let you get past the first > error. :-/ When I figure that one out I'll send it along. Hope that helps > for now. Hopefully now you'll get to the second problem if it's still around. Please let me know what that is when you find out. Thanks a ton! Greg From owner-scwm-discuss@mit.edu Sun Sep 13 12:33:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11282 for scwm-discuss-outgoing; Sun, 13 Sep 1998 12:33:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11279 for ; Sun, 13 Sep 1998 12:33:11 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA27239; Sun, 13 Sep 98 12:32:49 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id TAA28673 for ; Sun, 13 Sep 1998 19:32:50 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id SAA00874; Sun, 13 Sep 1998 18:32:51 +0200 To: scwm-discuss@mit.edu Subject: Re: iconification problems References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 13 Sep 1998 18:32:51 +0200 In-Reply-To: Greg Badros's message of "12 Sep 1998 14:01:45 -0700" Message-Id: Lines: 45 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > In scwm "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $" some > > applications don't iconify properly - they just disappear from the > > screen. These include xxgdb and netscape. Others do work: xterm etc. > > What does `icon-position' report for the iconified windows? Also, what > is viewport-position? I just added icon-viewport-position to base.scm, > as it was accidentally missing. > > It'd be great if you could narrow it down to either an icon not being > displayed, and icon's position being mis-computed, or an icon being > displayed in the wrong position. > I'll try. Just ran into another bug: maximizing one of my xterms made it move down the screen to display *half* of a caption. The coordinates, reported are: scwm> (icon-position (find-window-by-name "buggy")) (0 0) scwm> (viewport-position) (0 768) According to the window list, the xterm's geometry is 80x56+271+1536. Oh, yes, a *VERY* important part! This only happens on the bottom left virtual screen. On the bottom right virtual screen, it's even more weird - the xterm window gets maximized, and moves to the right, so the only thing I see is about 5 pixels!!! In both cases, switching the virtual screens, makes the xterms disappear, thus making them completely unreacheable. I'll try to create a minimal .scwmrc to show this behaviour. The release is the same as reported above. -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Sun Sep 13 13:02:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA11493 for scwm-discuss-outgoing; Sun, 13 Sep 1998 13:02:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA11490 for ; Sun, 13 Sep 1998 13:02:39 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00561; Sun, 13 Sep 98 13:02:15 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id UAA28989 for ; Sun, 13 Sep 1998 20:02:17 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id TAA01102; Sun, 13 Sep 1998 19:02:18 +0200 To: scwm-discuss@mit.edu Subject: maximization and minimization bugs - good example From: abel@bfr.co.il (Alexander L. Belikoff) Date: 13 Sep 1998 19:02:18 +0200 Message-Id: Lines: 207 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've created a [reasonably small] .scwmrc to expose the two bugs I reported recently: bad xterm's maximization and bad netscape's minimization. Again, the scwm release is Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $ guile is a snapshot 19980806 running on RedHat 4.2 (libc5-based) Here's what you have to do to see the bugs: 1. Make my .scwmrc your default one. 2. Fire up the X (don't do restart to guarantee the sameness of conditions). You'll have 4 virtual screens now. You are located in the top left one. 3. Press C-Down to go to the bottom left screen. Press right mouse button and select 'xterm' from the menu. Press M-F10 on the xterm to maximize it. Enjoy. :-) 4. Press C-Right to go to the *bottom right* screen from the previous one. Open another xterm and try to maximize it. Enjoy. :-) 5. Press C-Up to go to the *top right* screen from the previous one. Brung up another xterm and start Netscape from it. Press the minimization button on the Netscape window. Look for the icon. Regards, PS. Is there any reason, why whenever I restore a window from an icon, it goes to it's original screen, even if I use sticky icons? Is there any way to change it? =========================================================================== ;;-------------------------------;; ;; import the scwm modules ;; (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm doc) (app scwm style) (app scwm face)) (set-smart-placement-is-really-smart! #t) (set-edge-resistance! 500 0) (set-edge-scroll! (%x 100) (%y 100)) (set-edge-wrap! #f #f) ;;-------------------------------;; ;; set some basic styles info ;; (menu-style #:fg "Black" #:bg "Grey70" #:stipple "Grey40" ;; #:font (make-font "*helvetica-medium-r-*-120-*") #:font (make-font #"-*-helvetica-medium-r-*-*-*-100-*-*-*-*-*-*") #:mwm #t) ;;(title-style #:font (make-font "*helvetica-bold-r-*-120-*") (title-style #:font (make-font "-*-helvetica-bold-r-*-*-*-100-*-*-*-*-*-*") #:justify 'left) ;(set-icon-font! (make-font "*helvetica-bold-r-*-120-*")) (set-icon-font! (make-font "fixed")) (set-hilight-foreground! "Black") ;; (set-hilight-background! "Gray70") (set-hilight-background! "CadetBlue") (set-rubber-band-mask! 127) (set-desk-size! 2 2) (define HOME (getenv "HOME")) (define USER (getenv "USER")) (define user-image-load-path (list (string-append HOME "/desktop/icons"))) ;;-------------------------------;; ;; set some paths ;; ;; ;; these are OK for my system, but may need to be changed for ;; yours. This should probably be eventually autoconfed or something. ;;; set path to use for image searches (set! image-load-path (append user-image-load-path '("/usr/X11/lib/X11/mini-icons" "/usr/X11/include/X11/pixmaps" "/usr/lib/icons" "/usr/local/X11/include/X11/pixmaps" "/usr/local/lib/icons" "/usr/local/icons" "/uns/share/include/X11/pixmaps" "/uns/share/include/X11/bitmaps") image-load-path)) ;;-------------------------------;; ;; set some window styles ;; (window-style "*" #:fg "black" #:bg "gray55" #:icon "unknown1.xpm" #:sticky-icon #t #:icon-box (list 0 (y- 20) (y- 50) (y- 1)) #:border-width 6 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:mwm-buttons #t #:mwm-border #t #:int-override #t #:decorate-transient #t #:PPosition-hint #f ) (define desktop-menu (menu (list (menuitem "Desktop" #f) menu-title (menuitem "Xterm" #:image-left "mini-sh1.xpm" #:action (lambda () (execute "xterm"))) (menuitem "Emacs" #:image-left "mini-edit.xpm" #:action (lambda () (execute "emacs"))) menu-separator (menuitem "Restart" #:image-left "mini-turn.xpm" #:action (lambda () (restart "scwm"))) (menuitem "Quit" #:image-left "mini-stop.xpm" #:action quit)))) ;; now set some mouse and key bindings ;; (bind-mouse 'root 2 (lambda () (show-window-list-menu #:show-geometry #t))) (bind-mouse 'root 3 (lambda () (popup-menu desktop-menu))) (bind-mouse 'root "M-2" (lambda () (popup-menu window-ops-menu))) (define (vertical-toggle-maximize) (toggle-maximize 0 (%y 100))) ;; window buttons (bind-mouse 'button-1 1 popup-small-ops) (bind-mouse 'button-2 1 vertical-toggle-maximize) (bind-mouse 'button-4 1 iconify) ;; operations on parts of the window (bind-mouse '(frame sidebar) 1 resize-or-raise) (define (move-or-shade) (case (mouse-event-type) ((double-click) (toggle-window-shade)) (else (move-or-raise)))) (bind-mouse 'title 1 move-or-shade) (bind-mouse '(title frame sidebar) 3 toggle-raise) (bind-key '(window title icon frame sidebar) "M-F10" vertical-toggle-maximize) ;; some stuff for icons (define (move-or-deiconify) (case (mouse-event-type) ((motion) (interactive-move)) ((double-click) (deiconify)))) (bind-mouse 'icon 1 move-or-deiconify) (bind-mouse 'icon 2 deiconify) ;; move the viewport with the keyboard (bind-key 'all "C-Left" (lambda () (move-viewport (%x -100) 0))) (bind-key 'all "C-Right" (lambda () (move-viewport (%x 100) 0))) (bind-key 'all "C-Up" (lambda () (move-viewport 0 (%y -100)))) (bind-key 'all "C-Down" (lambda () (move-viewport 0 (%y 100)))) =========================================================================== -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Sun Sep 13 13:42:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA11873 for scwm-discuss-outgoing; Sun, 13 Sep 1998 13:42:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA11869 for ; Sun, 13 Sep 1998 13:42:37 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04938; Sun, 13 Sep 98 13:42:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA01943; Sun, 13 Sep 1998 10:42:12 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: iconification problems References: From: Greg Badros Date: 13 Sep 1998 10:42:11 -0700 In-Reply-To: abel@bfr.co.il's message of "13 Sep 1998 18:32:51 +0200" Message-Id: Lines: 62 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Greg Badros writes: > > > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > > > In scwm "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $" some > > > applications don't iconify properly - they just disappear from the > > > screen. These include xxgdb and netscape. Others do work: xterm etc. > > > > What does `icon-position' report for the iconified windows? Also, what > > is viewport-position? I just added icon-viewport-position to base.scm, > > as it was accidentally missing. > > > > It'd be great if you could narrow it down to either an icon not being > > displayed, and icon's position being mis-computed, or an icon being > > displayed in the wrong position. > > > > I'll try. Just ran into another bug: maximizing one of my xterms made > it move down the screen to display *half* of a caption. The > coordinates, reported are: > > scwm> (icon-position (find-window-by-name "buggy")) > (0 0) > > scwm> (viewport-position) > (0 768) > > According to the window list, the xterm's geometry is 80x56+271+1536. For windows, window-position reports the position that we care about (not icon-position). That is what window-geometry-string uses. > Oh, yes, a *VERY* important part! This only happens on the bottom left > virtual screen. On the bottom right virtual screen, it's even more > weird - the xterm window gets maximized, and moves to the right, so > the only thing I see is about 5 pixels!!! This is just one of those virtual vs. viewport problems that my cleaning up of of position code exposed. It's now fixed thanks to your pointing out the problem. Thanks! > In both cases, switching the virtual screens, makes the xterms > disappear, thus making them completely unreacheable. You can always use (move-window 0 0 (select-window-from-window-list)) to get it back. > I'll try to create a minimal .scwmrc to show this behaviour. Not needed. I'm all too familiar with these bugs by now. It was an easy fix. I'm gonna go through a bunch of the icon problems now and try to fix some of those bugs. Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 13 14:01:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA12029 for scwm-discuss-outgoing; Sun, 13 Sep 1998 14:01:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA12026 for ; Sun, 13 Sep 1998 14:01:47 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA07265; Sun, 13 Sep 98 14:01:22 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA19465; Sun, 13 Sep 1998 20:01:25 +0200 To: scwm-discuss@mit.edu Subject: size toggling strangeness - bug? Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 13 Sep 1998 20:01:24 +0200 In-Reply-To: Greg Badros's message of "13 Sep 1998 10:42:11 -0700" Message-Id: Lines: 32 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk toggle-maximize also toggles position. For example: 1. Size & position a window. 2. Do (toggle-maximize (%x 100) 0) to it. 3. Move the window. 4. Do (toggle-maximize (%x 100) 0) to it again. Step 4 brings it back to the original size again, but it also moves it back to the original position. I'm not sure if this is intended or not, but it's been around for a long time & I'm certainly not a fan of the behavior. I don't think fvwm has the same behavior. This has been with all versions up to & including 0.8a. I haven't checked in the most recent snapshots. Here's another related behavior - Although toggle-maximize also toggles position, it doesn't preserve window panes. 1. Set up scwm so you have at least 2 horizontal window panes on 1 desk - a left one & a right one. 2. Open up a window in the left pane. 3. Do (toggle-maximize (%x 200) 0) to it. The window should now stretch across both window panes. 4. Move to the right window pane & do (toggle-maximize (%x 200) 0) to it again. It contracts back to its original size, and reverts to its original position, but relative to the new viewport. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Sep 13 17:08:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13106 for scwm-discuss-outgoing; Sun, 13 Sep 1998 17:08:04 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA13100 for ; Sun, 13 Sep 1998 17:08:00 -0400 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA01957; Sun, 13 Sep 98 17:07:32 EDT Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA16927; Sun, 13 Sep 1998 17:14:28 -0400 (EDT) Received: from quirk.struble.c (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA17716; Sun, 13 Sep 1998 17:07:29 -0400 (EDT) Received: from localhost (cstruble@localhost) by quirk.struble.c (8.8.8/8.8.7) with SMTP id RAA08584; Sun, 13 Sep 1998 17:07:35 -0400 (EDT) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sun, 13 Sep 1998 17:07:34 -0400 (EDT) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: window positioning problems in current snapshot In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 13 Sep 1998, Greg Badros wrote: > Yep. Fixed it with a strdup. > Ok, that fixes problem one. > > I haven't yet gotten to the second free message. Setting the malloc > > options at runtime is useful, but it doesn't let you get past the first > > error. :-/ When I figure that one out I'll send it along. Hope that helps > > for now. > > Hopefully now you'll get to the second problem if it's still around. > Please let me know what that is when you find out. > This brings up the second problem, which I did look into more and which seems a bit trickier to deal with (and I found a third small bug in the process). Here's where the problem is: size_t free_decor(SCM obj) { DestroyScwmDecor(SCWMDECOR(obj)); FREE(SCWMDECOR(obj)->tag); /* XXX: This appears to duplicate the FREE in DestroyScwmDecor, the third bug */ FREE(SCWMDECOR(obj)); /* XXX: Here's where scwm aborts */ FREE(DECOR(obj)); return 0; }; The tag == "default" as before, so it's all with freeing the default decor. I think I know why. The default decor (DefaultDecor) is part of the ScreenInfo structure in screen.h. When you allocate space for the screen information, it includes the decor. Later on, the default decor must be getting freed, however its space wasn't allocated directly with malloc(), but as a side effect of allocating the ScreenInfo structure. So, free() is barfing on it because it's technically an invalid pointer for deallocation. You could allocate the default decor like every other decor, or have a special case to avoid deleting it altogether (hence removing the need to strdup("default") as well). Should it ever be deleted anyway? See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sun Sep 13 17:16:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13173 for scwm-discuss-outgoing; Sun, 13 Sep 1998 17:16:01 -0400 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA13167 for ; Sun, 13 Sep 1998 17:16:00 -0400 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA03032; Sun, 13 Sep 98 17:15:32 EDT Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA17918 for ; Sun, 13 Sep 1998 17:22:32 -0400 (EDT) Received: from quirk.struble.c (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id RAA25131 for ; Sun, 13 Sep 1998 17:15:34 -0400 (EDT) Received: from localhost (cstruble@localhost) by quirk.struble.c (8.8.8/8.8.7) with SMTP id RAA08600 for ; Sun, 13 Sep 1998 17:15:47 -0400 (EDT) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sun, 13 Sep 1998 17:15:46 -0400 (EDT) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Pager loses windows Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, here's a new bug I just got with updating today. Here's changed.c: char *szRepoLastChanged = "Sun Sep 13 16:03:10 EDT 1998 -- $Revision: 1.418 $"; Basically all of my windows fail to show up on the pager after I move to their desktop. If I move the window, it shows up again. Then if I move away from their desktop and back again, they disappear from the pager (but still appear on the screen). It looks like there are windows in the pager representing their icons instead. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sun Sep 13 17:59:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13435 for scwm-discuss-outgoing; Sun, 13 Sep 1998 17:59:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA13432 for ; Sun, 13 Sep 1998 17:59:42 -0400 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA08436; Sun, 13 Sep 98 17:59:13 EDT Received: from ZengHe.ens.fr (ZENGHE [139.100.161.82]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id SWVNHZ6Q; Sun, 13 Sep 1998 23:59:21 +0200 Received: (from fare@localhost) by ZengHe.ens.fr (8.8.7/) id XAA05622; Sun, 13 Sep 1998 23:58:17 +0200 Message-Id: <19980913235817.A5618@ZengHe.issy.cnet.fr> Date: Sun, 13 Sep 1998 23:58:17 +0200 From: Francois-Rene Rideau To: scwm-discuss@mit.edu Subject: scwm user report Reply-To: Francois-Rene Rideau Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.ens.fr id XAA05622 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA13433 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dear SCWM developers, I have the pleasure to announce that I'm now a scwm user! Despite my enabling it, you hopefully won't get many UDP usage packets, since I'm on a laptop with an inherent persistent session, that I try to reboot as seldom as possible (hey, this ain't Shitdows'9x). I hadn't tried scwm since 0.5, 0.6 or so, and am quite satisfied with the progress. I'm using the scwm-19980911.tar.gz with the guile-core-19980806-2.i386.rpm from the RedHat 5.1 contrib directory, without cassowary. COMPILATION: At first, scwm would NOT compile correctly. I almost renounced, but then, I remembered from times when I read scwm-discuss that by modifying config.h, I could perhaps get it to work. Indeed, this worked. This means that scwm could NOT autodetect features in libguile. However, NO SINGLE DOCUMENT coming with scwm would suggest to edit config.h; So newbies can't possibly get scwm to compile! Scary. Actually, newbies may be prone to having guile 1.2, which may (or not) compile out-of-the-box; still, that's no encouragement to would-be users; all the less since most of the features could be detected by determining where libguile is, and using nm. This is actually how I did it myself. And in case all that is not portably doable, surely such autodetection should be added in guile itself as a feature to help building of guile-based packages. BUG WITH ABSOLUTE/RELATIVE GEOMETRY: The recent change between absolute and relative coordinates in geometry has broken a lot of things: Windows maximize code is broken. xv always start in initial screen. The pager goes wierd as the non-current desktop's position (frozen in the way they were when the desktop was left) are interpreted relative to the current desktop. the current desktop seems ok, but when you change desktop, the other desktop becomes relative when the current one is absolute; and when you come back to the original desktop, it doesn't fix it until you move the current desktop sub-screen. KEYBOARD FILTERING: When I tested out scwm 0.5, I was pleased of the send-string function, which allowed me to have shortcut typing shared by all apps (and with which I intended to write an X-wide vietnamese keyboard filter). It doesn't seem to work anymore (key is intercepted, but nothing shows in either emacs or xterm, w/ or without "Allow send events"; and I tried X-synthetic-send-string, too). Am I doing anything wrong? DEFAULT CONFIGURATION: The system.scwmrc is not usable AT ALL. The various .scwmrc samples show that scwm has a truly great potential; but none of them is really usable, either, they explore a tiny part of scwm's capabilities, and they again are very clumsy to use. What I propose is that the default user configuration 1) be usable (features in it may be computed/detected at compile-time, and regenerated by super-user once in a while) 2) include a grand tour of scwm's feature, probably as an optional demand-loaded set of features, and perhaps even as an interactive demonstration. It might even end up being interactively customizable (reading/dumping standard forms in some .scwmrc.options). MENUS: When there's enough power for it, it would be nice that (as an option) menus that don't fit the space to the right of their scheduled place would push the main menu left (which would or not go back right if the submenu is deactivated), so you don't have to move the pointer to access the submenu (which is *very* annoying when the pointing device is little usable, like some touchpad or accupoint and other crappoint found on laptops). I think that *Step does that already. CACHEING: a source of slowdown at startup is the detection of path, programs, and features (which we may want to do at other moment than just startup, particularly in persistent scwm sessions like I intend to have). This is particularly annoying if we are to generalize detection a la wmconfig or other; or if there are lots of NFS mounted partitions, including unreliable ones, and detection may take a *very* long time. In such cases, we may want to have a mechanism of "cache" of available features, that gets explicitly refreshed. When we have such mechanism, the "normal case" is cheap, and we can afford doing sophisticated autodetection for the unusual case. Autodetection may include searching PATHs and wmconfig databases; locate(1)ing pixmaps, or using various heuristics to find their location; and more. WINDOW SIZES: I'd like window sizes to adapt to winmgr settings. For instance, I just do want many apps to be fullscreen (netscape, xdvi, gv, etc). scwm should modify the Xdefaults depending on decoration sizes so they fit; conversely, it should detect full-screen windows, and take appropriate actions (like, no decoration at all, or changing window geometry to fit the screen once decoration is there). STANDARD KEY BINDINGS: Maybe it's time to standardize keybindings among winmanagers? Anyway, if we are to allow nice enduser-settability of key bindings, we'd better push for a two-level setup, by which "physical" keyboard events be translated into "logical" window-manager event, that are then interpreted. Even Emacs somehow does it, by insisting that bindings go to "commands", that are distinguished from other closures, and must have a printable form (usually just a procedure name that you can look up in documentation). NON-PORTABILITY: Also, gjb.scwmrc as well as flux.scm make some untrue assumptions about variable USER being defined (this is done by bash; login defines only LOGNAME; zsh defines USERNAME). gjb.scwmrc also assumes that mail is in /var/spool/mail; this isn't true everywere (e.g. not on Slowaris); however, variable MAIL is defined by login, so let's use it. MAILING-LIST: I'm no more subscribed to the list, not because it isn't interesting (it sure IS interesting), but because it has more volume than I can handle; hence, please send replies to fare@tunes.org. ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Knowledge and Technology are the byproduct of Science as it progresses, just like slime is the byproduct of the snail as it moves on. From owner-scwm-discuss@mit.edu Sun Sep 13 19:15:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA14208 for scwm-discuss-outgoing; Sun, 13 Sep 1998 19:15:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA14202 for ; Sun, 13 Sep 1998 19:15:00 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA01801; Sun, 13 Sep 98 19:14:30 EDT Received: (qmail 6896 invoked by uid 501); 13 Sep 1998 23:14:53 -0000 Message-Id: <19980913161452.A6797@molehill.org> Date: Sun, 13 Sep 1998 16:14:52 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Message window position Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=zYM0uCDKw75PZbzx X-Mailer: Mutt 0.91i X-Tom-Swifty: "Vote for Reagan", said Tom electronically. Sender: owner-scwm-discuss@mit.edu Precedence: bulk --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii I keep losing the message (geometry) window when moving or resizing windows - I prefer it in the upper left corner to the center of the screen. I think I'd actually prefer it following the mouse, offset by maybe 20 pixels. Attached is a patch that gets part of the way there. To get the rest of the way there, I think I need to be able to hook into the middle of MoveLoop. Any hints on that? --zYM0uCDKw75PZbzx Content-Type: application/x-patch Content-Disposition: attachment; filename="msg-window-geo.patch" ? build-x86 ? build-ppc Index: scwm/move.c =================================================================== RCS file: /anoncvs/scwm/scwm/move.c,v retrieving revision 1.62 diff -u -r1.62 move.c --- move.c 1998/09/13 19:59:23 1.62 +++ move.c 1998/09/13 23:02:57 @@ -455,19 +455,27 @@ int winwidth = textwidth + SIZE_HINDENT*2; int textheight = FONTHEIGHT(Scr.msg_window_font); int winheight = textheight + SIZE_VINDENT*2; + int win_x, win_y; + GC gcMsg = Scr.ScratchGC2; GC gcHilite = Scr.ScratchGC2; GC gcShadow = Scr.ScratchGC3; SCM scmFgRelief, scmBgRelief; scmBgRelief = adjust_brightness(Scr.msg_window_bg, message_shadow_factor); scmFgRelief = adjust_brightness(Scr.msg_window_bg, message_hilight_factor); - + SetGCFg(gcHilite,XCOLOR(scmFgRelief)); SetGCFg(gcShadow,XCOLOR(scmBgRelief)); + + if (Scr.msg_window_geo) { + win_x = Scr.msg_window_x; + win_y = Scr.msg_window_y; + } else { + win_x = (Scr.DisplayWidth-winwidth)/2; + win_y = (Scr.DisplayHeight-winheight)/2; + } - XMoveResizeWindow(dpy, Scr.MsgWindow, - (Scr.DisplayWidth-winwidth)/2,(Scr.DisplayHeight-winheight)/2, - winwidth, winheight); + XMoveResizeWindow(dpy, Scr.MsgWindow, win_x, win_y, winwidth, winheight); if (fRelief) { XClearWindow(dpy, Scr.MsgWindow); Index: scwm/resize.c =================================================================== RCS file: /anoncvs/scwm/scwm/resize.c,v retrieving revision 1.44 diff -u -r1.44 resize.c --- resize.c 1998/09/11 22:46:48 1.44 +++ resize.c 1998/09/13 23:02:59 @@ -81,6 +81,56 @@ } #undef FUNC_NAME +SCWM_PROC(set_message_window_position_x, "set-message-window-position!", 2, 0, 0, + (SCM x, SCM y)) + /** Set the position to be used for the message window. +*/ +#define FUNC_NAME s_set_message_window_position_x +{ + SCM_REDEFER_INTS; + + if (!gh_number_p(x)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 1, x); + } + if (!gh_number_p(y)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 2, y); + } + + Scr.msg_window_geo = True; + Scr.msg_window_x = gh_scm2long(x); + Scr.msg_window_y = gh_scm2long(y); + + SCM_REALLOW_INTS; + + XMoveWindow(dpy, Scr.MsgWindow, x, y); + return SCM_UNDEFINED; +} +#undef FUNC_NAME + +SCWM_PROC(unset_message_window_position_x, "unset-message-window-position!", 0, 0, 0, + ()) + /** Return the message window to the center of the screen. +*/ +#define FUNC_NAME s_unset_message_window_position_x +{ + int x, y; + unsigned int width, height; + Scr.msg_window_geo = False; + Scr.msg_window_x = gh_scm2long(x); + Scr.msg_window_y = gh_scm2long(y); + + XGetGeometry(dpy, Scr.MsgWindow, &JunkRoot, &x, &y, + &width, &height, + &JunkBW, &JunkDepth); + + x = (Scr.DisplayWidth - width)/2; + y = (Scr.DisplayHeight - height)/2; + XMoveWindow(dpy, Scr.MsgWindow, x, y); + return SCM_UNDEFINED; +} +#undef FUNC_NAME SCWM_PROC (display_message, "display-message", 1, 0, 0, Index: scwm/screen.h =================================================================== RCS file: /anoncvs/scwm/scwm/screen.h,v retrieving revision 1.38 diff -u -r1.38 screen.h --- screen.h 1998/09/08 17:58:46 1.38 +++ screen.h 1998/09/13 23:03:00 @@ -233,6 +233,9 @@ SCM msg_window_font; /* font for the size/position window */ SCM msg_window_fg; /* fg color for the size/position window */ SCM msg_window_bg; /* bg color for the size/position window */ + Bool msg_window_geo; /* true if msg_window_{x,y} to be used */ + int msg_window_x; /* x position of the size/position window */ + int msg_window_y; /* y position of the size/position window */ GC MenuGC; GC MenuStippleGC; Index: scwm/scwm.c =================================================================== RCS file: /anoncvs/scwm/scwm/scwm.c,v retrieving revision 1.125 diff -u -r1.125 scwm.c --- scwm.c 1998/09/13 16:26:25 1.125 +++ scwm.c 1998/09/13 23:03:04 @@ -312,6 +312,7 @@ Scr.msg_window_font = make_font(str_fixed); Scr.msg_window_fg = BLACK_COLOR; Scr.msg_window_bg = WHITE_COLOR; + Scr.msg_window_geo = False; Scr.MenuColors.bg = SCM_UNDEFINED; Scr.DefaultDecor.HiColors.bg = SCM_UNDEFINED; --zYM0uCDKw75PZbzx-- From owner-scwm-discuss@mit.edu Sun Sep 13 21:39:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15002 for scwm-discuss-outgoing; Sun, 13 Sep 1998 21:39:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA14999 for ; Sun, 13 Sep 1998 21:39:47 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA06848; Sun, 13 Sep 98 21:39:13 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA02787; Sun, 13 Sep 1998 18:39:10 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Message window position References: <19980913161452.A6797@molehill.org> From: Greg Badros Date: 13 Sep 1998 18:39:10 -0700 In-Reply-To: Todd Larason's message of "Sun, 13 Sep 1998 16:14:52 -0700" Message-Id: Lines: 42 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > --zYM0uCDKw75PZbzx > Content-Type: text/plain; charset=us-ascii > > I keep losing the message (geometry) window when moving or resizing > windows - I prefer it in the upper left corner to the center of the > screen. I think I'd actually prefer it following the mouse, offset by > maybe 20 pixels. > > Attached is a patch that gets part of the way there. To get the > rest of the way there, I think I need to be able to hook into the > middle of MoveLoop. Any hints on that? I was thinking of doing this, too. Your change looks good. A couple of comments: 1) It'd be nice to be able to give a position and a "gravity." I.e., you should be able to express "centered at Scr.DisplayWidth/2,Scr.DisplayHeight/2" or "NW at 0,0". Maciej's dealt with the gravity stuff for windows before, so maybe he or his code might be useful in figuring out a clean way to do this. 2) With the above generalization, msg_window_geo becomes superfluous, and unset-message-window-position! can then be written in scheme and need no longer be a primitive. Wrt your question about moveLoop -- I think the right thing to do is have a user-hook called to report the new position of a window (InteractiveResize would need this too). We may need a hook for starting an interactive move/resize, and another for ending, in addition to per-new position/size event. The functions call[N]_hooks is used to call a hook and SCWM_HOOK is used to define a hook. Search for cannot_grab_hook in *.[ch] for an example. The start/stop should probably get the window being moved/resized, and the looping new position/size hook should get 3 values -- the new x, the new y, and the window. This'll be a nice addition if you'd like to follow through with the enhancement... Thanks! Greg From owner-scwm-discuss@mit.edu Sun Sep 13 21:59:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15247 for scwm-discuss-outgoing; Sun, 13 Sep 1998 21:59:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA15244 for ; Sun, 13 Sep 1998 21:59:07 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA11912; Sun, 13 Sep 98 21:58:33 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA02866; Sun, 13 Sep 1998 18:58:38 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: From: Greg Badros Date: 13 Sep 1998 18:58:38 -0700 In-Reply-To: hjstein@bfr.co.il's message of "13 Sep 1998 20:01:24 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > toggle-maximize also toggles position. For example: > > 1. Size & position a window. > 2. Do (toggle-maximize (%x 100) 0) to it. > 3. Move the window. > 4. Do (toggle-maximize (%x 100) 0) to it again. > > Step 4 brings it back to the original size again, but it also moves it > back to the original position. I'm not sure if this is intended or > not, but it's been around for a long time & I'm certainly not a fan of > the behavior. I don't think fvwm has the same behavior. toggle-maximize isn't written the way I'd like it either, but I think the primitives exist to do a more complete job with the better behaviours you're looking for. Perhaps you could write a new version that acts as you'd like it (and point out bugs in primitives as you encounter them, or request other C-level support that you might need). Thanks! Greg From owner-scwm-discuss@mit.edu Sun Sep 13 22:00:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA15263 for scwm-discuss-outgoing; Sun, 13 Sep 1998 22:00:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA15260 for ; Sun, 13 Sep 1998 22:00:45 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA25466; Sun, 13 Sep 98 22:00:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA02888; Sun, 13 Sep 1998 19:00:16 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: maximization and minimization bugs - good example References: From: Greg Badros Date: 13 Sep 1998 19:00:16 -0700 In-Reply-To: abel@bfr.co.il's message of "13 Sep 1998 19:02:18 +0200" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > I've created a [reasonably small] .scwmrc to expose the two bugs I > reported recently: bad xterm's maximization and bad netscape's > minimization. Again, the scwm release is Lots of changes in this code.... hopefully fixing these and numerous other bugs.... let me know if they're still there. Thanks for the nice description which made everything easy for me to find! (For these positioning bugs, you can often just give me a snippet of scheme code to execute on a window after telling me what the state of the window is [iconified or not, sticky or not, position, etc.]). Thanks! Greg From owner-scwm-discuss@mit.edu Sun Sep 13 22:30:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA15585 for scwm-discuss-outgoing; Sun, 13 Sep 1998 22:30:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA15582 for ; Sun, 13 Sep 1998 22:30:24 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA02409; Sun, 13 Sep 98 22:29:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id TAA02958; Sun, 13 Sep 1998 19:29:45 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> From: Greg Badros Date: 13 Sep 1998 19:29:45 -0700 In-Reply-To: Francois-Rene Rideau's message of "Sun, 13 Sep 1998 23:58:17 +0200" Message-Id: Lines: 60 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Thanks for the message-- I'll have more to write later, perhaps, but two quick remarks: Francois-Rene Rideau writes: > > COMPILATION: > At first, scwm would NOT compile correctly. I almost renounced, but then, > I remembered from times when I read scwm-discuss that by modifying config.h, > I could perhaps get it to work. Indeed, this worked. > This means that scwm could NOT autodetect features in libguile. > However, NO SINGLE DOCUMENT coming with scwm would suggest to edit config.h; Because one shouldn't have to. Please report this as a bug -- see BUG-REPORTING... what did you have to change in config.h? We need to fix this. > So newbies can't possibly get scwm to compile! Scary. Actually, newbies may > be prone to having guile 1.2, which may (or not) compile out-of-the-box; > still, that's no encouragement to would-be users; all the less since most > of the features could be detected by determining where libguile is, > and using nm. This is actually how I did it myself. And in case all that > is not portably doable, surely such autodetection should be added > in guile itself as a feature to help building of guile-based packages. Perhaps -- you should make a proposal to their mailing list. I think a large fraction of the build problems will go away when guile-1.3 comes out since we can completely ignore -1.2. > > BUG WITH ABSOLUTE/RELATIVE GEOMETRY: > The recent change between absolute and relative coordinates in geometry > has broken a lot of things: > Windows maximize code is broken. > xv always start in initial screen. > The pager goes wierd as the non-current desktop's position (frozen > in the way they were when the desktop was left) are interpreted > relative to the current desktop. I need a changed.c revision number to tell if these are relevant any longer-- I've been fixing all sorts of little mistakes where fvwm2 was sloppy about whether a virtual or a viewport position is intended, and we now have to be more careful. > KEYBOARD FILTERING: > When I tested out scwm 0.5, I was pleased of the send-string function, > which allowed me to have shortcut typing shared by all apps > (and with which I intended to write an X-wide vietnamese keyboard filter). > It doesn't seem to work anymore (key is intercepted, but nothing shows > in either emacs or xterm, w/ or without "Allow send events"; and I tried > X-synthetic-send-string, too). Am I doing anything wrong? No-- if you look at the error output it points out the simple bug -- `w' was used instead of `win'. I just fixed this in flux.scm. Thanks! More later... gotta run... Greg From owner-scwm-discuss@mit.edu Sun Sep 13 23:17:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA15844 for scwm-discuss-outgoing; Sun, 13 Sep 1998 23:17:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA15840; Sun, 13 Sep 1998 23:17:02 -0400 Message-Id: <199809140317.XAA15840@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Comments on the latest version of the event model proposal Date: Sun, 13 Sep 1998 23:17:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Event Rewrite Proposal for Scwm > Greg J. Badros, 6-Aug-1998, revised 2-Sep-1998, 3-Sep-1998, 5-Sep-1998 > (Inspired by conversations w/ Maciej and his "events" proposal in this > same directory) > > Intro: > ------ > > Motivating desires for a more flexible event-binding infrastructure > > o Elimination of "contexts" and replacing with event maps > -- event maps are more fundamental, and unifying > o Mode-specific event maps (e.g., when in an interactive move) > o Pinnable-menus event maps > o Multi-key bindings with prefix keys that change mode map > o Maps on a per window basis (e.g., xlogo could permit fewer modifier > keys to accompany an "m" keystroke to signify a desire to move the > window) > o Quoting mechanism for turning off scwm's handling of events > o Unifying X-events and user events I have a few additional motivations which I think should be added to this list (symbolic though it is): o Providing a complete interface that allows people to implement desired capablities which can not be achieved with the current event binding infrastructure; this will likely include capablities that we feel no need to provide a more convenient interface for, but that some users may desire anyway. o Provide a base for implementing a higher-level event binding system that may be less complete, but is very easy to understand, and at least superficially similar to the current system. Where I have them prepared, I will present concrete alternatives to the current proposal that I believe are more in line with the goals, as ammended by me. In other places, I will merely throw out ideas in the hopes that they can > As you wrote, event maps and event objects should be exposed to the > scheme layer as SMOBs (first class objects). The event maps will > contain event objects which are bound to procedures to be invoked. > Event maps will be attached to X windows (via Xlib's SaveContext > mechanism) and scheme window objects (using their top-level frame > window). E.g., an event map can be attached to a titlebar button > window, or to the titlebar window, etc. Upon further consideration, I think event specifiers should be a different type of object than events. I say this because event specifiers may contain some types of data that make no sense in actual events, and vice versa. For instance, a mouse-down event object should include the X and Y coordiantes where the event occured. However, this makes no sense for an event specifier. Contrariwise, in an event specifier, it may be desirable to include something representing some sort of filter in a given field, rather than a concrete value. For instance, it may be desirable to bind a procedure to be launched on any keypress event, by passing some magical constant such as #t, #f, or some special symbol in the key specifier field. But this would make no sense for an event to be dispatched on. Thus, I will present below a proposal for separate event and event-specifier types. > Overview: > --------- > 1 - Event Objects > 2 - Event Map Objects > 3 - Dispatch of Events > 4 - Binding of Event Maps > 1 - Event objects: > ------------------ > (make-key-event KEYSYM-NAME #&optional MODIFIER-SPECIFIER) > e.g.: > (make-key-event "F1") > (make-key-event "Return" '(control shift meta)) > KEYSYM-NAME is the name of a keysym (e.g., "x", "BackSpace", etc.). > It cannot have prefixed modifiers -- a convenience function can provide > conversions from (e.g., "C-S-M-Return" to the 2nd example above). > [[ The special pseudo-keysyms "KeyPress" and "KeyRelease" permit > events being bound to some combination of modifier keys just being > depressed or released. (These may not be necessary thanks to make-x-event)]] > > MODIFIER-SPECIFIER is a list of symbolic modifiers. If the first > element of the list is the pseudo-modifier 'exactly, then exactly > the list of modifiers that follows must be depressed for the event > to be matched. Modifiers include: > > 'control 'shift 'meta 'super 'alt 'hyper 'numlock 'capslock 'mod[1-8] > '~control '~shift '~meta '~super '~alt '~hyper '~numlock '~capslock > '~mod[1-8] > '*control '*shift '*meta '*super '*alt '*hyper '*numlock '*capslock > '*mod[1-8] > > The "~"-prefixes mean *not* that modifier, the "*"-prefixes mean don't > care either way for that modifier (only useful in conjunction with the > pseudo-modifier 'exactly. e.g., > > '(exactly control shift meta) > is the same as > '(control shift meta ~super ~alt ~hyper ~numlock ~capslock) > and > '(exactly control shift meta *numlock) > is the same as > '(control shift meta ~super ~alt ~hyper ~capslock) > > Another first-element pseudo-modifier is 'with, which is the same as > 'exactly, except for an implicit *numlock *capslock. 'iwith is the same > as 'with except for adding an implicit *shift, as well. > > These get converted internally to on and off bitmasks such that the > event matches iff: > ((MOD | OnMask == MOD) && (MOD & ~OffMask == MOD)). > Rebinding of modifiers will recompute the bitmasks. > > (Thanks to Robert Bihlmeyer who made useful comments regarding this > subsection.) > > (make-mouse-event BUTTON-SPECIFIER X-EVENT-SPECIFIER > #&optional MODIFIER-SPECIFIER) > e.g., > (make-mouse-event 1 'release) > (make-mouse-event 3 'double-click (with-modifier 'control 'meta 'shift)) > > BUTTON-SPECIFIER is the physical number of the button (a level of > indirection could easily be provided by variables named e.g., select > drag and menu, corresponding to buttons 1 2 and 3). Button number 0 > matches any/all buttons. Button -1 matches no button. Chorded buttons > are not specifiable directly -- the attached proc will have to check the > event if they are desired (their complexity for user interaction is > worth discouraging). > > X-EVENT-SPECIFIER is one of 'motion, 'press, 'release, 'click, > 'single-click or 'double-click. ('click, 'single-click and > 'double-click get manufactured by scwm -- a 'click is a press followed > by a release w/o intervening motion or too much intervening time. A > 'double-click is two clicks w/o intervening motion or too much > intervening time, and a 'single-click is a 'click that is not followed > by a second click; note that a 'click will always precede a > 'double-click, and the second click of a 'double-click will not generate > another 'click. A 'single-click is generated after the double-click > timeout after a 'click). E.g., the below are valid MOUSE_SPECIFIERs > > MODIFIER-SPECIFIER is as described above. > > > (make-x-event X-EVENT-SPECIFIER #&optional MODIFIER-SPECIFIER) > e.g., > (make-x-event 'enter-notify) > (make-x-event 'keypress (with-modifer 'control 'shift 'meta)) > (make-x-event 'pointer-motion (with-modifier 'hyper)) > > X-EVENT-SPECIFIER is a symbol referring to an X11 event. keypress, > keyrelease, enter-notify, leave-notify, pointer-motion, property-notify, > colormap-notify, focus-in, focus-out, etc. could be supported (see > include/X11/X.h for list). Binding procedures to these events could > replace some of the ad-hoc mechanisms for property-notification, etc., > that we currently have in scwm. > > MODIFIER-SPECIFIER is as described above. It is included > mostly for completeness and orthogonality. 'keypress events may test > for modifiers using the current state of the modifiers, not the state > under which the key was pressed. E.g., if Ctrl-Shift-Meta is depressed, > whichever of the three modifier keys that is physically registered last > will not be in the modifier bitmask for that keypress, but we might like > to bind something (e.g., a help menu) to those three keys being held > down. > > Note that make-x-event is the most primitive case, and the other two > procedures can be seen as adding a C-level filter on top of the actual > X-event. E.g., (make-mouse-event 1 'release) is applicable if there > is a x-event "ButtonRelease" and the button number is 1. > > I will respond to this section in whole, because I have pervasive changes to suggest. First of all, I think event specifiers should be different from event objects, and most of this section deals with specifiers. I suggest the following changes to the interface for event-specs: ** EVENT-SPECS ** -- Creating Event Specs -- (make-event-spec EVENT-TYPE #&rest FIELD-SPECS) EVENT-TYPE is a symbol identifying the type of X event. It should also include some events synthesized by scwm itself which are provided for convenience (mouse-click, mouse-double-click, mouse-single-click, etc). It should include at least the following (symbolic names, X11 names where appropriate, and brief explanations are given): 'key-down (KeyPress) 'key-up (KeyRelease) 'mouse-down (ButtonPress) 'mouse-up (ButtonRelease) 'mouse-drag (MotionNotify with at least one button down) 'mouse-move (MotionNotify with no mouse buttons down) 'mouse-click (A ButtonRelease that happens in the same window as a ButtonPress, but does not consitute the second click of a double click 'mouse-double-click (If the conditions for a mouse-click happen within some given time limit, a mouse-double-click is sent instead perhaps a movement threshold should also be provided) 'mouse-single-click (A click followed by enough time to definitively not constitute a double click. To summarize, when the mouse is single-clicked, 'mouse-click is sent immediately, and 'mouse-single-click is sent after the double click delay time passes. When it is double-clicked, 'mouse-click is sent immediately after the first click, and 'mouse-double-click is sent immediately after the second; 'mouse-single-click is not sent at all. 'mouse-up is sent on each release of the mouse in both cases. This should allow the full desired set of single-click semantics.) 'enter-notify (EnterNotify) 'leave-notify (LeaveNotify) 'focus-in (FocusIn) 'focus-out (FocusOut) 'visibility-notify (VisiblityNotify) 'property-notify (PropertyNotify) 'colormap-notify (ColormapNotify - comment: why is this useful?) 'mapping-notify (MappingNotify) * Synthetic events that could be added: 'mouse-one-and-a-half-click (A mouse click followed by a drag within the double click timeout - perhaps 'mouse-click-and-drag is a better name), 'mouse-triple-click (supported by Gtk, but probably not widely used), and 'mouse-double-click-and-drag (for orthogonality if the previous two are supported). Alternatively, a convenient way to mix timers with event maps may allow these (as well as orinary click events) to be synthesized by higher layers. * X events that should be supported in a different way, because attaching them to window-based event maps is illogical or inefficient: CreateNotify, DestroyNotify (in my opinion, these are better handled by special-case hooks. The former is illogical because it would not be in a window's event map until _after_ the window is created. The latter we only care about for top-level windows and probably want to handle specially to avoid race conditions). * X events ignored for now, though we may want to support them later: KeymapNotify, Expose, GraphicsExpose, NoExpose, UnmapNotify, MapNotify, MapRequest, ReparentNotify, ConfigureNotify, ConfigureRequest, GravityNotify, ResizeRequest, CirculateNotify, CirculateRequest, SelectionClear, SelectionRequest, SelectionNotify, ClientMessage ClientMessage may be especially useful to add, for the purpose of supporting custom protocols. * Commentary on "global" events: Some events are inherently not per-window, but global in the scope of the events of which they notify the application. These include (IMO) mapping-notify and colormap-notify. It may not be appropriate to handle these events through the event map mechanism; it may instead be preferrable to handle them through FIELD-SPECS is a list of specifiers for particular fields. The nature of a field specifier will be described first; then five possible syntaxes for the field specifiers will be proposed. A field specifier is a field used for filtering events according to particular fields (see the discussion of fields below in the section on event objects to see which events support what fields). It may be either an exact field value, which must be matched, the symbol '*, to indicate that this field should be ignored entirely when matching events, a procedure which should be a predicate of one argument, or possibly a special other value which is available for some fields. An event matches an event specifier if its type is the same, and all of its fields individually match the event specifier fields. An event field matches an event specifier field if any of the followind is true: * The value of the event field is identical to the event-spec field * The event-spec field in question has a value of '* * The event-spec field is a procedure, and returns a true value when applied to the event field. * The event-spec field is a special field-specific specifier and matches according to the relevant rules. The only special event-spec field value reccomended by now is the following for the 'modifiers field in many events: A pair of two lists can be accepted for a 'modifiers event-spec field; the first list is the list of names of modifiers that must be on, and the second is a list of modifers names that must be off. A modifier not present in either list is ignored entirely. The following syntaxes are suggested. For each of them, a field-spec not provided is assumed to be '*. 1) A fixed order of fields dependent on the event type. This may be less verbose, and perhaps easier to parse, but it may be confusing and awkward. 2) Name-value pairs or two-element lists, which may be provided in any order. This is clearer than the above 3) A set of keyword arguments. This is probably the most clear and consistent, but may be a bit harder to parse from C. Also, using it for events as well as event-specs may be a bit silly, since all fields must be provided to make an event, and keywords generally indicate optional constructs. 4) A combination of 1 and 2; Some optional aguemnts for each event type (the most commonly used ones) in a fixed order, followed by 5) -- Examining Event-Specs -- (event-spec-type EVENT-SPEC) Return the event type of the event specifier EVENT-SPEC. (event-spec-field EVENT-SPEC FIELD-NAME) Return the value of the field named by the symbol FIELD-NAME in EVENT-SPEC. Motivation: There are several changes in this version as compared to the previous version. Here is the motivation for them: o Single make-event-spec procedure vs. several specialized ones: Much functionality is common; IMO at this level of interface, we should keep things simple and leave greater convenience to the higher-level interfaces. o Making event filtering simple and uniform: IMO, this is the right thing for the low-level interface. We can pick convenient subsets of the functionality w/ convenient interfaces for the higher-level version. The whole decision about the user's intentions when trying to bind key events, for instance, can be punted to a higher level. ** EVENTS ** Events will be treated similarly to event specifiers except that, of course, they have different usages and different sets of restrictions on their fields. -- Creating Event Objetcs -- (make-event EVENT-TYPE #&rest FIELDS) The EVENT-TYPE field is any of the event types supported by The syntax for the FIELDS arguments should be similar to that for the FIELD-SPECS argument of make-event-spec, but all applicable fields are mandatory. Here is a list of the possible fields and their Scheme types: 'synthetic (boolean) 'window (integer - X window ID) 'root (integer - X window ID) 'subwindow (integer - X window ID) 'time (whatever type is appropriate for times in Scheme) 'x (integer) 'y (integer) 'x-root (integer) 'y-root (integer) 'property (either a string or an integer representing an X atom; which is better?) 'state (symbol; valid values depend on the event type. For 'property-notify : 'deleted or 'new-value ; For 'visibility-notify : 'unobscured, 'partially-obscured or 'fully-obscured ; ) 'request (symbol - one of 'modifier, 'keyboard or 'pointer) 'modifiers (list of symbols, each one of 'control 'shift 'meta 'super 'alt 'hyper 'numlock 'capslock 'mod[1-5] symbolic names will be given in preference to mod[1-5] names whenever possible.) 'buttons (list of the numbers 1-5) ;; maybe this should be ditched? 'button (an integer 1-5) 'key a string naming the key (we'll have to turn a keycode into a keysym and that in turn into a symbolic name - that will sure be fun) [Note to greg: X11 only supports mod1-5 AFAIK, so 6-8 are pointless] Here is a list of which events have which fields: All events: 'synthetic 'window All mouse and key events: 'root 'subwindow 'x 'y 'x-root 'time 'modifiers 'buttons Event: Extra fields supported: 'key-down (mouse/key fields) 'key 'key-up (mouse/key fields) 'key 'mouse-down (mouse/key fields) 'button 'mouse-up (mouse/key fields) 'button 'mouse-drag (mouse/key fields) 'button 'mouse-move (mouse/key fields) 'button 'mouse-click (mouse/key fields) 'button 'mouse-double-click (mouse/key fields) 'button 'mouse-single-click (mouse/key fields) 'button 'enter-notify (mouse/key fields) 'leave-notify (mouse/key fields) 'focus-in 'focus-out 'visibility-notify 'state 'property-notify 'property 'time 'state 'colormap-notify (I'm not sure what is useful to expose to Scheme 'cause I'm not sure why this event is useful to Scheme in the first place) 'mapping-notify 'request Implementation note: event-specs should use a representation that allocates common field-specs statically and rarely cared about ones dynamically for the sake of efficiency. Event objects could just contain an XEvent internally. > 2 - Event Map Objects: > ---------------------- > > Now, on to event map objects. My proposal is similar to yours but > instead of managing the installed event-map from Scheme code, I want to > attach event map objects to arbitrary X11 windows (e.g., the pager, or a > pinned menu, etc.), and have the appropriate grabs and XSelectInput > calls happen based on the event map for a given window. > Geometry-based hierarchy and installation of maps is obviously an excellent addition. One caveat: events should never propagate from any part of an application window to the root window (IMO). > First, a means of creating event-maps and populating them with bindings > from events to procedures: > > (make-event-map #&optional PARENT MERGE?) > ;; PARENT is an event-map object, or omitted or #f to indicate no parent > (I don't think we need to worry about delaying events, but I'm not sure > what problem that suggestion was trying to solve). > This will permit a form of inheritance of behaviours. Note, though, > that this mechanism should not be necessary for the geometry-based > chaining that X11 commonly uses. E.g., an event in a window decoration > (say, a button on the titlebar) will first dispatch based on the event > map (if any) attached to the decoration, then on the event map for that > top-level window, then on the global event map. Each of these event maps > would be built with the PARENT argument omitted or #f. A special > primitive or symbol can be bound to an event to permit preventing the > event from propagating, and instead letting it pass to the application. > MERGE? is #t to indicate that the resulting event-map should (for the > purposes of event dispatch) treat the PARENT's bindings as equipotent to > this new child event (i.e. all of the bindings will be checked when > doing dispatch). MERGE? is #f to indicate that only if no binding > matched in the child should the parent's bindings be checked. > How about allowing a list of parents to be specifier directly? i.e. add a rest argument which must be event maps optionally followed by a boolean field. Or something. It seems awkward to have to add extra parents explicitly. > event-map-global > ;; the built-in global event-map object -- it is an implicit, > ;; non-merged parent of all event-maps > I suggest replacing this by procedures, because it is probably a big lose to ever let the global event map not be an event map. i.e. there should be procedures (set-global-event-map! EVENT-MAP) and (global-event-map). > (event-map-parents EVENT-MAP) > ;; Return list of cons pairs (PARENT-EVENT-MAP . MERGE?) > (add-event-map-parent! EVENT-MAP PARENT MERGE?) > ;; Permit multiple parents, though only one can be specified at a time Suggest renaming this to event-map-add-parent! > (remove-event-map-parent! EVENT-MAP PARENT) > ;; return #t if successful, #f if parent not found Suggest renaming this to event-map-remove-parent! > (add-event-binding EVENT-MAP EVENT PROC-OR-SYMBOL) > (remove-event-binding EVENT-MAP EVENT) > ;; Similar to your {add,remove}-event-hook. > ;; These add and remove bindings for EVENT objects in the given > ;; EVENT-MAP object. > ;; PROC-OR-SYMBOL is either a procedure or 'pass to indicate > ;; that the event should not be grabbed by the wm and the application > ;; should get the event (this is only an issue for event maps attached > ;; to client windows). See dispatch-event for details about how > ;; the bindings are invoked. I suggest allowing multiple procedures to be bound to one event (or both 'pass and a procedure, to allow convenient implementation of a passively observing macro recorder facility or something like that). Proposed interface: (event-map-add-binding! EVENT-MAP EVENT-SPEC PROC-OR-PASS) ;; As `add-event-binding' above, but returns a "binding handle" which ;; uniquely identifies this specific binding in the map. Another suggestion: add an optional ARGS-DESIRED argument which may be one of #f, 'window, 'event or 'full. This only applies if PROC-OR-PASS is a procedure. If #f, the proc is passed no arguments; if 'window, it is passed the window object (or 'root-window) that the event is relevant to; if 'event, it is passed the event object; if 'full, it is passed the window object, the event object, and the window id in that order. This will make life a lot easier even though all the others can be simulated by higher layers if only 'full is provided. (event-map-remove-binding! EVENT-MAP EVENT-SPEC-OR-HANDLE) ;; As `remove-event-binding-above', but either a binding handle or an ;; event-spec may be passed (if a handle is passed, that exact binding ;; is removed; if an event-spec, all bindings for events with an event-spec ;; `equal?' to the one passed. > (list-event-bindings EVENT-MAP) > ;; return a list of all the event bindings added to EVENT-MAP > ;; as a cons parent of (EVENT-OBJECT . PROC-OR-SYMOBL) Suggest renaming this to event-map-bindings. Implementation notes: obviously, scwm should ask the server to not send it events it is not interested in. > 3 - Dispatch of Events > ---------------------- > > (dispatch-event EVENT-MAP EVENT) > ;; EVENT-MAP is an event-map object, EVENT is an event-object > ;; All applicable events' procedures should be invoked in the order that > ;; they were added to the EVENT-MAP. Parent EVENT-MAPs are handled > ;; as discussed above. I'm not convinced that specifying the order this way is a good idea; it may have negative performance implications. Then again, it may not. > ;; Each procedure is invoked with four arguments: > ;; #1 - the scheme object that the event acted on/in (e.g., for a button > ;; decoration, it will be that top-level frame; for a menu it will be > ;; the menu object, etc.), or #f if there is no applicable scheme object > ;; (e.g., the root window) > ;; #2 - the event object that caused this dispatch (i.e. EVENT) > ;; #3 - the window id of the X window that got the event. We can add > ;; primitives to query what decoration/menu/whatever a window ID is > ;; #4 - the time of that event, as reported by the X server > ;; #5 - a list of event-specific information or #f; e.g., > ;; a property-notify event may use > ;; '("WM_TITLE" 'NewValue) > ;; property name changed and either 'NewValue or 'Delete > ;; for this argument > ;; #6 - the event map object (i.e. EVENT-MAP) See my suggestion above for allowing procedures to have fewer arguments passed through an extra argument at binding time. I suggest removing 5 and 6 above entirely; 5 is redundant with the even object because event-field can be used to get that information, and 6 just seems insufficiently useful; if you really care what event map you got invoked from, make an appropriate closure. The time, if considered useful, could be added to full, however, IMO the time is logically part of the event object and should be a field thereof. In fact, not all events even have time. So 4 is unnecessary as well. > ;; > ;; We may need to do something to help simplify binding simple > ;; procedures to an event (maybe something like Emacs's (interactive) > ;; declaration), but I think we need all of the above (and maybe more) > ;; to get a lot of useful functionality. > ;; Only when no bindings are applicable in the child or its chain of > ;; parents should the event dispatching mechanism > ;; proceed to chain the event dispatch up to the enclosing event-map > ;; context. That is, from decoration->frame->global (button decorations > ;; perhaps should forward to the titlebar before the frame, but side-bar > ;; decorations probably should not). > ;; This primitive is what will get internally invoked when Scwm gets > ;; an event. Note that Scwm will have to manage selecting the > ;; appropriate events and grabbing the appropriate keys based on > ;; the event-map objects attached to various windows. > ;; Note that my proposed automatic chaining is a restriction (for > ;; programming understanding and reasoning purposes) on a more general > ;; notion of a procedure to be called when no event binding matches -- > ;; the chaining could be made more explicit and put under programmer > ;; control using this primitive. > > (Thanks to Robert Bihlmeyer who made useful comments regarding this > subsection.) > 4 - Binding of Event Maps: > -------------------------- > > Event maps can be attached to any X Window by its X Id. We can add > primitives that give the window id from a SCWM top-level window and a > decoration specifier. > > (attach-event-map X-WINDOW-ID EVENT-MAP) > e.g., > (attach-event-map (button-n-of 1 win) button-1-map-for-win) > (attach-event-map (title-bar-of win) title-bar-map-for-win) > ;; Only one event map is attached per window id -- attaching > ;; a new map removes any old one > > The window style mechanism should be used to attach a set > of event maps at startup for a given window style, e.g.: > > (window-style "*" #:event-maps (list (1 . default-button-1-map) > ('title . default-title-map) > ('window . default-window-map))) How event maps are to be integrated with styles is an issue that can be punted for now. However, I'd like to be more specific on naming window parts. I suggest the following interface: (window-part-id WINDOW PART-NAME) PART-NAME is a symbol that is one of the following: 'frame (the top-level frame window) 'title 'side-north 'side-east 'side-south 'side-west 'corner-ne 'corner-nw 'corner-se 'corner-sw '(button-right ) where is an integer '(button-left ) where is an integer ;; the arbitrary limit on number of buttons should be removed; they ;; should be dynamically created on demand. 'icon-title 'icon-image 'window ;; the actual application window Actually, some parts may consist of more than one window. For example, 'side and 'corner are each four windows which we almost always bind together. Thus, I suggest that attach-event-map should accept a list of X window ids in place of a single ID to make this more convenient. (alias-window-part WINDOW ALIAS-NAME ORIGINAL-NAME) For WINDOW, allow ALIAS-NAME to be treated the same as ORIGINAL-NAME for the purpose of window-part-id. ORIGINAL-NAME may be a part name or a list of part names. WINDOW may also be #t to indicate a global alias. The following global aliases are pre-defined: 'side => '(side-east side-west side-north side-south) 'corner => '(corner-ne corner-nw corner-se corner-sw) The following should be defined conventionally to ease look-independent binding of buttons: 'system-button 'maximize-button 'minimize-button 'close-button Other conventinal button names could be established as well. If it is considered desirable to give these aliases an initial value, I'd suggest '(button-left 1), '(button-right 1), '(button-right 2) and '(button-left 2) respectively. > [this avoids a bunch of attach-event-maps from being needed in the > new-window-hook -- the attaching of the default event maps needs to be > efficient, since it'll happen for each new window and on lots of > decorations -- it's only a single XSaveContext call for each attachment, > which should be fine]. > (event-map-for X-WINDOW-ID) > ;; Return the currently attach event-map object, if any, or #f Suggest renaming this to something like get-event-map, window-id-event-map, or something. IMO prepositions in procedure names should be used very sparingly. > (remove-event-map X-WINDOW-ID) > ;; detach any event map from X-WINDOW-ID > OTHER ISSUES: > > Enabling/disabling event maps on a per-attachment basis? > > Top-level global event map that's used first before any others? I suggest adding: (install-override-event-map EVENT-MAP) Install EVENT-MAP as the event map to use for everything. Bindings in EVENT-MAP override any other bindings that may have otherwise taken effect for the event, unless the binding is 'pass, in which case they are passed to the normal event map they would have been handled by (or the app window). Motivation: this would allow implementing features like "bookmarks" as suggested by Carl Witty, multi-event bindings, scwm-read-char and scwm-read-line, interactive-move and -resize in Scheme (at least the opaque version), and so on. For the more complex of these, we will definitely need something like the minibuffer in Emacs; I suggest reusing the floating coordinate window for this purpose, and letting the user optionally set it's contants and show and hide it explicitly. (current-override-event-map) Return the currently installed override event map or #f if none. (uninstall-override-event-map) Remove the current override event map, if any. > I'll try to come up with an example of using this system but please feel > free to poke holes in it or query me about how one might accomplish > something you're interested in being able to do. (Or if you think it's > redundant, overly-general, inefficient, etc.). > I think my suggestions make this interface more general, less redundant, and easier to understand. I will try to come up w/ proposals for higher-level binding functionality to be implemented on top of this interface sometime soon; I believe something as easy to use and understand as bind-key and bind-mouse, but providing greater generality, could easily be implemented. I'd like comments from Greg and anyone else on my suggested changes, especially suggestions on what to do about areas that I left wide open, like the syntax for event and event-spec fields. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 14 04:23:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA17838 for scwm-discuss-outgoing; Mon, 14 Sep 1998 04:23:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA17835 for ; Mon, 14 Sep 1998 04:23:25 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA07839; Mon, 14 Sep 98 04:22:43 EDT Received: (qmail 12540 invoked by uid 501); 14 Sep 1998 08:22:45 -0000 Message-Id: <19980914012244.A12507@molehill.org> Date: Mon, 14 Sep 1998 01:22:44 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: X programming help References: <19980913235817.A5618@ZengHe.issy.cnet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Sun, Sep 13, 1998 at 07:29:45PM -0700 X-Tom-Swifty: "A fault!" Martina cried reservedly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've done X application programming before using XView, but never with Xlib directly, so I'm trying to learn it at the same time I'm learning guile/scwm internals. I hope nobody minds a few probably silly questions as I learn. I've changed drawmenu.c:PaintSideImage() as follows: static void PaintSideImage(Window w, Pixel bg, int cpixHeight, scwm_image *psimg) { int y_off; if (!psimg) { scwm_msg(ERR,__FUNCTION__,"psimg is NULL"); return; } SetGCFg(Scr.ScratchGC1,bg); XFillRectangle(dpy, w, Scr.ScratchGC1, MENU_ITEM_RR_SPACE, MENU_ITEM_RR_SPACE, psimg->width, cpixHeight - 2*MENU_ITEM_RR_SPACE); y_off = cpixHeight - MENU_ITEM_RR_SPACE - psimg->height; if (y_off < MENU_ITEM_RR_SPACE) { SCM newimage = ImageMaskTop(psimg, cpixHeight - 2*MENU_ITEM_RR_SPACE); psimg = IMAGE(newimage); y_off = MENU_ITEM_RR_SPACE; } DrawImage(w,psimg,MENU_ITEM_RR_SPACE,y_off,NULL); } to draw the side image at the bottom of the menu rather than the top. To look right, this needs to clip the TOP of the image, enough to leave MENU_ITEM_RR_SPACE at the bottom. ImageMaskTop() is my attempt to do this, as follows: SCM ImageMaskTop(scwm_image * psimg, int new_height) { scwm_image * ci; SCM result; int off_y; GC gc = Scr.ScratchGC1; off_y = psimg->height - new_height; if (off_y < 0) { return SCM_UNSPECIFIED; /* XXX how to signal an error? */ } result = make_empty_image(gh_str02scm("clippedXXX")); ci = IMAGE(result); ci->image = XCreatePixmap(dpy, Scr.Root, psimg->width, new_height, DefaultDepthOfScreen(DefaultScreenOfDisplay(dpy))); ci->mask = XCreatePixmap(dpy, Scr.Root, psimg->width, new_height, DefaultDepthOfScreen(DefaultScreenOfDisplay(dpy))); ci->height = new_height; ci->width = psimg->width; ci->depth = psimg->depth; /* XXX docs say the following GC items are used; do they need to be set? function, plane-mask, subwindow mode, graphics-exposures; */ Globalgcv.clip_mask = None; Globalgcv.clip_x_origin = Globalgcv.clip_y_origin = 0; XChangeGC(dpy, gc, (GCClipMask | GCClipXOrigin | GCClipYOrigin), &Globalgcv); XCopyArea(dpy, psimg->image, ci->image, gc, 0, off_y, psimg->width, new_height, 0, 0); XCopyArea(dpy, psimg->mask, ci->mask, gc, 0, off_y, psimg->width, new_height, 0, 0); return result; } This all seems to be working, but I'm getting the following X errors: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 62 (X_CopyArea) Serial number of failed request: 18325 Current serial number in output stream: 18328 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 56 (X_ChangeGC) Serial number of failed request: 18326 Current serial number in output stream: 18328 My X docs say XCopyArea can generate BadMatch if the drawables don't share the same root or depth; I don't see how either of these can be different. The failing X_ChangeGC has a higher serial number than the X_CopyArea, so I think my changes must be causing a *later* X_ChangeGC to fail. My docs don't say what a BadMatch error for XChangeGC() means, but I'd assume the same thing. Once I get this straightened out, I'd like to rewrite this as a generic image-clip! primitive, if there isn't something like this already that I've missed. Obviously this isn't general enough to want to check in. Thanks in advance! From owner-scwm-discuss@mit.edu Mon Sep 14 06:09:41 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA18295 for scwm-discuss-outgoing; Mon, 14 Sep 1998 06:09:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA18292 for ; Mon, 14 Sep 1998 06:09:37 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13731; Mon, 14 Sep 98 06:09:03 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA03857; Mon, 14 Sep 1998 10:44:25 +0200 To: scwm-discuss@mit.edu Subject: And now for something completely different - CLOS event bindings! Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 14 Sep 1998 10:44:25 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 13 Sep 1998 23:17:01 EDT" Message-Id: Lines: 47 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I had an idea for handling event maps a long time ago when I was getting headaches trying to make STk do what I wanted it to do. The problem was all of these weird implicit bindings & rules for how they interacted which STk inherited from Tk. Not that I'm proposing that this be done with scwm, but I thought that the developers might find it useful to consider this orthogonal way of dealing with event bindings - they might find certain components convenient, or might gain inspiration for certain aspects of the event map proposal. My idea was to use the underlying object layer to define event bindings. Basically, binding can be implemented as a generic CLOS function of 2 arguments - the event and the window. Binding actions would be a matter of writing something like: (define-method (event-action (w ) (e )) (Code for what to do ...)) Whenever an event occurs, event-action is called with the window & the event as arguments. The generic dispatch mechanism of CLOS will automatically execute the most closely matching defined method. I believe that in CLOS specific instances can serve as the types in a define-method call, so this allows binding of actions for specific events to specific existing windows. Because of (before-method), (next-method) & (after-method), this allows for conveniently adding extra behaviors which occur at appropriate times, rather than just overriding behaviors. Of course, this assumes that windows and events both have type hierarchies. I thought it was a cool idea at the time, but never got around to trying anything with it. I started thinking that event maps analogous to those existing in emacs might be clearer than such a structure. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Sep 14 06:59:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA18543 for scwm-discuss-outgoing; Mon, 14 Sep 1998 06:59:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA18540 for ; Mon, 14 Sep 1998 06:59:02 -0400 Received: from smtp7.nwnexus.com by MIT.EDU with SMTP id AA16815; Mon, 14 Sep 98 06:58:29 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp7.nwnexus.com (8.8.8/8.8.8) with ESMTP id DAA14854 for ; Mon, 14 Sep 1998 03:58:31 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-15944>; Mon, 14 Sep 1998 03:57:49 -0700 To: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? In-Reply-To: Greg Badros' message of "13 Sep 1998 18:58:38 PDT." Date: Mon, 14 Sep 1998 03:57:35 -0600 From: Ken Pizzini Message-Id: <19980914105749Z276516-15944+171@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In , Greg Badros wrote: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > toggle-maximize also toggles position. For example: [snip] > > Step 4 brings it back to the original size again, but it also moves it > > back to the original position. I'm not sure if this is intended or > > not, but it's been around for a long time & I'm certainly not a fan of > > the behavior. I don't think fvwm has the same behavior. > toggle-maximize isn't written the way I'd like it either, but I think > the primitives exist to do a more complete job with the better > behaviours you're looking for. Perhaps you could write a new version > that acts as you'd like it (and point out bugs in primitives as you > encounter them, or request other C-level support that you might need). This discussion made me think about a gripe I have with maximize and doing something about it. I don't like the way that maximize currently always pushes to the zero-coordinate on whatever non-zero maximize axis is used. I prefer that the upper-left corner stay as near as possible to its initial position, with the constraint that the resized window should not go off the edge of the screen (unless it is too big to fit). Attached is a diff with my changes, both for my gripe and for Harvey's. --Ken Pizzini (relative to the 0.8a release) --- winops.scm-orig Sat Aug 29 19:55:59 1998 +++ winops.scm Mon Sep 14 03:55:20 1998 @@ -81,20 +81,35 @@ (if (not (maximized? w)) (set-object-property! w 'maximized (list x y width height))) - (move-to (if (> nw 0) 0 x) - (if (> nh 0) 0 y) w) (resize-frame-to (if (> nw 0) nw width) - (if (> nh 0) nh height) w)))) + (if (> nh 0) nh height) w) + (let* ( + ;; the resize-frame-to was just a hint; get the actual... + (new-size (window-frame-size w)) + (nw (car new-size)) + (nh (cadr new-size)) + (screen-size (display-size)) + (sw (car screen-size)) + (sh (cadr screen-size))) + (move-to (if (> sw (+ x nw)) x (if (> sw nw) (- sw nw) 0)) + (if (> sh (+ y nh)) y (if (> sh nh) (- sh nh) 0)) w))))) (define*-public (maximized? #&optional (w (get-window))) (->bool (object-property w 'maximized))) -(define*-public (unmaximize #&optional (w (get-window))) +(define*-public (unmaximize-to-original-position #&optional (w (get-window))) (if w (let ((max-prop (object-property w 'maximized))) (cond (max-prop (move-to (car max-prop) (cadr max-prop) w) (resize-frame-to (caddr max-prop) + (cadddr max-prop) w) + (set-object-property! w 'maximized #f)))))) + +(define*-public (unmaximize #&optional (w (get-window))) + (if w (let ((max-prop (object-property w 'maximized))) + (cond + (max-prop (resize-frame-to (caddr max-prop) (cadddr max-prop) w) (set-object-property! w 'maximized #f)))))) From owner-scwm-discuss@mit.edu Mon Sep 14 09:07:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA19079 for scwm-discuss-outgoing; Mon, 14 Sep 1998 09:07:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA19076 for ; Mon, 14 Sep 1998 09:07:54 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05252; Mon, 14 Sep 98 09:07:17 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id QAA03724 for ; Mon, 14 Sep 1998 16:07:02 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id PAA07358; Mon, 14 Sep 1998 15:07:02 +0200 To: scwm-discuss@mit.edu Subject: Re: maximization and minimization bugs - good example References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 14 Sep 1998 15:07:02 +0200 In-Reply-To: Greg Badros's message of "13 Sep 1998 19:00:16 -0700" Message-Id: Lines: 20 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > I've created a [reasonably small] .scwmrc to expose the two bugs I > > reported recently: bad xterm's maximization and bad netscape's > > minimization. Again, the scwm release is > > Lots of changes in this code.... hopefully fixing these and numerous > other bugs.... let me know if they're still there. > In the new snapshot (Sun Sep 13 22:29:53 EDT 1998 -- $Revision: 1.422 $) the maximization bug is not present anymore, but the minimization (iconification) one still is - icon for Netscape still disappears... -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Mon Sep 14 12:10:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA19988 for scwm-discuss-outgoing; Mon, 14 Sep 1998 12:10:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA19985 for ; Mon, 14 Sep 1998 12:10:20 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA09712; Mon, 14 Sep 98 12:09:44 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07245; Mon, 14 Sep 1998 09:09:41 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: X programming help References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980914012244.A12507@molehill.org> From: Greg Badros Date: 14 Sep 1998 09:09:35 -0700 In-Reply-To: Todd Larason's message of "Mon, 14 Sep 1998 01:22:44 -0700" Message-Id: Lines: 72 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I've done X application programming before using XView, but never with > Xlib directly, so I'm trying to learn it at the same time I'm learning > guile/scwm internals. I hope nobody minds a few probably silly > questions as I learn. No question is silly if you don't know the answer. > I've changed drawmenu.c:PaintSideImage() as follows: > > > to draw the side image at the bottom of the menu rather than the top. > To look right, this needs to clip the TOP of the image, enough to leave > MENU_ITEM_RR_SPACE at the bottom. ImageMaskTop() is my attempt to do > this, as follows: Meta level comments: just changing the code to have the behaviour you want is a good way to prototype changes and learn how to implement a feature. For a final implementation of this idea, though, we'd need to be able to specify the justification of the image, not just hard code it as a single one of the (at least 3) options. > SCM > ImageMaskTop(scwm_image * psimg, int new_height) > { > ci->image = XCreatePixmap(dpy, Scr.Root, psimg->width, new_height, > DefaultDepthOfScreen(DefaultScreenOfDisplay(dpy))); > ci->mask = XCreatePixmap(dpy, Scr.Root, psimg->width, new_height, > DefaultDepthOfScreen(DefaultScreenOfDisplay(dpy))); I always assummed that clip masks were bitmaps, not pixmaps (i.e., 1 bit depth). I've not done much low level Xlib programming in a while, though. I'm pretty sure this doesn't have to be as complicated as clipping images and all that. See PaintSidePic in menus.c of fvwm2.0.47[cd] -- if I remember correctly fvwm2 justified the side image to the bottom. > } > > My X docs say XCopyArea can generate BadMatch if the drawables don't > share the same root or depth; I don't see how either of these can be > different. > > The failing X_ChangeGC has a higher serial number than the X_CopyArea, > so I think my changes must be causing a *later* X_ChangeGC to fail. > My docs don't say what a BadMatch error for XChangeGC() means, but I'd > assume the same thing. Not sure, really. The shared uses of Scr.ScratchGC* is pretty ugly, though, so it seems possible. > Once I get this straightened out, I'd like to rewrite this as a generic > image-clip! primitive, if there isn't something like this already that > I've missed. Obviously this isn't general enough to want to check in. Meta-level comments: we probably don't want to do this level of Xlib programming ourselves. We should focus our energies instead on gaining access to Gtk/Gdk and letting their hard work pay off for us as well. Clipping images is something that a window manager may want to be able to do, but needn't be the provider of such functionality. I'd love to see justification added as an option for the side images of menus -- 'top, 'middle, 'bottom perhaps. This'd be a great feature to add. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 12:32:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA20276 for scwm-discuss-outgoing; Mon, 14 Sep 1998 12:32:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA20273 for ; Mon, 14 Sep 1998 12:32:02 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA10706; Mon, 14 Sep 98 12:31:08 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07253; Mon, 14 Sep 1998 09:31:11 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: And now for something completely different - CLOS event bindings! References: From: Greg Badros Date: 14 Sep 1998 09:31:05 -0700 In-Reply-To: hjstein@bfr.co.il's message of "14 Sep 1998 10:44:25 +0200" Message-Id: Lines: 68 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I had an idea for handling event maps a long time ago when I was > getting headaches trying to make STk do what I wanted it to do. The > problem was all of these weird implicit bindings & rules for how they > interacted which STk inherited from Tk. > > Not that I'm proposing that this be done with scwm, but I thought that > the developers might find it useful to consider this orthogonal way of > dealing with event bindings - they might find certain components > convenient, or might gain inspiration for certain aspects of the event > map proposal. > > My idea was to use the underlying object layer to define event > bindings. > > Basically, binding can be implemented as a generic CLOS function of 2 > arguments - the event and the window. I've thought about this a bit, too. CLOS's method combination is especially nice for dealing with augmented actions, etc. But I'm not convinced that CLOS's linearization is a good thing (I'm partial as I've had a lot of contact with the Cecil group here at the UW: http://www.cs.washington.edu/research/projects/cecil/www/ and they've got a better dispatch algorithm). The problem with this for scwm is we need to do XGrabKey-s on various windows and it's a bit harder to introspect on dispatch tables to figure out which keys to grab on which windows. > Binding actions would be a matter of writing something like: > > (define-method (event-action (w ) > (e )) > (Code for what to do ...)) > > Whenever an event occurs, event-action is called with the window & the > event as arguments. The generic dispatch mechanism of CLOS will > automatically execute the most closely matching defined method. > > I believe that in CLOS specific instances can serve as the types in a > define-method call, so this allows binding of actions for specific > events to specific existing windows. > > Because of (before-method), (next-method) & (after-method), this > allows for conveniently adding extra behaviors which occur at > appropriate times, rather than just overriding behaviors. Yep. > > Of course, this assumes that windows and events both have type > hierarchies. This is a practical issue, too, but generally seems manageable. > I thought it was a cool idea at the time, but never got around to > trying anything with it. I started thinking that event maps analogous > to those existing in emacs might be clearer than such a structure. I think for program understanding purposes, multimethod dispatch complicates reasoning. It's overkill for our needs, but definitely interesting to ponder. Greg From owner-scwm-discuss@mit.edu Mon Sep 14 13:02:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20665 for scwm-discuss-outgoing; Mon, 14 Sep 1998 13:02:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20661 for ; Mon, 14 Sep 1998 13:02:44 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28272; Mon, 14 Sep 98 13:02:09 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA07295; Mon, 14 Sep 1998 10:02:01 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <19980914105749Z276516-15944+171@pulsar.halcyon.com> From: Greg Badros Date: 14 Sep 1998 10:01:59 -0700 In-Reply-To: Ken Pizzini's message of "Mon, 14 Sep 1998 03:57:35 -0600" Message-Id: Lines: 40 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > In , > Greg Badros wrote: > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > > > toggle-maximize also toggles position. For example: > [snip] > > > Step 4 brings it back to the original size again, but it also moves it > > > back to the original position. I'm not sure if this is intended or > > > not, but it's been around for a long time & I'm certainly not a fan of > > > the behavior. I don't think fvwm has the same behavior. > > toggle-maximize isn't written the way I'd like it either, but I think > > the primitives exist to do a more complete job with the better > > behaviours you're looking for. Perhaps you could write a new version > > that acts as you'd like it (and point out bugs in primitives as you > > encounter them, or request other C-level support that you might need). > > This discussion made me think about a gripe I have with maximize > and doing something about it. I don't like the way that maximize > currently always pushes to the zero-coordinate on whatever non-zero > maximize axis is used. I prefer that the upper-left corner stay as > near as possible to its initial position, with the constraint that > the resized window should not go off the edge of the screen (unless > it is too big to fit). Attached is a diff with my changes, both > for my gripe and for Harvey's. I just integrated your patch into winops.scm, except renaming your unmaximize to unmaximize-no-move, and leaving the old unmaximize unchanged. Please try it out and make sure I got the changes the way you wanted them. I still think this is not perfect... maximizing and unmaximizing should undo each other-- that's why I left the old unmaximize function in place. Also, please note that patches are *way* more useful if they're relative to the very latest snapshot. It's amazing how much stuff has changed since 0.8a! Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 13:23:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20856 for scwm-discuss-outgoing; Mon, 14 Sep 1998 13:23:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20851; Mon, 14 Sep 1998 13:23:06 -0400 Message-Id: <199809141723.NAA20851@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? In-reply-to: Your message of "14 Sep 1998 10:01:59 PDT." Date: Mon, 14 Sep 1998 13:23:05 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Ken Pizzini writes: > > > This discussion made me think about a gripe I have with maximize > > and doing something about it. I don't like the way that maximize > > currently always pushes to the zero-coordinate on whatever non-zero > > maximize axis is used. I prefer that the upper-left corner stay as > > near as possible to its initial position, with the constraint that > > the resized window should not go off the edge of the screen (unless > > it is too big to fit). Attached is a diff with my changes, both > > for my gripe and for Harvey's. > > I just integrated your patch into winops.scm, except renaming your > unmaximize to unmaximize-no-move, and leaving the old unmaximize > unchanged. Please try it out and make sure I got the changes the way you > wanted them. I still think this is not perfect... maximizing and > unmaximizing should undo each other-- that's why I left the old > unmaximize function in place. > > Also, please note that patches are *way* more useful if they're relative > to the very latest snapshot. It's amazing how much stuff has changed > since 0.8a! > The interaction between maximize and moving the window is indeed a vexing issue and becomes even more annoying in the presence of window shading. Ignoring window shading for the time being, I think the correct semantics (in the sense of coming closest to always doing what you'd expect) are this: * If you maximize a window and then unmaximize it without moving it in between, it should return to it's position before maxsimizing. * If you maximize the window and then move it, unmaximizing it should leave the position alone. Another thing to consider is what should happen if you explicitly resize a maximized window. I think the right thing to do here is to make it lose the maximized property and leave the size andc position as explicitly set by the user. The problem is that right now we have no easy way to trap changes in window geometry, so it's not possible to tell if the window is moved or resized. IMO a geometry-change-hook (or both position-change-hook and size-change-hook) would allow this and other problems to be solved effectively. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 14 13:36:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA20974 for scwm-discuss-outgoing; Mon, 14 Sep 1998 13:36:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA20970 for ; Mon, 14 Sep 1998 13:36:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA10308; Mon, 14 Sep 98 13:35:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA07334; Mon, 14 Sep 1998 10:35:56 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <199809141723.NAA20851@huis-clos.mit.edu> From: Greg Badros Date: 14 Sep 1998 10:35:54 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 14 Sep 1998 13:23:05 EDT" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > The interaction between maximize and moving the window is indeed a > vexing issue and becomes even more annoying in the presence of window > shading. Ignoring window shading for the time being, I think the > correct semantics (in the sense of coming closest to always doing what > you'd expect) are this: > > * If you maximize a window and then unmaximize it without moving it in > between, it should return to it's position before maxsimizing. > > * If you maximize the window and then move it, unmaximizing it should > leave the position alone. > > Another thing to consider is what should happen if you explicitly > resize a maximized window. I think the right thing to do here is to > make it lose the maximized property and leave the size andc position > as explicitly set by the user. > > > The problem is that right now we have no easy way to trap changes in > window geometry, so it's not possible to tell if the window is moved > or resized. IMO a geometry-change-hook (or both position-change-hook > and size-change-hook) would allow this and other problems to be solved effectively. These fit into the event model -- catching configure notify events. I'm concerned about the expense of running scheme code during interactive moves and resizes, though. We have to be careful about choosing when to call scheme code, as there could be lots and lots of resize/move events when the user drags the window. Greg From owner-scwm-discuss@mit.edu Mon Sep 14 13:45:46 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA21196 for scwm-discuss-outgoing; Mon, 14 Sep 1998 13:45:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA21191 for ; Mon, 14 Sep 1998 13:45:44 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA13450; Mon, 14 Sep 98 13:45:08 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA07344; Mon, 14 Sep 1998 10:44:28 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: maximization and minimization bugs - good example References: From: Greg Badros Date: 14 Sep 1998 10:44:28 -0700 In-Reply-To: abel@bfr.co.il's message of "14 Sep 1998 15:07:02 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Greg Badros writes: > > > abel@bfr.co.il (Alexander L. Belikoff) writes: > > > > > I've created a [reasonably small] .scwmrc to expose the two bugs I > > > reported recently: bad xterm's maximization and bad netscape's > > > minimization. Again, the scwm release is > > > > Lots of changes in this code.... hopefully fixing these and numerous > > other bugs.... let me know if they're still there. > > > > In the new snapshot (Sun Sep 13 22:29:53 EDT 1998 -- $Revision: 1.422 > $) the maximization bug is not present anymore, but the minimization > (iconification) one still is - icon for Netscape still disappears... I fixed this for me, now. The netscape icon, when sticky, was going off the right edge of the viewport. Let me know if you still see this problem, or if you can track it down to some other difficulty. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 15:31:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA22038 for scwm-discuss-outgoing; Mon, 14 Sep 1998 15:31:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA22033; Mon, 14 Sep 1998 15:31:31 -0400 Message-Id: <199809141931.PAA22033@huis-clos.mit.edu> To: Mishka Gorodnitzky cc: scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-reply-to: Your message of "Fri, 11 Sep 1998 17:41:34 EDT." <13817.39182.141401.444937@tor-dev1.nbc.netcom.ca> Date: Mon, 14 Sep 1998 15:31:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk misaka@netcom.ca writes: > > I'm wondering if there is currently a pager available for > scwm. Currently, you can only use the fvwm2 pager. However, a native pager is planned. As soon as I can get the guile-gtk support to work well, I'd like to write a guile-gtk pager as one of the demos for the guile-gtk stuff. In the mean time, the fvwm2 pager is your best bet, so let's see if I can help with your problem. > I've noticed that there appears to be support for the fvwm pager > module, but yet here's what happens when I try to get it working: > > | scwm> (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmP > ager" '("0" "2"))) > | > | 0* (define fvwm2-pager (run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPage > r" (quote #))) > | 1* [define (define fvwm2-pager (#@run-fvwm2-module "/usr/X11R6/lib/X11/fvwm > 2/FvwmPager" #)) (#)] > | 2* [run-fvwm2-module "/usr/X11R6/lib/X11/fvwm2/FvwmPager"] > | 3 (let* ((other-args #) (config-file #) (config-info #)) (let-keywords* %% > gensym58 () ...)) > | 4* (cond ((not #) (let # # ...)) (#t (get-fvwm2-module-config #))) > | 5 [get-fvwm2-module-config ... > | 6* (basename module-name) > | > | ERROR: In expression (basename module-name): > | ERROR: Unbound variable: basename > > Presumably because basename isn't defined anywhere. Is this something > that should be available via the guile libs? Or am I doing something > wrong here? I do have the suggested code snippet from fvwm-module.scm > run before this code in my scwmrc ... if that affects the availability > of (basename ...). > basename should be in the Guile library. Can you tell me what version of Guile you have? I'll look into whether Guile provides basename on all systems, and if not, hack my own. Thanks for the bug report! - Maciej From owner-scwm-discuss@mit.edu Mon Sep 14 15:57:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA22245 for scwm-discuss-outgoing; Mon, 14 Sep 1998 15:57:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA22233; Mon, 14 Sep 1998 15:56:49 -0400 Message-Id: <199809141956.PAA22233@huis-clos.mit.edu> To: "Craig A. Struble" cc: scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-reply-to: Your message of "Fri, 11 Sep 1998 18:04:32 EDT." Date: Mon, 14 Sep 1998 15:56:49 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > I saw this message when using scwm-0.8 with guile-1.2 which doesn't > implement basename. Updating to a guile-1.3 snapshot fixes it and a number > of other strange things you see when using guile-1.2. Ah, there's the problem then. I'm about to commit a fix which defines basename if Guile doesn't provide it. (Given that it's four trivial lines, I don't think there are copyright issues.) - Maciej From owner-scwm-discuss@mit.edu Mon Sep 14 16:10:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA22461 for scwm-discuss-outgoing; Mon, 14 Sep 1998 16:10:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA22458 for ; Mon, 14 Sep 1998 16:10:56 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA05119; Mon, 14 Sep 98 16:09:57 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id QAA12833; Mon, 14 Sep 1998 16:10:22 -0400 (EDT) Message-Id: <199809142010.QAA12833@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: Your message of "Mon, 14 Sep 1998 15:31:30 EDT." <199809141931.PAA22033@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 16:10:22 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > I'm wondering if there is currently a pager available for > > scwm. > > Currently, you can only use the fvwm2 pager. However, a native pager > is planned. As soon as I can get the guile-gtk support to work well, > I'd like to write a guile-gtk pager as one of the demos for the > guile-gtk stuff. In the mean time, the fvwm2 pager is your best bet, > so let's see if I can help with your problem. Given the fact that it is claimed my constant hangs are caused by bugs in the scwm/fvwm-pager communication, I will be happy to see the native pager. :( Perry From owner-scwm-discuss@mit.edu Mon Sep 14 17:21:43 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23017 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:21:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23014 for ; Mon, 14 Sep 1998 17:21:42 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA01570; Mon, 14 Sep 98 17:20:42 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id OAA10731 for ; Mon, 14 Sep 1998 14:21:07 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276554-15944>; Mon, 14 Sep 1998 14:20:05 -0700 To: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? In-Reply-To: Your message of "Mon, 14 Sep 1998 13:23:05 EDT." <199809141723.NAA20851@huis-clos.mit.edu> Date: Mon, 14 Sep 1998 14:19:55 -0600 From: Ken Pizzini Message-Id: <19980914212005Z276554-15944+175@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <199809141723.NAA20851@huis-clos.mit.edu>, Maciej Stachowiak writes: > Ignoring window shading for the time being, I think the > correct semantics (in the sense of coming closest to always doing what > you'd expect) are this: > > * If you maximize a window and then unmaximize it without moving it in > between, it should return to it's position before maxsimizing. > > * If you maximize the window and then move it, unmaximizing it should > leave the position alone. Then perhaps the code below is a better approximation of desired behavior? --Ken Pizzini (define*-public (maximize nw nh #&optional (w (get-window))) (if w (let* ((pos (window-position w)) (size (window-frame-size w)) (x (car pos)) (y (cadr pos)) (width (car size)) (height (cadr size))) (resize-frame-to (if (> nw 0) nw width) (if (> nh 0) nh height) w) (let* ( ;; the resize-frame-to was just a hint; get the actual... (new-size (window-frame-size w)) (nw (car new-size)) (nh (cadr new-size)) (screen-size (display-size)) (sw (car screen-size)) (sh (cadr screen-size)) (nx (cond ((> sw (+ x nw)) x) ((> sw nw) (- sw nw)) (#t 0))) (ny (cond ((> sh (+ y nh)) y) ((> sh nh) (- sh nh)) (#t 0)))) (move-to nx ny w) (if (not (maximized? w)) (set-object-property! w 'maximized (list x y width height nx ny))))))) (define*-public (maximized? #&optional (w (get-window))) (->bool (object-property w 'maximized))) (define*-public (unmaximize #&optional (w (get-window))) (if w (let* ((max-prop (object-property w 'maximized)) (pos (window-position w)) (cur-x (car pos)) (cur-y (cadr pos))) (cond (max-prop (let ((maxed-x (car (cddddr max-prop))) (maxed-y (cadr (cddddr max-prop)))) (if (and (= cur-x maxed-x) (= cur-y maxed-y)) (move-to (car max-prop) (cadr max-prop) w)) (resize-frame-to (caddr max-prop) (cadddr max-prop) w) (set-object-property! w 'maximized #f))))))) From owner-scwm-discuss@mit.edu Mon Sep 14 17:20:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23006 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:20:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23003 for ; Mon, 14 Sep 1998 17:20:36 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03867; Mon, 14 Sep 98 17:19:55 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07754; Mon, 14 Sep 1998 14:19:56 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Comments on the latest version of the event model proposal References: <199809140317.XAA15840@huis-clos.mit.edu> From: Greg Badros Date: 14 Sep 1998 14:19:51 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 13 Sep 1998 23:17:01 EDT" Message-Id: Lines: 872 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > Event Rewrite Proposal for Scwm > > Greg J. Badros, 6-Aug-1998, revised 2-Sep-1998, 3-Sep-1998, 5-Sep-1998 > > (Inspired by conversations w/ Maciej and his "events" proposal in this > > same directory) > > > > Intro: > > ------ > > > > Motivating desires for a more flexible event-binding infrastructure > > > > o Elimination of "contexts" and replacing with event maps > > -- event maps are more fundamental, and unifying > > o Mode-specific event maps (e.g., when in an interactive move) > > o Pinnable-menus event maps > > o Multi-key bindings with prefix keys that change mode map > > o Maps on a per window basis (e.g., xlogo could permit fewer modifier > > keys to accompany an "m" keystroke to signify a desire to move the > > window) > > o Quoting mechanism for turning off scwm's handling of events > > o Unifying X-events and user events > > I have a few additional motivations which I think should be added to > this list (symbolic though it is): > > o Providing a complete interface that allows people to implement > desired capablities which can not be achieved with the current event > binding infrastructure; this will likely include capablities that we > feel no need to provide a more convenient interface for, but that some > users may desire anyway. > > o Provide a base for implementing a higher-level event binding system > that may be less complete, but is very easy to understand, and at > least superficially similar to the current system. Sure, these are good goals statements. > Where I have them prepared, I will present concrete alternatives to > the current proposal that I believe are more in line with the goals, > as ammended by me. In other places, I will merely throw out ideas in > the hopes that they can Lots of your messages seem to tail off into nothingness like this-- is this a mailer/editor problem? > > As you wrote, event maps and event objects should be exposed to the > > scheme layer as SMOBs (first class objects). The event maps will > > contain event objects which are bound to procedures to be invoked. > > Event maps will be attached to X windows (via Xlib's SaveContext > > mechanism) and scheme window objects (using their top-level frame > > window). E.g., an event map can be attached to a titlebar button > > window, or to the titlebar window, etc. > > Upon further consideration, I think event specifiers should be a > different type of object than events. I say this because event > specifiers may contain some types of data that make no sense in actual > events, and vice versa. > > For instance, a mouse-down event object should include the X and Y > coordiantes where the event occured. However, this makes no sense for > an event specifier. This example actually makes me think the opposite. A rectangular region is definitely something that would be worth filtering on for mouse events. E.g., menus are implemented w/o using separate X windows for the items, and highlighting a menu item occurs when the mouse enters the given region, and selecting occurs on a mouse-down in that region. (These are called gadgets in Motif -- lightweight things that have some of the behaviour of X windows). > Contrariwise, in an event specifier, it may be desirable to include > something representing some sort of filter in a given field, rather > than a concrete value. For instance, it may be desirable to bind a > procedure to be launched on any keypress event, by passing some > magical constant such as #t, #f, or some special symbol in the key > specifier field. But this would make no sense for an event to be > dispatched on. Thus, I will present below a proposal for separate > event and event-specifier types. > > > > I will respond to this section in whole, because I have pervasive > changes to suggest. First of all, I think event specifiers should be > different from event objects, and most of this section deals with > specifiers. I suggest the following changes to the interface for > event-specs: > > ** EVENT-SPECS ** > > -- Creating Event Specs -- > > (make-event-spec EVENT-TYPE #&rest FIELD-SPECS) > > EVENT-TYPE is a symbol identifying the type of X event. It should also > include some events synthesized by scwm itself which are provided for > convenience (mouse-click, mouse-double-click, mouse-single-click, etc). > > It should include at least the following (symbolic names, X11 names > where appropriate, and brief explanations are given): > > 'key-down (KeyPress) > 'key-up (KeyRelease) > 'mouse-down (ButtonPress) > 'mouse-up (ButtonRelease) > 'mouse-drag (MotionNotify with at least one button down) > 'mouse-move (MotionNotify with no mouse buttons down) > 'mouse-click (A ButtonRelease that happens in the same window as a > ButtonPress, but does not consitute the second click > of a double click > 'mouse-double-click (If the conditions for a mouse-click happen within some > given time limit, a mouse-double-click is sent instead > perhaps a movement threshold should also be provided) > 'mouse-single-click (A click followed by enough time to definitively not > constitute a double click. To summarize, when the mouse > is single-clicked, 'mouse-click is sent immediately, > and 'mouse-single-click is sent after the double click > delay time passes. When it is double-clicked, 'mouse-click > is sent immediately after the first click, and > 'mouse-double-click is sent immediately after the second; > 'mouse-single-click is not sent at all. 'mouse-up is sent > on each release of the mouse in both cases. This should > allow the full desired set of single-click semantics.) This is a good summary of the semantics that I think we already have a consensus for. The big change here is folding the creation of the event specifiers into a single primitive, which seems reasonable. I was a bit vague about event objects vs. event specifiers, and the distinction you draw is good. I strongly dislike the gratuitous and potentially confusing renaming of X events. I am fine with scheme-ifying the names, but an X11 KeyPress should be 'key-press, not 'key-down, and MotionNotify should be 'motion-notify w/ the buttons down filter as part of the FIELD-SPECS. > 'enter-notify (EnterNotify) > 'leave-notify (LeaveNotify) > 'focus-in (FocusIn) > 'focus-out (FocusOut) > 'visibility-notify (VisiblityNotify) > > 'property-notify (PropertyNotify) > 'colormap-notify (ColormapNotify - comment: why is this useful?) > 'mapping-notify (MappingNotify) These are much better named. :-) WRT ColormapNotify, it's useful because (I'm quoting you): o Providing a complete interface that allows people to implement desired capablities which can not be achieved with the current event binding infrastructure; this will likely include capablities that we feel no need to provide a more convenient interface for, but that some users may desire anyway. :-) > * Synthetic events that could be added: > > 'mouse-one-and-a-half-click (A mouse click followed by a drag within > the double click timeout - perhaps 'mouse-click-and-drag is a better > name), 'mouse-triple-click (supported by Gtk, but probably not widely > used), and 'mouse-double-click-and-drag (for orthogonality if the > previous two are supported). Alternatively, a convenient way to mix > timers with event maps may allow these (as well as orinary click > events) to be synthesized by higher layers. I think higher layers should deal with this. They are clearly implementable given the other accessible infrastructure. > * X events that should be supported in a different way, because > attaching them to window-based event maps is illogical or inefficient: > > CreateNotify, DestroyNotify > > (in my opinion, these are better handled by special-case hooks. The > former is illogical because it would not be in a window's event map > until _after_ the window is created. The latter we only care about for > top-level windows and probably want to handle specially to avoid race > conditions). I think that the special case hooks can exist for top level scheme windows, but unless implementing these causes undo hardship (which I'm pretty certain they won't), it's worth keeping them for consistency and completeness. In particular, CreateNotify is *not* illogical if selected for on the root window. > * X events ignored for now, though we may want to support them later: > > KeymapNotify, Expose, GraphicsExpose, NoExpose, UnmapNotify, > MapNotify, MapRequest, ReparentNotify, ConfigureNotify, > ConfigureRequest, GravityNotify, ResizeRequest, CirculateNotify, > CirculateRequest, SelectionClear, SelectionRequest, SelectionNotify, > ClientMessage > > ClientMessage may be especially useful to add, for the purpose of > supporting custom protocols. All of these should be potentially handle-able. Hopefully there won't be too much per-event work that needs to be done in the implementation. I.e., we should get most of these for free. There are also some visibility events that are missing from the above that would be potentially useful to exploit. > * Commentary on "global" events: Some events are inherently not > per-window, but global in the scope of the events of which they notify > the application. These include (IMO) mapping-notify and > colormap-notify. It may not be appropriate to handle these events > through the event map mechanism; it may instead be preferrable to > handle them through ??? another disappearing text act. wacky! I'll assume you were going to say "through hooks". I think that the global map can handle these events more elegantly. If the map happens to want to call a hook, that's fine (we need a way to invoke a hook from scheme don't we?). The global map can catch all events where we don't care on what window the event is. > FIELD-SPECS is a list of specifiers for particular fields. The nature > of a field specifier will be described first; then five possible > syntaxes for the field specifiers will be proposed. > > A field specifier is a field used for filtering events according to > particular fields (see the discussion of fields below in the section > on event objects to see which events support what fields). It may be > either an exact field value, which must be matched, the symbol '*, to > indicate that this field should be ignored entirely when matching > events, a procedure which should be a predicate of one argument, or > possibly a special other value which is available for some fields. An > event matches an event specifier if its type is the same, and all of > its fields individually match the event specifier fields. An event > field matches an event specifier field if any of the followind is > true: > > * The value of the event field is identical to the event-spec field > * The event-spec field in question has a value of '* > * The event-spec field is a procedure, and returns a true value when > applied to the event field. I don't like procedures used as filters. It requires us to either analyze the procedure to find out what it'll return #t for, or to just throw up our arms and Select a really general event and then call the procedure exceedingly often on events that we're not interested in. As much of the filtering as possible must be done by X11 (by not Selecting inappropriate events), another bit done by C code (when X doesn't provide the means to filter it directly), and the rest should be done by the called procedure. If that called procedure wants to have a scheme-level filtering procedure, it can, but the C level needn't worry about that (and it'll discourage such things). > * The event-spec field is a special field-specific specifier and > matches according to the relevant rules. > > The only special event-spec field value reccomended by now is the > following for the 'modifiers field in many events: > > A pair of two lists can be accepted for a 'modifiers event-spec field; > the first list is the list of names of modifiers that must be on, and > the second is a list of modifers names that must be off. A modifiernnnnn > not present in either list is ignored entirely. I prefer the list of symbols that can specify either on or off. An earlier draft had a must-be-on and a must-be-off list which was decided inadequate for another reason (it expose bitmasks instead of symbolic modifiers), but in that rewrite I really liked the new version's similarity to X resource modifier configurations. The MODIFIER-SPECIFIER in events.gjb is a bit higher-level -- in particular, the pseudo-specifiers 'exactly and 'with are nice because then you don't have to name all the other modifiers to say "not these". I know that we could provide that functionality in scheme, but it's pretty easy to do in C, too. > The following syntaxes are suggested. For each of them, a field-spec > not provided is assumed to be '*. > > 1) A fixed order of fields dependent on the event type. This may be > less verbose, and perhaps easier to parse, but it may be confusing and > awkward. > > 2) Name-value pairs or two-element lists, which may be provided in any > order. This is clearer than the above This seems fine. > > 3) A set of keyword arguments. This is probably the most clear and > consistent, but may be a bit harder to parse from C. Also, using it > for events as well as event-specs may be a bit silly, since all fields > must be provided to make an event, and keywords generally indicate > optional constructs. Not worth doing this unless it's easy to parse from C (what does the primitive actually get? it might be worth making keyword arguments easier to use from C, but not right now). > 4) A combination of 1 and 2; Some optional aguemnts for each event > type (the most commonly used ones) in a fixed order, followed by > > 5) ???? 5? > -- Examining Event-Specs -- > > (event-spec-type EVENT-SPEC) > > Return the event type of the event specifier EVENT-SPEC. > > > (event-spec-field EVENT-SPEC FIELD-NAME) > > Return the value of the field named by the symbol FIELD-NAME in EVENT-SPEC. > > > Motivation: > > There are several changes in this version as compared to the previous > version. Here is the motivation for them: > > o Single make-event-spec procedure vs. several specialized ones: Much > functionality is common; IMO at this level of interface, we should > keep things simple and leave greater convenience to the higher-level > interfaces. I'm not opposed to a single make-event-spec, but it seems like the various specialized once are exposing specializations which will occur in the implementation anyway, and are natural distinctions. There is often benefit in generalizing and unifying naturally distinct things. Here, though, your one-procedure is complicated by the need to parse different kinds of FIELD-SPECS for the different kinds of events based on the first argument: EVENT-TYPE. I'd rather fold that first argument into the primitive name since the code will be different based on that value, anyway (i.e., let the program do the "switch" that's gonna be inside the primitive anyway). > o Making event filtering simple and uniform: IMO, this is the right > thing for the low-level interface. We can pick convenient subsets of > the functionality w/ convenient interfaces for the higher-level > version. The whole decision about the user's intentions when trying to > bind key events, for instance, can be punted to a higher level. I agree, but I'm not convinced that the single primitive is simpler in any useful way relative to the three primitives in the earlier draft. You just move the complexity into the processing of the FIELD-SPECS of the one primitive. > ** EVENTS ** > > Events will be treated similarly to event specifiers except that, of > course, they have different usages and different sets of restrictions > on their fields. > > -- Creating Event Objetcs -- > > (make-event EVENT-TYPE #&rest FIELDS) > > The EVENT-TYPE field is any of the event types supported by > > The syntax for the FIELDS arguments should be similar to that for the > FIELD-SPECS argument of make-event-spec, but all applicable fields are > mandatory. Here is a list of the possible fields and their Scheme > types: > > > 'synthetic (boolean) > 'window (integer - X window ID) > 'root (integer - X window ID) > 'subwindow (integer - X window ID) > 'time (whatever type is appropriate for times in Scheme) > 'x (integer) > 'y (integer) > 'x-root (integer) > 'y-root (integer) > 'property (either a string or an integer representing an X atom; > which is better?) > 'state (symbol; valid values depend on the event type. For > 'property-notify : 'deleted or 'new-value ; For > 'visibility-notify : 'unobscured, 'partially-obscured or > 'fully-obscured ; ) > 'request (symbol - one of 'modifier, 'keyboard or 'pointer) > 'modifiers (list of symbols, each one of > 'control 'shift 'meta 'super 'alt 'hyper 'numlock 'capslock > 'mod[1-5] symbolic names will be given in preference to > mod[1-5] names whenever possible.) > 'buttons (list of the numbers 1-5) ;; maybe this should be ditched? > 'button (an integer 1-5) > 'key a string naming the key (we'll have to turn a keycode into > a keysym and that in turn into a symbolic name - that will > sure be fun) > > [Note to greg: X11 only supports mod1-5 AFAIK, so 6-8 are pointless] Yep... I was thinking/hoping that the 8 bits corresponded to Mod1-5, but Mod 1 is the 4th bit (bit 3, when numbered from 0). > > Here is a list of which events have which fields: > > All events: 'synthetic 'window > All mouse and key events: 'root 'subwindow 'x 'y 'x-root 'time 'modifiers > 'buttons 'subwindow might need to be subwindow-id (a number) -- we don't want to wrap subwindows, I'd think. > Event: Extra fields supported: > > 'key-down (mouse/key fields) 'key > 'key-up (mouse/key fields) 'key > 'mouse-down (mouse/key fields) 'button > 'mouse-up (mouse/key fields) 'button > 'mouse-drag (mouse/key fields) 'button > 'mouse-move (mouse/key fields) 'button > 'mouse-click (mouse/key fields) 'button > 'mouse-double-click (mouse/key fields) 'button > 'mouse-single-click (mouse/key fields) 'button > 'enter-notify (mouse/key fields) > 'leave-notify (mouse/key fields) > 'focus-in > 'focus-out > 'visibility-notify 'state > 'property-notify 'property 'time 'state > 'colormap-notify (I'm not sure what is useful to expose to Scheme 'cause > I'm not sure why this event is useful to Scheme in the > first place) > 'mapping-notify 'request Again, I prefer sticking easier-to-guess names by using schemified version of the X11 names. > Implementation note: event-specs should use a representation that > allocates common field-specs statically and rarely cared about ones > dynamically for the sake of efficiency. Event objects could just > contain an XEvent internally. Yep.... I'm wondering whether these objects have already been wrapped-- does Gtk do anything nice fore us here? Any X wrappers out there? I suppose it won't be too painful to do this. > > 2 - Event Map Objects: > > ---------------------- > > > > Now, on to event map objects. My proposal is similar to yours but > > instead of managing the installed event-map from Scheme code, I want to > > attach event map objects to arbitrary X11 windows (e.g., the pager, or a > > pinned menu, etc.), and have the appropriate grabs and XSelectInput > > calls happen based on the event map for a given window. > > > > Geometry-based hierarchy and installation of maps is obviously an > excellent addition. One caveat: events should never propagate from any > part of an application window to the root window (IMO). You mean as opposed to being caught in advance. Obviously we want global bindings to work even when on an application window. I was more talking about, e.g., a button1 decoration propagating up to the titlebar, then to the frame (top-level map for a given window). I think propagating to the root would be wrong, as you suggest. > > First, a means of creating event-maps and populating them with bindings > > from events to procedures: > > > > (make-event-map #&optional PARENT MERGE?) > > ;; PARENT is an event-map object, or omitted or #f to indicate no parent > > (I don't think we need to worry about delaying events, but I'm not sure > > what problem that suggestion was trying to solve). > > This will permit a form of inheritance of behaviours. Note, though, > > that this mechanism should not be necessary for the geometry-based > > chaining that X11 commonly uses. E.g., an event in a window decoration > > (say, a button on the titlebar) will first dispatch based on the event > > map (if any) attached to the decoration, then on the event map for that > > top-level window, then on the global event map. Each of these event maps > > would be built with the PARENT argument omitted or #f. A special > > primitive or symbol can be bound to an event to permit preventing the > > event from propagating, and instead letting it pass to the application. > > MERGE? is #t to indicate that the resulting event-map should (for the > > purposes of event dispatch) treat the PARENT's bindings as equipotent to > > this new child event (i.e. all of the bindings will be checked when > > doing dispatch). MERGE? is #f to indicate that only if no binding > > matched in the child should the parent's bindings be checked. > > > > How about allowing a list of parents to be specifier directly? > i.e. add a rest argument which must be event maps optionally followed > by a boolean field. Or something. It seems awkward to have to add > extra parents explicitly. Sure, that's doable -- a list of either event-maps or event-map bool cons cells (MERGE? == #f is implicit if an element is just an event-map instead of a cons cell). > > event-map-global > > ;; the built-in global event-map object -- it is an implicit, > > ;; non-merged parent of all event-maps > > > > I suggest replacing this by procedures, because it is probably a big > lose to ever let the global event map not be an event map. i.e. there > should be procedures (set-global-event-map! EVENT-MAP) and > (global-event-map). You're right. Procs are better here. > > > (event-map-parents EVENT-MAP) > > ;; Return list of cons pairs (PARENT-EVENT-MAP . MERGE?) > > > (add-event-map-parent! EVENT-MAP PARENT MERGE?) > > ;; Permit multiple parents, though only one can be specified at a time > > Suggest renaming this to event-map-add-parent! > > > (remove-event-map-parent! EVENT-MAP PARENT) > > ;; return #t if successful, #f if parent not found > > Suggest renaming this to event-map-remove-parent! > Both of these renames are good, too. > > (add-event-binding EVENT-MAP EVENT PROC-OR-SYMBOL) > > (remove-event-binding EVENT-MAP EVENT) > > ;; Similar to your {add,remove}-event-hook. > > ;; These add and remove bindings for EVENT objects in the given > > ;; EVENT-MAP object. > > ;; PROC-OR-SYMBOL is either a procedure or 'pass to indicate > > ;; that the event should not be grabbed by the wm and the application > > ;; should get the event (this is only an issue for event maps attached > > ;; to client windows). See dispatch-event for details about how > > ;; the bindings are invoked. > > I suggest allowing multiple procedures to be bound to one event (or > both 'pass and a procedure, to allow convenient implementation of a > passively observing macro recorder facility or something like > that). Proposed interface: > > (event-map-add-binding! EVENT-MAP EVENT-SPEC PROC-OR-PASS) > ;; As `add-event-binding' above, but returns a "binding handle" which > ;; uniquely identifies this specific binding in the map. That seems useful. Good. Do you envision the binding handles to be a SMOB, too, or some scheme-level representation? > Another suggestion: add an optional ARGS-DESIRED argument which may be > one of #f, 'window, 'event or 'full. This only applies if PROC-OR-PASS > is a procedure. If #f, the proc is passed no arguments; if 'window, it > is passed the window object (or 'root-window) that the event is > relevant to; if 'event, it is passed the event object; if 'full, it is > passed the window object, the event object, and the window id in that > order. This will make life a lot easier even though all the others > can be simulated by higher layers if only 'full is provided. I think this is a hack, and didn't want to do it at the event-binding area. I like Emacs' `interactive' a lot better, where with the command (proc) you specify what arguments it is expected to take. It also has the advantages of documenting what procedures are meant to be bound to events, and may provide better printable forms (even if it's a closure). We can simulate your ARGS-DESIRED argument with a set of standard closures, but I still think that the place that should be deciding that is the code that's gonna run (the proc, not the point of binding). I don't have a sense of how hard adding `interactive' declarations would be, but I imagine Jim Blandy could pull it off or provide some help as we need it. > (event-map-remove-binding! EVENT-MAP EVENT-SPEC-OR-HANDLE) > ;; As `remove-event-binding-above', but either a binding handle or an > ;; event-spec may be passed (if a handle is passed, that exact binding > ;; is removed; if an event-spec, all bindings for events with an event-spec > ;; `equal?' to the one passed. Good. > > (list-event-bindings EVENT-MAP) > > ;; return a list of all the event bindings added to EVENT-MAP > > ;; as a cons parent of (EVENT-OBJECT . PROC-OR-SYMOBL) > > Suggest renaming this to event-map-bindings. Agreed. > Implementation notes: obviously, scwm should ask the server to not > send it events it is not interested in. Rephrased to be more precise... scwm will select only the events in which it is interested, and do all the appropriate grab-keys, etc. This is part of the problem with the less-restricted lambda-filtering you suggested. > > 3 - Dispatch of Events > > ---------------------- > > > > (dispatch-event EVENT-MAP EVENT) > > ;; EVENT-MAP is an event-map object, EVENT is an event-object > > ;; All applicable events' procedures should be invoked in the order that > > ;; they were added to the EVENT-MAP. Parent EVENT-MAPs are handled > > ;; as discussed above. > > I'm not convinced that specifying the order this way is a good idea; > it may have negative performance implications. Then again, it may not. I don't think it's got any real problems performance-wise. We can experiment with greater flexibility on controlling the dispatch order later, as I think this design is suboptimal in flexibility (method combination in CLOS is a good place for examples and inspiration here). > > ;; Each procedure is invoked with four arguments: > > ;; #1 - the scheme object that the event acted on/in (e.g., for a button > > ;; decoration, it will be that top-level frame; for a menu it will be > > ;; the menu object, etc.), or #f if there is no applicable scheme object > > ;; (e.g., the root window) > > ;; #2 - the event object that caused this dispatch (i.e. EVENT) > > ;; #3 - the window id of the X window that got the event. We can add > > ;; primitives to query what decoration/menu/whatever a window ID is > > ;; #4 - the time of that event, as reported by the X server > > ;; #5 - a list of event-specific information or #f; e.g., > > ;; a property-notify event may use > > ;; '("WM_TITLE" 'NewValue) > > ;; property name changed and either 'NewValue or 'Delete > > ;; for this argument > > ;; #6 - the event map object (i.e. EVENT-MAP) > > See my suggestion above for allowing procedures to have fewer > arguments passed through an extra argument at binding time. I suggest > removing 5 and 6 above entirely; 5 is redundant with the even object > because event-field can be used to get that information, and 6 just > seems insufficiently useful; if you really care what event map you got > invoked from, make an appropriate closure. The time, if considered > useful, could be added to full, however, IMO the time is logically > part of the event object and should be a field thereof. In fact, not > all events even have time. So 4 is unnecessary as well. *3*, 4, and 5 are all subsumed by the first-class event objects distinct from event-specifiers --- they are folded into #2. I think the event-map object is useful as a place to hang extra-properties off of... given the notion of a binding-object, though, that should replace the event-map object, as it'll have to have an accessor querying the event map to which it corresponds. > > ;; We may need to do something to help simplify binding simple > > ;; procedures to an event (maybe something like Emacs's (interactive) > > ;; declaration), but I think we need all of the above (and maybe more) > > ;; to get a lot of useful functionality. > > ;; Only when no bindings are applicable in the child or its chain of > > ;; parents should the event dispatching mechanism > > ;; proceed to chain the event dispatch up to the enclosing event-map > > ;; context. That is, from decoration->frame->global (button decorations > > ;; perhaps should forward to the titlebar before the frame, but side-bar > > ;; decorations probably should not). > > ;; This primitive is what will get internally invoked when Scwm gets > > ;; an event. Note that Scwm will have to manage selecting the > > ;; appropriate events and grabbing the appropriate keys based on > > ;; the event-map objects attached to various windows. > > ;; Note that my proposed automatic chaining is a restriction (for > > ;; programming understanding and reasoning purposes) on a more general > > ;; notion of a procedure to be called when no event binding matches -- > > ;; the chaining could be made more explicit and put under programmer > > ;; control using this primitive. > > > > (Thanks to Robert Bihlmeyer who made useful comments regarding this > > subsection.) > > > > > 4 - Binding of Event Maps: > > -------------------------- > > > > Event maps can be attached to any X Window by its X Id. We can add > > primitives that give the window id from a SCWM top-level window and a > > decoration specifier. > > > > (attach-event-map X-WINDOW-ID EVENT-MAP) > > e.g., > > (attach-event-map (button-n-of 1 win) button-1-map-for-win) > > (attach-event-map (title-bar-of win) title-bar-map-for-win) > > ;; Only one event map is attached per window id -- attaching > > ;; a new map removes any old one > > > > The window style mechanism should be used to attach a set > > of event maps at startup for a given window style, e.g.: > > > > (window-style "*" #:event-maps (list (1 . default-button-1-map) > > ('title . default-title-map) > > ('window . default-window-map))) > > How event maps are to be integrated with styles is an issue that can > be punted for now. However, I'd like to be more specific on naming > window parts. I suggest the following interface: > > (window-part-id WINDOW PART-NAME) > > PART-NAME is a symbol that is one of the following: > 'frame (the top-level frame window) > 'title > 'side-north > 'side-east > 'side-south > 'side-west > 'corner-ne > 'corner-nw > 'corner-se > 'corner-sw either the side directions should be dropped to n,e,s,w or the corner ones should be spelled out. > '(button-right ) where is an integer > '(button-left ) where is an integer > ;; the arbitrary limit on number of buttons should be removed; they > ;; should be dynamically created on demand. Agreed, and maybe buttons should be first-class, too. It's a bit awkward to use button numbers. For a while, we should also have 'button-number that take an using the current (very screwey) convention of odds on left, and evens on right. > 'icon-title > 'icon-image > 'window ;; the actual application window I think 'window -> 'client-window > Actually, some parts may consist of more than one window. For example, > 'side and 'corner are each four windows which we almost always bind > together. Thus, I suggest that attach-event-map should accept a list > of X window ids in place of a single ID to make this more convenient. I was thinking that 'side should be the geometrical parent of each of the four 'side-[nesw]. Then the binding only occurs in that one map, and the intent is preserved. One shouldn't later be able to `event-map-remove' just the binding for 'side-n and leave the other three windows bound. > > (alias-window-part WINDOW ALIAS-NAME ORIGINAL-NAME) > > For WINDOW, allow ALIAS-NAME to be treated the same as ORIGINAL-NAME > for the purpose of window-part-id. ORIGINAL-NAME may be a part name or > a list of part names. WINDOW may also be #t to indicate a global > alias. > > The following global aliases are pre-defined: > > 'side => '(side-east side-west side-north side-south) > 'corner => '(corner-ne corner-nw corner-se corner-sw) This is unnecessary given my above comments. > > The following should be defined conventionally to ease > look-independent binding of buttons: > > 'system-button > 'maximize-button > 'minimize-button > 'close-button Can't these just be variables? > Other conventinal button names could be established as well. If it is > considered desirable to give these aliases an initial value, I'd > suggest '(button-left 1), '(button-right 1), '(button-right 2) and > '(button-left 2) respectively. > > > > [this avoids a bunch of attach-event-maps from being needed in the > > new-window-hook -- the attaching of the default event maps needs to be > > efficient, since it'll happen for each new window and on lots of > > decorations -- it's only a single XSaveContext call for each attachment, > > which should be fine]. > > > (event-map-for X-WINDOW-ID) > > ;; Return the currently attach event-map object, if any, or #f > > Suggest renaming this to something like get-event-map, > window-id-event-map, or something. IMO prepositions in procedure names > should be used very sparingly. This rename I don't like -- the primary reason I liked the other renames was because it kept event-map at the beginning of the procedure name. event-map-for-window-id would be fine. > > > (remove-event-map X-WINDOW-ID) > > ;; detach any event map from X-WINDOW-ID > > OTHER ISSUES: > > > > Enabling/disabling event maps on a per-attachment basis? > > > > Top-level global event map that's used first before any others? > > I suggest adding: > > (install-override-event-map EVENT-MAP) I think I'd prefer event-map-override and set-event-map-override! (or s/override/global/). There should just be a getter/setter interface to a global-map. (See below, too). > Install EVENT-MAP as the event map to use for everything. Bindings in > EVENT-MAP override any other bindings that may have otherwise taken > effect for the event, unless the binding is 'pass, in which case they > are passed to the normal event map they would have been handled by (or > the app window). > > Motivation: this would allow implementing features like "bookmarks" as > suggested by Carl Witty, multi-event bindings, scwm-read-char and > scwm-read-line, interactive-move and -resize in Scheme (at least the > opaque version), and so on. For the more complex of these, we will > definitely need something like the minibuffer in Emacs; I suggest > reusing the floating coordinate window for this purpose, and letting > the user optionally set it's contants and show and hide it explicitly. > > (current-override-event-map) > > Return the currently installed override event map or #f if none. > > (uninstall-override-event-map) > > Remove the current override event map, if any. The uninstall seems like it's for convenience only. The standard global map could be a null map and install/uninstall can happen by manipulating its parents. > > > I'll try to come up with an example of using this system but please feel > > free to poke holes in it or query me about how one might accomplish > > something you're interested in being able to do. (Or if you think it's > > redundant, overly-general, inefficient, etc.). > > > > I think my suggestions make this interface more general, less > redundant, and easier to understand. I will try to come up w/ > proposals for higher-level binding functionality to be implemented on > top of this interface sometime soon; I believe something as easy to > use and understand as bind-key and bind-mouse, but providing greater > generality, could easily be implemented. > > I'd like comments from Greg and anyone else on my suggested changes, > especially suggestions on what to do about areas that I left wide > open, like the syntax for event and event-spec fields. I like virtually all of your suggestions, *except* the make-event-spec. The only piece of that that makes sense to me is separating out event specifiers and event objects. Otherwise, the event-spec field stuff seems like a hack. My three primitives are more clear, easier to implement, and more nicely restricted than the make-event-spec that you specify. Think of my three primitives (make-key-event, make-mouse-event, make-x-event) as three constructors to an event specifier object. You're trying to overload a single ctr to make all three kinds of event specifiers, whereas I'm exploiting their differences to simplify their interfaces and implementation. This is perfectly reasonable given that there is a natural distinction among the three kinds of events (e.g., a user knows which primitive to invoke). I'll wait for another round of comments from you and others before integrating the changes we've discussed so far into the repository's proposal. Thanks! Greg From owner-scwm-discuss@mit.edu Mon Sep 14 17:24:42 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23077 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:24:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23072 for ; Mon, 14 Sep 1998 17:24:32 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05214; Mon, 14 Sep 98 17:23:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07772; Mon, 14 Sep 1998 14:23:52 -0700 (PDT) To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? References: <199809142010.QAA12833@jekyll.piermont.com> From: Greg Badros Date: 14 Sep 1998 14:23:52 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 14 Sep 1998 16:10:22 -0400" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Maciej Stachowiak writes: > > > I'm wondering if there is currently a pager available for > > > scwm. > > > > Currently, you can only use the fvwm2 pager. However, a native pager > > is planned. As soon as I can get the guile-gtk support to work well, > > I'd like to write a guile-gtk pager as one of the demos for the > > guile-gtk stuff. In the mean time, the fvwm2 pager is your best bet, > > so let's see if I can help with your problem. > > Given the fact that it is claimed my constant hangs are caused by bugs > in the scwm/fvwm-pager communication, I will be happy to see the > native pager. :( Are you still seeing the hangs in a recent version. I made a change (adding O_NONBLOCK to the pipe's flags) that may have helped. I've not noticed any hangs recently. If you do have hangs, can you use truss/strace to see if that's what it is (or tell me how to reproduce whatever you're seeing?) My way of generating the hang (drag the virtual desk around in the pager) no longer causes problems. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 17:26:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23151 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:26:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23148 for ; Mon, 14 Sep 1998 17:26:56 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA03117; Mon, 14 Sep 98 17:25:55 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07781; Mon, 14 Sep 1998 14:26:21 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <19980914212005Z276554-15944+175@pulsar.halcyon.com> From: Greg Badros Date: 14 Sep 1998 14:26:20 -0700 In-Reply-To: Ken Pizzini's message of "Mon, 14 Sep 1998 14:19:55 -0600" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > In message <199809141723.NAA20851@huis-clos.mit.edu>, > Maciej Stachowiak writes: > > Ignoring window shading for the time being, I think the > > correct semantics (in the sense of coming closest to always doing what > > you'd expect) are this: > > > > * If you maximize a window and then unmaximize it without moving it in > > between, it should return to it's position before maxsimizing. > > > > * If you maximize the window and then move it, unmaximizing it should > > leave the position alone. > > Then perhaps the code below is a better approximation of desired behavior? Can you give me a verbal diff or a patch against the current repo? I can't use any automatic tools because too much is different, and it's too time-consuming and error-prone for me to compare visually. Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 17:29:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23229 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:29:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23226 for ; Mon, 14 Sep 1998 17:29:34 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA04050; Mon, 14 Sep 98 17:28:33 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA07823; Mon, 14 Sep 1998 23:28:59 +0200 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <199809141723.NAA20851@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 14 Sep 1998 23:28:59 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 14 Sep 1998 13:23:05 EDT" Message-Id: Lines: 21 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Another thing to consider is what should happen if you explicitly > resize a maximized window. I think the right thing to do here is to > make it lose the maximized property and leave the size andc position > as explicitly set by the user. Actually, that's what fvwm does, and I've never liked it much. I always end up in this situation where toggling just changes the window size by +- 1 line. The alternative would be that resizing in maximize mode doesn't change the maximize property, in which case toggling would go back to original size & a 2nd toggle would switch back to full size. Neither option looks great, actually... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Sep 14 17:29:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23241 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:29:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23237 for ; Mon, 14 Sep 1998 17:29:53 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA07040; Mon, 14 Sep 98 17:29:15 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id RAA13230; Mon, 14 Sep 1998 17:29:06 -0400 (EDT) Message-Id: <199809142129.RAA13230@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: Your message of "14 Sep 1998 14:23:52 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 17:29:06 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Are you still seeing the hangs in a recent version. I made a change > (adding O_NONBLOCK to the pipe's flags) that may have helped. I've not > noticed any hangs recently. I will try recompiling a new scwm now and see what happens. Perry From owner-scwm-discuss@mit.edu Mon Sep 14 17:59:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA23696 for scwm-discuss-outgoing; Mon, 14 Sep 1998 17:59:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA23692 for ; Mon, 14 Sep 1998 17:59:11 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA13608; Mon, 14 Sep 98 17:57:40 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id RAA27887 for ; Mon, 14 Sep 1998 17:56:53 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: And now for something completely different - CLOS event bindings! References: <"x_T4A.0.EM.4yE_r"@tequila.systemsz.cs.yale.edu> Date: 14 Sep 1998 17:56:47 -0400 Message-Id: <5lk936xsrk.fsf@tequila.systemsz.cs.yale.edu> Lines: 12 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Harvey" == Harvey J Stein writes: > (define-method (event-action (w ) > (e )) > (Code for what to do ...)) It's indeed a nice way to implement it but with several shortcomings, most if not all of them coming from the fact that you can't inspect the event maps any more (or at least, not quite so easily). Event maps as data-structures allow you to copy/move/lookup/update them. Stefan From owner-scwm-discuss@mit.edu Mon Sep 14 18:09:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23777 for scwm-discuss-outgoing; Mon, 14 Sep 1998 18:09:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23774 for ; Mon, 14 Sep 1998 18:09:55 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA18639; Mon, 14 Sep 98 18:09:08 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA08040; Tue, 15 Sep 1998 00:08:30 +0200 To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: And now for something completely different - CLOS event bindings! References: <"x_T4A.0.EM.4yE_r"@tequila.systemsz.cs.yale.edu> <5lk936xsrk.fsf@tequila.systemsz.cs.yale.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Sep 1998 00:08:30 +0200 In-Reply-To: Stefan Monnier's message of "14 Sep 1998 17:56:47 -0400" Message-Id: Lines: 25 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Harvey" == Harvey J Stein writes: > > (define-method (event-action (w ) > > (e )) > > (Code for what to do ...)) > > It's indeed a nice way to implement it but with several > shortcomings, most if not all of them coming from the fact that you > can't inspect the event maps any more (or at least, not quite so > easily). Event maps as data-structures allow you to > copy/move/lookup/update them. Yes, which, as I said is why I felt that emacs style event maps might be better. However, most CLOS implementations allow for introspection, so a) you can inspect the event maps & b) they are data structures. But, yes, you can't copy/move/lookup/update them in a natural way, but you before/after/next-method covers most of it for you. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Sep 14 18:20:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23886 for scwm-discuss-outgoing; Mon, 14 Sep 1998 18:20:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23882 for ; Mon, 14 Sep 1998 18:20:05 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA19659; Mon, 14 Sep 98 18:19:02 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id PAA17361 for ; Mon, 14 Sep 1998 15:19:26 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15944>; Mon, 14 Sep 1998 15:09:23 -0700 To: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? In-Reply-To: Your message of "14 Sep 1998 14:26:20 PDT." Date: Mon, 14 Sep 1998 15:09:13 -0600 From: Ken Pizzini Message-Id: <19980914220923Z276516-15944+177@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros said: > Can you give me a verbal diff or a patch against the current repo? I > can't use any automatic tools because too much is different, and it's > too time-consuming and error-prone for me to compare visually. Sorry about that; I was still in the process of getting CVS on my machine when I sent that. Hopefully my patches will be more useful from now on... Maximize now tracks the new (x,y) coordinate that it positioned the window to within teh 'maximized object property. Unmaximize makes use of this: if, when unmaximize is called, the window is positioned at the same coordinates as when maximize finished, then the pre-maximize (x,y) coordinates are restored, otherwise the current (x,y) coordinates are maintained. --Ken Pizzini --- winops.scm-orig Mon Sep 14 15:03:40 1998 +++ winops.scm Mon Sep 14 15:04:12 1998 @@ -104,21 +104,25 @@ (y (cadr pos)) (width (car size)) (height (cadr size))) - (if (not (maximized? win)) - (set-object-property! win 'maximized - (list x y width height))) (resize-frame-to (if (> nw 0) nw width) (if (> nh 0) nh height) win) ;; above is just a hint, get the actual... ;; FIXGJB: race condition? (let* ((new-size (window-frame-size win)) (nw (car new-size)) - (nh (cadr new-size))) - (move-window (if (> display-width (+ x nw)) x - (if (> display-width nw) (- display-width nw) 0)) - (if (> display-height (+ y nh)) y - (if (> display-height nh) (- display-height nh) 0)) - win))))) + (nh (cadr new-size)) + (nx (cond + ((> display-width (+ x nw)) x) + ((> display-width nw) (- display-width nw)) + (#t 0))) + (ny (cond + ((> display-height (+ y nh)) y) + ((> display-height nh) (- display-height nh)) + (#t 0)))) + (move-window nx ny win) + (if (not (maximized? win)) + (set-object-property! win 'maximized + (list x y width height nx ny))))))) (define*-public (maximized? #&optional (win (get-window))) @@ -129,22 +133,18 @@ (define*-public (unmaximize #&optional (win (get-window))) "Unmaximize WIN so it returns to its size/position before maximization. This should use client units, but currently uses frame-size in pixels." - (if win (let ((max-prop (object-property win 'maximized))) + (if win (let* ((max-prop (object-property win 'maximized)) + (pos (window-position win)) + (cur-x (car pos)) + (cur-y (cadr pos))) (cond - (max-prop (move-to (car max-prop) - (cadr max-prop) win) - (resize-frame-to (caddr max-prop) - (cadddr max-prop) win) - (set-object-property! win 'maximized #f)))))) - -(define*-public (unmaximize-no-move #&optional (win (get-window))) - "Unmaximize WIN so it returns to its size before maximization. -This should use client units, but currently uses frame-size in pixels." - (if win (let ((max-prop (object-property win 'maximized))) - (cond - (max-prop (resize-frame-to (caddr max-prop) - (cadddr max-prop) win) - (set-object-property! win 'maximized #f)))))) + (max-prop + (let ((maxed-x (car (cddddr max-prop))) + (maxed-y (cadr (cddddr max-prop)))) + (if (and (= cur-x maxed-x) (= cur-y maxed-y)) + (move-window (car max-prop) (cadr max-prop) win)) + (resize-frame-to (caddr max-prop) (cadddr max-prop) win) + (set-object-property! win 'maximized #f))))))) (define-public (window-frame-area win) From owner-scwm-discuss@mit.edu Mon Sep 14 18:38:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24054 for scwm-discuss-outgoing; Mon, 14 Sep 1998 18:38:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA24051 for ; Mon, 14 Sep 1998 18:38:01 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA25705; Mon, 14 Sep 98 18:37:22 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA07877; Mon, 14 Sep 1998 15:37:26 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <19980914220923Z276516-15944+177@pulsar.halcyon.com> From: Greg Badros Date: 14 Sep 1998 15:37:24 -0700 In-Reply-To: Ken Pizzini's message of "Mon, 14 Sep 1998 15:09:13 -0600" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > Greg Badros said: > > Can you give me a verbal diff or a patch against the current repo? I > > can't use any automatic tools because too much is different, and it's > > too time-consuming and error-prone for me to compare visually. > > Sorry about that; I was still in the process of getting CVS > on my machine when I sent that. Hopefully my patches will > be more useful from now on... > > Maximize now tracks the new (x,y) coordinate that it positioned > the window to within teh 'maximized object property. Unmaximize > makes use of this: if, when unmaximize is called, the window is > positioned at the same coordinates as when maximize finished, then > the pre-maximize (x,y) coordinates are restored, otherwise the current > (x,y) coordinates are maintained. Thanks! I'll try it out soon... Greg From owner-scwm-discuss@mit.edu Mon Sep 14 18:51:05 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24201 for scwm-discuss-outgoing; Mon, 14 Sep 1998 18:51:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA24197 for ; Mon, 14 Sep 1998 18:51:01 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA28858; Mon, 14 Sep 98 18:50:22 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA18648; Mon, 14 Sep 1998 18:50:20 -0400 (EDT) Message-Id: <199809142250.SAA18648@jekyll.piermont.com> To: perry@piermont.com Cc: Greg Badros , Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: Your message of "Mon, 14 Sep 1998 17:29:06 EDT." <199809142129.RAA13230@jekyll.piermont.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 18:50:20 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > I will try recompiling a new scwm now and see what happens. I recompiled, and I haven't had hangs yet, but then again, they were never very predictable before. BTW, my problem with undecorated windows in the lower right corner being miss-placed continues. Perry From owner-scwm-discuss@mit.edu Mon Sep 14 18:53:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24246 for scwm-discuss-outgoing; Mon, 14 Sep 1998 18:53:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA24243 for ; Mon, 14 Sep 1998 18:53:44 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA28449; Mon, 14 Sep 98 18:52:39 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA07912; Mon, 14 Sep 1998 15:53:02 -0700 (PDT) To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? References: <199809142250.SAA18648@jekyll.piermont.com> From: Greg Badros Date: 14 Sep 1998 15:53:00 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 14 Sep 1998 18:50:20 -0400" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > "Perry E. Metzger" writes: > > I will try recompiling a new scwm now and see what happens. > > I recompiled, and I haven't had hangs yet, but then again, they were > never very predictable before. Ok, let me know after a couple more days... > BTW, my problem with undecorated windows in the lower right corner > being miss-placed continues. Remind me about this one... "lower right corner" means what? How can I reproduce this (briefly)? Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 14 19:02:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24432 for scwm-discuss-outgoing; Mon, 14 Sep 1998 19:02:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24429 for ; Mon, 14 Sep 1998 19:02:04 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA01481; Mon, 14 Sep 98 19:01:21 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA07990; Mon, 14 Sep 1998 16:01:17 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? References: <199809141723.NAA20851@huis-clos.mit.edu> From: Greg Badros Date: 14 Sep 1998 16:01:17 -0700 In-Reply-To: hjstein@bfr.co.il's message of "14 Sep 1998 23:28:59 +0200" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Maciej Stachowiak writes: > > > Another thing to consider is what should happen if you explicitly > > resize a maximized window. I think the right thing to do here is to > > make it lose the maximized property and leave the size andc position > > as explicitly set by the user. > > Actually, that's what fvwm does, and I've never liked it much. I > always end up in this situation where toggling just changes the window > size by +- 1 line. > > The alternative would be that resizing in maximize mode doesn't change > the maximize property, in which case toggling would go back to > original size & a 2nd toggle would switch back to full size. > > Neither option looks great, actually... Or we could not permit resizing of maximized windows. This is how Windows gets around the issue, because there maximized really means maximized (less flexible, of course, but the restriction avoids these tricky questions). Greg From owner-scwm-discuss@mit.edu Mon Sep 14 19:06:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24508 for scwm-discuss-outgoing; Mon, 14 Sep 1998 19:06:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24501 for ; Mon, 14 Sep 1998 19:06:05 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01580; Mon, 14 Sep 98 19:04:59 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id TAA18719; Mon, 14 Sep 1998 19:05:23 -0400 (EDT) Message-Id: <199809142305.TAA18719@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: Your message of "14 Sep 1998 15:53:00 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 14 Sep 1998 19:05:23 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > BTW, my problem with undecorated windows in the lower right corner > > being miss-placed continues. > > Remind me about this one... "lower right corner" means what? How can I > reproduce this (briefly)? assuming, say, that xclock is undecorated, try: xclock -geometry -0-0 Perry From owner-scwm-discuss@mit.edu Mon Sep 14 19:17:24 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24664 for scwm-discuss-outgoing; Mon, 14 Sep 1998 19:17:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24661 for ; Mon, 14 Sep 1998 19:17:23 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA04605; Mon, 14 Sep 98 19:16:43 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA08016; Mon, 14 Sep 1998 16:16:44 -0700 (PDT) To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A pager for scwm? References: <199809142305.TAA18719@jekyll.piermont.com> From: Greg Badros Date: 14 Sep 1998 16:16:40 -0700 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 14 Sep 1998 19:05:23 -0400" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > > BTW, my problem with undecorated windows in the lower right corner > > > being miss-placed continues. > > > > Remind me about this one... "lower right corner" means what? How can I > > reproduce this (briefly)? > > > assuming, say, that xclock is undecorated, try: > > xclock -geometry -0-0 Oh right -- the windows that get misplaced by 6-8 pixels (8 pixels for me, w/ gjb.scwmrc) bug. I was leaving that one for Maciej in case he wasn't done with the gravity rewrite (which I think is true, since we want setters/getters, and resize to take gravity into account). Thanks for the reminder. Greg From owner-scwm-discuss@mit.edu Mon Sep 14 19:55:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24907 for scwm-discuss-outgoing; Mon, 14 Sep 1998 19:55:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24904 for ; Mon, 14 Sep 1998 19:55:22 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12547; Mon, 14 Sep 98 19:54:18 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA08182; Mon, 14 Sep 1998 16:54:46 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: define-command macro? From: Greg Badros Date: 14 Sep 1998 16:54:45 -0700 Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I was thinking about interactive declarations, and it seems we could get almost all the way there with a define-command macro that acts like define-public, but uses an extra INTERACTIVE-SPECIFIER argument(s) to also define a closure that does the conversion of the arguments passed by the dispatch-event routine into those that the procedure wants. That argument-translation closure then gets bound to an object property for the real procedure, and we can write a `command?' procedure that checks for that property. Then event bindings could be restricted to be made only to procedures for which `command?' is true. We lose the ability to do stuff like: (define-key global-map "\M-`" (lambda () (interactive) (kill-buffer nil))) but there's a reasonably strong reason to not want people to do this anyway -- it's nice to have a succint name for anything bound to an event. From owner-scwm-discuss@mit.edu Mon Sep 14 19:57:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA24942 for scwm-discuss-outgoing; Mon, 14 Sep 1998 19:57:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA24939 for ; Mon, 14 Sep 1998 19:57:55 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12973; Mon, 14 Sep 98 19:57:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA08198; Mon, 14 Sep 1998 16:57:19 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Cassowary 0.21 released! From: Greg Badros Date: 14 Sep 1998 16:57:17 -0700 Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just made a slightly enhanced v0.21 of Cassowary available on the web and ftp. I updated the web page to include the README file, and mention the need for a recent C++ compiler and provide a link to egcs, the C++ compiler I use. This new version works with the latest scwm snapshots (and may not work with earlier versions). See: http://www.cs.washington.edu/research/constraints/cassowary/ for details and the distribution. Greg >From NEWS: 14-Sep-98, Changes since Cassowary v0.2 (for release v0.21) * Make compile cleanly using egcs-1.1b -- use typename, and drop unused templated instantiation * Improved guile interface: add a void pointer to the solver objects, and let the guile wrapper use it to keep a pointer to the scheme-level object; also added clv-attach! and clv-attached-object for attaching an object to a cl-variable (somewhat redundant with guile's object properties) * Wrap ClStayConstraints so they can be managed explicitly * cl-add-stay, cl-add-editvar now take strength and factor arguments, instead of a list of cl-vars * Added weight option to addEditVar From owner-scwm-discuss@mit.edu Mon Sep 14 23:23:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26431 for scwm-discuss-outgoing; Mon, 14 Sep 1998 23:23:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA26428 for ; Mon, 14 Sep 1998 23:23:55 -0400 Received: from smtp8.nwnexus.com by MIT.EDU with SMTP id AA24238; Mon, 14 Sep 98 23:22:46 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp8.nwnexus.com (8.8.8/8.8.8) with ESMTP id UAA02577 for ; Mon, 14 Sep 1998 20:22:01 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276553-15944>; Mon, 14 Sep 1998 16:41:32 -0700 To: scwm-discuss@mit.edu Subject: Re: size toggling strangeness - bug? In-Reply-To: Your message of "14 Sep 1998 16:01:17 PDT." Date: Mon, 14 Sep 1998 16:41:18 -0600 From: Ken Pizzini Message-Id: <19980914234132Z276553-15944+181@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Or we could not permit resizing of maximized windows. This is how > Windows gets around the issue, because there maximized really means > maximized (less flexible, of course, but the restriction avoids these > tricky questions). Blech. --Ken Pizzini From owner-scwm-discuss@mit.edu Mon Sep 14 23:40:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26674 for scwm-discuss-outgoing; Mon, 14 Sep 1998 23:40:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA26671 for ; Mon, 14 Sep 1998 23:40:25 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24907; Mon, 14 Sep 98 23:39:43 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id GAA10770 for ; Tue, 15 Sep 1998 06:39:41 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id FAA12604; Tue, 15 Sep 1998 05:39:40 +0200 To: scwm-discuss@mit.edu Subject: tiny suggestion From: abel@bfr.co.il (Alexander L. Belikoff) Date: 15 Sep 1998 05:39:40 +0200 Message-Id: Lines: 12 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk When I resize or move a window in scwm, I get a small window at the center of the screen w/ running coordinates. The window color is white. How about making it the same color as the highlight-background/foreground ones? Cheers, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 15 00:12:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26851 for scwm-discuss-outgoing; Tue, 15 Sep 1998 00:12:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA26846 for ; Tue, 15 Sep 1998 00:11:11 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA29616; Tue, 15 Sep 98 00:10:23 EDT Received: (qmail 22607 invoked by uid 501); 15 Sep 1998 04:10:36 -0000 Message-Id: <19980914211036.A22566@molehill.org> Date: Mon, 14 Sep 1998 21:10:36 -0700 From: Todd Larason To: "Alexander L. Belikoff" , scwm-discuss@mit.edu Subject: Re: tiny suggestion References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Alexander L. Belikoff on Tue, Sep 15, 1998 at 05:39:40AM +0200 X-Tom-Swifty: "We need a 10-gauge needle", Tom hypothesized. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980915, Alexander L. Belikoff wrote: > > When I resize or move a window in scwm, I get a small window at the > center of the screen w/ running coordinates. The window color is > white. How about making it the same color as the > highlight-background/foreground ones? set-message-window-attributes! sets the font, foreground, and background settings for the message window. (set-message-window-attributes! (make-font "-*-helvetica-bold-r-*-*-12-*-*-*-*-*-*-*") "Black" "Gray80") for example. From owner-scwm-discuss@mit.edu Tue Sep 15 03:52:32 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28572 for scwm-discuss-outgoing; Tue, 15 Sep 1998 03:52:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA28569 for ; Tue, 15 Sep 1998 03:52:28 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25421; Tue, 15 Sep 98 03:51:13 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id JAA10910; Tue, 15 Sep 1998 09:51:49 +0200 To: scwm-discuss@mit.edu Subject: Another max/min bug. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Sep 1998 09:51:49 +0200 In-Reply-To: Greg Badros's message of "14 Sep 1998 10:44:28 -0700" Message-Id: Lines: 21 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Toggling off maximize switches back to the original size in pixels, not the original size in rows & columns. This is a bug for windows that resize in rows & columns - text windows such as emacs & xterms. Example: 1. Bring up an xterm. 2. Maximize it. 3. Switch it to a much smaller font (control-right_mouse_button) so that the window gets much smaller in pixels. It preserves the # of rows & columns, though. 4. Unmaximize it. When doing step 4 the window reverts back to the original size in pixels - i.e. - has too many rows & columns. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 15 03:56:20 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28607 for scwm-discuss-outgoing; Tue, 15 Sep 1998 03:56:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA28604 for ; Tue, 15 Sep 1998 03:56:19 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21435; Tue, 15 Sep 98 03:55:35 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id JAA10929; Tue, 15 Sep 1998 09:55:39 +0200 To: scwm-discuss@mit.edu Subject: Re: Message window position References: <19980913161452.A6797@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 15 Sep 1998 09:55:39 +0200 In-Reply-To: Todd Larason's message of "Sun, 13 Sep 1998 16:14:52 -0700" Message-Id: Lines: 25 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I keep losing the message (geometry) window when moving or resizing > windows - I prefer it in the upper left corner to the center of the > screen. I think I'd actually prefer it following the mouse, offset by > maybe 20 pixels. > > Attached is a patch that gets part of the way there. To get the > rest of the way there, I think I need to be able to hook into the > middle of MoveLoop. Any hints on that? Thanks - I still haven't been able to get used to the geometry window being in the middle of the screen. I much prefer it in the upper left corner (where I keep my pager, xclock & biff). Following the mouse would be better than the center of the screen, but now that you're changing the behavior, how difficult would it be to make this configurable - either display at a (configurable) location or a (configurable) offset from the mouse? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 15 04:29:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA28863 for scwm-discuss-outgoing; Tue, 15 Sep 1998 04:29:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA28860 for ; Tue, 15 Sep 1998 04:29:14 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA24209; Tue, 15 Sep 98 04:28:28 EDT Received: (qmail 24411 invoked by uid 501); 15 Sep 1998 08:28:07 -0000 Message-Id: <19980915012807.A24306@molehill.org> Date: Tue, 15 Sep 1998 01:28:07 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: X programming help References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980914012244.A12507@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Mon, Sep 14, 1998 at 09:09:35AM -0700 X-Tom-Swifty: "It's a unit of electric current", said Tom amply. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980914, Greg Badros wrote: > Meta level comments: just changing the code to have the behaviour you > want is a good way to prototype changes and learn how to implement a > feature. I fully agree - I was just trying to get the first step working before moving on to the next. > I always assummed that clip masks were bitmaps, not pixmaps (i.e., 1 bit > depth). I've not done much low level Xlib programming in a while, though. Of course they are...silly me. Fixing that took care of one of the errors, but also made the code stop working entirely. I think I needed to be checking the mask for None separately from copying it, but I haven't verified that yet. Setting the new mask to None removes the second error message, and makes the code work again. > I'm pretty sure this doesn't have to be as complicated as clipping > images and all that. See PaintSidePic in menus.c of fvwm2.0.47[cd] -- > if I remember correctly fvwm2 justified the side image to the bottom. I'm working on this, and am now at the point of either doing the clipping or finding a better way to do it...and I've spent the past half hour looking for fvwm2.0.47. Any hints? Brady's disappeared, and evidentally with him, his machine. Messages on fvwm-workers dating back to August from people who can't connect, and nobody's offered any mirrors. From owner-scwm-discuss@mit.edu Tue Sep 15 04:32:15 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA28898 for scwm-discuss-outgoing; Tue, 15 Sep 1998 04:32:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA28895 for ; Tue, 15 Sep 1998 04:32:10 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24394; Tue, 15 Sep 98 04:31:26 EDT Received: (qmail 24440 invoked by uid 501); 15 Sep 1998 08:31:47 -0000 Message-Id: <19980915013147.A24417@molehill.org> Date: Tue, 15 Sep 1998 01:31:47 -0700 From: Todd Larason To: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: Message window position References: <19980913161452.A6797@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Harvey J. Stein on Tue, Sep 15, 1998 at 09:55:39AM +0200 X-Tom-Swifty: "I'm a lesbian", Mary mentioned. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980915, Harvey J. Stein wrote: > Following the mouse would be better than the center of the screen, but > now that you're changing the behavior, how difficult would it be to > make this configurable - either display at a (configurable) location > or a (configurable) offset from the mouse? I was envisioning calling an scwm procedure during the move/resize loop, which could then call set-message-window-position! as appropriate. Trying to get that working, and seeing if it's fast enough to be usable, is next on my scwm todo list after the menu side image stuff. Of course, my employers seem to think they get a higher place on the global todo list... From owner-scwm-discuss@mit.edu Tue Sep 15 07:38:28 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA29689 for scwm-discuss-outgoing; Tue, 15 Sep 1998 07:38:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA29686 for ; Tue, 15 Sep 1998 07:38:24 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA11748; Tue, 15 Sep 98 07:37:00 EDT Received: (qmail 30060 invoked by uid 501); 15 Sep 1998 11:37:41 -0000 Message-Id: <19980915043741.A30014@molehill.org> Date: Tue, 15 Sep 1998 04:37:41 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: menu side image alignment Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "These bit patterns will be more readable in groups of 8", said Tom bitingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk DON'T APPLY THIS PATCH At least, not until someone has given it a good looking-over. In menu.c, I commented out some references to scmExtraOptions. Before I did that, my patched scwm was crashing during startup, doing a GC mark on that field. I expect commenting it out is just masking the problem, whatever it is. I haven't found yet what I broke, and I should have been in bed hours ago, so I'm hoping some fresh eyes on it might make it obvious to someone. ? build-x86 ? build-ppc ? diff Index: sample.scwmrc/menu-test.scm =================================================================== RCS file: /anoncvs/scwm/sample.scwmrc/menu-test.scm,v retrieving revision 1.10 diff -u -r1.10 menu-test.scm --- menu-test.scm 1998/07/06 06:52:24 1.10 +++ menu-test.scm 1998/09/15 11:30:36 @@ -47,7 +47,7 @@ (display "toggle-stick\n")) #f #f (make-image "mini-stick.xpm") #f #f "stick")) - #f #f (make-color "gray80")) + #f #f #f (make-color "gray80")) ) (define more-menu-ops-item @@ -65,7 +65,7 @@ window-ops-title-item bitmap-separator sticky-menu-item move-menu-item resize-menu-item more-menu-ops-item) - (make-image "linux-menu.xpm") (make-color "blue") + (make-image "linux-menu.xpm") 'top (make-color "blue") 'a-color)) @@ -80,7 +80,7 @@ (make-menu-item "Stick/Unstick" toggle-stick "" #f (make-image "mini-stick.xpm") #f #f "stick")) - #f #f (make-color "gray80")) + #f #f #f (make-color "gray80")) ) ;;(popup-menu a-menu) Index: scheme/base.scm =================================================================== RCS file: /anoncvs/scwm/scheme/base.scm,v retrieving revision 1.54 diff -u -r1.54 base.scm --- base.scm 1998/09/13 17:41:19 1.54 +++ base.scm 1998/09/15 11:30:39 @@ -292,6 +292,7 @@ (define*-public (menu list-of-menuitems #&key image-side + (image-align 'top) (color-bg-image-side 'menu-bg-color) (image-bg #f) (color-text 'menu-text-color) @@ -300,11 +301,13 @@ "Return a menu object with the given attributes. LIST-OF-MENUITEMS is a list of menuitem objects (each created with `make-menuitem' or `menuitem'). IMAGE-SIDE is an image object to be -displayed along the left edge of the menu. COLOR-BG-IMAGE-SIDE is the -background color for that image object. COLOR-TEXT is a color object -or string for the foreground text color of menu items. COLOR-BG is a -color object or string for the background color for the menu and menu -items. FONT is a font object for the font of the menu items." +displayed along the left edge of the menu. IMAGE-ALIGN determines +whether to align that image to the 'top, 'center or 'bottom of the +menu. COLOR-BG-IMAGE-SIDE is the background color for that image +object. COLOR-TEXT is a color object or string for the foreground +text color of menu items. COLOR-BG is a color object or string for +the background color for the menu and menu items. FONT is a font +object for the font of the menu items." (if (string? image-side) (set! image-side (make-image image-side))) (if (string? color-bg) @@ -313,7 +316,7 @@ (set! color-text (make-color color-text))) (if (string? color-bg-image-side) (set! color-bg-image-side (make-color color-bg-image-side))) - (make-menu list-of-menuitems image-side color-bg-image-side + (make-menu list-of-menuitems image-side image-align color-bg-image-side color-bg color-text image-bg font)) (define-public (image-property image key) Index: scwm/drawmenu.c =================================================================== RCS file: /anoncvs/scwm/scwm/drawmenu.c,v retrieving revision 1.27 diff -u -r1.27 drawmenu.c --- drawmenu.c 1998/09/03 21:34:18 1.27 +++ drawmenu.c 1998/09/15 11:30:41 @@ -21,6 +21,8 @@ #include "dmalloc.h" #endif +extern SCM sym_top, sym_center, sym_bottom; + /* FIXGJB: comment these! */ #define MENU_EDGE_VERT_SPACING 2 #define MENU_EDGE_HORIZ_SPACING 2 @@ -49,8 +51,12 @@ } static void -PaintSideImage(Window w, Pixel bg, int cpixHeight, scwm_image *psimg) +PaintSideImage(Window w, Pixel bg, int cpixHeight, scwm_image *psimg, + SCM align) { + int cpixDstYoffset, cpixSrcYoffset; + int height; + if (!psimg) { scwm_msg(ERR,__FUNCTION__,"psimg is NULL"); return; @@ -59,9 +65,38 @@ XFillRectangle(dpy, w, Scr.ScratchGC1, MENU_ITEM_RR_SPACE, MENU_ITEM_RR_SPACE, psimg->width, cpixHeight - 2*MENU_ITEM_RR_SPACE); - DrawImage(w,psimg,MENU_ITEM_RR_SPACE,MENU_ITEM_RR_SPACE,NULL); -} + height = psimg->height; + if (height > cpixHeight - 2*MENU_ITEM_RR_SPACE) + height = cpixHeight - 2*MENU_ITEM_RR_SPACE; + + if (align == sym_top) { + cpixDstYoffset = MENU_ITEM_RR_SPACE; + cpixSrcYoffset = 0; + } else if (align == sym_center) { + if (psimg->height > height) { + cpixDstYoffset = MENU_ITEM_RR_SPACE; + cpixSrcYoffset = (psimg->height - height)/2; + } else { + cpixDstYoffset = (cpixHeight - height)/2; + cpixSrcYoffset = 0; + } + } else { + if (psimg->height > height) { + cpixDstYoffset = MENU_ITEM_RR_SPACE; + cpixSrcYoffset = psimg->height - height; + } else { + cpixDstYoffset = cpixHeight - height; + cpixSrcYoffset = 0; + } + } + + DrawSubImage(w, psimg, + MENU_ITEM_RR_SPACE, cpixDstYoffset, + 0, cpixSrcYoffset, + psimg->width, height, + NULL); +} /* * RelieveHalfRectangle - add relief lines to the sides only of a @@ -293,7 +328,8 @@ { /* scope */ scwm_image *psimgSide = SAFE_IMAGE(pmd->pmenu->scmImgSide); if (psimgSide) { - PaintSideImage(w,pmdi->SideBGColor,pmdi->cpixHeight,psimgSide); + PaintSideImage(w,pmdi->SideBGColor,pmdi->cpixHeight,psimgSide, + pmd->pmenu->scmSideAlign); } } XSync(dpy,0); Index: scwm/face.c =================================================================== RCS file: /anoncvs/scwm/scwm/face.c,v retrieving revision 1.42 diff -u -r1.42 face.c --- face.c 1998/09/07 19:30:29 1.42 +++ face.c 1998/09/15 11:30:44 @@ -316,11 +316,14 @@ void add_spec_to_face_x(SCM face, SCM spec, SCM arg); -/* These three symbols are also used by msicprocs.c's - set-title-justify! */ +/* 'left, 'right and 'center are also used by miscprocs.c's + set-title-justify!; 'center, 'top and 'bottom are used by + menu.c's side menu alignment */ SCWM_GLOBAL_SYMBOL(sym_left , "left"); SCWM_GLOBAL_SYMBOL(sym_right , "right"); SCWM_GLOBAL_SYMBOL(sym_center , "center"); +SCWM_GLOBAL_SYMBOL(sym_top , "top"); +SCWM_GLOBAL_SYMBOL(sym_bottom , "bottom"); SCWM_SYMBOL(sym_clear , "clear"); SCWM_SYMBOL(sym_justify , "justify"); @@ -329,8 +332,6 @@ SCWM_SYMBOL(sym_use_style_of , "use-style-of"); SCWM_SYMBOL(sym_hidden_handles , "hidden-handles"); SCWM_SYMBOL(sym_no_inset , "no-inset"); -SCWM_SYMBOL(sym_top , "top"); -SCWM_SYMBOL(sym_bottom , "bottom"); SCWM_SYMBOL(sym_flat , "flat"); SCWM_SYMBOL(sym_sunk , "sunk"); SCWM_SYMBOL(sym_raised , "raised"); Index: scwm/menu.c =================================================================== RCS file: /anoncvs/scwm/scwm/menu.c,v retrieving revision 1.33 diff -u -r1.33 menu.c --- menu.c 1998/09/14 16:36:20 1.33 +++ menu.c 1998/09/15 11:30:51 @@ -43,6 +43,8 @@ #include "dmalloc.h" #endif +extern SCM sym_top, sym_center, sym_bottom; + static DynamicMenu *NewDynamicMenu(Menu *pmenu, DynamicMenu *pmdPoppedFrom); static void PopdownMenu(DynamicMenu *pmd); static void FreeDynamicMenu(DynamicMenu *pmd); @@ -78,12 +80,13 @@ GC_MARK_SCM_IF_SET(pmenu->scmMenuItems); GC_MARK_SCM_IF_SET(pmenu->scmImgSide); + GC_MARK_SCM_IF_SET(pmenu->scmSideAlign); GC_MARK_SCM_IF_SET(pmenu->scmSideBGColor); GC_MARK_SCM_IF_SET(pmenu->scmBGColor); GC_MARK_SCM_IF_SET(pmenu->scmTextColor); GC_MARK_SCM_IF_SET(pmenu->scmImgBackground); GC_MARK_SCM_IF_SET(pmenu->scmFont); - GC_MARK_SCM_IF_SET(pmenu->scmExtraOptions); +//XXX GC_MARK_SCM_IF_SET(pmenu->scmExtraOptions); return SCM_BOOL_F; } @@ -178,6 +181,7 @@ return pch; } +/* XXX should be assoc list? whichever, add scmSideAlign */ SCWM_PROC(menu_properties, "menu-properties", 1, 0, 0, (SCM menu)) /** Returns the a list of the menu properties of MENU, a menu object. @@ -197,20 +201,23 @@ pmenu->scmTextColor, pmenu->scmImgBackground, pmenu->scmFont, - pmenu->scmExtraOptions, +//XXX pmenu->scmExtraOptions, gh_str02scm(pmenu->pchUsedShortcutKeys), SCM_UNDEFINED); } #undef FUNC_NAME +/* XXX the side picture arguments should probably be EXTRA-OPTIONS - what's + a 'side image' for a pie menu? */ SCWM_PROC(make_menu, "make-menu", 1, 7, 0, (SCM list_of_menuitems, - SCM picture_side, SCM side_bg_color, + SCM picture_side, SCM picture_align, SCM side_bg_color, SCM bg_color, SCM text_color, SCM picture_bg, SCM font, SCM extra_options)) /** Make and return a menu object from the given arguments. LIST-OF-MENUITEMS is a non-empty scheme list of menu items -- see `make-menuitem'; +PICTURE-ALIGN is one of 'top, 'center, or 'bottom; PICTURE-SIDE is an image object; SIDE-BG-COLOR, BG-COLOR, TEXT-COLOR, PICTURE-BG are color objects; FONT is a font object; @@ -240,6 +247,18 @@ pmenu->scmImgSide = picture_side; iarg++; + if (UNSET_SCM(picture_align)) { + picture_align = sym_top; + } else if (!gh_symbol_p(picture_align) || + (picture_align != sym_top && + picture_align != sym_center && + picture_align != sym_bottom)) { + scm_misc_error(FUNC_NAME,"PICTURE-ALIGN must be 'top, 'center or 'bottom'", + SCM_EOL); + } + pmenu->scmSideAlign = picture_align; + + iarg++; if (UNSET_SCM(side_bg_color)) { side_bg_color = WHITE_COLOR; } else if (!COLOR_OR_SYMBOL_P(side_bg_color)) { @@ -282,7 +301,7 @@ } pmenu->scmFont = font; - pmenu->scmExtraOptions = extra_options; +//XXX pmenu->scmExtraOptions = extra_options; pmenu->pchUsedShortcutKeys = NULL; Index: scwm/menu.h =================================================================== RCS file: /anoncvs/scwm/scwm/menu.h,v retrieving revision 1.11 diff -u -r1.11 menu.h --- menu.h 1998/08/21 20:21:32 1.11 +++ menu.h 1998/09/15 11:30:52 @@ -72,6 +72,7 @@ SCM scmImgBackground; /* background image */ SCM scmFont; /* font for labels */ SCM scmExtraOptions; /* extra list of options for the drawing code */ + SCM scmSideAlign; /* side image alignment */ char *pchUsedShortcutKeys; /* list of characters that are shortcut keys */ } Menu; @@ -89,7 +90,6 @@ PfnPaintDynamicMenu fnPaintDynamicMenu; /* the function to paint the whole menu */ PfnPaintMenuItem fnPaintMenuItem; /* the function to paint a single menu item */ }; - #define MENU_P(X) (SCM_NIMP((X)) && (gh_car((X)) == (SCM)scm_tc16_scwm_menu)) #define MENU(X) ((Menu *)gh_cdr((X))) Index: scwm/xmisc.c =================================================================== RCS file: /anoncvs/scwm/scwm/xmisc.c,v retrieving revision 1.21 diff -u -r1.21 xmisc.c --- xmisc.c 1998/09/03 21:34:22 1.21 +++ xmisc.c 1998/09/15 11:31:34 @@ -104,23 +104,39 @@ void DrawImage(Window w, scwm_image *psimg, int cpixXoffset, int cpixYoffset, GC gc) { + DrawSubImage(w, psimg, cpixXoffset, cpixYoffset, 0, 0, psimg->width, psimg->height, gc); +} + +/* Note: gc is only used for bitmaps! */ +void +DrawSubImage(Window w, scwm_image *psimg, + int cpixDstXoffset, int cpixDstYoffset, + int cpixSrcXoffset, int cpixSrcYoffset, + int cpixWidth, int cpixHeight, + GC gc) +{ if (psimg->depth > 0) { GC gcPixmap = Scr.ScratchGC1; /* a full pixmap (as opposed to just a bitmap) */ Globalgcv.clip_mask = psimg->mask; - Globalgcv.clip_x_origin = cpixXoffset; - Globalgcv.clip_y_origin = cpixYoffset; + Globalgcv.clip_x_origin = cpixDstXoffset; + Globalgcv.clip_y_origin = cpixDstYoffset; XChangeGC(dpy,gcPixmap,(GCClipMask | GCClipXOrigin | GCClipYOrigin),&Globalgcv); - XCopyArea(dpy, psimg->image, w, gcPixmap, 0, 0, psimg->width, psimg->height, - Globalgcv.clip_x_origin, Globalgcv.clip_y_origin); + XCopyArea(dpy, psimg->image, w, gcPixmap, + cpixSrcXoffset, cpixSrcYoffset, + cpixWidth, cpixHeight, + cpixDstXoffset, cpixDstYoffset); Globalgcv.clip_mask = None; XChangeGC(dpy,gcPixmap,(GCClipMask),&Globalgcv); } else { /* bitmap */ - XCopyPlane(dpy, psimg->image, w, gc, 0, 0, psimg->width, psimg->height, - cpixXoffset, cpixYoffset, 1 /* plane */); + XCopyPlane(dpy, psimg->image, w, gc, + cpixSrcXoffset, cpixSrcYoffset, + cpixWidth, cpixHeight, + cpixDstXoffset, cpixDstYoffset, + 1 /* plane */); } } Index: scwm/xmisc.h =================================================================== RCS file: /anoncvs/scwm/scwm/xmisc.h,v retrieving revision 1.15 diff -u -r1.15 xmisc.h --- xmisc.h 1998/09/01 21:30:37 1.15 +++ xmisc.h 1998/09/15 11:31:35 @@ -29,6 +29,11 @@ Bool FXIsWindowMapped(Display *dpy, Window w); void DrawImage(Window w, scwm_image *psimg, int cpixXoffset, int cpixYoffset, GC gc); +void DrawSubImage(Window w, scwm_image *psimg, + int cpixDstXoffset, int cpixDstYoffset, + int cpixSrcXoffset, int cpixSrcYOffset, + int cpixWidth, int cpixHeight, + GC gc); XTextProperty *PNewXTextPropertyFromSz(const char *sz); int flush_expose(Window w); void RestoreWithdrawnLocation(ScwmWindow *, Bool); From owner-scwm-discuss@mit.edu Tue Sep 15 09:11:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30086 for scwm-discuss-outgoing; Tue, 15 Sep 1998 09:11:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA30083 for ; Tue, 15 Sep 1998 09:11:31 -0400 Received: from tor-dev1.nbc.netcom.ca by MIT.EDU with SMTP id AA29712; Tue, 15 Sep 98 09:10:08 EDT Received: (from misaka@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) id JAA07114; Tue, 15 Sep 1998 09:10:29 -0400 (EDT) From: Mishka Gorodnitzky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13822.26437.593754.684305@tor-dev1.nbc.netcom.ca> Date: Tue, 15 Sep 1998 09:10:29 -0400 (EDT) To: "Craig A. Struble" Cc: Mishka Gorodnitzky , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: References: <13817.39182.141401.444937@tor-dev1.nbc.netcom.ca> X-Mailer: VM 6.53 under 20.4 "Emerald" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig A. Struble writes: ] I saw this message when using scwm-0.8 with guile-1.2 which doesn't ] implement basename. Updating to a guile-1.3 snapshot fixes it and a number ] of other strange things you see when using guile-1.2. Yup. That's the setup I've got. (guile-1.2). I haven't had a chance to recompile scwm to use 1.3 though (I originally installed it from a binary package). Thanks for the advice ... hope to get this recompiled and working soon! -- Mishka From owner-scwm-discuss@mit.edu Tue Sep 15 09:16:50 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30132 for scwm-discuss-outgoing; Tue, 15 Sep 1998 09:16:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA30129 for ; Tue, 15 Sep 1998 09:16:49 -0400 Received: from tor-dev1.nbc.netcom.ca by MIT.EDU with SMTP id AA24829; Tue, 15 Sep 98 09:16:04 EDT Received: (from misaka@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) id JAA07132; Tue, 15 Sep 1998 09:16:00 -0400 (EDT) From: Mishka Gorodnitzky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13822.26768.453538.473856@tor-dev1.nbc.netcom.ca> Date: Tue, 15 Sep 1998 09:16:00 -0400 (EDT) To: Maciej Stachowiak Cc: "Craig A. Struble" , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: <199809141956.PAA22233@huis-clos.mit.edu> References: <199809141956.PAA22233@huis-clos.mit.edu> X-Mailer: VM 6.53 under 20.4 "Emerald" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: ] ] cstruble@vt.edu writes: ] > I saw this message when using scwm-0.8 with guile-1.2 which doesn't ] > implement basename. Updating to a guile-1.3 snapshot fixes it and a number ] > of other strange things you see when using guile-1.2. ] ] Ah, there's the problem then. I'm about to commit a fix which defines ] basename if Guile doesn't provide it. (Given that it's four trivial ] lines, I don't think there are copyright issues.) Heh. I was thinking htat writing a basename might be a good way for me to get more familiar with scheme, but I figured I might want to check here in case there's more to just adding a basename for this version of guile. Thanks for the help, and thanks to the developers and helpers on the scwm-discuss list for the great work on scwm. -- Mishka From owner-scwm-discuss@mit.edu Tue Sep 15 11:02:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30706 for scwm-discuss-outgoing; Tue, 15 Sep 1998 11:02:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30703 for ; Tue, 15 Sep 1998 11:02:50 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA09066; Tue, 15 Sep 98 11:01:26 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09490; Tue, 15 Sep 1998 08:01:59 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: X programming help References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980914012244.A12507@molehill.org> <19980915012807.A24306@molehill.org> From: Greg Badros Date: 15 Sep 1998 08:01:58 -0700 In-Reply-To: Todd Larason's message of "Tue, 15 Sep 1998 01:28:07 -0700" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > > I'm pretty sure this doesn't have to be as complicated as clipping > > images and all that. See PaintSidePic in menus.c of fvwm2.0.47[cd] -- > > if I remember correctly fvwm2 justified the side image to the bottom. > > I'm working on this, and am now at the point of either doing the clipping > or finding a better way to do it...and I've spent the past half hour > looking for fvwm2.0.47. Any hints? Brady's disappeared, and evidentally > with him, his machine. Messages on fvwm-workers dating back to August > from people who can't connect, and nobody's offered any mirrors. I just put fvwm-2.0.47c.tar.gz on my ftp site: ftp.cs.washington.edu:/homes/gjb I'll only leave it up for a couple of days, but that should be plenty. Greg From owner-scwm-discuss@mit.edu Tue Sep 15 11:28:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30856 for scwm-discuss-outgoing; Tue, 15 Sep 1998 11:28:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30853 for ; Tue, 15 Sep 1998 11:28:24 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA18674; Tue, 15 Sep 98 11:26:59 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09513; Tue, 15 Sep 1998 08:27:37 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Message window position References: <19980913161452.A6797@molehill.org> <19980915013147.A24417@molehill.org> From: Greg Badros Date: 15 Sep 1998 08:27:36 -0700 In-Reply-To: Todd Larason's message of "Tue, 15 Sep 1998 01:31:47 -0700" Message-Id: Lines: 28 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980915, Harvey J. Stein wrote: > > Following the mouse would be better than the center of the screen, but > > now that you're changing the behavior, how difficult would it be to > > make this configurable - either display at a (configurable) location > > or a (configurable) offset from the mouse? > > I was envisioning calling an scwm procedure during the move/resize loop, > which could then call set-message-window-position! as appropriate. Trying > to get that working, and seeing if it's fast enough to be usable, is next > on my scwm todo list after the menu side image stuff. This'd be plenty fast-- I thought about eliminating the message window from C code during move/resizes in favor of doing exactly this, but didn't bother (but did get the message window usable enough from scheme to make it an option, as you've recognized). Good! Glad to see you've got some nice concrete enhancements planned! > Of course, my employers seem to think they get a higher place on the > global todo list... Funny that! :-) Thanks, Greg From owner-scwm-discuss@mit.edu Tue Sep 15 11:33:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30909 for scwm-discuss-outgoing; Tue, 15 Sep 1998 11:33:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30905 for ; Tue, 15 Sep 1998 11:33:56 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA20803; Tue, 15 Sep 98 11:32:28 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09516; Tue, 15 Sep 1998 08:33:06 -0700 (PDT) To: Mishka Gorodnitzky Cc: Maciej Stachowiak , "Craig A. Struble" , scwm-discuss@mit.edu Subject: Re: A pager for scwm? References: <199809141956.PAA22233@huis-clos.mit.edu> <13822.26768.453538.473856@tor-dev1.nbc.netcom.ca> From: Greg Badros Date: 15 Sep 1998 08:33:05 -0700 In-Reply-To: Mishka Gorodnitzky's message of "Tue, 15 Sep 1998 09:16:00 -0400 (EDT)" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mishka Gorodnitzky writes: > Maciej Stachowiak writes: > ] > ] cstruble@vt.edu writes: > ] > I saw this message when using scwm-0.8 with guile-1.2 which doesn't > ] > implement basename. Updating to a guile-1.3 snapshot fixes it and a number > ] > of other strange things you see when using guile-1.2. > ] > ] Ah, there's the problem then. I'm about to commit a fix which defines > ] basename if Guile doesn't provide it. (Given that it's four trivial > ] lines, I don't think there are copyright issues.) > > Heh. I was thinking htat writing a basename might be a good way > for me to get more familiar with scheme, but I figured I might want to > check here in case there's more to just adding a basename for this > version of guile. Gosh, unfortunately Maciej already beat you to it -- see fvwm-module.scm in the repository. Please do keep looking for a project w/ scwm -- see the TODO list for a list of things that may be worth doing (always be sure to ask us, too, as the list can sometimes drift out of date, or we may have some useful ideas to get you started). > Thanks for the help, and thanks to the developers and helpers on > the scwm-discuss list for the great work on scwm. You're welcome -- thank's for your interest! Greg From owner-scwm-discuss@mit.edu Tue Sep 15 11:37:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA30976 for scwm-discuss-outgoing; Tue, 15 Sep 1998 11:37:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA30973 for ; Tue, 15 Sep 1998 11:37:07 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AB16782; Tue, 15 Sep 98 11:36:20 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA09522; Tue, 15 Sep 1998 08:36:21 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: menu side image alignment References: <19980915043741.A30014@molehill.org> From: Greg Badros Date: 15 Sep 1998 08:36:21 -0700 In-Reply-To: Todd Larason's message of "Tue, 15 Sep 1998 04:37:41 -0700" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > DON'T APPLY THIS PATCH > > At least, not until someone has given it a good looking-over. > > In menu.c, I commented out some references to scmExtraOptions. Before > I did that, my patched scwm was crashing during startup, doing a GC > mark on that field. I expect commenting it out is just masking the > problem, whatever it is. I haven't found yet what I broke, and I should > have been in bed hours ago, so I'm hoping some fresh eyes on it might > make it obvious to someone. I'm trying it now... I'll get back to you. Thanks, Greg From owner-scwm-discuss@mit.edu Tue Sep 15 12:35:59 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA31515 for scwm-discuss-outgoing; Tue, 15 Sep 1998 12:35:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA31511 for ; Tue, 15 Sep 1998 12:35:46 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12504; Tue, 15 Sep 98 12:34:15 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA09574; Tue, 15 Sep 1998 09:34:48 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: menu side image alignment References: <19980915043741.A30014@molehill.org> From: Greg Badros Date: 15 Sep 1998 09:34:43 -0700 In-Reply-To: Todd Larason's message of "Tue, 15 Sep 1998 04:37:41 -0700" Message-Id: Lines: 435 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > DON'T APPLY THIS PATCH > > At least, not until someone has given it a good looking-over. > > In menu.c, I commented out some references to scmExtraOptions. Before > I did that, my patched scwm was crashing during startup, doing a GC > mark on that field. I expect commenting it out is just masking the > problem, whatever it is. I haven't found yet what I broke, and I should > have been in bed hours ago, so I'm hoping some fresh eyes on it might > make it obvious to someone. Actually, you just needed to: cd ../doc; remake scwm.sgml And the problem would've been reported to you: .... scwm/menu.c:211:**** make_menu: argument inconsistency -- check #s of arguments .... You forgot (as I have many a time, which is why I added the warning to the extract-docs script long ago) to update the number of arguments in the make-menu primitive. I have applied this patch, and corrected that warning, and it seems to work well. Nice job! My only concern is it is not a compatible change as it throws off the other arguments to make-menu, but since that's wrapped by the `menu' procedure, it shouldn't be a big problem. (People will need to remember to reinstall from the scheme directory to get the change to the menu primitive, but this should be standard fare). Thanks for the nice addition! BTW, your comments regarding side pictures and pie menus, etc, are all valid, but I was figuring that some meaning (if slightly contorted) could be given to the options. I wanted to common case to not use extra-options. (Plus I wrote that code nearly a year ago, when scwm was a baby -- the menu system was the first guile code I wrote, and I'm not nearly as happy with it now given what I've learned in the last 12 months). I'm committing your improvement now -- please make other changes relative to the repository if possible. Thanks, Greg > > ? build-x86 > ? build-ppc > ? diff > Index: sample.scwmrc/menu-test.scm > =================================================================== > RCS file: /anoncvs/scwm/sample.scwmrc/menu-test.scm,v > retrieving revision 1.10 > diff -u -r1.10 menu-test.scm > --- menu-test.scm 1998/07/06 06:52:24 1.10 > +++ menu-test.scm 1998/09/15 11:30:36 > @@ -47,7 +47,7 @@ > (display "toggle-stick\n")) #f #f > (make-image "mini-stick.xpm") #f #f > "stick")) > - #f #f (make-color "gray80")) > + #f #f #f (make-color "gray80")) > ) > > (define more-menu-ops-item > @@ -65,7 +65,7 @@ > window-ops-title-item bitmap-separator > sticky-menu-item move-menu-item resize-menu-item > more-menu-ops-item) > - (make-image "linux-menu.xpm") (make-color "blue") > + (make-image "linux-menu.xpm") 'top (make-color "blue") > 'a-color)) > > > @@ -80,7 +80,7 @@ > (make-menu-item "Stick/Unstick" toggle-stick "" #f > (make-image "mini-stick.xpm") #f #f > "stick")) > - #f #f (make-color "gray80")) > + #f #f #f (make-color "gray80")) > ) > > ;;(popup-menu a-menu) > Index: scheme/base.scm > =================================================================== > RCS file: /anoncvs/scwm/scheme/base.scm,v > retrieving revision 1.54 > diff -u -r1.54 base.scm > --- base.scm 1998/09/13 17:41:19 1.54 > +++ base.scm 1998/09/15 11:30:39 > @@ -292,6 +292,7 @@ > > (define*-public (menu list-of-menuitems #&key > image-side > + (image-align 'top) > (color-bg-image-side 'menu-bg-color) > (image-bg #f) > (color-text 'menu-text-color) > @@ -300,11 +301,13 @@ > "Return a menu object with the given attributes. > LIST-OF-MENUITEMS is a list of menuitem objects (each created with > `make-menuitem' or `menuitem'). IMAGE-SIDE is an image object to be > -displayed along the left edge of the menu. COLOR-BG-IMAGE-SIDE is the > -background color for that image object. COLOR-TEXT is a color object > -or string for the foreground text color of menu items. COLOR-BG is a > -color object or string for the background color for the menu and menu > -items. FONT is a font object for the font of the menu items." > +displayed along the left edge of the menu. IMAGE-ALIGN determines > +whether to align that image to the 'top, 'center or 'bottom of the > +menu. COLOR-BG-IMAGE-SIDE is the background color for that image > +object. COLOR-TEXT is a color object or string for the foreground > +text color of menu items. COLOR-BG is a color object or string for > +the background color for the menu and menu items. FONT is a font > +object for the font of the menu items." > (if (string? image-side) > (set! image-side (make-image image-side))) > (if (string? color-bg) > @@ -313,7 +316,7 @@ > (set! color-text (make-color color-text))) > (if (string? color-bg-image-side) > (set! color-bg-image-side (make-color color-bg-image-side))) > - (make-menu list-of-menuitems image-side color-bg-image-side > + (make-menu list-of-menuitems image-side image-align color-bg-image-side > color-bg color-text image-bg font)) > > (define-public (image-property image key) > Index: scwm/drawmenu.c > =================================================================== > RCS file: /anoncvs/scwm/scwm/drawmenu.c,v > retrieving revision 1.27 > diff -u -r1.27 drawmenu.c > --- drawmenu.c 1998/09/03 21:34:18 1.27 > +++ drawmenu.c 1998/09/15 11:30:41 > @@ -21,6 +21,8 @@ > #include "dmalloc.h" > #endif > > +extern SCM sym_top, sym_center, sym_bottom; > + > /* FIXGJB: comment these! */ > #define MENU_EDGE_VERT_SPACING 2 > #define MENU_EDGE_HORIZ_SPACING 2 > @@ -49,8 +51,12 @@ > } > > static void > -PaintSideImage(Window w, Pixel bg, int cpixHeight, scwm_image *psimg) > +PaintSideImage(Window w, Pixel bg, int cpixHeight, scwm_image *psimg, > + SCM align) > { > + int cpixDstYoffset, cpixSrcYoffset; > + int height; > + > if (!psimg) { > scwm_msg(ERR,__FUNCTION__,"psimg is NULL"); > return; > @@ -59,9 +65,38 @@ > XFillRectangle(dpy, w, Scr.ScratchGC1, > MENU_ITEM_RR_SPACE, MENU_ITEM_RR_SPACE, > psimg->width, cpixHeight - 2*MENU_ITEM_RR_SPACE); > - DrawImage(w,psimg,MENU_ITEM_RR_SPACE,MENU_ITEM_RR_SPACE,NULL); > -} > > + height = psimg->height; > + if (height > cpixHeight - 2*MENU_ITEM_RR_SPACE) > + height = cpixHeight - 2*MENU_ITEM_RR_SPACE; > + > + if (align == sym_top) { > + cpixDstYoffset = MENU_ITEM_RR_SPACE; > + cpixSrcYoffset = 0; > + } else if (align == sym_center) { > + if (psimg->height > height) { > + cpixDstYoffset = MENU_ITEM_RR_SPACE; > + cpixSrcYoffset = (psimg->height - height)/2; > + } else { > + cpixDstYoffset = (cpixHeight - height)/2; > + cpixSrcYoffset = 0; > + } > + } else { > + if (psimg->height > height) { > + cpixDstYoffset = MENU_ITEM_RR_SPACE; > + cpixSrcYoffset = psimg->height - height; > + } else { > + cpixDstYoffset = cpixHeight - height; > + cpixSrcYoffset = 0; > + } > + } > + > + DrawSubImage(w, psimg, > + MENU_ITEM_RR_SPACE, cpixDstYoffset, > + 0, cpixSrcYoffset, > + psimg->width, height, > + NULL); > +} > > /* > * RelieveHalfRectangle - add relief lines to the sides only of a > @@ -293,7 +328,8 @@ > { /* scope */ > scwm_image *psimgSide = SAFE_IMAGE(pmd->pmenu->scmImgSide); > if (psimgSide) { > - PaintSideImage(w,pmdi->SideBGColor,pmdi->cpixHeight,psimgSide); > + PaintSideImage(w,pmdi->SideBGColor,pmdi->cpixHeight,psimgSide, > + pmd->pmenu->scmSideAlign); > } > } > XSync(dpy,0); > Index: scwm/face.c > =================================================================== > RCS file: /anoncvs/scwm/scwm/face.c,v > retrieving revision 1.42 > diff -u -r1.42 face.c > --- face.c 1998/09/07 19:30:29 1.42 > +++ face.c 1998/09/15 11:30:44 > @@ -316,11 +316,14 @@ > > void add_spec_to_face_x(SCM face, SCM spec, SCM arg); > > -/* These three symbols are also used by msicprocs.c's > - set-title-justify! */ > +/* 'left, 'right and 'center are also used by miscprocs.c's > + set-title-justify!; 'center, 'top and 'bottom are used by > + menu.c's side menu alignment */ > SCWM_GLOBAL_SYMBOL(sym_left , "left"); > SCWM_GLOBAL_SYMBOL(sym_right , "right"); > SCWM_GLOBAL_SYMBOL(sym_center , "center"); > +SCWM_GLOBAL_SYMBOL(sym_top , "top"); > +SCWM_GLOBAL_SYMBOL(sym_bottom , "bottom"); > > SCWM_SYMBOL(sym_clear , "clear"); > SCWM_SYMBOL(sym_justify , "justify"); > @@ -329,8 +332,6 @@ > SCWM_SYMBOL(sym_use_style_of , "use-style-of"); > SCWM_SYMBOL(sym_hidden_handles , "hidden-handles"); > SCWM_SYMBOL(sym_no_inset , "no-inset"); > -SCWM_SYMBOL(sym_top , "top"); > -SCWM_SYMBOL(sym_bottom , "bottom"); > SCWM_SYMBOL(sym_flat , "flat"); > SCWM_SYMBOL(sym_sunk , "sunk"); > SCWM_SYMBOL(sym_raised , "raised"); > Index: scwm/menu.c > =================================================================== > RCS file: /anoncvs/scwm/scwm/menu.c,v > retrieving revision 1.33 > diff -u -r1.33 menu.c > --- menu.c 1998/09/14 16:36:20 1.33 > +++ menu.c 1998/09/15 11:30:51 > @@ -43,6 +43,8 @@ > #include "dmalloc.h" > #endif > > +extern SCM sym_top, sym_center, sym_bottom; > + > static DynamicMenu *NewDynamicMenu(Menu *pmenu, DynamicMenu *pmdPoppedFrom); > static void PopdownMenu(DynamicMenu *pmd); > static void FreeDynamicMenu(DynamicMenu *pmd); > @@ -78,12 +80,13 @@ > > GC_MARK_SCM_IF_SET(pmenu->scmMenuItems); > GC_MARK_SCM_IF_SET(pmenu->scmImgSide); > + GC_MARK_SCM_IF_SET(pmenu->scmSideAlign); > GC_MARK_SCM_IF_SET(pmenu->scmSideBGColor); > GC_MARK_SCM_IF_SET(pmenu->scmBGColor); > GC_MARK_SCM_IF_SET(pmenu->scmTextColor); > GC_MARK_SCM_IF_SET(pmenu->scmImgBackground); > GC_MARK_SCM_IF_SET(pmenu->scmFont); > - GC_MARK_SCM_IF_SET(pmenu->scmExtraOptions); > +//XXX GC_MARK_SCM_IF_SET(pmenu->scmExtraOptions); > > return SCM_BOOL_F; > } > @@ -178,6 +181,7 @@ > return pch; > } > > +/* XXX should be assoc list? whichever, add scmSideAlign */ > SCWM_PROC(menu_properties, "menu-properties", 1, 0, 0, > (SCM menu)) > /** Returns the a list of the menu properties of MENU, a menu object. > @@ -197,20 +201,23 @@ > pmenu->scmTextColor, > pmenu->scmImgBackground, > pmenu->scmFont, > - pmenu->scmExtraOptions, > +//XXX pmenu->scmExtraOptions, > gh_str02scm(pmenu->pchUsedShortcutKeys), > SCM_UNDEFINED); > } > #undef FUNC_NAME > > > +/* XXX the side picture arguments should probably be EXTRA-OPTIONS - what's > + a 'side image' for a pie menu? */ > SCWM_PROC(make_menu, "make-menu", 1, 7, 0, > (SCM list_of_menuitems, > - SCM picture_side, SCM side_bg_color, > + SCM picture_side, SCM picture_align, SCM side_bg_color, > SCM bg_color, SCM text_color, > SCM picture_bg, SCM font, SCM extra_options)) > /** Make and return a menu object from the given arguments. > LIST-OF-MENUITEMS is a non-empty scheme list of menu items -- see `make-menuitem'; > +PICTURE-ALIGN is one of 'top, 'center, or 'bottom; > PICTURE-SIDE is an image object; > SIDE-BG-COLOR, BG-COLOR, TEXT-COLOR, PICTURE-BG are color objects; > FONT is a font object; > @@ -240,6 +247,18 @@ > pmenu->scmImgSide = picture_side; > > iarg++; > + if (UNSET_SCM(picture_align)) { > + picture_align = sym_top; > + } else if (!gh_symbol_p(picture_align) || > + (picture_align != sym_top && > + picture_align != sym_center && > + picture_align != sym_bottom)) { > + scm_misc_error(FUNC_NAME,"PICTURE-ALIGN must be 'top, 'center or 'bottom'", > + SCM_EOL); > + } > + pmenu->scmSideAlign = picture_align; > + > + iarg++; > if (UNSET_SCM(side_bg_color)) { > side_bg_color = WHITE_COLOR; > } else if (!COLOR_OR_SYMBOL_P(side_bg_color)) { > @@ -282,7 +301,7 @@ > } > pmenu->scmFont = font; > > - pmenu->scmExtraOptions = extra_options; > +//XXX pmenu->scmExtraOptions = extra_options; > > pmenu->pchUsedShortcutKeys = NULL; > > Index: scwm/menu.h > =================================================================== > RCS file: /anoncvs/scwm/scwm/menu.h,v > retrieving revision 1.11 > diff -u -r1.11 menu.h > --- menu.h 1998/08/21 20:21:32 1.11 > +++ menu.h 1998/09/15 11:30:52 > @@ -72,6 +72,7 @@ > SCM scmImgBackground; /* background image */ > SCM scmFont; /* font for labels */ > SCM scmExtraOptions; /* extra list of options for the drawing code */ > + SCM scmSideAlign; /* side image alignment */ > char *pchUsedShortcutKeys; /* list of characters that are shortcut keys */ > } Menu; > > @@ -89,7 +90,6 @@ > PfnPaintDynamicMenu fnPaintDynamicMenu; /* the function to paint the whole menu */ > PfnPaintMenuItem fnPaintMenuItem; /* the function to paint a single menu item */ > }; > - > > #define MENU_P(X) (SCM_NIMP((X)) && (gh_car((X)) == (SCM)scm_tc16_scwm_menu)) > #define MENU(X) ((Menu *)gh_cdr((X))) > Index: scwm/xmisc.c > =================================================================== > RCS file: /anoncvs/scwm/scwm/xmisc.c,v > retrieving revision 1.21 > diff -u -r1.21 xmisc.c > --- xmisc.c 1998/09/03 21:34:22 1.21 > +++ xmisc.c 1998/09/15 11:31:34 > @@ -104,23 +104,39 @@ > void > DrawImage(Window w, scwm_image *psimg, int cpixXoffset, int cpixYoffset, GC gc) > { > + DrawSubImage(w, psimg, cpixXoffset, cpixYoffset, 0, 0, psimg->width, psimg->height, gc); > +} > + > +/* Note: gc is only used for bitmaps! */ > +void > +DrawSubImage(Window w, scwm_image *psimg, > + int cpixDstXoffset, int cpixDstYoffset, > + int cpixSrcXoffset, int cpixSrcYoffset, > + int cpixWidth, int cpixHeight, > + GC gc) > +{ > if (psimg->depth > 0) { > GC gcPixmap = Scr.ScratchGC1; > /* a full pixmap (as opposed to just a bitmap) */ > Globalgcv.clip_mask = psimg->mask; > - Globalgcv.clip_x_origin = cpixXoffset; > - Globalgcv.clip_y_origin = cpixYoffset; > + Globalgcv.clip_x_origin = cpixDstXoffset; > + Globalgcv.clip_y_origin = cpixDstYoffset; > > XChangeGC(dpy,gcPixmap,(GCClipMask | GCClipXOrigin | GCClipYOrigin),&Globalgcv); > - XCopyArea(dpy, psimg->image, w, gcPixmap, 0, 0, psimg->width, psimg->height, > - Globalgcv.clip_x_origin, Globalgcv.clip_y_origin); > + XCopyArea(dpy, psimg->image, w, gcPixmap, > + cpixSrcXoffset, cpixSrcYoffset, > + cpixWidth, cpixHeight, > + cpixDstXoffset, cpixDstYoffset); > > Globalgcv.clip_mask = None; > XChangeGC(dpy,gcPixmap,(GCClipMask),&Globalgcv); > } else { > /* bitmap */ > - XCopyPlane(dpy, psimg->image, w, gc, 0, 0, psimg->width, psimg->height, > - cpixXoffset, cpixYoffset, 1 /* plane */); > + XCopyPlane(dpy, psimg->image, w, gc, > + cpixSrcXoffset, cpixSrcYoffset, > + cpixWidth, cpixHeight, > + cpixDstXoffset, cpixDstYoffset, > + 1 /* plane */); > } > } > > Index: scwm/xmisc.h > =================================================================== > RCS file: /anoncvs/scwm/scwm/xmisc.h,v > retrieving revision 1.15 > diff -u -r1.15 xmisc.h > --- xmisc.h 1998/09/01 21:30:37 1.15 > +++ xmisc.h 1998/09/15 11:31:35 > @@ -29,6 +29,11 @@ > Bool FXIsWindowMapped(Display *dpy, Window w); > > void DrawImage(Window w, scwm_image *psimg, int cpixXoffset, int cpixYoffset, GC gc); > +void DrawSubImage(Window w, scwm_image *psimg, > + int cpixDstXoffset, int cpixDstYoffset, > + int cpixSrcXoffset, int cpixSrcYOffset, > + int cpixWidth, int cpixHeight, > + GC gc); > XTextProperty *PNewXTextPropertyFromSz(const char *sz); > int flush_expose(Window w); > void RestoreWithdrawnLocation(ScwmWindow *, Bool); From owner-scwm-discuss@mit.edu Tue Sep 15 13:11:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA31894 for scwm-discuss-outgoing; Tue, 15 Sep 1998 13:11:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA31891 for ; Tue, 15 Sep 1998 13:11:35 -0400 Received: from Galois.suse.de by MIT.EDU with SMTP id AA24519; Tue, 15 Sep 98 13:10:05 EDT Received: from tieck.suse.de (Tieck.suse.de [192.168.103.11]) by Galois.suse.de (8.8.8/8.8.8) with SMTP id TAA28191 for ; Tue, 15 Sep 1998 19:10:49 +0200 Received: by tieck.suse.de id (Smail-3.2 1996-Jul-4 #1); Sun, 13 Sep 1998 20:13:39 +0200 (MEST) To: scwm-discuss@mit.edu Subject: diff files X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN) Mime-Version: 1.0 (generated by SEMI 1.8.5 - "Nishi-Takaoka") Content-Type: text/plain; charset=US-ASCII From: Karl Eichwalder Date: 13 Sep 1998 20:13:38 +0200 Message-Id: Lines: 6 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Nothing important, but please, use the diff switch "-urN". scwm-980912.diff.gz lacks xrm.h. Thanks for all your work; it's a great windowmanager! Karl From owner-scwm-discuss@mit.edu Tue Sep 15 13:21:25 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA32048 for scwm-discuss-outgoing; Tue, 15 Sep 1998 13:21:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA32044 for ; Tue, 15 Sep 1998 13:21:23 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA23518; Tue, 15 Sep 98 13:20:36 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA09657; Tue, 15 Sep 1998 10:20:32 -0700 (PDT) To: Karl Eichwalder Cc: scwm-discuss@mit.edu Subject: Re: diff files References: From: Greg Badros Date: 15 Sep 1998 10:20:30 -0700 In-Reply-To: Karl Eichwalder's message of "13 Sep 1998 20:13:38 +0200" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Karl Eichwalder writes: > Nothing important, but please, use the diff switch "-urN". > scwm-980912.diff.gz lacks xrm.h. Good point... I just added the -N option to a diff command in the cvssnapdiff of the /usr/local/bin/make-scwm-snap script -- Maciej, can you check if that looks right? > Thanks for all your work; it's a great windowmanager! You're welcome on behalf of us all... and thanks for helping to make it better! Greg From owner-scwm-discuss@mit.edu Tue Sep 15 14:08:00 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32564 for scwm-discuss-outgoing; Tue, 15 Sep 1998 14:08:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32561 for ; Tue, 15 Sep 1998 14:07:50 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA10347; Tue, 15 Sep 98 14:06:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA09701; Tue, 15 Sep 1998 11:06:51 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> From: Greg Badros Date: 15 Sep 1998 11:06:47 -0700 In-Reply-To: Francois-Rene Rideau's message of "Sun, 13 Sep 1998 23:58:17 +0200" Message-Id: Lines: 145 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi -- more responses to your email of a couple days ago. Francois-Rene Rideau writes: > COMPILATION: > At first, scwm would NOT compile correctly. I almost renounced, but then, > I remembered from times when I read scwm-discuss that by modifying config.h, > I could perhaps get it to work. Indeed, this worked. > This means that scwm could NOT autodetect features in libguile. > However, NO SINGLE DOCUMENT coming with scwm would suggest to edit config.h; > So newbies can't possibly get scwm to compile! Scary. Actually, newbies may > be prone to having guile 1.2, which may (or not) compile out-of-the-box; > still, that's no encouragement to would-be users; all the less since most > of the features could be detected by determining where libguile is, > and using nm. This is actually how I did it myself. And in case all that > is not portably doable, surely such autodetection should be added > in guile itself as a feature to help building of guile-based packages. Please do let us know what change you needed to make to config.h work for you. > BUG WITH ABSOLUTE/RELATIVE GEOMETRY: As I wrote before, I think many of these are fixed. > KEYBOARD FILTERING: Fixed. > DEFAULT CONFIGURATION: > The system.scwmrc is not usable AT ALL. > The various .scwmrc samples show that scwm has a truly great potential; > but none of them is really usable, either, > they explore a tiny part of scwm's capabilities, > and they again are very clumsy to use. > What I propose is that the default user configuration > 1) be usable (features in it may be computed/detected at compile-time, > and regenerated by super-user once in a while) > 2) include a grand tour of scwm's feature, probably as an optional > demand-loaded set of features, and perhaps even > as an interactive demonstration. It might even end up being > interactively customizable (reading/dumping standard forms in > some .scwmrc.options). I agree with your remarks, and we've recently begun discussing making system.scwmrc more useful and full-featured. There are at least two biggish rewrites pending, too, which mean it may be worth putting off the complete design of a stock configuration. You're more than welcome to contribute your .scwmrc as a move in the direction you'd like to see. > MENUS: > When there's enough power for it, it would be nice that (as an option) > menus that don't fit the space to the right of their scheduled place > would push the main menu left (which would or not go back right if the > submenu is deactivated), so you don't have to move the pointer to access > the submenu (which is *very* annoying when the pointing device is little > usable, like some touchpad or accupoint and other crappoint found on laptops). > I think that *Step does that already. This is certainly a feature of the new fvwm2 code (I know, I wrote it-- and I wasn't aware of the feature anywhere else at the time). I got a bit lazy writing the fvwm2 code but have always meant to go back and add animated menus (only so much Xlib programming a guy can stand to do at a time). > CACHEING: > a source of slowdown at startup is the detection of path, programs, > and features (which we may want to do at other moment than just startup, > particularly in persistent scwm sessions like I intend to have). > This is particularly annoying if we are to generalize detection > a la wmconfig or other; or if there are lots of NFS mounted partitions, > including unreliable ones, and detection may take a *very* long time. > In such cases, we may want to have a mechanism of "cache" of available > features, that gets explicitly refreshed. > When we have such mechanism, the "normal case" is cheap, > and we can afford doing sophisticated autodetection for the unusual case. > Autodetection may include searching PATHs and wmconfig databases; > locate(1)ing pixmaps, or using various heuristics to find their location; > and more. This would be nice, but probably should be booted to a system-wide level. We should be able to come up with a reasonable work around, but I think the caching should be turned off by default as it could be confusing to new users. Again, a specific proposal here would be most helpful! > WINDOW SIZES: > I'd like window sizes to adapt to winmgr settings. > For instance, I just do want many apps to be fullscreen > (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > depending on decoration sizes so they fit; > conversely, it should detect full-screen windows, and take appropriate > actions (like, no decoration at all, or changing window geometry > to fit the screen once decoration is there). I don't like the idea of writing to Xdefaults -- you can now write to a separate SCWM resources file, and that could prove very useful. > STANDARD KEY BINDINGS: > Maybe it's time to standardize keybindings among winmanagers? Yea, right .... that'll happen! :-) We should try to have some system that scwm configurations stick to, and an analysis of the various keybindings in use could prove helpful to figuring out some common ground. Luckily, my TheNextLevel and subsequent AnotherLevel are used by lots of RedHat folks, so there is some precedent for many of the keybindings that various .scwmrc-s use (esp. gjb.scwmrc). > Anyway, if we are to allow nice enduser-settability of key bindings, > we'd better push for a two-level setup, by which "physical" keyboard events > be translated into "logical" window-manager event, that are then interpreted. > Even Emacs somehow does it, by insisting that bindings go to "commands", > that are distinguished from other closures, and must have a printable form > (usually just a procedure name that you can look up in documentation). I've discussed some of these ideas recently (partially influenced by your message, no doubt) w.r.t the event rewrite. > NON-PORTABILITY: > Also, gjb.scwmrc as well as flux.scm make some untrue assumptions > about variable USER being defined (this is done by bash; login defines > only LOGNAME; zsh defines USERNAME). gjb.scwmrc also assumes that mail > is in /var/spool/mail; this isn't true everywere (e.g. not on Slowaris); > however, variable MAIL is defined by login, so let's use it. Thanks for pointing out these problems. I'll fix in my .scwmrc. > > MAILING-LIST: > I'm no more subscribed to the list, not because it isn't interesting > (it sure IS interesting), but because it has more volume than I can handle; > hence, please send replies to fare@tunes.org. I encourage you to stay active by reading the web archive of the list regularly, or using a mail filtering program (such as procmail). It's especially helpful to read this list if you're using the latest developers versions as things change fairly frequently. Thanks for your comments, and I hope you have time to help follow through on some of your suggestions. Thanks, Greg From owner-scwm-discuss@mit.edu Tue Sep 15 14:20:23 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32645 for scwm-discuss-outgoing; Tue, 15 Sep 1998 14:20:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32639 for ; Tue, 15 Sep 1998 14:19:52 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA18559; Tue, 15 Sep 98 14:18:13 EDT Received: (qmail 18 invoked by uid 501); 15 Sep 1998 18:18:50 -0000 Message-Id: <19980915111849.A32595@molehill.org> Date: Tue, 15 Sep 1998 11:18:49 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: menu side image alignment References: <19980915043741.A30014@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Tue, Sep 15, 1998 at 09:34:43AM -0700 X-Tom-Swifty: "My ancestor was a famous Confederate general who had an army fort named after him", Tom bragged. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980915, Greg Badros wrote: > Actually, you just needed to: > cd ../doc; remake scwm.sgml > And the problem would've been reported to you: > .... > scwm/menu.c:211:**** make_menu: argument inconsistency -- check #s of arguments > .... Thanks, I'll file that away for next time. I tried a 'make clean all', thinking it might be an inconsistency between modules, and that didn't help. > My only concern is it is not a compatible change as it throws off > the other arguments to make-menu, but since that's wrapped by the `menu' > procedure, it shouldn't be a big problem. (People will need to remember > to reinstall from the scheme directory to get the change to the menu > primitive, but this should be standard fare). I'd considered putting the new argument at the end, but it seemed to fit better where I did put it, and none of the sample scwmrcs used make-menu directly, and we're still in pre-1.0 mode, so it seemed reasonable to do it 'right' instead of 'maximally compatible'. > I'm committing your improvement now -- please make other changes > relative to the repository if possible. Thanks! From owner-scwm-discuss@mit.edu Tue Sep 15 14:23:10 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32688 for scwm-discuss-outgoing; Tue, 15 Sep 1998 14:23:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32681; Tue, 15 Sep 1998 14:23:08 -0400 Message-Id: <199809151823.OAA32681@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: diff files In-reply-to: Your message of "15 Sep 1998 10:20:30 PDT." Date: Tue, 15 Sep 1998 14:23:08 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Karl Eichwalder writes: > > > Nothing important, but please, use the diff switch "-urN". > > scwm-980912.diff.gz lacks xrm.h. > > Good point... I just added the -N option to a diff command in the > cvssnapdiff of the /usr/local/bin/make-scwm-snap script -- Maciej, can > you check if that looks right? > I didn't know about the "-N" option until now, but upon reading the man page it definitely the right thing to do. > > Thanks for all your work; it's a great windowmanager! > > You're welcome on behalf of us all... and thanks for helping to make it bette > r! > Likewise from me! - Maciej From owner-scwm-discuss@mit.edu Tue Sep 15 14:27:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32750 for scwm-discuss-outgoing; Tue, 15 Sep 1998 14:27:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA32747 for ; Tue, 15 Sep 1998 14:27:03 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17366; Tue, 15 Sep 98 14:26:15 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA10537; Tue, 15 Sep 1998 11:26:14 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: menu side image alignment References: <19980915043741.A30014@molehill.org> <19980915111849.A32595@molehill.org> From: Greg Badros Date: 15 Sep 1998 11:26:13 -0700 In-Reply-To: Todd Larason's message of "Tue, 15 Sep 1998 11:18:49 -0700" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I'd considered putting the new argument at the end, but it seemed to > fit better where I did put it, and none of the sample scwmrcs used > make-menu directly, and we're still in pre-1.0 mode, so it seemed > reasonable to do it 'right' instead of 'maximally compatible'. Exactly-- and that was the primary motivation for the `menu' wrapper instead of having users use make-menu directly. > > I'm committing your improvement now -- please make other changes > > relative to the repository if possible. > > Thanks! No thank *you*! Greg From owner-scwm-discuss@mit.edu Tue Sep 15 14:27:16 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32760 for scwm-discuss-outgoing; Tue, 15 Sep 1998 14:27:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA32755; Tue, 15 Sep 1998 14:27:14 -0400 Message-Id: <199809151827.OAA32755@huis-clos.mit.edu> To: Mishka Gorodnitzky cc: scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-reply-to: Your message of "Tue, 15 Sep 1998 09:16:00 EDT." <13822.26768.453538.473856@tor-dev1.nbc.netcom.ca> Date: Tue, 15 Sep 1998 14:27:14 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk misaka@netcom.ca writes: > Maciej Stachowiak writes: > ] > ] cstruble@vt.edu writes: > ] > I saw this message when using scwm-0.8 with guile-1.2 which doesn't > ] > implement basename. Updating to a guile-1.3 snapshot fixes it and a numbe > r > ] > of other strange things you see when using guile-1.2. > ] > ] Ah, there's the problem then. I'm about to commit a fix which defines > ] basename if Guile doesn't provide it. (Given that it's four trivial > ] lines, I don't think there are copyright issues.) > > Heh. I was thinking htat writing a basename might be a good way > for me to get more familiar with scheme, but I figured I might want to > check here in case there's more to just adding a basename for this > version of guile. > Sorry, I didn't mean to ruin your fun :-) > Thanks for the help, and thanks to the developers and helpers on > the scwm-discuss list for the great work on scwm. > Maybe we should try to be slower about fixing bugs so more people can get coding experience. - Maciej From owner-scwm-discuss@mit.edu Tue Sep 15 16:29:55 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA00997 for scwm-discuss-outgoing; Tue, 15 Sep 1998 16:29:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA00994 for ; Tue, 15 Sep 1998 16:29:47 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01448; Tue, 15 Sep 98 16:28:55 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id XAA18141 for ; Tue, 15 Sep 1998 23:28:40 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id WAA18394; Tue, 15 Sep 1998 22:28:40 +0200 To: scwm-discuss@mit.edu Subject: minimization bug - not anymore From: abel@bfr.co.il (Alexander L. Belikoff) Date: 15 Sep 1998 22:28:40 +0200 Message-Id: Lines: 10 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Current snapshot of scwm (Revision: 1.438) seems to fix the icon disappearance bug. Thanks a lot. -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 15 16:40:09 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01158 for scwm-discuss-outgoing; Tue, 15 Sep 1998 16:40:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01154 for ; Tue, 15 Sep 1998 16:40:06 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA05615; Tue, 15 Sep 98 16:39:12 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA17201; Tue, 15 Sep 1998 13:39:01 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: minimization bug - not anymore References: From: Greg Badros Date: 15 Sep 1998 13:39:00 -0700 In-Reply-To: abel@bfr.co.il's message of "15 Sep 1998 22:28:40 +0200" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Current snapshot of scwm (Revision: 1.438) seems to fix the icon > disappearance bug. Great news -- thanks! > Thanks a lot. You're welcome. :-) Greg From owner-scwm-discuss@mit.edu Tue Sep 15 16:52:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01357 for scwm-discuss-outgoing; Tue, 15 Sep 1998 16:52:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01354 for ; Tue, 15 Sep 1998 16:52:27 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA17739; Tue, 15 Sep 98 16:50:55 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA18414; Tue, 15 Sep 1998 13:51:35 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Event comments revisited From: Greg Badros Date: 15 Sep 1998 13:51:32 -0700 Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk In my comments to Maciej's comments, I realize I was a bit fuzzy on the difference between an override-map (that is used first, before any other map) and a global-map (which is the implicit parent of all maps and is used last). We need both, and I think they should be special maps w/ getters and setters. Also, having an (override-map-uninstall) might be a worthy encapsulation of common uses of the override map. Greg From owner-scwm-discuss@mit.edu Tue Sep 15 17:56:56 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01906 for scwm-discuss-outgoing; Tue, 15 Sep 1998 17:56:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01903 for ; Tue, 15 Sep 1998 17:56:53 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA02132; Tue, 15 Sep 98 17:56:02 EDT Received: by tis.bellhow.com; id RAA06985; Tue, 15 Sep 1998 17:56:06 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma006917; Tue, 15 Sep 98 17:55:14 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id RAA29045 for ; Tue, 15 Sep 1998 17:55:14 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Pager Problems Date: Tue, 15 Sep 1998 21:55:14 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <3605dc4a.707891043@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id RAA01904 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greetings! I'm using the 9/15/98 snapshot. The pager is getting better and better, but there are still some problems. Dragging a viewport around in the pager with mouse 3 will hang if the viewport touches an "edge" of the pager. After a successful drag of a viewport, no more drags are possible until a mouse 1 is clicked. Mouse 2 drags in the pager only really seem to work from viewport (0,0). If you are not in (0,0), a mouse 2 drag will put the window in the viewport above or above and left of where you dragged it. I'm not sure if it can be helped, but a shaded window appears unshaded in the pager. I didn't realize this before, but the internal pager of Fvwm is only in the 1.x versions. It's not in the 2.0.46 code that I have. I *like* the internal pager. It's small and fast without useless verbiage. :) I have figured out (from reading source) how to make the Fvwm2 pager look like the Fvmw 1.x internal pager, so if scwm never gets that mythical internal pager I won't be too disappointed. ;) Dale From owner-scwm-discuss@mit.edu Tue Sep 15 20:16:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA02716 for scwm-discuss-outgoing; Tue, 15 Sep 1998 20:16:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA02712 for ; Tue, 15 Sep 1998 20:16:26 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA12771; Tue, 15 Sep 98 20:14:48 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA26114; Tue, 15 Sep 1998 17:15:34 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Pager Problems References: <3605dc4a.707891043@smtp> From: Greg Badros Date: 15 Sep 1998 17:15:31 -0700 In-Reply-To: smithd@bellhow.com's message of "Tue, 15 Sep 1998 21:55:14 GMT" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > Greetings! > > I'm using the 9/15/98 snapshot. > > The pager is getting better and better, but there are still some problems. Good.... and bad... > > Dragging a viewport around in the pager with mouse 3 will hang if the viewport > touches an "edge" of the pager. > > After a successful drag of a viewport, no more drags are possible until a mouse 1 > is clicked. > I've noticed this, too... I'd love it if you could try to track these down and at least summarize what's going wrong... > Mouse 2 drags in the pager only really seem to work from viewport > (0,0). If you are not in (0,0), a mouse 2 drag will put the window in > the viewport above or above and left of where you dragged it. Ok, this is now fixed, as is the problem where "xv" windows showed up in the top-left viewport. > > I'm not sure if it can be helped, but a shaded window appears unshaded in the pager. I can probably fix this later... > I didn't realize this before, but the internal pager of Fvwm is only > in the 1.x versions. It's not in the 2.0.46 code that I have. I > *like* the internal pager. It's small and fast without useless > verbiage. :) I have figured out (from reading source) how to make the > Fvwm2 p> pager look like the Fvmw 1.x internal pager, so if scwm never > gets that mythical internal pager I won't be too disappointed. ;) It'll be a bit, I'd think.... glad things are pretty okay with the fvwm2 pager. Greg From owner-scwm-discuss@mit.edu Wed Sep 16 06:00:37 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA06359 for scwm-discuss-outgoing; Wed, 16 Sep 1998 06:00:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA06356 for ; Wed, 16 Sep 1998 06:00:32 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA20300; Wed, 16 Sep 98 05:59:31 EDT Received: (qmail 18020 invoked by uid 501); 16 Sep 1998 09:59:57 -0000 Message-Id: <19980916025957.A17883@molehill.org> Date: Wed, 16 Sep 1998 02:59:57 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: patches Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=1yeeQ81UyVL57Vl7 X-Mailer: Mutt 0.91i X-Tom-Swifty: "Let's play a joke on the Sun Users Group", Tom suggested. Sender: owner-scwm-discuss@mit.edu Precedence: bulk --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii menu.patch o fixes menu-test.scm to include the new side-align argument in its tests o fixes CopySubImage()'s mask handling on non-0,0-source copies. One of the tests in menu-test.scm shows a distored image without this patch tags.patch o makes a TAGS file for the scheme directory move-callback.patch o adds a call3_hooks() to match call0 through call2 o adds an 'interactive-move-new-position-hook' called in the move loop when a new position is detected, with window, newx, and newy arguments. o controls the message window position via an x,y position and an align_x, align_y multiplier pair; the upper-left corner of the message window is always at (x + align_x * window_width, y + align_y * window_height). (Scr.DisplayWidth/2, Scr.DisplayHeight/2, -.5, -.5) gives the current behavior; (0, 0, 0, 0) puts it in the upper left hand corner of the screen; (Scr.DisplayWidth, Scr.DispleyHeight, -1, -1) puts it in the lower right corner of the scren. (this is logically part of the next patch, but part of it is in move.c along with the hook calling) msg-position.patch o the rest of message position code o new funtion in base.scm unset-message-window-position! moves the message window back to the default center position o new primitive set-message-window-position! sets the x, y, align_x and align_y values Combining all these, (add-hook! interactive-move-new-position-hook (lambda (window x y) (apply set-message-window-position! (append (pointer-position) (list -.5 -1.2))))) is working fairly well for me; this centers the message window slightly above the pointer during interactive moves. There's a bit of flicer, but not too bad. Any ideas how to get rid of it? There needs to be a hook called at the end of the move, to put the window back where it normally belongs. I'll do that tomorrow night, and add the corresponding hooks for resize, unless someone beats me to it. --1yeeQ81UyVL57Vl7 Content-Type: application/x-patch Content-Disposition: attachment; filename="menu.patch" Index: sample.scwmrc/menu-test.scm =================================================================== RCS file: /anoncvs/scwm/sample.scwmrc/menu-test.scm,v retrieving revision 1.10 diff -u -r1.10 menu-test.scm --- menu-test.scm 1998/07/06 06:52:24 1.10 +++ menu-test.scm 1998/09/16 09:35:42 @@ -32,7 +32,7 @@ (display "toggle-stick\n")) #f #f (make-image "mini-stick.xpm") #f #f "stick")) - #f #f (make-color "gray80")) + #f #f #f (make-color "gray80")) ) (define b-popup-menu @@ -47,7 +47,7 @@ (display "toggle-stick\n")) #f #f (make-image "mini-stick.xpm") #f #f "stick")) - #f #f (make-color "gray80")) + #f #f #f (make-color "gray80")) ) (define more-menu-ops-item @@ -65,7 +65,7 @@ window-ops-title-item bitmap-separator sticky-menu-item move-menu-item resize-menu-item more-menu-ops-item) - (make-image "linux-menu.xpm") (make-color "blue") + (make-image "linux-menu.xpm") 'bottom (make-color "blue") 'a-color)) @@ -74,13 +74,13 @@ (define a-popup-menu (make-menu (list - (make-menu-item "Iconify/Restore" toggle-iconify "C-S-Down" #f + (make-menuitem "Iconify/Restore" toggle-iconify "C-S-Down" #f (make-image "mini-iconify.xpm") #f #f "iconify") - (make-menu-item "Stick/Unstick" toggle-stick "" #f + (make-menuitem "Stick/Unstick" toggle-stick "" #f (make-image "mini-stick.xpm") #f #f "stick")) - #f #f (make-color "gray80")) + #f #f #f (make-color "gray80")) ) ;;(popup-menu a-menu) Index: scwm/xmisc.c =================================================================== RCS file: /anoncvs/scwm/scwm/xmisc.c,v retrieving revision 1.22 diff -u -r1.22 xmisc.c --- xmisc.c 1998/09/15 16:35:27 1.22 +++ xmisc.c 1998/09/16 09:36:24 @@ -119,8 +119,8 @@ GC gcPixmap = Scr.ScratchGC1; /* a full pixmap (as opposed to just a bitmap) */ Globalgcv.clip_mask = psimg->mask; - Globalgcv.clip_x_origin = cpixDstXoffset; - Globalgcv.clip_y_origin = cpixDstYoffset; + Globalgcv.clip_x_origin = cpixDstXoffset - cpixSrcXoffset; + Globalgcv.clip_y_origin = cpixDstYoffset - cpixSrcYoffset; XChangeGC(dpy,gcPixmap,(GCClipMask | GCClipXOrigin | GCClipYOrigin),&Globalgcv); XCopyArea(dpy, psimg->image, w, gcPixmap, --1yeeQ81UyVL57Vl7 Content-Type: application/x-patch Content-Disposition: attachment; filename="tags.patch" Index: scheme/Makefile.am =================================================================== RCS file: /anoncvs/scwm/scheme/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- Makefile.am 1998/09/06 23:27:27 1.4 +++ Makefile.am 1998/09/16 09:35:44 @@ -11,3 +11,5 @@ ## Distribute only EXTRA_DIST = minimal.scm +ETAGS_ARGS = $(scwm_scheme_DATA) $(EXTRA_DIST) +TAGS_DEPENDENCIES = $(scwm_scheme_DATA) $(EXTRA_DIST) --1yeeQ81UyVL57Vl7 Content-Type: application/x-patch Content-Disposition: attachment; filename="move-callback.patch" Index: scwm/callbacks.h =================================================================== RCS file: /anoncvs/scwm/scwm/callbacks.h,v retrieving revision 1.10 diff -u -r1.10 callbacks.h --- callbacks.h 1998/09/06 20:15:36 1.10 +++ callbacks.h 1998/09/16 09:35:46 @@ -53,6 +53,7 @@ SCM call0_hooks (SCM hook); SCM call1_hooks (SCM hook_type, SCM arg); SCM call2_hooks (SCM hook_type, SCM arg1, SCM arg2); +SCM call3_hooks (SCM hook_type, SCM arg1, SCM arg2, SCM arg3); SCM apply_hooks (SCM hook_type, SCM args); SCM apply_hooks_message_only (SCM hook_type, SCM args); Index: scwm/callbacks.c =================================================================== RCS file: /anoncvs/scwm/scwm/callbacks.c,v retrieving revision 1.34 diff -u -r1.34 callbacks.c --- callbacks.c 1998/09/06 20:15:36 1.34 +++ callbacks.c 1998/09/16 09:35:46 @@ -180,6 +180,13 @@ return scwm_safe_apply (proc, gh_list(arg1, arg2, SCM_UNDEFINED)); } +SCM +scwm_safe_call3 (SCM proc, SCM arg1, SCM arg2, SCM arg3) +{ + /* This means w must cons (albeit only once) on each callback of + size two - seems lame. */ + return scwm_safe_apply (proc, gh_list(arg1, arg2, arg3, SCM_UNDEFINED)); +} /* Slightly tricky - we want to catch errors per expression, but only establish a new dynamic root per load operation, as it's perfectly @@ -352,6 +359,26 @@ for (p = hook_list; p != SCM_EOL; p = gh_cdr(p)) { scwm_safe_call2 (gh_car(p), arg1, arg2); + } + + return SCM_UNSPECIFIED; +} + +SCM call3_hooks (SCM hook, SCM arg1, SCM arg2, SCM arg3) +{ + SCM p; + SCM hook_list; + /* Ensure hook list is a list. */ + + hook_list = gh_cdr(hook); + + if (!gh_list_p(hook_list)) { + WarnBadHook(hook); + return SCM_UNSPECIFIED; + } + + for (p = hook_list; p != SCM_EOL; p = gh_cdr(p)) { + scwm_safe_call3 (gh_car(p), arg1, arg2, arg3); } return SCM_UNSPECIFIED; Index: scwm/move.c =================================================================== RCS file: /anoncvs/scwm/scwm/move.c,v retrieving revision 1.62 diff -u -r1.62 move.c --- move.c 1998/09/13 19:59:23 1.62 +++ move.c 1998/09/16 09:36:07 @@ -290,11 +292,13 @@ xl += XOffset; yt += YOffset; - if (!opaque_move) { RedrawOutlineAtNewPosition(Scr.Root, xl, yt, OutlineWidth, OutlineHeight); } - + call3_hooks(interactive_move_new_position_hook, psw->schwin, + gh_int2scm(xl + WIN_VP_OFFSET_X(psw)), + gh_int2scm(yt + WIN_VP_OFFSET_Y(psw))); + DisplayPosition(psw, xl + WIN_VP_OFFSET_X(psw), yt + WIN_VP_OFFSET_Y(psw), True); @@ -385,6 +389,9 @@ WIN_VP_OFFSET_X(psw)+xl, WIN_VP_OFFSET_Y(psw)+yt,opaque_move); } + call3_hooks(interactive_move_new_position_hook, psw->schwin, + gh_int2scm(xl + WIN_VP_OFFSET_X(psw)), + gh_int2scm(yt + WIN_VP_OFFSET_Y(psw))); DisplayPosition(psw, xl + WIN_VP_OFFSET_X(psw), yt + WIN_VP_OFFSET_Y(psw), True); Index: scwm/move.c =================================================================== RCS file: /anoncvs/scwm/scwm/move.c,v retrieving revision 1.62 diff -u -r1.62 move.c --- move.c 1998/09/13 19:59:23 1.62 +++ move.c 1998/09/16 09:36:07 @@ -177,13 +177,15 @@ MapMessageWindow() { int w, h; + int x, y; + if (!FXGetWindowSize(Scr.MsgWindow,&w,&h)) assert(False); + + x = Scr.msg_window_x + (Scr.msg_window_x_align * w); + y = Scr.msg_window_y + (Scr.msg_window_y_align * h); - /* center it onscreen */ - XMoveWindow(dpy, Scr.MsgWindow, - Scr.DisplayWidth/2 - w/2, - Scr.DisplayHeight/2 - h/2); + XMoveWindow(dpy, Scr.MsgWindow, x, y); XMapRaised(dpy, Scr.MsgWindow); } @@ -290,11 +292,13 @@ xl += XOffset; yt += YOffset; - if (!opaque_move) { RedrawOutlineAtNewPosition(Scr.Root, xl, yt, OutlineWidth, OutlineHeight); } - + call3_hooks(interactive_move_new_position_hook, psw->schwin, + gh_int2scm(xl + WIN_VP_OFFSET_X(psw)), + gh_int2scm(yt + WIN_VP_OFFSET_Y(psw))); + DisplayPosition(psw, xl + WIN_VP_OFFSET_X(psw), yt + WIN_VP_OFFSET_Y(psw), True); @@ -385,6 +389,9 @@ WIN_VP_OFFSET_X(psw)+xl, WIN_VP_OFFSET_Y(psw)+yt,opaque_move); } + call3_hooks(interactive_move_new_position_hook, psw->schwin, + gh_int2scm(xl + WIN_VP_OFFSET_X(psw)), + gh_int2scm(yt + WIN_VP_OFFSET_Y(psw))); DisplayPosition(psw, xl + WIN_VP_OFFSET_X(psw), yt + WIN_VP_OFFSET_Y(psw), True); @@ -455,19 +462,22 @@ int winwidth = textwidth + SIZE_HINDENT*2; int textheight = FONTHEIGHT(Scr.msg_window_font); int winheight = textheight + SIZE_VINDENT*2; + int win_x, win_y; + GC gcMsg = Scr.ScratchGC2; GC gcHilite = Scr.ScratchGC2; GC gcShadow = Scr.ScratchGC3; SCM scmFgRelief, scmBgRelief; scmBgRelief = adjust_brightness(Scr.msg_window_bg, message_shadow_factor); scmFgRelief = adjust_brightness(Scr.msg_window_bg, message_hilight_factor); - + SetGCFg(gcHilite,XCOLOR(scmFgRelief)); SetGCFg(gcShadow,XCOLOR(scmBgRelief)); - - XMoveResizeWindow(dpy, Scr.MsgWindow, - (Scr.DisplayWidth-winwidth)/2,(Scr.DisplayHeight-winheight)/2, - winwidth, winheight); + + win_x = Scr.msg_window_x + (Scr.msg_window_x_align * winwidth); + win_y = Scr.msg_window_y + (Scr.msg_window_y_align * winheight); + + XMoveResizeWindow(dpy, Scr.MsgWindow, win_x, win_y, winwidth, winheight); if (fRelief) { XClearWindow(dpy, Scr.MsgWindow); Index: scwm/window.c =================================================================== RCS file: /anoncvs/scwm/scwm/window.c,v retrieving revision 1.159 diff -u -r1.159 window.c --- window.c 1998/09/16 00:16:20 1.159 +++ window.c 1998/09/16 09:36:22 @@ -3901,6 +3901,10 @@ successfully grab the X server. `beep' is one example of a procedure to use here. */ + SCWM_HOOK(interactive_move_new_position_hook,"interactive-move-new-position-hook"); + /** This hook is invoked with three arguments, WINDOW, NEW_X, and NEW_Y +during an interactive move whenever the window is moved to a new location. */ + #ifndef SCM_MAGIC_SNARFER #include "window.x" #endif Index: scwm/window.h =================================================================== RCS file: /anoncvs/scwm/scwm/window.h,v retrieving revision 1.62 diff -u -r1.62 window.h --- window.h 1998/09/13 19:59:27 1.62 +++ window.h 1998/09/16 09:36:23 @@ -281,6 +281,7 @@ EXTERN SCM invalid_interaction_hook; EXTERN SCM cannot_grab_hook; +EXTERN SCM interactive_move_new_position_hook; #define WINDOWP(X) (SCM_NIMP(X) && (gh_car(X) == (SCM)scm_tc16_scwm_window)) #define WINDOW(X) ((scwm_window *)gh_cdr(X)) --1yeeQ81UyVL57Vl7 Content-Type: application/x-patch Content-Disposition: attachment; filename="msg-position.patch" Index: scheme/base.scm =================================================================== RCS file: /anoncvs/scwm/scheme/base.scm,v retrieving revision 1.55 diff -u -r1.55 base.scm --- base.scm 1998/09/15 16:39:01 1.55 +++ base.scm 1998/09/16 09:35:44 @@ -445,6 +445,10 @@ (set-edge-x-scroll! x) (set-edge-y-scroll! y)) +(define-public (unset-message-window-position!) + "Move the message window back to the default screen-center position" + (apply set-message-window-position! + (append (map (lambda (x) (/ x 2)) (display-size)) (list -.5 -.5)))) (defmacro-public scwm-user-var (sym) "Lookup sym in the scwm user variable environment. Index: scwm/resize.c =================================================================== RCS file: /anoncvs/scwm/scwm/resize.c,v retrieving revision 1.44 diff -u -r1.44 resize.c --- resize.c 1998/09/11 22:46:48 1.44 +++ resize.c 1998/09/16 09:36:08 @@ -81,7 +81,42 @@ } #undef FUNC_NAME +SCWM_PROC(set_message_window_position_x, "set-message-window-position!", 4, 0, 0, + (SCM x, SCM y, SCM x_align, SCM y_align)) + /** Set the position to be used for the message window. +*/ +#define FUNC_NAME s_set_message_window_position_x +{ + SCM_REDEFER_INTS; + if (!gh_number_p(x)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 1, x); + } + if (!gh_number_p(y)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 2, y); + } + if (!gh_number_p(x_align)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 3, x_align); + } + if (!gh_number_p(y)) { + gh_allow_ints(); + scm_wrong_type_arg(FUNC_NAME, 4, y_align); + } + + Scr.msg_window_x = gh_scm2long(x); + Scr.msg_window_y = gh_scm2long(y); + Scr.msg_window_x_align = gh_scm2double(x_align); + Scr.msg_window_y_align = gh_scm2double(y_align); + + SCM_REALLOW_INTS; + + XMoveWindow(dpy, Scr.MsgWindow, x, y); + return SCM_UNDEFINED; +} +#undef FUNC_NAME SCWM_PROC (display_message, "display-message", 1, 0, 0, (SCM msg)) Index: scwm/screen.h =================================================================== RCS file: /anoncvs/scwm/scwm/screen.h,v retrieving revision 1.38 diff -u -r1.38 screen.h --- screen.h 1998/09/08 17:58:46 1.38 +++ screen.h 1998/09/16 09:36:08 @@ -233,6 +233,10 @@ SCM msg_window_font; /* font for the size/position window */ SCM msg_window_fg; /* fg color for the size/position window */ SCM msg_window_bg; /* bg color for the size/position window */ + int msg_window_x; /* x position of the size/position window */ + int msg_window_y; /* y position of the size/position window */ + double msg_window_x_align; /* offset msg window by multiple of size */ + double msg_window_y_align; /* offset msg window by multiple of size */ GC MenuGC; GC MenuStippleGC; Index: scwm/scwm.c =================================================================== RCS file: /anoncvs/scwm/scwm/scwm.c,v retrieving revision 1.126 diff -u -r1.126 scwm.c --- scwm.c 1998/09/14 01:56:58 1.126 +++ scwm.c 1998/09/16 09:36:12 @@ -312,6 +312,10 @@ Scr.msg_window_font = make_font(str_fixed); Scr.msg_window_fg = BLACK_COLOR; Scr.msg_window_bg = WHITE_COLOR; + Scr.msg_window_x = Scr.DisplayWidth/2; + Scr.msg_window_y = Scr.DisplayHeight/2; + Scr.msg_window_x_align = -.5; + Scr.msg_window_y_align = -.5; Scr.MenuColors.bg = SCM_UNDEFINED; Scr.DefaultDecor.HiColors.bg = SCM_UNDEFINED; --1yeeQ81UyVL57Vl7-- From owner-scwm-discuss@mit.edu Wed Sep 16 11:31:19 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA08050 for scwm-discuss-outgoing; Wed, 16 Sep 1998 11:31:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA08041 for ; Wed, 16 Sep 1998 11:31:14 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA22792; Wed, 16 Sep 98 11:29:14 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA14332; Wed, 16 Sep 1998 08:30:13 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: patches References: <19980916025957.A17883@molehill.org> From: Greg Badros Date: 16 Sep 1998 08:30:08 -0700 In-Reply-To: Todd Larason's message of "Wed, 16 Sep 1998 02:59:57 -0700" Message-Id: Lines: 96 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > --1yeeQ81UyVL57Vl7 > Content-Type: text/plain; charset=us-ascii > > menu.patch > o fixes menu-test.scm to include the new side-align argument in its tests Note that I moved menu-test.scm into scheme/tests. > o fixes CopySubImage()'s mask handling on non-0,0-source copies. One of > the tests in menu-test.scm shows a distored image without this patch Good. > > tags.patch > o makes a TAGS file for the scheme directory Great. > > move-callback.patch > o adds a call3_hooks() to match call0 through call2 > o adds an 'interactive-move-new-position-hook' called in the move loop > when a new position is detected, with window, newx, and newy arguments. > o controls the message window position via an x,y position and an > align_x, align_y multiplier pair; the upper-left corner of the > message window is always at > (x + align_x * window_width, y + align_y * window_height). > (Scr.DisplayWidth/2, Scr.DisplayHeight/2, -.5, -.5) gives the current > behavior; (0, 0, 0, 0) puts it in the upper left hand corner of the > screen; > (Scr.DisplayWidth, Scr.DispleyHeight, -1, -1) puts it in the lower > right corner of the scren. > (this is logically part of the next patch, but part of it is in move.c > along with the hook calling) Nice abstraction -- we might need a scheme wrapper to make the common cases more obvious. > msg-position.patch > o the rest of message position code > o new funtion in base.scm unset-message-window-position! moves the message > window back to the default center position > o new primitive set-message-window-position! sets the x, y, align_x and > align_y values Good. > Combining all these, > > (add-hook! interactive-move-new-position-hook > (lambda (window x y) > (apply set-message-window-position! > (append (pointer-position) (list -.5 -1.2))))) > > is working fairly well for me; this centers the message window slightly > above the pointer during interactive moves. There's a bit of flicer, but > not too bad. Any ideas how to get rid of it? I might have some ideas after I get to actually play with the code. Generally happens because of a delay in processing an expose event, but I might be able to tell better by looking at it. > There needs to be a hook called at the end of the move, to put the window > back where it normally belongs. I'll do that tomorrow night, and add the > corresponding hooks for resize, unless someone beats me to it. These patches look great-- please feel free to commit them (or, if you prefer, wait until you have the resize version done, too). It may be worth using a hook at the beginning of moves and resizes, too, for symmetry. Also, a couple of general comments (will be checked in under doc/dev/new-devs): o the first line of a doc string should be a brief synopsis sentence. This is in keeping with Emacs tradition, and the synopses are used in overviews and treated slightly specially in places. o be sure to mention all formal argument names in the doc string; in particular, running "rm -f scwm.sgml; make scwm.sgml" from doc/ will verify that this has been done (tries to ensure reasonably complete documentation -- minimally users need to know what each formal is supposed to contain... those descriptions usually come after the synopsis line). o when you do check in, be sure to add a change log entry. Emacs has add-change-log-entry which works great if you use it from the file and function in which you made the change. If you're not using pcl-cvs mode to do your CVS updates, consider it -- it works pretty well, and is a lot nicer than the command line or even the vc-mode keybindings. Thanks, Todd! Greg From owner-scwm-discuss@mit.edu Wed Sep 16 14:20:38 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA09227 for scwm-discuss-outgoing; Wed, 16 Sep 1998 14:20:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA09224 for ; Wed, 16 Sep 1998 14:20:33 -0400 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA25499; Wed, 16 Sep 98 14:18:31 EDT Received: from ZengHe.enst.fr (zenghe.issy.cnet.fr [139.100.250.71]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id SWVN2W10; Wed, 16 Sep 1998 20:19:39 +0200 Received: (from fare@localhost) by ZengHe.enst.fr (8.8.7/) id UAA03310; Wed, 16 Sep 1998 20:25:46 +0200 Message-Id: <19980916202545.A3249@ZengHe.issy> Date: Wed, 16 Sep 1998 20:25:45 +0200 From: Francois-Rene Rideau To: scwm-discuss@mit.edu Subject: Re: scwm user report Reply-To: Francois-Rene Rideau References: <19980913235817.A5618@ZengHe.issy.cnet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Greg Badros on Sun, Sep 13, 1998 at 07:29:45PM -0700 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.enst.fr id UAA03310 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id OAA09225 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Because one shouldn't have to. Please report this as a bug -- see > BUG-REPORTING... what did you have to change in config.h? We need to > fix this. I had to change every single guile-version-dependent feature. I had a recent guile snapshot, but config.h was for guile 1.2. > Perhaps -- you should make a proposal to their mailing list. I think a > large fraction of the build problems will go away when guile-1.3 comes > out since we can completely ignore -1.2. After 1.3, there'll be 1.4; guile will always be a moving target; so they'd better add easy feature detection... > I need a changed.c revision number to tell if these are relevant any > longer-- char *szRepoLastChanged = "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $"; ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Anyone who goes to a psychiatrist ought to have his head examined. -- Samuel Goldwyn From owner-scwm-discuss@mit.edu Wed Sep 16 14:50:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA09422 for scwm-discuss-outgoing; Wed, 16 Sep 1998 14:50:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA09419 for ; Wed, 16 Sep 1998 14:50:27 -0400 Received: from tor-dev1.nbc.netcom.ca by MIT.EDU with SMTP id AA16736; Wed, 16 Sep 98 14:49:27 EDT Received: (from misaka@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) id OAA09799; Wed, 16 Sep 1998 14:49:16 -0400 (EDT) From: Mishka Gorodnitzky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13824.2091.780869.447195@tor-dev1.nbc.netcom.ca> Date: Wed, 16 Sep 1998 14:49:15 -0400 (EDT) To: Maciej Stachowiak Cc: Mishka Gorodnitzky , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: <199809151827.OAA32755@huis-clos.mit.edu> References: <13822.26768.453538.473856@tor-dev1.nbc.netcom.ca> <199809151827.OAA32755@huis-clos.mit.edu> X-Mailer: VM 6.53 under 20.4 "Emerald" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: ] [...] ] Maybe we should try to be slower about fixing bugs so more people can ] get coding experience. Certainly a valiant sacrifice, but perhaps not a good idea. I'm sure there is a lot of work to be done anyway, and I could always write a basename function for my own curiousity on my own, without _having_ to contribute. -- Mishka From owner-scwm-discuss@mit.edu Wed Sep 16 14:53:44 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA09452 for scwm-discuss-outgoing; Wed, 16 Sep 1998 14:53:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA09449 for ; Wed, 16 Sep 1998 14:53:43 -0400 Received: from tor-dev1.nbc.netcom.ca by MIT.EDU with SMTP id AA18066; Wed, 16 Sep 98 14:52:44 EDT Received: (from misaka@localhost) by tor-dev1.nbc.netcom.ca (8.8.8/8.8.8) id OAA09808; Wed, 16 Sep 1998 14:52:40 -0400 (EDT) From: Mishka Gorodnitzky Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13824.2296.28632.537243@tor-dev1.nbc.netcom.ca> Date: Wed, 16 Sep 1998 14:52:40 -0400 (EDT) To: Greg Badros Cc: Mishka Gorodnitzky , scwm-discuss@mit.edu Subject: Re: A pager for scwm? In-Reply-To: References: <199809141956.PAA22233@huis-clos.mit.edu> <13822.26768.453538.473856@tor-dev1.nbc.netcom.ca> X-Mailer: VM 6.53 under 20.4 "Emerald" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: [...] ] Gosh, unfortunately Maciej already beat you to it -- see fvwm-module.scm ] in the repository. Please do keep looking for a project w/ scwm -- see ] the TODO list for a list of things that may be worth doing (always be ] sure to ask us, too, as the list can sometimes drift out of date, or we ] may have some useful ideas to get you started). Thanks, I'll check that out. As it is, I've sort of got my hands full with this NewtonScript telnet app I'm working on, but I'll certainly keep my eyes open around scwm. -- Mishka From owner-scwm-discuss@mit.edu Wed Sep 16 15:46:29 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA09792 for scwm-discuss-outgoing; Wed, 16 Sep 1998 15:46:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA09789 for ; Wed, 16 Sep 1998 15:46:20 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA26246; Wed, 16 Sep 98 15:44:17 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA17530; Wed, 16 Sep 1998 12:45:05 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980916202545.A3249@ZengHe.issy> From: Greg Badros Date: 16 Sep 1998 12:45:04 -0700 In-Reply-To: Francois-Rene Rideau's message of "Wed, 16 Sep 1998 20:25:45 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > > Because one shouldn't have to. Please report this as a bug -- see > > BUG-REPORTING... what did you have to change in config.h? We need to > > fix this. > I had to change every single guile-version-dependent feature. > I had a recent guile snapshot, but config.h was for guile 1.2. Hmmm... configure gets this right for me, and many others. Are you sure you didn't have guile-1.2 lying around and configure was using that instead? > > Perhaps -- you should make a proposal to their mailing list. I think a > > large fraction of the build problems will go away when guile-1.3 comes > > out since we can completely ignore -1.2. > After 1.3, there'll be 1.4; guile will always be a moving target; > so they'd better add easy feature detection... I agree-- it'd be a great thing to bring up on their list to get in place before 1.3 comes out. > > I need a changed.c revision number to tell if these are relevant any > > longer-- > char *szRepoLastChanged = "Thu Sep 10 19:02:40 EDT 1998 -- $Revision: 1.378 $"; I think yesterday I took care of the last of the bugs you mentioned. If it's not so, please send another report. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Sep 17 02:11:40 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA13153 for scwm-discuss-outgoing; Thu, 17 Sep 1998 02:11:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA13150 for ; Thu, 17 Sep 1998 02:11:36 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA15970; Thu, 17 Sep 98 02:09:18 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id XAA04367 for ; Wed, 16 Sep 1998 23:10:34 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15944>; Wed, 16 Sep 1998 23:07:03 -0700 To: scwm-discuss@mit.edu Subject: Re: Another max/min bug. In-Reply-To: Your message of "15 Sep 1998 09:51:49 +0200." Date: Wed, 16 Sep 1998 23:06:54 -0600 From: Ken Pizzini Message-Id: <19980917060703Z276516-15944+189@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein wrote: > Toggling off maximize switches back to the original size in pixels, > not the original size in rows & columns. This is a bug for windows > that resize in rows & columns - text windows such as emacs & xterms. Okay; here is another attempt at gettin maximize/unmaximize right... (diff relative to a cvs co with changed.c at revision 1.454) Change in English: place in the "original size" positions of the 'maximized object property the original size in client units during maximize. During unmaximize, use the current window-size-hints to convert the client units to the pixels required by resize-window. --Ken Pizzini --- winops.scm-orig Wed Sep 16 09:01:10 1998 +++ winops.scm Wed Sep 16 22:49:44 1998 @@ -96,16 +96,19 @@ (make-toggling-winop icon-sticky? unstick-icon stick-icon)) (define*-public (maximize nw nh #&optional (win (get-window))) - "Maximize WIN to new width NW and new height NH. + "Maximize WIN to new pixel width NW and new pixel height NH. If NW or NH is 0, that dimension is not changed." (if win (let* ((pos (window-viewport-position win)) - (size (window-frame-size win)) (x (car pos)) (y (cadr pos)) - (width (car size)) - (height (cadr size))) - (resize-frame-to (if (> nw 0) nw width) - (if (> nh 0) nh height) win) + (frame-size (window-frame-size win)) + (pix-width (car frame-size)) + (pix-height (cadr frame-size)) + (cli-size (window-size win)) + (cli-width (caddr cli-size)) + (cli-height (cadddr cli-size))) + (resize-frame-to (if (> nw 0) nw pix-width) + (if (> nh 0) nh pix-height) win) ;; above is just a hint, get the actual... ;; FIXGJB: race condition? (let* ((new-size (window-frame-size win)) @@ -121,30 +124,36 @@ (#t 0)))) (move-window-viewport-position nx ny win) (if (not (maximized? win)) - (set-object-property! win 'maximized - (list x y width height nx ny))))))) + (set-object-property! + win 'maximized (list x y cli-width cli-height nx ny))))))) (define*-public (maximized? #&optional (win (get-window))) "Return #t if WIN is maximized, #f otherwise." (->bool (object-property win 'maximized))) -;; FIXGJB: use client units (define*-public (unmaximize #&optional (win (get-window))) - "Unmaximize WIN so it returns to its size/position before maximization. -This should use client units, but currently uses frame-size in pixels." - (if win (let* ((max-prop (object-property win 'maximized)) - (pos (window-viewport-position win)) - (cur-x (car pos)) - (cur-y (cadr pos))) - (cond - (max-prop - (let ((maxed-x (car (cddddr max-prop))) - (maxed-y (cadr (cddddr max-prop)))) - (if (and (= cur-x maxed-x) (= cur-y maxed-y)) - (move-window-viewport-position (car max-prop) (cadr max-prop) win)) - (resize-frame-to (caddr max-prop) (cadddr max-prop) win) - (set-object-property! win 'maximized #f))))))) + "Unmaximize WIN so it returns to its size/position before maximization." + (if win (let ((max-prop (object-property win 'maximized))) + (cond + (max-prop + (let* ((maxed-dims (cddddr max-prop)) + (maxed-x (car maxed-dims)) + (maxed-y (cadr maxed-dims)) + (cur-pos (window-viewport-position win)) + (cur-x (car cur-pos)) + (cur-y (cadr cur-pos)) + (size-hints (cddr (window-size-hints win)))) + (if (and (= cur-x maxed-x) (= cur-y maxed-y)) + (move-window-viewport-position + (car max-prop) (cadr max-prop) win)) + (resize-window + (+ (* (caddr max-prop) (caar size-hints)) + (caadr size-hints)) + (+ (* (cadddr max-prop) (cdar size-hints)) + (cdadr size-hints)) + win) + (set-object-property! win 'maximized #f))))))) (define-public (window-frame-area win) From owner-scwm-discuss@mit.edu Thu Sep 17 03:42:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA14392 for scwm-discuss-outgoing; Thu, 17 Sep 1998 03:42:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA14389 for ; Thu, 17 Sep 1998 03:42:03 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA03991; Thu, 17 Sep 98 03:40:54 EDT Received: (qmail 30182 invoked by uid 501); 17 Sep 1998 07:41:19 -0000 Message-Id: <19980917004118.A30141@molehill.org> Date: Thu, 17 Sep 1998 00:41:18 -0700 From: Todd Larason To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I used to work for Kelly Services", Tom extemporized. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I need this patch to make tonight's cvs tree work well for me. Without it, netscape windows flash open then move to different viewports. the scwm.c part may need a little fuzz to apply. the events.c change was made today evidentally because of a similar problem with xv; the patched version seems fine with my xv, but I may have broken another version or something. Index: scwm/events.c =================================================================== RCS file: /anoncvs/scwm/scwm/events.c,v retrieving revision 1.109 diff -u -r1.109 events.c --- events.c 1998/09/16 00:16:19 1.109 +++ events.c 1998/09/17 07:33:02 @@ -1443,8 +1443,9 @@ } /* Don't modify frame_XXX fields before calling SetupWindow! */ - x = FRAME_X(pswCurrent); - y = FRAME_Y(pswCurrent); + x = FRAME_X_VP(pswCurrent); + y = FRAME_Y_VP(pswCurrent); + DBUG_RESIZE((DBG,__FUNCTION__, "FRAME_Y() = %d\n", y)); width = FRAME_WIDTH(pswCurrent); height = FRAME_HEIGHT(pswCurrent); @@ -1456,8 +1457,10 @@ if (cre->value_mask & CWX) x = cre->x - pswCurrent->boundary_width - pswCurrent->bw; - if (cre->value_mask & CWY) + if (cre->value_mask & CWY) { y = cre->y - pswCurrent->boundary_width - pswCurrent->title_height - pswCurrent->bw; + DBUG_RESIZE((DBG,__FUNCTION__, "CWY set, new y = %d\n", y)); + } if (cre->value_mask & CWWidth) width = cre->width + 2 * pswCurrent->boundary_width; Index: scwm/scwm.c =================================================================== RCS file: /anoncvs/scwm/scwm/scwm.c,v retrieving revision 1.128 diff -u -r1.128 scwm.c --- scwm.c 1998/09/16 22:56:54 1.128 +++ scwm.c 1998/09/17 07:33:35 @@ -1169,7 +1173,7 @@ unsigned int mask; /* Undo gravity adjustments. */ xwc.x = FRAME_X_VP(psw) - GRAV_X_ADJUSTMENT(psw); - xwc.y = FRAME_X_VP(psw) - GRAV_Y_ADJUSTMENT(psw); + xwc.y = FRAME_Y_VP(psw) - GRAV_Y_ADJUSTMENT(psw); xwc.border_width = psw->old_bw; mask = (CWX | CWY | CWBorderWidth); Index: scwm/window.c =================================================================== RCS file: /anoncvs/scwm/scwm/window.c,v retrieving revision 1.160 diff -u -r1.160 window.c --- window.c 1998/09/16 22:35:20 1.160 +++ window.c 1998/09/17 07:33:45 @@ -867,8 +867,8 @@ Bool FIsPartiallyInViewport(const ScwmWindow *psw) { - return ! (((FRAME_X_VP(psw) + FRAME_HEIGHT(psw)) < 0) || - (FRAME_Y_VP(psw) + FRAME_WIDTH(psw) < 0) || + return ! (((FRAME_X_VP(psw) + FRAME_WIDTH(psw)) < 0) || + (FRAME_Y_VP(psw) + FRAME_HEIGHT(psw) < 0) || (FRAME_X_VP(psw) > Scr.DisplayWidth) || (FRAME_Y_VP(psw) > Scr.DisplayHeight)); } From owner-scwm-discuss@mit.edu Thu Sep 17 08:04:13 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA15384 for scwm-discuss-outgoing; Thu, 17 Sep 1998 08:04:13 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA15381 for ; Thu, 17 Sep 1998 08:04:09 -0400 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA22837; Thu, 17 Sep 98 08:03:01 EDT Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id IAA09955 for ; Thu, 17 Sep 1998 08:10:09 -0400 (EDT) Received: from quirk.struble.c (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id IAA10884 for ; Thu, 17 Sep 1998 08:03:05 -0400 (EDT) Received: from localhost (cstruble@localhost) by quirk.struble.c (8.8.8/8.8.7) with SMTP id IAA24710 for ; Thu, 17 Sep 1998 08:03:05 -0400 (EDT) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Thu, 17 Sep 1998 08:03:04 -0400 (EDT) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Icon/Pager bug Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Well another small bug with scwm and the fvwm pager. I have a sticky icon that always appears on the first desktop in the pager even when I change desktops (shows up fine on the screen though). The viewport seems to change appropriately, although always on the first desktop. Here's changed.c: char *szRepoLastChanged = "Wed Sep 16 18:57:41 EDT 1998 -- $Revision: 1.454 $"; On a brighter note, I somehow managed to remove whatever was causing my window sizing problems from my .scwmrc. However, I was removing so much at once, I couldn't pinpoint what it was that did it. I'm going to go back and see if I can track things down, but it might be this weekend before I get to it. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Thu Sep 17 11:39:03 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16247 for scwm-discuss-outgoing; Thu, 17 Sep 1998 11:39:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA16241 for ; Thu, 17 Sep 1998 11:38:58 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA25404; Thu, 17 Sep 98 11:36:27 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20324; Thu, 17 Sep 1998 08:37:49 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: none References: <19980917004118.A30141@molehill.org> From: Greg Badros Date: 17 Sep 1998 08:37:47 -0700 In-Reply-To: Todd Larason's message of "Thu, 17 Sep 1998 00:41:18 -0700" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I need this patch to make tonight's cvs tree work well for me. Without it, > netscape windows flash open then move to different viewports. > > the scwm.c part may need a little fuzz to apply. > > the events.c change was made today evidentally because of a similar > problem with xv; the patched version seems fine with my xv, but I may > have broken another version or something. Excellent changes.... thanks for all these great fixes... I'll make these changes in the repo (giving you credit, of course) since you're still waiting for access (hopefully not much longer). Thanks! Greg From owner-scwm-discuss@mit.edu Thu Sep 17 11:52:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16374 for scwm-discuss-outgoing; Thu, 17 Sep 1998 11:52:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA16371 for ; Thu, 17 Sep 1998 11:52:28 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03278; Thu, 17 Sep 98 11:51:16 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id SAA02682 for ; Thu, 17 Sep 1998 18:51:15 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id RAA32127; Thu, 17 Sep 1998 17:51:14 +0200 To: scwm-discuss@mit.edu Subject: more 'changing icon' and window positioning bugs From: abel@bfr.co.il (Alexander L. Belikoff) Date: 17 Sep 1998 17:51:14 +0200 Message-Id: Lines: 47 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi everybody, Usual mantra first: - scwm Wed Sep 16 18:57:41 EDT 1998 -- $Revision: 1.454 $ - guile 19980806 - RedHat 4.2 (libc5) First of all, window positioning code seems to be broken again. One of the application s I'm using has it's window jump past the right screen edge whenever it tries to do a certain operation (to bring up some kind of "popup window", which is not strictly an X window - just an emulation). Another problem, which is quite old, is the one about icons, changing its contents. Again, one application I'm using changes it's icon back and forth, creating a blink effect whenever mail arrives. The application's windows is located on top right screen. While the icon is "quiet', there is no problem - I have sticky icons, so I am able to see it from any virtual screen. However, once it starts blinking, the following bizarre effect is observed: - on top right (original) screen and on bottom right one, the icon blinks normally - on left screens however, the icon disappears upon its first attempt to change it's contents - once I switch to one of the right screens, the icon appears again and blinks normally. In both cases I am talking about a proprietary application, therefore I am not able to create a reliable demonstration test case. The icon bug may be probably reproduced by using some other application with icon changing its contents (any ideas which one?) Regards, PS. And *PLEASE* tell me how to change the behaviour of de-iconifying a window to it's original screen. I want it to be restored on the current one. Thanks. -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Thu Sep 17 12:18:45 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA16794 for scwm-discuss-outgoing; Thu, 17 Sep 1998 12:18:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA16791 for ; Thu, 17 Sep 1998 12:18:38 -0400 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA12575; Thu, 17 Sep 98 12:17:27 EDT Received: from ZengHe.enst.fr (ZENGHE [139.100.161.87]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id SWVN29WW; Thu, 17 Sep 1998 18:17:17 +0200 Received: (from fare@localhost) by ZengHe.enst.fr (8.8.7/) id MAA10618; Thu, 17 Sep 1998 12:37:53 +0200 Message-Id: <19980917123752.A10380@ZengHe.issy> Date: Thu, 17 Sep 1998 12:37:52 +0200 From: Francois-Rene Rideau To: scwm-discuss@mit.edu Subject: Re: scwm user report Reply-To: Francois-Rene Rideau References: <19980913235817.A5618@ZengHe.issy.cnet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: <19980913235817.A5618@ZengHe.issy.cnet.fr>; from Francois-Rene Rideau on Sun, Sep 13, 1998 at 11:58:17PM +0200 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.enst.fr id MAA10618 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA16792 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dear developers, here is a new report, since I upgraded to the 19980916 snapshot [BTW, there was no scwm-icons-19980916 available on huis-clos]. > BUG WITH ABSOLUTE/RELATIVE GEOMETRY: It looks like they are fixed in 19980916 (a five day period!). > KEYBOARD FILTERING: Ok, X-synthetic-send-string seems *partly* fixed now (send-string is unbound; is X-synthetic-send-string its replacement???). At least it sends letters in the window, but if I try non-letter characters (such as ":~/.", as found in URLs), I get messages like: [Scwm][send-key-press]: <> No symbol `:' [Scwm][send-key-press]: <> Bad keysym `:' not sent so non-letters are filtered out. I can't remember how 0.5 behaved, but at least this is wrong. Also, does anyone know how to enable send-string for XEmacs? Is there at least one wordprocessor that will accept them? And is it possible to filter sequences of keys, instead of combinations? Looks at least doable by having the key binders have some memory. Would it be doable outside of the window-manager, so as to be wm-independent? [Full story: I want to enable my mom to use vietnamese on a wordprocessor on Linux, so as to get definitely rid of Losedoze] > DEFAULT CONFIGURATION: I admit I'm not proficient enough to help (yet) much about writing a full-featured system.scwmrc (I only know a tiny part of scwm's features), but if I can do anything, I'm willing... > CACHEING: Maybe we should build an API for cacheing of objects in a path (.xpm, executables, wmconfig, etc). Cache invalidation may be done either explicitly, or by detecting directory modification date... > WINDOW SIZES: > I'd like window sizes to adapt to winmgr settings. > For instance, I just do want many apps to be fullscreen > (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > depending on decoration sizes so they fit; > conversely, it should detect full-screen windows, and take appropriate > actions (like, no decoration at all, or changing window geometry > to fit the screen once decoration is there). I didn't mean "modify the .Xdefaults", but just "dynamically change the resource database" (e.g. echo "foo: bar" |xrdb). > STANDARD KEY BINDINGS: If you can do that, you're just great! > MAILING-LIST: Hum. After all, perhaps I'll stay "mostly subscribed" to have my localhost as mail archive, instead of having to access the web archive only when connected... PS to Maciej: Is Olin Shivers aware of SCWM? Is he using it? If you see him, say "hi!" on my behalf. ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Some people will argue that since there's no evidence either way whether the smurf fboinks or not, it's ok to firmly believe that indeed it does. Such people are insane, often as the result of a life-long endoctrination. From owner-scwm-discuss@mit.edu Thu Sep 17 12:32:04 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA16984 for scwm-discuss-outgoing; Thu, 17 Sep 1998 12:32:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA16973 for ; Thu, 17 Sep 1998 12:31:51 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16989; Thu, 17 Sep 98 12:30:19 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA30460; Thu, 17 Sep 1998 18:29:56 +0200 To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Sep 1998 18:29:55 +0200 In-Reply-To: Francois-Rene Rideau's message of "Thu, 17 Sep 1998 12:37:52 +0200" Message-Id: Lines: 38 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > > KEYBOARD FILTERING: > Ok, X-synthetic-send-string seems *partly* fixed now > (send-string is unbound; is X-synthetic-send-string its replacement???). > At least it sends letters in the window, but if I try non-letter characters > (such as ":~/.", as found in URLs), I get messages like: > [Scwm][send-key-press]: <> No symbol `:' > [Scwm][send-key-press]: <> Bad keysym `:' not sent > so non-letters are filtered out. I can't remember how 0.5 behaved, > but at least this is wrong. Why not use send-key-press? Evidentally the above is not mapping all characters to their corresponding X names. I do: (define (send-string m b) (for-each (lambda (c) (send-key-press (x-char c) b)) (string->list m))) (define (x-char c) (case c ((#\space) "space") ((#\newline) "Return") ((#\tab) "Tab") ((#\*) "S-8") (else (make-string 1 c)))) for example. > Also, does anyone know how to enable send-string for XEmacs? > Is there at least one wordprocessor that will accept them? Emacs does. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Sep 17 13:55:34 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA17822 for scwm-discuss-outgoing; Thu, 17 Sep 1998 13:55:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA17819 for ; Thu, 17 Sep 1998 13:55:27 -0400 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA15361; Thu, 17 Sep 98 13:52:54 EDT Received: from ZengHe.enst.fr (ZENGHE [139.100.161.88]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id SWVN20L3; Thu, 17 Sep 1998 19:54:19 +0200 Received: (from fare@localhost) by ZengHe.enst.fr (8.8.7/) id UAA17375; Thu, 17 Sep 1998 20:00:13 +0200 Message-Id: <19980917200010.A17354@ZengHe.issy> Date: Thu, 17 Sep 1998 20:00:10 +0200 From: Francois-Rene Rideau To: scwm-discuss@mit.edu Subject: Re: scwm user report Reply-To: Francois-Rene Rideau References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: ; from Harvey J. Stein on Thu, Sep 17, 1998 at 06:29:55PM +0200 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.enst.fr id UAA17375 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id NAA17820 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Why not use send-key-press? Evidentally the above is not mapping all > characters to their corresponding X names. I do: > > (define (send-string m b) > (for-each (lambda (c) (send-key-press (x-char c) b)) > (string->list m))) > > (define (x-char c) > (case c > ((#\space) "space") > ((#\newline) "Return") > ((#\tab) "Tab") > ((#\*) "S-8") > (else (make-string 1 c)))) > > for example. Ouch! First, my keyboard mapping is a french one; second, if I want to redistribute the program, it had better be keyboard-mapping independent. What if I wanna send a symbol that's not mapped? [Particularly true with vietnamese characters]. I guess I could define "hidden" mappings in an unreachable part of the keymap and send those keys (real PITA). X looks to me like it **really** sucks. >> Also, does anyone know how to enable send-string for XEmacs? >> Is there at least one wordprocessor that will accept them? > > Emacs does. Those were independent questions. 1) my XEmacs setup refuses X-synthetic-send-string stuff 2) XEmacs is not a wordprocessor; plus there is already MULE for Vietnamese input. But my mom sometimes has to read and write documents readable by LoseWord, yet having viet fonts. Doable with LoseWord, but not (yet?) with Emacs... [BTW, I saw that there is a forms-mode, but it's a long way to a usable database interface for my mom. Does anyone know of a database engine that I could interface to XEmacs or Netscape?] ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## As long as software is not free, we'll have hardware compatibility, hence bad, expensive, hardware that has decades-long obsolete design -- Faré From owner-scwm-discuss@mit.edu Thu Sep 17 14:07:39 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA17976 for scwm-discuss-outgoing; Thu, 17 Sep 1998 14:07:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA17972 for ; Thu, 17 Sep 1998 14:07:28 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA19698; Thu, 17 Sep 98 14:04:54 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA20448; Thu, 17 Sep 1998 11:06:09 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Francois-Rene Rideau , scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> From: Greg Badros Date: 17 Sep 1998 11:06:08 -0700 In-Reply-To: hjstein@bfr.co.il's message of "17 Sep 1998 18:29:55 +0200" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Francois-Rene Rideau writes: > > > > KEYBOARD FILTERING: > > Ok, X-synthetic-send-string seems *partly* fixed now > > (send-string is unbound; is X-synthetic-send-string its replacement???). > > At least it sends letters in the window, but if I try non-letter characters > > (such as ":~/.", as found in URLs), I get messages like: > > [Scwm][send-key-press]: <> No symbol `:' > > [Scwm][send-key-press]: <> Bad keysym `:' not sent > > so non-letters are filtered out. I can't remember how 0.5 behaved, > > but at least this is wrong. > > Why not use send-key-press? Evidentally the above is not mapping all > characters to their corresponding X names. I do: X-synthetic-send-string is a wrapper around code like you suggest. It uses `printable-char->keysym-string', similar to your xchar. That proc was just incomplete before. I've made it complete, now, and it works on my X system and keyword for lots of special characters. YMMV, though. For strings, I'd recommend putting the string you want to send in a cut buffer and then sending a key command to ask the application to paste the cut buffer. For XEmacs, you can "(setq x-allow-sendevents t)" to make it accept synthetic events. Greg From owner-scwm-discuss@mit.edu Thu Sep 17 14:11:35 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18025 for scwm-discuss-outgoing; Thu, 17 Sep 1998 14:11:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA18022 for ; Thu, 17 Sep 1998 14:11:33 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA20467; Thu, 17 Sep 98 14:10:21 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA20454; Thu, 17 Sep 1998 11:10:23 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> From: Greg Badros Date: 17 Sep 1998 11:10:22 -0700 In-Reply-To: Francois-Rene Rideau's message of "Thu, 17 Sep 1998 12:37:52 +0200" Message-Id: Lines: 56 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > > > KEYBOARD FILTERING: See response to Harvey's response. > Also, does anyone know how to enable send-string for XEmacs? (setq x-allow-sendevents t) > > DEFAULT CONFIGURATION: > I admit I'm not proficient enough to help (yet) much about writing > a full-featured system.scwmrc (I only know a tiny part of scwm's features), > but if I can do anything, I'm willing... Testing is good while you learn. Bug reports are appreciated immensely. > > CACHEING: > Maybe we should build an API for cacheing of objects in a path > (.xpm, executables, wmconfig, etc). Cache invalidation may be done > either explicitly, or by detecting directory modification date... Yep... seems reasonable. Startup time is unbearable on my 486/100 at home. > > WINDOW SIZES: > > I'd like window sizes to adapt to winmgr settings. > > For instance, I just do want many apps to be fullscreen > > (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > > depending on decoration sizes so they fit; > > conversely, it should detect full-screen windows, and take appropriate > > actions (like, no decoration at all, or changing window geometry > > to fit the screen once decoration is there). > I didn't mean "modify the .Xdefaults", but just "dynamically change > the resource database" (e.g. echo "foo: bar" |xrdb). Many programs only consult the resource database at startup, so this wouldn't do us much good. There's a lot of unused potential in the primitives I just added for resource management. > > MAILING-LIST: > Hum. After all, perhaps I'll stay "mostly subscribed" to have my > localhost as mail archive, instead of having to access the web archive > only when connected... Good! Thanks, Greg From owner-scwm-discuss@mit.edu Thu Sep 17 14:20:06 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18170 for scwm-discuss-outgoing; Thu, 17 Sep 1998 14:20:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA18164 for ; Thu, 17 Sep 1998 14:20:04 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA24114; Thu, 17 Sep 98 14:17:31 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA20482; Thu, 17 Sep 1998 11:18:55 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> <19980917200010.A17354@ZengHe.issy> From: Greg Badros Date: 17 Sep 1998 11:18:54 -0700 In-Reply-To: Francois-Rene Rideau's message of "Thu, 17 Sep 1998 20:00:10 +0200" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > Ouch! First, my keyboard mapping is a french one; > second, if I want to redistribute the program, it had better be > keyboard-mapping independent. What if I wanna send a symbol that's not mapped? > [Particularly true with vietnamese characters]. > I guess I could define "hidden" mappings in an unreachable part of the > keymap and send those keys (real PITA). > > X looks to me like it **really** sucks. May not be X's fault. I'm not sure if there is a better way to convert from a character to a keysym. (It seems there's gotta be). Again, using the cut-buffer + a single "paste" keystroke command is probably the better way to do it. Greg From owner-scwm-discuss@mit.edu Thu Sep 17 14:23:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18257 for scwm-discuss-outgoing; Thu, 17 Sep 1998 14:23:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18245; Thu, 17 Sep 1998 14:23:37 -0400 Message-Id: <199809171823.OAA18245@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm user report In-reply-to: Your message of "17 Sep 1998 11:06:08 PDT." Date: Thu, 17 Sep 1998 14:23:37 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Francois-Rene Rideau writes: > > > > > > KEYBOARD FILTERING: > > > Ok, X-synthetic-send-string seems *partly* fixed now > > > (send-string is unbound; is X-synthetic-send-string its replacement???). > > > At least it sends letters in the window, but if I try non-letter charact > ers > > > (such as ":~/.", as found in URLs), I get messages like: > > > [Scwm][send-key-press]: <> No symbol `:' > > > [Scwm][send-key-press]: <> Bad keysym `:' not sent > > > so non-letters are filtered out. I can't remember how 0.5 behaved, > > > but at least this is wrong. > > > > Why not use send-key-press? Evidentally the above is not mapping all > > characters to their corresponding X names. I do: > > > X-synthetic-send-string is a wrapper around code like you suggest. It > uses `printable-char->keysym-string', similar to your xchar. That proc > was just incomplete before. I've made it complete, now, and it works on > my X system and keyword for lots of special characters. YMMV, though. > For strings, I'd recommend putting the string you want to send in a cut > buffer and then sending a key command to ask the application to paste > the cut buffer. > I really wish X11 had a general way to convert a character to a keysym (or keysym + modifiers), but last time this came up, I couldn't find anything like this in the Xlib programing manual (plenty of functions to go the other way though :-/). Does anyone know of a general way to turn a character into a corresponding keysym or keysym + modifier mask under X11? - Maciej From owner-scwm-discuss@mit.edu Thu Sep 17 14:27:54 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18355 for scwm-discuss-outgoing; Thu, 17 Sep 1998 14:27:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA18351; Thu, 17 Sep 1998 14:27:51 -0400 Message-Id: <199809171827.OAA18351@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: none In-reply-to: Your message of "17 Sep 1998 11:21:19 PDT." Date: Thu, 17 Sep 1998 14:27:51 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Subject: Re: huis-close / is full -- move /home/ftp to /usr/local/home/ftp > > In-reply-to: Your message of "17 Sep 1998 11:07:34 PDT." > > > > -------- > > > > gjb@cs.washington.edu writes: > > > This really really needs to be done asap. > > > > > > > Gotcha. The problem is I need physical access to do this because I > > have no ssh here at work, but I should be able to get it done tonight > > (also the new CVS accounts). > > Ahh... Any chance of building ssh at work? Where did you end up > choosing to work? Be sure to tell them there're a lot of folks hoping > you'll not be worked too hard! :-) > Viewlogic Systems (an EDA company - I am the Unix porting guru, so hopefully I can get them to port to Linux as well). I can't build ssh because I don't have root on my own machine, and while it's _possible_ to build it as joe user and install it in my homedir, I don't want to deal w/ the hassle. Hopefully I can get MIS to give me the root password eventually. I almost ended up working at Cygnus instead, but the timing really didn't work out (they couldn't have me out for the final interview until well after my start date at this job). Anyway, they haven't worked me too hard yet, but I've had annoying Real World (tm) concerns like finding an apartment, etc. - Maciej From owner-scwm-discuss@mit.edu Thu Sep 17 15:03:30 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18702 for scwm-discuss-outgoing; Thu, 17 Sep 1998 15:03:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA18699 for ; Thu, 17 Sep 1998 15:03:26 -0400 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA09123; Thu, 17 Sep 98 15:02:12 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id MAA10976 for ; Thu, 17 Sep 1998 12:02:15 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15242>; Thu, 17 Sep 1998 12:01:40 -0700 To: scwm-discuss@mit.edu Subject: borderline bugs and squishy problems Date: Thu, 17 Sep 1998 12:01:29 -0600 From: Ken Pizzini Message-Id: <19980917190140Z276516-15242+1@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk First, some vitals: i586/Linux-2.0.33/glibc-2.0.6 (aka libc6)/scwm revision 1.454/ guile snapshot 19980623 Now, some bug reports: When I position a window at +0+0, +0-0, -0-0, or -0+0 I can still see one pixel of the bacground left along the edges that the window should be flush against. Positioning a window so that it resists moving an further down, and calling window-frame-size and window-position, I do a little math and find that scwm is behaving as if the screen were two pixels shorter than it should be. (This misbehavior is new since the 0.8a release.) When I have a non-zero border-width, the first pixel of border (counting outward from the window) is a black pixel, and then I have the normal frame border. This black pixel is not treated as part of the frame either --- as I exit an xterm my cursor goes from the text cursor, to an arrow cursor (on the black border), to a resize cursor (on the frame proper), to the X cursor (on the root window). Is there a reason for this special one-pixel border? (This has been been around for quite some time.) When I use the "squash"ed titlebar, there is no frame along the top of the window from the right edge of the titlebar region to the right edge of the window --- at minimum I'd like a single pixel of contrast so that overlapping windows can be distinguised easily, but I really think that there should be a standard frame along there. Toggling a window between a squashed and unsquashed titlebar does not immediately take effect, but if I iconify and then deiconify the window the squashedness becomes correct. When using a border-width of 0, the squashed titlebar does not properly render the last one or two letters of the title. That's all for now... --Ken Pizzini From owner-scwm-discuss@mit.edu Thu Sep 17 15:07:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18729 for scwm-discuss-outgoing; Thu, 17 Sep 1998 15:07:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA18724 for ; Thu, 17 Sep 1998 15:07:05 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA10473; Thu, 17 Sep 98 15:05:45 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA20549; Thu, 17 Sep 1998 12:05:50 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: none References: <199809171827.OAA18351@huis-clos.mit.edu> From: Greg Badros Date: 17 Sep 1998 12:05:48 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 17 Sep 1998 14:27:51 EDT" Message-Id: Lines: 50 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > > > > Subject: Re: huis-close / is full -- move /home/ftp to /usr/local/home/ftp > > > In-reply-to: Your message of "17 Sep 1998 11:07:34 PDT." > > > > > > -------- > > > > > > gjb@cs.washington.edu writes: > > > > This really really needs to be done asap. > > > > > > > > > > Gotcha. The problem is I need physical access to do this because I > > > have no ssh here at work, but I should be able to get it done tonight > > > (also the new CVS accounts). > > > > Ahh... Any chance of building ssh at work? Where did you end up > > choosing to work? Be sure to tell them there're a lot of folks hoping > > you'll not be worked too hard! :-) > > > > Viewlogic Systems (an EDA company - I am the Unix porting guru, so > hopefully I can get them to port to Linux as well). Definitely > > I can't build ssh because I don't have root on my own machine, and > while it's _possible_ to build it as joe user and install it in my > homedir, I don't want to deal w/ the hassle. Hopefully I can get MIS > to give me the root password eventually. I thought you could build and use the ssh client w/o superuser privileges... not sure, though, as it's been a while. > I almost ended up working at Cygnus instead, but the timing really > didn't work out (they couldn't have me out for the final interview > until well after my start date at this job). > > Anyway, they haven't worked me too hard yet, but I've had annoying > Real World (tm) concerns like finding an apartment, etc. Sure... I know it's gotta be busy... hopefully it'll settle down soon, since my time is about to get short when the quarter starts a week from this coming Monday. (Not real short, though, plus I've got two undergrads who are going to be working on scwm and constraints stuff). Greg From owner-scwm-discuss@mit.edu Thu Sep 17 15:07:53 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18736 for scwm-discuss-outgoing; Thu, 17 Sep 1998 15:07:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA18726 for ; Thu, 17 Sep 1998 15:07:13 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA10531; Thu, 17 Sep 98 15:05:55 EDT Received: (qmail 6151 invoked by uid 501); 17 Sep 1998 19:06:37 -0000 Message-Id: <19980917120637.A6029@molehill.org> Date: Thu, 17 Sep 1998 12:06:37 -0700 From: Todd Larason To: Greg Badros , Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> <19980917123752.A10380@ZengHe.issy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Sep 17, 1998 at 11:10:22AM -0700 X-Tom-Swifty: "In the beginning voz...", averred the German preacher. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980917, Greg Badros wrote: > > I didn't mean "modify the .Xdefaults", but just "dynamically change > > the resource database" (e.g. echo "foo: bar" |xrdb). > > Many programs only consult the resource database at startup, so this > wouldn't do us much good. There's a lot of unused potential in the > primitives I just added for resource management. There's a protocol for sending resource changes to some apps, used by editres. The manpage isn't clear whether it's a toolkit thing or an Athena thing; it seems to work at least partially one motif-based Netscape. From owner-scwm-discuss@mit.edu Thu Sep 17 15:22:31 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA19076 for scwm-discuss-outgoing; Thu, 17 Sep 1998 15:22:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA19072 for ; Thu, 17 Sep 1998 15:22:26 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17906; Thu, 17 Sep 98 15:19:48 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id WAA04161 for ; Thu, 17 Sep 1998 22:21:16 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id VAA00886; Thu, 17 Sep 1998 21:21:15 +0200 To: scwm-discuss@mit.edu Subject: Re: more 'changing icon' and window positioning bugs References: From: abel@bfr.co.il (Alexander L. Belikoff) Date: 17 Sep 1998 21:21:15 +0200 In-Reply-To: abel@bfr.co.il's message of "17 Sep 1998 17:51:14 +0200" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > Hi everybody, > > Usual mantra first: > > - scwm Wed Sep 16 18:57:41 EDT 1998 -- $Revision: 1.454 $ > - guile 19980806 > - RedHat 4.2 (libc5) > Actually, the positioning code in that release is completely broken. Netscape on my top right virtual screen disappears every time I request a new URL. It is still present in the Window List, and whenever I click on it, it reappears again. Other apps also behave weirdly. I had to move to a previous release - 1.438. :-( Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Thu Sep 17 16:28:01 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19597 for scwm-discuss-outgoing; Thu, 17 Sep 1998 16:28:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19592 for ; Thu, 17 Sep 1998 16:27:57 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA11617; Thu, 17 Sep 98 16:25:18 EDT Received: (qmail 6656 invoked by uid 501); 17 Sep 1998 20:26:48 -0000 Message-Id: <19980917132648.B6325@molehill.org> Date: Thu, 17 Sep 1998 13:26:48 -0700 From: Todd Larason To: "Alexander L. Belikoff" , scwm-discuss@mit.edu Subject: Re: more 'changing icon' and window positioning bugs References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Alexander L. Belikoff on Thu, Sep 17, 1998 at 09:21:15PM +0200 X-Tom-Swifty: "Let's walk", said Tom stridently. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980917, Alexander L. Belikoff wrote: > Actually, the positioning code in that release is completely broken. > Netscape on my top right virtual screen disappears every time I > request a new URL. It is still present in the Window List, and > whenever I click on it, it reappears again. Other apps also behave > weirdly. I had to move to a previous release - 1.438. :-( I think the patch I posted last night will fix this; it looks like it's been checked into the repository if you want to try again. From owner-scwm-discuss@mit.edu Thu Sep 17 16:26:52 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19587 for scwm-discuss-outgoing; Thu, 17 Sep 1998 16:26:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19584 for ; Thu, 17 Sep 1998 16:26:46 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA09209; Thu, 17 Sep 98 16:25:31 EDT Received: (qmail 6636 invoked by uid 501); 17 Sep 1998 20:25:35 -0000 Message-Id: <19980917132534.A6325@molehill.org> Date: Thu, 17 Sep 1998 13:25:34 -0700 From: Todd Larason To: Ken Pizzini , scwm-discuss@mit.edu Subject: Re: borderline bugs and squishy problems References: <19980917190140Z276516-15242+1@pulsar.halcyon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980917190140Z276516-15242+1@pulsar.halcyon.com>; from Ken Pizzini on Thu, Sep 17, 1998 at 12:01:29PM -0600 X-Tom-Swifty: "My bid for this contract aims to please", said Tom tenderly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980917, Ken Pizzini wrote: > When I position a window at +0+0, +0-0, -0-0, or -0+0 I can > still see one pixel of the bacground left along the edges > that the window should be flush against. I'm seeing this again too. I had it fixed once for me, but I think the fix caused windows going over the edge for other people. > When I have a non-zero border-width, the first pixel of border > (counting outward from the window) is a black pixel, and then > I have the normal frame border. There's some confusion, in my mind at least, between the X window property 'BorderWidth', the #:border-width scwm style property, the psw->bw and psw->boundary_width scwm internal window properties. It looks like psw->bw and BorderWidth are the same, and #:border-width is psw->boundary_width. BorderWidth doesn't look like it's individually controlled, but is always 1 unless some MWM flags are set for the window. Is there any good reason to leave an X border when we can do it ourselves and save the confusion? > This black pixel is not treated > as part of the frame either I assume it's the X border. From owner-scwm-discuss@mit.edu Thu Sep 17 17:54:58 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA20270 for scwm-discuss-outgoing; Thu, 17 Sep 1998 17:54:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA20267 for ; Thu, 17 Sep 1998 17:54:51 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA07952; Thu, 17 Sep 98 17:53:38 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA22303; Thu, 17 Sep 1998 14:53:34 -0700 (PDT) To: Todd Larason Cc: Ken Pizzini , scwm-discuss@mit.edu Subject: Re: borderline bugs and squishy problems References: <19980917190140Z276516-15242+1@pulsar.halcyon.com> <19980917132534.A6325@molehill.org> From: Greg Badros Date: 17 Sep 1998 14:53:29 -0700 In-Reply-To: Todd Larason's message of "Thu, 17 Sep 1998 13:25:34 -0700" Message-Id: Lines: 40 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980917, Ken Pizzini wrote: > > When I position a window at +0+0, +0-0, -0-0, or -0+0 I can > > still see one pixel of the bacground left along the edges > > that the window should be flush against. > > I'm seeing this again too. I had it fixed once for me, but I think > the fix caused windows going over the edge for other people. > > > When I have a non-zero border-width, the first pixel of border > > (counting outward from the window) is a black pixel, and then > > I have the normal frame border. > > There's some confusion, in my mind at least, between the X window property > 'BorderWidth', the #:border-width scwm style property, the psw->bw > and psw->boundary_width scwm internal window properties. > > It looks like psw->bw and BorderWidth are the same, and #:border-width is > psw->boundary_width. BorderWidth doesn't look like it's individually > controlled, but is always 1 unless some MWM flags are set for the window. > > Is there any good reason to leave an X border when we can do it ourselves > and save the confusion? > > > This black pixel is not treated > > as part of the frame either > > I assume it's the X border. Right, your analysis is correct, and the confusion is real. I had to work through these details, too. The X11 window border width seems to be pretty useless to change; I think we should just reset it to 0, draw our own boundaries, and restore it to its value when we unparent the window. This kind of stuff might as well wait for the decoration rewrite though. Greg From owner-scwm-discuss@mit.edu Thu Sep 17 18:19:36 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA20446 for scwm-discuss-outgoing; Thu, 17 Sep 1998 18:19:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA20443 for ; Thu, 17 Sep 1998 18:19:33 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17492; Thu, 17 Sep 98 18:16:53 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id BAA05359 for ; Fri, 18 Sep 1998 01:18:12 +0300 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id AAA02538; Fri, 18 Sep 1998 00:18:11 +0200 To: scwm-discuss@mit.edu Subject: icons and windows still buggy From: abel@bfr.co.il (Alexander L. Belikoff) Date: 18 Sep 1998 00:18:11 +0200 Message-Id: Lines: 11 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk The new (1.466) version fixes the Netscape disappearance, but it still has the window jumping and blinking icon disappearance problems I described before. :-( Cheers, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Thu Sep 17 19:17:33 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA20944 for scwm-discuss-outgoing; Thu, 17 Sep 1998 19:17:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA20940 for ; Thu, 17 Sep 1998 19:17:27 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA26625; Thu, 17 Sep 98 19:16:06 EDT Received: (qmail 7911 invoked by uid 501); 17 Sep 1998 23:16:15 -0000 Message-Id: <19980917161613.A7836@molehill.org> Date: Thu, 17 Sep 1998 16:16:13 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: controlling netscape via scwm Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Listen to my Stallone impression", said Tom slyly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk http://home.netscape.com/newsref/std/x-remote-proto.html documents a protocol for controlling a netscape instance. (X-property-set! (netscape-win) "_MOZILLA_COMMAND" "openUrl(URL)" "STRING" 8 'replace) *works* but isn't right. To do it properly from scheme requires an XGrabServer/XUngrabServer primitive pair, and a way of binding events to property changes. I understand a window-property-change-hook mechanism is already planned (or is it now waiting for the Event Rewrite?). Just how dangerous would an x-grab-server primitive be? could it be made safer as (with-grabbed-server FORM ...), much like emacs' with-excursion? Can it be done that way to ensure that all exits will ungrab the server? From owner-scwm-discuss@mit.edu Thu Sep 17 19:51:02 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA21366 for scwm-discuss-outgoing; Thu, 17 Sep 1998 19:51:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA21360 for ; Thu, 17 Sep 1998 19:50:59 -0400 Received: from demille.cs.washington.edu by MIT.EDU with SMTP id AA08110; Thu, 17 Sep 98 19:48:18 EDT Received: (gjb@localhost) by demille.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA22733; Thu, 17 Sep 1998 16:49:40 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> From: Greg Badros Date: 17 Sep 1998 16:49:38 -0700 In-Reply-To: Todd Larason's message of "Thu, 17 Sep 1998 16:16:13 -0700" Message-Id: Lines: 42 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > http://home.netscape.com/newsref/std/x-remote-proto.html documents a > protocol for controlling a netscape instance. > > (X-property-set! (netscape-win) "_MOZILLA_COMMAND" "openUrl(URL)" > "STRING" 8 'replace) > > *works* but isn't right. > > To do it properly from scheme requires an XGrabServer/XUngrabServer > primitive pair, and a way of binding events to property changes. We have the latter. And the former is too dangerous. We would need to abstract out the full set of actions to be done between the grab and ungrab, and ensure that that set of actions terminates. Better to defined primitives that do the grabbing themselves. > > I understand a window-property-change-hook mechanism is already planned > (or is it now waiting for the Event Rewrite?). It's there as `X-PropertyNotify-hook'. > Just how dangerous would an x-grab-server primitive be? could > it be made safer as (with-grabbed-server FORM ...), much like emacs' > with-excursion? Can it be done that way to ensure that all exits will > ungrab the server? I'm sure we can figure something out. In particular, it seems as though it may be useful to have an `X-atomic-property-set-if-unset!' to grab the Mozilla lock. That'd be safe to do (we just return #f if the property is already set, and scheme code could do a backoff delay and retry. For talking to netscape, though, the "netscape -remote ..." system call is probably sufficient for many users (needs a suitably equivalent netscape on the local host, but the netscape doesn't need to be running on the same host as the system call). Are there other shortcomings of this approach? Greg From owner-scwm-discuss@mit.edu Thu Sep 17 20:03:47 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA21505 for scwm-discuss-outgoing; Thu, 17 Sep 1998 20:03:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA21495; Thu, 17 Sep 1998 20:03:38 -0400 Message-Id: <199809180003.UAA21495@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm In-reply-to: Your message of "Thu, 17 Sep 1998 16:16:13 PDT." <19980917161613.A7836@molehill.org> Date: Thu, 17 Sep 1998 20:03:38 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > http://home.netscape.com/newsref/std/x-remote-proto.html documents a > protocol for controlling a netscape instance. > > (X-property-set! (netscape-win) "_MOZILLA_COMMAND" "openUrl(URL)" > "STRING" 8 'replace) > > *works* but isn't right. > > To do it properly from scheme requires an XGrabServer/XUngrabServer > primitive pair, Sounds potentially dangerous, but see below. > and a way of binding events to property changes. > You can already be notified of X property changes with X-Property-notify-hook (see docs thereof). > I understand a window-property-change-hook mechanism is already planned > (or is it now waiting for the Event Rewrite?). > > Just how dangerous would an x-grab-server primitive be? could > it be made safer as (with-grabbed-server FORM ...), much like emacs' > with-excursion? Can it be done that way to ensure that all exits will > ungrab the server? Well, even if you made it with-grabbed-server to ensure an ungrab for each grab, it is still possible the code in the form could go into an infinite loop. The thing is, if the window manager goes into an infinite loop _without_ the server grabbed, you are still pretty screwed. The way I rationalize that (since to fix it I'd have to either solve the halting problem or make the scwm language non-turing complete) is that at least you can telnet in or switch to a text console and kill the window manager in such cases and get some semblance of an X session back, in the unlikely event it occurs. If the wm has the server grabbed while this happens, it may spell greater trouble. Or it may not, I don't know. Optimally, I'd like scwm to be able to fulfil both it's original intended role as a window manager (which requires some modicum of stability and safety) and it's growing role as a general scripting and automation facility for X11. But they seem potentially in conflict here. - Maciej From owner-scwm-discuss@mit.edu Thu Sep 17 20:18:48 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA21672 for scwm-discuss-outgoing; Thu, 17 Sep 1998 20:18:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA21668 for ; Thu, 17 Sep 1998 20:18:45 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA13356; Thu, 17 Sep 98 20:16:00 EDT Received: (qmail 8281 invoked by uid 501); 18 Sep 1998 00:17:38 -0000 Message-Id: <19980917171737.A8109@molehill.org> Date: Thu, 17 Sep 1998 17:17:37 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Sep 17, 1998 at 04:49:38PM -0700 X-Tom-Swifty: "I'm dying", Tom croaked. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980917, Greg Badros wrote: > Todd Larason writes: > > > To do it properly from scheme requires an XGrabServer/XUngrabServer > > primitive pair, and a way of binding events to property changes. > > We have the latter. Oops, I was reading old docs which said it was planned. > I'm sure we can figure something out. In particular, it seems as though > it may be useful to have an `X-atomic-property-set-if-unset!' to grab > the Mozilla lock. That's a nice middle ground. > Are there other shortcomings of > this approach? I sometimes run in a mode where the netscape and window manager aren't on the same machine, and the machine isn't terribly fast, and the fork/exec time for that is noticable. That is admittedly an unusual case. More importantly, this feels like something scwm "ought" to be able to do. As the X Properties docs say, "the user should be able to implement any of these he likes, including making up his own for personal use.". From owner-scwm-discuss@mit.edu Fri Sep 18 00:01:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA22802 for scwm-discuss-outgoing; Fri, 18 Sep 1998 00:01:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA22799 for ; Fri, 18 Sep 1998 00:01:40 -0400 Received: from fecundity.webcoi.com by MIT.EDU with SMTP id AA14844; Fri, 18 Sep 98 00:00:23 EDT Received: (from jtl@localhost) by fecundity.webcoi.com (8.8.7/8.8.7) id VAA01241; Thu, 17 Sep 1998 21:03:25 -0700 Message-Id: <19980917210324.20981@molehill.org> Date: Thu, 17 Sep 1998 21:03:24 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: controlling netscape Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-scwm-discuss@mit.edu Precedence: bulk This adds an X-atomic-property-set-if-unset! primitive, suitable for locking. An example of its use follows. I make no claims it's a *good* example; I'd love to hear how it could be done cleaner. (define (netscape-win) (car (list-windows #:only (lambda (w) (and (string=? (window-class w) "Netscape") (string=? (window-resource w) "Navigator")))))) (define (run-in-netscape command completion) (let* ((netwin (netscape-win)) (mozilla-version (car (X-property-get netwin "_MOZILLA_VERSION")))) (letrec ((get-mozilla-hook (lambda () (if (X-atomic-property-set-if-unset! netwin "_MOZILLA_LOCK" "lock!") (put-mozilla-command) (add-timer-hook! 50 get-mozilla-hook)))) (put-mozilla-command (lambda () (X-property-set! netwin "_MOZILLA_COMMAND" command))) (mozilla-property-notify (lambda (propname window) ; (write-all #t "mpn: want " netwin ":_MOZILLA_RESPONSE " ; "got " window ":" propname "\n") (cond ((and (eq? window netwin) (string=? propname "_MOZILLA_RESPONSE")) (remove-hook! X-PropertyNotify-hook mozilla-property-notify) (X-property-get netwin "_MOZILLA_LOCK" #t) (completion (car (X-property-get netwin "_MOZILLA_RESPONSE" #t)))))))) (add-hook! X-PropertyNotify-hook mozilla-property-notify) (get-mozilla-hook) #t))) (run-in-netscape "openUrl(http://huis-clos.mit.edu/scwm/)" display-message) diff -u -r1.23 xproperty.c --- xproperty.c 1998/09/07 13:44:02 1.23 +++ xproperty.c 1998/09/18 03:54:50 @@ -200,6 +200,113 @@ } #undef FUNC_NAME +SCWM_PROC(X_atomic_property_set_if_unset_x, "X-atomic-property-set-if-unset!", 3, 2, 0, + (SCM win, SCM name, SCM value, SCM type, SCM format)) + /** Set X property NAME on window WIN to VALUE if it isn't already set. +WIN is the window to set the X property on, or 'root-window. +NAME and TYPE are strings. TYPE defaults to "STRING". +FORMAT may be one of the integers 8, 16, and 32, defining the element size +of the VALUE. It is 8 by default. +VALUE may be a string, if FORMAT is 8, and may always be a vector +of FORMAT-bit integers. + +If NAME is already set, returns #f and doesn't change NAME. If not, +sets NAME to VALUE and return #f. The server is grabbed during the +checking and setting, so this can be used for locking. +*/ +#define FUNC_NAME s_X_atomic_property_set_if_unset_x +{ + int fmt, len, mode, fmtJunk; + unsigned long nitemsJunk, leftJunk; + void *val; + char *str; + unsigned char *propJunk; + Atom aprop, atype, atypeJunk; + Window w; + + if (win == sym_root_window) { + w = Scr.Root; + } else if (WINDOWP(win)) { + w = PSWFROMSCMWIN(win)->w; + } else { + scm_wrong_type_arg(FUNC_NAME, 1, win); + } + if (!gh_string_p(name)) { + scm_wrong_type_arg(FUNC_NAME, 2, name); + } + if (format == SCM_UNDEFINED) { + fmt=8; + } else if (gh_number_p(format)) { + fmt=gh_scm2int(format); + if (fmt != 8 && fmt != 16 && fmt != 32) { + scwm_error(FUNC_NAME, "FORMAT must be 8, 16, or 32."); + return SCM_UNSPECIFIED; + } + } else { + scm_wrong_type_arg(FUNC_NAME, 5, format); + } + if (fmt == 8 && gh_string_p(value)) { + val=gh_scm2newstr(value, &len); + } else if (gh_vector_p(value)) { + int i; + int (*setter)(void **, long); + void *v; + switch (fmt) { + case 8: + setter=&Set8Value; + break; + case 16: + setter=&Set16Value; + break; + case 32: + setter=&Set32Value; + break; + } + len=gh_vector_length(value); + v=val=safemalloc(len*fmt/8); + for (i=0; i From owner-scwm-discuss@mit.edu Fri Sep 18 00:39:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA23153 for scwm-discuss-outgoing; Fri, 18 Sep 1998 00:39:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA23150 for ; Fri, 18 Sep 1998 00:39:32 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20380; Fri, 18 Sep 98 00:38:15 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA23979; Thu, 17 Sep 1998 21:38:09 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> <19980917171737.A8109@molehill.org> From: Greg Badros Date: 17 Sep 1998 21:38:09 -0700 In-Reply-To: Todd Larason's message of "Thu, 17 Sep 1998 17:17:37 -0700" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > More importantly, this feels like something scwm "ought" to be able to do. > As the X Properties docs say, "the user should be able to implement > any of these he likes, including making up his own for personal use.". Totally-- and after reading the netscape page and seeing the protocol, that same type of locking mechanism seems generally applicable, so it'll be a good thing to have. Greg From owner-scwm-discuss@mit.edu Fri Sep 18 01:17:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA23666 for scwm-discuss-outgoing; Fri, 18 Sep 1998 01:17:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA23662; Fri, 18 Sep 1998 01:17:22 -0400 Message-Id: <199809180517.BAA23662@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Administrivia Date: Fri, 18 Sep 1998 01:17:21 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I moved the scwm web site and ftp site to a different partition on the same machine. HOpefully nothing will break, but please let me know if it does. I will soon work on adding things like bonsai, cvsweb and a gnats bug tracking interface to the web site. Are there any other services people would like? From owner-scwm-discuss@mit.edu Fri Sep 18 10:51:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA27883 for scwm-discuss-outgoing; Fri, 18 Sep 1998 10:51:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA27880 for ; Fri, 18 Sep 1998 10:51:15 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA17467; Fri, 18 Sep 98 10:51:04 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA28722; Fri, 18 Sep 1998 07:51:08 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199809181451.HAA28722@fielder.cs.washington.edu> Subject: Re: controlling netscape To: jtl@webcointernational.com (Todd Larason) Date: Fri, 18 Sep 1998 07:51:08 -0700 (PDT) Cc: scwm-discuss@mit.edu In-Reply-To: <19980917210324.20981@molehill.org> from "Todd Larason" at Sep 17, 98 09:03:24 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk When this discussion began, I recalled that there was some not-entirely-well-documented way to do this on the netscape command line. It would make things a lot more straightforward (although this X property stuff is still useful in many settings). Anyway, I found the documentation that I remember reading. See http://home.netscape.com/newsref/std/x-remote.html Here's an excerpt: When Netscape Navigator is invoked with the -remote argument, it does not open a window, but instead connects to and controls an already-existing process. The argument to the -remote switch is an Xt action to invoke, with optional arguments. Remote control is implemented using X properties, so the two processes need not be running on the same machine, and need not share a file system. [...] To open a document, you would do netscape -remote 'openURL(http://home.netscape.com)'. This was the mechanism I wanted to use in my 'go to URL stored in X cut buffer' idea. -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Fri Sep 18 10:53:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA27918 for scwm-discuss-outgoing; Fri, 18 Sep 1998 10:53:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA27915 for ; Fri, 18 Sep 1998 10:53:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03886; Fri, 18 Sep 98 10:51:51 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id QAA04282; Fri, 18 Sep 1998 16:53:21 +0200 To: Greg Badros Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Sep 1998 16:53:21 +0200 In-Reply-To: Greg Badros's message of "17 Sep 1998 16:49:38 -0700" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > Just how dangerous would an x-grab-server primitive be? could > > it be made safer as (with-grabbed-server FORM ...), much like emacs' > > with-excursion? Can it be done that way to ensure that all exits will > > ungrab the server? > > I'm sure we can figure something out. In particular, it seems as though > it may be useful to have an `X-atomic-property-set-if-unset!' to grab > the Mozilla lock. That'd be safe to do (we just return #f if the > property is already set, and scheme code could do a backoff delay and > retry. Why would a with-grabbed-server macro (or function) implemented with dynamic-wind be dangerous? The worst that could happen would be that the FORM crashes scwm leaving the server grabbed before the release could happen, but 1) if this happens you're almost dead anyway, and 2) an on_exit or atexit cleanup could prevent this case. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 11:06:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28082 for scwm-discuss-outgoing; Fri, 18 Sep 1998 11:06:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28076 for ; Fri, 18 Sep 1998 11:05:50 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22734; Fri, 18 Sep 98 11:05:39 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA27144; Fri, 18 Sep 1998 08:05:44 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Administrivia References: <199809180517.BAA23662@huis-clos.mit.edu> From: Greg Badros Date: 18 Sep 1998 08:05:44 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 18 Sep 1998 01:17:21 EDT" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I moved the scwm web site and ftp site to a different partition on the > same machine. HOpefully nothing will break, but please let me know if > it does. I will soon work on adding things like bonsai, cvsweb and a > gnats bug tracking interface to the web site. Are there any other > services people would like? A mailing list of just the change-log entries was requested. We could just use a new mailing list as the entity that gets email w/ the log messages. Then we developers can just subscribe to that list, along with anyone else interested. Greg From owner-scwm-discuss@mit.edu Fri Sep 18 11:09:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28133 for scwm-discuss-outgoing; Fri, 18 Sep 1998 11:09:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28130 for ; Fri, 18 Sep 1998 11:09:01 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA23821; Fri, 18 Sep 98 11:08:51 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA04372; Fri, 18 Sep 1998 17:08:50 +0200 To: Maciej Stachowiak Subject: Re: controlling netscape via scwm References: <199809180003.UAA21495@huis-clos.mit.edu> Cc: scwm-discuss@mit.edu, hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Sep 1998 17:08:50 +0200 In-Reply-To: Maciej Stachowiak's message of "Thu, 17 Sep 1998 20:03:38 EDT" Message-Id: Lines: 46 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > The thing is, if the window manager goes into an infinite loop > _without_ the server grabbed, you are still pretty screwed. > at least you can telnet in or switch to a text console and kill the > window manager in such cases and get some semblance of an X session > back > If the wm has the server grabbed while this happens, it may spell > greater trouble. Or it may not, I don't know. What about releasing the server in atexit? > Optimally, I'd like scwm to be able to fulfil both it's original > intended role as a window manager (which requires some modicum of > stability and safety) and it's growing role as a general scripting and > automation facility for X11. But they seem potentially in conflict > here. I don't see why there's this requirement to make everything safe. As safe as possible - ok. As clean & simple as possible - great. But dumping features because they can't be done safely - why? I hate the idea of dumbing down scwm to prevent people from screwing up their window manager. It's also a little futile, as you point out. There's still a variety of ways to seize it up & crash it, some of which just *can't* be prevented. Are we going to outlaw color setting to prevent people from setting *everything* to black? That'd make everything as unusable as anything else. What about accidentally binding *everything* to (lambda () #f)? Turning off focus-follows-mouse & *unbinding* everything? It just takes a little creativity, and you can be sure that people will do it - you can't make anything foolproof because fools are so ingenious. How about another tactic for managing the risks? What about having a module called unsafe-and-dangerous which users would need to use if they want access to this "dangerous" stuff? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 11:11:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28171 for scwm-discuss-outgoing; Fri, 18 Sep 1998 11:11:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28168 for ; Fri, 18 Sep 1998 11:11:29 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA10792; Fri, 18 Sep 98 11:09:40 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA27161; Fri, 18 Sep 1998 08:11:11 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> From: Greg Badros Date: 18 Sep 1998 08:11:10 -0700 In-Reply-To: hjstein@bfr.co.il's message of "18 Sep 1998 16:53:21 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Why would a with-grabbed-server macro (or function) implemented with > dynamic-wind be dangerous? The worst that could happen would be that > the FORM crashes scwm leaving the server grabbed before the release > could happen, but 1) if this happens you're almost dead anyway, and 2) > an on_exit or atexit cleanup could prevent this case. Because people could still use the primitive directly. If we need a more general mechanism then what we've now got, we could always have a primitive that takes a lambda of no arguments and runs it in between an XGrabServer_withSemaphore and XUngrabServer_withSemaphore. I just want to enforce the matching ungrab from C code. Greg From owner-scwm-discuss@mit.edu Fri Sep 18 11:20:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28404 for scwm-discuss-outgoing; Fri, 18 Sep 1998 11:20:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28400 for ; Fri, 18 Sep 1998 11:20:39 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14033; Fri, 18 Sep 98 11:18:50 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA04460; Fri, 18 Sep 1998 17:20:31 +0200 To: Greg Badros Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Sep 1998 17:20:31 +0200 In-Reply-To: Greg Badros's message of "18 Sep 1998 08:11:10 -0700" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Why would a with-grabbed-server macro (or function) implemented with > > dynamic-wind be dangerous? The worst that could happen would be that > > the FORM crashes scwm leaving the server grabbed before the release > > could happen, but 1) if this happens you're almost dead anyway, and 2) > > an on_exit or atexit cleanup could prevent this case. > > Because people could still use the primitive directly. You don't have to make the primitives available - just the with-grabbed-server function. > If we need a more general mechanism then what we've now got, we > could always have a primitive that takes a lambda of no arguments > and runs it in between an XGrabServer_withSemaphore and > XUngrabServer_withSemaphore. I just want to enforce the matching > ungrab from C code. That would be with-grabbed-server. Except it'd be better to use dynamic-wind in the C code implementation. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 11:42:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28685 for scwm-discuss-outgoing; Fri, 18 Sep 1998 11:42:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28682 for ; Fri, 18 Sep 1998 11:42:04 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22639; Fri, 18 Sep 98 11:40:12 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA27188; Fri, 18 Sep 1998 08:41:51 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809180003.UAA21495@huis-clos.mit.edu> From: Greg Badros Date: 18 Sep 1998 08:41:51 -0700 In-Reply-To: hjstein@bfr.co.il's message of "18 Sep 1998 17:08:50 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I don't see why there's this requirement to make everything safe. As > safe as possible - ok. As clean & simple as possible - great. But > dumping features because they can't be done safely - why? I hate the What feature are we dropping? We're just able to do better than C in that we can easily force pairing of Grabs and Ungrabs, so why shouldn't we? It's an invariant in the correct use of the X calls that C just doesn't give us any help in enforcing. > idea of dumbing down scwm to prevent people from screwing up their > window manager. It's also a little futile, as you point out. There's > still a variety of ways to seize it up & crash it, some of which just Right, because we're not willing to dump features (like Turing completeness) because they can't be done safely. :-) When we can improve the safety of X calls, we should. We can w/ grabbing the server, so we will. Greg From owner-scwm-discuss@mit.edu Fri Sep 18 12:57:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29115 for scwm-discuss-outgoing; Fri, 18 Sep 1998 12:57:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29109 for ; Fri, 18 Sep 1998 12:57:00 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA00761; Fri, 18 Sep 98 12:56:49 EDT Received: (qmail 17480 invoked by uid 501); 18 Sep 1998 16:57:14 -0000 Message-Id: <19980918095713.A13449@molehill.org> Date: Fri, 18 Sep 1998 09:57:13 -0700 From: Todd Larason To: "Harvey J. Stein" , Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Harvey J. Stein on Fri, Sep 18, 1998 at 05:20:31PM +0200 X-Tom-Swifty: "What should I do about this P.S.?" asked Tom submissively. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980918, Harvey J. Stein wrote: > > You don't have to make the primitives available - just the > with-grabbed-server function. > > > If we need a more general mechanism then what we've now got, we > > could always have a primitive that takes a lambda of no arguments > > and runs it in between an XGrabServer_withSemaphore and > > XUngrabServer_withSemaphore. I just want to enforce the matching > > ungrab from C code. > > That would be with-grabbed-server. Except it'd be better to use > dynamic-wind in the C code implementation. I checked in X-atomic-set-property-if-unset! last night, but if the consensus is that it's safe enough, I'd prefer to implement it with a with-grabbed-server primitive. I'm getting ready to go out of town for the weekend. If someone feels like working on this over the weekend, feel free to undo my changes. If not, I'll read up on dynamic-unwind when I get back. From owner-scwm-discuss@mit.edu Fri Sep 18 12:59:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29136 for scwm-discuss-outgoing; Fri, 18 Sep 1998 12:59:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29133 for ; Fri, 18 Sep 1998 12:59:40 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA19874; Fri, 18 Sep 98 12:57:49 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA27391; Fri, 18 Sep 1998 09:59:33 -0700 (PDT) To: Todd Larason Cc: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <19980917161613.A7836@molehill.org> <19980918095713.A13449@molehill.org> From: Greg Badros Date: 18 Sep 1998 09:59:32 -0700 In-Reply-To: Todd Larason's message of "Fri, 18 Sep 1998 09:57:13 -0700" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980918, Harvey J. Stein wrote: > > > > You don't have to make the primitives available - just the > > with-grabbed-server function. > > > > > If we need a more general mechanism then what we've now got, we > > > could always have a primitive that takes a lambda of no arguments > > > and runs it in between an XGrabServer_withSemaphore and > > > XUngrabServer_withSemaphore. I just want to enforce the matching > > > ungrab from C code. > > > > That would be with-grabbed-server. Except it'd be better to use > > dynamic-wind in the C code implementation. > > I checked in X-atomic-set-property-if-unset! last night, but if the > consensus is that it's safe enough, I'd prefer to implement it with a > with-grabbed-server primitive. That's fine w/ me and seems like the right thing, as long as it's a primitive (yes it's still possible that the closure won't terminate, but that's not what we're worried about). Greg From owner-scwm-discuss@mit.edu Fri Sep 18 13:13:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA29357 for scwm-discuss-outgoing; Fri, 18 Sep 1998 13:13:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA29354 for ; Fri, 18 Sep 1998 13:13:46 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA06442; Fri, 18 Sep 98 13:13:35 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA02847; Fri, 18 Sep 1998 13:13:40 -0400 (EDT) Message-Id: <199809181713.NAA02847@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Administrivia In-Reply-To: Your message of "Fri, 18 Sep 1998 01:17:21 EDT." <199809180517.BAA23662@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Sep 1998 13:13:39 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I moved the scwm web site and ftp site to a different partition on the > same machine. HOpefully nothing will break, but please let me know if > it does. I will soon work on adding things like bonsai, cvsweb and a > gnats bug tracking interface to the web site. Are there any other > services people would like? I'd like an email list that sends out notification of all CVS commits. NetBSD & FreeBSD do this and it is very cool. Perry From owner-scwm-discuss@mit.edu Fri Sep 18 13:16:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA29415 for scwm-discuss-outgoing; Fri, 18 Sep 1998 13:16:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA29409; Fri, 18 Sep 1998 13:16:39 -0400 Message-Id: <199809181716.NAA29409@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm In-reply-to: Your message of "18 Sep 1998 09:59:32 PDT." Date: Fri, 18 Sep 1998 13:16:39 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Todd Larason writes: > > > On 980918, Harvey J. Stein wrote: > > > > > > You don't have to make the primitives available - just the > > > with-grabbed-server function. > > > > > > > If we need a more general mechanism then what we've now got, we > > > > could always have a primitive that takes a lambda of no arguments > > > > and runs it in between an XGrabServer_withSemaphore and > > > > XUngrabServer_withSemaphore. I just want to enforce the matching > > > > ungrab from C code. > > > > > > That would be with-grabbed-server. Except it'd be better to use > > > dynamic-wind in the C code implementation. > > > > I checked in X-atomic-set-property-if-unset! last night, but if the > > consensus is that it's safe enough, I'd prefer to implement it with a > > with-grabbed-server primitive. > > That's fine w/ me and seems like the right thing, as long as it's a > primitive (yes it's still possible that the closure won't terminate, but > that's not what we're worried about). > A few notes for implementing this: I reccomend calling the primitive `call-with-grabbed-server' and writing a `with-grabbed-server' macro on top of this (see decor.scm's `call-with-decor' and `with-decor' for an example). Also, dynamic-wind is tricky to use from the C level and doing this (all together now) Only Works With Recent Guile Snapshots (tm). Possible hackish solution: provide `X-grab-server' and `X-ungrab-server' primitives, in minimal.scm write `with-grabbed-server' using `dynamic-wind', then undefine the basic primitives. I do agree that `with-grabbed-server' is probably a better solution for the original problem than `X-atomic-set-property-if-unset!' by virtue of being more general, however, it would still be nice to provide a Scheme-implemented version - Maciej From owner-scwm-discuss@mit.edu Fri Sep 18 13:28:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA29586 for scwm-discuss-outgoing; Fri, 18 Sep 1998 13:28:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA29580; Fri, 18 Sep 1998 13:28:22 -0400 Message-Id: <199809181728.NAA29580@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: Administrivia In-reply-to: Your message of "Fri, 18 Sep 1998 13:13:39 EDT." <199809181713.NAA02847@jekyll.piermont.com> Date: Fri, 18 Sep 1998 13:28:22 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > I moved the scwm web site and ftp site to a different partition on the > > same machine. HOpefully nothing will break, but please let me know if > > it does. I will soon work on adding things like bonsai, cvsweb and a > > gnats bug tracking interface to the web site. Are there any other > > services people would like? > > I'd like an email list that sends out notification of all CVS > commits. NetBSD & FreeBSD do this and it is very cool. > OK. I've been thinking of doing this for some time. Currently log messages are mailed to a hand-maintained list of people, which is increasingly a hassle. Also, now that there is anonymous CVS, it seems like a sensible thing to do. - Maciej From owner-scwm-discuss@mit.edu Fri Sep 18 16:54:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA30928 for scwm-discuss-outgoing; Fri, 18 Sep 1998 16:54:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA30925 for ; Fri, 18 Sep 1998 16:54:54 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13247; Fri, 18 Sep 98 16:52:58 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA06068; Fri, 18 Sep 1998 22:54:48 +0200 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Sep 1998 22:54:48 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 18 Sep 1998 13:16:39 EDT" Message-Id: Lines: 56 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > A few notes for implementing this: I reccomend calling the primitive > `call-with-grabbed-server' and writing a `with-grabbed-server' macro > on top of this (see decor.scm's `call-with-decor' and `with-decor' for > an example). I think you took an unfortunate naming convention with the above two functions. I also think with-decor is a little extra syntax that, although convenient, isn't so commonly done in scheme. It also might be a little buggy - I'm not sure about environment captures & name collisions, but I could easily be wrong here - I didn't think about it hard enough to verify one way or another. What I find unfortunate is that it doesn't follow R4RS conventions, where call-with-X takes a fcn of 1 arg & with-X takes a thunk (a fcn of 0 args, for those of you who haven't heard the term before). The pair usually show up when there's global context involved. ("conventions" is a little strong, but I can't think of the right word right now.) For example, there's call-with-input-file and with-input-from-file. The former takes a fcn of 1 arg & calls it on the input port derived from opening the file, and the latter calls a fcn of 0 args (a thunk) in the context where (current-input-port) is the input port derived from opening the file. This is in contrast to your call-with-decor & with-decor where the former calls a thunk & the latter wraps a form in a lambda & calls the former. So, when I saw your statement, I was quite confused because I couldn't think of any object one would want to pass into the function passed to call-with-grabbed-server which would be in the environment for with-grabbed-server. Also, as I mentioned, the common way of passing code around in scheme is by wrapping it in a lambda. I tend to avoid using macros except when necessary, reserving it for tangible syntax extension, such as fluid-let. > Also, dynamic-wind is tricky to use from the C level and > doing this (all together now) Only Works With Recent Guile Snapshots > (tm). Possible hackish solution: provide `X-grab-server' and > `X-ungrab-server' primitives, in minimal.scm write `with-grabbed-server' > using `dynamic-wind', then undefine the basic primitives. That's unfortunate, but that's a reasonable protection. I still don't agree though that it's important to prevent access to X-grab-server & X-ungrab-server from scheme code. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 17:34:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA31155 for scwm-discuss-outgoing; Fri, 18 Sep 1998 17:34:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA31152 for ; Fri, 18 Sep 1998 17:34:17 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA24697; Fri, 18 Sep 98 17:32:17 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA29950; Fri, 18 Sep 1998 14:34:05 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> From: Greg Badros Date: 18 Sep 1998 14:34:05 -0700 In-Reply-To: hjstein@bfr.co.il's message of "18 Sep 1998 22:54:48 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > That's unfortunate, but that's a reasonable protection. > > I still don't agree though that it's important to prevent access to > X-grab-server & X-ungrab-server from scheme code. I think we're thinking of it differently. I'm not so much interested in preventing access to X-grab-server and X-ungrab-server, I just want to enforce that they are called in matching pairs (sorry if I'm starting to sound redundant). Exposing the individual primitives themselves permits them to be used unmatched, which is error-prone (and gains nothing over the proc taking the closure to run between the matched calls). Greg From owner-scwm-discuss@mit.edu Fri Sep 18 18:01:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31315 for scwm-discuss-outgoing; Fri, 18 Sep 1998 18:01:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31312 for ; Fri, 18 Sep 1998 18:01:41 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01674; Fri, 18 Sep 98 17:59:44 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA06382; Sat, 19 Sep 1998 00:01:33 +0200 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Sep 1998 00:01:33 +0200 In-Reply-To: Greg Badros's message of "18 Sep 1998 14:34:05 -0700" Message-Id: Lines: 50 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > That's unfortunate, but that's a reasonable protection. > > > > I still don't agree though that it's important to prevent access to > > X-grab-server & X-ungrab-server from scheme code. > > I think we're thinking of it differently. I'm not so much interested in > preventing access to X-grab-server and X-ungrab-server, I just want to > enforce that they are called in matching pairs (sorry if I'm starting to > sound redundant). Exposing the individual primitives themselves permits > them to be used unmatched, which is error-prone (and gains nothing over > the proc taking the closure to run between the matched calls). A with-grabbed-server implemented using X-grab-server, X-ungrab-server & dynamic-wind gives an interface for those who want to make sure their grabs & ungrabs are appropriately matched. For those having reasons I cannot fathom that want to do the dangerous thing of using X-grab-server & X-ungrab-server directly, I don't see why they should be prevented from shooting themselves in the foot, or anywhere else for that matter. Personally, I think (with-grabbed-server thunk) using dynamic-wind is perfect. It's exactly what dynamic-wind is intended for & gives all the necessary functionality packaged in the appropriate way. I just don't see why there needs to be any effort to prevent people from using X-grab-server & X-ungrab-server directly to their own probable detriment. One reason I'd say is reasonable is that the developers think that they'd get too many "Why does scwm keep hanging" messages. I don't think this is the case (anyone trying to grab & ungrab the server probably wouldn't complain to scwm-discuss that they hung scwm), but it'd be a reasonable concern. But, as I mentioned before, there're *tons* of ways to hang scwm. I just thought of two more while typing the previous message - (wait-for-window x) where x never shows up, & screwing up an #:other-proc. While writing the last sentence, I thought of another one - screwing up with add-timer-hook! There are just so many ways to hang things I don't see why it's important to hide functionality which *someone* *might* find important because said functionality is yet another way to hang things when improperly used. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 18:09:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31412 for scwm-discuss-outgoing; Fri, 18 Sep 1998 18:09:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31402 for ; Fri, 18 Sep 1998 18:08:52 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03425; Fri, 18 Sep 98 18:06:55 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA06420; Sat, 19 Sep 1998 00:08:47 +0200 To: scwm-discuss@mit.edu Subject: embedded documentation help. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Sep 1998 00:08:47 +0200 Message-Id: Lines: 27 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk This just in: From: Radey_Shouman@splashtech.COM (Radey Shouman) Newsgroups: comp.lang.scheme Subject: slib2c3 Scheme Library released This message announces the availability of Scheme Library release slib2c3. New in slib2c3 are filename matching (a la Bash glob) and `Schmooz', a lightweight markup language for interspersing Texinfo documentation with Scheme source code. Might be useful for scwm's embedded documentation (& guile's for that matter). I'll have to check it out... I also noticed that Luke Tierney (the xlispstat developer) has been using noweb (http://www.cs.virginia.edu/~nr/noweb/) for embedded doucmentation. This might also be easier/more convenient than rolling our own. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 18:20:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31517 for scwm-discuss-outgoing; Fri, 18 Sep 1998 18:20:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31512 for ; Fri, 18 Sep 1998 18:20:33 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11965; Fri, 18 Sep 98 18:20:22 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA00757; Fri, 18 Sep 1998 15:20:20 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> From: Greg Badros Date: 18 Sep 1998 15:20:19 -0700 In-Reply-To: hjstein@bfr.co.il's message of "19 Sep 1998 00:01:33 +0200" Message-Id: Lines: 51 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > A with-grabbed-server implemented using X-grab-server, X-ungrab-server > & dynamic-wind gives an interface for those who want to make sure > their grabs & ungrabs are appropriately matched. For those having > reasons I cannot fathom that want to do the dangerous thing of using > X-grab-server & X-ungrab-server directly, I don't see why they should > be prevented from shooting themselves in the foot, or anywhere else > for that matter. I don't buy this argument. As a library-provider, it's our duty to try to make using the library as fail-safe as possible. The interface we choose to provide can aid the user or it can confuse; I'd prefer the former. > Personally, I think (with-grabbed-server thunk) using dynamic-wind is > perfect. It's exactly what dynamic-wind is intended for & gives all > the necessary functionality packaged in the appropriate way. I agree (but will leave it to Maciej, Todd, and/or you to implement). > But, as I mentioned before, there're *tons* of ways to hang scwm. I > just thought of two more while typing the previous message - > (wait-for-window x) where x never shows up, & screwing up an > #:other-proc. While writing the last sentence, I thought of another > one - screwing up with add-timer-hook! And perhaps these shouldn't be provided in their current form (in particular wait-for-window's documentation even suggests it may be removed soon). The issue isn't "is there a way to shoot yourself in the foot". We should just try to provide features that are as easy to use w/o worry as possible. > There are just so many ways to hang things I don't see why it's > important to hide functionality which *someone* *might* find important > because said functionality is yet another way to hang things when > improperly used. You're way to hung up on the hiding of functionality which we're not trying to do. We want to prevent as safe of an interface as possible. For XGrabServer, an invariant is it needs to be matched with an XUngrabServer, so we force that matching to occur. (One would do the same thing in C++ by having a local object constructed that grabs the server within the scope of the code that needs the server grabbed, and have the destructor of that "grabber" object ungrab the server to ensure that control didn't escape that scope without the ungrab taking place; similar to auto_ptr's protecting against memory leaks). Greg From owner-scwm-discuss@mit.edu Fri Sep 18 18:25:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31578 for scwm-discuss-outgoing; Fri, 18 Sep 1998 18:25:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31574 for ; Fri, 18 Sep 1998 18:25:53 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA06732; Fri, 18 Sep 98 18:23:55 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA06514; Sat, 19 Sep 1998 00:25:42 +0200 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Sep 1998 00:25:42 +0200 In-Reply-To: Greg Badros's message of "18 Sep 1998 15:20:19 -0700" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > Personally, I think (with-grabbed-server thunk) using dynamic-wind is > > perfect. It's exactly what dynamic-wind is intended for & gives all > > the necessary functionality packaged in the appropriate way. > > I agree (but will leave it to Maciej, Todd, and/or you to implement). (define (with-grabbed-server thunk) (dynamic-wind (lambda () (The-Dangerous-X-grab-server)) thunk (lambda () (Thank-God-For-X-ungrab-server)))) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Sep 18 19:36:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA32149 for scwm-discuss-outgoing; Fri, 18 Sep 1998 19:36:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA32143 for ; Fri, 18 Sep 1998 19:35:58 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA24617; Fri, 18 Sep 98 19:34:49 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id TAA22958 for ; Fri, 18 Sep 1998 19:32:24 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> <"WkMlW2.0.KX4.b2k0s"@tequila.systemsz.cs.yale.edu> Date: 18 Sep 1998 19:32:18 -0400 Message-Id: <5lpvctuhdp.fsf@tequila.systemsz.cs.yale.edu> Lines: 12 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu X-Trace: 18 Sep 1998 19:32:18 -0500, tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: > I don't buy this argument. As a library-provider, it's our duty to try > to make using the library as fail-safe as possible. The interface we > choose to provide can aid the user or it can confuse; I'd prefer the > former. How about using a `special' kind of identifier for those primitive that are not intended for the normal user ? Kind of like the leading underscore in C. Stefan "convinced call/cc should be spelled _call/cc" From owner-scwm-discuss@mit.edu Fri Sep 18 19:56:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA32305 for scwm-discuss-outgoing; Fri, 18 Sep 1998 19:56:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA32302 for ; Fri, 18 Sep 1998 19:56:12 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22710; Fri, 18 Sep 98 19:54:14 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA01472; Fri, 18 Sep 1998 16:55:22 -0700 (PDT) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> <"WkMlW2.0.KX4.b2k0s"@tequila.systemsz.cs.yale.edu> <5lpvctuhdp.fsf@tequila.systemsz.cs.yale.edu> From: Greg Badros Date: 18 Sep 1998 16:55:18 -0700 In-Reply-To: Stefan Monnier's message of "18 Sep 1998 19:32:18 -0400" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Greg" == Greg Badros writes: > > I don't buy this argument. As a library-provider, it's our duty to try > > to make using the library as fail-safe as possible. The interface we > > choose to provide can aid the user or it can confuse; I'd prefer the > > former. > > How about using a `special' kind of identifier for those primitive that > are not intended for the normal user ? > Kind of like the leading underscore in C. It'd be reasonable in other cases, I think (though perhaps the scheme world has a different convention from a leading underscore), but here I'll continue to claim that it's more than just a suggestion. > Stefan "convinced call/cc should be spelled _call/cc" :-) Greg From owner-scwm-discuss@mit.edu Fri Sep 18 21:09:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00210 for scwm-discuss-outgoing; Fri, 18 Sep 1998 21:09:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00203; Fri, 18 Sep 1998 21:09:39 -0400 Message-Id: <199809190109.VAA00203@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm In-reply-to: Your message of "18 Sep 1998 16:55:18 PDT." Date: Fri, 18 Sep 1998 21:09:38 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Stefan Monnier writes: > > > >>>>> "Greg" == Greg Badros writes: > > > I don't buy this argument. As a library-provider, it's our duty to try > > > to make using the library as fail-safe as possible. The interface we > > > choose to provide can aid the user or it can confuse; I'd prefer the > > > former. > > > > How about using a `special' kind of identifier for those primitive that > > are not intended for the normal user ? > > Kind of like the leading underscore in C. > > It'd be reasonable in other cases, I think (though perhaps the scheme > world has a different convention from a leading underscore), but here > I'll continue to claim that it's more than just a suggestion. > I think a leading `%' is common in many implementations, but it does not indicate danger, just generally that this interface should not be used directly. > > Stefan "convinced call/cc should be spelled _call/cc" > > :-) > Hey, call/cc is very useful directly, see the .sig below. :-) - Maciej -- guile -c '(define c call-with-current-continuation)(define(f s)(lambda(o)(let ((n(c(lambda(x)(o x)x))))(let p((n n)(l(string->list s)))(cond((not (null? l) )(display(car l))(p(c n)(cdr l))))))))((f"Js nte ul akr")(f"utAohrGieHce\n"))' From owner-scwm-discuss@mit.edu Fri Sep 18 21:44:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00664 for scwm-discuss-outgoing; Fri, 18 Sep 1998 21:44:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA00634; Fri, 18 Sep 1998 21:43:51 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA06552; Fri, 18 Sep 98 21:41:52 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA00629; Fri, 18 Sep 1998 21:43:49 -0400 Message-Id: <199809190143.VAA00629@huis-clos.mit.edu> To: scwm-discuss@mit.edu, scwm-announce@mit.edu Subject: scwm-commits mailing list Date: Fri, 18 Sep 1998 21:43:48 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk It is now possible to receive scwm CVS commit messages by email; these will indicate the files that have changed in the repository and contain an informative message regarding the nature of the change. You can subscribe by sending mail to scwm-commits-request@huis-clos.mit.edu with a body of `subscribe'. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sat Sep 19 15:48:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA06277 for scwm-discuss-outgoing; Sat, 19 Sep 1998 15:48:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA06274 for ; Sat, 19 Sep 1998 15:48:34 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA07077; Sat, 19 Sep 98 15:48:24 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id VAA12900; Sat, 19 Sep 1998 21:47:45 +0200 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Sep 1998 21:47:45 +0200 In-Reply-To: hjstein@bfr.co.il's message of "19 Sep 1998 00:25:42 +0200" Message-Id: Lines: 28 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Greg Badros writes: > > > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Personally, I think (with-grabbed-server thunk) using dynamic-wind is > > > perfect. It's exactly what dynamic-wind is intended for & gives all > > > the necessary functionality packaged in the appropriate way. > > > > I agree (but will leave it to Maciej, Todd, and/or you to implement). > > > (define (with-grabbed-server thunk) > (dynamic-wind (lambda () (The-Dangerous-X-grab-server)) > thunk > (lambda () (Thank-God-For-X-ungrab-server)))) This'd work, but I've got more lambdas than are needed... Better would be: (define (with-grabbed-server thunk) (dynamic-wind The-Dangerous-X-grab-server thunk Thank-God-For-X-ungrab-server)) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Sep 20 14:21:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA12144 for scwm-discuss-outgoing; Sun, 20 Sep 1998 14:21:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA12141 for ; Sun, 20 Sep 1998 14:21:15 -0400 Received: from M2-032-16.MIT.EDU by MIT.EDU with SMTP id AA27357; Sun, 20 Sep 98 14:20:36 EDT Received: by m2-032-16 (SMI-8.6/4.7) id OAA01331; Sun, 20 Sep 1998 14:21:00 -0400 Message-Id: <199809201821.OAA01331@m2-032-16> To: scwm-discuss@mit.edu Subject: snapshot and anoncvs downtime Date: Sun, 20 Sep 1998 14:21:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hey everyone, the snapshot script and anoncvs wrapper program for scwm got accidentally deleted recently; these services will be down for a bit until I can find spare copies or reconstruct them. - Maciej From owner-scwm-discuss@mit.edu Sun Sep 20 16:27:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA13076 for scwm-discuss-outgoing; Sun, 20 Sep 1998 16:27:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA13073 for ; Sun, 20 Sep 1998 16:27:42 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AB12211; Sun, 20 Sep 98 16:27:26 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id WAA05329; Sun, 20 Sep 1998 22:27:19 +0200 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id WAA05298; Sun, 20 Sep 1998 22:27:22 +0200 To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: icons and windows still buggy References: <19980917154445.A7616@molehill.org> From: abel@bfr.co.il (Alexander L. Belikoff) Date: 20 Sep 1998 22:27:22 +0200 In-Reply-To: Todd Larason's message of "Thu, 17 Sep 1998 15:44:45 -0700" Message-Id: Lines: 44 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980918, Alexander L. Belikoff wrote: > > > > The new (1.466) version fixes the Netscape disappearance, but it still > > has the window jumping > > Can you reproduce this with a distributable app? Alternately, can you > compile events.c with -DSCWM_DEBUG_RESIZE_MSGS and see if you get debug > output at the time the window jumps? > I cannot find any suitable application to reproduce it. Anyway, I've recompiled the thing as you asked (revision 1.474), and both problems (jumping windows and disappearing icons still exist). This is what I get at the time the window jumps: [Scwm][HandleConfigureRequest]: <> Routine Entered [Scwm][HandleConfigureRequest]: <> !pswCurrent && configure to 88,26 [Scwm][HandleConfigureRequest]: <> Routine Entered [Scwm][HandleConfigureRequest]: <> MoveResize to 342,105 668x558 ..and when I try the same later: [Scwm][HandleConfigureRequest]: <> Routine Entered [Scwm][HandleConfigureRequest]: <> !pswCurrent && configure to 88,26 [Scwm][HandleConfigureRequest]: <> Routine Entered [Scwm][HandleConfigureRequest]: <> MoveResize to 424,105 668x558 However, there is something *NEW*: in the release I complained about (1.466), the window jumped right past the rightmost edge of the screen. Now, it jumps about 100-150 pixels right each time this happens. BTW, Is there any way to see the event flow or some kind of actions trace in scwm? This would be of great help to find out why scwm treats my application so badly. Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Sun Sep 20 17:01:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13499 for scwm-discuss-outgoing; Sun, 20 Sep 1998 17:01:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13492; Sun, 20 Sep 1998 17:01:30 -0400 Message-Id: <199809202101.RAA13492@huis-clos.mit.edu> To: Maciej Stachowiak cc: scwm-discuss@mit.edu Subject: Re: snapshot and anoncvs downtime In-reply-to: Your message of "Sun, 20 Sep 1998 14:21:00 EDT." <199809201821.OAA01331@m2-032-16> Date: Sun, 20 Sep 1998 17:01:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mstachow@mit.edu writes: > > Hey everyone, the snapshot script and anoncvs wrapper program for scwm > got accidentally deleted recently; these services will be down for a > bit until I can find spare copies or reconstruct them. > It's all fixed now. I also added cvsweb to the web site (see http://huis-clos.mit.edu/cgi-bin/cvsweb to get there directly). I am now trying to set up GNATS - does anyone know where I can find a good web interface for it? Also, does anyone have any experience with bonsai or lxr (source browsing tools vaguely similar to cvsweb but with some different features)? Should I add either or both of them? - Maciej From owner-scwm-discuss@mit.edu Sun Sep 20 21:02:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15273 for scwm-discuss-outgoing; Sun, 20 Sep 1998 21:02:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA15270 for ; Sun, 20 Sep 1998 21:02:07 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA23555; Sun, 20 Sep 98 21:01:20 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA29960; Sun, 20 Sep 1998 18:01:42 -0700 (PDT) To: abel@bfr.co.il (Alexander L. Belikoff) Cc: scwm-discuss@mit.edu Subject: Re: icons and windows still buggy References: <19980917154445.A7616@molehill.org> From: Greg Badros Date: 20 Sep 1998 18:01:35 -0700 In-Reply-To: abel@bfr.co.il's message of "20 Sep 1998 22:27:22 +0200" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk abel@bfr.co.il (Alexander L. Belikoff) writes: > (jumping windows and disappearing icons still exist). This is what I > get at the time the window jumps: > > [Scwm][HandleConfigureRequest]: <> Routine Entered > [Scwm][HandleConfigureRequest]: <> !pswCurrent && configure to 88,26 > [Scwm][HandleConfigureRequest]: <> Routine Entered > [Scwm][HandleConfigureRequest]: <> MoveResize to 342,105 668x558 > > ..and when I try the same later: > > [Scwm][HandleConfigureRequest]: <> Routine Entered > [Scwm][HandleConfigureRequest]: <> !pswCurrent && configure to 88,26 > [Scwm][HandleConfigureRequest]: <> Routine Entered > [Scwm][HandleConfigureRequest]: <> MoveResize to 424,105 668x558 > > However, there is something *NEW*: in the release I complained about > (1.466), the window jumped right past the rightmost edge of the > screen. Now, it jumps about 100-150 pixels right each time this > happens. > > BTW, Is there any way to see the event flow or some kind of actions > trace in scwm? This would be of great help to find out why scwm treats > my application so badly. You can set some debugging flags (e.g., SCWM_DEBUG_RESIZE_MSGS, etc.), or run under the debugger. You can also use "xev -id ". I'm pretty certain it's just that scwm is mis-handling the ConfigureRequest events that your app is generating. I'll look into it tomorrow, I hope. Greg From owner-scwm-discuss@mit.edu Sun Sep 20 21:27:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15614 for scwm-discuss-outgoing; Sun, 20 Sep 1998 21:27:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA15611 for ; Sun, 20 Sep 1998 21:27:13 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA27089; Sun, 20 Sep 98 21:26:24 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15607; Sun, 20 Sep 1998 21:27:09 -0400 Message-Id: <199809210127.VAA15607@huis-clos.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Comments on the latest version of the event model proposal Date: Sun, 20 Sep 1998 21:27:08 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk First off, apologies for the delay in responding to this message. I have been really busy with starting my new job and all. Greg, if you don't manage to get the new event model stuff in before you are hosed again, I will implement it myself according to a spec we can get consensus on. In the comments below, I will remove changes I suggested that you agreed with, and concentrate on our remaining points of disagreement. gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > Where I have them prepared, I will present concrete alternatives to > > the current proposal that I believe are more in line with the goals, > > as ammended by me. In other places, I will merely throw out ideas in > > the hopes that they can > > Lots of your messages seem to tail off into nothingness like this-- is > this a mailer/editor problem? > I used to think it was a problem caused by me editing my replies out of order, but I am very certain I wrote more than what the text says in some places here. It's rather myseterious. Anyway, what I meant to say was that maybe someone can come up with a good way of implementing it. > > > > Upon further consideration, I think event specifiers should be a > > different type of object than events. I say this because event > > specifiers may contain some types of data that make no sense in actual > > events, and vice versa. > > > > For instance, a mouse-down event object should include the X and Y > > coordiantes where the event occured. However, this makes no sense for > > an event specifier. > > This example actually makes me think the opposite. A rectangular region > is definitely something that would be worth filtering on for mouse > events. E.g., menus are implemented w/o using separate X windows for > the items, and highlighting a menu item occurs when the mouse enters the > given region, and selecting occurs on a mouse-down in that > region. (These are called gadgets in Motif -- lightweight things that > have some of the behaviour of X windows). > You're right, and I actually reconsidered this entirely by the time I got to my event-spec proposal below. > > > > I will respond to this section in whole, because I have pervasive > > changes to suggest. First of all, I think event specifiers should be > > different from event objects, and most of this section deals with > > specifiers. I suggest the following changes to the interface for > > event-specs: > > > > ** EVENT-SPECS ** > > > > -- Creating Event Specs -- > > > > (make-event-spec EVENT-TYPE #&rest FIELD-SPECS) > > > > EVENT-TYPE is a symbol identifying the type of X event. It should also > > include some events synthesized by scwm itself which are provided for > > convenience (mouse-click, mouse-double-click, mouse-single-click, etc). > > > > It should include at least the following (symbolic names, X11 names > > where appropriate, and brief explanations are given): > > > > 'key-down (KeyPress) > > 'key-up (KeyRelease) > > 'mouse-down (ButtonPress) > > 'mouse-up (ButtonRelease) > > 'mouse-drag (MotionNotify with at least one button down) > > 'mouse-move (MotionNotify with no mouse buttons down) > > 'mouse-click (A ButtonRelease that happens in the same window as a > > ButtonPress, but does not consitute the second click > > of a double click > > 'mouse-double-click (If the conditions for a mouse-click happen within some > > given time limit, a mouse-double-click is sent instead > > perhaps a movement threshold should also be provided) > > 'mouse-single-click (A click followed by enough time to definitively not > > constitute a double click. To summarize, when the mous e > > is single-clicked, 'mouse-click is sent immediately, > > and 'mouse-single-click is sent after the double click > > delay time passes. When it is double-clicked, 'mouse-c lick > > is sent immediately after the first click, and > > 'mouse-double-click is sent immediately after the seco nd; > > 'mouse-single-click is not sent at all. 'mouse-up is s ent > > on each release of the mouse in both cases. This shoul d > > allow the full desired set of single-click semantics.) > > This is a good summary of the semantics that I think we already have a > consensus for. The big change here is folding the creation of the event > specifiers into a single primitive, which seems reasonable. I was a bit > vague about event objects vs. event specifiers, and the distinction you > draw is good. > > I strongly dislike the gratuitous and potentially confusing renaming of > X events. I am fine with scheme-ifying the names, but an X11 KeyPress > should be 'key-press, not 'key-down, and MotionNotify should be > 'motion-notify w/ the buttons down filter as part of the FIELD-SPECS. > OK, agreed on the key ones. However, I think we should rename the mouse events because we are going to have at least some changes in semantics and split some into more than one, plus I think mouse-down is a _lot_ more clear than button-press. I also think we should keep motion-notify split into mouse-drag and mouse-move because in every GUI, the usages of these two user actions are near-universally almost totally unrelated. X11 does actually let you select for one or the other, the event just happens to be named the same thing because it easily could be. But I don't necessarily think it is a good idea to expose that implementation detail of X11. See my comments below on how literally we should provide the X event interface. > > WRT ColormapNotify, it's useful because (I'm quoting you): > > o Providing a complete interface that allows people to implement > desired capablities which can not be achieved with the current event > binding infrastructure; this will likely include capablities that we > feel no need to provide a more convenient interface for, but that some > users may desire anyway. > > :-) > I was wondering more along the lines of, is there a use _any_one has for this? I don't care if I think it's a good uae, but I find it hard to see why user code would care at all ever. Is this something that was just stuck on the list because it could be, or is there a reason for it to be there? We could take two approaches in the low-level event infrastructure. We could either provide a fairly literal translation of what X provides, or we could try to make it a bit cleaner and more orthogonal to reduce the amount of abstraction we have to put between it and the user to present an interface that's both powerful and convenient. I prefer to make the low-level abstractions more clear and orthogonal than X itself is. This is my motivation in splitting drags from moves and in not handling events that users will not care about. However, in any given case, even one example of something that cannot otherwise be done easily is sufficient to change my mind. > > > * Synthetic events that could be added: > > > > 'mouse-one-and-a-half-click (A mouse click followed by a drag within > > the double click timeout - perhaps 'mouse-click-and-drag is a better > > name), 'mouse-triple-click (supported by Gtk, but probably not widely > > used), and 'mouse-double-click-and-drag (for orthogonality if the > > previous two are supported). Alternatively, a convenient way to mix > > timers with event maps may allow these (as well as orinary click > > events) to be synthesized by higher layers. > > I think higher layers should deal with this. They are clearly > implementable given the other accessible infrastructure. > In that case we could reconsider wether to explicitly provide any of the abstractions we otherwise would on top of mouse-down and mouse-up (all the click and double-click stuff). OTOH it is desirable to optimize the common cases and to provide access to such higher-level events through the same event-map interface. Perhaps we could allow the user to define new event types, but this opens a whole new exciting can of worms. > > * X events that should be supported in a different way, because > > attaching them to window-based event maps is illogical or inefficient: > > > > CreateNotify, DestroyNotify > > > > (in my opinion, these are better handled by special-case hooks. The > > former is illogical because it would not be in a window's event map > > until _after_ the window is created. The latter we only care about for > > top-level windows and probably want to handle specially to avoid race > > conditions). > > I think that the special case hooks can exist for top level scheme > windows, but unless implementing these causes undo hardship (which I'm > pretty certain they won't), it's worth keeping them for consistency and > completeness. In particular, CreateNotify is *not* illogical if > selected for on the root window. > I don't know - I'm not entirely certain that it will make things more consistent in the end for us to treat everything as an event that X11 does. Events are really the only callback mechanism X11 has, and are overloaded to handle many tasks. We have the opportunity to handle some of these tasks differently. > > * X events ignored for now, though we may want to support them later: > > > > KeymapNotify, Expose, GraphicsExpose, NoExpose, UnmapNotify, > > MapNotify, MapRequest, ReparentNotify, ConfigureNotify, > > ConfigureRequest, GravityNotify, ResizeRequest, CirculateNotify, > > CirculateRequest, SelectionClear, SelectionRequest, SelectionNotify, > > ClientMessage > > > > ClientMessage may be especially useful to add, for the purpose of > > supporting custom protocols. > > All of these should be potentially handle-able. Hopefully there won't > be too much per-event work that needs to be done in the implementation. > I.e., we should get most of these for free. > I don't think so; some are hard to select explicitly, each has a different XFooEvent structure that goes along with it, and we will need to make the implementation of event-specs more complicated for each. Further, adding more stuff to an interface is not always good. Excessive options that are never needed serve only to confuse the user. We consider for each event whether notifying the user of it is ever meaningful. I am quite willing to bet that, for instance, GraphicsExpose is totally useless from the Scheme level given the fact that redraws are managed entirely by C code. For some of these events an argument might be made that they are useful from the Scheme level, but I am saying here that I'd rather wait to hear this argument. > There are also some visibility events that are missing from the above > that would be potentially useful to exploit. > There are? I listed visibility-notify with the provided events above, and since I copied the list of events from an X11 header file, I doubt I missed any. > > * Commentary on "global" events: Some events are inherently not > > per-window, but global in the scope of the events of which they notify > > the application. These include (IMO) mapping-notify and > > colormap-notify. It may not be appropriate to handle these events > > through the event map mechanism; it may instead be preferrable to > > handle them through > > ??? another disappearing text act. wacky! I'll assume you were going to > say "through hooks". > Yeah, hooks or other specific mechanisms. > I think that the global map can handle these events more elegantly. If > the map happens to want to call a hook, that's fine (we need a way to > invoke a hook from scheme don't we?). > It can be done with trivial amounts of Scheme code (there is already a `run-hooks' in Guile which is the equivalent of call0_hooks). > The global map can catch all events where we don't care on what window > the event is. > > > > FIELD-SPECS is a list of specifiers for particular fields. The nature > > of a field specifier will be described first; then five possible > > syntaxes for the field specifiers will be proposed. > > > > A field specifier is a field used for filtering events according to > > particular fields (see the discussion of fields below in the section > > on event objects to see which events support what fields). It may be > > either an exact field value, which must be matched, the symbol '*, to > > indicate that this field should be ignored entirely when matching > > events, a procedure which should be a predicate of one argument, or > > possibly a special other value which is available for some fields. An > > event matches an event specifier if its type is the same, and all of > > its fields individually match the event specifier fields. An event > > field matches an event specifier field if any of the followind is > > true: > > > > * The value of the event field is identical to the event-spec field > > * The event-spec field in question has a value of '* > > * The event-spec field is a procedure, and returns a true value when > > applied to the event field. > > I don't like procedures used as filters. It requires us to either > analyze the procedure to find out what it'll return #t for, or to just > throw up our arms and Select a really general event and then call the > procedure exceedingly often on events that we're not interested in. As > much of the filtering as possible must be done by X11 (by not Selecting > inappropriate events), another bit done by C code (when X doesn't > provide the means to filter it directly), and the rest should be done by > the called procedure. If that called procedure wants to have a > scheme-level filtering procedure, it can, but the C level needn't worry > about that (and it'll discourage such things). > There's a specific reason I added them. I agree with you that we want to let as much filtering as possible be done by X11. However, the constraints X11 can use for filtering and the fields they can be applied to are extremely limited. For the case of '* above (which I am sure you will agree is critical for a complete interface), we will already need to select on a really general event. I would like to provide something appropriate for the fourth category of event-spec values for all common cases where we can do useful filtering, as with modifiers. But I think letting the event-spec interface be fully general is a good thing. As long as we are doing _some_ filtering at this level, we may as well make it fully general and allow the user to do any filtering he wants. Again, I don't see why X11's arbitrary limitations and non-orthogonalities must become ours. It's certainly not the intent that you'd provide a predicate on keysyms instead of an actual keysym in the usual case, but you should be able to for those cases when you really really need to. > > * The event-spec field is a special field-specific specifier and > > matches according to the relevant rules. > > > > The only special event-spec field value reccomended by now is the > > following for the 'modifiers field in many events: > > > > A pair of two lists can be accepted for a 'modifiers event-spec field; > > the first list is the list of names of modifiers that must be on, and > > the second is a list of modifers names that must be off. A modifiernnnnn > > not present in either list is ignored entirely. > > I prefer the list of symbols that can specify either on or off. An > earlier draft had a must-be-on and a must-be-off list which was decided > inadequate for another reason (it expose bitmasks instead of symbolic > modifiers), but in that rewrite I really liked the new version's > similarity to X resource modifier configurations. The > MODIFIER-SPECIFIER in events.gjb is a bit higher-level -- in particular, > the pseudo-specifiers 'exactly and 'with are nice because then you don't > have to name all the other modifiers to say "not these". I know that we > could provide that functionality in scheme, but it's pretty easy to do > in C, too. > Well, there are really three sets of modifiers to think about here, must-be-on, must-be-off, and don't-care; since these three must be mutually exclusive and exhaustive, the simplest interface is to let the user specify exactly two sets. I'd be happy enough with a list that allows ~modifiers or *modifiers along with modifiers, but not both. In fact, I'd actually prefer requireds and don't cares to be specified, because IMO a modifier should be assumed to be unwanted unless you explicitly say otherwise. When I ask to bind Control-x, I hardly ever mean that I don't care what other modifiers besides Control are down. And the common case should be the easiest to specify. I don't like the 'exactly and 'with conventions at all. 'with is exteremely ambiguous unles you already know what it means; what it should be assumed, but this should be done on a higher level. 'exactly I consider evil because it should be (as I said above) the default; don't cares should be specified explictly, not assumed by default, since they are hardly ever what you intend. > > The following syntaxes are suggested. For each of them, a field-spec > > not provided is assumed to be '*. > > > > 1) A fixed order of fields dependent on the event type. This may be > > less verbose, and perhaps easier to parse, but it may be confusing and > > awkward. > > > > 2) Name-value pairs or two-element lists, which may be provided in any > > order. This is clearer than the above > > This seems fine. > > > > > 3) A set of keyword arguments. This is probably the most clear and > > consistent, but may be a bit harder to parse from C. Also, using it > > for events as well as event-specs may be a bit silly, since all fields > > must be provided to make an event, and keywords generally indicate > > optional constructs. > > Not worth doing this unless it's easy to parse from C (what does the > primitive actually get? it might be worth making keyword arguments > easier to use from C, but not right now). It would get a rest arg which contains the keyword-value pairs. We would then have to parse it apart by hand, which is slightly but not much harder than the parsing required for 2. Upon reconsideration, we should probably save keywords for the higher-level interfaces. > > > 4) A combination of 1 and 2; Some optional aguemnts for each event > > type (the most commonly used ones) in a fixed order, followed by > > followed by name-value pairs it should have said. > > 5) > > ???? 5? > Darn mailer/editor/whatever. This should have been a combination of 1 and 3 analogous to 4. > > -- Examining Event-Specs -- > > > > (event-spec-type EVENT-SPEC) > > > > Return the event type of the event specifier EVENT-SPEC. > > > > > > (event-spec-field EVENT-SPEC FIELD-NAME) > > > > Return the value of the field named by the symbol FIELD-NAME in EVENT-SPEC. > > > > > > Motivation: > > > > There are several changes in this version as compared to the previous > > version. Here is the motivation for them: > > > > o Single make-event-spec procedure vs. several specialized ones: Much > > functionality is common; IMO at this level of interface, we should > > keep things simple and leave greater convenience to the higher-level > > interfaces. > > I'm not opposed to a single make-event-spec, but it seems like the > various specialized once are exposing specializations which will occur > in the implementation anyway, and are natural distinctions. There is > often benefit in generalizing and unifying naturally distinct things. > Here, though, your one-procedure is complicated by the need to parse > different kinds of FIELD-SPECS for the different kinds of events based > on the first argument: EVENT-TYPE. I'd rather fold that first argument > into the primitive name since the code will be different based on that > value, anyway (i.e., let the program do the "switch" that's gonna be > inside the primitive anyway). > In my opinion, there are only two ways of splitting it up that make sense: either a single make-event-spec, or a separate make--event-spec for each type of event that has a different X11 event structure. Splitting into 3 quasi-arbitrary categories is IMO not a good plan. > > o Making event filtering simple and uniform: IMO, this is the right > > thing for the low-level interface. We can pick convenient subsets of > > the functionality w/ convenient interfaces for the higher-level > > version. The whole decision about the user's intentions when trying to > > bind key events, for instance, can be punted to a higher level. > > I agree, but I'm not convinced that the single primitive is simpler in > any useful way relative to the three primitives in the earlier draft. > You just move the complexity into the processing of the FIELD-SPECS of > the one primitive. > This was not referring so much to the single make-event-spec primitive as to the fact that (a) you can filter on any field of an event; and (b) because '* (meaning "any") and predicate filters are provided, you can filter in any way you want (although the common cases are all optimized). > > ** EVENTS ** > > > > Events will be treated similarly to event specifiers except that, of > > course, they have different usages and different sets of restrictions > > on their fields. > > > > -- Creating Event Objetcs -- > > > > (make-event EVENT-TYPE #&rest FIELDS) > > > > The EVENT-TYPE field is any of the event types supported by > > > > The syntax for the FIELDS arguments should be similar to that for the > > FIELD-SPECS argument of make-event-spec, but all applicable fields are > > mandatory. Here is a list of the possible fields and their Scheme > > types: > > > > > > 'synthetic (boolean) > > 'window (integer - X window ID) > > 'root (integer - X window ID) > > 'subwindow (integer - X window ID) > > 'time (whatever type is appropriate for times in Scheme) > > 'x (integer) > > 'y (integer) > > 'x-root (integer) > > 'y-root (integer) > > 'property (either a string or an integer representing an X atom; > > which is better?) > > 'state (symbol; valid values depend on the event type. For > > 'property-notify : 'deleted or 'new-value ; For > > 'visibility-notify : 'unobscured, 'partially-obscured or > > 'fully-obscured ; ) > > 'request (symbol - one of 'modifier, 'keyboard or 'pointer) > > 'modifiers (list of symbols, each one of > > 'control 'shift 'meta 'super 'alt 'hyper 'numlock 'capslock > > 'mod[1-5] symbolic names will be given in preference to > > mod[1-5] names whenever possible.) > > 'buttons (list of the numbers 1-5) ;; maybe this should be ditched? > > 'button (an integer 1-5) > > 'key a string naming the key (we'll have to turn a keycode into > > a keysym and that in turn into a symbolic name - that will > > sure be fun) > > > > [Note to greg: X11 only supports mod1-5 AFAIK, so 6-8 are pointless] > > Yep... I was thinking/hoping that the 8 bits corresponded to Mod1-5, but > Mod 1 is the 4th bit (bit 3, when numbered from 0). > > > > > Here is a list of which events have which fields: > > > > All events: 'synthetic 'window > > All mouse and key events: 'root 'subwindow 'x 'y 'x-root 'time 'modifiers > > 'buttons > > 'subwindow might need to be subwindow-id (a number) -- we don't want to wrap > subwindows, I'd think. > 'window is meant to be a window ID as well, not a window object. I wouldn't be opposed to appending -id to both of these names for the sake of clarity. > > Event: Extra fields supported: > > > > 'key-down (mouse/key fields) 'key > > 'key-up (mouse/key fields) 'key > > 'mouse-down (mouse/key fields) 'button > > 'mouse-up (mouse/key fields) 'button > > 'mouse-drag (mouse/key fields) 'button > > 'mouse-move (mouse/key fields) 'button Hmm, I forgot, 'mouse-move wouldn't really have a 'button field. > > 'mouse-click (mouse/key fields) 'button > > 'mouse-double-click (mouse/key fields) 'button > > 'mouse-single-click (mouse/key fields) 'button > > 'enter-notify (mouse/key fields) > > 'leave-notify (mouse/key fields) > > 'focus-in > > 'focus-out > > 'visibility-notify 'state > > 'property-notify 'property 'time 'state > > 'colormap-notify (I'm not sure what is useful to expose to Scheme 'cause > > I'm not sure why this event is useful to Scheme in the > > first place) > > 'mapping-notify 'request > > Again, I prefer sticking easier-to-guess names by using schemified > version of the X11 names. > For the event names or field names? I prefer renaming the mouse events because my target guesser is not necessarily someone who is an X11 expert, and I think the renamings of the mouse events at least add clarity. I renamed only a few of the field names for simplicitly. > > Implementation note: event-specs should use a representation that > > allocates common field-specs statically and rarely cared about ones > > dynamically for the sake of efficiency. Event objects could just > > contain an XEvent internally. > > Yep.... I'm wondering whether these objects have already been wrapped-- > does Gtk do anything nice fore us here? Any X wrappers out there? I > suppose it won't be too painful to do this. > Gtk depends on Gdk which is a thin wrapper on top of raw Xlib. The scheme interface is a very thin wrapper on top of that, and does not provide nice, orthogonal event filtering. Also it entirely removes access to events the user is unlikely to care about at the Gtk level (some of these even being events scwm users are likely to care about). > > > > Geometry-based hierarchy and installation of maps is obviously an > > excellent addition. One caveat: events should never propagate from any > > part of an application window to the root window (IMO). > > You mean as opposed to being caught in advance. Obviously we want > global bindings to work even when on an application window. > The global event map (implicit parent of all event maps) and the root event map (the event map on the root window) are, I hope, two separate creatures. > I was more talking about, e.g., a button1 decoration propagating up to > the titlebar, then to the frame (top-level map for a given window). I > think propagating to the root would be wrong, as you suggest. > Yes, I agree in both of these ways. > > > (add-event-binding EVENT-MAP EVENT PROC-OR-SYMBOL) > > > (remove-event-binding EVENT-MAP EVENT) > > > ;; Similar to your {add,remove}-event-hook. > > > ;; These add and remove bindings for EVENT objects in the given > > > ;; EVENT-MAP object. > > > ;; PROC-OR-SYMBOL is either a procedure or 'pass to indicate > > > ;; that the event should not be grabbed by the wm and the application > > > ;; should get the event (this is only an issue for event maps attached > > > ;; to client windows). See dispatch-event for details about how > > > ;; the bindings are invoked. > > > > I suggest allowing multiple procedures to be bound to one event (or > > both 'pass and a procedure, to allow convenient implementation of a > > passively observing macro recorder facility or something like > > that). Proposed interface: > > > > (event-map-add-binding! EVENT-MAP EVENT-SPEC PROC-OR-PASS) > > ;; As `add-event-binding' above, but returns a "binding handle" which > > ;; uniquely identifies this specific binding in the map. > > That seems useful. Good. Do you envision the binding handles to be a > SMOB, too, or some scheme-level representation? > Whatever is convenient to implement and guarantee the uniquness of. For input and timer hooks, I used the Scheme pairs actually stored in the internal list. In this case, a SMOB of some kind or other unique token (each empty vector is distinct, for instance) may be more appropriate since an event map may look pretty weird internally. > > Another suggestion: add an optional ARGS-DESIRED argument which may be > > one of #f, 'window, 'event or 'full. This only applies if PROC-OR-PASS > > is a procedure. If #f, the proc is passed no arguments; if 'window, it > > is passed the window object (or 'root-window) that the event is > > relevant to; if 'event, it is passed the event object; if 'full, it is > > passed the window object, the event object, and the window id in that > > order. This will make life a lot easier even though all the others > > can be simulated by higher layers if only 'full is provided. > > I think this is a hack, and didn't want to do it at the event-binding > area. I like Emacs' `interactive' a lot better, where with the command > (proc) you specify what arguments it is expected to take. It also has > the advantages of documenting what procedures are meant to be bound to > events, and may provide better printable forms (even if it's a closure). > We can simulate your ARGS-DESIRED argument with a set of standard > closures, but I still think that the place that should be deciding that > is the code that's gonna run (the proc, not the point of binding). > > I don't have a sense of how hard adding `interactive' declarations would > be, but I imagine Jim Blandy could pull it off or provide some help as > we need it. > I have the exact opposite feeling - I think things like `interactive' are a hack, and what arguments to pass to a proc should be determined at the time you bind it to something. I say this because I don't think that some special set of procedures that take a window should be specially identified as being meant to be bound to events; you should be able to bind *any* procedure that takes arguments in one of the appropriate formats to an event without the need to declare a helper proc that has a special declaration. In general, I have a very strong feeling that the decision on what arguements to pass should be made by the caller, i.e. the event-map (as specified by the user making the binding) rather than the procedure, because the procedure cannot possibly anticipate all of the places it might be used in. And I think `interactive' in emacs is intended to solve a very different problem from the fact that event bindings may care about different sets of information; as I understand it, it exists primarily to allow a function to either take an argument when called in code, or to interactively query the user with a specified prompt. We could discuss further how exactly to specify what args a procedure wants, but I feel very strongly that this should be specified at the time of binding, not at the time of declaring the proc. On the other hand, some procedures will likely want the event object to work right but we don't want the user to know or care (e.g. interactive-move); perhaps a hybrid approach involving bind-time specification, but also a special procedure property that gives the correct value for specially declared procedures would work best. I don't want it to look like (interactive) though, because IMO making random forms in a procedure have a magical declarative effect confuses the semantics of the language (and confuses me when thinking about how the heck to implement them). I'd rather see define-command and/or lambda-command macros which contain the additional declaration and set the procedure property according to an extra arg. > > > Implementation notes: obviously, scwm should ask the server to not > > send it events it is not interested in. > > Rephrased to be more precise... scwm will select only the events in > which it is interested, and do all the appropriate grab-keys, etc. This > is part of the problem with the less-restricted lambda-filtering you > suggested. > Note that the lambda filtering was suggested _in addition to_, and not _instead of_ specifications which can be used to generate the proper grabs automatically. lambda-filtering does not introduce any problems that '* (don't care) filtering doesn't already. And we need '* for completeness. > > > 3 - Dispatch of Events > > > ---------------------- > > > > > > (dispatch-event EVENT-MAP EVENT) > > > ;; EVENT-MAP is an event-map object, EVENT is an event-object > > > ;; All applicable events' procedures should be invoked in the order that > > > ;; they were added to the EVENT-MAP. Parent EVENT-MAPs are handled > > > ;; as discussed above. > > > > I'm not convinced that specifying the order this way is a good idea; > > it may have negative performance implications. Then again, it may not. > > I don't think it's got any real problems performance-wise. We can > experiment with greater flexibility on controlling the dispatch order > later, as I think this design is suboptimal in flexibility (method > combination in CLOS is a good place for examples and inspiration here). > I was thinking we could use tricks with hash tables or something like that to make event dispatch faster than a linear scan, but this may conflict with a guaranteed ordering. I guess it depends on how big event maps are expected to get; certainly if you have a lot of global key bindings, a linear scan may be a bad idea. > > > ;; Each procedure is invoked with four arguments: > > > ;; #1 - the scheme object that the event acted on/in (e.g., for a button > > > ;; decoration, it will be that top-level frame; for a menu it will be > > > ;; the menu object, etc.), or #f if there is no applicable scheme object > > > ;; (e.g., the root window) > > > ;; #2 - the event object that caused this dispatch (i.e. EVENT) > > > ;; #3 - the window id of the X window that got the event. We can add > > > ;; primitives to query what decoration/menu/whatever a window ID is > > > ;; #4 - the time of that event, as reported by the X server > > > ;; #5 - a list of event-specific information or #f; e.g., > > > ;; a property-notify event may use > > > ;; '("WM_TITLE" 'NewValue) > > > ;; property name changed and either 'NewValue or 'Delete > > > ;; for this argument > > > ;; #6 - the event map object (i.e. EVENT-MAP) > > > > See my suggestion above for allowing procedures to have fewer > > arguments passed through an extra argument at binding time. I suggest > > removing 5 and 6 above entirely; 5 is redundant with the even object > > because event-field can be used to get that information, and 6 just > > seems insufficiently useful; if you really care what event map you got > > invoked from, make an appropriate closure. The time, if considered > > useful, could be added to full, however, IMO the time is logically > > part of the event object and should be a field thereof. In fact, not > > all events even have time. So 4 is unnecessary as well. > > *3*, 4, and 5 are all subsumed by the first-class event objects distinct from > event-specifiers --- they are folded into #2. > Umm, I think the window-id in the X event structure is not necessarily always the window-id of the window that received the event, in the case of some X events; so the info is not necessarily redundant. I need to reread the relevant part of the Xlib programming manual I guess. > I think the event-map object is useful as a place to hang > extra-properties off of... given the notion of a binding-object, though, > that should replace the event-map object, as it'll have to have an > accessor querying the event map to which it corresponds. > I suspect the desire to hang info off of the event-map or binding object is neither the world's greatest plan, or a likely common useage; if someone really wants it, they can simulate it with appropriate closures, e.g. (define (some-proc-that-really-wants-an-event-map window event event-map) ;; do some stuff ) (event-map-add-binding! my-event-map (let ((event-map my-event-map)) (lambda (window event) (some-proc-that-really-wants-an-event-map window event event-map)))) Voila! So I think we should provide context information only if it is both commonly desired and impossibly to get otherwise (both of these being true of the event object and the window object). > > > > > 4 - Binding of Event Maps: > > > -------------------------- > > > > > > Event maps can be attached to any X Window by its X Id. We can add > > > primitives that give the window id from a SCWM top-level window and a > > > decoration specifier. > > > > > > (attach-event-map X-WINDOW-ID EVENT-MAP) > > > e.g., > > > (attach-event-map (button-n-of 1 win) button-1-map-for-win) > > > (attach-event-map (title-bar-of win) title-bar-map-for-win) > > > ;; Only one event map is attached per window id -- attaching > > > ;; a new map removes any old one > > > > > > The window style mechanism should be used to attach a set > > > of event maps at startup for a given window style, e.g.: > > > > > > (window-style "*" #:event-maps (list (1 . default-button-1-map) > > > ('title . default-title-map) > > > ('window . default-window-map))) > > > > How event maps are to be integrated with styles is an issue that can > > be punted for now. However, I'd like to be more specific on naming > > window parts. I suggest the following interface: > > > > (window-part-id WINDOW PART-NAME) > > > > PART-NAME is a symbol that is one of the following: > > 'frame (the top-level frame window) > > 'title > > 'side-north > > 'side-east > > 'side-south > > 'side-west > > 'corner-ne > > 'corner-nw > > 'corner-se > > 'corner-sw > > either the side directions should be dropped to n,e,s,w or the corner > ones should be spelled out. > OK, full spelling then (although I don't think the abbreviation threshold I used was illogical). > > '(button-right ) where is an integer > > '(button-left ) where is an integer > > ;; the arbitrary limit on number of buttons should be removed; they > > ;; should be dynamically created on demand. > > Agreed, and maybe buttons should be first-class, too. It's a bit > awkward to use button numbers. For a while, we should also have > 'button-number that take an using the current (very screwey) > convention of odds on left, and evens on right. > > > 'icon-title > > 'icon-image > > 'window ;; the actual application window > > I think 'window -> 'client-window > OK. > > Actually, some parts may consist of more than one window. For example, > > 'side and 'corner are each four windows which we almost always bind > > together. Thus, I suggest that attach-event-map should accept a list > > of X window ids in place of a single ID to make this more convenient. > > I was thinking that 'side should be the geometrical parent of each of > the four 'side-[nesw]. Then the binding only occurs in that one map, > and the intent is preserved. One shouldn't later be able to > `event-map-remove' just the binding for 'side-n and leave the other > three windows bound. > I don't believe it is possible to do this for both sides and corners simultaneously without using the Shape extension because the screen geometry just doesn't work. Let's not depend on it for such simple things. > > > > (alias-window-part WINDOW ALIAS-NAME ORIGINAL-NAME) > > > > For WINDOW, allow ALIAS-NAME to be treated the same as ORIGINAL-NAME > > for the purpose of window-part-id. ORIGINAL-NAME may be a part name or > > a list of part names. WINDOW may also be #t to indicate a global > > alias. > > > > The following global aliases are pre-defined: > > > > 'side => '(side-east side-west side-north side-south) > > 'corner => '(corner-ne corner-nw corner-se corner-sw) > > This is unnecessary given my above comments. > > > > > The following should be defined conventionally to ease > > look-independent binding of buttons: > > > > 'system-button > > 'maximize-button > > 'minimize-button > > 'close-button > > Can't these just be variables? > I suggest the aliases for a particular reason. I want to come up with a system for people to distribute theme files that specify the look of the window manager, but still leave it to the user to specify behaviors in his or her own scwmrc. To achieve this with maximum transparency, we need logical button names, since different looks will likely have the buttons with the same general purpose in different places, but the user wants to be able Variables are insufficient, because themes ought to be settable per-window; it needs to be some kind of property of the window. > > Other conventinal button names could be established as well. If it is > > considered desirable to give these aliases an initial value, I'd > > suggest '(button-left 1), '(button-right 1), '(button-right 2) and > > '(button-left 2) respectively. > > > > > > > [this avoids a bunch of attach-event-maps from being needed in the > > > new-window-hook -- the attaching of the default event maps needs to be > > > efficient, since it'll happen for each new window and on lots of > > > decorations -- it's only a single XSaveContext call for each attachment, > > > which should be fine]. > > > > > (event-map-for X-WINDOW-ID) > > > ;; Return the currently attach event-map object, if any, or #f > > > > Suggest renaming this to something like get-event-map, > > window-id-event-map, or something. IMO prepositions in procedure names > > should be used very sparingly. > > This rename I don't like -- the primary reason I liked the other renames > was because it kept event-map at the beginning of the procedure name. > event-map-for-window-id would be fine. > I think this function is logically different from the others in a way that makes it desirable _not_ to prefix it with event-map-. In particular, the Scheme convention as I understand it is that procedures should be prefixed with a data type when they are understood to be primarily operating on objects of that data type in some sense (e.g. vector-set!, string-ref, etc). To me, this operation is primarily operating on the window ID > > > > > (remove-event-map X-WINDOW-ID) > > > ;; detach any event map from X-WINDOW-ID > > > OTHER ISSUES: > > > > > > Enabling/disabling event maps on a per-attachment basis? > > > > > > Top-level global event map that's used first before any others? > > > > I suggest adding: > > > > (install-override-event-map EVENT-MAP) > > I think I'd prefer event-map-override and set-event-map-override! (or > s/override/global/). There should just be a getter/setter interface to > a global-map. (See below, too). > The global map != the override map, as you mentioned in a later post. With respect to the comments below, (override-event-map) and (set-override-event-map! EVENT-MAP) are an equipotent and likely clearer interface. > > Install EVENT-MAP as the event map to use for everything. Bindings in > > EVENT-MAP override any other bindings that may have otherwise taken > > effect for the event, unless the binding is 'pass, in which case they > > are passed to the normal event map they would have been handled by (or > > the app window). > > > > Motivation: this would allow implementing features like "bookmarks" as > > suggested by Carl Witty, multi-event bindings, scwm-read-char and > > scwm-read-line, interactive-move and -resize in Scheme (at least the > > opaque version), and so on. For the more complex of these, we will > > definitely need something like the minibuffer in Emacs; I suggest > > reusing the floating coordinate window for this purpose, and letting > > the user optionally set it's contants and show and hide it explicitly. > > > > (current-override-event-map) > > > > Return the currently installed override event map or #f if none. > > > > (uninstall-override-event-map) > > > > Remove the current override event map, if any. > > The uninstall seems like it's for convenience only. The standard global > map could be a null map and install/uninstall can happen by manipulating > its parents. > > > > > > I'll try to come up with an example of using this system but please feel > > > free to poke holes in it or query me about how one might accomplish > > > something you're interested in being able to do. (Or if you think it's > > > redundant, overly-general, inefficient, etc.). > > > > > > > I think my suggestions make this interface more general, less > > redundant, and easier to understand. I will try to come up w/ > > proposals for higher-level binding functionality to be implemented on > > top of this interface sometime soon; I believe something as easy to > > use and understand as bind-key and bind-mouse, but providing greater > > generality, could easily be implemented. > > > > I'd like comments from Greg and anyone else on my suggested changes, > > especially suggestions on what to do about areas that I left wide > > open, like the syntax for event and event-spec fields. > > I like virtually all of your suggestions, *except* the make-event-spec. > The only piece of that that makes sense to me is separating out event > specifiers and event objects. Otherwise, the event-spec field stuff > seems like a hack. IMO, you should be allowed to select on all fields that an event has, wether or not X11 supports doing so in the server. And you should be allowed to make the decision in any way you want. It may be true that _in fact_ the decision will be made on a different level depending on wether you give an exact value or a lambda, but I think hiding this from the user is more useful than costly. > My three primitives are more clear, easier to > implement, and more nicely restricted than the make-event-spec that you > specify. I don't think the additional restrictions net you anything; and I specifically _don't_ think they are more clear, in particular, make-x-event needs to be nearly as complex as make-event if not more so to provide the same functionality. > Think of my three primitives (make-key-event, > make-mouse-event, make-x-event) as three constructors to an event > specifier object. You're trying to overload a single ctr to make all > three kinds of event specifiers, whereas I'm exploiting their > differences to simplify their interfaces and implementation. I don't mind exploiting differences, _but_ if we do this, we should make distinctions between all events that are actually in fact different rather than sorting them into three semi-arbitrary bins. I'm for either one way of making event-specs (and events) or a different constructor for each type X has a different event structure for. In fact, I would even suggest taking different tracks for specs and events; have a whole bunch of constructors for event objects, since each type of event needs an exact set of mandatory fields, and a single one for event specs, since for these everything but the event type should by rights be optional, and many fields (those we can't select for easily from the server or from C code) will be handled in a totally parallel way, I'd expect. > This is > perfectly reasonable given that there is a natural distinction among the > three kinds of events (e.g., a user knows which primitive to invoke). > Yes, but there are also equally natural distinctions between some of the things you have grouped together. > I'll wait for another round of comments from you and others before > integrating the changes we've discussed so far into the repository's > proposal. > One thing I forgot to suggest before is a procedure `event-matches-event-spec?', a predicate which allows the user to check whether an event matches a spec. I didn't think of a real use but it seemed like it might be a handy thing to have around. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 21 03:12:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18864 for scwm-discuss-outgoing; Mon, 21 Sep 1998 03:12:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18861 for ; Mon, 21 Sep 1998 03:12:52 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id JAA02156 for scwm-discuss@huis-clos.mit.edu; Mon, 21 Sep 1998 09:12:31 +0200 (MET DST) >Return-Path: Received: (qmail 1128 invoked by uid 115); 20 Sep 1998 14:13:16 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) From: Robert Bihlmeyer Date: 20 Sep 1998 16:13:15 +0200 Message-ID: Lines: 28 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 13 Sep 1998 23:58:17 +0200 >>>>> Francois-Rene Rideau said: FRR> For instance, I just do want many apps to be fullscreen FRR> (netscape, xdvi, gv, etc). scwm should modify the Xdefaults FRR> depending on decoration sizes so they fit; Something like this should work: (X-property-set! 'root-window "RESOURCE_MANAGER" (string-append "gv.geometry: " (number->string (- (car (display-size)) 5)) "x" (number->string (- (cadr (display-size)) 17)) "\n") "STRING" 8 'append) But for this particular purpose, you should perhaps consider doing: (window-style "gv" #:placement-proc (lambda (win) (maximize (%x 100) (%y 100) win))) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Sep 21 03:13:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18869 for scwm-discuss-outgoing; Mon, 21 Sep 1998 03:13:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18866 for ; Mon, 21 Sep 1998 03:12:56 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id JAA02170 for scwm-discuss@huis-clos.mit.edu; Mon, 21 Sep 1998 09:12:35 +0200 (MET DST) >Return-Path: Received: (qmail 730 invoked by uid 115); 20 Sep 1998 12:36:25 -0000 To: scwm-discuss@mit.edu Subject: system(3) References: X-Attribution: Robbe From: Robert Bihlmeyer Date: 20 Sep 1998 14:36:21 +0200 Message-ID: Lines: 34 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, some more facts to the system mystery: >>>>> On 11 Sep 1998 10:46:17 -0700 >>>>> Greg Badros said: [solaris] Greg> Note that the xterm's process group ID and session ID are Greg> separate from the guile that started it. [linux] Greg> Here the xterm has the same sesion and process group IDs as the Greg> guile. It also has the same terminal process group id. This is very probably due to differences in /bin/sh on these platforms. It seems that sh on Solaris and others are creating a new session even for non-interactive shells. Looks like a bug or misfeature. Greg> Why do we care? Many of you probably don't need to, really. I Greg> was concerned because all the xterm-s that I started under scwm Greg> were dying when I hit C-c on the scwm process (running in a tty Greg> for testing) that started them. Why wasn't scwm exiting upon SIGINT? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Sep 21 10:55:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA20785 for scwm-discuss-outgoing; Mon, 21 Sep 1998 10:55:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA20782 for ; Mon, 21 Sep 1998 10:55:05 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26826; Mon, 21 Sep 98 10:54:20 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA07443; Mon, 21 Sep 1998 07:54:50 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <19980913235817.A5618@ZengHe.issy.cnet.fr> From: Greg Badros Date: 21 Sep 1998 07:54:49 -0700 In-Reply-To: Robert Bihlmeyer's message of "20 Sep 1998 16:13:15 +0200" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On Sun, 13 Sep 1998 23:58:17 +0200 > >>>>> Francois-Rene Rideau said: > > FRR> For instance, I just do want many apps to be fullscreen > FRR> (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > FRR> depending on decoration sizes so they fit; > > Something like this should work: > > (X-property-set! 'root-window "RESOURCE_MANAGER" > (string-append > "gv.geometry: " > (number->string (- (car (display-size)) 5)) "x" > (number->string (- (cadr (display-size)) 17)) "\n") > "STRING" 8 'append) I don't recommend this, though -- it'll erase all the other resources (they're all stored under that single property). Also note that display-width and display-height are variables which are preset to the result of (car (display-size)) and (cadr (display-size)), resp (see scheme/base.scm). Greg From owner-scwm-discuss@mit.edu Mon Sep 21 12:33:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21446 for scwm-discuss-outgoing; Mon, 21 Sep 1998 12:33:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21439; Mon, 21 Sep 1998 12:33:33 -0400 Message-Id: <199809211633.MAA21439@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm user report In-reply-to: Your message of "21 Sep 1998 07:54:49 PDT." Date: Mon, 21 Sep 1998 12:33:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Robert Bihlmeyer writes: > > > Hi, > > > > >>>>> On Sun, 13 Sep 1998 23:58:17 +0200 > > >>>>> Francois-Rene Rideau said: > > > > FRR> For instance, I just do want many apps to be fullscreen > > FRR> (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > > FRR> depending on decoration sizes so they fit; > > > > Something like this should work: > > > > (X-property-set! 'root-window "RESOURCE_MANAGER" > > (string-append > > "gv.geometry: " > > (number->string (- (car (display-size)) 5)) "x" > > (number->string (- (cadr (display-size)) 17)) "\n") > > "STRING" 8 'append) > > I don't recommend this, though -- it'll erase all the other resources > (they're all stored under that single property). > This operation appends to the property so I can't see how it would do that (unless there are null-termination issues). Actually, this is one reason I wanted X-property-set! to be called X-property-change! originally - it's closer to the X11 name (XChangeProperty) and makes clear that the property may be modified instead of replaced. > Also note that display-width and display-height are variables which are > preset to the result of (car (display-size)) and (cadr (display-size)), > resp (see scheme/base.scm). > Yeah. What I don't like about it is the magic constants of 5 and 17. Are these supposed to account for the space taken by the title bar and frame? There's got to be a better way to do that. Or if not, there should be. From owner-scwm-discuss@mit.edu Mon Sep 21 12:45:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21557 for scwm-discuss-outgoing; Mon, 21 Sep 1998 12:45:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA21554 for ; Mon, 21 Sep 1998 12:45:53 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA24451; Mon, 21 Sep 98 12:45:48 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07592; Mon, 21 Sep 1998 09:45:48 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Comments on the latest version of the event model proposal References: <199809210127.VAA15607@huis-clos.mit.edu> From: Greg Badros Date: 21 Sep 1998 09:45:47 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 20 Sep 1998 21:27:08 EDT" Message-Id: Lines: 734 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > First off, apologies for the delay in responding to this message. I > have been really busy with starting my new job and all. Greg, if you > don't manage to get the new event model stuff in before you are hosed > again, I will implement it myself according to a spec we can get > consensus on. Yeah, it's getting pretty tight for me, so perhaps I will defer to you. My general exam begins in 9-10 days and other responsibilities for the fall resume in 2 days. I'll try to focus my energies on my research with constraints and their use in scwm to try to make them more useful, expressive and efficient. > In the comments below, I will remove changes I suggested that you > agreed with, and concentrate on our remaining points of disagreement. Ok. Me too. > > > I will respond to this section in whole, because I have pervasive > > > changes to suggest. First of all, I think event specifiers should be > > > different from event objects, and most of this section deals with > > > specifiers. I suggest the following changes to the interface for > > > event-specs: > > > > > > ** EVENT-SPECS ** > > > > > > -- Creating Event Specs -- > > > > > > (make-event-spec EVENT-TYPE #&rest FIELD-SPECS) > > > > > > EVENT-TYPE is a symbol identifying the type of X event. It should also > > > include some events synthesized by scwm itself which are provided for > > > convenience (mouse-click, mouse-double-click, mouse-single-click, etc). > > > > > > It should include at least the following (symbolic names, X11 names > > > where appropriate, and brief explanations are given): > > > > > > 'key-down (KeyPress) > > > 'key-up (KeyRelease) > > > 'mouse-down (ButtonPress) > > > 'mouse-up (ButtonRelease) > > > 'mouse-drag (MotionNotify with at least one button down) > > > 'mouse-move (MotionNotify with no mouse buttons down) > > > 'mouse-click (A ButtonRelease that happens in the same window as a > > > ButtonPress, but does not consitute the second click > > > of a double click > > > 'mouse-double-click (If the conditions for a mouse-click happen within some > > > > given time limit, a mouse-double-click is sent instead > > > perhaps a movement threshold should also be provided) > > > 'mouse-single-click (A click followed by enough time to definitively not > > > constitute a double click. To summarize, when the mous > e > > > is single-clicked, 'mouse-click is sent immediately, > > > and 'mouse-single-click is sent after the double click > > > delay time passes. When it is double-clicked, 'mouse-c > lick > > > is sent immediately after the first click, and > > > 'mouse-double-click is sent immediately after the seco > nd; > > > 'mouse-single-click is not sent at all. 'mouse-up is s > ent > > > on each release of the mouse in both cases. This shoul > d > > > allow the full desired set of single-click semantics.) > > > > This is a good summary of the semantics that I think we already have a > > consensus for. The big change here is folding the creation of the event > > specifiers into a single primitive, which seems reasonable. I was a bit > > vague about event objects vs. event specifiers, and the distinction you > > draw is good. > > > > I strongly dislike the gratuitous and potentially confusing renaming of > > X events. I am fine with scheme-ifying the names, but an X11 KeyPress > > should be 'key-press, not 'key-down, and MotionNotify should be > > 'motion-notify w/ the buttons down filter as part of the FIELD-SPECS. > > > > OK, agreed on the key ones. However, I think we should rename the > mouse events because we are going to have at least some changes in > semantics and split some into more than one, plus I think mouse-down > is a _lot_ more clear than button-press. Fine. > I also think we should keep motion-notify split into mouse-drag and > mouse-move because in every GUI, the usages of these two user actions > are near-universally almost totally unrelated. X11 does actually let > you select for one or the other, the event just happens to be named > the same thing because it easily could be. But I don't necessarily > think it is a good idea to expose that implementation detail of X11. Only when they affect what we can do reasonably efficiently (see comments below). > See my comments below on how literally we should provide the X event > interface. > > > > > > WRT ColormapNotify, it's useful because (I'm quoting you): > > > > o Providing a complete interface that allows people to implement > > desired capablities which can not be achieved with the current event > > binding infrastructure; this will likely include capablities that we > > feel no need to provide a more convenient interface for, but that some > > users may desire anyway. > > > > :-) > > > > I was wondering more along the lines of, is there a use _any_one has > for this? I don't care if I think it's a good uae, but I find it hard > to see why user code would care at all ever. Is this something that > was just stuck on the list because it could be, or is there a reason > for it to be there? Sure, on an 8 bit display one might want to decorate windows with a private colormap differently so the user is aware that moving into that window will cause the rainbow-effect elsewhere as the palette is altered. I'm not sure how important this event is in supporting this interaction, but it seems potentially useful to me. > We could take two approaches in the low-level event infrastructure. We > could either provide a fairly literal translation of what X provides, > or we could try to make it a bit cleaner and more orthogonal to reduce > the amount of abstraction we have to put between it and the user to > present an interface that's both powerful and convenient. I prefer to > make the low-level abstractions more clear and orthogonal than X > itself is. This is my motivation in splitting drags from moves and in > not handling events that users will not care about. However, in any > given case, even one example of something that cannot otherwise be > done easily is sufficient to change my mind. I'm slightly more conservative about trying to add abstractions over X in our most primitive level for performance reasons and design-mismatch concerns... these specific changes you suggest seem harmless and usefull. > > > * Synthetic events that could be added: > > > > > > 'mouse-one-and-a-half-click (A mouse click followed by a drag within > > > the double click timeout - perhaps 'mouse-click-and-drag is a better > > > name), 'mouse-triple-click (supported by Gtk, but probably not widely > > > used), and 'mouse-double-click-and-drag (for orthogonality if the > > > previous two are supported). Alternatively, a convenient way to mix > > > timers with event maps may allow these (as well as orinary click > > > events) to be synthesized by higher layers. > > > > I think higher layers should deal with this. They are clearly > > implementable given the other accessible infrastructure. > > > > In that case we could reconsider wether to explicitly provide any of > the abstractions we otherwise would on top of mouse-down and mouse-up > (all the click and double-click stuff). OTOH it is desirable to > optimize the common cases and to provide access to such higher-level > events through the same event-map interface. Perhaps we could allow > the user to define new event types, but this opens a whole new > exciting can of worms. We should provide for the common (and suggested) cases initially -- i.e. single and double clicks. Later if something more general is written in scheme using a FSM and mouse-{down,up}, we could rip out our two special cases w/o any big deal. > > > * X events that should be supported in a different way, because > > > attaching them to window-based event maps is illogical or inefficient: > > > > > > CreateNotify, DestroyNotify > > > > > > (in my opinion, these are better handled by special-case hooks. The > > > former is illogical because it would not be in a window's event map > > > until _after_ the window is created. The latter we only care about for > > > top-level windows and probably want to handle specially to avoid race > > > conditions). > > > > I think that the special case hooks can exist for top level scheme > > windows, but unless implementing these causes undo hardship (which I'm > > pretty certain they won't), it's worth keeping them for consistency and > > completeness. In particular, CreateNotify is *not* illogical if > > selected for on the root window. > > > > I don't know - I'm not entirely certain that it will make things more > consistent in the end for us to treat everything as an event that X11 > does. Events are really the only callback mechanism X11 has, and are > overloaded to handle many tasks. We have the opportunity to handle > some of these tasks differently. But if we can keep the event-based view of these things at little or no effort, why shouldn't we? And once we have the event-based view, we can choose to implement the hooks using the event mechanism if we choose (it's easy enough to do in C code that it's probably no big difference either way). I'm hesitant to give up the event model on the root window just because we think callbacks make more sense there (I want my cake [event model] and eat it too [callbacks]). > > > * X events ignored for now, though we may want to support them later: > > > > > > KeymapNotify, Expose, GraphicsExpose, NoExpose, UnmapNotify, > > > MapNotify, MapRequest, ReparentNotify, ConfigureNotify, > > > ConfigureRequest, GravityNotify, ResizeRequest, CirculateNotify, > > > CirculateRequest, SelectionClear, SelectionRequest, SelectionNotify, > > > ClientMessage > > > > > > ClientMessage may be especially useful to add, for the purpose of > > > supporting custom protocols. > > > > All of these should be potentially handle-able. Hopefully there won't > > be too much per-event work that needs to be done in the implementation. > > I.e., we should get most of these for free. > > > > I don't think so; some are hard to select explicitly, each has a > different XFooEvent structure that goes along with it, and we will > need to make the implementation of event-specs more complicated for > each. Further, adding more stuff to an interface is not always > good. Excessive options that are never needed serve only to confuse > the user. We consider for each event whether notifying the user of it > is ever meaningful. I am quite willing to bet that, for instance, > GraphicsExpose is totally useless from the Scheme level given the fact > that redraws are managed entirely by C code. For some of these events > an argument might be made that they are useful from the Scheme level, > but I am saying here that I'd rather wait to hear this argument. I've got no problem with implementing the more generally useful stuff first... but when we're talking about design, we need to assume that any of the events might need to be handled. > > There are also some visibility events that are missing from the above > > that would be potentially useful to exploit. > > > > There are? I listed visibility-notify with the provided events above, > and since I copied the list of events from an X11 header file, I doubt > I missed any. Sorry, you're right. I had already mentally split the VisibilityNotify event into 3 separate events according to the state member: VisibilityUnobscured, VisibilityPartiallyObscured, and VisibilityFullyObscured. > > I think that the global map can handle these events more elegantly. If > > the map happens to want to call a hook, that's fine (we need a way to > > invoke a hook from scheme don't we?). > > > > It can be done with trivial amounts of Scheme code (there is already a > `run-hooks' in Guile which is the equivalent of call0_hooks). So we should add call[n]-hooks to our scheme interface, too. > > > FIELD-SPECS is a list of specifiers for particular fields. The nature > > > of a field specifier will be described first; then five possible > > > syntaxes for the field specifiers will be proposed. > > > > > > A field specifier is a field used for filtering events according to > > > particular fields (see the discussion of fields below in the section > > > on event objects to see which events support what fields). It may be > > > either an exact field value, which must be matched, the symbol '*, to > > > indicate that this field should be ignored entirely when matching > > > events, a procedure which should be a predicate of one argument, or > > > possibly a special other value which is available for some fields. An > > > event matches an event specifier if its type is the same, and all of > > > its fields individually match the event specifier fields. An event > > > field matches an event specifier field if any of the followind is > > > true: > > > > > > * The value of the event field is identical to the event-spec field > > > * The event-spec field in question has a value of '* > > > * The event-spec field is a procedure, and returns a true value when > > > applied to the event field. > > > > I don't like procedures used as filters. It requires us to either > > analyze the procedure to find out what it'll return #t for, or to just > > throw up our arms and Select a really general event and then call the > > procedure exceedingly often on events that we're not interested in. As > > much of the filtering as possible must be done by X11 (by not Selecting > > inappropriate events), another bit done by C code (when X doesn't > > provide the means to filter it directly), and the rest should be done by > > the called procedure. If that called procedure wants to have a > > scheme-level filtering procedure, it can, but the C level needn't worry > > about that (and it'll discourage such things). > > > > There's a specific reason I added them. I agree with you that we want > to let as much filtering as possible be done by X11. However, the > constraints X11 can use for filtering and the fields they can be > applied to are extremely limited. Doing filtering in C code (instead of at the server) can be really expensive -- calling out to scheme to do further filtering seems like it's too much work. When truly necessary, it can easily be done by binding to a filtering function that then calls the real function if the event passes the filter. I just don't want to encourage filtering of events done in scheme because A) it can be a huge performance hit to have to see the plethora of messages that are uninteresting (filtered out) and B) the proc-based filtering is redundant (by being more general) with the more-highly optimized filtering that permits reasonable performance by exposing enough information to let us perform better select-s in the server. > For the case of '* above (which I am > sure you will agree is critical for a complete interface), we will Not needed if you don't do filtering except where that filtering influences the X select configuration or so useful that it's worth doing in C (e.g., within a gadget's rectangle [e.g., a menuitem] in a ButtonPress event). > already need to select on a really general event. I would like to > provide something appropriate for the fourth category of event-spec > values for all common cases where we can do useful filtering, as with > modifiers. But I think letting the event-spec interface be fully > general is a good thing. As long as we are doing _some_ filtering at > this level, we may as well make it fully general and allow the user to > do any filtering he wants. Again, I don't see why X11's arbitrary > limitations and non-orthogonalities must become ours. It's certainly For performance, it's better if we not fight the event model that X gives us. Naove users need to recognize that there is something fundamentally different about events that the server can filter and those that we're going to get anyway and have to run code on every time we receive them. (Note that my complaint would disappear if the X server let us "download" our filtering code into the server in the same general way that you want to do it from w/i scwm -- since that's not gonna happen, I'd prefer the more restricted interface to make obvious the distinction.) > not the intent that you'd provide a predicate on keysyms instead of an > actual keysym in the usual case, but you should be able to for those > cases when you really really need to. If proc-filtering were provided, I'd think: "But it's so much cleaner to provide the predicate on keysyms too (the general mechanism extends more gracefully, so it should be used all the time)". Thus sacrificing performance dramatically. Granted we can just document that it's important to use the specific filtering arguments when applicable, but I still think it's not so hard to do the proc filtering completely in scheme that it's worth not providing a performance-questionable feature in the primitive layer. > > > * The event-spec field is a special field-specific specifier and > > > matches according to the relevant rules. > > > > > > The only special event-spec field value reccomended by now is the > > > following for the 'modifiers field in many events: > > > > > > A pair of two lists can be accepted for a 'modifiers event-spec field; > > > the first list is the list of names of modifiers that must be on, and > > > the second is a list of modifers names that must be off. A modifiernnnnn > > > not present in either list is ignored entirely. > > > > I prefer the list of symbols that can specify either on or off. An > > earlier draft had a must-be-on and a must-be-off list which was decided > > inadequate for another reason (it expose bitmasks instead of symbolic > > modifiers), but in that rewrite I really liked the new version's > > similarity to X resource modifier configurations. The > > MODIFIER-SPECIFIER in events.gjb is a bit higher-level -- in particular, > > the pseudo-specifiers 'exactly and 'with are nice because then you don't > > have to name all the other modifiers to say "not these". I know that we > > could provide that functionality in scheme, but it's pretty easy to do > > in C, too. > > > > Well, there are really three sets of modifiers to think about here, > must-be-on, must-be-off, and don't-care; since these three must be > mutually exclusive and exhaustive, the simplest interface is to let > the user specify exactly two sets. I'd be happy enough with a list > that allows ~modifiers or *modifiers along with modifiers, but not > both. In fact, I'd actually prefer requireds and don't cares to be > specified, because IMO a modifier should be assumed to be unwanted > unless you explicitly say otherwise. When I ask to bind Control-x, I > hardly ever mean that I don't care what other modifiers besides > Control are down. And the common case should be the easiest to > specify. I disagree... I might often mean C-x or C-X (*shift) and almost always mean *NumLock. > I don't like the 'exactly and 'with conventions at all. 'with is > exteremely ambiguous unles you already know what it means; what it > should be assumed, but this should be done on a higher level. 'exactly > I consider evil because it should be (as I said above) the default; > don't cares should be specified explictly, not assumed by default, > since they are hardly ever what you intend. Nobody wants to have to specify *NumLock, etc., every time. > In my opinion, there are only two ways of splitting it up that make > sense: either a single make-event-spec, or a separate > make--event-spec for each type of event that has a different X11 > event structure. Splitting into 3 quasi-arbitrary categories is IMO > not a good plan. > They were split based on the kinds of filtering that would need to be done and in thinking about what kinds of events need to be treated differently internally. As a result, the categories also correspond to the kinds of arguments that the event-specifier constructs would take. > > > o Making event filtering simple and uniform: IMO, this is the right > > > thing for the low-level interface. We can pick convenient subsets of > > > the functionality w/ convenient interfaces for the higher-level > > > version. The whole decision about the user's intentions when trying to > > > bind key events, for instance, can be punted to a higher level. > > > > I agree, but I'm not convinced that the single primitive is simpler in > > any useful way relative to the three primitives in the earlier draft. > > You just move the complexity into the processing of the FIELD-SPECS of > > the one primitive. > > > > This was not referring so much to the single make-event-spec primitive > as to the fact that (a) you can filter on any field of an event; and > (b) because '* (meaning "any") and predicate filters are provided, you > can filter in any way you want (although the common cases are all > optimized). > > > > Here is a list of which events have which fields: > > > > > > All events: 'synthetic 'window > > > All mouse and key events: 'root 'subwindow 'x 'y 'x-root 'time 'modifiers > > > 'buttons > > > > 'subwindow might need to be subwindow-id (a number) -- we don't want to wrap > > subwindows, I'd think. > > > > 'window is meant to be a window ID as well, not a window object. I > wouldn't be opposed to appending -id to both of these names for the > sake of clarity. I concur. 'window is ambiguous. [now talking about binding events to procedures] > > I think this is a hack, and didn't want to do it at the event-binding > > area. I like Emacs' `interactive' a lot better, where with the command > > (proc) you specify what arguments it is expected to take. It also has > > the advantages of documenting what procedures are meant to be bound to > > events, and may provide better printable forms (even if it's a closure). > > We can simulate your ARGS-DESIRED argument with a set of standard > > closures, but I still think that the place that should be deciding that > > is the code that's gonna run (the proc, not the point of binding). > > > > I don't have a sense of how hard adding `interactive' declarations would > > be, but I imagine Jim Blandy could pull it off or provide some help as > > we need it. > > > > I have the exact opposite feeling - I think things like `interactive' > are a hack, and what arguments to pass to a proc should be determined > at the time you bind it to something. I say this because I don't think > that some special set of procedures that take a window should be > specially identified as being meant to be bound to events; you should > be able to bind *any* procedure that takes arguments in one of the > appropriate formats to an event without the need to declare a helper > proc that has a special declaration. > > In general, I have a very strong feeling that the decision on what > arguements to pass should be made by the caller, i.e. the event-map > (as specified by the user making the binding) rather than the > procedure, because the procedure cannot possibly anticipate all of the > places it might be used in. > > And I think `interactive' in emacs is intended to solve a very > different problem from the fact that event bindings may care about > different sets of information; as I understand it, it exists primarily > to allow a function to either take an argument when called in code, or > to interactively query the user with a specified prompt. > > We could discuss further how exactly to specify what args a procedure > wants, but I feel very strongly that this should be specified at the > time of binding, not at the time of declaring the proc. My thoughts are much more fuzzy on these issues, so I'll defer as it sounds you have thought harder about this stuff. > On the other hand, some procedures will likely want the event object > to work right but we don't want the user to know or care > (e.g. interactive-move); perhaps a hybrid approach involving bind-time > specification, but also a special procedure property that gives the > correct value for specially declared procedures would work best. I > don't want it to look like (interactive) though, because IMO making > random forms in a procedure have a magical declarative effect confuses > the semantics of the language (and confuses me when thinking about how > the heck to implement them). I'd rather see define-command and/or > lambda-command macros which contain the additional declaration and set > the procedure property according to an extra arg. I agree completely re: goofy declarations being bad. As I was thinking about this more last week, I changed my mind in favor of macros that provide conversion lambdas to make the passed arguments meet the specs of the procedure. I do think it's good that commands meant to be bound to an event be so documented. > > > Implementation notes: obviously, scwm should ask the server to not > > > send it events it is not interested in. > > > > Rephrased to be more precise... scwm will select only the events in > > which it is interested, and do all the appropriate grab-keys, etc. This > > is part of the problem with the less-restricted lambda-filtering you > > suggested. > > > > Note that the lambda filtering was suggested _in addition to_, and not > _instead of_ specifications which can be used to generate the proper > grabs automatically. lambda-filtering does not introduce any problems > that '* (don't care) filtering doesn't already. And we need '* for > completeness. I'm not sure how you mean. No filtering is very different than lambda filtering. > > *3*, 4, and 5 are all subsumed by the first-class event objects distinct from > > event-specifiers --- they are folded into #2. > > > > Umm, I think the window-id in the X event structure is not necessarily > always the window-id of the window that received the event, in the > case of some X events; so the info is not necessarily redundant. I > need to reread the relevant part of the Xlib programming manual I > guess. You're right... sometimes the window-id might be the title bar, or a corner window, etc. > > I think the event-map object is useful as a place to hang > > extra-properties off of... given the notion of a binding-object, though, > > that should replace the event-map object, as it'll have to have an > > accessor querying the event map to which it corresponds. > > > > I suspect the desire to hang info off of the event-map or binding > object is neither the world's greatest plan, or a likely common > useage; if someone really wants it, they can simulate it with > appropriate closures, e.g. > > (define (some-proc-that-really-wants-an-event-map window event event-map) > ;; do some stuff > ) > > (event-map-add-binding! my-event-map > (let ((event-map my-event-map)) > (lambda (window event) > (some-proc-that-really-wants-an-event-map > window event event-map)))) > > Voila! > > So I think we should provide context information only if it is both > commonly desired and impossibly to get otherwise (both of these being > true of the event object and the window object). Ok. > > > PART-NAME is a symbol that is one of the following: > > > 'frame (the top-level frame window) > > > 'title > > > 'side-north > > > 'side-east > > > 'side-south > > > 'side-west > > > 'corner-ne > > > 'corner-nw > > > 'corner-se > > > 'corner-sw > > > > either the side directions should be dropped to n,e,s,w or the corner > > ones should be spelled out. > > > > OK, full spelling then (although I don't think the abbreviation > threshold I used was illogical). Yeah, I changed my mind on this. I don't want to write out northeast. I'd prefer either your original suggestion or 'side-n, 'side-e, etc. > > I was thinking that 'side should be the geometrical parent of each of > > the four 'side-[nesw]. Then the binding only occurs in that one map, > > and the intent is preserved. One shouldn't later be able to > > `event-map-remove' just the binding for 'side-n and leave the other > > three windows bound. > > > > I don't believe it is possible to do this for both sides and corners > simultaneously without using the Shape extension because the screen > geometry just doesn't work. Let's not depend on it for such simple > things. Sorry, I was confusing: I didn't mean that they should literally be parents in the window hierarchy, only that the dispatcher should treat them as such. i.e., events can be attached to just 'side, which is treated as a parent of all the 'side-* windows by the dispatching. > > > (alias-window-part WINDOW ALIAS-NAME ORIGINAL-NAME) > > > > > > For WINDOW, allow ALIAS-NAME to be treated the same as ORIGINAL-NAME > > > for the purpose of window-part-id. ORIGINAL-NAME may be a part name or > > > a list of part names. WINDOW may also be #t to indicate a global > > > alias. > > > > > > The following global aliases are pre-defined: > > > > > > 'side => '(side-east side-west side-north side-south) > > > 'corner => '(corner-ne corner-nw corner-se corner-sw) > > > > This is unnecessary given my above comments. > > > > > > > > The following should be defined conventionally to ease > > > look-independent binding of buttons: > > > > > > 'system-button > > > 'maximize-button > > > 'minimize-button > > > 'close-button > > > > Can't these just be variables? > > > > I suggest the aliases for a particular reason. I want to come up with > a system for people to distribute theme files that specify the look of > the window manager, but still leave it to the user to specify > behaviors in his or her own scwmrc. To achieve this with maximum > transparency, we need logical button names, since different looks will > likely have the buttons with the same general purpose in different > places, but the user wants to be able > > Variables are insufficient, because themes ought to be settable > per-window; it needs to be some kind of property of the window. Ok, but I'd prefer aliases be a 1-1 mapping, and the relationship between 'side-* and 'side be modelled internally (and similarly for 'corner and 'corner-*). > > > > > > > (event-map-for X-WINDOW-ID) > > > > ;; Return the currently attach event-map object, if any, or #f > > > > > > Suggest renaming this to something like get-event-map, > > > window-id-event-map, or something. IMO prepositions in procedure names > > > should be used very sparingly. > > > > This rename I don't like -- the primary reason I liked the other renames > > was because it kept event-map at the beginning of the procedure name. > > event-map-for-window-id would be fine. > > > > I think this function is logically different from the others in a way > that makes it desirable _not_ to prefix it with event-map-. In > particular, the Scheme convention as I understand it is that > procedures should be prefixed with a data type when they are > understood to be primarily operating on objects of that data type in > some sense (e.g. vector-set!, string-ref, etc). To me, this operation > is primarily operating on the window ID I still disagree, I suppose, but I don't care that much on this point. > > My three primitives are more clear, easier to > > implement, and more nicely restricted than the make-event-spec that you > > specify. > > I don't think the additional restrictions net you anything; and I > specifically _don't_ think they are more clear, in particular, > make-x-event needs to be nearly as complex as make-event if not more > so to provide the same functionality. Not if make-x-event-spec does no filtering (if we're talking about the event objects, then I agree-- those can be wrapped separately with individual constructors). > > Think of my three primitives (make-key-event, > > make-mouse-event, make-x-event) as three constructors to an event > > specifier object. You're trying to overload a single ctr to make all > > three kinds of event specifiers, whereas I'm exploiting their > > differences to simplify their interfaces and implementation. > > I don't mind exploiting differences, _but_ if we do this, we should > make distinctions between all events that are actually in fact > different rather than sorting them into three semi-arbitrary bins. > > I'm for either one way of making event-specs (and events) or a > different constructor for each type X has a different event structure > for. In fact, I would even suggest taking different tracks for specs > and events; have a whole bunch of constructors for event objects, > since each type of event needs an exact set of mandatory fields, and a > single one for event specs, since for these everything but the event > type should by rights be optional, and many fields (those we can't > select for easily from the server or from C code) will be handled in a > totally parallel way, I'd expect. I agree about events being separate ctrs. > > This is > > perfectly reasonable given that there is a natural distinction among the > > three kinds of events (e.g., a user knows which primitive to invoke). > > > > Yes, but there are also equally natural distinctions between some of the > things you have grouped together. > > > I'll wait for another round of comments from you and others before > > integrating the changes we've discussed so far into the repository's > > proposal. > > > > One thing I forgot to suggest before is a procedure > `event-matches-event-spec?', a predicate which allows the user to > check whether an event matches a spec. I didn't think of a real use > but it seemed like it might be a handy thing to have around. Sure. Greg From owner-scwm-discuss@mit.edu Mon Sep 21 12:52:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA21652 for scwm-discuss-outgoing; Mon, 21 Sep 1998 12:52:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA21648 for ; Mon, 21 Sep 1998 12:52:16 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26361; Mon, 21 Sep 98 12:52:11 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07632; Mon, 21 Sep 1998 09:52:11 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <199809211633.MAA21439@huis-clos.mit.edu> From: Greg Badros Date: 21 Sep 1998 09:52:10 -0700 In-Reply-To: Maciej Stachowiak's message of "Mon, 21 Sep 1998 12:33:32 EDT" Message-Id: Lines: 58 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Robert Bihlmeyer writes: > > > > > Hi, > > > > > > >>>>> On Sun, 13 Sep 1998 23:58:17 +0200 > > > >>>>> Francois-Rene Rideau said: > > > > > > FRR> For instance, I just do want many apps to be fullscreen > > > FRR> (netscape, xdvi, gv, etc). scwm should modify the Xdefaults > > > FRR> depending on decoration sizes so they fit; > > > > > > Something like this should work: > > > > > > (X-property-set! 'root-window "RESOURCE_MANAGER" > > > (string-append > > > "gv.geometry: " > > > (number->string (- (car (display-size)) 5)) "x" > > > (number->string (- (cadr (display-size)) 17)) "\n") > > > "STRING" 8 'append) > > > > I don't recommend this, though -- it'll erase all the other resources > > (they're all stored under that single property). > > > > This operation appends to the property so I can't see how it would > do that (unless there are null-termination issues). Argh.. yep -- I missed the 'append. Though it still would do the wrong thing if the code ran multiple times. Managing the property directly is the wrong way to do this stuff. > Actually, this is one reason I wanted X-property-set! to be called > X-property-change! originally - it's closer to the X11 name > (XChangeProperty) and makes clear that the property may be modified > instead of replaced. I agree (obviously, since the above fooled me!) -- X-property-append! and X-property-prepend! should probably be added in scheme, and X-property-set! should default to 'replace mode. > > Also note that display-width and display-height are variables which are > > preset to the result of (car (display-size)) and (cadr (display-size)), > > resp (see scheme/base.scm). > > > > Yeah. What I don't like about it is the magic constants of 5 and > 17. Are these supposed to account for the space taken by the title bar > and frame? There's got to be a better way to do that. Or if not, there > should be. A couple of weeks ago I added a couple of gettors `window-title-size' and `window-frame-border-width' that might be useful here. Greg From owner-scwm-discuss@mit.edu Mon Sep 21 18:33:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23636 for scwm-discuss-outgoing; Mon, 21 Sep 1998 18:33:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23633 for ; Mon, 21 Sep 1998 18:33:14 -0400 Received: from fecundity.webcoi.com by MIT.EDU with SMTP id AA19976; Mon, 21 Sep 98 18:33:10 EDT Received: (from jtl@localhost) by fecundity.webcoi.com (8.8.7/8.8.7) id PAA25586; Mon, 21 Sep 1998 15:36:12 -0700 Message-Id: <19980921153612.18312@molehill.org> Date: Mon, 21 Sep 1998 15:36:12 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: useful synthetic events Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-scwm-discuss@mit.edu Precedence: bulk (define (find-window class resource) (car (list-windows #:only (lambda (w) (and (string=? (window-class w) class) (string=? (window-resource w) resource)))))) (define (rvplayer-pauseplay) (let* ((curpos (pointer-position)) (rvwin (find-window "rvplayer" "rvplayer")) (rvpos (window-position rvwin)) (newpos (list (+ 54 (car rvpos)) (+ 74 (cadr rvpos))))) (apply move-pointer-to newpos) (send-button-press 1 rvwin) (apply move-pointer-to curpos))) This sometimes works, but at a minimum, it seems the real player window has to be on the current viewport and mapped. Additionally, in focus-follows-mouse mode, if the pointer isn't in the window that has focus at when executing rvplayer-pauseplay, the focus changes. Is there a better way to do this? -- "You keep claiming things don't work. Im just going to sit here proving they do. If you play this game for long enough we might even find a real library bug" -- Alan Cox From owner-scwm-discuss@mit.edu Mon Sep 21 19:35:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23999 for scwm-discuss-outgoing; Mon, 21 Sep 1998 19:35:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA23996 for ; Mon, 21 Sep 1998 19:35:48 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA25978; Mon, 21 Sep 98 19:34:56 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id TAA10869; Mon, 21 Sep 1998 19:35:45 -0400 (EDT) Message-Id: <199809212335.TAA10869@jekyll.piermont.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: snapshot and anoncvs downtime In-Reply-To: Your message of "Sun, 20 Sep 1998 17:01:30 EDT." <199809202101.RAA13492@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 21 Sep 1998 19:35:44 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > It's all fixed now. I also added cvsweb to the web site (see > http://huis-clos.mit.edu/cgi-bin/cvsweb to get there directly). I am > now trying to set up GNATS - does anyone know where I can find a good > web interface for it? Look at www.netbsd.org -- we have an "okay" interface. let me know if you like it -- I could then see about getting you a copy. .pm From owner-scwm-discuss@mit.edu Mon Sep 21 20:51:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA24465 for scwm-discuss-outgoing; Mon, 21 Sep 1998 20:51:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA24462 for ; Mon, 21 Sep 1998 20:51:28 -0400 Received: from md12-210.mun.compuserve.com by MIT.EDU with SMTP id AA11634; Mon, 21 Sep 98 20:50:33 EDT Received: (from forcer@localhost) by forcix.roof.lan (8.9.1/8.9.1) id CAA26258 for scwm-discuss@mit.edu; Tue, 22 Sep 1998 02:51:30 +0200 Message-Id: <19980922025129.A26186@forcix.roof.lan> Date: Tue, 22 Sep 1998 02:51:29 +0200 From: forcer To: scwm-discuss@mit.edu Subject: source for placing problems found Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux forcix 2.0.36 X-Url: http://webserver.de/forcer/ Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi there. I already stated once that i have problems with Scwm and the Click-to-place (random-placement #f, smart-placement #f) type of placement proc. I noticed that the rubber border for some windows were positioned below and right of the pointer, but didn't find any relationship there. Now i found the reason... It seems like Scwm is using the positioning hint of the window in relation to the current position of the pointer, e.g. if the window wanted to be placed 30 pixels left of the 0,0 coordinate of the current window, the rubber border for the placement got positioned 30 pixels right of the pointer. I'm using 1.3a (snapshot) and a current Scwm snapshot. I hope this provides enough information to fix this bug, as i'm not good enough in window manager programming to fix it myself :) Oh, and one other thing: it seems like scwm.el gets installed as /scwm.el if there's no emacs installed on the system. planning to replace /vmunix with /scwm.el? ;)) -forcer -- /* You ascii stupid question, you get stupid ansi. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Tue Sep 22 01:39:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA25881 for scwm-discuss-outgoing; Tue, 22 Sep 1998 01:39:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA25878 for ; Tue, 22 Sep 1998 01:39:49 -0400 Received: from smtp5.nwnexus.com by MIT.EDU with SMTP id AA00603; Tue, 22 Sep 98 01:38:52 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp5.nwnexus.com (8.8.8/8.8.8) with ESMTP id WAA29154 for ; Mon, 21 Sep 1998 22:39:45 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276553-15622>; Mon, 21 Sep 1998 21:44:34 -0700 To: scwm-discuss@mit.edu Cc: Robert Bihlmeyer Subject: Re: system(3) In-Reply-To: Your message of "20 Sep 1998 14:36:21 +0200." Date: Mon, 21 Sep 1998 21:44:30 -0600 From: Ken Pizzini Message-Id: <19980922044434Z276553-15622+10@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Why wasn't scwm exiting upon SIGINT? Because system(3) ignores SIGINT while its child is running, per POSIX.2 specification. --Ken Pizzini From owner-scwm-discuss@mit.edu Tue Sep 22 02:35:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA26169 for scwm-discuss-outgoing; Tue, 22 Sep 1998 02:35:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA26166 for ; Tue, 22 Sep 1998 02:35:08 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA05780; Tue, 22 Sep 98 02:34:10 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id XAA04738 for ; Mon, 21 Sep 1998 23:35:04 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15622>; Mon, 21 Sep 1998 23:14:08 -0700 To: scwm-discuss@mit.edu Subject: window size problem? Date: Mon, 21 Sep 1998 23:14:04 -0600 From: Ken Pizzini Message-Id: <19980922061408Z276516-15622+11@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk The width retured by the (window-title-size) below does not make sense to me. $ scwm --version Scwm Version post0.8a compiled on Sep 21 1998 at 22:44:31 RCS_ID=$Id: scwm.c,v 1.131 1998/09/18 07:13:11 jtl Exp $ Repository Timestamp: Fri Sep 18 03:28:48 EDT 1998 -- $Revision: 1.474 $ $ scwmrepl scwm> (define w (get-window)) # scwm> (window-frame-size w) (486 475) scwm> (window-size w) (484 459 80 35) scwm> (window-title-size w) (485 14) scwm> (window-frame-border-width w) 1 scwm> A possibly related symptom is that I sometimes notice some oddities in the drawing of the left edge of my title bar. Then again, this may be due to some other problem, as I also sometimes note oddities in the drawing of the top line of the title bar. To duplicate: . set up a window with #:border-width 1; . overlap some other window behind it, so that the upper-left corner of the #:border-width 1 window covers something which contrasts well with the title bar; . iconify the window below the #:border-width 1 window; . note how the top and left edges of the title bar retain pixels from the now-iconified window. --Ken Pizzini From owner-scwm-discuss@mit.edu Tue Sep 22 07:33:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA27781 for scwm-discuss-outgoing; Tue, 22 Sep 1998 07:33:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA27778 for ; Tue, 22 Sep 1998 07:33:09 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id NAA06264 for scwm-discuss@huis-clos.mit.edu; Tue, 22 Sep 1998 13:33:02 +0200 (MET DST) >Return-Path: Received: (qmail 8014 invoked by uid 115); 22 Sep 1998 11:21:50 -0000 To: scwm-discuss@mit.edu Subject: Re: Comments on the latest version of the event model proposal References: <199809210127.VAA15607@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) From: Robert Bihlmeyer Date: 22 Sep 1998 13:21:48 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 20 Sep 1998 21:27:08 EDT" Message-ID: Lines: 107 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, [aggressive snipping in effect] >>>>> On Sun, 20 Sep 1998 21:27:08 EDT >>>>> Maciej Stachowiak said: [Event naming] Maciej> [...], plus I think mouse-down is a _lot_ more clear than Maciej> button-press. For me the opposite is true. If we adopt key-press, button-press is the obvious extrapolation. Furthermore, regardless of us providing other mouse-events, if we have one with semantics equal to ButtonPress, it should be named likewise. Indeed, a nice distinction between low-level events (prefixed with button-) and events of higher semantic sophistication (named mouse-{click,drag,doubleclic,...}) arises. YMMV, obviously. Maciej> I also think we should keep motion-notify split into Maciej> mouse-drag and mouse-move because in every GUI, the usages of Maciej> these two user actions are near-universally almost totally Maciej> unrelated. Agreement. [Permit filtering events with lambdas?] Maciej> However, the constraints X11 can use for filtering and the Maciej> fields they can be applied to are extremely limited. For the Maciej> case of '* above (which I am sure you will agree is critical Maciej> for a complete interface), we will already need to select on Maciej> a really general event. To recap: (please correct me if I misunderstood) We want to a) outsource as much filtering as is possible to the X server b) filter the most of the cases (especially the common ones) in C c) and provide facilities to filter with Scheme code, for applications that were not anticipated. Maciej> When I ask to bind Control-x, I hardly ever mean that I don't Maciej> care what other modifiers besides Control are down. And the Maciej> common case should be the easiest to specify. I normally *do* mean that the status of NumLock is irrelevant. But adding NumLock to the don't-care-set of all key-bindings is cumbersome. I think there should be a list of modifiers that are ignored (defaulting to NumLock, ScrollLock). OTOH giving two sets (e.g. must-be-on and don't-care) is no longer sufficient then. Either have an optional third set, or (in the alternate syntax) permit "~mod" to cancel out the "ignoredness". Perhaps this is stuff for the high-level interface. I.e. have exactly two sets (must-be-on and don't-care) on low-level, and have the high-level-functions add each member of `ignored-modifiers' to don't-care unless it is explicitly mentioned as on or off. BTW, I'm also not too excited about 'exactly and 'with. [How to define command procedures] Maciej> I have the exact opposite feeling - I think things like Maciej> `interactive' are a hack, and what arguments to pass to a Maciej> proc should be determined at the time you bind it to Maciej> something. One possibility that has not been mentioned yet: Introspect about the arity of the given procedure and give it (if possible) exactly this amount of information. This would work right away for things like `close-window'. But `interactive-move' (and many others) would need a small lambda-wrapper to prevent the event from being passed as the second parameter (opaqueness in this case). Hmm, perhaps a variation on the following ... Maciej> On the other hand, some procedures will likely want the event Maciej> object to work right but we don't want the user to know or Maciej> care (e.g. interactive-move); perhaps a hybrid approach Maciej> involving bind-time specification, but also a special Maciej> procedure property that gives the correct value for specially Maciej> declared procedures would work best. ... would be better: What about a procedure-property that signals in which (if any) parameter the procedure expects the object, the event, etc. This could be wrapped in `define-command' and `lambda-command'. (procedure-property close-window 'interactive) => (1 0) ; only wants the scheme object (a window) in parmeter #1 (procedure-property my-interactive-move 'interactive) => (1 3) ; expects the window first, then opaqueness and finally the ; event to do something with it Or remember only the number of interactive arguments that are expected and restrict them to always come before all others and in a particular order. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 22 11:41:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28998 for scwm-discuss-outgoing; Tue, 22 Sep 1998 11:41:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA28994 for ; Tue, 22 Sep 1998 11:41:56 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id RAA24744 for scwm-discuss@huis-clos.mit.edu; Tue, 22 Sep 1998 17:41:53 +0200 (MET DST) >Return-Path: Received: (qmail 11891 invoked by uid 115); 22 Sep 1998 15:34:03 -0000 To: scwm-discuss@mit.edu Subject: guessing the correct desk X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) From: Robert Bihlmeyer Date: 22 Sep 1998 17:34:00 +0200 Message-ID: Lines: 27 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, in add_window.c the commandlines associated with new top-level windows are searched for options forcing the application to a specific desk: "-xrm" and "-workspace". While "-xrm" is understood (and unknown settings are ignored) by some (not all) X applications, I know of none that handles "-workspace". Yes, one can usually coax the program into interpreting "-workspace 2" as filenames, but than there are various unintended side-effects (complaints about files not found, etc.) I'd venture that this feature is next-to-useless, and vote for dropping it. No functionality is lost, since the same effect can be provided with: (set-current-desk! X) (execute CMD) Or, in the shell: scwmexec '(set-current-desk! X)' CMD Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 22 11:41:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28996 for scwm-discuss-outgoing; Tue, 22 Sep 1998 11:41:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA28986 for ; Tue, 22 Sep 1998 11:41:53 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id RAA24728 for scwm-discuss@huis-clos.mit.edu; Tue, 22 Sep 1998 17:41:50 +0200 (MET DST) >Return-Path: Received: (qmail 10821 invoked by uid 115); 22 Sep 1998 14:58:20 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm user report References: <199809211633.MAA21439@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) From: Robert Bihlmeyer Date: 22 Sep 1998 16:58:19 +0200 In-Reply-To: Greg Badros's message of "21 Sep 1998 09:52:10 -0700" Message-ID: Lines: 36 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 21 Sep 1998 09:52:10 -0700 >>>>> Greg Badros said: Greg> Argh.. yep -- I missed the 'append. Though it still would do Greg> the wrong thing if the code ran multiple times. Managing the Greg> property directly is the wrong way to do this stuff. Well, it works if used multiple times, but it works badly (leaving the old settings in). You'd either have to be more careful in Scheme, or rely on a C interface. xrm.c could be the one - but see my criticism in another mail. Greg> I agree (obviously, since the above fooled me!) -- Greg> X-property-append! and X-property-prepend! should probably be Greg> added in scheme, and X-property-set! should default to 'replace Greg> mode. The latter is already the case. I'll add `X-property-append!' and `-prepend!' - where? base.scm? Greg> A couple of weeks ago I added a couple of gettors Greg> `window-title-size' and `window-frame-border-width' that might Greg> be useful here. Indeed, the magic constants were only there because I was lazy in this is not the best way to do it anyhow. I just wanted to point into the vague direction where one would head if inclined to change the global X resources from scwm. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 22 11:41:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28999 for scwm-discuss-outgoing; Tue, 22 Sep 1998 11:41:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA28990 for ; Tue, 22 Sep 1998 11:41:54 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) id RAA24736 for scwm-discuss@huis-clos.mit.edu; Tue, 22 Sep 1998 17:41:52 +0200 (MET DST) >Return-Path: Received: (qmail 10910 invoked by uid 115); 22 Sep 1998 15:21:30 -0000 To: scwm-discuss@mit.edu Subject: xrm.c X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) From: Robert Bihlmeyer Date: 22 Sep 1998 17:21:29 +0200 Message-ID: Lines: 22 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, there are two primitives `X-resource-put' and `X-resource-get' in xrm.c which could be useful but aren't AFAIS. They change the resource database "db"[1], which is overwritten whenever a new window is added (in add_window.c). Even if this was prevented, the database pretty much exists in limbo (i.e. has no implications in the outside world). So what was the intention of these functions. As I have hinted in another mail, these facilities could be extended to permit changing of e.g. the global resource database (easier than changing the root-window's RESOURCE_MANAGER property directly). Robbe [1] Not the best name for a global variable, BTW. -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 22 11:51:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA29191 for scwm-discuss-outgoing; Tue, 22 Sep 1998 11:51:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA29188 for ; Tue, 22 Sep 1998 11:51:36 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16772; Tue, 22 Sep 98 11:51:32 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28226; Tue, 22 Sep 1998 08:51:31 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: source for placing problems found References: <19980922025129.A26186@forcix.roof.lan> From: Greg Badros Date: 22 Sep 1998 08:51:30 -0700 In-Reply-To: forcer's message of "Tue, 22 Sep 1998 02:51:29 +0200" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk forcer writes: > Hi there. > I already stated once that i have problems with Scwm and the Click-to-place > (random-placement #f, smart-placement #f) type of placement proc. > I noticed that the rubber border for some windows were positioned below and > right of the pointer, but didn't find any relationship there. > Now i found the reason... It seems like Scwm is using the positioning hint > of the window in relation to the current position of the pointer, e.g. > if the window wanted to be placed 30 pixels left of the 0,0 coordinate > of the current window, the rubber border for the placement got positioned > 30 pixels right of the pointer. Can you give a specific example of an application that starts up as you describe so I can reproduce this? On a related note, I noticed that the placement code with random & smart placement off does not handle xmag properly -- InteractiveMove gets called and it tries to execute a GrabEm to grab the pointer and keyboard. But xmag has already done a grab (possibly this is a race condition, too) and the GrabEm fails after 1000 tries. I'm not sure what a correct fix is for this offhand... any ideas? Greg From owner-scwm-discuss@mit.edu Tue Sep 22 12:11:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29600 for scwm-discuss-outgoing; Tue, 22 Sep 1998 12:11:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29595 for ; Tue, 22 Sep 1998 12:11:03 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA23126; Tue, 22 Sep 98 12:10:57 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA28268; Tue, 22 Sep 1998 09:10:53 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: guessing the correct desk References: From: Greg Badros Date: 22 Sep 1998 09:10:53 -0700 In-Reply-To: Robert Bihlmeyer's message of "22 Sep 1998 17:34:00 +0200" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > in add_window.c the commandlines associated with new top-level windows > are searched for options forcing the application to a specific desk: > "-xrm" and "-workspace". While "-xrm" is understood (and unknown > settings are ignored) by some (not all) X applications, I know of none > that handles "-workspace". Yes, one can usually coax the program into > interpreting "-workspace 2" as filenames, but than there are various > unintended side-effects (complaints about files not found, etc.) Maybe we should blast the -workspace option since you're right that very few apps will let it sneak by. > > I'd venture that this feature is next-to-useless, and vote for > dropping it. No functionality is lost, since the same effect can be > provided with: > > (set-current-desk! X) > (execute CMD) > > Or, in the shell: > > scwmexec '(set-current-desk! X)' > CMD I don't think they're quite the same since set-current-desk! changes the current desktop *now* and makes you sit there and wait for the application to map it's top-level window. Having an application start on a specific desk means you don't have to be on that desk when it's starting. (and if that's not the case, it's a bug). Greg From owner-scwm-discuss@mit.edu Tue Sep 22 12:20:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29759 for scwm-discuss-outgoing; Tue, 22 Sep 1998 12:20:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29756 for ; Tue, 22 Sep 1998 12:20:49 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26511; Tue, 22 Sep 98 12:20:44 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA28275; Tue, 22 Sep 1998 09:20:41 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: xrm.c References: From: Greg Badros Date: 22 Sep 1998 09:20:40 -0700 In-Reply-To: Robert Bihlmeyer's message of "22 Sep 1998 17:21:29 +0200" Message-Id: Lines: 45 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > there are two primitives `X-resource-put' and `X-resource-get' in > xrm.c which could be useful but aren't AFAIS. > > They change the resource database "db"[1], which is overwritten > whenever a new window is added (in add_window.c). Even if this was > prevented, the database pretty much exists in limbo (i.e. has no > implications in the outside world). So what was the intention of these > functions. As you're footnote suggests, this variable name has caused difficulties for you because it's shadowed by a local "XrmDatabase db" in add_window. The global one retains its values. Also you're ignoring `X-resource-database-save' and the fact that the db gets the resources merged in from RESOURCE_MANAGER and/or .Xdefaults (similar to how Intrinsics manages resources). So, at present, you can interrogate resources as an Intrinsics app would (e.g., user-level settings could be in a scwm resource file instead of a .scwmrc) and you can set resources and save the resulting database (separate from .Xdefaults/RESOURCE_MANAGER) into a text file. > As I have hinted in another mail, these facilities could be extended > to permit changing of e.g. the global resource database (easier than > changing the root-window's RESOURCE_MANAGER property directly). Yes, through appropriate merging of the databases, that makes sense. Also changes to RESOURCE_MANAGER property need to get integrated into the scwm database (this code is partially written). I stopped working on the feature because I didn't have a clear view of what my goals were and because I started thinking it might make more sense to wrap X resource databases as first-class objects, including the ability to get and set the RESOURCE_MANAGER property, do merges, etc. Doing it right was a bit more than I had time for a couple weeks ago as the bugs from my big window-placement change were keeping me busy (not to mention all my other work!) > [1] Not the best name for a global variable, BTW. Agreed. Greg From owner-scwm-discuss@mit.edu Tue Sep 22 12:22:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA29790 for scwm-discuss-outgoing; Tue, 22 Sep 1998 12:22:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA29787 for ; Tue, 22 Sep 1998 12:22:29 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27142; Tue, 22 Sep 98 12:21:22 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA28278; Tue, 22 Sep 1998 09:22:20 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: scwm user report References: <199809211633.MAA21439@huis-clos.mit.edu> From: Greg Badros Date: 22 Sep 1998 09:22:20 -0700 In-Reply-To: Robert Bihlmeyer's message of "22 Sep 1998 16:58:19 +0200" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 21 Sep 1998 09:52:10 -0700 > >>>>> Greg Badros said: > > Greg> Argh.. yep -- I missed the 'append. Though it still would do > Greg> the wrong thing if the code ran multiple times. Managing the > Greg> property directly is the wrong way to do this stuff. > > Well, it works if used multiple times, but it works badly (leaving the > old settings in). You'd either have to be more careful in Scheme, or > rely on a C interface. xrm.c could be the one - but see my criticism > in another mail. > > Greg> I agree (obviously, since the above fooled me!) -- > Greg> X-property-append! and X-property-prepend! should probably be > Greg> added in scheme, and X-property-set! should default to 'replace > Greg> mode. > > The latter is already the case. I'll add `X-property-append!' and > `-prepend!' - where? base.scm? Maybe we need another file for these. xrm.scm? Greg From owner-scwm-discuss@mit.edu Tue Sep 22 14:16:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA30440 for scwm-discuss-outgoing; Tue, 22 Sep 1998 14:16:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA30437 for ; Tue, 22 Sep 1998 14:16:30 -0400 Received: from md19-125.mun.compuserve.com by MIT.EDU with SMTP id AA09162; Tue, 22 Sep 98 14:15:19 EDT Received: (from forcer@localhost) by forcix.roof.lan (8.9.1/8.9.1) id SAA03097; Tue, 22 Sep 1998 18:20:14 +0200 Message-Id: <19980922182014.A3063@forcix.roof.lan> Date: Tue, 22 Sep 1998 18:20:14 +0200 From: forcer To: gjb@cs.washington.edu Cc: scwm-discuss@mit.edu Subject: Re: source for placing problems found Mail-Followup-To: gjb@cs.washington.edu, scwm-discuss@mit.edu References: <19980922025129.A26186@forcix.roof.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Greg Badros on Tue, Sep 22, 1998 at 08:51:30AM -0700 X-Operating-System: Linux forcix 2.0.36 X-Url: http://webserver.de/forcer/ Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, Sep 22, 1998 at 08:51:30AM -0700, Greg Badros wrote: >forcer writes: > >> Hi there. >> I already stated once that i have problems with Scwm and the Click-to-place >> (random-placement #f, smart-placement #f) type of placement proc. >> I noticed that the rubber border for some windows were positioned below and >> right of the pointer, but didn't find any relationship there. >> Now i found the reason... It seems like Scwm is using the positioning hint >> of the window in relation to the current position of the pointer, e.g. >> if the window wanted to be placed 30 pixels left of the 0,0 coordinate >> of the current window, the rubber border for the placement got positioned >> 30 pixels right of the pointer. > >Can you give a specific example of an application that starts up as you >describe so I can reproduce this? The easiest thing to reproduce this is to do something like, from an xterm, start: xmessage -center "hello" Here, the rubber border for the window gets placed not in the center of the screen, nor at the pointer as it should be, but too far lower right of the pointer (actually exactly half the screen width to the right, and half the screen height down, as if the pointer is the 0,0 coordinate for the screen). Hope this helps, -forcer -- /* Never believe anything until it's been officially denied. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Wed Sep 23 01:05:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA00975 for scwm-discuss-outgoing; Wed, 23 Sep 1998 01:05:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA00972 for ; Wed, 23 Sep 1998 01:05:29 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA00380; Wed, 23 Sep 98 01:04:09 EDT Received: (qmail 23027 invoked by uid 501); 23 Sep 1998 05:05:31 -0000 Message-Id: <19980922220530.A22945@molehill.org> Date: Tue, 22 Sep 1998 22:05:30 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: regrab resize problem, ResizeTo() problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Of course I still masturbate", said Tom with a look of self- satisfaction. Sender: owner-scwm-discuss@mit.edu Precedence: bulk Commenting out the "ResizeTo(psw, FRAME_WIDTH(psw), FRAME_HEIGHT(psw) - extra_height)" line in set-window-decor! (decor.c:332) seems to fix the xterm resize problems I've been having, with no obvious ill effects. I think probably SOMETHING should be there, but I'm not sure ResizeTo is right; it's awfully heavy-weight for a few pixel adjustment on a title bar. I'm not sure its handling of title bar height is correct, either; I'm not sure I understand the distinction between psw->title_height and psw->fl->TitleHeight. I'm not finding anything that sets the title_height to the new decor's TitleHeight, just that it makes an attempt to make room for it. When ConstrainSize tries to find allowable dimensions, the few pixel difference here frequently leads to truncating to the next smaller size. From owner-scwm-discuss@mit.edu Wed Sep 23 07:06:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA02676 for scwm-discuss-outgoing; Wed, 23 Sep 1998 07:06:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA02673 for ; Wed, 23 Sep 1998 07:06:27 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17896; Wed, 23 Sep 98 07:06:21 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA23433; Wed, 23 Sep 1998 13:06:14 +0200 To: scwm-discuss@mit.edu Subject: scwm themes for themes.org. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 23 Sep 1998 13:06:13 +0200 In-Reply-To: Robert Bihlmeyer's message of "22 Sep 1998 13:21:48 +0200" Message-Id: Lines: 8 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is anyone putting together themes, pages, screen shots, etc, for themes.org? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Sep 23 10:33:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA03547 for scwm-discuss-outgoing; Wed, 23 Sep 1998 10:33:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA03544 for ; Wed, 23 Sep 1998 10:33:51 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA26664; Wed, 23 Sep 98 10:33:46 EDT Received: by tis.bellhow.com; id KAA20269; Wed, 23 Sep 1998 10:32:08 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma020124; Wed, 23 Sep 98 10:31:34 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA08843 for ; Wed, 23 Sep 1998 10:31:33 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Snapshots stilll Down? Date: Wed, 23 Sep 1998 14:31:33 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <360e0412.513728282@smtp> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA03545 Sender: owner-scwm-discuss@mit.edu Precedence: bulk A reminder that the latest snapshot is still 9/18/1998. Some of us live behind a firewall that can only be ftp'd through. Thanks! Dale From owner-scwm-discuss@mit.edu Wed Sep 23 11:16:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA03823 for scwm-discuss-outgoing; Wed, 23 Sep 1998 11:16:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA03820 for ; Wed, 23 Sep 1998 11:16:29 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA01678; Wed, 23 Sep 98 11:16:27 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22442; Wed, 23 Sep 1998 08:16:20 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: window size problem? References: <19980922061408Z276516-15622+11@pulsar.halcyon.com> From: Greg Badros Date: 23 Sep 1998 08:16:20 -0700 In-Reply-To: Ken Pizzini's message of "Mon, 21 Sep 1998 23:14:04 -0600" Message-Id: Lines: 43 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > The width retured by the (window-title-size) below does not make sense > to me. > > $ scwm --version > Scwm Version post0.8a compiled on Sep 21 1998 at 22:44:31 > RCS_ID=$Id: scwm.c,v 1.131 1998/09/18 07:13:11 jtl Exp $ > Repository Timestamp: Fri Sep 18 03:28:48 EDT 1998 -- $Revision: 1.474 $ > $ scwmrepl > scwm> (define w (get-window)) > # > scwm> (window-frame-size w) > (486 475) > scwm> (window-size w) > (484 459 80 35) > scwm> (window-title-size w) > (485 14) > scwm> (window-frame-border-width w) > 1 > scwm> Weird. What kind of window is it? How is the window decorated? What .scwmrc are you using? > A possibly related symptom is that I sometimes notice some oddities > in the drawing of the left edge of my title bar. Then again, this may > be due to some other problem, as I also sometimes note oddities in the > drawing of the top line of the title bar. To duplicate: > . set up a window with #:border-width 1; > . overlap some other window behind it, so that the upper-left > corner of the #:border-width 1 window covers something which > contrasts well with the title bar; > . iconify the window below the #:border-width 1 window; > . note how the top and left edges of the title bar retain > pixels from the now-iconified window. The above information may help me reproduce this too, as I couldn't with my setup. Thanks, Greg From owner-scwm-discuss@mit.edu Wed Sep 23 11:58:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04167 for scwm-discuss-outgoing; Wed, 23 Sep 1998 11:58:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04158; Wed, 23 Sep 1998 11:58:23 -0400 Message-Id: <199809231558.LAA04158@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: regrab resize problem, ResizeTo() problems In-reply-to: Your message of "Tue, 22 Sep 1998 22:05:30 PDT." <19980922220530.A22945@molehill.org> Date: Wed, 23 Sep 1998 11:58:22 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > Commenting out the "ResizeTo(psw, FRAME_WIDTH(psw), FRAME_HEIGHT(psw) > - extra_height)" line in set-window-decor! (decor.c:332) seems to fix > the xterm resize problems I've been having, with no obvious ill > effects. > > I think probably SOMETHING should be there, but I'm not sure ResizeTo > is right; it's awfully heavy-weight for a few pixel adjustment on a > title bar. I'm not sure its handling of title bar height is correct, > either; I'm not sure I understand the distinction between > psw->title_height and psw->fl->TitleHeight. I'm not finding anything > that sets the title_height to the new decor's TitleHeight, just that > it makes an attempt to make room for it. > I can't address most of this, but I can explain the (slightly bogus) difference between psw->title_hieght and psw->fl->TitleHeight. psw->fl->TitleHeight is the height the title bar should be assigned if there is one, and psw->title_height is the height actually being used for the title bar, or 0 if none. psw->title_height could probably be replaced by an appropriate macro, but some code (anything that changes the title height in a decor, including both set-title-height! and set-title-font!) depends on these being separate in a slightly hairy way. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 23 12:32:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA04511 for scwm-discuss-outgoing; Wed, 23 Sep 1998 12:32:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA04508 for ; Wed, 23 Sep 1998 12:32:04 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22241; Wed, 23 Sep 98 12:32:02 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA24359; Wed, 23 Sep 1998 09:31:56 -0700 (PDT) To: dale.smith@bellhow.com Cc: scwm-discuss@mit.edu Subject: Re: Snapshots stilll Down? References: <360e0412.513728282@smtp> From: Greg Badros Date: 23 Sep 1998 09:31:56 -0700 In-Reply-To: smithd@bellhow.com's message of "Wed, 23 Sep 1998 14:31:33 GMT" Message-Id: Lines: 8 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com (Dale Smith) writes: > A reminder that the latest snapshot is still 9/18/1998. Some of us live > behind a firewall that can only be ftp'd through. The mailing list archive seems to be stalled then, too. Greg From owner-scwm-discuss@mit.edu Wed Sep 23 14:05:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05065 for scwm-discuss-outgoing; Wed, 23 Sep 1998 14:05:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA05062 for ; Wed, 23 Sep 1998 14:05:09 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26382; Wed, 23 Sep 98 14:05:04 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA27679; Wed, 23 Sep 1998 20:05:04 +0200 Date: Wed, 23 Sep 1998 20:05:04 +0200 Message-Id: <199809231805.UAA27679@blinky.bfr.co.il> From: "Harvey J. Stein" To: scwm-discuss@mit.edu Subject: more max min issues. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just remembered another thing about maximize that I've always found annoying. Consider: 1. Toggle-maximize to make the window full width. 2. Change window height. 3. toggle-maximize again. The window goes back to it's original size. Shouldn't just revert to the old width, keeping the new height? Maybe toggle-maximize is way too overloaded. Maybe there should be a toggle-maximize-width & toggle-maximize-height which toggle the width & height independently? I haven't checked what the latest code does with this. Harvey From owner-scwm-discuss@mit.edu Wed Sep 23 14:24:27 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05396 for scwm-discuss-outgoing; Wed, 23 Sep 1998 14:24:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA05393 for ; Wed, 23 Sep 1998 14:24:26 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA04168; Wed, 23 Sep 98 14:24:21 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA26547; Wed, 23 Sep 1998 11:24:21 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: source for placing problems found References: <19980922025129.A26186@forcix.roof.lan> From: Greg Badros Date: 23 Sep 1998 11:24:20 -0700 In-Reply-To: forcer's message of "Tue, 22 Sep 1998 02:51:29 +0200" Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk forcer writes: > Hi there. > I already stated once that i have problems with Scwm and the Click-to-place > (random-placement #f, smart-placement #f) type of placement proc. > I noticed that the rubber border for some windows were positioned below and > right of the pointer, but didn't find any relationship there. > Now i found the reason... It seems like Scwm is using the positioning hint > of the window in relation to the current position of the pointer, e.g. > if the window wanted to be placed 30 pixels left of the 0,0 coordinate > of the current window, the rubber border for the placement got positioned > 30 pixels right of the pointer. > I'm using 1.3a (snapshot) and a current Scwm snapshot. > I hope this provides enough information to fix this bug, as i'm not good > enough in window manager programming to fix it myself :) This is now better, I think. > Oh, and one other thing: it seems like scwm.el gets installed as /scwm.el > if there's no emacs installed on the system. planning to replace /vmunix with > /scwm.el? ;)) This still needs fixing. Greg From owner-scwm-discuss@mit.edu Wed Sep 23 14:33:18 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05477 for scwm-discuss-outgoing; Wed, 23 Sep 1998 14:33:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA05474 for ; Wed, 23 Sep 1998 14:33:16 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07603; Wed, 23 Sep 98 14:33:12 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA26598; Wed, 23 Sep 1998 11:33:12 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> From: Greg Badros Date: 23 Sep 1998 11:33:12 -0700 In-Reply-To: Todd Larason's message of "Mon, 21 Sep 1998 15:36:12 -0700" Message-Id: Lines: 42 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > (define (find-window class resource) > (car > (list-windows #:only > (lambda (w) > (and (string=? (window-class w) class) > (string=? (window-resource w) resource)))))) > > (define (rvplayer-pauseplay) > (let* ((curpos (pointer-position)) > (rvwin (find-window "rvplayer" "rvplayer")) > (rvpos (window-position rvwin)) > (newpos (list (+ 54 (car rvpos)) > (+ 74 (cadr rvpos))))) > (apply move-pointer-to newpos) > (send-button-press 1 rvwin) > (apply move-pointer-to curpos))) > > This sometimes works, but at a minimum, it seems the real player > window has to be on the current viewport and mapped. Additionally, in > focus-follows-mouse mode, if the pointer isn't in the window that has > focus at when executing rvplayer-pauseplay, the focus changes. > > Is there a better way to do this? The ideal thing is rvplayer providing some real ipc mechanism (ala the netscape property feature or -remote command line option, or a pipe, or whatever). A couple minor changes that might make the above a bit better: o Use `current-window-with-focus' and `focus' to restore the focus (restore focus before returning the pointer to its curpos). o You could make the window sticky and deiconify it, then restore its state when you're done (visually lame). Bottom line is that rvplayer might need some kind of control-mechanism separate from the GUI (lots of CD players have this feature). Greg From owner-scwm-discuss@mit.edu Wed Sep 23 15:20:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05780 for scwm-discuss-outgoing; Wed, 23 Sep 1998 15:20:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA05777 for ; Wed, 23 Sep 1998 15:20:38 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA04855 for scwm-discuss@huis-clos.mit.edu; Wed, 23 Sep 1998 21:01:39 +0200 (MET DST) Received: (qmail 1472 invoked by uid 115); 23 Sep 1998 15:02:08 -0000 To: scwm-discuss@mit.edu Subject: Re: xrm.c References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Sep 1998 17:02:07 +0200 In-Reply-To: Greg Badros's message of "22 Sep 1998 09:20:40 -0700" Message-ID: Lines: 26 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 22 Sep 1998 09:20:40 -0700 >>>>> Greg Badros said: Greg> As you're footnote suggests, this variable name has caused Greg> difficulties for you because it's shadowed by a local Greg> "XrmDatabase db" in add_window. The global one retains its Greg> values. Greg> Also you're ignoring `X-resource-database-save' and the fact Greg> that the db gets the resources merged in from RESOURCE_MANAGER Greg> and/or .Xdefaults (similar to how Intrinsics manages Greg> resources). Hmm, there's no procedure of that name in my scwm. Because I couldn't update the version here for a while, it seems that this has been improved since. So I'll shutup and checkout. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Sep 23 15:21:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05791 for scwm-discuss-outgoing; Wed, 23 Sep 1998 15:21:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA05785 for ; Wed, 23 Sep 1998 15:21:00 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA04856 for scwm-discuss@huis-clos.mit.edu; Wed, 23 Sep 1998 21:01:40 +0200 (MET DST) Received: (qmail 1494 invoked by uid 115); 23 Sep 1998 15:23:17 -0000 To: scwm-discuss@mit.edu Subject: Re: guessing the correct desk References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Sep 1998 17:23:16 +0200 In-Reply-To: Greg Badros's message of "22 Sep 1998 09:10:53 -0700" Message-ID: Lines: 34 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 22 Sep 1998 09:10:53 -0700 >>>>> Greg Badros said: >> (set-current-desk! X) (execute CMD) Greg> I don't think they're quite the same since set-current-desk! Greg> changes the current desktop *now* and makes you sit there and Greg> wait for the application to map it's top-level window. Yes, I was cheating. In fact, it is quite difficult to do a fool-proof version. If a solution, that does work in most cases, is considered sufficient, it would look like this: (add-hook! before-new-window-hook (define next-window-on-desk (win) (if (wildcard-match "TITLE" win) (set-current-desk! X)) (remove-hook! before-new-window-hook next-window-on-desk))) (execute CMD) Greg> Having an application start on a specific desk means you don't Greg> have to be on that desk when it's starting. (and if that's not Greg> the case, it's a bug). No, no, it works well. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Sep 23 16:08:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06151 for scwm-discuss-outgoing; Wed, 23 Sep 1998 16:08:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA06148 for ; Wed, 23 Sep 1998 16:08:48 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA18560; Wed, 23 Sep 98 16:08:45 EDT Received: (qmail 28078 invoked by uid 501); 23 Sep 1998 20:08:43 -0000 Message-Id: <19980923130842.A27993@molehill.org> Date: Wed, 23 Sep 1998 13:08:42 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Sep 23, 1998 at 11:33:12AM -0700 X-Tom-Swifty: "Personally, I find masturbation to be very pleasurable", said Tom, holding his own in the conversation. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980923, Greg Badros wrote: > The ideal thing is rvplayer providing some real ipc mechanism (ala the > netscape property feature or -remote command line option, or a pipe, or > whatever). I've figured out their protocol for changing URLs, but have no indication there is any protocol for what I'm trying to do. (working on this project has taught me more about X itself than using it for years or writing XView apps ever could - xprop is wonderfully cool). Does anybody know of an X protocol analyzer? It seems that 'strace -ewrite -ewrite=' would be a useful way of getting hints about protocols like this. I also looked at xev's output while manually clicking on the button, and although it saw lots of mouse movements in the rvplayer window, it didn't appear to see the mouseclick; I assume it's on a subwindow and isn't being propagated to the window I was watching. Does anybody know how to either get subwindow window-IDs or to have xev watch child windows? From owner-scwm-discuss@mit.edu Wed Sep 23 16:46:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06372 for scwm-discuss-outgoing; Wed, 23 Sep 1998 16:46:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA06369 for ; Wed, 23 Sep 1998 16:46:33 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA28406; Wed, 23 Sep 98 16:46:28 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA29610; Wed, 23 Sep 1998 13:46:19 -0700 (PDT) To: "Harvey J. Stein" Cc: scwm-discuss@mit.edu Subject: Re: more max min issues. References: <199809231805.UAA27679@blinky.bfr.co.il> From: Greg Badros Date: 23 Sep 1998 13:46:17 -0700 In-Reply-To: "Harvey J. Stein"'s message of "Wed, 23 Sep 1998 20:05:04 +0200" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Harvey J. Stein" writes: > I just remembered another thing about maximize that I've always found > annoying. Consider: > > 1. Toggle-maximize to make the window full width. > 2. Change window height. > 3. toggle-maximize again. > > The window goes back to it's original size. Shouldn't just revert to > the old width, keeping the new height? > > Maybe toggle-maximize is way too overloaded. Maybe there should be a > toggle-maximize-width & toggle-maximize-height which toggle the width > & height independently? Some of this sounds like you want two separate window configurations that can be easily swapped in and out. I think stuff similar to Emacs' window-configuration-to-register may be in order. I'm inclined to believe that the dimension(s) along which a window is maximized should not be alterable at all... Greg From owner-scwm-discuss@mit.edu Wed Sep 23 16:49:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06400 for scwm-discuss-outgoing; Wed, 23 Sep 1998 16:49:01 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA06394 for ; Wed, 23 Sep 1998 16:49:00 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA29499; Wed, 23 Sep 98 16:48:55 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA29625; Wed, 23 Sep 1998 13:48:50 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: xrm.c References: From: Greg Badros Date: 23 Sep 1998 13:48:50 -0700 In-Reply-To: Robert Bihlmeyer's message of "23 Sep 1998 17:02:07 +0200" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 22 Sep 1998 09:20:40 -0700 > >>>>> Greg Badros said: > > Greg> As you're footnote suggests, this variable name has caused > Greg> difficulties for you because it's shadowed by a local > Greg> "XrmDatabase db" in add_window. The global one retains its > Greg> values. > > Greg> Also you're ignoring `X-resource-database-save' and the fact > Greg> that the db gets the resources merged in from RESOURCE_MANAGER > Greg> and/or .Xdefaults (similar to how Intrinsics manages > Greg> resources). > > Hmm, there's no procedure of that name in my scwm. Because I couldn't > update the version here for a while, it seems that this has been > improved since. Yes, for a long while (several weeks, probably) the xrm stuff behaved as you described-- that was due to a partial implementation as the bugs were overwhelming me a bit and I didn't have time to finish that new code. There's lots of room for improvements, and I am growing more fond of the idea of first class X-resource database w/ greater functionality, but I think we should wait until we see how people want to use resources first. Greg From owner-scwm-discuss@mit.edu Wed Sep 23 16:51:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA06456 for scwm-discuss-outgoing; Wed, 23 Sep 1998 16:51:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA06452 for ; Wed, 23 Sep 1998 16:51:42 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA00811; Wed, 23 Sep 98 16:51:38 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA29628; Wed, 23 Sep 1998 13:51:35 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> <19980923130842.A27993@molehill.org> From: Greg Badros Date: 23 Sep 1998 13:51:34 -0700 In-Reply-To: Todd Larason's message of "Wed, 23 Sep 1998 13:08:42 -0700" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 980923, Greg Badros wrote: > > The ideal thing is rvplayer providing some real ipc mechanism (ala the > > netscape property feature or -remote command line option, or a pipe, or > > whatever). > > I've figured out their protocol for changing URLs, but have no indication > there is any protocol for what I'm trying to do. (working on this project > has taught me more about X itself than using it for years or writing > XView apps ever could - xprop is wonderfully cool). > > Does anybody know of an X protocol analyzer? It seems that > 'strace -ewrite -ewrite=' would be a useful way of getting hints > about protocols like this. xev is the event viewer which is pretty useful -- there are numerous more sophisticated event watchers, too. > I also looked at xev's output while manually clicking on the button, and > although it saw lots of mouse movements in the rvplayer window, it didn't > appear to see the mouseclick; I assume it's on a subwindow and isn't being > propagated to the window I was watching. Does anybody know how to either > get subwindow window-IDs or to have xev watch child windows? editres may help you here. Read its man page. My rvplayer understands editres protocol, so I'd imagine yours does too (it's a pretty easy feature to add to an Xaw app, if I remember correctly). Greg From owner-scwm-discuss@mit.edu Wed Sep 23 17:19:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA06788 for scwm-discuss-outgoing; Wed, 23 Sep 1998 17:19:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA06782; Wed, 23 Sep 1998 17:19:49 -0400 Message-Id: <199809232119.RAA06782@huis-clos.mit.edu> To: dale.smith@bellhow.com cc: scwm-discuss@mit.edu Subject: Re: Snapshots stilll Down? In-reply-to: Your message of "Wed, 23 Sep 1998 14:31:33 GMT." <360e0412.513728282@smtp> Date: Wed, 23 Sep 1998 17:19:48 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk smithd@bellhow.com writes: > > A reminder that the latest snapshot is still 9/18/1998. Some of us live > behind a firewall that can only be ftp'd through. > Darn, I think the cron jobs on huis-clos are broken (the mail archiving seems to have stopped too, and for all I know, the anoncvs repository may no longer be updating). I may not be able to fix this tonight, but probably tomorrow at the latest. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 23 17:38:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA07042 for scwm-discuss-outgoing; Wed, 23 Sep 1998 17:38:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA07039 for ; Wed, 23 Sep 1998 17:38:13 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16320; Wed, 23 Sep 98 17:38:07 EDT Received: from vermis.bfr.co.il (vermis.bfr.co.il [128.253.154.43]) by buster.bfr.co.il (8.8.5/8.8.5) with ESMTP id XAA31576 for ; Wed, 23 Sep 1998 23:37:57 +0200 Received: (from abel@localhost) by vermis.bfr.co.il (8.8.5/8.8.5) id XAA29786; Wed, 23 Sep 1998 23:37:57 +0200 To: scwm-discuss@mit.edu Subject: bug report - reproducible placement problems From: abel@bfr.co.il (Alexander L. Belikoff) Date: 23 Sep 1998 23:37:57 +0200 Message-Id: Lines: 92 X-Mailer: Gnus v5.6.22/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello everybody, Here is a reproducible placement bug. Although I am using Rev. 1.474 now, I noticed it quite a while ago. 1. Use my minimalistic .scwmrc attached below. 2. Fire up your scwm 3. Note the position of xbiff. I requested -0+0, but in my case there is a small offset between the window and the edge of the screen - bug #1. 4. Click the right button to get a desktop menu and hit 'Restart'. 5. Watch xclock and xbiff windows travel more and more left with each restart - bug #2. ========================================================================= ;; -*- scwm -*- ;;-------------------------------;; ;; import the scwm modules ;; (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm doc) (app scwm style) (app scwm face) (app scwm decor)) (define desk-widget (make-style #:plain-border #t #:sticky #t #:winlist-skip #t #:border-width 2 #:no-titlebar #t #:focus 'none)) (window-style "xclock" #:use-style desk-widget) (window-style "xbiff" #:use-style desk-widget) (define desktop-menu (menu (list (menuitem "Desktop" #f) menu-title (menuitem "Xterm" #:image-left "mini-sh1.xpm" #:action (lambda () (execute "xterm"))) (menuitem "Emacs" #:image-left "mini-edit.xpm" #:action (lambda () (execute "emacs"))) menu-separator (menuitem "Restart" #:image-left "mini-turn.xpm" #:action (lambda () (restart "scwm"))) (menuitem "Quit" #:image-left "mini-stop.xpm" #:action quit)))) (bind-mouse 'root 3 (lambda () (popup-menu desktop-menu))) (define (find-window-by-name window-name) (let ((wlist (list-windows #:only (lambda (w) (string=? (window-title w) window-name))))) (if (null? wlist) #f (car wlist)))) (add-hook! startup-hook (lambda () (if (not (find-window-by-name "xbiff")) (execute "xbiff -bg Grey45 -fg Red -geometry 60x60-0+0")) (if (not (find-window-by-name "xclock")) (execute "xclock -bg Grey45 -fg Black -geometry 60x60-60+0")) )) ========================================================================= Regards, -- Alexander L. Belikoff Bloomberg L.P. / BFM Financial Research Ltd. abel@bfr.co.il From owner-scwm-discuss@mit.edu Wed Sep 23 19:13:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA07560 for scwm-discuss-outgoing; Wed, 23 Sep 1998 19:13:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA07557 for ; Wed, 23 Sep 1998 19:13:46 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA18010; Wed, 23 Sep 98 19:13:44 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id QAA06854 for ; Wed, 23 Sep 1998 16:13:41 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276516-15622>; Wed, 23 Sep 1998 16:13:23 -0700 To: scwm-discuss@mit.edu Subject: Re: more max min issues. In-Reply-To: Your message of "Wed, 23 Sep 1998 20:05:04 +0200." <199809231805.UAA27679@blinky.bfr.co.il> Date: Wed, 23 Sep 1998 16:13:11 -0600 From: Ken Pizzini Message-Id: <19980923231323Z276516-15622+16@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <199809231805.UAA27679@blinky.bfr.co.il>, Harvey J. Stein wrote: > 1. Toggle-maximize to make the window full width. > 2. Change window height. > 3. toggle-maximize again. > > The window goes back to it's original size. Shouldn't just revert to > the old width, keeping the new height? I don't know. To me, that makes sense, but so does the current behavior. > Maybe toggle-maximize is way too overloaded. Maybe there should be a > toggle-maximize-width & toggle-maximize-height which toggle the width > & height independently? Hmmm... interesting point. Perhaps unmaximize should only undo changes which are attributable to the last maximize on that window. If you change the height after a maximize, unmaximize should leave the new height alone; likewise for width and position. Attached is a patch (relative to revision 1.474) which does this. (This also includes my earlier patch to unmaximize using client units, which never got incorporated.) --Ken Pizzini --- winops.scm-orig Wed Sep 16 09:01:10 1998 +++ winops.scm Wed Sep 23 16:05:13 1998 @@ -96,16 +96,19 @@ (make-toggling-winop icon-sticky? unstick-icon stick-icon)) (define*-public (maximize nw nh #&optional (win (get-window))) - "Maximize WIN to new width NW and new height NH. + "Maximize WIN to new pixel width NW and new pixel height NH. If NW or NH is 0, that dimension is not changed." (if win (let* ((pos (window-viewport-position win)) - (size (window-frame-size win)) (x (car pos)) (y (cadr pos)) - (width (car size)) - (height (cadr size))) - (resize-frame-to (if (> nw 0) nw width) - (if (> nh 0) nh height) win) + (frame-size (window-frame-size win)) + (pix-width (car frame-size)) + (pix-height (cadr frame-size)) + (cli-size (window-size win)) + (cli-width (caddr cli-size)) + (cli-height (cadddr cli-size))) + (resize-frame-to (if (> nw 0) nw pix-width) + (if (> nh 0) nh pix-height) win) ;; above is just a hint, get the actual... ;; FIXGJB: race condition? (let* ((new-size (window-frame-size win)) @@ -121,30 +124,49 @@ (#t 0)))) (move-window-viewport-position nx ny win) (if (not (maximized? win)) - (set-object-property! win 'maximized - (list x y width height nx ny))))))) + (set-object-property! + win 'maximized (list x y cli-width cli-height + nx ny nw nh))))))) (define*-public (maximized? #&optional (win (get-window))) "Return #t if WIN is maximized, #f otherwise." (->bool (object-property win 'maximized))) -;; FIXGJB: use client units +;; now uses client units (define*-public (unmaximize #&optional (win (get-window))) - "Unmaximize WIN so it returns to its size/position before maximization. -This should use client units, but currently uses frame-size in pixels." - (if win (let* ((max-prop (object-property win 'maximized)) - (pos (window-viewport-position win)) - (cur-x (car pos)) - (cur-y (cadr pos))) - (cond - (max-prop - (let ((maxed-x (car (cddddr max-prop))) - (maxed-y (cadr (cddddr max-prop)))) - (if (and (= cur-x maxed-x) (= cur-y maxed-y)) - (move-window-viewport-position (car max-prop) (cadr max-prop) win)) - (resize-frame-to (caddr max-prop) (cadddr max-prop) win) - (set-object-property! win 'maximized #f))))))) + "Unmaximize WIN so it returns to its size/position before maximization." + (if win (let ((max-prop (object-property win 'maximized))) + (cond + (max-prop + (let* ((maxed-dims (cddddr max-prop)) + (maxed-x (car maxed-dims)) + (maxed-y (cadr maxed-dims)) + (maxed-width (caddr maxed-dims)) + (maxed-height (cadddr maxed-dims)) + (cur-pos (window-viewport-position win)) + (cur-size (window-size win)) + (cur-x (car cur-pos)) + (cur-y (cadr cur-pos)) + (cur-width (caddr cur-size)) + (cur-height (cadddr cur-size)) + (size-hints (cddr (window-size-hints win)))) + (if (and (= cur-x maxed-x) (= cur-y maxed-y)) + (move-window-viewport-position + (car max-prop) (cadr max-prop) win)) + (resize-to + (+ (* (if (= maxed-width cur-width) + (caddr max-prop) + (cur-width)) + (caar size-hints)) + (caadr size-hints)) + (+ (* (if (= maxed-height cur-height) + (cadddr max-prop) + (cur-height)) + (cdar size-hints)) + (cdadr size-hints)) + win) + (set-object-property! win 'maximized #f))))))) (define-public (window-frame-area win) From owner-scwm-discuss@mit.edu Wed Sep 23 20:08:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07922 for scwm-discuss-outgoing; Wed, 23 Sep 1998 20:08:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA07919 for ; Wed, 23 Sep 1998 20:08:06 -0400 Received: from smtp3.nwnexus.com by MIT.EDU with SMTP id AA29302; Wed, 23 Sep 98 20:08:03 EDT Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp3.nwnexus.com (8.8.8/8.8.8) with ESMTP id RAA10732 for ; Wed, 23 Sep 1998 17:08:00 -0700 (PDT) Received: from ken@localhost by pulsar.halcyon.com id <276517-15622>; Wed, 23 Sep 1998 17:08:25 -0700 To: scwm-discuss@mit.edu Subject: Re: more max min issues. In-Reply-To: Your message of "Wed, 23 Sep 1998 16:13:11 MDT." <19980923231323Z276516-15622+16@pulsar.halcyon.com> Date: Wed, 23 Sep 1998 17:08:15 -0600 From: Ken Pizzini Message-Id: <19980924000825Z276517-15622+18@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <19980923231323Z276516-15622+16@pulsar.halcyon.com>, I said: > Attached is a patch (relative to revision 1.474) which does this. > (This also includes my earlier patch to unmaximize using client units, > which never got incorporated.) Ooops! I forgot to test that one first. Let's try that again... --Ken Pizzini --- winops.scm-orig Wed Sep 16 09:01:10 1998 +++ winops.scm Wed Sep 23 17:02:33 1998 @@ -96,55 +96,80 @@ (make-toggling-winop icon-sticky? unstick-icon stick-icon)) (define*-public (maximize nw nh #&optional (win (get-window))) - "Maximize WIN to new width NW and new height NH. +"Maximize WIN to new pixel width NW and new pixel height NH. If NW or NH is 0, that dimension is not changed." - (if win (let* ((pos (window-viewport-position win)) - (size (window-frame-size win)) - (x (car pos)) - (y (cadr pos)) - (width (car size)) - (height (cadr size))) - (resize-frame-to (if (> nw 0) nw width) - (if (> nh 0) nh height) win) - ;; above is just a hint, get the actual... - ;; FIXGJB: race condition? - (let* ((new-size (window-frame-size win)) - (nw (car new-size)) - (nh (cadr new-size)) - (nx (cond - ((> display-width (+ x nw)) x) - ((> display-width nw) (- display-width nw)) - (#t 0))) - (ny (cond - ((> display-height (+ y nh)) y) - ((> display-height nh) (- display-height nh)) - (#t 0)))) - (move-window-viewport-position nx ny win) - (if (not (maximized? win)) - (set-object-property! win 'maximized - (list x y width height nx ny))))))) +(if win (let* ((pos (window-viewport-position win)) + (x (car pos)) + (y (cadr pos)) + (frame-size (window-frame-size win)) + (pix-width (car frame-size)) + (pix-height (cadr frame-size)) + (cli-size (window-size win)) + (cli-width (caddr cli-size)) + (cli-height (cadddr cli-size))) + (resize-frame-to (if (> nw 0) nw pix-width) + (if (> nh 0) nh pix-height) win) + ;; above is just a hint, get the actual... + ;; FIXGJB: race conditions? + (let* ((new-frame-size (window-frame-size win)) + (new-client-size (window-size win)) + (nfw (car new-frame-size)) + (nfh (cadr new-frame-size)) + (ncw (caddr new-client-size)) + (nch (cadddr new-client-size)) + (nx (cond + ((> display-width (+ x nfw)) x) + ((> display-width nfw) (- display-width nfw)) + (#t 0))) + (ny (cond + ((> display-height (+ y nfh)) y) + ((> display-height nfh) (- display-height nfh)) + (#t 0)))) + (move-window-viewport-position nx ny win) + (if (not (maximized? win)) + (set-object-property! + win 'maximized (list x y cli-width cli-height + nx ny ncw nch))))))) (define*-public (maximized? #&optional (win (get-window))) "Return #t if WIN is maximized, #f otherwise." (->bool (object-property win 'maximized))) -;; FIXGJB: use client units +;; uses client units (define*-public (unmaximize #&optional (win (get-window))) - "Unmaximize WIN so it returns to its size/position before maximization. -This should use client units, but currently uses frame-size in pixels." - (if win (let* ((max-prop (object-property win 'maximized)) - (pos (window-viewport-position win)) - (cur-x (car pos)) - (cur-y (cadr pos))) - (cond - (max-prop - (let ((maxed-x (car (cddddr max-prop))) - (maxed-y (cadr (cddddr max-prop)))) - (if (and (= cur-x maxed-x) (= cur-y maxed-y)) - (move-window-viewport-position (car max-prop) (cadr max-prop) win)) - (resize-frame-to (caddr max-prop) (cadddr max-prop) win) - (set-object-property! win 'maximized #f))))))) + "Unmaximize WIN so it returns to its size/position before maximization." + (if win (let ((max-prop (object-property win 'maximized))) + (cond + (max-prop + (let* ((maxed-dims (cddddr max-prop)) + (maxed-x (car maxed-dims)) + (maxed-y (cadr maxed-dims)) + (maxed-width (caddr maxed-dims)) + (maxed-height (cadddr maxed-dims)) + (cur-pos (window-viewport-position win)) + (cur-size (window-size win)) + (cur-x (car cur-pos)) + (cur-y (cadr cur-pos)) + (cur-width (caddr cur-size)) + (cur-height (cadddr cur-size)) + (size-hints (cddr (window-size-hints win)))) + (if (and (= cur-x maxed-x) (= cur-y maxed-y)) + (move-window-viewport-position + (car max-prop) (cadr max-prop) win)) + (resize-to + (+ (* (if (= maxed-width cur-width) + (caddr max-prop) + cur-width) + (caar size-hints)) + (caadr size-hints)) + (+ (* (if (= maxed-height cur-height) + (cadddr max-prop) + cur-height) + (cdar size-hints)) + (cdadr size-hints)) + win) + (set-object-property! win 'maximized #f))))))) (define-public (window-frame-area win) From owner-scwm-discuss@mit.edu Wed Sep 23 20:49:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA08215 for scwm-discuss-outgoing; Wed, 23 Sep 1998 20:49:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA08211 for ; Wed, 23 Sep 1998 20:48:36 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA00244; Wed, 23 Sep 98 20:48:27 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id RAA26765; Wed, 23 Sep 1998 17:48:28 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id RAA14991; Wed, 23 Sep 1998 17:48:27 -0700 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809180003.UAA21495@huis-clos.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 23 Sep 1998 17:48:27 -0700 In-Reply-To: hjstein@bfr.co.il's message of "18 Sep 1998 17:08:50 +0200" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Maciej Stachowiak writes: > > If the wm has the server grabbed while this happens, it may spell > > greater trouble. Or it may not, I don't know. > > What about releasing the server in atexit? This is unnecessary; according to the X specification: A client closing its connection automatically ungrabs the server. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Sep 23 20:48:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA08208 for scwm-discuss-outgoing; Wed, 23 Sep 1998 20:48:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA08201 for ; Wed, 23 Sep 1998 20:47:39 -0400 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA29941; Wed, 23 Sep 98 20:47:29 EDT Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [206.125.74.108]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id RAA26742; Wed, 23 Sep 1998 17:46:03 -0700 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id RAA14961; Wed, 23 Sep 1998 17:46:02 -0700 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 23 Sep 1998 17:46:02 -0700 In-Reply-To: Greg Badros's message of "18 Sep 1998 15:20:19 -0700" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > There are just so many ways to hang things I don't see why it's > > important to hide functionality which *someone* *might* find important > > because said functionality is yet another way to hang things when > > improperly used. > > You're way to hung up on the hiding of functionality which we're not > trying to do. We want to prevent as safe of an interface as possible. > For XGrabServer, an invariant is it needs to be matched with an > XUngrabServer, so we force that matching to occur. (One would do the > same thing in C++ by having a local object constructed that grabs the > server within the scope of the code that needs the server grabbed, and > have the destructor of that "grabber" object ungrab the server to ensure > that control didn't escape that scope without the ungrab taking place; > similar to auto_ptr's protecting against memory leaks). Why do you think that this isn't hiding functionality? In other words, why do you believe that grab/ungrab server pairs will always be paired within the dynamic scope of some function? Consider the tired old example of move/resize with rubberbanding; depending on how the event system is implemented, providing a single function which will do both the grab and the ungrab could be difficult. (I think you'd have to have a "call the event loop recursively" primitive, somewhat like the Emacs recursive-edit.) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Sep 23 22:06:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08847 for scwm-discuss-outgoing; Wed, 23 Sep 1998 22:06:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA08844 for ; Wed, 23 Sep 1998 22:06:20 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA23765; Wed, 23 Sep 98 22:06:08 EDT Received: (qmail 30510 invoked by uid 501); 24 Sep 1998 02:06:03 -0000 Message-Id: <19980923190603.A30461@molehill.org> Date: Wed, 23 Sep 1998 19:06:03 -0700 From: Todd Larason To: "Alexander L. Belikoff" , scwm-discuss@mit.edu Subject: Re: bug report - reproducible placement problems References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Alexander L. Belikoff on Wed, Sep 23, 1998 at 11:37:57PM +0200 X-Tom-Swifty: "The size of those cobs is a-maize-ing!" was Tom's corny joke. Sender: owner-scwm-discuss@mit.edu Precedence: bulk > 1. Use my minimalistic .scwmrc attached below. > 2. Fire up your scwm > 3. Note the position of xbiff. I requested -0+0, but in my case there > is a small offset between the window and the edge of the screen - > bug #1. > 4. Click the right button to get a desktop menu and hit 'Restart'. > 5. Watch xclock and xbiff windows travel more and more left with each > restart - bug #2. I've just checked in changes that fix bug #1. #2 seems to actually be a bug in the restart code - after my change, if you kill scwm and restart it by hand, the movement is minimal, and explained by the window not having been shifted back to make up for the border; if you do a graceful restart, there is a larger movement, even though the window is initially moved back properly. I'll start tracing restart code now. From owner-scwm-discuss@mit.edu Wed Sep 23 22:21:25 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA09104 for scwm-discuss-outgoing; Wed, 23 Sep 1998 22:21:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from neoteny.eccosys.com (eccosys.com [199.100.7.5]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id WAA09101 for ; Wed, 23 Sep 1998 22:21:23 -0400 From: sen_ml@eccosys.com Received: from localhost (localhost [127.0.0.1]) by neoteny.eccosys.com (8.8.8/8.8.8) with ESMTP id LAA28660 for ; Thu, 24 Sep 1998 11:21:20 +0900 (JST) To: scwm-discuss@mit.edu Subject: making a clock (or arbitrary window) always appear on the current desk X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-URL: http://www.findmail.com/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980924112119K.sen_ml@eccosys.com> Date: Thu, 24 Sep 1998 11:21:19 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hello- i'm trying to figure out how to get a clock (or any other window for that matter) to appear on whichever desktop is current (perhaps another way to put this would be that the window follows the current desk). is there an obvious/accepted way to do this? at least asclock appears to exhibit this behavior already, but i'd like to be able to specify this via scheme...i looked in the list of hooks (in the on-line docs) to see whether there was a hook for when the current desktop changed (like an 'after-desktop-changed') but didn't see anything. [actually i have no idea how the behavior of things like asclock are implemented] thanks for your time. -sen p.s. btw, thanks for scwm it's great :-) scwmrepl is very nice. From owner-scwm-discuss@mit.edu Wed Sep 23 22:44:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA09468 for scwm-discuss-outgoing; Wed, 23 Sep 1998 22:44:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA09462 for ; Wed, 23 Sep 1998 22:43:58 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA21420; Wed, 23 Sep 98 22:43:46 EDT Received: (qmail 30734 invoked by uid 501); 24 Sep 1998 02:43:53 -0000 Message-Id: <19980923194353.A30703@molehill.org> Date: Wed, 23 Sep 1998 19:43:53 -0700 From: Todd Larason To: sen_ml@eccosys.com, scwm-discuss@mit.edu Subject: Re: making a clock (or arbitrary window) always appear on the current desk References: <19980924112119K.sen_ml@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980924112119K.sen_ml@eccosys.com>; from sen_ml@eccosys.com on Thu, Sep 24, 1998 at 11:21:19AM +0900 X-Tom-Swifty: "Yes, I wrote 'Pictures at an Exhibition', but only the piano version", said the composer modestly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980924, sen_ml@eccosys.com wrote: > i'm trying to figure out how to get a clock (or any other window for > that matter) to appear on whichever desktop is current (perhaps > another way to put this would be that the window follows the current > desk). is there an obvious/accepted way to do this? this is the 'sticky' window attribute. (window-style "xclock" #:use-style sticky #t) for instance. Some of the sample .scwmrcs define desk-widget style sets that may give other behavior you want for a clock. From gjb.scwmrc for example: (define desk-widget (make-style #:plain-border #t #:sticky #t #:winlist-skip #t #:border-width 3 #:circulate-skip #t #:focus 'none)) ;; Inherit above style options and specialize (define desk-widget-on-top (make-style #:use-style desk-widget #:kept-on-top #t)) (define desk-widget-on-top-no-titlebar (make-style #:use-style desk-widget-on-top #:no-titlebar #t)) (window-style "xclock*" #:use-style desk-widget-on-top-no-titlebar) makes xclock windows use some minimal decoration, never take focus, never come up in the window circulate list (so the common meta-tab binding won't ever select them, for example), and always stay on top of other windows. From owner-scwm-discuss@mit.edu Wed Sep 23 22:45:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA09495 for scwm-discuss-outgoing; Wed, 23 Sep 1998 22:45:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA09492 for ; Wed, 23 Sep 1998 22:45:08 -0400 From: sen_ml@eccosys.com Received: from eccosys.com by MIT.EDU with SMTP id AA00994; Wed, 23 Sep 98 22:45:06 EDT Received: from localhost (localhost [127.0.0.1]) by neoteny.eccosys.com (8.8.8/8.8.8) with ESMTP id LAA28760 for ; Thu, 24 Sep 1998 11:45:04 +0900 (JST) To: scwm-discuss@mit.edu Subject: Re: making a clock (or arbitrary window) always appear on the current desk In-Reply-To: Your message of "Thu, 24 Sep 1998 11:21:19 +0900" <19980924112119K.sen_ml@eccosys.com> References: <19980924112119K.sen_ml@eccosys.com> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-Url: http://www.findmail.com/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980924114503H.sen_ml@eccosys.com> Date: Thu, 24 Sep 1998 11:45:03 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 8 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hmmm, why do i find an answer while working on something else... i see that if i use styles and #:sticky #t i get the desired behavior. thanks for your time. -sen From owner-scwm-discuss@mit.edu Thu Sep 24 00:00:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA10397 for scwm-discuss-outgoing; Thu, 24 Sep 1998 00:00:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA10394 for ; Thu, 24 Sep 1998 00:00:17 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA14887; Thu, 24 Sep 98 00:00:14 EDT Received: (qmail 31319 invoked by uid 501); 24 Sep 1998 04:00:21 -0000 Message-Id: <19980923210021.A31298@molehill.org> Date: Wed, 23 Sep 1998 21:00:21 -0700 From: Todd Larason To: "Alexander L. Belikoff" , scwm-discuss@mit.edu Subject: Re: bug report - reproducible placement problems References: <19980923190603.A30461@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980923190603.A30461@molehill.org>; from Todd Larason on Wed, Sep 23, 1998 at 07:06:03PM -0700 X-Tom-Swifty: "I want to be carried in a covered couch", said Tom literally. Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I've just checked in changes that fix bug #1. > #2 seems to actually be a bug in the restart code Okay, my brain's not working well enough to be doing this. #2 is fixed too, the same bug as #1. (restart "scwm") was getting scwm out of my PATH, which didn't have the changes I was testing. I would have realized this much earlier except that for some reason, a gdb breakpoint on 'restart' wasn't triggering; changing the function name to 'scwm_restart' did better, and I still don't understand why. From owner-scwm-discuss@mit.edu Thu Sep 24 00:44:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA10775 for scwm-discuss-outgoing; Thu, 24 Sep 1998 00:44:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA10770; Thu, 24 Sep 1998 00:44:49 -0400 Message-Id: <199809240444.AAA10770@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: scwm themes for themes.org. In-reply-to: Your message of "23 Sep 1998 13:06:13 +0200." Date: Thu, 24 Sep 1998 00:44:48 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Is anyone putting together themes, pages, screen shots, etc, for > themes.org? > No one is that I know of. A volunteer to do this would be much appreciated. Scwm does not technically have "themes" in the sense I think of them (something that configures just the look and leaves your feel, keybindings, menus, etc alone), but nor do I think most mean that when they say themes; a theme seems to typically be a tarball of a complete config file and the images it needs. Of course, we could easily do that with some quick scheme code to untar the tarball, add the untar location to the image load path, and load the conventionally named scwmrc file inside pending a better theme technology. There is also an entry on scwm at http://www.x11.org That could probably also use more screenshots, more reviews, and more detail in the main article and feature list. A volunteer to do that would be much appreciated as well (they could be the same "external web presence" person if anyone wants that task). I will probably get to interfacing more with each of these sites eventually if no one volunteers, but I am hosed with finding an apartment and starting my new job right now, so I am trying to stick to basic administration tasks, and fixing major bugs I am most qualified to deal with. - Maciej From owner-scwm-discuss@mit.edu Thu Sep 24 01:10:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA11079 for scwm-discuss-outgoing; Thu, 24 Sep 1998 01:10:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA11076 for ; Thu, 24 Sep 1998 01:10:50 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26131; Thu, 24 Sep 98 01:10:47 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA10239; Wed, 23 Sep 1998 22:10:35 -0700 (PDT) To: cwitty@newtonlabs.com (Carl R. Witty) Cc: hjstein@bfr.co.il (Harvey J. Stein), Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> From: Greg Badros Date: 23 Sep 1998 22:10:33 -0700 In-Reply-To: cwitty@newtonlabs.com's message of "23 Sep 1998 17:46:02 -0700" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com (Carl R. Witty) writes: > Greg Badros writes: > Why do you think that this isn't hiding functionality? In other > words, why do you believe that grab/ungrab server pairs will always be > paired within the dynamic scope of some function? It's not so much that I believe that they will, but it's that I believe they should. If they're not, then there needs to be some other way to ensure that the ungrab happens. > Consider the tired old example of move/resize with rubberbanding; > depending on how the event system is implemented, providing a single > function which will do both the grab and the ungrab could be difficult. > (I think you'd have to have a "call the event loop recursively" > primitive, somewhat like the Emacs recursive-edit.) I really dislike the grabbing of the server for the rubberbanding. If we need to come up with a second abstraction for pairing the ungrabs with the grabs that's fine. I'd prefer to add on the safe and conservative side for now. Greg From owner-scwm-discuss@mit.edu Thu Sep 24 01:29:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA11309 for scwm-discuss-outgoing; Thu, 24 Sep 1998 01:29:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA11306 for ; Thu, 24 Sep 1998 01:29:46 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA28418; Thu, 24 Sep 98 01:29:44 EDT Received: (qmail 31831 invoked by uid 501); 24 Sep 1998 05:29:53 -0000 Message-Id: <19980923222952.A31750@molehill.org> Date: Wed, 23 Sep 1998 22:29:52 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: scwm themes for themes.org. References: <199809240444.AAA10770@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199809240444.AAA10770@huis-clos.mit.edu>; from Maciej Stachowiak on Thu, Sep 24, 1998 at 12:44:48AM -0400 X-Tom-Swifty: "I've done more than talk to her on the phone", said Tom metaphysically. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980924, Maciej Stachowiak wrote: > Of course, we could > easily do that with some quick scheme code to untar the tarball, add > the untar location to the image load path, and load the conventionally > named scwmrc file inside pending a better theme technology. In my mind, one of the goals of the Great Decoration Rewrite should be to give the primitives needed to emulate the look of the other window managers, including, with the proper scheme support, using their theme files directly. From owner-scwm-discuss@mit.edu Thu Sep 24 08:09:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA13455 for scwm-discuss-outgoing; Thu, 24 Sep 1998 08:09:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA13452 for ; Thu, 24 Sep 1998 08:09:02 -0400 Received: from pegasus.kuis.kyoto-u.ac.jp by MIT.EDU with SMTP id AA17651; Thu, 24 Sep 98 08:08:57 EDT Received: from localhost (virgo.kuis.kyoto-u.ac.jp [130.54.22.207]) by sato.kuis.kyoto-u.ac.jp (8.8.8/3.6W) with ESMTP id VAA25230 for ; Thu, 24 Sep 1998 21:08:58 +0900 (JST) To: scwm-discuss@mit.edu Subject: placement fix From: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) X-Mailer: Mew version 1.93b51 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980924210905N.sakurada@kuis.kyoto-u.ac.jp> Date: Thu, 24 Sep 1998 21:09:05 +0900 (JST) X-Dispatcher: imput version 980702 Lines: 24 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, This patch fixes a bug around placement at least in my environment. *** placement.c.orig Fri Sep 11 03:10:08 1998 --- placement.c Thu Sep 24 21:03:20 1998 *************** *** 558,563 **** --- 558,564 ---- have_orig_position = True; orig_x = 0; orig_y = 0; InteractiveMove(psw, False, &finalx, &finaly); + have_orig_position = False; } } } Regards. -- Hideki Sakurada sakurada@kuis.kyoto-u.ac.jp From owner-scwm-discuss@mit.edu Thu Sep 24 12:52:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14758 for scwm-discuss-outgoing; Thu, 24 Sep 1998 12:52:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14751; Thu, 24 Sep 1998 12:52:25 -0400 Message-Id: <199809241652.MAA14751@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: scwm themes for themes.org. In-reply-to: Your message of "Wed, 23 Sep 1998 22:29:52 PDT." <19980923222952.A31750@molehill.org> Date: Thu, 24 Sep 1998 12:52:25 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 980924, Maciej Stachowiak wrote: > > > Of course, we could > > easily do that with some quick scheme code to untar the tarball, add > > the untar location to the image load path, and load the conventionally > > named scwmrc file inside pending a better theme technology. > > In my mind, one of the goals of the Great Decoration Rewrite should be > to give the primitives needed to emulate the look of the other window > managers, including, with the proper scheme support, using their theme > files directly. > I agree that we should be able to emulate all their looks. Using their theme files I've never thought of, but Enlightenment at least has a config file format that should be a lot easier to parse and emulate than fvwm; it should certainly be doable with enough work. Thanks for raising our ambition level to even more ludicrous heights. - Maciej From owner-scwm-discuss@mit.edu Thu Sep 24 13:24:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA15074 for scwm-discuss-outgoing; Thu, 24 Sep 1998 13:24:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA15068; Thu, 24 Sep 1998 13:24:16 -0400 Message-Id: <199809241724.NAA15068@huis-clos.mit.edu> To: "Eric S. Raymond" cc: scwm-discuss@mit.edu Subject: Re: scwm-0.8a configure script is broken In-reply-to: Your message of "Thu, 24 Sep 1998 07:41:11 EDT." <199809241141.HAA04791@snark.thyrsus.com> Date: Thu, 24 Sep 1998 13:24:16 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi Eric, Thanks for the bug report. Before I address your problem, let me point out that I was on a month-long vacation when 0.8 and 0.8a were released; rather than go too long between releases, we decided to have Greg do a release cycle, which had previously always been managed by me. This was his first time doing so, and also I've previously dealt with all the Guile cross-version portability issues, so I will take the blame for not documenting the release process adequately. Most users of scwm use it with a recent Guile snapshot (due to Guile having gone waaaay too long between releases) so 1.2 support is a non-trivial and mostly thankless task. (Nontheless, this is the first I've heard of 0.8a not even building against guile 1.2). esr@snark.thyrsus.com writes: > Script started on Thu Sep 24 07:34:07 1998 > > Guile 1.2 is installed: > > snark:~/src/scwm-0.8a$ rpm -qa | grep guile > guile-doc-19980806-2 > guile-1.2-2 > guile-devel-1.2-2 > > Configure fails with the following error: > > snark:~/src/scwm-0.8a$ configure > loading cache ./config.cache > checking for a BSD compatible install... /usr/bin/install -c > checking for add_history in -lreadline... yes > : > checking for sin in -lm... yes > checking for main in -lrx... no > checking for main in -lqt... yes > checking for dlopen in -ldl... yes > checking for scm_handle_by_message_noexit in -lguile... no > configure: error: Can not find Guile 1.2 or later on the system > > It's there, though: > > snark:~/src/scwm-0.8a$ ls /usr/lib/*gu* > /usr/lib/libguile.a /usr/lib/libguile.so.2 > /usr/lib/libguile.la /usr/lib/libguile.so.2.0.0 > /usr/lib/libguile.so > snark:~/src/scwm-0.8a$ exit > > Script done on Thu Sep 24 07:34:53 1998 > Although Guile-1.2 related breakage is not to be entirely unexpected, this is a surprising failure mode; could you please send us the results of ldd `which guile` that we may better address your problem? > I'd really like to support scwm. But this is the third time a > supposedly usable release has failed to even build. If you guys > can't get it together better than this, I'm going to have to write > you off. I apologize for us shipping software broken in a way we did not adequately advertise. I think given this we should roll out an 0.8b. Greg, can you tell me what tag to check out to get the 0.8a baseline? I will check it out and try to roll out an 0.8b which specifically fixes the Guile 1.2 issues. (If anyone has any other major bug fixes which should be installed on the branch, let me know). In general, let me assure you that we are aware of the reliability issues and are addressing them; the current development tree even has the start of a regression test suite. We will start doing more extensive testing before releasing, since the code has an increasing number of users depending on it. - Maciej From owner-scwm-discuss@mit.edu Thu Sep 24 14:49:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA15558 for scwm-discuss-outgoing; Thu, 24 Sep 1998 14:49:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA15555 for ; Thu, 24 Sep 1998 14:49:08 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA29612; Thu, 24 Sep 98 14:49:04 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA20767; Thu, 24 Sep 1998 11:49:05 -0700 (PDT) To: Maciej Stachowiak Cc: "Eric S. Raymond" , scwm-discuss@mit.edu Subject: Re: scwm-0.8a configure script is broken References: <199809241724.NAA15068@huis-clos.mit.edu> From: Greg Badros Date: 24 Sep 1998 11:49:04 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 24 Sep 1998 13:24:16 EDT" Message-Id: Lines: 58 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Before I address your problem, let me point out that I was on a > month-long vacation when 0.8 and 0.8a were released; rather than go > too long between releases, we decided to have Greg do a release cycle, > which had previously always been managed by me. This was his first > time doing so, and also I've previously dealt with all the Guile > cross-version portability issues, so I will take the blame for not > documenting the release process adequately. No no no. Mea culpa. But that's beside the point.. > Most users of scwm use it with a recent Guile snapshot (due to Guile > having gone waaaay too long between releases) so 1.2 support is a > non-trivial and mostly thankless task. (Nontheless, this is the first > I've heard of 0.8a not even building against guile 1.2). This is the real point. 1.2 support is something I chose not to bother with, but didn't document that decision sufficiently. > Although Guile-1.2 related breakage is not to be entirely unexpected, > this is a surprising failure mode; could you please send us the > results of > ldd `which guile` > that we may better address your problem? > > > I'd really like to support scwm. But this is the third time a > > supposedly usable release has failed to even build. If you guys > > can't get it together better than this, I'm going to have to write > > you off. > > I apologize for us shipping software broken in a way we did not > adequately advertise. I think given this we should roll out an > 0.8b. Greg, can you tell me what tag to check out to get the 0.8a > baseline? I will check it out and try to roll out an 0.8b which > specifically fixes the Guile 1.2 issues. (If anyone has any other > major bug fixes which should be installed on the branch, let me know). realv0-8 (v0-8 is a test tag that I used in error; things were hectic then! [as they are again now]). But I think it makes more sense to just do a 0.9 release. We're still beta software. The only major change that negatively impacts stability since 0.8 was the window virtual/viewport position changes. I spent the last three weeks working out most (hopefully nearly all) of the bugs that this fundamental change resulted in. Otherwise 0.9 would be a lot more stable than 0.8, and has plenty of useful new features. > In general, let me assure you that we are aware of the reliability > issues and are addressing them; the current development tree even has > the start of a regression test suite. We will start doing more > extensive testing before releasing, since the code has an increasing > number of users depending on it. Yep. We should and will. Greg From owner-scwm-discuss@mit.edu Thu Sep 24 14:58:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA15633 for scwm-discuss-outgoing; Thu, 24 Sep 1998 14:58:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA15629 for ; Thu, 24 Sep 1998 14:58:13 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA03118; Thu, 24 Sep 98 14:58:08 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA21387; Thu, 24 Sep 1998 11:58:00 -0700 (PDT) To: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) Cc: scwm-discuss@mit.edu Subject: Re: placement fix References: <19980924210905N.sakurada@kuis.kyoto-u.ac.jp> From: Greg Badros Date: 24 Sep 1998 11:57:59 -0700 In-Reply-To: Hideki Sakurada's message of "Thu, 24 Sep 1998 21:09:05 +0900 (JST)" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) writes: > Hi, > > This patch fixes a bug around placement at least > in my environment. Good.. thanks.. I just added code to reset that awful global after it's tested in InteractiveMove. Greg From owner-scwm-discuss@mit.edu Thu Sep 24 15:29:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA16067 for scwm-discuss-outgoing; Thu, 24 Sep 1998 15:29:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA16064 for ; Thu, 24 Sep 1998 15:29:32 -0400 Received: from news.mtu.edu by MIT.EDU with SMTP id AA14027; Thu, 24 Sep 98 15:29:26 EDT Received: from mtu.edu (root@mtu.edu [141.219.70.1]) by news.mtu.edu (8.8.8/8.8.8) with ESMTP id PAA13798 for ; Thu, 24 Sep 1998 15:29:29 -0400 (EDT) Received: from wiley.sas.it.mtu.edu (wiley.sas.it.mtu.edu [141.219.36.70]) by mtu.edu (8.8.8/8.8.8) with ESMTP id PAA03873 for ; Thu, 24 Sep 1998 15:29:28 -0400 (EDT) Received: (from adisaacs@localhost) by wiley.sas.it.mtu.edu (8.8.7/8.8.7/mturelay-1.2) id PAA29423 for scwm-discuss@mit.edu; Thu, 24 Sep 1998 15:29:25 -0400 (EDT) Message-Id: <19980924152925.A28637@mtu.edu> Date: Thu, 24 Sep 1998 15:29:25 -0400 From: Andrew Isaacson To: scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> <19980923130842.A27993@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1 In-Reply-To: <19980923130842.A27993@molehill.org>; from Todd Larason on Wed, Sep 23, 1998 at 01:08:42PM -0700 X-Pgp-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-Pgp-Key-Url: http://www.csl.mtu.edu/~adisaacs/pgp.txt Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, Sep 23, 1998 at 01:08:42PM -0700, Todd Larason wrote: > Does anybody know of an X protocol analyzer? It seems that > 'strace -ewrite -ewrite=' would be a useful way of getting hints > about protocols like this. Look into xscope. It's installed in /usr/openwin/demo on Solaris, and I believe the source is available at ftp.x.org. -andy -- Andy Isaacson adisaacs@mtu.edu adi@acm.org Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/ From owner-scwm-discuss@mit.edu Thu Sep 24 17:01:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA16801 for scwm-discuss-outgoing; Thu, 24 Sep 1998 17:01:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA16798 for ; Thu, 24 Sep 1998 17:01:39 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA18202; Thu, 24 Sep 98 17:01:34 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id RAA07295 for ; Thu, 24 Sep 1998 17:01:29 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> Date: 24 Sep 1998 17:01:22 -0400 Message-Id: <5lemt1mdi5.fsf@tequila.systemsz.cs.yale.edu> Lines: 7 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu X-Trace: 24 Sep 1998 17:01:22 -0500, tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: > I really dislike the grabbing of the server for the rubberbanding. If Die, rubberbanding, die ! Stefan From owner-scwm-discuss@mit.edu Thu Sep 24 20:41:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA17896 for scwm-discuss-outgoing; Thu, 24 Sep 1998 20:41:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA17893 for ; Thu, 24 Sep 1998 20:41:34 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA19820; Thu, 24 Sep 98 20:41:30 EDT Received: (qmail 8920 invoked by uid 501); 25 Sep 1998 00:41:34 -0000 Message-Id: <19980924174134.A8895@molehill.org> Date: Thu, 24 Sep 1998 17:41:34 -0700 From: Todd Larason To: Andrew Isaacson , scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> <19980923130842.A27993@molehill.org> <19980924152925.A28637@mtu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19980924152925.A28637@mtu.edu>; from Andrew Isaacson on Thu, Sep 24, 1998 at 03:29:25PM -0400 X-Tom-Swifty: "Eating uranium makes me feel funny", said Tom glowingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980924, Andrew Isaacson wrote: > On Wed, Sep 23, 1998 at 01:08:42PM -0700, Todd Larason wrote: > > Does anybody know of an X protocol analyzer? It seems that > > 'strace -ewrite -ewrite=' would be a useful way of getting hints > > about protocols like this. > > Look into xscope. It's installed in /usr/openwin/demo on Solaris, and > I believe the source is available at ftp.x.org. My Solaris 2.6 box doesn't have this, and I can't find it on ftp.x.org or as part of the free xview distribution. I found a tool called 'xmon' in ftp.x.org:contrib/utilities that looks promising. From owner-scwm-discuss@mit.edu Fri Sep 25 12:31:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23077 for scwm-discuss-outgoing; Fri, 25 Sep 1998 12:31:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA23073 for ; Fri, 25 Sep 1998 12:31:33 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA18907 for scwm-discuss@huis-clos.mit.edu; Fri, 25 Sep 1998 18:11:45 +0200 (MET DST) Received: (qmail 1596 invoked by uid 115); 25 Sep 1998 13:28:38 -0000 To: scwm-discuss@mit.edu Subject: Re: making a clock (or arbitrary window) always appear on the current desk References: <19980924112119K.sen_ml@eccosys.com> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 25 Sep 1998 15:28:37 +0200 In-Reply-To: sen_ml@eccosys.com's message of "Thu, 24 Sep 1998 11:21:19 +0900" Message-ID: Lines: 18 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 24 Sep 1998 11:21:19 +0900 >>>>> sen_ml@eccosys.com said: sen> [actually i have no idea how the behavior of things like asclock sen> are implemented] I'd guess that asclock sets OverrideRedirect on its top-level window, which more or less tells the window manager to leave it alone (this is normally used for popup-menus & such). In this case the window is undecorated and immune to desk/screen-switching. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Sep 25 12:31:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA23076 for scwm-discuss-outgoing; Fri, 25 Sep 1998 12:31:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id MAA23070 for ; Fri, 25 Sep 1998 12:31:32 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA18906 for scwm-discuss@huis-clos.mit.edu; Fri, 25 Sep 1998 18:11:44 +0200 (MET DST) Received: (qmail 1574 invoked by uid 115); 25 Sep 1998 13:20:18 -0000 To: scwm-discuss@mit.edu Subject: Re: useful synthetic events References: <19980921153612.18312@molehill.org> <19980923130842.A27993@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 25 Sep 1998 15:20:17 +0200 In-Reply-To: Todd Larason's message of "Wed, 23 Sep 1998 13:08:42 -0700" Message-ID: Lines: 14 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 23 Sep 1998 13:08:42 -0700 >>>>> Todd Larason said: Todd> Does anybody know how to either get subwindow window-IDs [...]? xwininfo -tree Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Sep 25 16:29:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA24378 for scwm-discuss-outgoing; Fri, 25 Sep 1998 16:29:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA24371 for ; Fri, 25 Sep 1998 16:28:58 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA04007; Fri, 25 Sep 98 16:28:55 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id PAA00270; Fri, 25 Sep 1998 15:28:34 -0500 To: Greg Badros Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Jim Blandy Date: 25 Sep 1998 15:28:33 -0500 In-Reply-To: Greg Badros's message of 02 Aug 1998 09:44:47 -0700 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Cool -- I'm excited to see you've taken the initiative to start a > rewrite on the documentation extractor. The guile folks are probably > even happier (since it'd be a major faux pas for them to include a perl > script with the guile distribution). Faux pas? There'd be lynchin's, boy. From owner-scwm-discuss@mit.edu Fri Sep 25 17:06:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA24649 for scwm-discuss-outgoing; Fri, 25 Sep 1998 17:06:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA24643 for ; Fri, 25 Sep 1998 17:06:00 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA17394; Fri, 25 Sep 98 17:05:56 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA20922; Fri, 25 Sep 1998 14:05:50 -0700 (PDT) To: Jim Blandy Cc: hjstein@bfr.co.il (Harvey J. Stein), scwm-discuss@mit.edu Subject: Re: extract-docs partially rewritten in scheme. References: From: Greg Badros Date: 25 Sep 1998 14:05:49 -0700 In-Reply-To: Jim Blandy's message of "25 Sep 1998 15:28:33 -0500" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > Cool -- I'm excited to see you've taken the initiative to start a > > rewrite on the documentation extractor. The guile folks are probably > > even happier (since it'd be a major faux pas for them to include a perl > > script with the guile distribution). > > Faux pas? There'd be lynchin's, boy. Glad to see you're back! I hope the move went well... Harvery's guile extractor is sufficiently mature to start modifying and extending it and our documentation system for guile. Though I put a huge priority on good documentation, we're very anxious for a 1.3 release. I know you've gotta be really busy, but it'll be a huge win for scwm and the other projects that rely on guile once there is a new stable version. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Sep 25 22:26:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA26345 for scwm-discuss-outgoing; Fri, 25 Sep 1998 22:26:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA26342 for ; Fri, 25 Sep 1998 22:26:23 -0400 Received: from smtp1.nwnexus.com by MIT.EDU with SMTP id AA10412; Fri, 25 Sep 98 22:26:14 EDT Received: from pulsar.halcyon.com (coho.halcyon.com [198.137.231.21]) by smtp1.nwnexus.com (8.8.8/8.8.8) with ESMTP id TAA12571 for ; Fri, 25 Sep 1998 19:26:08 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-15622>; Fri, 25 Sep 1998 19:13:50 -0700 To: scwm-discuss@mit.edu Subject: what's up with anoncvs? Date: Fri, 25 Sep 1998 19:13:37 -0600 From: Ken Pizzini Message-Id: <19980926021350Z276516-15622+25@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Have scwm check-ins ground to a halt, or is there something wrong with the anoncvs server? As of this writing, the most recent changed.c file available through anoncvs says: char *szRepoLastChanged = "Fri Sep 18 03:28:48 EDT 1998 -- $Revision: 1.474 $"; That's a shade over a week ago. --Ken Pizzini From owner-scwm-discuss@mit.edu Sat Sep 26 01:55:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA27458 for scwm-discuss-outgoing; Sat, 26 Sep 1998 01:55:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA27455 for ; Sat, 26 Sep 1998 01:55:07 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02168; Sat, 26 Sep 98 01:55:05 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA03412; Fri, 25 Sep 1998 22:55:00 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: what's up with anoncvs? References: <19980926021350Z276516-15622+25@pulsar.halcyon.com> From: Greg Badros Date: 25 Sep 1998 22:54:59 -0700 In-Reply-To: Ken Pizzini's message of "Fri, 25 Sep 1998 19:13:37 -0600" Message-Id: Lines: 12 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > Have scwm check-ins ground to a halt, or is there something > wrong with the anoncvs server? As of this writing, the most anoncvs is served from a separate repository that is a mirror of the real repository. cron jobs are failing on huis-clos, and the script that does the mirroring isn't running. Sorry for the inconvenience. Maciej will likely have this fixed real soon (he's swamped with non-computing must-dos like finding an apartment). Greg From owner-scwm-discuss@mit.edu Sat Sep 26 03:19:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28141 for scwm-discuss-outgoing; Sat, 26 Sep 1998 03:19:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA28136; Sat, 26 Sep 1998 03:19:13 -0400 Message-Id: <199809260719.DAA28136@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: what's up with anoncvs? In-reply-to: Your message of "25 Sep 1998 22:54:59 PDT." Date: Sat, 26 Sep 1998 03:19:13 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Ken Pizzini writes: > > > Have scwm check-ins ground to a halt, or is there something > > wrong with the anoncvs server? As of this writing, the most > > anoncvs is served from a separate repository that is a mirror of the > real repository. cron jobs are failing on huis-clos, and the script > that does the mirroring isn't running. Sorry for the inconvenience. > Maciej will likely have this fixed real soon (he's swamped with > non-computing must-dos like finding an apartment). > The mail archive is now updating. I think I figured out the problem with snapshots and anoncvs and it will probably be fixed tomorrow. Sorry for the inconvenience. - Maciej From owner-scwm-discuss@mit.edu Sat Sep 26 15:40:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA31115 for scwm-discuss-outgoing; Sat, 26 Sep 1998 15:40:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA31112 for ; Sat, 26 Sep 1998 15:40:56 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA00692; Sat, 26 Sep 98 15:40:50 EDT Received: (qmail 23798 invoked by uid 501); 26 Sep 1998 19:41:18 -0000 Message-Id: <19980926124117.A23714@molehill.org> Date: Sat, 26 Sep 1998 12:41:17 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: documentation building issues. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I have those totals for you", Tom added. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I had to change "use Balanced" to "use Text::Balanced" extract-docs (and install the perl Text::Balanced module) in order to run the documentation extractor. This step seems to be working now, so I assume this is the right module. doc building is the only building step that can't be currently done in a separate build tree, which is kinda a pain. 'make html' fails rather badly; It looks like I need the DocBook DTD. Can someone point me at it and tell me where to put it? I'm sure it's in the docs somewhere, but I'm a complete sgml novice, and have other things I'd rather spend learning/working on. It doesn't look like scwm.texi is built from the extracted SGML; is this something that's just not done yet, or are they intended to be kept separate? From owner-scwm-discuss@mit.edu Sat Sep 26 16:54:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA31647 for scwm-discuss-outgoing; Sat, 26 Sep 1998 16:54:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA31639; Sat, 26 Sep 1998 16:54:45 -0400 Message-Id: <199809262054.QAA31639@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: documentation building issues. In-reply-to: Your message of "Sat, 26 Sep 1998 12:41:17 PDT." <19980926124117.A23714@molehill.org> Date: Sat, 26 Sep 1998 16:54:45 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I had to change "use Balanced" to "use Text::Balanced" extract-docs > (and install the perl Text::Balanced module) in order to run the > documentation extractor. This step seems to be working now, so I > assume this is the right module. > > doc building is the only building step that can't be currently done in > a separate build tree, which is kinda a pain. > IMO, the Makefile setup for building documentation is somewhat broken and needs to be fixed. Scripts we ship also shouldn't have hard-coded paths to the binary in them. This is something I will fix before 0.9. > 'make html' fails rather badly; It looks like I need the DocBook DTD. > Can someone point me at it and tell me where to put it? I'm sure it's > in the docs somewhere, but I'm a complete sgml novice, and have other things > I'd rather spend learning/working on. > Pointers to many DocBook resources: http://www.gnome.org/devel/docs.shtml DocBook DTD: ftp://ftp.ora.com/pub/davenport/ Other tools you may need at: http://www.oreilly.com/davenport/ > It doesn't look like scwm.texi is built from the extracted SGML; is > this something that's just not done yet, or are they intended to be > kept separate? scwm.texi is an older piece of documentation which we have not removed yet because we do not yet have a way to generate texi from the extracted docs, and because it currently contains some info not in the SGML docs. - Maciej From owner-scwm-discuss@mit.edu Sat Sep 26 19:25:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA32302 for scwm-discuss-outgoing; Sat, 26 Sep 1998 19:25:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA32299 for ; Sat, 26 Sep 1998 19:25:07 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24320; Sat, 26 Sep 98 19:24:59 EDT Received: (qmail 28116 invoked by uid 501); 26 Sep 1998 23:25:33 -0000 Message-Id: <19980926162531.A28094@molehill.org> Date: Sat, 26 Sep 1998 16:25:31 -0700 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> <199809262054.QAA31639@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199809262054.QAA31639@huis-clos.mit.edu>; from Maciej Stachowiak on Sat, Sep 26, 1998 at 04:54:45PM -0400 X-Tom-Swifty: "We're all out of Amontillado", Tom reported. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980926, Maciej Stachowiak wrote: > Pointers to many DocBook resources: > > http://www.gnome.org/devel/docs.shtml > > DocBook DTD: > > ftp://ftp.ora.com/pub/davenport/ > > Other tools you may need at: > > http://www.oreilly.com/davenport/ This was helpful, but I'm still very frustrated. I first tried hacking everything together myself, with predictably poor results. Then I found the prepacked tools gnome is using, at ftp://ftp.cygnus.com/pub/home/rosalia/docware, got those built and installed, figured out where DOCBOOK_HOME needed to point, and reduced the error count significantly; now I'm getting a core dump instead. Does anybody but Greg have this working? Greg, can you give pointers to what packages/versions you have installed? From owner-scwm-discuss@mit.edu Sat Sep 26 20:22:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA00029 for scwm-discuss-outgoing; Sat, 26 Sep 1998 20:22:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA00018; Sat, 26 Sep 1998 20:22:04 -0400 Message-Id: <199809270022.UAA00018@huis-clos.mit.edu> To: Jim Blandy cc: scwm-discuss@mit.edu Subject: Re: [bug] readline completion In-reply-to: Your message of "26 Sep 1998 11:52:52 CDT." Date: Sat, 26 Sep 1998 20:22:04 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > Really? It seems like (my R4RS is still packed, *SHAME*) you'd just > have to scan backwards from the current cursor position while the > characters were valid symbol constituents, and then complete on that > substring. I don't think this quite works because there are characters that can be in the middle of a symbol but not the beginning, and starting a symbol with them in many cases should generate a syntax error rather than parsing into two tokens. But that's pretty close. - Maciej From owner-scwm-discuss@mit.edu Sat Sep 26 22:17:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA00591 for scwm-discuss-outgoing; Sat, 26 Sep 1998 22:17:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA00588 for ; Sat, 26 Sep 1998 22:17:37 -0400 Received: from brazil.tcimet.net by MIT.EDU with SMTP id AA17767; Sat, 26 Sep 98 22:17:30 EDT Received: (from bakicale@localhost) by brazil.tcimet.net (8.8.8/8.7.3) id WAA24073; Sat, 26 Sep 1998 22:20:37 -0400 From: Aleksandar Bakic Message-Id: <199809270220.WAA24073@brazil.tcimet.net> Subject: Re: documentation building issues. To: mstachow@mit.edu (Maciej Stachowiak) Date: Sat, 26 Sep 1998 22:20:36 -0400 (EDT) Cc: jtl@molehill.org, scwm-discuss@mit.edu In-Reply-To: <199809262054.QAA31639@huis-clos.mit.edu> from "Maciej Stachowiak" at Sep 26, 98 04:54:45 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I posted an URL some time ago; you can still find DocBook examples under Docs section at http://www.egr.msu.edu/Pgrt/ . Regards, Aleks From owner-scwm-discuss@mit.edu Sat Sep 26 23:06:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01111 for scwm-discuss-outgoing; Sat, 26 Sep 1998 23:06:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA01108 for ; Sat, 26 Sep 1998 23:06:17 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22245; Sat, 26 Sep 98 23:06:10 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA17877; Sat, 26 Sep 1998 20:06:05 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> From: Greg Badros Date: 26 Sep 1998 20:06:04 -0700 In-Reply-To: Todd Larason's message of "Sat, 26 Sep 1998 12:41:17 -0700" Message-Id: Lines: 44 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I had to change "use Balanced" to "use Text::Balanced" extract-docs > (and install the perl Text::Balanced module) in order to run the > documentation extractor. This step seems to be working now, so I > assume this is the right module. Yep. My install of the module is probably broken. I'll fix it so we can leave the script at "use Text::Balanced". > doc building is the only building step that can't be currently done in > a separate build tree, which is kinda a pain. > > 'make html' fails rather badly; It looks like I need the DocBook DTD. > Can someone point me at it and tell me where to put it? I'm sure it's > in the docs somewhere, but I'm a complete sgml novice, and have other things > I'd rather spend learning/working on. I'm adding a README file to the doc/ subdir to include a couple of pointers and some brief tips. See that file (and please add to it as you find it's shortcomings -- I know there are many as I'm positive it wasn't as straightforward as that file outlines). > It doesn't look like scwm.texi is built from the extracted SGML; is > this something that's just not done yet, or are they intended to be > kept separate? There doesn't yet exist a docbook2texinfo converter. I don't think we want to keep them separate -- the scwm.texi file predates the embedded documentation. It should be marked as obsolete or removed. We have three choices for the scwm.texi: 1) wait for db2texi 2) write db2texi (need to be a dsssl whiz, I'd guess) 3) output texi from extract-docs script (some of the docbook markup [e.g., tables] would best be ignored here, otherwise it'd be as hard as 2) I am patient enough to do #1 (maybe we need to talk to the SgmlTools folks and see if this is in the cards -- the last time I looked I didn't see much discussion about it, despite how useful it'd be), but #3 would probably not be too hard and could be useful until someone does #2. Thanks, Greg From owner-scwm-discuss@mit.edu Sat Sep 26 23:29:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA01483 for scwm-discuss-outgoing; Sat, 26 Sep 1998 23:29:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA01480 for ; Sat, 26 Sep 1998 23:29:34 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16803; Sat, 26 Sep 98 23:29:23 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA17980; Sat, 26 Sep 1998 20:29:18 -0700 (PDT) To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> <199809262054.QAA31639@huis-clos.mit.edu> <19980926162531.A28094@molehill.org> From: Greg Badros Date: 26 Sep 1998 20:29:18 -0700 In-Reply-To: Todd Larason's message of "Sat, 26 Sep 1998 16:25:31 -0700" Message-Id: Lines: 51 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > > Pointers to many DocBook resources: > > > > http://www.gnome.org/devel/docs.shtml > > > > DocBook DTD: > > > > ftp://ftp.ora.com/pub/davenport/ > > > > Other tools you may need at: > > > > http://www.oreilly.com/davenport/ > > This was helpful, but I'm still very frustrated. So was I doing this.... it is definitely far from obvious. I wish I'd spent more time keeping notes about my ordeal so I could be more help. I thought things would get better by the time people wanted to be created html on their own. I don't think much has changed yet, though. > > I first tried hacking everything together myself, with predictably > poor results. Then I found the prepacked tools gnome is using, > at ftp://ftp.cygnus.com/pub/home/rosalia/docware, got those built and > installed, figured out where DOCBOOK_HOME needed to point, and reduced > the error count significantly; now I'm getting a core dump instead. > > Does anybody but Greg have this working? Greg, can you give pointers > to what packages/versions you have installed? I'll make a tgz file of jade/ docbook/ and docbook-extra/ which are the three directories I have that are related. (I don't think the third is actually used, but just in case, I'll include it anyway -- some of the tar files I grabbed from the web are in there). Any built code in the tgz is Linux x86 (RedHat 4.2 [ie. pre-glibc]). Sorry I don't have time to investigate more thoroughly right now, but perhaps this will be enough to get things working for you. See ftp.cs.washington.edu:/homes/gjb/scwm-jade-docbook-gjb.tgz Note that all three directories are installed under /scratch/gjb on the machine where I generate the html. Also note that it takes a *long* time to generate the html from the .sgml file -- 10 minutes or more on my Pentium 200 at school. Good Luck, Greg From owner-scwm-discuss@mit.edu Sun Sep 27 00:07:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01882 for scwm-discuss-outgoing; Sun, 27 Sep 1998 00:07:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA01876 for ; Sun, 27 Sep 1998 00:07:11 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20858; Sun, 27 Sep 98 00:06:59 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA18118; Sat, 26 Sep 1998 21:06:59 -0700 (PDT) To: scwm-discuss@mit.edu Subject: New html pages From: Greg Badros Date: 26 Sep 1998 21:06:58 -0700 Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just updated the html documentation for scwm which is available at: http://www.cs.washington.edu/homes/gjb/scwm-doc/ This corresponds to repository as of right now. Comments and suggestions for improvement (especially patches to the embedded documentation in the source code) are always appreciated. Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 27 01:51:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA02796 for scwm-discuss-outgoing; Sun, 27 Sep 1998 01:51:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA02793 for ; Sun, 27 Sep 1998 01:51:19 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA29981; Sun, 27 Sep 98 01:51:08 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id AAA02407; Sun, 27 Sep 1998 00:51:03 -0500 To: Greg Badros Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> From: Jim Blandy Date: 27 Sep 1998 00:51:02 -0500 In-Reply-To: Greg Badros's message of 26 Sep 1998 20:06:04 -0700 Message-Id: Lines: 16 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > 1) wait for db2texi > 2) write db2texi (need to be a dsssl whiz, I'd guess) > 3) output texi from extract-docs script (some of the docbook markup > [e.g., tables] would best be ignored here, otherwise it'd be as hard > as 2) > > I am patient enough to do #1 (maybe we need to talk to the SgmlTools > folks and see if this is in the cards -- the last time I looked I didn't > see much discussion about it, despite how useful it'd be), but #3 would > probably not be too hard and could be useful until someone does #2. I think there's a third option, although I might be misunderstanding the issues. Craig Brozefsky has hooked up a generic SGML parser library to Guile, which makes db2texi a matter of walking the parse tree and spitting out the right .texi. From owner-scwm-discuss@mit.edu Sun Sep 27 01:53:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA02840 for scwm-discuss-outgoing; Sun, 27 Sep 1998 01:53:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA02837 for ; Sun, 27 Sep 1998 01:53:46 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA08469; Sun, 27 Sep 98 01:53:37 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA20325; Sat, 26 Sep 1998 22:53:33 -0700 (PDT) To: Jim Blandy Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> From: Greg Badros Date: 26 Sep 1998 22:53:32 -0700 In-Reply-To: Jim Blandy's message of "27 Sep 1998 00:51:02 -0500" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > 1) wait for db2texi > > 2) write db2texi (need to be a dsssl whiz, I'd guess) > > 3) output texi from extract-docs script (some of the docbook markup > > [e.g., tables] would best be ignored here, otherwise it'd be as hard > > as 2) > > > > I am patient enough to do #1 (maybe we need to talk to the SgmlTools > > folks and see if this is in the cards -- the last time I looked I didn't > > see much discussion about it, despite how useful it'd be), but #3 would > > probably not be too hard and could be useful until someone does #2. > > I think there's a third option, although I might be misunderstanding > the issues. Craig Brozefsky has hooked up a > generic SGML parser library to Guile, which makes db2texi a matter of > walking the parse tree and spitting out the right .texi. Interesting. That seems like a very doable project. Any pointers to the parser library? Thanks, Greg From owner-scwm-discuss@mit.edu Sun Sep 27 08:51:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA05140 for scwm-discuss-outgoing; Sun, 27 Sep 1998 08:51:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id IAA05135 for ; Sun, 27 Sep 1998 08:51:31 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA04848 for scwm-discuss@huis-clos.mit.edu; Sun, 27 Sep 1998 14:31:43 +0200 (MET DST) Received: (qmail 7090 invoked by uid 115); 27 Sep 1998 09:56:43 -0000 To: scwm-discuss@mit.edu Subject: SGML stuff References: <19980926124117.A23714@molehill.org> <199809262054.QAA31639@huis-clos.mit.edu> <19980926162531.A28094@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 27 Sep 1998 11:56:39 +0200 In-Reply-To: Todd Larason's message of "Sat, 26 Sep 1998 16:25:31 -0700" Message-ID: Lines: 33 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sat, 26 Sep 1998 16:25:31 -0700 >>>>> Todd Larason said: Todd> Does anybody but Greg have this working? Well, it was certainly not a painless installation, but I have jade and the nwalsh-stylesheets more-or-less working. I began with downloading SGMLtools 1.1.x which I think is still the best starting-point. You may want to ignore all the TeX related things, since installing jadetex depends on a load of TeX packages. I can offer more details if someone's interested. The jade that was packaged with SGMLtools built cleanly but seg-faulted whenever I fed it non-trivial stylesheets. Original jade (IIRC) and the rpm'd one from redhat/~rosalia also did segfault. I ended up running jade under Windows NT (blech!), because it seems to run on all platforms except mine (and yours?) - BSD, Solaris, NT, Greg's (libc5-linux if I'm not mistaken). Booting NT for this was of course unacceptable - but I discovered that one (sorry, can't remember which) of the jade versions did segfault *after* producing complete (AFAICT) output. So I use this for now. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Sep 27 15:14:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA06632 for scwm-discuss-outgoing; Sun, 27 Sep 1998 15:14:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA06629 for ; Sun, 27 Sep 1998 15:14:17 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA29899; Sun, 27 Sep 98 15:13:58 EDT Received: (qmail 8070 invoked by uid 501); 27 Sep 1998 19:14:19 -0000 Message-Id: <19980927121419.A8049@molehill.org> Date: Sun, 27 Sep 1998 12:14:19 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: gray menuitems & titles Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Let's go for another gallop", Tom recanted. Sender: owner-scwm-discuss@mit.edu Precedence: bulk The menu code currently has partial support for grayed-out items, but nothing sets an item to be grayed-out, and the grayed-out appearance is usually identical to the normal appearance. I've added code to gray out menu items that have no action and am fixing the appearance so they're actually gray - it's controlled by the menu stipple color, which I'm not sure anybody really realized; there are GJB comments about that not being used, and there's no per-menu setting for it, only the global one, and I broke it even worse than it was last night. This brings us to menu titles. Right now, a menu title is just a convention - a menu item with no action, at the top of a menu, with a menu-title after it; the menu-title is just a separator. Problems with this approach: o with grayed-out support, titles are grayed out o other menu styles want to treat the title more specially; pie menus probably want the title over the whole pie, but don't want it to have a slice. Fancier versions of the rectangular menus want it to be highlighted or have a different background (see for an example style I'd like to be possible). I see a few options: 1a. document & formalize the convention; a title is the first menuitem, if it has no action and is followed by a separator. 1b. just like 1a, but create a way to differentiate a title separator from a normal one; a magic symbol as the action, maybe, or a new flag 2. add a flag to the menuitem to mean that this item is a title 3. have the title be a menu-item object, but passed to make-menu separate from the list-of-menuitems #2 and 3 look about equally good to me. #2 is more flexible in that there can be 'titles' in the middle of menus; this won't be meaningful for all drawing styles though. 1a and 1b both feel like kluges to me. Their only redeeming grace, and it's a big one, is that user code won't have to be modified. From owner-scwm-discuss@mit.edu Sun Sep 27 19:00:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13060 for scwm-discuss-outgoing; Sun, 27 Sep 1998 19:00:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from forcix.roof.lan (md11-017.mun.compuserve.com [195.232.38.17]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id TAA13057 for ; Sun, 27 Sep 1998 19:00:40 -0400 Received: (from forcer@localhost) by forcix.roof.lan (8.9.1/8.9.1) id AAA30822 for scwm-discuss@huis-clos.mit.edu; Mon, 28 Sep 1998 00:59:50 +0200 Message-ID: <19980928005949.A30813@forcix.roof.lan> Date: Mon, 28 Sep 1998 00:59:49 +0200 From: forcer To: scwm-discuss@mit.edu Subject: the placing problems ;) Mail-Followup-To: scwm-discuss@huis-clos.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux forcix 2.0.36 X-URL: http://webserver.de/forcer/ Sender: owner-scwm-discuss@mit.edu Precedence: bulk Just FYI, the finally available CVS version fixes the placing problems i encountered. Thanks, and keep up the good work :) -forcer -- /* A CONS is an object which cares. */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Sun Sep 27 19:04:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13095 for scwm-discuss-outgoing; Sun, 27 Sep 1998 19:04:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA13092 for ; Sun, 27 Sep 1998 19:04:54 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07579; Sun, 27 Sep 98 19:04:38 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA04117; Sun, 27 Sep 1998 16:04:31 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: gray menuitems & titles References: <19980927121419.A8049@molehill.org> From: Greg Badros Date: 27 Sep 1998 16:04:30 -0700 In-Reply-To: Todd Larason's message of "Sun, 27 Sep 1998 12:14:19 -0700" Message-Id: Lines: 58 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > The menu code currently has partial support for grayed-out items, but > nothing sets an item to be grayed-out, and the grayed-out appearance > is usually identical to the normal appearance. > > I've added code to gray out menu items that have no action and am > fixing the appearance so they're actually gray - it's controlled by > the menu stipple color, which I'm not sure anybody really realized; > there are GJB comments about that not being used, and there's no > per-menu setting for it, only the global one, and I broke it even > worse than it was last night. It might be nice to have per-item colors, and to be able to control grayed-out ness via a property on the menuitem object.... > This brings us to menu titles. Right now, a menu title is just a > convention - a menu item with no action, at the top of a menu, with a > menu-title after it; the menu-title is just a separator. > > Problems with this approach: > o with grayed-out support, titles are grayed out > o other menu styles want to treat the title more specially; pie menus > probably want the title over the whole pie, but don't want it to have > a slice. Fancier versions of the rectangular menus want it to be > highlighted or have a different background (see > for an example style I'd > like to be possible). > > I see a few options: > 1a. document & formalize the convention; a title is the first menuitem, if > it has no action and is followed by a separator. > 1b. just like 1a, but create a way to differentiate a title separator from > a normal one; a magic symbol as the action, maybe, or a new flag > 2. add a flag to the menuitem to mean that this item is a title > 3. have the title be a menu-item object, but passed to make-menu separate > from the list-of-menuitems > > #2 and 3 look about equally good to me. #2 is more flexible in that there > can be 'titles' in the middle of menus; this won't be meaningful for all > drawing styles though. I like number 2, since it's seems wrong to have multiple titles for a single menu. > > 1a and 1b both feel like kluges to me. Their only redeeming grace, and it's > a big one, is that user code won't have to be modified. Not that big of a deal since we can make the menu procedure take a new keyword argument for its title menu-object. That means that the old code will still work, but will have a grayed-out title (still functional, just not ideal). Besides, we're pre-1.0 -- doing things right matters more than backward compatibility still. These enhancements look great! Greg From owner-scwm-discuss@mit.edu Sun Sep 27 19:09:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13155 for scwm-discuss-outgoing; Sun, 27 Sep 1998 19:09:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA13151 for ; Sun, 27 Sep 1998 19:09:43 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA00770; Sun, 27 Sep 98 19:09:24 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA04126; Sun, 27 Sep 1998 16:08:00 -0700 (PDT) To: forcer Cc: scwm-discuss@mit.edu Subject: Re: the placing problems ;) References: <19980928005949.A30813@forcix.roof.lan> From: Greg Badros Date: 27 Sep 1998 16:07:59 -0700 In-Reply-To: forcer's message of "Mon, 28 Sep 1998 00:59:49 +0200" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk forcer writes: > Just FYI, > the finally available CVS version fixes the placing problems i encountered. > Thanks, and keep up the good work :) Our newest active developer is responsible-- kudos and thanks to Todd Larason! Greg From owner-scwm-discuss@mit.edu Sun Sep 27 19:16:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13360 for scwm-discuss-outgoing; Sun, 27 Sep 1998 19:16:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA13345; Sun, 27 Sep 1998 19:16:01 -0400 Message-Id: <199809272316.TAA13345@huis-clos.mit.edu> To: forcer cc: scwm-discuss@mit.edu Subject: Re: the placing problems ;) In-reply-to: Your message of "Mon, 28 Sep 1998 00:59:49 +0200." <19980928005949.A30813@forcix.roof.lan> Date: Sun, 27 Sep 1998 19:16:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk forcer@mindless.com writes: > Just FYI, > the finally available CVS version fixes the placing problems i encountered. > Thanks, and keep up the good work :) > -forcer > Glad it helped. Sorry about the anoncvs downtime - what happened was that /usr/local/bin got accidentally blown away and it took me a while to hunt down all the programs that had to be put back there for things to work. I think I finally got them all. - Maciej From owner-scwm-discuss@mit.edu Mon Sep 28 11:17:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28050 for scwm-discuss-outgoing; Mon, 28 Sep 1998 11:17:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28047 for ; Mon, 28 Sep 1998 11:17:36 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26597; Mon, 28 Sep 98 11:17:10 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA10270; Mon, 28 Sep 1998 08:17:09 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: maximize/unmaximize code in winops.scm References: <19980928041833Z276516-15622+32@pulsar.halcyon.com> From: Greg Badros Date: 28 Sep 1998 08:17:08 -0700 In-Reply-To: Ken Pizzini's message of "Sun, 27 Sep 1998 21:18:26 -0600" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > Now that anoncvs is working again, I note that neither of my "maximize" > changes in the last week or two have made it in to scheme/winops.scm. > > Is there a problem with them? Did they get lost? Is it just one of > those "no time (at the beginning of a school year)" problems? If you > want/need a fresh diff I can send it to you; if there's a problem > with them I'd like to know about it. I just applied it and will be checking it in today. No problems in the code that I've found, so we definitely need others to bang on it. Sorry for the delay (our classes start today so I'd just been a bit busy). And thanks for the nice feature enhancement! Thanks, Greg From owner-scwm-discuss@mit.edu Mon Sep 28 11:39:27 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA28211 for scwm-discuss-outgoing; Mon, 28 Sep 1998 11:39:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA28207 for ; Mon, 28 Sep 1998 11:39:18 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA04190; Mon, 28 Sep 98 11:38:51 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id KAA05061; Mon, 28 Sep 1998 10:38:38 -0500 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> From: Jim Blandy Date: 28 Sep 1998 10:38:37 -0500 In-Reply-To: Greg Badros's message of 26 Sep 1998 22:53:32 -0700 Message-Id: Lines: 86 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > I think there's a third option, although I might be misunderstanding > > the issues. Craig Brozefsky has hooked up a > > generic SGML parser library to Guile, which makes db2texi a matter of > > walking the parse tree and spitting out the right .texi. > > Interesting. That seems like a very doable project. Any pointers to the > parser library? Here's the post: From: Craig Brozefsky Subject: guile port of sdc To: guile@cygnus.com Date: 29 Aug 1998 20:38:49 -0500 Return-Path: Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by gargle.red-bean.com (8.8.5/8.8.5) with ESMTP id UAA02739; Sat, 29 Aug 1998 20:59:49 -0700 Received: (from majordom@localhost) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) id SAA13340; Sat, 29 Aug 1998 18:31:22 -0700 (PDT) Received: from duomo.onshore.com (duomo.onshore.com [206.69.90.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with SMTP id SAA13336 for ; Sat, 29 Aug 1998 18:31:18 -0700 (PDT) Received: (qmail 32253 invoked by uid 1000); 30 Aug 1998 01:38:49 -0000 Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: karlheg@inetarena.com's message of 29 Aug 1998 14:40:09 -0700 Message-ID: <87u32vw8nq.fsf_-_@duomo.onshore.com> X-Mailer: Gnus v5.5/Emacs 20.2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by cygnus.com id SAA13337 Sender: owner-guile@cygnus.com Precedence: bulk Status: O X-Status: X-UID: 820 Lines: 45 Xref: totoro.red-bean.com mail.guile:2256 SDC for guile The original sdc was written for Bigloo by Jvrg Wittenberger and is available at [1]http://www.inf.tu-dresden.de/~jw6/doc/sdc/index.html. Presently this port to guile does not support all of the backends sdc supports, and has a few bugs in it I'm sure. This version is a straight-forward port, with the only major change being the module definitions, and the addition of an entity-manager construct. The major reason for the port was to get sdc, which is GPLed code, off of Bigloo and onto a GPLed scheme, and to separate it's ESIS tokenizer/compiler from the rest of the application so that it could be easily used in other experiments. You can download a tarball at: [2]http://www.red-bean.com/~craig/sdc-guile/sdc-guile_0.1.tar.gz The performance of this port can stand some improvement, and I'm working on implementing them presently. I assume that a dumper/freezer, or even a scheme compiler would greatly increase the performance, at least to get back to somewhere close to the Bigloo implementation which was rather fast. If anyone has ideas on how to make module definitions portable across several of the more popular free scheme implementations I would be grateful if they would share it with me. Some things planned for the future: * Debian package with linux-doc and debian-doc support. * Get the rest of the backends working. * Better error handling and debugging. * Compiled version using modified hobbit scheme compiler. * Create a DTD compiler which could be used for validation and automatic generation of documents. * DSSSL driver for the backends. _________________________________________________________________ Craig Brozefsky [3]craig@red-bean.com References 1. http://www.inf.tu-dresden.de/~jw6/doc/sdc/index.html 2. http://www.red-bean.com/~craig/sdc-guile/sdc-guile_0.1.tar.gz 3. mailto:craig@red-bean.com From owner-scwm-discuss@mit.edu Tue Sep 29 04:03:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA11692 for scwm-discuss-outgoing; Tue, 29 Sep 1998 04:03:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id EAA11689 for ; Tue, 29 Sep 1998 04:03:41 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA27407 for scwm-discuss@huis-clos.mit.edu; Tue, 29 Sep 1998 09:44:53 +0200 (MET DST) Received: (qmail 494 invoked by uid 115); 28 Sep 1998 17:49:11 -0000 To: scwm-discuss@mit.edu Subject: Re: gray menuitems & titles References: <19980927121419.A8049@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Sep 1998 19:49:10 +0200 In-Reply-To: Greg Badros's message of "27 Sep 1998 16:04:30 -0700" Message-ID: Lines: 21 X-Mailer: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 27 Sep 1998 16:04:30 -0700 >>>>> Greg Badros said: >> 2. add a flag to the menuitem to mean that this item is a title >> 3. have the title be a menu-item object, but passed to make-menu >> separate from the list-of-menuitems Greg> I like number 2, since it's seems wrong to have multiple titles Greg> for a single menu. I'd guess you mean 3 then - 2 gives you the possiblity to have more titles, 3 offers exactly one title. I vote for 3. The concept of multiple titles is too muddy to be supported correctly. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Sep 29 04:43:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA11912 for scwm-discuss-outgoing; Tue, 29 Sep 1998 04:43:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA11909 for ; Tue, 29 Sep 1998 04:43:13 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA01916; Tue, 29 Sep 98 04:43:08 EDT Received: (qmail 27625 invoked by uid 501); 29 Sep 1998 08:43:15 -0000 Message-Id: <19980929014315.A27583@molehill.org> Date: Tue, 29 Sep 1998 01:43:15 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: menu teaser Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "She must be wearing mink", Tom inferred. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm not gonna check any of this in tonight after all, there's a few more things I want to clean up before I left anyone else see how the sausage is made. But there's a nice (IMHO) teaser of what the sausage could taste like at http://fecundity.webcoi.com/~jtl/menus.jpg. The first two menus shown there are a new 'xpm' menu type; the decorations are taken straight from some KDE themes I found at kde.themes.org. Hopefully the details on how the other pixmappable-themed WMs work are close enough they can be used too; KDE's rules are reasonable, but certainly not obvious. From owner-scwm-discuss@mit.edu Tue Sep 29 09:14:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA12931 for scwm-discuss-outgoing; Tue, 29 Sep 1998 09:14:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA12928 for ; Tue, 29 Sep 1998 09:14:09 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA04878; Tue, 29 Sep 98 09:14:04 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA14896; Tue, 29 Sep 1998 15:13:35 +0200 To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: controlling netscape via scwm References: <199809181716.NAA29409@huis-clos.mit.edu> <5lemt1mdi5.fsf@tequila.systemsz.cs.yale.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Sep 1998 15:13:35 +0200 In-Reply-To: Stefan Monnier's message of "24 Sep 1998 17:01:22 -0400" Message-Id: Lines: 13 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Greg" == Greg Badros writes: > > I really dislike the grabbing of the server for the rubberbanding. If > > Die, rubberbanding, die ! I *like* rubberbanding... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 29 09:22:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA12980 for scwm-discuss-outgoing; Tue, 29 Sep 1998 09:22:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA12974 for ; Tue, 29 Sep 1998 09:21:33 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA02846; Tue, 29 Sep 98 09:21:26 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA14928; Tue, 29 Sep 1998 15:21:10 +0200 To: Jim Blandy Cc: Greg Badros , Todd Larason , scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Sep 1998 15:21:10 +0200 In-Reply-To: Jim Blandy's message of "27 Sep 1998 00:51:02 -0500" Message-Id: Lines: 37 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > 1) wait for db2texi > > 2) write db2texi (need to be a dsssl whiz, I'd guess) > > 3) output texi from extract-docs script (some of the docbook markup > > [e.g., tables] would best be ignored here, otherwise it'd be as hard > > as 2) > > > > I am patient enough to do #1 (maybe we need to talk to the SgmlTools > > folks and see if this is in the cards -- the last time I looked I didn't > > see much discussion about it, despite how useful it'd be), but #3 would > > probably not be too hard and could be useful until someone does #2. > > I think there's a third option, although I might be misunderstanding > the issues. Craig Brozefsky has hooked up a > generic SGML parser library to Guile, which makes db2texi a matter of > walking the parse tree and spitting out the right .texi. extract.scm creates an intermediate sgml internal format before outputing the sgml, something like sgml-list : ((tag tag-args ...) sgml-list-or-text-string) so at least in extract.scm the sgml parsing isn't needed. I started thinking about doing some sort of sgml->texi in extract.scm, but it wasn't clear to me that there's a clean mapping of the sgml tags used to the appropriate texi constructs. I think it'd be easier to do extracted-docs->texi the same way I do extracted-docs->sgml - by working directly with the internal extracted docs structures. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Sep 29 11:00:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA14459 for scwm-discuss-outgoing; Tue, 29 Sep 1998 11:00:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA14378; Tue, 29 Sep 1998 10:57:12 -0400 Message-Id: <199809291457.KAA14378@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: menu teaser In-reply-to: Your message of "Tue, 29 Sep 1998 01:43:15 PDT." <19980929014315.A27583@molehill.org> Date: Tue, 29 Sep 1998 10:57:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I'm not gonna check any of this in tonight after all, there's a few > more things I want to clean up before I left anyone else see how the > sausage is made. But there's a nice (IMHO) teaser of what the sausage > could taste like at http://fecundity.webcoi.com/~jtl/menus.jpg. > > The first two menus shown there are a new 'xpm' menu type; the > decorations are taken straight from some KDE themes I found at > kde.themes.org. Hopefully the details on how the other > pixmappable-themed WMs work are close enough they can be used too; > KDE's rules are reasonable, but certainly not obvious. Wow. That screenshot looks pretty cool. I'd like to post something like it on the scwm web page once you have all that code incorporated in the tree. - Maciej From owner-scwm-discuss@mit.edu Tue Sep 29 11:22:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA14594 for scwm-discuss-outgoing; Tue, 29 Sep 1998 11:22:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA14591 for ; Tue, 29 Sep 1998 11:22:25 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18042; Tue, 29 Sep 98 11:22:11 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA14140; Tue, 29 Sep 1998 08:21:46 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: gray menuitems & titles References: <19980927121419.A8049@molehill.org> From: Greg Badros Date: 29 Sep 1998 08:21:46 -0700 In-Reply-To: Robert Bihlmeyer's message of "28 Sep 1998 19:49:10 +0200" Message-Id: Lines: 16 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >> 2. add a flag to the menuitem to mean that this item is a title > >> 3. have the title be a menu-item object, but passed to make-menu > >> separate from the list-of-menuitems > > Greg> I like number 2, since it's seems wrong to have multiple titles > Greg> for a single menu. > > I'd guess you mean 3 then - 2 gives you the possiblity to have > more titles, 3 offers exactly one title. I vote for 3. The concept > of multiple titles is too muddy to be supported correctly. Right, #3. My apologies for my inanity. :-) Greg From owner-scwm-discuss@mit.edu Tue Sep 29 11:24:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA14606 for scwm-discuss-outgoing; Tue, 29 Sep 1998 11:24:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA14603 for ; Tue, 29 Sep 1998 11:24:22 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18830; Tue, 29 Sep 98 11:24:13 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA14146; Tue, 29 Sep 1998 08:24:08 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: menu teaser References: <19980929014315.A27583@molehill.org> From: Greg Badros Date: 29 Sep 1998 08:24:08 -0700 In-Reply-To: Todd Larason's message of "Tue, 29 Sep 1998 01:43:15 -0700" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I'm not gonna check any of this in tonight after all, there's a few > more things I want to clean up before I left anyone else see how the > sausage is made. But there's a nice (IMHO) teaser of what the sausage > could taste like at http://fecundity.webcoi.com/~jtl/menus.jpg. Pretty dang nifty! I'm looking forward to seeing the code after it's all cleaned up and ready for public consumption! Greg From owner-scwm-discuss@mit.edu Tue Sep 29 13:02:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA15195 for scwm-discuss-outgoing; Tue, 29 Sep 1998 13:02:28 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA15192 for ; Tue, 29 Sep 1998 13:02:25 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA22974; Tue, 29 Sep 98 13:02:21 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id MAA07009; Tue, 29 Sep 1998 12:02:08 -0500 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: documentation building issues. References: <19980926124117.A23714@molehill.org> From: Jim Blandy Date: 29 Sep 1998 12:02:06 -0500 In-Reply-To: hjstein@bfr.co.il's message of 29 Sep 1998 15:21:10 +0200 Message-Id: Lines: 6 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I think it'd be easier to do extracted-docs->texi the same way I do > extracted-docs->sgml - by working directly with the internal extracted > docs structures. That sounds reasonable. From owner-scwm-discuss@mit.edu Wed Sep 30 02:55:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA21438 for scwm-discuss-outgoing; Wed, 30 Sep 1998 02:55:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA21435 for ; Wed, 30 Sep 1998 02:55:25 -0400 Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id PAA19775 for ; Wed, 30 Sep 1998 15:55:18 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id PAA01849; Wed, 30 Sep 1998 15:55:18 +0900 To: scwm-discuss@mit.edu Subject: usage note message X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 30 Sep 1998 15:55:18 +0900 Message-ID: Lines: 29 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am using the following version from cvs: Wed Sep 23 22:25:58 EDT 1998 -- $Revision: 1.499 $ and have been diligently sending out usage note packets whenever I (re-)start scwm. I always used to get the output: [Scwm][SendUsagePacket]: Opening socket for usage log... [Scwm][SendUsagePacket]: Sent usage note with your hostname and version number-- thank you! However recently the output, things have become more verbose. I see also: packet: (0 16 "SET_MASK 838655\n" 1) packet: (0 15 "Send_ConfigInfo" 1) packet: (0 15 "Send_WindowList" 1) Anyway would it be possible to quieten down this process. I would be happy with a short single line message. Say: [Scwm][SendUsagePacket]: Opening socket for usage log...done (If desirable the last 4 characters could be output after the packet was sent.) -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Wed Sep 30 03:05:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA21536 for scwm-discuss-outgoing; Wed, 30 Sep 1998 03:05:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA21533 for ; Wed, 30 Sep 1998 03:05:18 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22091; Wed, 30 Sep 98 03:05:13 EDT Received: (qmail 1469 invoked by uid 501); 30 Sep 1998 07:05:33 -0000 Message-Id: <19980930000533.A1444@molehill.org> Date: Wed, 30 Sep 1998 00:05:33 -0700 From: Todd Larason To: Jens-Ulrik Petersen , scwm-discuss@mit.edu Subject: Re: usage note message References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jens-Ulrik Petersen on Wed, Sep 30, 1998 at 03:55:18PM +0900 X-Tom-Swifty: "Someone bumped into me while I was brushing my teeth", said Tom with a gleam in his eye. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980930, Jens-Ulrik Petersen wrote: > and have been diligently sending out usage note packets whenever I > (re-)start scwm. > However recently the output, things have become more verbose. I see > also: > > packet: (0 16 "SET_MASK 838655\n" 1) > packet: (0 15 "Send_ConfigInfo" 1) > packet: (0 15 "Send_WindowList" 1) Those are from the fvwm module support. I'd guess you've recently started using the fvwm pager or windowlist? From owner-scwm-discuss@mit.edu Wed Sep 30 03:21:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA21741 for scwm-discuss-outgoing; Wed, 30 Sep 1998 03:21:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA21737 for ; Wed, 30 Sep 1998 03:21:01 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA25335; Wed, 30 Sep 98 03:20:58 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA21728; Wed, 30 Sep 1998 03:20:55 -0400 Message-Id: <199809300720.DAA21728@huis-clos.mit.edu> To: Todd Larason Cc: Jens-Ulrik Petersen , scwm-discuss@mit.edu Subject: Re: usage note message In-Reply-To: Your message of "Wed, 30 Sep 1998 00:05:33 PDT." <19980930000533.A1444@molehill.org> Date: Wed, 30 Sep 1998 03:20:55 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 980930, Jens-Ulrik Petersen wrote: > > and have been diligently sending out usage note packets whenever I > > (re-)start scwm. > > > However recently the output, things have become more verbose. I see > > also: > > > > packet: (0 16 "SET_MASK 838655\n" 1) > > packet: (0 15 "Send_ConfigInfo" 1) > > packet: (0 15 "Send_WindowList" 1) > > Those are from the fvwm module support. I'd guess you've recently > started using the fvwm pager or windowlist? > That's right, and these debugging statements should be commented out by default, and used to be. Why are they not any more? - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 03:49:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA22751 for scwm-discuss-outgoing; Wed, 30 Sep 1998 03:49:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA22748 for ; Wed, 30 Sep 1998 03:49:31 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA28159; Wed, 30 Sep 98 03:49:27 EDT Received: (qmail 1702 invoked by uid 501); 30 Sep 1998 07:49:49 -0000 Message-Id: <19980930004948.A1635@molehill.org> Date: Wed, 30 Sep 1998 00:49:48 -0700 From: Todd Larason To: scwm-discuss list Subject: menu code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Nice mirror!" said Tom reflectively. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't had a chance to work on scwm tonight, and won't have much time, and may not tomorrow. I could go ahead and check in what I have tonight or tomorrow morning and give people a chance to bang on it. I can comment out the graying code, so as long as you don't change menu styles, you *shouldn't* see any changes (well, one, but $10 says nobody notices). The big change I was hoping to get done before checking in was putting a nice interface on changing menu modes, and letting menus be set separately, or using the current default (much like the menucolors are done now ). As it currently stands, there are primitives set-menus-xpm! and set-menus-pie! that cause all menus to be drawn in that style; the xpm menu code falls back to the standard, when drawing a menu with no pixmaps. (and the pie code isn't drawing pies yet; I'm having to refresh my memory on things like trigonometry.) So...should I check in as is, or wait till I find time to get it to a better state? From owner-scwm-discuss@mit.edu Wed Sep 30 04:25:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA23240 for scwm-discuss-outgoing; Wed, 30 Sep 1998 04:25:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA23234; Wed, 30 Sep 1998 04:25:33 -0400 Message-Id: <199809300825.EAA23234@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: menu code In-reply-to: Your message of "Wed, 30 Sep 1998 00:49:48 PDT." <19980930004948.A1635@molehill.org> Date: Wed, 30 Sep 1998 04:25:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I haven't had a chance to work on scwm tonight, and won't have much > time, and may not tomorrow. I could go ahead and check in what I have > tonight or tomorrow morning and give people a chance to bang on it. > Don't feel time pressured, but OTOH don't be afraid to check in code that's not quite perfect. However, if you doubt whether this can be gotten right in a short period of time (either by you or by others), a good thing to do might be to check it in on a branch. In fact, I'm thinking we could use an 0.9 release sometime after Guile 1.3 comes out and will want to do some orthogonal significant changes from my high priority list towards that end (as soon as I get a copyright disclaimer from my employer, most likely), so maybe a branch would be a good thing until the enhanced menu code stabilizes. I apologize if that sentence is unclear, I haven't slept in a while (been babysitting a fragile but time-critical build at work all night). - Maciej PS Thanks yet again for all the cool stuff you have been adding. I love to see the code doing things neither God nor I ever intended a window manager to do :-) From owner-scwm-discuss@mit.edu Wed Sep 30 05:09:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA23591 for scwm-discuss-outgoing; Wed, 30 Sep 1998 05:09:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA23588 for ; Wed, 30 Sep 1998 05:09:46 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA19582; Wed, 30 Sep 98 05:09:43 EDT Received: (qmail 2003 invoked by uid 501); 30 Sep 1998 09:10:05 -0000 Message-Id: <19980930021005.A1955@molehill.org> Date: Wed, 30 Sep 1998 02:10:05 -0700 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: menu code References: <19980930004948.A1635@molehill.org> <199809300825.EAA23234@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199809300825.EAA23234@huis-clos.mit.edu>; from Maciej Stachowiak on Wed, Sep 30, 1998 at 04:25:32AM -0400 X-Tom-Swifty: "Ouch! When I get stung, I want revenge", said Tom begrudgingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980930, Maciej Stachowiak wrote: > However, if you doubt whether this can be > gotten right in a short period of time (either by you or by others), a > good thing to do might be to check it in on a branch. I don't think it will take that long to get right. I'm actually pretty confident right now that the functionality that's there now is still all working. > In fact, I'm thinking we could use an 0.9 release sometime after Guile > 1.3 comes out and will want to do some orthogonal significant changes > from my high priority list towards that end (as soon as I get a > copyright disclaimer from my employer, most likely), so maybe a branch > would be a good thing until the enhanced menu code stabilizes. Is everything marked on the TODO list for 0.9 still intended? I'll be impressed if the even rewrite is done soon after the guile 1.3 release (October 4th?), must less the decoration rewrite. > PS Thanks yet again for all the cool stuff you have been adding. I > love to see the code doing things neither God nor I ever intended a > window manager to do :-) Um, sure! I'm going to take that at face value and not as an oblique way of saying 'why are you trying to put all this stuff into my window manager when there's real work needed on it?'. =) I really do hope what I'm working on is useful/desired by you and others. So far, nothing on the TODO list looks within my grasp...and frankly, I spend 40-60 hours a week dealing with TODO lists at work, and do this for fun. Sorry for the babbling, it's been a long night here, too. Finally done though, maybe I'll get some scwm work in after all. From owner-scwm-discuss@mit.edu Wed Sep 30 10:59:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA25214 for scwm-discuss-outgoing; Wed, 30 Sep 1998 10:59:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA25211 for ; Wed, 30 Sep 1998 10:59:35 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02514; Wed, 30 Sep 98 10:59:35 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA20432; Wed, 30 Sep 1998 07:59:26 -0700 (PDT) To: Jens-Ulrik Petersen Cc: scwm-discuss@mit.edu Subject: Re: usage note message References: From: Greg Badros Date: 30 Sep 1998 07:59:26 -0700 In-Reply-To: Jens-Ulrik Petersen's message of "30 Sep 1998 15:55:18 +0900" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jens-Ulrik Petersen writes: > I am using the following version from cvs: > > Wed Sep 23 22:25:58 EDT 1998 -- $Revision: 1.499 $ > > and have been diligently sending out usage note packets whenever I > (re-)start scwm. Great, thanks! > However recently the output, things have become more verbose. I see > also: In fvwm-module.scm, I've had the default value of debug-fvwm-module as #t for a while now. You can change your copy to #f, or maybe it's time to make the default be false as fvwm2 module support seems to be a more stable now. Greg From owner-scwm-discuss@mit.edu Wed Sep 30 11:00:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA25226 for scwm-discuss-outgoing; Wed, 30 Sep 1998 11:00:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA25223 for ; Wed, 30 Sep 1998 11:00:12 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA15949; Wed, 30 Sep 98 11:00:09 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20454; Wed, 30 Sep 1998 08:00:09 -0700 (PDT) To: Maciej Stachowiak Cc: Todd Larason , Jens-Ulrik Petersen , scwm-discuss@mit.edu Subject: Re: usage note message References: <199809300720.DAA21728@huis-clos.mit.edu> From: Greg Badros Date: 30 Sep 1998 08:00:08 -0700 In-Reply-To: Maciej Stachowiak's message of "Wed, 30 Sep 1998 03:20:55 EDT" Message-Id: Lines: 9 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > That's right, and these debugging statements should be commented out > by default, and used to be. Why are they not any more? Because we were debugging lots of pager related problems during late Augustish. Greg From owner-scwm-discuss@mit.edu Wed Sep 30 11:10:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA25301 for scwm-discuss-outgoing; Wed, 30 Sep 1998 11:10:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA25298 for ; Wed, 30 Sep 1998 11:10:16 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA19371; Wed, 30 Sep 98 11:10:12 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20458; Wed, 30 Sep 1998 08:10:07 -0700 (PDT) To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: menu code References: <19980930004948.A1635@molehill.org> <199809300825.EAA23234@huis-clos.mit.edu> <19980930021005.A1955@molehill.org> From: Greg Badros Date: 30 Sep 1998 08:10:06 -0700 In-Reply-To: Todd Larason's message of "Wed, 30 Sep 1998 02:10:05 -0700" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > Is everything marked on the TODO list for 0.9 still intended? I'll be > impressed if the even rewrite is done soon after the guile 1.3 release > (October 4th?), must less the decoration rewrite. You won't be the only one impressed. The decoration rewrite definitely won't make 0.9; I think the event rewrite should happen after .9, and our goal for 0.9 should be bug fixes and ease of building/use so that .9 can be almost like a 1.0 release of scwm w/o the remaining major infrastructure changes. > > PS Thanks yet again for all the cool stuff you have been adding. I > > love to see the code doing things neither God nor I ever intended a > > window manager to do :-) > > Um, sure! I'm going to take that at face value and not as an oblique > way of saying 'why are you trying to put all this stuff into my window > manager when there's real work needed on it?'. =) Don't forget the cleaner separation of interface and implementation in the menuing code that your changes provide. This clearly is "real" work that was sorely needed. Extra whiz-bang features are more than welcome as long as they are reasonably modular so that when we start pulling scwm apart into pieces they can be left out as individual users choose. Greg From owner-scwm-discuss@mit.edu Wed Sep 30 16:48:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26894 for scwm-discuss-outgoing; Wed, 30 Sep 1998 16:48:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26887; Wed, 30 Sep 1998 16:48:48 -0400 Message-Id: <199809302048.QAA26887@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: usage note message In-reply-to: Your message of "30 Sep 1998 07:59:26 PDT." Date: Wed, 30 Sep 1998 16:48:47 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > In fvwm-module.scm, I've had the default value of debug-fvwm-module as > #t for a while now. You can change your copy to #f, or maybe it's time > to make the default be false as fvwm2 module support seems to be a more > stable now. > Oh, I see you did that already. IMO, the default should be #f, but the variable should be exported (using define-public) so the user can change the debug level from his or her scwmrc. Apologies for another irrelevant message if this is done already. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 16:52:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26942 for scwm-discuss-outgoing; Wed, 30 Sep 1998 16:52:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26934; Wed, 30 Sep 1998 16:52:43 -0400 Message-Id: <199809302052.QAA26934@huis-clos.mit.edu> To: Bill Schottstaedt cc: scwm-discuss@mit.edu Subject: Re: Additions to the gh_ interface. In-reply-to: Your message of "Wed, 30 Sep 1998 05:51:01 PDT." <199809301251.FAA11818@cmn14.stanford.edu> Date: Wed, 30 Sep 1998 16:52:43 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk bil@ccrma.stanford.edu writes: > I fired up the guile-core snapshot yesterday to make sure > the new version works in my little sound editor (it does); > I was using gh_vset and other vector functions that are now > obsolete, so it would be nice if there were a version number > or something I could use with #if -- I didn't immediately > see one (the versiondat.h file, I think, is not included > by gh.h(?) and the version stuff there is "3a" or something > that will be a headache to keep track of). A good (well, OK, good is going a bit far, but workable) way to track these things is to use autoconf tests. If your app is already using autoconf this should not be hard. The configure.in file in the scwm distribution has a test for just about every user-visible C API change between 1.2 and the current snap; the files guile-compat.c and guile-compat.h hide the details of the differing interfaces if you compile in the former and #include the latter. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Wed Sep 30 17:07:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27196 for scwm-discuss-outgoing; Wed, 30 Sep 1998 17:07:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27189; Wed, 30 Sep 1998 17:07:37 -0400 Message-Id: <199809302107.RAA27189@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: menu code In-reply-to: Your message of "30 Sep 1998 08:10:06 PDT." Date: Wed, 30 Sep 1998 17:07:36 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm going to reply to two messages at once because I'm lazy. gjb@cs.washington.edu writes: > Todd Larason writes: > > > > > Is everything marked on the TODO list for 0.9 still intended? I'll be > > impressed if the even rewrite is done soon after the guile 1.3 release > > (October 4th?), must less the decoration rewrite. > Ummm, if the TODO says that we should conveniently ignore it for now. The impending Guile 1.3 release gives us an opportunity to make a nice, very stable release that does not depend on an unstable snapshot series. This is, IMO, more important than trying to sneak all the features in. Heck, I've sometimes thought that all the decoration rewrite stuff could wait until after 1.0 (it would be fruitful material for a 1.1.x development series). > You won't be the only one impressed. The decoration rewrite definitely > won't make 0.9; I think the event rewrite should happen after .9, and > our goal for 0.9 should be bug fixes and ease of building/use so that .9 > can be almost like a 1.0 release of scwm w/o the remaining major > infrastructure changes. Agreed. Towards this end we also need to test it as widely and thoroghly as possible. > > > > PS Thanks yet again for all the cool stuff you have been adding. I > > > love to see the code doing things neither God nor I ever intended a > > > window manager to do :-) > > > > Um, sure! I'm going to take that at face value and not as an oblique > > way of saying 'why are you trying to put all this stuff into my window > > manager when there's real work needed on it?'. =) > Hey, I was tired when I wrote this so I didn't realize it could be taken that way; but I really did mean it in the positive sense. I actually prefer if people make changes that weren't already planned, because I figure stuff on the TODO list would have eventually happened anyway. Plus, it's cool to be able to have slick screenshots, and Greg and I are usually less interested in/qualified qualified to do changes with good screenshot potential. > Don't forget the cleaner separation of interface and implementation in > the menuing code that your changes provide. This clearly is "real" work > that was sorely needed. Extra whiz-bang features are more than welcome > as long as they are reasonably modular so that when we start pulling > scwm apart into pieces they can be left out as individual users choose. > This is very true. Changes that increase modularity are a good thing. Here's another thought. I'd really like to start splitting out some less central features into loadable modules. Previously I'd always planned to add a new feature and handle it this way, which ensured it never happened, but I can think of a good candidate in the current code for loadable-module-ness, namely all the low-level X stuff (X properties, X atoms, the xrm interface, cut buffer support, etc). These features have the useful properties that (1) they are not heavily integrated into other code and (2) many users don't depend on any of them and thus would win from not having to pay the memory footprint cost. Would this be a good thing to do before 0.9? On the plus side, it would let us widely test whether the libtool shared library support and Guile dynamic linking work on platforms people use. On the other hand, maybe we don't want to do that experiment in a release that should otherwise strive for stability. Does anyone here use scwm on a platform that does not support dynamic linking? - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 18:17:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA29791 for scwm-discuss-outgoing; Wed, 30 Sep 1998 18:17:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA29782; Wed, 30 Sep 1998 18:16:58 -0400 Message-Id: <199809302216.SAA29782@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: usage note message In-reply-to: Your message of "30 Sep 1998 14:30:58 PDT." Date: Wed, 30 Sep 1998 18:16:57 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > > (define-public debug-fvwm-module #f) > > > > _after_ the module declaration; the user will still be able to set! > > the debug level from his or her .scwmrc in that case. > > > > The reason we needed to do this the other, hackish, way for some > > different code is, I am afraid, somewhat obscure; it has to do with > > the variables being reference from C code. I think I know how to fix > > it though, and will probably do that soon, because it is really a > > gross hack. > > Well, as you do fix this, it might be nice to introduce a macro for > user-exposed variables. Ideally, such variables could have a docstring > that could be interrogated as well (like functions). In > scwm/scheme/base.scm, e.g., I use ;;;**VAR to mark docstring comments on > variables, but this is not ideal. > I'll take a look, but I am not sure what we can hang the docstring off of for this. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 18:39:00 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA29976 for scwm-discuss-outgoing; Wed, 30 Sep 1998 18:39:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA29973 for ; Wed, 30 Sep 1998 18:38:57 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24776; Wed, 30 Sep 98 18:38:50 EDT Received: (qmail 11106 invoked by uid 501); 30 Sep 1998 22:38:58 -0000 Message-Id: <19980930153857.A10989@molehill.org> Date: Wed, 30 Sep 1998 15:38:57 -0700 From: Todd Larason To: Maciej Stachowiak , Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: menu code References: <199809302107.RAA27189@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199809302107.RAA27189@huis-clos.mit.edu>; from Maciej Stachowiak on Wed, Sep 30, 1998 at 05:07:36PM -0400 X-Tom-Swifty: "But I don't know C++", Tom objected. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980930, Maciej Stachowiak wrote: > Hey, I was tired when I wrote this so I didn't realize it could be > taken that way; but I really did mean it in the positive sense. S'okay, I was pretty sure you did, just wanted to make sure. I'd hate to be stepping on toes. > Plus, it's cool to be able to have slick screenshots, and Greg and I > are usually less interested in/qualified qualified to do changes with > good screenshot potential. I'm not terribly qualified either, but it is something I'm interested in supporting. That's why I made it work with themes people were already developing. I certainly won't be developing any. > Does anyone here use scwm on a platform that does not support dynamic > linking? Were I still at my last job, I'd be using it on an HP-UX system that didn't support the dlopen or dld interfaces, but did support dynamic linking. My memory is that was the only odd one out of Linux, Solaris, Digital Unix, Irix, FreeBSD and BSDI BSD/OS. From owner-scwm-discuss@mit.edu Wed Sep 30 18:57:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30144 for scwm-discuss-outgoing; Wed, 30 Sep 1998 18:57:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30137 for ; Wed, 30 Sep 1998 18:57:12 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA28644; Wed, 30 Sep 98 18:57:06 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30126; Wed, 30 Sep 1998 18:57:05 -0400 Message-Id: <199809302257.SAA30126@huis-clos.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: menu code In-Reply-To: Your message of "Wed, 30 Sep 1998 15:38:57 PDT." <19980930153857.A10989@molehill.org> Date: Wed, 30 Sep 1998 18:57:05 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 980930, Maciej Stachowiak wrote: > > Hey, I was tired when I wrote this so I didn't realize it could be > > taken that way; but I really did mean it in the positive sense. > > S'okay, I was pretty sure you did, just wanted to make sure. I'd > hate to be stepping on toes. > Nope, no problem. I have to admit I used to have anxiety about code going into scwm that I didn't have a chance to personally review line by line, but it's been over a year now (I think) and I've grown to like surprises. > > Plus, it's cool to be able to have slick screenshots, and Greg and I > > are usually less interested in/qualified qualified to do changes with > > good screenshot potential. > > I'm not terribly qualified either, but it is something I'm interested > in supporting. That's why I made it work with themes people were > already developing. I certainly won't be developing any. > I know some graphics people who might develop scwm-specific themes, but repackaging existing stuff (or better yet, being able to use it directly) is a big win. > > Does anyone here use scwm on a platform that does not support dynamic > > linking? > > Were I still at my last job, I'd be using it on an HP-UX system that > didn't support the dlopen or dld interfaces, but did support dynamic > linking. My memory is that was the only odd one out of Linux, Solaris, > Digital Unix, Irix, FreeBSD and BSDI BSD/OS. Guile dynamic linking support does in fact handle HP-UX's `shl' interface. I suspect the only platform that will lose that anyone is at all likely to have is Ultrix, as I don't think GNU dld has been ported to it yet. But I could be wrong. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 19:29:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA32397 for scwm-discuss-outgoing; Wed, 30 Sep 1998 19:29:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA32393; Wed, 30 Sep 1998 19:29:04 -0400 Message-Id: <199809302329.TAA32393@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Change in script handling Date: Wed, 30 Sep 1998 19:29:04 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just changed some stuff about the way perl and guile scripts are handled; ./configure now generates a version with the right path to the interpreter in it. Unfortunately, these changes make automake print a spurious error message, so if you are using the CVS sources, do not be distrubed about complaints regarding missing .in files. This is an automake bug which is fixed in the CVS sources of automake, but not any released version yet. - Maciej From owner-scwm-discuss@mit.edu Wed Sep 30 22:16:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA00412 for scwm-discuss-outgoing; Wed, 30 Sep 1998 22:16:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA00409 for ; Wed, 30 Sep 1998 22:16:02 -0400 Received: from fecundity.webcoi.com by MIT.EDU with SMTP id AA07687; Wed, 30 Sep 98 22:15:55 EDT Received: (from jtl@localhost) by fecundity.webcoi.com (8.8.7/8.8.7) id TAA19353 for scwm-discuss@mit.edu; Wed, 30 Sep 1998 19:20:17 -0700 Message-Id: <19980930191811.24237@molehill.org> Date: Wed, 30 Sep 1998 19:18:11 -0700 From: Todd Larason To: scwm-discuss@molehill.org Subject: some more message window configurations, crashing bug Reply-To: jtl@molehill.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e Sender: owner-scwm-discuss@mit.edu Precedence: bulk This might be interesting to some people. I would put it in flux, except that it uncondtionally adds some hooks. Even if you don't care where the message box is, please read the section below the code snippit. (define (move-message-window-to-mouse w) (let* ((ppx (car (pointer-position))) (ppy (cadr (pointer-position))) (xoff (if (< ppx 40) 0 -.5)) (yoff (if (< ppy 20) .2 -1.2))) (set-message-window-position! ppx ppy xoff yoff))) (define (move-message-window-to-window-center w) (apply set-message-window-position! (append (map + (map truncate (map / (window-frame-size w) '(2 2))) (window-viewport-position w)) '(-.5 -.5)))) (define (move-message-window-to-screen-corner) (set-message-window-position! 0 0 0 0)) (define (move-message-window-to-screen-center) (apply set-message-window-position! (append (map truncate (map / (display-size) '(2 2))) '(-.5 -.5)))) (define (message-window-near-mouse) (set! position-message-window-for-window move-message-window-to-mouse) (set! position-message-window-default move-message-window-to-screen-corner) (move-message-window-to-screen-corner)) (define (message-window-in-window-center) (set! position-message-window-for-window move-message-window-to-window-center) (set! position-message-window-default move-message-window-to-screen-center) (move-message-window-to-screen-center)) (define position-message-window-for-window #f) (define position-message-window-default #f) (add-hook! interactive-move-start-hook (lambda (w) (position-message-window-for-window w))) (add-hook! interactive-move-new-position-hook (lambda (w x y) (position-message-window-for-window w))) (add-hook! interactive-move-finish-hook (lambda (w) (position-message-window-default))) (add-hook! interactive-resize-start-hook (lambda (w x y) (position-message-window-for-window w))) (add-hook! interactive-resize-new-size-hook (lambda (w xd yd) (position-message-window-for-window w))) (add-hook! interactive-resize-finish-hook (lambda (w) (position-message-window-for-window w))) ;(message-window-near-mouse) An earlier version of this had: (add-hook! interactive-resize-start-hook (lambda (w) (position-message-window-for-window w))) (two arguments short). Rather than get a nice backtrace, I got a nice corefile. The segv was on the line source = SCM_FRAME_SOURCE (SCM_FRAME_PREV (current_frame)); in guile's backtrace.c, line 207 in my snapshot. I don't understand the scm_internal_cwdr and the like at all, and don't know where to start debugging this. Pointers? -- "You keep claiming things don't work. Im just going to sit here proving they do. If you play this game for long enough we might even find a real library bug" -- Alan Cox From owner-scwm-discuss@mit.edu Wed Sep 30 22:32:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA00511 for scwm-discuss-outgoing; Wed, 30 Sep 1998 22:32:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA00499; Wed, 30 Sep 1998 22:31:57 -0400 Message-Id: <199810010231.WAA00499@huis-clos.mit.edu> To: jtl@molehill.org cc: scwm-discuss@mit.edu Subject: Re: some more message window configurations, crashing bug In-reply-to: Your message of "Wed, 30 Sep 1998 19:18:11 PDT." <19980930191811.24237@molehill.org> Date: Wed, 30 Sep 1998 22:31:57 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@webcoi.com writes: > > > This might be interesting to some people. I would put it in flux, except > that it uncondtionally adds some hooks. Even if you don't care where the > message box is, please read the section below the code snippit. > > An earlier version of this had: > (add-hook! interactive-resize-start-hook > (lambda (w) > (position-message-window-for-window w))) > > (two arguments short). Rather than get a nice backtrace, I got a nice > corefile. The segv was on the line > source = SCM_FRAME_SOURCE (SCM_FRAME_PREV (current_frame)); > in guile's backtrace.c, line 207 in my snapshot. > > I don't understand the scm_internal_cwdr and the like at all, and > don't know where to start debugging this. Pointers? > The stack saving code that scwm uses to be able to get backtraces has some limitations, in particular, some categories of bugs seem to crash scwm when printing a backtrace. One such category is hook procedures that take the wrong number of arguments getting invoked. Another is hook procedures that have an unbound variable as the body [i.e. (lambda () some-unbound-variable) cores but (lambda () (some-unbound-variable)) doesn't]. Perhaps you just found a third. My attempts to find a simple failing case for this bug have been frustrated so far, but I am working on this now so that, with luck, it can be fixed in Guile before 1.3 if it is a Guile bug. I consider it high priority because, though rare, it is a potential crash waiting to happen in very commonly used code. But to actually address your request for pointers, the manipulations with scm_internal_cwdr and scm_internal_stack_catch and the like are to make sure that, when a hook is invoked, the call happens in a new dynamic root, so that you can't escape from the call with a continuation (I'm pretty sure scwm is not safe against copntinuations), and so that the stack is saved before evaluating, so that debugging information can be retrieved if an error is thrown. This code, while simle, is hard to understand unless you already knoww what is going on and why. Reading the source to root.c and throw.c in Guile may or may not be enlightening. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 1 04:37:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA16968 for scwm-discuss-outgoing; Thu, 1 Oct 1998 04:37:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA16962 for ; Thu, 1 Oct 1998 04:37:00 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA26856; Thu, 1 Oct 98 04:36:48 EDT Received: (qmail 17694 invoked by uid 501); 1 Oct 1998 08:37:14 -0000 Message-Id: <19981001013713.A17576@molehill.org> Date: Thu, 1 Oct 1998 01:37:13 -0700 From: Todd Larason To: scwm-discuss list Subject: menus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Zoos are a necessary evil, I think", said Tom cagily. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just checked in my current menu code. There's LOTs left I'd like to do with it, but a couple notes on things that are somewhat 'broken': set-menu-look! doesn't change the look used for already-defined menus; I expect I'm just missing a level of indirection. I had to remove the menu-look paramater I added to make-menu, because there's evidentally a 10-argument limit to guile functions. Any thoughts on how to restructure the args to make-menu, or some other workaround? To use the XPM menus, go find a KDE theme you like, and then do something like: (set-menu-look! xpm-shaped-menu-look) (define menu-decor-blue-metal (list (make-image "BlueMetal/topleft.xpm") (make-image "BlueMetal/top.xpm") (make-image "BlueMetal/topright.xpm") (make-image "BlueMetal/left.xpm") (make-image "BlueMetal/right.xpm") (make-image "BlueMetal/bottomleft.xpm") (make-image "BlueMetal/bottom.xpm") (make-image "BlueMetal/bottomright.xpm"))) (define menu-root (menu (list (menuitem "Root Menu" #f) menu-title (menuitem "Red Hat Applications" #:action 'menu-redhat-apps) (menuitem "&Window actions" #:action 'menu-window-actions) menu-separator (menuitem "&Switch to..." #:action (lambda () (show-window-list-menu #:show-geometry #t))) (menuitem "Re&fresh Screen" ; #:image-left "mini-ray.xpm" #:action refresh) menu-separator (menuitem "&Restart scwm" #:action (lambda () (restart "scwm"))) (menuitem "&Exit scwm" #:action 'menu-quit-verify)) #:image-side "jtl-linux-98-menu.xpm" #:image-align 'bottom #:color-bg-image-side "grey80" #:image-bg (make-image "wh_marble_3.xpm") #:color-stipple "navy" ; #:color-bg (make-color "#242b4a") ; #:color-text "yellow" #:extra menu-decor-blue-metal)) The filenames don't seem to be standardized enough to build the lists automatically, but it's usually clear. The list is top left, top, top right, left, right, bottom left, bottom, bottom right, just like reading. If you don't turn on XPM menus, you should see basically no changes. Please let me know if you do. From owner-scwm-discuss@mit.edu Thu Oct 1 04:59:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA17364 for scwm-discuss-outgoing; Thu, 1 Oct 1998 04:59:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA17360; Thu, 1 Oct 1998 04:59:33 -0400 Message-Id: <199810010859.EAA17360@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Old crashing bug Date: Thu, 01 Oct 1998 04:59:33 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I found a workaround for the old crashing on a hook backtrace bug which occurs, e.g. when a hook procedure with the wrong number of args is installed and checked it in. If you have hook-related code that used to crash in this way (e.g. Todd's recent post), please test it again. Thanks, Maciej From owner-scwm-discuss@mit.edu Thu Oct 1 05:23:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA17670 for scwm-discuss-outgoing; Thu, 1 Oct 1998 05:23:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA17667 for ; Thu, 1 Oct 1998 05:23:25 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA15969; Thu, 1 Oct 98 05:23:18 EDT Received: (qmail 18664 invoked by uid 501); 1 Oct 1998 09:23:40 -0000 Message-Id: <19981001022338.A18632@molehill.org> Date: Thu, 1 Oct 1998 02:23:38 -0700 From: Todd Larason To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Old crashing bug References: <199810010859.EAA17360@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810010859.EAA17360@huis-clos.mit.edu>; from Maciej Stachowiak on Thu, Oct 01, 1998 at 04:59:33AM -0400 X-Tom-Swifty: "I wonder what syllables I should sing these sixteenth notes to", said Ward Swingle dubiously. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981001, Maciej Stachowiak wrote: > > I found a workaround for the old crashing on a hook backtrace bug > which occurs, e.g. when a hook procedure with the wrong number of args > is installed and checked it in. If you have hook-related code that > used to crash in this way (e.g. Todd's recent post), please test it > again. Mine still crashes. My case is a function that takes 1 argument added to a hook and called with 3 arguments; maybe your fix works for the opposite case but not this one? From owner-scwm-discuss@mit.edu Thu Oct 1 10:59:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA19031 for scwm-discuss-outgoing; Thu, 1 Oct 1998 10:59:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA19017; Thu, 1 Oct 1998 10:58:54 -0400 Message-Id: <199810011458.KAA19017@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Old crashing bug In-reply-to: Your message of "Thu, 01 Oct 1998 02:23:38 PDT." <19981001022338.A18632@molehill.org> Date: Thu, 01 Oct 1998 10:58:53 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981001, Maciej Stachowiak wrote: > > > > I found a workaround for the old crashing on a hook backtrace bug > > which occurs, e.g. when a hook procedure with the wrong number of args > > is installed and checked it in. If you have hook-related code that > > used to crash in this way (e.g. Todd's recent post), please test it > > again. > > Mine still crashes. My case is a function that takes 1 argument added > to a hook and called with 3 arguments; maybe your fix works for the > opposite case but not this one? D'oh! No, actually, I don't think it should care, or even notice. In fact, I found the workaround while testing with both a one-argument proc on a 0-arg hoook and vice versa. Back to the grindstone... - Maciej From owner-scwm-discuss@mit.edu Thu Oct 1 14:31:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA20248 for scwm-discuss-outgoing; Thu, 1 Oct 1998 14:31:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA20245 for ; Thu, 1 Oct 1998 14:31:20 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16727; Thu, 1 Oct 98 14:31:04 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA23719; Thu, 1 Oct 1998 11:31:04 -0700 (PDT) To: Maciej Stachowiak Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: Old crashing bug References: <199810011458.KAA19017@huis-clos.mit.edu> From: Greg Badros Date: 01 Oct 1998 11:31:04 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 01 Oct 1998 10:58:53 EDT" Message-Id: Lines: 49 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > jtl@molehill.org writes: > > On 981001, Maciej Stachowiak wrote: > > > > > > I found a workaround for the old crashing on a hook backtrace bug > > > which occurs, e.g. when a hook procedure with the wrong number of args > > > is installed and checked it in. If you have hook-related code that > > > used to crash in this way (e.g. Todd's recent post), please test it > > > again. > > > > Mine still crashes. My case is a function that takes 1 argument added > > to a hook and called with 3 arguments; maybe your fix works for the > > opposite case but not this one? Mine too. With latest (yesterday evening) guile via anoncvs. Here's my backtrace (though I imagine you can reproduce it -- I was testing using the interactive-move-new-position-hook [probably same as Todd is using]). Greg #0 0x40151dfc in display_error_body (a=0xbfffdfa0) at backtrace.c:206 #1 0x40145249 in scm_internal_catch (tag=9076, body=0x40151d04 , body_data=0xbfffdfa0, handler=0x40151f8c , handler_data=0xbfffdf88) at throw.c:236 #2 0x401520b3 in scm_display_error (stack=1077372040, port=1076801160, subr=8564, message=1077372664, args=1077372672, rest=10612) at backtrace.c:259 #3 0x8057cef in scwm_handle_error (data=0x0, tag=1076770664, throw_args=1077372632) at callbacks.c:65 #4 0x40145222 in scm_internal_catch (tag=9076, body=0x401455ac , body_data=0xbfffe05c, handler=0x8057c2c , handler_data=0x0) at throw.c:231 #5 0x40145642 in scm_internal_stack_catch (tag=9076, body=0x8057d8c , body_data=0xbfffe15c, handler=0x8057c2c , handler_data=0x0) at throw.c:377 #6 0x8057de6 in cwssdr_body (data=0xbfffe130) at callbacks.c:110 #7 0x40145249 in scm_internal_catch (tag=9076, body=0x8057db8 , body_data=0xbfffe130, handler=0x40137834 , handler_data=0xbfffe0fc) at throw.c:236 #8 0x40137a30 in scm_internal_cwdr (body=0x8057db8 , body_data=0xbfffe130, handler=0x8057c2c , handler_data=0x80a8cf6, stack_start=0xbfffe164) at root.c:300 #9 0x8057e2d in scm_internal_stack_cwdr (body=0x8057d8c , body_data=0xbfffe15c, handler=0x8057c2c , handler_data=0x80a8cf6, stack_item=0xbfffe164) at callbacks.c:126 #10 0x8057e6a in scwm_safe_apply (proc=1077396320, args=1077372928) at callbacks.c:141 #11 0x8057f60 in scwm_safe_call3 (proc=1077396320, arg1=1077117328, arg2=420, arg3=64) at callbacks.c:189 #12 0x805838c in call3_hooks (hook=1077012920, arg1=1077117328, arg2=420, arg3=64) at callbacks.c:382 #13 0x8071678 in moveLoop (psw=0x81ce500, XOffset=-295, YOffset=-380, OutlineWidth=678, OutlineHeight=803, FinalX=0xbfffe268, FinalY=0xbfffe264, opaque_move=1) at move.c:409 #14 0x8072100 in InteractiveMove (psw=0x81ce500, fOpaque=1, FinalX=0xbfffe268, FinalY=0xbfffe264) at move.c:724 #15 0x807221c in interactive_move (win=1077117328, opaque_p=9076) at move.c:760 From owner-scwm-discuss@mit.edu Thu Oct 1 18:00:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA21625 for scwm-discuss-outgoing; Thu, 1 Oct 1998 18:00:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA21622 for ; Thu, 1 Oct 1998 18:00:39 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA28948; Thu, 1 Oct 98 18:00:21 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA26463; Thu, 1 Oct 1998 15:00:20 -0700 (PDT) To: scwm-discuss@mit.edu Subject: deiconifying to current desktop From: Greg Badros Date: 01 Oct 1998 15:00:20 -0700 Message-Id: Lines: 15 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk A while back someone (my apologies for forgetting who) asked about deiconifying a window to the current desktop. I'm not sure that this is possible right now (though it definitely needs to be). Can anyone think of a way to do this? I'm planning on either adding an optional position argument to deiconify, or permit moving of windows while they are iconified (right now move-window moves the icon window if the window is iconified -- it doesn't move the framed window). Thoughts? Greg From owner-scwm-discuss@mit.edu Fri Oct 2 01:41:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA26812 for scwm-discuss-outgoing; Fri, 2 Oct 1998 01:41:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA26809 for ; Fri, 2 Oct 1998 01:41:54 -0400 Received: from M2-032-9.MIT.EDU by MIT.EDU with SMTP id AA22136; Fri, 2 Oct 98 01:41:34 EDT Received: by m2-032-9.mit.edu (SMI-8.6/4.7) id BAA03820; Fri, 2 Oct 1998 01:41:36 -0400 Message-Id: <199810020541.BAA03820@m2-032-9.mit.edu> To: scwm-discuss@mit.edu Subject: Crashing bug Date: Fri, 02 Oct 1998 01:41:36 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hmm, the bug was deeper in Guile than I thought, my workaround worked in a few cases but not most. The good news is that I found a rather small minimal failing case. The bad news is that the debug code the crash relates to is incredibly hairy, and I will be surprised and impressed if the people on bug-guile can fix it in a small amount of time. I have no patch for them yet, sad to say. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 03:23:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA30196 for scwm-discuss-outgoing; Fri, 2 Oct 1998 03:23:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA30189; Fri, 2 Oct 1998 03:23:25 -0400 Message-Id: <199810020723.DAA30189@huis-clos.mit.edu> To: Joshua Woolsey cc: scwm-discuss@mit.edu Subject: Re: scwm - numlock fix In-reply-to: Your message of "Thu, 01 Oct 1998 20:05:37 -0300." <36140AC0.75E4CD25@ns.sympatico.ca> Date: Fri, 02 Oct 1998 03:23:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk memph@ns.sympatico.ca writes: > hello, > when numlock is on the mouse does not work correctly (can't bring > windows to the forground) > To fix this one can uncomment the 'ServerNumLock' statment in the > XF86Config file. Ugh, I hate when X does silly things like that. > > ps, i am having problems with scwm locking the audio device (and hence > RealAudio does not work under scwm), i am looking for a solution to this > but i don't know where scwm does anything with sounds, if you could lead > me in the right direction i could try to fix this. > I'm not sure why that would happen, scwm does not, a far as I know, access the sound device at all (yet). Can you cat simple .au files to /dev/audio directly when running scwm? - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 03:39:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA31178 for scwm-discuss-outgoing; Fri, 2 Oct 1998 03:39:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA31166; Fri, 2 Oct 1998 03:39:30 -0400 Message-Id: <199810020739.DAA31166@huis-clos.mit.edu> To: Maciej Stachowiak cc: scwm-discuss@mit.edu Subject: Re: Crashing bug In-reply-to: Your message of "Fri, 02 Oct 1998 01:41:36 EDT." <199810020541.BAA03820@m2-032-9.mit.edu> Date: Fri, 02 Oct 1998 03:39:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I wrote: > > I have no patch for them yet, sad to say. > But I do now and submitted it to bug-guile. This problem should go away soon, therefore. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 04:23:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA31503 for scwm-discuss-outgoing; Fri, 2 Oct 1998 04:23:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA31500 for ; Fri, 2 Oct 1998 04:23:44 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA14784; Fri, 2 Oct 98 04:23:27 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.115.98]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id JAA05776 for ; Fri, 2 Oct 1998 09:20:53 +0100 (BST) Message-Id: <12769.199810020823@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Fri, 2 Oct 1998 09:23:00 +0100 Date: Fri, 2 Oct 1998 09:25:59 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Alt-TAB window switching.... To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I haven't had time to play around much with SCWM, (finishing up my thesis and just started an RA job), but I have a couple of suggestions:- Easy ones first(!) At present, I'm using scwm and Gnome (Gnome is still flaky as hell), I don't have a virtual desktop browser - how can I set up CTRL-Arrow Keys to move to a corresponding desktop. I often have many windows in the current screen, completely filling the root window - I know I can bind a key to bring up a window list, but one thing that would be useful is the type of ALT-Tab task window ala Win98 (sorry, I apologise for using such a vile OS), with a little icon-type window... And one thing that would be very useful - a lot of you developers/users have greatly modified the .scwmrc files - obviously things change/break etc, but if people have a nice setup (In their opinion) wouldn't it be a good idea to have a central collection (if only for people to see the different ways of doing things) ? Keep up the cool work :-) Mark. From owner-scwm-discuss@mit.edu Fri Oct 2 04:39:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA31636 for scwm-discuss-outgoing; Fri, 2 Oct 1998 04:39:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA31633 for ; Fri, 2 Oct 1998 04:39:19 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA09054; Fri, 2 Oct 98 04:38:57 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA02345; Fri, 2 Oct 1998 10:38:53 +0200 To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Oct 1998 10:38:53 +0200 In-Reply-To: Mark Toller's message of "Fri, 2 Oct 1998 09:25:59 +0100 (GMT)" Message-Id: Lines: 42 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > At present, I'm using scwm and Gnome (Gnome is still flaky as hell), I > don't have a virtual desktop browser - how can I set up CTRL-Arrow Keys > to move to a corresponding desktop. Why don't you use the fvwm2 pager? In any case, here're some functions for moving right & left. They go to the next viewport until they've made it to the last viewport & then go to the next desktop. I bind them to control-meta-left-arrow & control-meta-right-arrow: (define (page-rt) (let ((vp (viewport-position)) (d (current-desk)) (ds (desk-size))) (if (>= (car vp) (* (- (car ds) 1) (%x 100))) (begin (set-current-desk! (1+ d)) (move-viewport (- (car vp)) 0)) (move-viewport (%x 100) 0)))) (define (page-left) (let ((vp (viewport-position)) (d (current-desk)) (ds (desk-size))) (if (and (= (car vp) 0) (> d 0)) (begin (set-current-desk! (1- d)) (move-viewport (* (%x 100) (1- (car ds))) 0)) (move-viewport (%x -100) 0)))) (bind-key 'all "C-M-Right" page-rt) (bind-key 'all "C-M-Left" page-left) You should be able to work out the mods you need for the up & down arrow (if you want to actually navigate a 2d set of window panes). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Oct 2 04:42:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA31673 for scwm-discuss-outgoing; Fri, 2 Oct 1998 04:42:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA31670 for ; Fri, 2 Oct 1998 04:42:35 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA16085; Fri, 2 Oct 98 04:42:17 EDT Received: (qmail 17697 invoked by uid 501); 2 Oct 1998 08:42:14 -0000 Message-Id: <19981002014214.A17197@molehill.org> Date: Fri, 2 Oct 1998 01:42:14 -0700 From: Todd Larason To: mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <12769.199810020823@penelope.ecs.soton.ac.uk>; from Mark Toller on Fri, Oct 02, 1998 at 09:25:59AM +0100 X-Tom-Swifty: "All I ever do is work", Tom droned. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981002, Mark Toller wrote: > At present, I'm using scwm and Gnome (Gnome is still flaky as hell), I > don't have a virtual desktop browser - how can I set up CTRL-Arrow Keys > to move to a corresponding desktop. If you aren't using anything from flux.scm now, add (use-modules (app scwm flux)) to your .scwmrc file, then something like: (key-viewport-moves "C" 100 "Left" "Down" "Up" "Right") the "C" there is the modifier key to use, 'C' for 'control'. The 100 is a percent to move. You could add (key-viewport-moves "C-S" 10 "Left" "Down" "Up" "Right") to let control-shift-arrow scroll in smaller amounts. > one thing that would be useful is the type of ALT-Tab task window ala > Win98 (sorry, I apologise for using such a vile OS), with a little > icon-type window... There are several varieties of this in the sample scwmrcs, but as far as I know none of them have the little icon window. This version doesn't either, but does have a few nice differences: (define (jtl-next-window) (next-window #:only (lambda (w) (> (percent-visible w) 30)) #:except iconified? #:proc jtl-window-list-proc)) (define (jtl-prev-window) (prev-window #:only (lambda (w) (> (percent-visible w) 30)) #:except iconified? #:proc jtl-window-list-proc)) (define*-public (jtl-window-list-proc #&optional (w (get-window))) (cond (w (deiconify w) (focus w) (raise-window w)))) (bind-key 'all "M-Tab" jtl-next-window) (bind-key 'all "M-S-Tab" jtl-prev-window) This will make Meta-Tab and shift-Meta-tab move between windows, skipping icons and windows tha are less than 30% on this screen. Unlike the standard winlist function, this one won't move either the viewport or the pointer. > etc, but if people have a nice setup (In their opinion) wouldn't it be > a good idea to have a central collection (if only for people to see the > different ways of doing things) ? There's the beginnings of this in the sample.scwmrcs directory of the distribution. I think a website with snippits of useful/unusual/interesting configurations would be a great idea, if someone has the time and inclination. From owner-scwm-discuss@mit.edu Fri Oct 2 04:54:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA31849 for scwm-discuss-outgoing; Fri, 2 Oct 1998 04:54:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA31846 for ; Fri, 2 Oct 1998 04:54:43 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16771; Fri, 2 Oct 98 04:54:26 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA02585; Fri, 2 Oct 1998 10:54:06 +0200 To: Todd Larason Cc: mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> <19981002014214.A17197@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Oct 1998 10:54:06 +0200 In-Reply-To: Todd Larason's message of "Fri, 2 Oct 1998 01:42:14 -0700" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981002, Mark Toller wrote: > > > At present, I'm using scwm and Gnome (Gnome is still flaky as hell), I > > don't have a virtual desktop browser - how can I set up CTRL-Arrow Keys > > to move to a corresponding desktop. > > If you aren't using anything from flux.scm now, add > (use-modules (app scwm flux)) > to your .scwmrc file, then something like: > (key-viewport-moves "C" 100 "Left" "Down" "Up" "Right") Isn't it the case that this will move viewports but not desktops? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Oct 2 05:10:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA31999 for scwm-discuss-outgoing; Fri, 2 Oct 1998 05:10:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA31996 for ; Fri, 2 Oct 1998 05:10:37 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA17713; Fri, 2 Oct 98 05:10:19 EDT Received: (qmail 22195 invoked by uid 501); 2 Oct 1998 09:10:15 -0000 Message-Id: <19981002021012.A21254@molehill.org> Date: Fri, 2 Oct 1998 02:10:12 -0700 From: Todd Larason To: "Harvey J. Stein" Cc: mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> <19981002014214.A17197@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Harvey J. Stein on Fri, Oct 02, 1998 at 10:54:06AM +0200 X-Tom-Swifty: "Why don't you have some fruit?", asked Tom with aplomb. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981002, Harvey J. Stein wrote: > Todd Larason writes: > > If you aren't using anything from flux.scm now, add > > (use-modules (app scwm flux)) > > to your .scwmrc file, then something like: > > (key-viewport-moves "C" 100 "Left" "Down" "Up" "Right") > > Isn't it the case that this will move viewports but not desktops? Oops, you're absolutely right. What are the relative advantages of desktops over viewports? From owner-scwm-discuss@mit.edu Fri Oct 2 05:32:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA32187 for scwm-discuss-outgoing; Fri, 2 Oct 1998 05:32:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA32184 for ; Fri, 2 Oct 1998 05:32:48 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA19034; Fri, 2 Oct 98 05:32:28 EDT Received: (qmail 23362 invoked by uid 501); 2 Oct 1998 09:32:27 -0000 Message-Id: <19981002023226.A23328@molehill.org> Date: Fri, 2 Oct 1998 02:32:26 -0700 From: Todd Larason To: Maciej Stachowiak , Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: menu code References: <199809302107.RAA27189@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199809302107.RAA27189@huis-clos.mit.edu>; from Maciej Stachowiak on Wed, Sep 30, 1998 at 05:07:36PM -0400 X-Tom-Swifty: "I support mechanization", said the promoter. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 980930, Maciej Stachowiak wrote: > Here's another thought. I'd really like to start splitting out some > less central features into loadable modules. I have a patch that will make the xpm menu support a loadable module, using the nice guile interface where (use-module (app scwm xpm)) loads and initializes the module. If we want this in 0.9, I can check it in, and start looking for other reasonable candidates. I'm surprised and impressed how small the changes are; the automake, autoconf, libtool and guile people deserve many thanks. The patch creates a new directory in libdir analogous to the scwm-modules directory in sharedir, and puts binary modules there. > Does anyone here use scwm on a platform that does not support dynamic > linking? libtool has some support ("dlpreopening") for helping apps simulate dlopen on platforms that don't support it. I don't see any evidence that guile is set up to handle it though. From owner-scwm-discuss@mit.edu Fri Oct 2 06:14:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA32422 for scwm-discuss-outgoing; Fri, 2 Oct 1998 06:14:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA32419 for ; Fri, 2 Oct 1998 06:14:50 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AB21859; Fri, 2 Oct 98 06:14:32 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id MAA02992; Fri, 2 Oct 1998 12:14:18 +0200 To: Todd Larason Cc: "Harvey J. Stein" , mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> <19981002014214.A17197@molehill.org> <19981002021012.A21254@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Oct 1998 12:14:17 +0200 In-Reply-To: Todd Larason's message of "Fri, 2 Oct 1998 02:10:12 -0700" Message-Id: Lines: 34 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981002, Harvey J. Stein wrote: > > Todd Larason writes: > > > If you aren't using anything from flux.scm now, add > > > (use-modules (app scwm flux)) > > > to your .scwmrc file, then something like: > > > (key-viewport-moves "C" 100 "Left" "Down" "Up" "Right") > > > > Isn't it the case that this will move viewports but not desktops? > > Oops, you're absolutely right. What are the relative advantages of > desktops over viewports? God only knows. I guess a viewport is the size of the screen. It's a view of part of the desktop. Windows can be positioned anywhere on a given desktop, and thus you can see part of a window depending on how the viewport is positioned. However, you can configure things so that the desktop is carved into a set of viewports (like window panes), in which case the only functional difference becomes that the parts of windows sticking out past the edge of a viewport are visible in the adjacent viewport. The parts sticking out past the edge are invisible in the next desktop. Another difference is that there're an infinite # of desktops, but a finite fixed grid of viewports. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Oct 2 07:53:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00072 for scwm-discuss-outgoing; Fri, 2 Oct 1998 07:53:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA00069 for ; Fri, 2 Oct 1998 07:53:38 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA29906; Fri, 2 Oct 98 07:53:17 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.115.98]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id MAA08933 for ; Fri, 2 Oct 1998 12:50:25 +0100 (BST) Message-Id: <9214.199810021152@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Fri, 2 Oct 1998 12:52:31 +0100 Date: Fri, 2 Oct 1998 12:55:33 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Re: Alt-TAB window switching.... To: scwm-discuss@mit.edu In-Reply-To: <19981002014214.A17197@molehill.org> Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk [snip] > (define (jtl-next-window) > (next-window #:only (lambda (w) > (> (percent-visible w) > 30)) > #:except iconified? > #:proc jtl-window-list-proc)) > > (define (jtl-prev-window) > (prev-window #:only (lambda (w) > (> (percent-visible w) > 30)) > #:except iconified? > #:proc jtl-window-list-proc)) > (define*-public (jtl-window-list-proc #&optional (w (get-window))) > (cond > (w (deiconify w) > (focus w) > (raise-window w)))) > (bind-key 'all "M-Tab" jtl-next-window) > (bind-key 'all "M-S-Tab" jtl-prev-window) OK, I can't actully get this code to work, but I imagine it has the same problem as I'm encountering - namely, I'm working in one window, full screen, and need to bring the calculator to the front - using these forms of window switching, each window you cycle through brings it to the front, so you end up with the calculator on top, with many other windows blocking the view to the one you were working in, that has the data you need to enter into the calculator! Hence, what I use at the moment, is simply :- (bind-key 'all "M-Tab" (lambda () (show-window-list-menu #:show-geometry #t))) and then use the mouse or arrow keys to select the window from the list... surely there must be a way to modify this so that once this window-list appears, another ALT-Tab would move down the list, and when released, select the current item - this would give an almost exact duplication of Alt-tab under windows... ? Thanks for the info on desktop switching. Cheers, Mark. From owner-scwm-discuss@mit.edu Fri Oct 2 11:21:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA01049 for scwm-discuss-outgoing; Fri, 2 Oct 1998 11:21:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA01046 for ; Fri, 2 Oct 1998 11:21:35 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20914; Fri, 2 Oct 98 11:21:09 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23816; Fri, 2 Oct 1998 08:20:57 -0700 (PDT) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Todd Larason , mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: Re: Alt-TAB window switching.... References: <12769.199810020823@penelope.ecs.soton.ac.uk> <19981002014214.A17197@molehill.org> <19981002021012.A21254@molehill.org> From: Greg Badros Date: 02 Oct 1998 08:20:57 -0700 In-Reply-To: hjstein@bfr.co.il's message of "02 Oct 1998 12:14:17 +0200" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > > Oops, you're absolutely right. What are the relative advantages of > > desktops over viewports? > > God only knows. > > I guess a viewport is the size of the screen. It's a view of part of > the desktop. Windows can be positioned anywhere on a given desktop, > and thus you can see part of a window depending on how the viewport is > positioned. > > However, you can configure things so that the desktop is carved into a > set of viewports (like window panes), in which case the only > functional difference becomes that the parts of windows sticking out > past the edge of a viewport are visible in the adjacent viewport. The > parts sticking out past the edge are invisible in the next desktop. > > Another difference is that there're an infinite # of desktops, but a > finite fixed grid of viewports. Desktops have their own coordinate system so you don't get into the sometimes confusing virtual vs. viewport issue. If desktops are the size of the physical X display, then a windows virtual position is the same as its viewport position always, which simplifies management of windows in some way. Virtual desktops and viewports are useful if you have large windows (bigger than the physical X display) or want to rearrange your windows in the context of a larger space (e.g., this can be especially useful with partial viewport moves -- though many don't use the feature, the viewport can be positioned at arbitrary places in the virtual desktop, not just at multiples of the display size. Greg From owner-scwm-discuss@mit.edu Fri Oct 2 11:26:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA01102 for scwm-discuss-outgoing; Fri, 2 Oct 1998 11:26:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA01099 for ; Fri, 2 Oct 1998 11:26:21 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22603; Fri, 2 Oct 98 11:25:56 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA23819; Fri, 2 Oct 1998 08:25:54 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <9214.199810021152@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 02 Oct 1998 08:25:53 -0700 In-Reply-To: Mark Toller's message of "Fri, 2 Oct 1998 12:55:33 +0100 (GMT)" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > OK, I can't actully get this code to work, but I imagine it has the > same problem as I'm encountering - namely, I'm working in one window, > full screen, and need to bring the calculator to the front - using > these forms of window switching, each window you cycle through brings > it to the front, so you end up with the calculator on top, with many > other windows blocking the view to the one you were working in, that > has the data you need to enter into the calculator! I think we need our new event system to detect the release of the modifiers to do something nicer like waiting for the release of all keys before actually giving focus to the new window. Then one could make M-Tab bound to something that just highlights the next window (w/o giving it the focus) and gives its name using the message-window. Then on release of "meta", the new window could get the focus. > Hence, what I use at the moment, is simply :- > > (bind-key 'all "M-Tab" (lambda () > (show-window-list-menu #:show-geometry #t))) > > and then use the mouse or arrow keys to select the window from the > list... surely there must be a way to modify this so that once this > window-list appears, another ALT-Tab would move down the list, and when > released, select the current item - this would give an almost exact > duplication of Alt-tab under windows... ? It'd be pretty easy to do this in the current C code, but it's probably better to just wait for the event rewrite which will permit such flexibility at the scheme level. Greg From owner-scwm-discuss@mit.edu Fri Oct 2 11:54:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA01360 for scwm-discuss-outgoing; Fri, 2 Oct 1998 11:54:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA01357 for ; Fri, 2 Oct 1998 11:54:23 -0400 Received: from talisker.channelpoint.com by MIT.EDU with SMTP id AA03526; Fri, 2 Oct 98 11:53:57 EDT Received: by channelpoint.com (SMI-8.6/SMI-SVR4) id JAA13242; Fri, 2 Oct 1998 09:53:51 -0600 To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <9214.199810021152@penelope.ecs.soton.ac.uk> From: Sam Falkner Date: 02 Oct 1998 09:53:50 -600 In-Reply-To: Mark Toller's message of "Fri, 2 Oct 1998 12:55:33 +0100 (GMT)" Message-Id: Lines: 41 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk i'm very interested in this Alt-Tab stuff too. i hate MS windows as much as anyone, but i do like some of their keyboard shortcuts. if you have a kinesis ergonomic keyboard (www.kinesis-ergo.com), these kinds of shortcuts are particularly nice. Alt-Tab on my keyboard is very comfortable to type. (i have no financial interest in kinesis, except that i'd like them to stay in business so i can replace their stuff as i wear it out!) Mark Toller writes: > [ . . . ] > Hence, what I use at the moment, is simply :- > (bind-key 'all "M-Tab" (lambda () > (show-window-list-menu #:show-geometry #t))) this is cool, and is better than what i'm currently doing; i'll switch to this! > and then use the mouse or arrow keys to select the window from the > list... surely there must be a way to modify this so that once this > window-list appears, another ALT-Tab would move down the list, and > when released, select the current item - this would give an almost > exact duplication of Alt-tab under windows... ? this would be better still; i'd like being able to use the same key sequences as i do at work (where i'm forced to use NT). > [ . . . ] i'd still like to see behavior that's closer to what windows does, i.e. the pop-up with the full-sized icons, a box around your current selection, and releasing the Alt key making the current selection pop to foreground/in-focus. i imagine that scwm integrating with the gtk toolkit might make this rather easy, i.e. you could write it in guile. does anyone agree, or should i (or someone) try to write it in C, embedded in scwm or as an external fvwm module thingy? any opinions? - sam From owner-scwm-discuss@mit.edu Fri Oct 2 13:02:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA01969 for scwm-discuss-outgoing; Fri, 2 Oct 1998 13:02:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA01964; Fri, 2 Oct 1998 13:02:51 -0400 Message-Id: <199810021702.NAA01964@huis-clos.mit.edu> To: Sam Falkner cc: scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... In-reply-to: Your message of "02 Oct 1998 09:53:50." Date: Fri, 02 Oct 1998 13:02:50 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk samf@channelpoint.com writes: > > i'd still like to see behavior that's closer to what windows does, > i.e. the pop-up with the full-sized icons, a box around your current > selection, and releasing the Alt key making the current selection pop > to foreground/in-focus. i imagine that scwm integrating with the gtk > toolkit might make this rather easy, i.e. you could write it in guile. > does anyone agree, or should i (or someone) try to write it in C, > embedded in scwm or as an external fvwm module thingy? any opinions? > I think the key points to emulating Windoze Alt+Tab switching are the following: * Traverse windows in LRU order on Alt+Tab as long as Alt is held down. * Provide visual feedback of some sort along the way. * Do not confirm until Alt is released. The stickler as far as writing this in Scheme goes, is that there is no way to bind key releases right now. Using the fvwm module interface won't help with that, plus the fvwm module interface is gross in many ways anyway. The new event model will solve the last point, whereupon I think we will soon have windows-style alt-tabbing. Another note: someone, possibly me, should hack the window list menu to have an option to show mini-icons for windows that have them. This would provide a slightly better substitute for the Windows row of icons thing. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 13:38:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02261 for scwm-discuss-outgoing; Fri, 2 Oct 1998 13:38:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA02258 for ; Fri, 2 Oct 1998 13:38:11 -0400 Received: from dns1.tc.net by MIT.EDU with SMTP id AA19668; Fri, 2 Oct 98 13:37:50 EDT Received: from [10.16.190.28] by dns1.tc.net for id NAA16024; Fri Oct 2 13:37:47 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id NAA12230; Fri, 2 Oct 1998 13:37:46 -0400 Subject: FVWMButtons in SCWM? Date: 02 Oct 1998 13:37:46 -0400 Message-Id: Lines: 10 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: scwm-discuss@mit.edu From: Doug McNaught Sender: owner-scwm-discuss@mit.edu Precedence: bulk Anybody got a .scwmrc that show how to use FVWMButtons (especially with swallowing apps)? I've got the pager working well but I haven't had time to try to get Buttons working, and I'd love an example to work from... -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Fri Oct 2 13:58:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02461 for scwm-discuss-outgoing; Fri, 2 Oct 1998 13:58:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA02454; Fri, 2 Oct 1998 13:58:27 -0400 Message-Id: <199810021758.NAA02454@huis-clos.mit.edu> To: Doug McNaught cc: scwm-discuss@mit.edu Subject: Re: FVWMButtons in SCWM? In-reply-to: Your message of "02 Oct 1998 13:37:46 EDT." Date: Fri, 02 Oct 1998 13:58:24 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk doug@tc.net writes: > Anybody got a .scwmrc that show how to use FVWMButtons (especially > with swallowing apps)? I've got the pager working well but I haven't > had time to try to get Buttons working, and I'd love an example to > work from... > A while ago, someone mentioned using FvwmButtons with scwm, perhaps you could check the archives to see if he posted an example config. Do you have an FvwmButtons configuration from an fvwm2rc that you'd like to convert, or do you just want to know how to write one from scratch? - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 14:03:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA02522 for scwm-discuss-outgoing; Fri, 2 Oct 1998 14:03:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA02519 for ; Fri, 2 Oct 1998 14:03:15 -0400 Received: from dns1.tc.net by MIT.EDU with SMTP id AA15119; Fri, 2 Oct 98 14:02:49 EDT Received: from [10.16.190.28] by dns1.tc.net for id OAA18565; Fri Oct 2 14:02:51 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id OAA12313; Fri, 2 Oct 1998 14:02:50 -0400 Subject: Re: FVWMButtons in SCWM? References: <199810021758.NAA02454@huis-clos.mit.edu> Date: 02 Oct 1998 14:02:50 -0400 In-Reply-To: Maciej Stachowiak's message of "Fri, 02 Oct 1998 13:58:24 EDT" Message-Id: Lines: 28 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: Maciej Stachowiak From: Doug McNaught Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > doug@tc.net writes: > > Anybody got a .scwmrc that show how to use FVWMButtons (especially > > with swallowing apps)? I've got the pager working well but I haven't > > had time to try to get Buttons working, and I'd love an example to > > work from... > > > > A while ago, someone mentioned using FvwmButtons with scwm, perhaps > you could check the archives to see if he posted an example config. > > Do you have an FvwmButtons configuration from an fvwm2rc that you'd > like to convert, or do you just want to know how to write one from > scratch? I'll be generating it from scratch, because I just moved from fvwm1 to scwm. I don't doubt that I can hack one up; I just wanted to see if someone had done it before. I'll check the list archive for sure. -Doug [hoping I can squeeze out some time this weekend to grab the latest guile and scwm snapshots and do some hacking] -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Fri Oct 2 14:21:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA02739 for scwm-discuss-outgoing; Fri, 2 Oct 1998 14:21:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA02735; Fri, 2 Oct 1998 14:21:33 -0400 Message-Id: <199810021821.OAA02735@huis-clos.mit.edu> To: Doug McNaught cc: scwm-discuss@mit.edu Subject: Re: FVWMButtons in SCWM? In-reply-to: Your message of "02 Oct 1998 14:02:50 EDT." Date: Fri, 02 Oct 1998 14:21:33 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk doug@tc.net writes: > > I'll be generating it from scratch, because I just moved from fvwm1 to > scwm. I don't doubt that I can hack one up; I just wanted to see if > someone had done it before. I'll check the list archive for sure. > In that case, an example from a fvwm2rc configuration should be useful for figuring out the FvwmButtons setting themselves; Adding the stock bit of wrapper code to make scwm run it is relatively simple, any example of running an fvwm module can serve as an example for that. I think there is an archive of fvwmrcs somewhere, but I forget hwere. > > [hoping I can squeeze out some time this weekend to grab the latest > guile and scwm snapshots and do some hacking] Cool. Hacking is good. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 15:06:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03019 for scwm-discuss-outgoing; Fri, 2 Oct 1998 15:06:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA03015 for ; Fri, 2 Oct 1998 15:06:11 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA21168; Fri, 2 Oct 98 15:05:40 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA28338; Fri, 2 Oct 1998 12:05:27 -0700 (PDT) To: Maciej Stachowiak Cc: Sam Falkner , scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... References: <199810021702.NAA01964@huis-clos.mit.edu> From: Greg Badros Date: 02 Oct 1998 12:05:27 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 02 Oct 1998 13:02:50 EDT" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Another note: someone, possibly me, should hack the window list menu > to have an option to show mini-icons for windows that have them. This > would provide a slightly better substitute for the Windows row of > icons thing. I did this a while back -- the show-mini-icon option to show-window-list-menu. Greg From owner-scwm-discuss@mit.edu Fri Oct 2 16:04:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03535 for scwm-discuss-outgoing; Fri, 2 Oct 1998 16:04:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03527; Fri, 2 Oct 1998 16:04:01 -0400 Message-Id: <199810022004.QAA03527@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Alt-TAB window switching.... In-reply-to: Your message of "02 Oct 1998 12:05:27 PDT." Date: Fri, 02 Oct 1998 16:04:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Another note: someone, possibly me, should hack the window list menu > > to have an option to show mini-icons for windows that have them. This > > would provide a slightly better substitute for the Windows row of > > icons thing. > > I did this a while back -- the show-mini-icon option to > show-window-list-menu. > Wow, every time I suggest something should get done lately, it turns out someone already did it. I love free software! - Maciej From owner-scwm-discuss@mit.edu Fri Oct 2 16:47:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03827 for scwm-discuss-outgoing; Fri, 2 Oct 1998 16:47:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA03824 for ; Fri, 2 Oct 1998 16:47:40 -0400 Received: from md49-021.mun.compuserve.com by MIT.EDU with SMTP id AA11812; Fri, 2 Oct 98 16:47:10 EDT Received: (from forcer@localhost) by forcix.roof.lan (8.9.1/8.9.1) id VAA09700 for scwm-discuss@mit.edu; Fri, 2 Oct 1998 21:50:20 +0200 Message-Id: <19981002215019.A9570@forcix.roof.lan> Date: Fri, 2 Oct 1998 21:50:19 +0200 From: forcer To: scwm-discuss@mit.edu Subject: bug in shadeing Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Operating-System: Linux forcix 2.0.36 X-Url: http://webserver.de/forcer/ Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi there. I've recently found a bug in scwm which manifests itself when a window resizes while being shaded. The window changes the size horizontally, but not vertically. That is, when it's being unshaded, only the original height gets displayed. This changes as soon as it's being resized any other way - it pops back to the "real" size. The little tcl/tk script i used to test this was button .b -width 12 -height 12 -text start -command { after 4000 .b configure -width 24 -height 24 } pack .b Just press the button and shade the window, when the title bar changes horizontal size unshade it and see the problem :) (this was tested on Guile 1.3a (recent snapshot) and SCWM as follows: Scwm Version post0.8a compiled on Oct 2 1998 at 21:30:28 RCS_ID=$Id: scwm.c,v 1.137 1998/10/01 08:16:17 jtl Exp $ Repository Timestamp: Thu Oct 1 19:16:57 EDT 1998 -- $Revision: 1.545 $) And as a side not... can someone *please* exclude numlock from the keys that affect key events? or at least tell me how to do that? :) Keep up the good work, -forcer -- /* Isn't "Microsoft Works" an advertisement lie? */ /* email: forcer@mindless.com -><- www: http://webserver.de/forcer/ */ /* IRC: forcer@#StarWars (IRCnet) -><- PGP/GPG: available on my website */ From owner-scwm-discuss@mit.edu Fri Oct 2 20:44:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05098 for scwm-discuss-outgoing; Fri, 2 Oct 1998 20:44:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05095 for ; Fri, 2 Oct 1998 20:44:46 -0400 Received: from smtp7.nwnexus.com by MIT.EDU with SMTP id AA00478; Fri, 2 Oct 98 20:44:16 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp7.nwnexus.com (8.8.8/8.8.8) with ESMTP id RAA00813 for ; Fri, 2 Oct 1998 17:44:16 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-15622>; Fri, 2 Oct 1998 17:37:34 -0700 To: scwm-discuss@mit.edu Subject: Re: bug in shadeing In-Reply-To: forcer's message of "Fri, 02 Oct 1998 21:50:19 +0200." <19981002215019.A9570@forcix.roof.lan> Date: Fri, 02 Oct 1998 17:37:23 -0600 From: Ken Pizzini Message-Id: <19981003003734Z276516-15622+55@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <19981002215019.A9570@forcix.roof.lan>, wrote to scwm-discuss@mit.edu: > And as a side not... can someone *please* exclude numlock from the keys > that affect key events? or at least tell me how to do that? :) Here's what I'm doing, at least until the event rewrite happens: xmodmap \ -e 'remove lock = Caps_Lock' \ -e 'remove mod2 = Num_Lock' \ -e 'remove mod5 = Scroll_Lock' (A bit drastic, perhaps, but I find that the *Lock keys tend to cause me occasional grief, with no offseting benefit.) --Ken Pizzini From owner-scwm-discuss@mit.edu Sat Oct 3 02:28:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA06725 for scwm-discuss-outgoing; Sat, 3 Oct 1998 02:28:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA06722 for ; Sat, 3 Oct 1998 02:28:51 -0400 Received: from dns1.tc.net by MIT.EDU with SMTP id AA26538; Sat, 3 Oct 98 02:28:25 EDT Received: from [10.16.190.28] by dns1.tc.net for id CAA01980; Sat Oct 3 02:28:21 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id CAA13567; Sat, 3 Oct 1998 02:28:21 -0400 Subject: Progress on using FvwmButtons (and some questions) Date: 03 Oct 1998 02:28:20 -0400 Message-Id: Lines: 72 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: scwm-discuss@mit.edu From: Doug McNaught Sender: owner-scwm-discuss@mit.edu Precedence: bulk I grabbed the latest Guile and Scwm snapshots tonight. I have the FvwmButtons module partially working. Here is the relevant .scwmrc fragment: (register-fvwm2-module-config "FvwmButtons" "*FvwmButtonsBack grey76" "*FvwmButtonsFore black" "*FvwmButtonsGeometry 400x60-1-1" "*FvwmButtonsRows 1" "*FvwmButtons(Swallow XLoad 'Exec xload -nolabel -geometry 60x60+0+0 -bg grey76 -update 5')" "*FvwmButtons(4x1,Swallow \"FvwmPager\" \"FvwmPager 0 0\"" ) (define fvwm2-buttons (run-fvwm2-module "FvwmButtons")) With the help of a small patch to fvwm-eval.scm (on which more below), this fires up the module, which then calls back to Scwm to fire off Xload, which the module then swallows. This works great. What doesn't work is the last element, which is supposed to invoke and swallow the FvwmPager. The packet that comes from FvwmButtons to Scwm is '(0 13 "FvwmPager 0 0" 1)'. This works for Fvwm2, because its behavior when fed an unrecognized command is to try to execute it as a module. Scwm, however, looks up "FvwmPager" in fvwm-command-hash-table, doesn't find it, and returns failure. The cheesy way to fix this would be to define an "FvwmPager" command in fvwm-eval.scm and have it invoke the pager. The preferable way (IMHO) would be to emulate Fvwm and try to treat unknown commands as modules. In either case, though, it would involve calling run-fvwm2-module from fvwm-eval.scm, leading to a cross-dependency between that file and fvwm-module.scm . I have no idea whether or not this would be a Bad Thing--the Guile manual (such as it is) doesn't say anything about it, and it's a bit late in the evening to go grovelling though the Guile sources. Any ideas on this one? Oh, about the patch--I made the following fix to fvwm-eval.scm, because 'apply' was getting a string instead of a list as its second argument in the particular case I've generated. I only have anon cvs access so if it's acceptable, could someone apply it to the master sources? *** /home/doug/src/cvs/scwm/scheme/fvwm-eval.scm Fri Oct 2 22:22:00 1998 --- /usr/local/share/scwm-modules/app/scwm/fvwm-eval.scm Sat Oct 3 02:04:13 1998 *************** *** 141,147 **** (eval-string args)) (define-fvwm-command "Exec" ! (fvwm-exec (apply string-append args))) (define-fvwm-command "Restart" (restart)) --- 141,150 ---- (eval-string args)) (define-fvwm-command "Exec" ! (fvwm-exec ! (cond ! ((string? args) args) ! ((list? args) (apply string-append args))))) (define-fvwm-command "Restart" (restart)) -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Sat Oct 3 05:02:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA08594 for scwm-discuss-outgoing; Sat, 3 Oct 1998 05:02:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA08589; Sat, 3 Oct 1998 05:02:18 -0400 Message-Id: <199810030902.FAA08589@huis-clos.mit.edu> To: Doug McNaught cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "03 Oct 1998 02:28:20 EDT." Date: Sat, 03 Oct 1998 05:02:17 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk doug@tc.net writes: > I grabbed the latest Guile and Scwm snapshots tonight. I have the > FvwmButtons module partially working. Here is the relevant .scwmrc > fragment: > > (register-fvwm2-module-config "FvwmButtons" > "*FvwmButtonsBack grey76" > "*FvwmButtonsFore black" > "*FvwmButtonsGeometry 400x60-1-1" > "*FvwmButtonsRows 1" > "*FvwmButtons(Swallow XLoad 'Exec xload -nolabel > -geometry 60x60+0+0 -bg grey76 -update 5')" > "*FvwmButtons(4x1,Swallow \"FvwmPager\" \"FvwmPag > er 0 0\"" > ) > > (define fvwm2-buttons (run-fvwm2-module "FvwmButtons")) > > With the help of a small patch to fvwm-eval.scm (on which more below), > this fires up the module, which then calls back to Scwm to fire off > Xload, which the module then swallows. This works great. > Cool, I'm glad it works. > What doesn't work is the last element, which is supposed to invoke and > swallow the FvwmPager. The packet that comes from FvwmButtons to Scwm > is '(0 13 "FvwmPager 0 0" 1)'. This works for Fvwm2, because its > behavior when fed an unrecognized command is to try to execute it as a > module. Scwm, however, looks up "FvwmPager" in fvwm-command-hash-table, > doesn't find it, and returns failure. > Yeah, I've thought about this before, for full emulation purposes, but there are a few subtleties here. We don't have all the actual fvwm commands implemented yet, and we wouldn't want to fork a module search on those. If you want a cheesy workaround for now, you can use the following command from your Swallow directive: "Eval (run-fvwm2-module \"FvwmPager\" '(\"0\" \"0\")) (scwm supports the extra fvwm psuedo-command Eval for modules which lets you tell the module to run arbitrary Scheme code.) > The cheesy way to fix this would be to define an "FvwmPager" command > in fvwm-eval.scm and have it invoke the pager. The preferable way > (IMHO) would be to emulate Fvwm and try to treat unknown commands as > modules. In either case, though, it would involve calling > run-fvwm2-module from fvwm-eval.scm, leading to a cross-dependency > between that file and fvwm-module.scm . I have no idea whether or not > this would be a Bad Thing--the Guile manual (such as it is) doesn't > say anything about it, and it's a bit late in the evening to go > grovelling though the Guile sources. I think Guile allows modules to mutually use each other (I believe there are special cases in the module loading code for arbitrary circular dependecies in fact), but I have tried to avoid them as much as possible, since it seems kind of bad form. But there may be no other solution here. Certainly the fvwm command language and module facility are circularly dependent in fvwm2 itself. > > Any ideas on this one? > > Oh, about the patch--I made the following fix to fvwm-eval.scm, > because 'apply' was getting a string instead of a list as its second > argument in the particular case I've generated. I only have anon cvs > access so if it's acceptable, could someone apply it to the master > sources? > Now that I think about it more, I am pretty sure that args is always a single string, not a list. I will clean up this patch in the morning and apply it. Thanks for the bug report and the patch, as well as the discussion of fvwm modules launching each other (I hadn't realized there were any that wanted to do that). > *** /home/doug/src/cvs/scwm/scheme/fvwm-eval.scm Fri Oct 2 22:22:00 1 > 998 > --- /usr/local/share/scwm-modules/app/scwm/fvwm-eval.scm Sat Oct 3 02 > :04:13 1998 > *************** > *** 141,147 **** > (eval-string args)) > > (define-fvwm-command "Exec" > ! (fvwm-exec (apply string-append args))) > > (define-fvwm-command "Restart" > (restart)) > --- 141,150 ---- > (eval-string args)) > > (define-fvwm-command "Exec" > ! (fvwm-exec > ! (cond > ! ((string? args) args) > ! ((list? args) (apply string-append args))))) > > (define-fvwm-command "Restart" > (restart)) > Incidentally, would you mind sending unified diffs in the future (`diff -ub' is a good set of options)? Context diffs are certainly good enough though (if you don't have GNU diff on the system for instance). - Maciej From owner-scwm-discuss@mit.edu Sat Oct 3 12:22:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA10426 for scwm-discuss-outgoing; Sat, 3 Oct 1998 12:22:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA10423 for ; Sat, 3 Oct 1998 12:22:01 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA05071; Sat, 3 Oct 98 12:21:30 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA04338; Sat, 3 Oct 1998 09:21:24 -0700 (PDT) To: Maciej Stachowiak Cc: Doug McNaught , scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810030902.FAA08589@huis-clos.mit.edu> From: Greg Badros Date: 03 Oct 1998 09:21:23 -0700 In-Reply-To: Maciej Stachowiak's message of "Sat, 03 Oct 1998 05:02:17 EDT" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Incidentally, would you mind sending unified diffs in the future > (`diff -ub' is a good set of options)? Context diffs are certainly > good enough though (if you don't have GNU diff on the system for > instance). If you are using GNU diff, can I also suggest that people use -F'#define.FUNC_NAME' so that the function name is mentioned in the diff chunks (instead of a line of the comment docstring which starts in the zeroth column). In my .emacs, I use: (setq diff-switches '("-ub" "-F#define.FUNC_NAME")) ;; for scwm (setq cvs-diff-flags diff-switches) (BTW, if anyone knows of a way to trick diff into actually seeing the SCWM_PROC line instead of just the #define FUNC_NAME, I'd love to hear about it.) Thanks, Greg From owner-scwm-discuss@mit.edu Sat Oct 3 13:08:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA10670 for scwm-discuss-outgoing; Sat, 3 Oct 1998 13:08:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA10667 for ; Sat, 3 Oct 1998 13:08:35 -0400 Received: from dns1.tc.net by MIT.EDU with SMTP id AA10716; Sat, 3 Oct 98 13:08:04 EDT Received: from [10.16.190.28] by dns1.tc.net for id NAA17338; Sat Oct 3 13:08:01 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id NAA13878; Sat, 3 Oct 1998 13:08:00 -0400 Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810030902.FAA08589@huis-clos.mit.edu> Date: 03 Oct 1998 13:08:00 -0400 In-Reply-To: Maciej Stachowiak's message of "Sat, 03 Oct 1998 05:02:17 EDT" Message-Id: Lines: 55 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: scwm-discuss@mit.edu From: Doug McNaught Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > What doesn't work is the last element, which is supposed to invoke and > > swallow the FvwmPager. The packet that comes from FvwmButtons to Scwm > > is '(0 13 "FvwmPager 0 0" 1)'. This works for Fvwm2, because its > > behavior when fed an unrecognized command is to try to execute it as a > > module. Scwm, however, looks up "FvwmPager" in fvwm-command-hash-table, > > doesn't find it, and returns failure. > > > > Yeah, I've thought about this before, for full emulation purposes, but > there are a few subtleties here. We don't have all the actual fvwm > commands implemented yet, and we wouldn't want to fork a module search > on those. > > If you want a cheesy workaround for now, you can use the following > command from your Swallow directive: > > "Eval (run-fvwm2-module \"FvwmPager\" '(\"0\" \"0\")) > > (scwm supports the extra fvwm psuedo-command Eval for modules which > lets you tell the module to run arbitrary Scheme code.) OK. I will give this a try. > Now that I think about it more, I am pretty sure that args is always a > single string, not a list. I will clean up this patch in the morning > and apply it. Thanks for the bug report and the patch, as well as the > discussion of fvwm modules launching each other (I hadn't realized > there were any that wanted to do that). Yeah, it's kind of screwy. I've been using the FwvmButtons module (called GoodStuff in fvwm1) for a while and I like it, so it's nice to get it working in scwm. > Incidentally, would you mind sending unified diffs in the future > (`diff -ub' is a good set of options)? Context diffs are certainly > good enough though (if you don't have GNU diff on the system for > instance). Not a problem. I'm running Linux so everything is GNU ;) BTW, many kudos to everybody who's been working on scwm. The CVS version I'm running now is much stabler than 0.8a, which would crash a lot when running decor stuff and sometimes completely failed to restart. I love this window manager--the first time I fired up scwmrepl and used it to change my window border widths on the fly, I was totally hooked. After I bang on it for a few more days I'll probably move to it at work as well. -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Sat Oct 3 14:13:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA10970 for scwm-discuss-outgoing; Sat, 3 Oct 1998 14:13:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA10967 for ; Sat, 3 Oct 1998 14:13:37 -0400 Received: from dns1.tc.net by MIT.EDU with SMTP id AA18522; Sat, 3 Oct 98 14:13:05 EDT Received: from [10.16.190.28] by dns1.tc.net for id OAA18948; Sat Oct 3 14:13:02 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id OAA13916; Sat, 3 Oct 1998 14:13:01 -0400 Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810030902.FAA08589@huis-clos.mit.edu> Date: 03 Oct 1998 14:13:01 -0400 In-Reply-To: Doug McNaught's message of "03 Oct 1998 13:08:00 -0400" Message-Id: Lines: 37 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: scwm-discuss@mit.edu From: Doug McNaught Sender: owner-scwm-discuss@mit.edu Precedence: bulk Following up to my own post... Doug McNaught writes: > Maciej Stachowiak writes: > > > If you want a cheesy workaround for now, you can use the following > > command from your Swallow directive: > > > > "Eval (run-fvwm2-module \"FvwmPager\" '(\"0\" \"0\")) > > > > (scwm supports the extra fvwm psuedo-command Eval for modules which > > lets you tell the module to run arbitrary Scheme code.) > > OK. I will give this a try. Your idea above worked fine, but I had to mess with the quoting. The quoted-string handling in fvwm (and its modules) is broken--it doesn't deal properly with backslash-escaping, so I ended up feeding register-fvwm2-module-config the following really gross hairball: "*FvwmButtons(4x1,Swallow \"Desk 0\" 'Eval (run-fvwm2-module \"FvwmPager\" (quote (\"0\" \"0\")))')" Thanks be to the Lisp gods for the original (quote foo) syntax, because FvwmButtons wouldn't accept an escaped single quote in that string; using all double quotes failed because fvwm doesn't treat \\ as an escaped single backslash. Just goes to show the value of Guile--when people invent toy extension languages for their software, they're almost always annoyingly limited. -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Sat Oct 3 17:28:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12074 for scwm-discuss-outgoing; Sat, 3 Oct 1998 17:28:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12069; Sat, 3 Oct 1998 17:28:35 -0400 Message-Id: <199810032128.RAA12069@huis-clos.mit.edu> To: Doug McNaught cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "03 Oct 1998 13:08:00 EDT." Date: Sat, 03 Oct 1998 17:28:34 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk doug@tc.net writes: > Maciej Stachowiak writes: > > > > > Incidentally, would you mind sending unified diffs in the future > > (`diff -ub' is a good set of options)? Context diffs are certainly > > good enough though (if you don't have GNU diff on the system for > > instance). > > Not a problem. I'm running Linux so everything is GNU ;) > Well, I have to use Slowlaris at work now, and the incompetent sysadmin has apparently not installed the full suite of GNU tools anywhere. So I know that poor souls forced to live with vendor `diff' exist. > BTW, many kudos to everybody who's been working on scwm. The CVS > version I'm running now is much stabler than 0.8a, which would crash a > lot when running decor stuff and sometimes completely failed to > restart. Well, it's good that things have stabilized, but bad that they weren't stable already in the release. I am hoping that after Guile 1.3 comes out, we can have a rock-solid 0.9 release. > I love this window manager--the first time I fired up > scwmrepl and used it to change my window border widths on the fly, I > was totally hooked. After I bang on it for a few more days I'll > probably move to it at work as well. > Cool. Wanna submit a review to http://www.x11.org/wm/scwm/ perhaps? I really need to submit some changes for the general text there though, I think they miss the point a bit, i.e. the difference between mere configurability and actual extensibility/programmability. - Maciej From owner-scwm-discuss@mit.edu Sat Oct 3 17:47:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA12266 for scwm-discuss-outgoing; Sat, 3 Oct 1998 17:47:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA12263 for ; Sat, 3 Oct 1998 17:47:04 -0400 Received: from raspberry.duff.org by MIT.EDU with SMTP id AA14393; Sat, 3 Oct 98 17:46:29 EDT Received: from localhost (danius@localhost) by raspberry.duff.org (8.9.0/8.9.0) with SMTP id WAA00760; Sat, 3 Oct 1998 22:46:21 +0100 Date: Sat, 3 Oct 1998 22:46:21 +0100 (BST) From: Danius Michaelides To: scwm-discuss@mit.edu Cc: doug@tc.net Subject: Re: Progress on using FvwmButtons (and some questions) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Doug McNaught writes: > > Maciej Stachowiak writes: > > > > > If you want a cheesy workaround for now, you can use the following > > > command from your Swallow directive: > > > > > > "Eval (run-fvwm2-module \"FvwmPager\" '(\"0\" \"0\")) > > > > > > (scwm supports the extra fvwm psuedo-command Eval for modules which > > > lets you tell the module to run arbitrary Scheme code.) > > > > OK. I will give this a try. > > Your idea above worked fine, but I had to mess with the quoting. The > quoted-string handling in fvwm (and its modules) is broken--it doesn't > deal properly with backslash-escaping, so I ended up feeding > register-fvwm2-module-config the following really gross hairball: > > "*FvwmButtons(4x1,Swallow \"Desk 0\" 'Eval (run-fvwm2-module \"FvwmPager\" (quote (\"0\" \"0\")))')" When I added the Eval function, I used it as follows: "*FvwmButtons(2x2,Swallow \"FvwmPager\" `Eval (run-fvwm-pager)` Frame 1)" (define (run-fvwm-pager) (run-fvwm2-module "FvwmPager" '("0" "0"))) which is perhaps a little more readable.. Also, as far as i recall, args should always be a string. Its been awhile since I've looked at this code, but the code i use has just (define-fvwm-command "Exec" (fvwm-exec args)) and not (define-fvwm-command "Exec" (fvwm-exec (apply string-append args))) Puzzling. Danius From owner-scwm-discuss@mit.edu Sat Oct 3 20:28:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA13037 for scwm-discuss-outgoing; Sat, 3 Oct 1998 20:28:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA13034 for ; Sat, 3 Oct 1998 20:28:30 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA04774; Sat, 3 Oct 98 20:27:47 EDT Received: (qmail 31626 invoked by uid 501); 4 Oct 1998 00:28:31 -0000 Message-Id: <19981003172830.A31567@molehill.org> Date: Sat, 3 Oct 1998 17:28:30 -0700 From: Todd Larason To: Maciej Stachowiak , Doug McNaught Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810032128.RAA12069@huis-clos.mit.edu>; from Maciej Stachowiak on Sat, Oct 03, 1998 at 05:28:34PM -0400 X-Tom-Swifty: "I have to insert this wooden spatula in your mouth", said Tom depressingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981003, Maciej Stachowiak wrote: > Well, it's good that things have stabilized, but bad that they weren't > stable already in the release. I am hoping that after Guile 1.3 comes > out, we can have a rock-solid 0.9 release. Right before leaving the office yesterday, scwm started crashing during the GC sweep cycle. I can't think of anything I changed that should have triggered new bugs, but I had done an cvs update earlire in the afternoon. I'll look for this as soon as I'm back in town (Sunday night). Right now, I'm trying to demonstrate scwm to a Mac user, with MI/X, over a poor modem connection, then ssh tunneling. Not a great debugging environment. Actually, it's not a great using environment, aside from the speed. There were many many errors on X_PutImage, similar to the ones when running in XNest. Can anything be done about the server size limits? From owner-scwm-discuss@mit.edu Sun Oct 4 07:01:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00217 for scwm-discuss-outgoing; Sun, 4 Oct 1998 07:01:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA00213 for ; Sun, 4 Oct 1998 07:01:14 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id MAA06111 for scwm-discuss@huis-clos.mit.edu; Sun, 4 Oct 1998 12:47:40 +0200 (MET DST) Received: (qmail 1391 invoked by uid 115); 3 Oct 1998 16:27:28 -0000 To: scwm-discuss@mit.edu Subject: Re: menu code References: <199809302107.RAA27189@huis-clos.mit.edu> <19981002023226.A23328@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Oct 1998 18:27:28 +0200 In-Reply-To: Todd Larason's message of "Fri, 2 Oct 1998 02:32:26 -0700" Message-ID: Lines: 27 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 2 Oct 1998 02:32:26 -0700 >>>>> Todd Larason said: Todd> I have a patch that will make the xpm menu support a loadable Todd> module, using the nice guile interface where (use-module (app Todd> scwm xpm)) loads and initializes the module. Tres cool. Todd> If we want this in 0.9, I can check it in, and start looking Todd> for other reasonable candidates. I think this should go in. If someone airs stability concerns[1], you may want to limit this to new or fringe features - OTOH the possible problems will only be postponed. Robbe [1] Which raises the question of which route we would like to take: should 0.9 directly predate 1.0, or should there be 0.10, 0.11, etc. between them. In other words: is 0.9 pre-stable feature-freeze material? -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Oct 4 07:00:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00207 for scwm-discuss-outgoing; Sun, 4 Oct 1998 07:00:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id HAA00204 for ; Sun, 4 Oct 1998 07:00:48 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id MAA06110 for scwm-discuss@huis-clos.mit.edu; Sun, 4 Oct 1998 12:47:38 +0200 (MET DST) Received: (qmail 1382 invoked by uid 115); 3 Oct 1998 16:21:38 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm - numlock fix References: <199810020723.DAA30189@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Oct 1998 18:21:37 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 02 Oct 1998 03:23:24 EDT" Message-ID: Lines: 21 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 02 Oct 1998 03:23:24 EDT >>>>> Maciej Stachowiak said: Maciej> memph@ns.sympatico.ca writes: >> hello, when numlock is on the mouse does not work correctly [...] Maciej> Ugh, I hate when X does silly things like that. This is not so silly. scwm just does not care about mouse events with the numlock modifier bit on. Nobody told it to `bind-mouse' to "Numlock-Button1" after all (this is AFAIK not even possible yet). I think this is another one from the "hopfully fixed after the events rewrite" category. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Oct 4 07:09:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00384 for scwm-discuss-outgoing; Sun, 4 Oct 1998 07:09:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00378; Sun, 4 Oct 1998 07:09:47 -0400 Message-Id: <199810041109.HAA00378@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: menu code In-reply-to: Your message of "03 Oct 1998 18:27:28 +0200." Date: Sun, 04 Oct 1998 07:09:47 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > [1] Which raises the question of which route we would like to take: > should 0.9 directly predate 1.0, or should there be 0.10, 0.11, etc. > between them. In other words: is 0.9 pre-stable feature-freeze material? > I don't think 0.9 should be followed by 1.0. We have at least one big rewrite that definitely needs ot happen before 1.0, namely the event model stuff. We could either continue with 0.10, 0.11, etc, or go to 0.9.x, although that may also give a misleading picture of the stability of the interfaces. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 4 07:12:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00468 for scwm-discuss-outgoing; Sun, 4 Oct 1998 07:12:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA00463; Sun, 4 Oct 1998 07:12:18 -0400 Message-Id: <199810041112.HAA00463@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: scwm - numlock fix In-reply-to: Your message of "03 Oct 1998 18:21:37 +0200." Date: Sun, 04 Oct 1998 07:12:18 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Fri, 02 Oct 1998 03:23:24 EDT > >>>>> Maciej Stachowiak said: > > Maciej> memph@ns.sympatico.ca writes: > >> hello, when numlock is on the mouse does not work correctly [...] > > Maciej> Ugh, I hate when X does silly things like that. > > This is not so silly. scwm just does not care about mouse events with > the numlock modifier bit on. Nobody told it to `bind-mouse' to > "Numlock-Button1" after all (this is AFAIK not even possible yet). > I think this is another one from the "hopfully fixed after the events > rewrite" category. > I know it makes sense in light of X's event selection rules and the fact that scwm is not terribly clever about them in this way. My point was that it's stupid in general for numlock to affect mouse events. NumLock is NumLock, it shouldn't be a general-purpose modifier. But the X designers clearly had a different thought on this. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 4 11:56:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA01649 for scwm-discuss-outgoing; Sun, 4 Oct 1998 11:56:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA01646 for ; Sun, 4 Oct 1998 11:56:42 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA09743; Sun, 4 Oct 98 11:55:53 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA26238; Sun, 4 Oct 1998 08:55:54 -0700 (PDT) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: menu code References: <199810041109.HAA00378@huis-clos.mit.edu> From: Greg Badros Date: 04 Oct 1998 08:55:53 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 04 Oct 1998 07:09:47 EDT" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > robbe@orcus.priv.at writes: > > > > [1] Which raises the question of which route we would like to take: > > should 0.9 directly predate 1.0, or should there be 0.10, 0.11, etc. > > between them. In other words: is 0.9 pre-stable feature-freeze material? > > > > I don't think 0.9 should be followed by 1.0. We have at least one big > rewrite that definitely needs ot happen before 1.0, namely the event > model stuff. We could either continue with 0.10, 0.11, etc, or go to > 0.9.x, although that may also give a misleading picture of the > stability of the interfaces. As long as we always used letters after the tenth digit before, I'd prefer .10, and .11 (but we need to document this reasonably well-- I, and probably others, find such a numbering convention a bit confusing). We definitely don't want to go to 1.0 after .9 -- the changes to be made are very destabilizing. Greg From owner-scwm-discuss@mit.edu Sun Oct 4 12:02:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01741 for scwm-discuss-outgoing; Sun, 4 Oct 1998 12:02:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01738 for ; Sun, 4 Oct 1998 12:02:27 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA10629; Sun, 4 Oct 98 12:01:38 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA27131; Sun, 4 Oct 1998 09:01:39 -0700 (PDT) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: scwm - numlock fix References: <199810041112.HAA00463@huis-clos.mit.edu> From: Greg Badros Date: 04 Oct 1998 09:01:39 -0700 In-Reply-To: Maciej Stachowiak's message of "Sun, 04 Oct 1998 07:12:18 EDT" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > This is not so silly. scwm just does not care about mouse events with > > the numlock modifier bit on. Nobody told it to `bind-mouse' to > > "Numlock-Button1" after all (this is AFAIK not even possible yet). > > I think this is another one from the "hopfully fixed after the events > > rewrite" category. > > > > I know it makes sense in light of X's event selection rules and the > fact that scwm is not terribly clever about them in this way. My point > was that it's stupid in general for numlock to affect mouse > events. NumLock is NumLock, it shouldn't be a general-purpose > modifier. But the X designers clearly had a different thought on this. Along the lines of other uses for the numlock key -- I used to just disable it completely (the keypad should just always be numbers, imo, if you've the separate grid of insert/delete and cursor movement keys), but now I make it a sticky C-S-M (my wm "doit" keystroke -- almost all of my keybindings require all three of these modifiers to be pressed to take effect, which makes them two handed interactions -- with the numlock doing this stickily, I can get by while eating a sub!). >From my .Xmodmap: ! Make Num_Lock do a sticky-toggle of C-S-M, my common window-mgr ops modifier remove Mod2 = Num_Lock add Mod1 = Num_Lock add Shift = Num_Lock add Control = Num_Lock Greg From owner-scwm-discuss@mit.edu Sun Oct 4 15:20:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA03111 for scwm-discuss-outgoing; Sun, 4 Oct 1998 15:20:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA03108 for ; Sun, 4 Oct 1998 15:20:34 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA15324 for scwm-discuss@huis-clos.mit.edu; Sun, 4 Oct 1998 21:07:10 +0200 (MET DST) Received: (qmail 6058 invoked by uid 115); 4 Oct 1998 15:15:27 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm - numlock fix References: <199810041112.HAA00463@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 04 Oct 1998 17:15:26 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 04 Oct 1998 07:12:18 EDT" Message-ID: Lines: 21 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 04 Oct 1998 07:12:18 EDT >>>>> Maciej Stachowiak said: Maciej> My point was that it's stupid in general for numlock to Maciej> affect mouse events. NumLock is NumLock, it shouldn't be a Maciej> general-purpose modifier. But the X designers clearly had a Maciej> different thought on this. If I understand it correctly, X window's key model essentially treats all keys as equals. You can bind NumLock to generate "N" if you wish. For you and others that think that NumLock is special, there's the "ServerNumLock" setting that does what you wish. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Oct 4 16:27:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03613 for scwm-discuss-outgoing; Sun, 4 Oct 1998 16:27:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03608; Sun, 4 Oct 1998 16:27:09 -0400 Message-Id: <199810042027.QAA03608@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: menu code In-reply-to: Your message of "04 Oct 1998 08:55:53 PDT." Date: Sun, 04 Oct 1998 16:27:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > > I don't think 0.9 should be followed by 1.0. We have at least one big > > rewrite that definitely needs ot happen before 1.0, namely the event > > model stuff. We could either continue with 0.10, 0.11, etc, or go to > > 0.9.x, although that may also give a misleading picture of the > > stability of the interfaces. > > As long as we always used letters after the tenth digit before, I'd > prefer .10, and .11 (but we need to document this reasonably well-- I, > and probably others, find such a numbering convention a bit confusing). > Well, I think after 1.0 we should switch to the well established convention of 1.0.x for stable releases, then 1.1.x for an unstable development series, etc. So we could do it a bit earlier. But we may as well just stick with 0.xx for now and just explain that 0.10 > 0.9. > We definitely don't want to go to 1.0 after .9 -- the changes to be made > are very destabilizing. > Yep. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 4 18:08:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04146 for scwm-discuss-outgoing; Sun, 4 Oct 1998 18:08:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04136; Sun, 4 Oct 1998 18:07:51 -0400 Message-Id: <199810042207.SAA04136@huis-clos.mit.edu> To: Lauri Alanko cc: scwm-discuss@mit.edu Subject: Re: Guile startup cleaned up a bit In-reply-to: Your message of "Sun, 04 Oct 1998 21:04:12 +0300." Date: Sun, 04 Oct 1998 18:07:50 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk lealanko@cc.helsinki.fi writes: > > > On Sat, 3 Oct 1998, Jim Blandy wrote: > > > ** The gh_enter function now takes care of loading the Guile startup files. > > gh_enter works by calling scm_boot_guile; see the remarks below. > > This is okay, since gh_ is supposed to be a "high level" interface anyway. > > > ** The function scm_boot_guile now takes care of loading the startup files. > > > > Since Guile cannot operate properly until boot-9.scm is loaded, there > > is no reason to separate loading boot-9.scm from Guile's other > > initialization processes. > > Except that it (currently) takes an eternity to load. Until the > initialization is blindingly fast, there should be an alternative of not > loading boot-9. For some stuff you just don't need a module system, > records or all that stuff. > > My personal opinion about this init stuff, btw, is that boot-9 should be > in C. Of course it would be preferable if it were compiled by hobbit or > something, but failing that, it should be translated by hand.. > The features in boot-9 need to be totally re-engineered, not just reqritten in C. The primary reason boot-9.scm is as ludicrously huge as it is, is due to the Scheme implementation of the module system, which one might call `idiosyncratic'. The vast majority of the stuff in there should live in separate modules but can't because it is used to implement the module system. Examples of this include defmacro, records, the read-line/read-delimited stuff (try-using-libtool-name uses it), the random posix stuff (a couple of those get used by module loading), other random file operations (same deal), and all 1072 lines of the module system itself. In any case, once Guile has a clean simple module system implemented in C, most of boot-9 will be able to move to separate modules or disappear entirely. Some things could possibly be taken out already, but it's hard to know without a comprehensive review. I do have interest in personally working on this area, as I find the slow guile startup time about the most annoying thing about scwm; but I don't think it would be wise to make changes to that effect so close to the planned release date for 1.3. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 5 05:15:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA08842 for scwm-discuss-outgoing; Mon, 5 Oct 1998 05:15:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA08836 for ; Mon, 5 Oct 1998 05:14:58 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA25679; Mon, 5 Oct 98 05:14:07 EDT Received: (qmail 19159 invoked by uid 501); 5 Oct 1998 09:14:08 -0000 Message-Id: <19981005021407.A19134@molehill.org> Date: Mon, 5 Oct 1998 02:14:07 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981003172830.A31567@molehill.org>; from Todd Larason on Sat, Oct 03, 1998 at 05:28:30PM -0700 X-Tom-Swifty: "The enemy has taken stronghold F", said Tom effortlessly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981003, Todd Larason wrote: > On 981003, Maciej Stachowiak wrote: > > Well, it's good that things have stabilized, but bad that they weren't > > stable already in the release. I am hoping that after Guile 1.3 comes > > out, we can have a rock-solid 0.9 release. > > Right before leaving the office yesterday, scwm started crashing during > the GC sweep cycle. I can't think of anything I changed that should > have triggered new bugs, but I had done an cvs update earlire in the > afternoon. It seems to be closure/hook related. When ;(add-hook! interactive-move-start-hook ; (lambda (w) ; (position-message-window-for-window w))) ;(add-hook! interactive-move-new-position-hook ; (lambda (w x y) ; (position-message-window-for-window w))) ;(add-hook! interactive-move-finish-hook ; (lambda (w) ; (position-message-window-default))) in my .scwmrc is uncommented, scwm crashes during/immediately after a move. (the rest of that code was posted a few days ago; I can repost if needed). Backing out the last callbacks.c change has no effect. This is at home, with a guile snapshot from October 2nd, but is presumably also the cause of the crashes at work, where I'm using a guile from early September. I commented out all my xpm menu references, and am running here a version where that's dynamically loaded, so that's presumably not it. (and the dynamic module code isn't being used at work, so that's not it either). The backtrace looks like: #0 __libc_free (mem=0x2974) at malloc.c:2859 #1 0x40113bed in scm_must_free (obj=0x2974
) at ../../libguile/gc.c:1496 #2 0x40113601 in scm_gc_sweep () at ../../libguile/gc.c:1195 #3 0x401126b8 in scm_igc (what=0x40147cda "inferior root continuation") at ../../libguile/gc.c:552 #4 0x40113a88 in scm_must_malloc (len=176, what=0x40147cda "inferior root continuation") at ../../libguile/gc.c:1432 #5 0x4012ff28 in scm_internal_cwdr (body=0x80598d8 , body_data=0xbfffd184, handler=0x80597f8 , handler_data=0x807a23f, stack_start=0xbfffd1b0) at ../../libguile/root.c:273 #6 0x8059928 in scm_internal_stack_cwdr (body=0x80598c4 , body_data=0xbfffd1b4, handler=0x80597f8 , handler_data=0x807a23f, stack_item=0xbfffd1b0) at ../../scwm/callbacks.c:126 #7 0x805995a in scwm_safe_apply (proc=1077095400, args=1076722864) at ../../scwm/callbacks.c:141 #8 0x8059a05 in scwm_safe_call3 (proc=1077095400, arg1=1077059000, arg2=4, arg3=138) at ../../scwm/callbacks.c:189 #9 0x8059d56 in call3_hooks (hook=1076837136, arg1=1077059000, arg2=4, arg3=138) at ../../scwm/callbacks.c:382 #10 0x8068df8 in moveLoop (psw=0x80e44c8, XOffset=-163, YOffset=-18, OutlineWidth=600, OutlineHeight=641, FinalX=0xbfffd2d0, FinalY=0xbfffd2cc, opaque_move=1) at ../../scwm/move.c:409 #11 0x806962e in InteractiveMove (psw=0x80e44c8, fOpaque=1, FinalX=0xbfffd2d0, FinalY=0xbfffd2cc) at ../../scwm/move.c:724 #12 0x8069708 in interactive_move (win=1077059000, opaque_p=9076) at ../../scwm/move.c:760 #13 0x401164bf in scm_gsubr_apply (args=1076845296) at ../../libguile/gsubr.c:145 #14 0x4010e0cf in scm_dapply (proc=1076625672, arg1=1076831560, args=1076845312) at ../../libguile/eval.c:2946 #15 0x4010d37f in scm_deval (x=10612, env=1076909912) at ../../libguile/eval.c:2433 #16 0x4010e2cd in scm_dapply (proc=1076924528, arg1=10612, args=1076970584) at ../../libguile/eval.c:3005 #17 0x40109b0c in scm_apply (proc=1076924528, arg1=10612, args=10612) at ../../libguile/eval.c:2827 #18 0x40115ac0 in gh_apply (proc=1076924528, args=10612) at ../../libguile/gh_funcs.c:144 #19 0x80598d4 in scwm_body_apply (body_data=0xbfffd744) at ../../scwm/callbacks.c:84 #20 0x40139739 in scm_internal_lazy_catch (tag=9076, body=0x80598c4 , body_data=0xbfffd744, handler=0x40139790 , handler_data=0x0) at ../../libguile/throw.c:328 #21 0x40139809 in cwss_body (data=0xbfffd5c4) at ../../libguile/throw.c:363 #22 0x401395a0 in scm_internal_catch (tag=9076, body=0x401397e0 , body_data=0xbfffd5c4, handler=0x80597f8 , handler_data=0x0) at ../../libguile/throw.c:236 #23 0x4013984c in scm_internal_stack_catch (tag=9076, body=0x80598c4 , body_data=0xbfffd744, handler=0x80597f8 , handler_data=0x0) at ../../libguile/throw.c:377 #24 0x80598f0 in cwssdr_body (data=0xbfffd714) at ../../scwm/callbacks.c:110 #25 0x401395a0 in scm_internal_catch (tag=9076, body=0x80598d8 , body_data=0xbfffd714, handler=0x4012fea8 , handler_data=0xbfffd6ec) at ../../libguile/throw.c:236 #26 0x4013000c in scm_internal_cwdr (body=0x80598d8 , body_data=0xbfffd714, handler=0x80597f8 , handler_data=0x807a23f, stack_start=0xbfffd740) at ../../libguile/root.c:300 #27 0x8059928 in scm_internal_stack_cwdr (body=0x80598c4 , body_data=0xbfffd744, handler=0x80597f8 , handler_data=0x807a23f, stack_item=0xbfffd740) at ../../scwm/callbacks.c:126 #28 0x805995a in scwm_safe_apply (proc=1076924528, args=10612) at ../../scwm/callbacks.c:141 #29 0x805999c in scwm_safe_call0 (thunk=1076924528) at ../../scwm/callbacks.c:164 #30 0x805fd4b in HandleButtonPress () at ../../scwm/events.c:1253 #31 0x805e561 in DispatchEvent () at ../../scwm/events.c:194 #32 0x805e592 in HandleEvents () at ../../scwm/events.c:216 #33 0x806cd59 in scwm_main (argc=3, argv=0xbfffdc98) at ../../scwm/scwm.c:960 #34 0x806c245 in scwm_gh_launch_pad (closure=0x806c27c, argc=3, argv=0xbfffdc98) at ../../scwm/scwm.c:433 #35 0x40117ce4 in invoke_main_func (body_data=0xbfffdc44) at ../../libguile/init.c:505 #36 0x401395a0 in scm_internal_catch (tag=9076, body=0x40117cc4 , body_data=0xbfffdc44, handler=0x40139a00 , handler_data=0x0) at ../../libguile/throw.c:236 #37 0x40117c9b in scm_boot_guile_1 (base=0xbfffdc40, closure=0xbfffdc44) at ../../libguile/init.c:481 #38 0x40117a51 in scm_boot_guile (argc=3, argv=0xbfffdc98, main_func=0x806c228 , closure=0x806c27c) at ../../libguile/init.c:346 #39 0x806c262 in scwm_gh_enter (argc=3, argv=0xbfffdc98, c_main_prog=0x806c27c ) at ../../scwm/scwm.c:440 #40 0x806c277 in main (argc=3, argv=0xbfffdc98) at ../../scwm/scwm.c:452 I'd been using this move hook configuration for a few days with no problems. Any ideas what might have changed since, say, Wednesday, to do this? From owner-scwm-discuss@mit.edu Mon Oct 5 11:18:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA10432 for scwm-discuss-outgoing; Mon, 5 Oct 1998 11:18:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA10429 for ; Mon, 5 Oct 1998 11:18:06 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA08582; Mon, 5 Oct 98 11:17:14 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA01111; Mon, 5 Oct 1998 08:17:05 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> From: Greg Badros Date: 05 Oct 1998 08:17:05 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 02:14:07 -0700" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I'd been using this move hook configuration for a few days with no > problems. Any ideas what might have changed since, say, Wednesday, to > do this? In case you're not aware of this option, you know you can do: cvs diff -D "9/30/98 12:00 GMT" to answer exactly the first part of your question (what has changed). The second part of the question is harder-- I'll have to try to reproduce the crash before I can investigate it. A couple of notes: o be sure you have everything checked in (cvs update -n) so that it's not some change that you've not committed to the repository that's causing problems (otherwise, others will be chasing down a bug that isn't in the code you're looking at). I don't think this is the problem, but it's the first thing I double check. o Scwm has latent GC-related bugs. A while back I went through all the code and caught a bunch of them, but I can't imagine that there are none left. What this means is that a completely unrelated change can cause a GC to occur earlier or later than it used to and Scwm isn't in a state that is safe for collecting. This is especially true for the initialization code, but very well could be an issue later. Greg From owner-scwm-discuss@mit.edu Mon Oct 5 11:25:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA10494 for scwm-discuss-outgoing; Mon, 5 Oct 1998 11:25:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA10491 for ; Mon, 5 Oct 1998 11:25:44 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA09535; Mon, 5 Oct 98 11:24:44 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA01114; Mon, 5 Oct 1998 08:24:45 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> From: Greg Badros Date: 05 Oct 1998 08:24:44 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 02:14:07 -0700" Message-Id: Lines: 34 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981003, Todd Larason wrote: > > On 981003, Maciej Stachowiak wrote: > > > Well, it's good that things have stabilized, but bad that they weren't > > > stable already in the release. I am hoping that after Guile 1.3 comes > > > out, we can have a rock-solid 0.9 release. > > > > Right before leaving the office yesterday, scwm started crashing during > > the GC sweep cycle. I can't think of anything I changed that should > > have triggered new bugs, but I had done an cvs update earlire in the > > afternoon. > > It seems to be closure/hook related. When > ;(add-hook! interactive-move-start-hook > ; (lambda (w) > ; (position-message-window-for-window w))) > ;(add-hook! interactive-move-new-position-hook > ; (lambda (w x y) > ; (position-message-window-for-window w))) > ;(add-hook! interactive-move-finish-hook > ; (lambda (w) > ; (position-message-window-default))) > in my .scwmrc is uncommented, scwm crashes during/immediately after a > move. (the rest of that code was posted a few days ago; I can repost > if needed). Backing out the last callbacks.c change has no effect. Do we need to protect the hook objects, perhaps? Or does scm_sysintern take care of marking the objects attached to a hook? (Todd, does the crash go away if you define real functions and use them instead of the lambdas?) Greg From owner-scwm-discuss@mit.edu Mon Oct 5 17:48:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13448 for scwm-discuss-outgoing; Mon, 5 Oct 1998 17:48:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA13442; Mon, 5 Oct 1998 17:48:18 -0400 Message-Id: <199810052148.RAA13442@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "05 Oct 1998 08:24:44 PDT." Date: Mon, 05 Oct 1998 17:48:18 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > Do we need to protect the hook objects, perhaps? Or does scm_sysintern > take care of marking the objects attached to a hook? > The hooks are in a list bound to a variable; variables are GC-protected. SCM_SYSINTERN basically has the same effect as `define'ing a symbol with the given name to the given value. I will see if I can reproduce this crash myself, and if so, investigate. I've been digging up a lot of odd bugs lately. For instance, can anyone else successfully run the Scheme-version doc extractor with recent Guile snapshots without getting a segfault? It keeps dumping core on me in really strange places. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 5 18:00:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13575 for scwm-discuss-outgoing; Mon, 5 Oct 1998 18:00:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA13572 for ; Mon, 5 Oct 1998 18:00:51 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA08081; Mon, 5 Oct 98 17:59:47 EDT Received: (qmail 21931 invoked by uid 501); 5 Oct 1998 22:00:18 -0000 Message-Id: <19981005150018.A21837@molehill.org> Date: Mon, 5 Oct 1998 15:00:18 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Mon, Oct 05, 1998 at 08:24:44AM -0700 X-Tom-Swifty: "I always pray to St. Ignatius", said Tom loyally. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981005, Greg Badros wrote: > Do we need to protect the hook objects, perhaps? Or does scm_sysintern > take care of marking the objects attached to a hook? I don't see why we would; If I'm reading the hook functions right, hooks are just lists of functions. scm_sysintern should protect the hook itself, and the hook should protect all the contents, no? Plus that, using a named function instead of a lambda doesn't make the crash go away. I'm at work now, and have verified that the crashes are the same, and in my install here I'm not using any unchecked-in code, and have an old and trusted guile. Looking over the changes over the past week now... From owner-scwm-discuss@mit.edu Mon Oct 5 18:03:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13631 for scwm-discuss-outgoing; Mon, 5 Oct 1998 18:03:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13625; Mon, 5 Oct 1998 18:03:27 -0400 Message-Id: <199810052203.SAA13625@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: gh interface needs for Scwm In-reply-to: Your message of "05 Oct 1998 08:44:11 PDT." Date: Mon, 05 Oct 1998 18:03:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > Depending on across what subset of Scheme implementation the gh_ > interface is meant to be portable, some of the GC calls could be > usefully exposed (there is a lot of similarity among GC algorithms). > If you just consider Stop and Copy vs. Mark and Sweep and Conservative vs. Non-Conservative, you get very different expectations of what C wants to do. Actually, I think the idea of a truly portable gh_ interface may be hopeless just due to GC; Guile programs can assume that it's safe to keep SCM objects on the C stack without protecting them, while for the vast majority of Scheme implementations this is not true. Maybe guile could add a gh_protect_stack_object macro which, for guile, expands to an empty statement. Then protecting heap objects would be an interesting thing to consider making portable, although in general, you'd need to pass a pointer to the SCM object rather than the SCM itself, because Stop and Copy would need to alter pointers. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 5 18:04:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA13679 for scwm-discuss-outgoing; Mon, 5 Oct 1998 18:04:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA13675 for ; Mon, 5 Oct 1998 18:04:23 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA09120; Mon, 5 Oct 98 18:03:19 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA21940; Mon, 5 Oct 1998 15:03:19 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> From: Greg Badros Date: 05 Oct 1998 15:03:19 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 15:00:18 -0700" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I don't see why we would; If I'm reading the hook functions right, > hooks are just lists of functions. scm_sysintern should protect the > hook itself, and the hook should protect all the contents, no? Yep. Reaching at straws, in retrospect. > Plus that, using a named function instead of a lambda doesn't make the > crash go away. Always nice to double check. > I'm at work now, and have verified that the crashes are the same, and > in my install here I'm not using any unchecked-in code, and have an > old and trusted guile. Looking over the changes over the past week > now... Good.... Greg From owner-scwm-discuss@mit.edu Mon Oct 5 18:53:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA14388 for scwm-discuss-outgoing; Mon, 5 Oct 1998 18:53:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA14385 for ; Mon, 5 Oct 1998 18:53:41 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22454; Mon, 5 Oct 98 18:52:36 EDT Received: (qmail 22220 invoked by uid 501); 5 Oct 1998 22:53:10 -0000 Message-Id: <19981005155309.A22149@molehill.org> Date: Mon, 5 Oct 1998 15:53:09 -0700 From: Todd Larason To: Greg Badros , maciej@molehill.org Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Mon, Oct 05, 1998 at 03:03:19PM -0700 X-Tom-Swifty: "I flunked this lousy exam", said Tom testily. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981005, Greg Badros wrote: > Todd Larason writes: > > Looking over the changes over the past week > > now... > > Good.... The only changes I'm seeing that look at all fishy GC-wise are my menu changes (me culpa). I'm comparing the GC handling for Scr.menu_look with Scr.menu_font, and finding something I don't understand. In set-menu-font! (font.c:345), the font is added to a protected_fonts vector, which is a permanent object (font.c:397). I don't understand why this is needed though, since mark_screen marks the menu_font, and Scr is protected (scwm.c:355). Are both of these protection methods needed? (as an aside, is the only difference between protected objects and permanent objects that scm_unprotect_object() will undo protection, but not permanence?) From owner-scwm-discuss@mit.edu Mon Oct 5 19:06:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA14519 for scwm-discuss-outgoing; Mon, 5 Oct 1998 19:06:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA14514 for ; Mon, 5 Oct 1998 19:06:41 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA24981; Mon, 5 Oct 98 19:05:35 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA24151; Mon, 5 Oct 1998 16:05:34 -0700 (PDT) To: Todd Larason Cc: maciej@molehill.org, scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> <19981005155309.A22149@molehill.org> From: Greg Badros Date: 05 Oct 1998 16:05:34 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 15:53:09 -0700" Message-Id: Lines: 37 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981005, Greg Badros wrote: > > Todd Larason writes: > > > Looking over the changes over the past week > > > now... > > > > Good.... > > The only changes I'm seeing that look at all fishy GC-wise are my menu > changes (me culpa). I'm comparing the GC handling for Scr.menu_look > with Scr.menu_font, and finding something I don't understand. > > In set-menu-font! (font.c:345), the font is added to a protected_fonts > vector, which is a permanent object (font.c:397). I don't understand > why this is needed though, since mark_screen marks the menu_font, and > Scr is protected (scwm.c:355). Are both of these protection methods > needed? Doesn't seem so, no. (Note that this is only because the scmScreen object gets marked always because of the scm_protect_object in scwm.c). > (as an aside, is the only difference between protected objects and > permanent objects that scm_unprotect_object() will undo protection, > but not permanence?) I think so, if memory serves. (Maciej?). scm_protect_object adds the object to a list of protected objects that the GC will always mark. scm_permanent_objects adds it to a separate but analogous list of permanent objects that the GC will also always mark. scm_unprotect_object removes an object from the first list. Actually, s/\blist\b/hash/g in the above paragraph, as I think one scm_unprotect_object is (unfortunately, IMO) enough to unprotect a previously protected object. Greg From owner-scwm-discuss@mit.edu Mon Oct 5 22:06:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA15642 for scwm-discuss-outgoing; Mon, 5 Oct 1998 22:06:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA15627 for ; Mon, 5 Oct 1998 22:06:24 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA10226; Mon, 5 Oct 98 22:05:19 EDT Received: (qmail 23227 invoked by uid 501); 6 Oct 1998 02:05:50 -0000 Message-Id: <19981005190549.A23185@molehill.org> Date: Mon, 5 Oct 1998 19:05:49 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981005150018.A21837@molehill.org>; from Todd Larason on Mon, Oct 05, 1998 at 03:00:18PM -0700 X-Tom-Swifty: "What ample bosoms those chorus girls have!" remarked Tom robustly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981005, Todd Larason wrote: > Looking over the changes over the past week > now... Got it, using the embarassingly brute-force method of bisecting patches. A call to the interactive-move-new-position-hook was being made with C ints instead of SCM ints. From owner-scwm-discuss@mit.edu Mon Oct 5 22:25:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA15923 for scwm-discuss-outgoing; Mon, 5 Oct 1998 22:25:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA15910; Mon, 5 Oct 1998 22:24:44 -0400 Message-Id: <199810060224.WAA15910@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "Mon, 05 Oct 1998 15:53:09 PDT." <19981005155309.A22149@molehill.org> Date: Mon, 05 Oct 1998 22:24:34 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981005, Greg Badros wrote: > > Todd Larason writes: > > > Looking over the changes over the past week > > > now... > > Sorry if you already said so and I just missed it, but have you tried again with last week's code in the same environment? I know it _should_ be redundant, but I've discovered Heisenbugs in my environment this way on occasion. > > Good.... > > The only changes I'm seeing that look at all fishy GC-wise are my menu > changes (me culpa). It's not _necessarily_ a GC problem. But I have to admit that given past history, GC is a likely culprit for mysterious problems. > I'm comparing the GC handling for Scr.menu_look > with Scr.menu_font, and finding something I don't understand. > > In set-menu-font! (font.c:345), the font is added to a protected_fonts > vector, which is a permanent object (font.c:397). I don't understand > why this is needed though, since mark_screen marks the menu_font, and > Scr is protected (scwm.c:355). Are both of these protection methods > needed? > No. Originally, font.c (and color.c) went through some gyrations to protect fonts and colors that were used for global parameters, because they were not GC protected in any way. However, in parallel, the GC-protected screen object changes happened and this now-redundant protection didn't get undone. > (as an aside, is the only difference between protected objects and > permanent objects that scm_unprotect_object() will undo protection, > but not permanence?) Functionally speaking, yes. Implementation-wise, they are also stored in separate lists. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 5 23:34:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA16494 for scwm-discuss-outgoing; Mon, 5 Oct 1998 23:34:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA16491 for ; Mon, 5 Oct 1998 23:34:13 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA27428; Mon, 5 Oct 98 23:33:16 EDT Received: (qmail 23579 invoked by uid 501); 6 Oct 1998 03:33:45 -0000 Message-Id: <19981005203344.A23553@molehill.org> Date: Mon, 5 Oct 1998 20:33:45 -0700 From: Todd Larason To: scwm-discuss list Subject: mailing list archives Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I know how to communicate sequential processes", said the whore guardedly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk http://huis-clos.mit.edu/scwm-archives.html's heading mispells 'Mailing'. The perl5 porters archives are easier to use; they're searchable, viewable by thread or by date, and the browsing pages are split up and shorter. They're using MHonarc and glimpseHTTP. The look and feel are close enough to make me think that hypermail and mhonarc are the same package, renamed. More information is at http://www.xray.mpe.mpg.de/mailing-lists/more-about.html From owner-scwm-discuss@mit.edu Mon Oct 5 23:35:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA16520 for scwm-discuss-outgoing; Mon, 5 Oct 1998 23:35:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA16517 for ; Mon, 5 Oct 1998 23:35:27 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA19661; Mon, 5 Oct 98 23:34:18 EDT Received: (qmail 23599 invoked by uid 501); 6 Oct 1998 03:35:00 -0000 Message-Id: <19981005203500.A23582@molehill.org> Date: Mon, 5 Oct 1998 20:35:00 -0700 From: Todd Larason To: scwm-discuss list Subject: guile-gtk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Have some shampoo", was Tom's unconditional offer. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I seem to recall Maciej posting an almost-working example of using guile-gtk with scwm, but it doesn't look like I saved it, and can't find it in the archives. If someone has it handy, I'd appreciate seeing it. From owner-scwm-discuss@mit.edu Tue Oct 6 00:03:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA16770 for scwm-discuss-outgoing; Tue, 6 Oct 1998 00:03:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA16766 for ; Tue, 6 Oct 1998 00:03:12 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA03344; Tue, 6 Oct 98 00:02:14 EDT Received: (qmail 23703 invoked by uid 501); 6 Oct 1998 04:02:47 -0000 Message-Id: <19981005210246.A23672@molehill.org> Date: Mon, 5 Oct 1998 21:02:46 -0700 From: Todd Larason To: scwm-discuss list Subject: menu interface cleanup/changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I don't think I'll have the pickled fish today", said Tom unerringly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk How important is it to keep primitive interfaces easy to use? The make-menu interface goes to great effort to allow defaults to be used, which leads to many many primitives to set all the defaults, then scheme wrappers around some of those primitives to keep them convenient. If make-menu is allowed to be harder to use, Scr.menu_font, Scr.menu_look and the primtives for getting and setting them can disappear. Scr.menu_color and the like can be renamed (tentatively proposing Scr.not_menu_color, an intentionally awful name, to encourage further cleanup), the primitives to set them can be cleaned up some, and the wrappers in base.scm can go away. base.scm's (menu) and the menu test files are the only things using make-menu, and I've incompatibly broken the interface before without people griping. From owner-scwm-discuss@mit.edu Tue Oct 6 01:22:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17322 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:22:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17319 for ; Tue, 6 Oct 1998 01:22:45 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA16523; Tue, 6 Oct 98 01:21:48 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA10137; Mon, 5 Oct 1998 22:21:38 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> <19981005190549.A23185@molehill.org> From: Greg Badros Date: 05 Oct 1998 22:21:38 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 19:05:49 -0700" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981005, Todd Larason wrote: > > Looking over the changes over the past week > > now... > > Got it, using the embarassingly brute-force method of bisecting patches. > > A call to the interactive-move-new-position-hook was being made with > C ints instead of SCM ints. So now the question is: how could this bug have been caught through language, infrastructure or conventional means. I.e., what failing of C, the compiler, or us caused us to write the buggy code that was not caught, and not so obviously wrong to be easy to spot. Glad you found it! Greg From owner-scwm-discuss@mit.edu Tue Oct 6 01:20:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17311 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:20:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17294; Tue, 6 Oct 1998 01:20:09 -0400 Message-Id: <199810060520.BAA17294@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: mailing list archives In-reply-to: Your message of "Mon, 05 Oct 1998 20:33:45 PDT." <19981005203344.A23553@molehill.org> Date: Tue, 06 Oct 1998 01:19:59 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > http://huis-clos.mit.edu/scwm-archives.html's heading mispells 'Mailing'. > > The perl5 porters archives are easier to use; they're searchable, > viewable by thread or by date, and the browsing pages are split up and > shorter. They're using MHonarc and glimpseHTTP. > > The look and feel > are close enough to make me think that hypermail and mhonarc are the > same package, renamed. > Actually, I think MHonarc is a free software clone of Hypermail (which has a non-commercial use license). > More information is at > http://www.xray.mpe.mpg.de/mailing-lists/more-about.html I'll save this message and look at upgrading soon. I still need to finish setting up GNATS, I'd like to have that ready to go before the next release. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 01:25:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17369 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:25:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17366 for ; Tue, 6 Oct 1998 01:25:40 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA06885; Tue, 6 Oct 98 01:24:33 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA10140; Mon, 5 Oct 1998 22:24:34 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: guile-gtk References: <19981005203500.A23582@molehill.org> From: Greg Badros Date: 05 Oct 1998 22:24:33 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 20:35:00 -0700" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I seem to recall Maciej posting an almost-working example of using > guile-gtk with scwm, but it doesn't look like I saved it, and can't > find it in the archives. If someone has it handy, I'd appreciate > seeing it. You do. See scwm/scheme/tests/scwm-gtk.scm. I try to put all useful snippets in the repository so that people poking around can run into interesting stuff to play with, debug, and extend. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 01:26:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17382 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:26:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17379 for ; Tue, 6 Oct 1998 01:26:14 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA06952; Tue, 6 Oct 98 01:25:07 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA10143; Mon, 5 Oct 1998 22:25:07 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: mailing list archives References: <19981005203344.A23553@molehill.org> From: Greg Badros Date: 05 Oct 1998 22:25:07 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 20:33:45 -0700" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > The perl5 porters archives are easier to use; they're searchable, > viewable by thread or by date, and the browsing pages are split up and > shorter. They're using MHonarc and glimpseHTTP. The look and feel > are close enough to make me think that hypermail and mhonarc are the > same package, renamed. I second this positive review. of MHonarc + glimpse Greg From owner-scwm-discuss@mit.edu Tue Oct 6 01:26:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17416 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:26:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17400; Tue, 6 Oct 1998 01:26:50 -0400 Message-Id: <199810060526.BAA17400@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: guile-gtk In-reply-to: Your message of "Mon, 05 Oct 1998 20:35:00 PDT." <19981005203500.A23582@molehill.org> Date: Tue, 06 Oct 1998 01:26:50 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I seem to recall Maciej posting an almost-working example of using > guile-gtk with scwm, but it doesn't look like I saved it, and can't > find it in the archives. It's there on the thread "Widget sets and scwm", but I haven't had a chance to make the changes to scwm and/or guile-gtk to make it truly useful. The guile-gtk event loop is not yet properly integrated. IMO the right way to handle this is for gtk/gdk to somehow expose the fd's it wants to select on and it's timer timeout, then proper hooks can be added purely at the Scheme level to invoke the event loop when relevant. We may need to add idle hooks to scwm's event loop as well. I think this is probably the easiest solution. Possibly more useful would be to do something spiffy with threads, but that too is tricky. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 01:27:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17453 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:27:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17449 for ; Tue, 6 Oct 1998 01:27:36 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA17150; Tue, 6 Oct 98 01:26:39 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id WAA10146; Mon, 5 Oct 1998 22:26:30 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: menu interface cleanup/changes References: <19981005210246.A23672@molehill.org> From: Greg Badros Date: 05 Oct 1998 22:26:30 -0700 In-Reply-To: Todd Larason's message of "Mon, 5 Oct 1998 21:02:46 -0700" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > How important is it to keep primitive interfaces easy to use? Simple things should be simple, complex things should be possible (Alan Kay). > base.scm's (menu) and the menu test files are the only things using > make-menu, and I've incompatibly broken the interface before without > people griping. I've got no problems with the primitive interface to menus getting a bit hairier. That's why we have the scheme wrapper to hide implementation detail changes and present a cleaner view to the end user. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 01:31:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17572 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:31:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17559; Tue, 6 Oct 1998 01:31:04 -0400 Message-Id: <199810060531.BAA17559@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: menu interface cleanup/changes In-reply-to: Your message of "Mon, 05 Oct 1998 21:02:46 PDT." <19981005210246.A23672@molehill.org> Date: Tue, 06 Oct 1998 01:31:03 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > How important is it to keep primitive interfaces easy to use? > > The make-menu interface goes to great effort to allow defaults to be > used, which leads to many many primitives to set all the defaults, then > scheme wrappers around some of those primitives to keep them > convenient. > > If make-menu is allowed to be harder to use, Scr.menu_font, > Scr.menu_look and the primtives for getting and setting them can > disappear. Scr.menu_color and the like can be renamed (tentatively > proposing Scr.not_menu_color, an intentionally awful name, to encourage > further cleanup), the primitives to set them can be cleaned up some, > and the wrappers in base.scm can go away. > > base.scm's (menu) and the menu test files are the only things using > make-menu, and I've incompatibly broken the interface before without > people griping. > It's probably foolish to keep global defaults in C space, for much the reasons you cited. I think the high-level menu interface should be moved to live in its own module at some point and get enhanced to do all the default handling on the Scheme level. We also need to be more clever in some ways about handling menu styles, so that we can allow changing all aspects of meny style on the fly at least as conveniently as you can for window styles. I'll post a rough proposal for this soon. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 01:32:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17639 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:32:32 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17632 for ; Tue, 6 Oct 1998 01:32:29 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA07759; Tue, 6 Oct 98 01:31:21 EDT Received: (qmail 24215 invoked by uid 501); 6 Oct 1998 05:32:07 -0000 Message-Id: <19981005223207.A24102@molehill.org> Date: Mon, 5 Oct 1998 22:32:07 -0700 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: guile-gtk References: <19981005203500.A23582@molehill.org> <199810060526.BAA17400@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810060526.BAA17400@huis-clos.mit.edu>; from Maciej Stachowiak on Tue, Oct 06, 1998 at 01:26:50AM -0400 X-Tom-Swifty: "Have some shampoo", was Tom's unconditional offer. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981006, Maciej Stachowiak wrote: > It's there on the thread "Widget sets and scwm", thank you, and Greg, and Craig =) > The guile-gtk event loop is not yet properly integrated. IMO > the right way to handle this is for gtk/gdk to somehow expose the fd's > it wants to select on and it's timer timeout, then proper hooks can be > added purely at the Scheme level to invoke the event loop when > relevant. I'm probably missing something very basic here, but why does gtk need to select on FDs at all? Why can't it use the X connection scwm already has, and just be handed X events (and timeout events) for the windows it's handling? From owner-scwm-discuss@mit.edu Tue Oct 6 01:34:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17705 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:34:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17699; Tue, 6 Oct 1998 01:34:01 -0400 Message-Id: <199810060534.BAA17699@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "05 Oct 1998 22:21:38 PDT." Date: Tue, 06 Oct 1998 01:34:01 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > So now the question is: how could this bug have been caught through > language, infrastructure or conventional means. I.e., what failing of > C, the compiler, or us caused us to write the buggy code that was not > caught, and not so obviously wrong to be easy to spot. > Probably largely the fact that SCM is secretly a typedef for long and therefore passing integer types when a SCM is intended does not give an error. There are ways to fix this, but none are pretty. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 01:42:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17816 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:42:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA17813 for ; Tue, 6 Oct 1998 01:42:19 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA19293; Tue, 6 Oct 98 01:41:03 EDT Received: (qmail 24283 invoked by uid 501); 6 Oct 1998 05:41:36 -0000 Message-Id: <19981005224135.A24229@molehill.org> Date: Mon, 5 Oct 1998 22:41:35 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810032128.RAA12069@huis-clos.mit.edu> <19981003172830.A31567@molehill.org> <19981005021407.A19134@molehill.org> <19981005150018.A21837@molehill.org> <19981005190549.A23185@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Mon, Oct 05, 1998 at 10:21:38PM -0700 X-Tom-Swifty: "That hydroelectric facility is so beautiful I think I'll pass out!" said Tom, fainting with dam praise. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981005, Greg Badros wrote: > Todd Larason writes: > > So now the question is: how could this bug have been caught through > language, infrastructure or conventional means. I.e., what failing of > C, the compiler, or us caused us to write the buggy code that was not > caught, and not so obviously wrong to be easy to spot. : /* In the beginning was the Word: */ typedef long SCM; looks likes the options are to rewrite guile to use another type for SCM (struct scm *? then cast to long internally? Ugh. and this would leave open void *s as still non-warnable) or to implement the egcs suggestion of arbitary meta-type attributes for variables; the original problem that was to solve was host vs. network byte order ints. The problem seems very similar. From owner-scwm-discuss@mit.edu Tue Oct 6 01:44:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17829 for scwm-discuss-outgoing; Tue, 6 Oct 1998 01:44:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA17820; Tue, 6 Oct 1998 01:43:49 -0400 Message-Id: <199810060543.BAA17820@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: guile-gtk In-reply-to: Your message of "Mon, 05 Oct 1998 22:32:07 PDT." <19981005223207.A24102@molehill.org> Date: Tue, 06 Oct 1998 01:43:39 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > > I'm probably missing something very basic here, but why does gtk need > to select on FDs at all? Why can't it use the X connection scwm > already has, and just be handed X events (and timeout events) for the > windows it's handling? > There are two issues. 1) libgdk provides gdk_input_add and gdk_timer_add which allow relevant hooks to be added. We could ask that these just not get called in scwm guile-gtk code, but some interesting gtk extension libraries (notably GNOME) use them from within C code. So Gtk needs to have it's own FDs and timers just for that. 2) Hacking both scwm and gtk so that they can share an X file descriptor, and so scwm can pass relevant X events to gtk (well, actually, gdk) and gtk can receive them that way instead of getting them istelf would require a _lot_ of restructuring of both sets of code. I'd like it to be possible to use guile-gtk unmodified in scwm instead of having to maintain a hacked version, and the gtk+ and guile-gtk maintainers are a lot more likely to accept patches for small and generally useful changes, like introspecting about the fds and timeouts gtk cares about. That's why I think the right solution is to be overly-clever and open two X fds. As it is, doing a `destroy-window' on a guile-gtk window spawned by scwm itself will kill scwm; we can hack around that, but I think with a shared X connection there'd be even worse interactions. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 04:07:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA19787 for scwm-discuss-outgoing; Tue, 6 Oct 1998 04:07:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA19784 for ; Tue, 6 Oct 1998 04:07:06 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA05051; Tue, 6 Oct 98 04:06:52 EDT Received: (qmail 24909 invoked by uid 501); 6 Oct 1998 08:07:33 -0000 Message-Id: <19981006010732.A24879@molehill.org> Date: Tue, 6 Oct 1998 01:07:32 -0700 From: Todd Larason To: scwm-discuss list Subject: 0.9 release timing, branch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Don't worry, I'll take full responsibility for providing the prisoner with getaway footwear", said Tom consolingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I think it may be a good idea to create a branch for a 0.9 release. I'm sitting on changes to support dynamic modules, to remove a lot of the default menu setting cruft, and to allow menu looks to be inherited and extended somewhat (coming close to meeting my needs/desires for general menu styles). I'm in that middle ground of confidence with the changes where I'd normally check them in, but not confident enough to do them ~3 days before a hopefully rock-solid release. From owner-scwm-discuss@mit.edu Tue Oct 6 10:58:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21603 for scwm-discuss-outgoing; Tue, 6 Oct 1998 10:58:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21600 for ; Tue, 6 Oct 1998 10:58:17 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA15239; Tue, 6 Oct 98 10:58:20 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA11966; Tue, 6 Oct 1998 07:58:12 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810060534.BAA17699@huis-clos.mit.edu> From: Greg Badros Date: 06 Oct 1998 07:58:11 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 01:34:01 EDT" Message-Id: Lines: 25 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > > > So now the question is: how could this bug have been caught through > > language, infrastructure or conventional means. I.e., what failing of > > C, the compiler, or us caused us to write the buggy code that was not > > caught, and not so obviously wrong to be easy to spot. > > > > Probably largely the fact that SCM is secretly a typedef for long and > therefore passing integer types when a SCM is intended does not give > an error. There are ways to fix this, but none are pretty. Another possibility is to guard all guile (gh_ and scm_) functions which take SCMs with initial assertions about an SCM being >= some minimum value. I'd imagine that various platforms can make some guarantees. Though this approach is dynamic and heuristic, it seems like it'd've caught this bug and many others (as integers are often small enough to not be mistaken as a pointer). Non debug builds of course would have the assertions turned off so there'd ultimately be no performance penalty. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 11:10:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21718 for scwm-discuss-outgoing; Tue, 6 Oct 1998 11:10:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA21715 for ; Tue, 6 Oct 1998 11:10:38 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA19877; Tue, 6 Oct 98 11:10:41 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA12040; Tue, 6 Oct 1998 08:10:30 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: 0.9 release timing, branch References: <19981006010732.A24879@molehill.org> From: Greg Badros Date: 06 Oct 1998 08:10:30 -0700 In-Reply-To: Todd Larason's message of "Tue, 6 Oct 1998 01:07:32 -0700" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I think it may be a good idea to create a branch for a 0.9 release. > > I'm sitting on changes to support dynamic modules, to remove a lot of > the default menu setting cruft, and to allow menu looks to be inherited > and extended somewhat (coming close to meeting my needs/desires for > general menu styles). I'm in that middle ground of confidence with > the changes where I'd normally check them in, but not confident enough > to do them ~3 days before a hopefully rock-solid release. Where did 3 days come from? I'm guessing we can pull off a trial 0.9 about a week after guile-1.3 is released, and then a real 0.9 once the list folks have all banged enough on the trial to be confident that it'll be all that we hoped for. WRT creating a branch, I think it makes more sense to create a .10 (>.9) branch for you to check in your work on, and have the .9 release changes continue to happen on the main branch. (But I am by no means a CVS branching guru -- insight and tips from those who are is appreciated). Greg From owner-scwm-discuss@mit.edu Tue Oct 6 11:16:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21780 for scwm-discuss-outgoing; Tue, 6 Oct 1998 11:16:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21773; Tue, 6 Oct 1998 11:16:33 -0400 Message-Id: <199810061516.LAA21773@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) In-reply-to: Your message of "Mon, 05 Oct 1998 22:41:35 PDT." <19981005224135.A24229@molehill.org> Date: Tue, 06 Oct 1998 11:16:33 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981005, Greg Badros wrote: > > Todd Larason writes: > > > > So now the question is: how could this bug have been caught through > > language, infrastructure or conventional means. I.e., what failing of > > C, the compiler, or us caused us to write the buggy code that was not > > caught, and not so obviously wrong to be easy to spot. > > : > /* In the beginning was the Word: > */ > typedef long SCM; > > > looks likes the options are to rewrite guile to use another type for > SCM (struct scm *? then cast to long internally? Ugh. and this > would leave open void *s as still non-warnable) or to implement the > egcs suggestion of arbitary meta-type attributes for variables; the > original problem that was to solve was host vs. network byte order > ints. The problem seems very similar. Solutions that would integrate better with typechecking that I've heard include making SCM a typedef for a single-member structure, or an appropriate union. This is doable but would require changing quite a bit of code. Plus i make the Guile code less comprehensible. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 11:28:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22008 for scwm-discuss-outgoing; Tue, 6 Oct 1998 11:28:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21998; Tue, 6 Oct 1998 11:28:15 -0400 Message-Id: <199810061528.LAA21998@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: 0.9 release timing, branch In-reply-to: Your message of "Tue, 06 Oct 1998 01:07:32 PDT." <19981006010732.A24879@molehill.org> Date: Tue, 06 Oct 1998 11:28:15 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I think it may be a good idea to create a branch for a 0.9 release. > > I'm sitting on changes to support dynamic modules, to remove a lot of > the default menu setting cruft, and to allow menu looks to be inherited > and extended somewhat (coming close to meeting my needs/desires for > general menu styles). I'm in that middle ground of confidence with > the changes where I'd normally check them in, but not confident enough > to do them ~3 days before a hopefully rock-solid release. > I don't think we are going to release in 3 days. I have some changes in my working dir I'd like to check in, but I have been trying to avoid checking in anything that's not either a trivial change or someone else's patch, because I want to wait until my emplyer processes my copyright disclaimer, and I want to keep scwm's proverbial nose clean on this. We also need some time for extensive testing. I'd suggest you go ahead and check in your changes. We probably will want a release branch at some point, but not yet; and it's pretty hard to merge from the trunk to a branch in CVS from what I hear. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 12:04:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22440 for scwm-discuss-outgoing; Tue, 6 Oct 1998 12:04:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22436 for ; Tue, 6 Oct 1998 12:04:10 -0400 Received: from [152.78.71.3] by MIT.EDU with SMTP id AA27492; Tue, 6 Oct 98 12:03:59 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id RAA29251 for ; Tue, 6 Oct 1998 17:01:23 +0100 (BST) Message-Id: <6514.199810061603@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Tue, 6 Oct 1998 17:03:26 +0100 Date: Tue, 6 Oct 1998 17:03:55 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: can't find Guile? To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk D'Oh, I've just upgraded my machine, and d/l guile-core and scwm (latest cvs) - compiled and installed guile (libguile.so.3)... but scwm './configure' cannot find the guile - I just get :- configure: error: Can not find Guile 1.2 or later on the system Guile is installed in /usr/local, and I've tried the --with-guile options... Any ideas? Cheers, Mark. From owner-scwm-discuss@mit.edu Tue Oct 6 12:24:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22600 for scwm-discuss-outgoing; Tue, 6 Oct 1998 12:24:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22594; Tue, 6 Oct 1998 12:24:13 -0400 Message-Id: <199810061624.MAA22594@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: 0.9 release timing, branch In-reply-to: Your message of "06 Oct 1998 08:10:30 PDT." Date: Tue, 06 Oct 1998 12:24:13 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Todd Larason writes: > > > I think it may be a good idea to create a branch for a 0.9 release. > > > > I'm sitting on changes to support dynamic modules, to remove a lot of > > the default menu setting cruft, and to allow menu looks to be inherited > > and extended somewhat (coming close to meeting my needs/desires for > > general menu styles). I'm in that middle ground of confidence with > > the changes where I'd normally check them in, but not confident enough > > to do them ~3 days before a hopefully rock-solid release. > > Where did 3 days come from? I'm guessing we can pull off a trial 0.9 > about a week after guile-1.3 is released, and then a real 0.9 once the > list folks have all banged enough on the trial to be confident that > it'll be all that we hoped for. > > WRT creating a branch, I think it makes more sense to create a .10 (>.9) > branch for you to check in your work on, and have the .9 release changes > continue to happen on the main branch. (But I am by no means a CVS > branching guru -- insight and tips from those who are is appreciated). > Branching is done for two purposes, to keep unstable changes under revision control without affecting developers, and to be able to work on a track of development stemming from an older revision (e.g. bugfixes to an old release, or working on cleaning up code to be release while continuing other development). We probably should fork a pre-0.9 branch at some point in case anyone wants to check other stuff in while the release branch needs to see bugfixes only, but, IMO, not yet. Todd could make his own branch for menuing changes, but I think he may as well check his stuff in on the trunk, if it's reasonably tested at least by him. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 12:38:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22785 for scwm-discuss-outgoing; Tue, 6 Oct 1998 12:38:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22777; Tue, 6 Oct 1998 12:38:41 -0400 Message-Id: <199810061638.MAA22777@huis-clos.mit.edu> To: mst95r@ecs.soton.ac.uk cc: scwm-discuss@mit.edu Subject: Re: can't find Guile? In-reply-to: Your message of "Tue, 06 Oct 1998 17:03:55 BST." <6514.199810061603@penelope.ecs.soton.ac.uk> Date: Tue, 06 Oct 1998 12:38:41 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mst95r@ecs.soton.ac.uk writes: > D'Oh, > > I've just upgraded my machine, and d/l guile-core and scwm (latest > cvs) - compiled and installed guile (libguile.so.3)... but scwm > './configure' cannot find the guile - I just get :- > > configure: error: Can not find Guile 1.2 or later on the system > > > Guile is installed in /usr/local, and I've tried the --with-guile > options... > > Any ideas? > Can you post config.log or email it to me? I think I made changes recently to work with the latest guile-core but I may have screwed up (build-guile got renamed to guile-config). - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 13:07:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23109 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:07:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23106 for ; Tue, 6 Oct 1998 13:07:25 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA01948; Tue, 6 Oct 98 13:07:28 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13086; Tue, 6 Oct 1998 10:07:20 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810061619.MAA22545@huis-clos.mit.edu> From: Greg Badros Date: 06 Oct 1998 10:07:20 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 12:19:30 EDT" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Not all SCMs are actually pointers, characters and integers up to 30 > bits are stored directly in that word, with a type tag. One could come > up with an assertion based on the possible values of the type tags, > but this would be pretty complicated. Which is why we have abstractions like macros and functions. From a quick look at tags.h, it looks as though the valid SCM values are sparse enough and well-defined enough that perhaps a macro for validating SCMs could be written. Then asserting the validity of all SCMs at function calls in a debug build might help catch some errors dynamically. Obviously I'd prefer a solution that got us this statically, but it sounds like that would require more pervasive changes to guile. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 13:09:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23145 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:09:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23142 for ; Tue, 6 Oct 1998 13:09:06 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA19133; Tue, 6 Oct 98 13:08:58 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13119; Tue, 6 Oct 1998 10:08:38 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: can't find Guile? References: <6514.199810061603@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 06 Oct 1998 10:08:37 -0700 In-Reply-To: Mark Toller's message of "Tue, 6 Oct 1998 17:03:55 +0100 (GMT)" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > D'Oh, > > I've just upgraded my machine, and d/l guile-core and scwm (latest > cvs) - compiled and installed guile (libguile.so.3)... but scwm > './configure' cannot find the guile - I just get :- > > configure: error: Can not find Guile 1.2 or later on the system > > > Guile is installed in /usr/local, and I've tried the --with-guile > options... > > Any ideas? Look at the end of config.log and see if that gives you any hints (or send it to Maciej and me in private email). Greg From owner-scwm-discuss@mit.edu Tue Oct 6 13:24:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23342 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:24:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23339 for ; Tue, 6 Oct 1998 13:24:08 -0400 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA07841; Tue, 6 Oct 98 13:24:10 EDT Received: from ZengHe.augustin.thierry (zenghe.issy.cnet.fr [139.100.250.71]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4MA3JX0M; Tue, 6 Oct 1998 19:24:05 +0200 Received: (from fare@localhost) by ZengHe.augustin.thierry (8.8.7/) id TAA16833 for scwm-discuss@mit.edu; Tue, 6 Oct 1998 19:30:42 +0200 Message-Id: <19981006190137.A16703@ZengHe.issy.cnet.fr> Date: Tue, 6 Oct 1998 19:01:37 +0200 From: Francois-Rene Rideau To: owner-scwm-discuss@mit.edu Subject: Re: Progress on using FvwmButtons (and some questions) Reply-To: Francois-Rene Rideau References: <19981005224135.A24229@molehill.org> <199810061516.LAA21773@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: <199810061516.LAA21773@huis-clos.mit.edu>; from Maciej Stachowiak on Tue, Oct 06, 1998 at 11:16:33AM -0400 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.augustin.thierry id TAA16833 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id NAA23340 Sender: owner-scwm-discuss@mit.edu Precedence: bulk About code analysis tools and typedef long SCM preventing catching of type errors, what about using Tom Lord's Ctool? It's a C code analysis tool he wrote for systas, which is basically a forked version of GUILE. Maybe it could be usefully backported to main GUILE, and help catch such type errors? Hum. Looks like ctool is no longer available by FTP. Maybe contact Tom Lord ? Just my 2p worth, anyway. PS: I've (only) now made scwm my permanent window manager. When netscape (on some non-top-left virtual screen) pops us a "find" window, it appears far out of screen, as if netscape gave an absolute geometry that was interpreted relative to current screen. I can then select the window in the list, and move it several screens away to where I'd like, but it's annoying. PPS: uh, can anyone gimme hints about use of cut-buffers with scwm? ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Reporter: Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. From owner-scwm-discuss@mit.edu Tue Oct 6 13:32:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23450 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:32:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23447 for ; Tue, 6 Oct 1998 13:32:42 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA27191; Tue, 6 Oct 98 13:32:35 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13439; Tue, 6 Oct 1998 10:32:32 -0700 (PDT) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Progress on using FvwmButtons (and some questions) References: <19981005224135.A24229@molehill.org> <199810061516.LAA21773@huis-clos.mit.edu> <19981006190137.A16703@ZengHe.issy.cnet.fr> From: Greg Badros Date: 06 Oct 1998 10:32:31 -0700 In-Reply-To: Francois-Rene Rideau's message of "Tue, 6 Oct 1998 19:01:37 +0200" Message-Id: Lines: 33 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > About code analysis tools and typedef long SCM > preventing catching of type errors, > what about using Tom Lord's Ctool? > It's a C code analysis tool he wrote for systas, > which is basically a forked version of GUILE. > Maybe it could be usefully backported to main GUILE, > and help catch such type errors? > > Hum. Looks like ctool is no longer available by FTP. > Maybe contact Tom Lord ? > > Just my 2p worth, anyway. Sounds potentially useful... > PS: I've (only) now made scwm my permanent window manager. > When netscape (on some non-top-left virtual screen) > pops us a "find" window, it appears far out of screen, > as if netscape gave an absolute geometry that was interpreted > relative to current screen. I can then select the window in the list, > and move it several screens away to where I'd like, but it's annoying. Which .scwmrc are you using -- mine (gjb.scwmrc) does some funky things with placing the find window that may either hide or introduce this problem for you. > PPS: uh, can anyone gimme hints about use of cut-buffers with scwm? See netscape-goto-cut-buffer-url in scwm/scheme/flux.scm Greg From owner-scwm-discuss@mit.edu Tue Oct 6 13:35:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23505 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:35:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23502 for ; Tue, 6 Oct 1998 13:35:16 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA28049; Tue, 6 Oct 98 13:35:08 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13573; Tue, 6 Oct 1998 10:35:10 -0700 (PDT) To: scwm-discuss@mit.edu Subject: scwm/scwm -> scwm/src From: Greg Badros Date: 06 Oct 1998 10:35:09 -0700 Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm re-proposing the rename of the main src directory. I think a binary with path "scwm/scwm/scwm" bites-- plus a prefix "scwm/" in discussions is ambiguous. If the scwm subdir of the scwm top-level subdir were renamed to src/, the ambiguities would disappear, and things would be a bit more in line with other packages' conventions. (The downside is the renaming of the directory in the repository can complicate retrieving old versions -- I think we can get around it with a symlink in the repo that make scwm/scwm an alias for scwm/src). Greg From owner-scwm-discuss@mit.edu Tue Oct 6 13:51:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23714 for scwm-discuss-outgoing; Tue, 6 Oct 1998 13:51:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23708; Tue, 6 Oct 1998 13:51:27 -0400 Message-Id: <199810061751.NAA23708@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "06 Oct 1998 10:35:09 PDT." Date: Tue, 06 Oct 1998 13:51:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > I'm re-proposing the rename of the main src directory. I think a binary > with path "scwm/scwm/scwm" bites-- plus a prefix "scwm/" in discussions > is ambiguous. If the scwm subdir of the scwm top-level subdir were > renamed to src/, the ambiguities would disappear, and things would be a > bit more in line with other packages' conventions. > > (The downside is the renaming of the directory in the repository can > complicate retrieving old versions -- I think we can get around it with > a symlink in the repo that make scwm/scwm an alias for scwm/src). > I agree this is a good idea in general, however, both ways I can think of to do it have an annoying downside. Just cvs deleting the old files and cvs adding them in a new location has the annoying property of losing the revision history. This is, IMO, a non-starter. Moving the directory in the repository will break the nightly patches (OK, we can probably live with telling people not to use a particular patch), and will, as you mentioned, complicate retriving older versions in exactly the form in which they existed. I don't know if putting symlinks in the repository is a good idea or whether it will have the intended effect. I expect the result will be that all checkouts will end up with both `scwm/' and `src/' subdirectories. I really wish CVS properly supported renames... - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 14:22:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24072 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:22:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24069 for ; Tue, 6 Oct 1998 14:22:48 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA14830; Tue, 6 Oct 98 14:22:43 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id OAA17874 for ; Tue, 6 Oct 1998 14:22:46 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: scwm/scwm -> scwm/src References: Date: 06 Oct 1998 14:22:40 -0400 Message-Id: <5lg1d1eej3.fsf@tequila.systemsz.cs.yale.edu> Lines: 13 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu X-Trace: 6 Oct 1998 14:22:40 -0500, tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Greg" == Greg Badros writes: > complicate retrieving old versions -- I think we can get around it with > a symlink in the repo that make scwm/scwm an alias for scwm/src). I would advise against a symlink in the repo. CVS doesn't understand them, so it will just not know it's dealing twice with the same thing. It seemed to work OK when I tried, but you'll still have a serious slowdown for duplication of work. And I don't guarantee that it will indeed work correctly (I have tried it, but only a tiny bit). Stefan From owner-scwm-discuss@mit.edu Tue Oct 6 14:26:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24108 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:26:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24104 for ; Tue, 6 Oct 1998 14:26:34 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA16261; Tue, 6 Oct 98 14:26:27 EDT Received: (qmail 32556 invoked by uid 501); 6 Oct 1998 18:26:30 -0000 Message-Id: <19981006112629.A32407@molehill.org> Date: Tue, 6 Oct 1998 11:26:29 -0700 From: Todd Larason To: scwm-discuss list Subject: module source directory Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Have it monogrammed", was Tom's initial suggestion. Sender: owner-scwm-discuss@mit.edu Precedence: bulk Should the module-ified version of draw-xpm-menus.c stay in scwm/, or move somewhere else, maybe app/xpm-menus/? From owner-scwm-discuss@mit.edu Tue Oct 6 14:32:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24210 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:32:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24206 for ; Tue, 6 Oct 1998 14:32:12 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA03288; Tue, 6 Oct 98 14:32:14 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA15006; Tue, 6 Oct 1998 11:32:06 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: <199810061751.NAA23708@huis-clos.mit.edu> From: Greg Badros Date: 06 Oct 1998 11:32:06 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 13:51:27 EDT" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I agree this is a good idea in general, however, both ways I can think > of to do it have an annoying downside. Just cvs deleting the old files > and cvs adding them in a new location has the annoying property of > losing the revision history. This is, IMO, a non-starter. Right. > Moving the directory in the repository will break the nightly patches > (OK, we can probably live with telling people not to use a particular > patch), and will, as you mentioned, complicate retriving older > versions in exactly the form in which they existed. How 'bout we copy all the scwm/scwm/?* to scwm/src/ (inside the repository) and then cvs remove all the files in scwm/scwm/?* and the scwm/scwm directory? (After backing up the repo, of course!) Greg From owner-scwm-discuss@mit.edu Tue Oct 6 14:35:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24280 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:35:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24276 for ; Tue, 6 Oct 1998 14:35:08 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA04322; Tue, 6 Oct 98 14:35:08 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 06 Oct 1998 14:34:24 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 06 Oct 1998 14:34:23 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA27988; Tue, 6 Oct 1998 14:35:03 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Oct 1998 10:35:09 -0700" Date: 06 Oct 1998 14:35:03 -0400 Message-Id: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk whatever the trouble, this has to be done, and the earlier it is done, the better. (just MO). >>>> In message >>>> Sent on 06 Oct 1998 10:35:09 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "scwm/scwm -> scwm/src": >> I'm re-proposing the rename of the main src directory. I think a binary >> with path "scwm/scwm/scwm" bites-- plus a prefix "scwm/" in discussions >> is ambiguous. If the scwm subdir of the scwm top-level subdir were >> renamed to src/, the ambiguities would disappear, and things would be a >> bit more in line with other packages' conventions. >> >> (The downside is the renaming of the directory in the repository can >> complicate retrieving old versions -- I think we can get around it with >> a symlink in the repo that make scwm/scwm an alias for scwm/src). Come on! Just cheat: search and replace `scwm' with `src' in the *right places* in the CVS tree. This is not MSjunk, after all, all files are plain text. It can't be *that* hard. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Apathy Club meeting this Friday. If you want to come, you're not invited. From owner-scwm-discuss@mit.edu Tue Oct 6 14:44:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24501 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:44:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA24497 for ; Tue, 6 Oct 1998 14:44:41 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AB07823; Tue, 6 Oct 98 14:44:43 EDT Received: from jekyll.piermont.com (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id OAA26138; Tue, 6 Oct 1998 14:44:35 -0400 (EDT) Message-Id: <199810061844.OAA26138@jekyll.piermont.com> To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-Reply-To: Your message of "Tue, 06 Oct 1998 13:51:27 EDT." <199810061751.NAA23708@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 06 Oct 1998 14:44:35 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk The ugly way we do this in NetBSD is as follows: 1) physically copy the ,v files in the repository to the new location. 2) remove all tags from the copied ,v files 3) cvs rm the old file locations. This allows you to check out an old branch and still maintain revision history on the moved files. It is ugly as sin but works. .pm Maciej Stachowiak writes: > I agree this is a good idea in general, however, both ways I can think > of to do it have an annoying downside. Just cvs deleting the old files > and cvs adding them in a new location has the annoying property of > losing the revision history. This is, IMO, a non-starter. > > Moving the directory in the repository will break the nightly patches > (OK, we can probably live with telling people not to use a particular > patch), and will, as you mentioned, complicate retriving older > versions in exactly the form in which they existed. > > I don't know if putting symlinks in the repository is a good idea or > whether it will have the intended effect. I expect the result will be > that all checkouts will end up with both `scwm/' and `src/' > subdirectories. > > I really wish CVS properly supported renames... > > - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 14:51:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24642 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:51:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24636; Tue, 6 Oct 1998 14:51:38 -0400 Message-Id: <199810061851.OAA24636@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: module source directory In-reply-to: Your message of "Tue, 06 Oct 1998 11:26:29 PDT." <19981006112629.A32407@molehill.org> Date: Tue, 06 Oct 1998 14:51:38 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > Should the module-ified version of draw-xpm-menus.c stay in scwm/, > or move somewhere else, maybe app/xpm-menus/? I'd like to see dynamically loaded modules have their own separate directories. These shouldn't be under `app/' though, that's just a convenience to run out of a build tree, not a place for real source. I've previously thought of "modules" or possible "binmod" to not be confused with Scheme-based non-binary modules. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 14:55:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24713 for scwm-discuss-outgoing; Tue, 6 Oct 1998 14:55:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA24708; Tue, 6 Oct 1998 14:55:27 -0400 Message-Id: <199810061855.OAA24708@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "06 Oct 1998 11:32:06 PDT." Date: Tue, 06 Oct 1998 14:55:27 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > Moving the directory in the repository will break the nightly patches > > (OK, we can probably live with telling people not to use a particular > > patch), and will, as you mentioned, complicate retriving older > > versions in exactly the form in which they existed. > > How 'bout we copy all the scwm/scwm/?* to scwm/src/ (inside the > repository) and then cvs remove all the files in scwm/scwm/?* and the > scwm/scwm directory? > > (After backing up the repo, of course!) > That would mostly work, except that src/ would still get checked out on attempts to check out old versions. Perhaps that's not as much a concern though. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Tue Oct 6 15:09:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25038 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:09:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25026; Tue, 6 Oct 1998 15:09:53 -0400 Message-Id: <199810061909.PAA25026@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "06 Oct 1998 14:35:03 EDT." Date: Tue, 06 Oct 1998 15:09:53 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > whatever the trouble, this has to be done, and the earlier it is done, > the better. > (just MO). > Maybe if we wait long enough, someone will write renaming support for CVS. OK, back to reality now. > > Come on! Just cheat: search and replace `scwm' with `src' in the *right > places* in the CVS tree. This is not MSjunk, after all, all files are > plain text. > It can't be *that* hard. > I don't like the idea of falsifying old revisions; I'd prefer Greg's other suggest solution of copying the scwm/ directory to src/ and then CVS deleting it better. At least that would give us a superset of the code actually shipped for those old versions. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 15:10:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25054 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:10:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25051 for ; Tue, 6 Oct 1998 15:10:02 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA18363; Tue, 6 Oct 98 15:09:56 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA15083; Tue, 6 Oct 1998 12:09:48 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: <199810061855.OAA24708@huis-clos.mit.edu> From: Greg Badros Date: 06 Oct 1998 12:09:47 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 14:55:27 EDT" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > > > > > > Moving the directory in the repository will break the nightly patches > > > (OK, we can probably live with telling people not to use a particular > > > patch), and will, as you mentioned, complicate retriving older > > > versions in exactly the form in which they existed. > > > > How 'bout we copy all the scwm/scwm/?* to scwm/src/ (inside the > > repository) and then cvs remove all the files in scwm/scwm/?* and the > > scwm/scwm directory? > > > > (After backing up the repo, of course!) > > > > That would mostly work, except that src/ would still get checked out > on attempts to check out old versions. Perhaps that's not as much a > concern though. That seems ok, if suboptimal. The other issue is it increases the size of the repo by about 5MB (from 10MB -> 15MB) since all the ,v files are duplicated. It might be possible to make the scwm/Attic/*,v files point to the src/*,v files to save space, but probably not worth the risk. I'll let you use whatever mechanism you choose, since it'll need to be done as root to preserve owners of files, etc. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 15:17:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25237 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:17:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25229; Tue, 6 Oct 1998 15:17:43 -0400 Message-Id: <199810061917.PAA25229@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "Tue, 06 Oct 1998 14:44:35 EDT." <199810061844.OAA26138@jekyll.piermont.com> Date: Tue, 06 Oct 1998 15:17:43 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > The ugly way we do this in NetBSD is as follows: > > 1) physically copy the ,v files in the repository to the new location. > 2) remove all tags from the copied ,v files > 3) cvs rm the old file locations. > > This allows you to check out an old branch and still maintain revision > history on the moved files. It is ugly as sin but works. > OK, that works for me. I'll try to do this ASAP. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 15:26:27 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25476 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:26:27 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25473 for ; Tue, 6 Oct 1998 15:26:26 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA08461; Tue, 6 Oct 98 15:26:19 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA15096; Tue, 6 Oct 1998 12:26:22 -0700 (PDT) To: scwm-discuss@mit.edu Subject: scwm-mode [was Re: scwm/scwm -> scwm/src] References: From: Greg Badros Date: 06 Oct 1998 12:26:22 -0700 In-Reply-To: Sam Steingold's message of "06 Oct 1998 14:35:03 -0400" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > whatever the trouble, this has to be done, and the earlier it is done, > the better. > (just MO). Hey, welcome back! I had a thought about scwm-mode while you were away. It'd be nice to have a silly heuristic in the evaluating of scwm sexps that tried to reset scwm-obarray to nil (so that it gets re-initialized) any time a define is evaluated (thus introducing a new possible completion). The problem is that, if I evaluate (define (foo-bar-baz) ..... ) any time after the first time I do a completion (which is when the scwm-obarray gets initialized), I won't be able to complete to foo-bar-baz. I'm willing to live with a conservative (overly-stupid) approximation that just resets the obarray to nil whenever a "([ \t]*\\(define\\|use-modules\\|load\>)" is in an expression sent to scwm. If all the macros/procedures that do a define start with "define" this should work reasonably well. (And when it's broken, one can always reset it by hand-- I'd just like to reduce the frequency of doing so). I suppose the right way to do this is have a guile hook when a new symbol is interned, but that's probably overkill. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 15:33:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25784 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:33:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25779 for ; Tue, 6 Oct 1998 15:33:56 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA11350; Tue, 6 Oct 98 15:33:48 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA15141; Tue, 6 Oct 1998 12:33:45 -0700 (PDT) To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: <199810061917.PAA25229@huis-clos.mit.edu> From: Greg Badros Date: 06 Oct 1998 12:33:44 -0700 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 15:17:43 EDT" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > perry@piermont.com writes: > > > > The ugly way we do this in NetBSD is as follows: > > > > 1) physically copy the ,v files in the repository to the new location. > > 2) remove all tags from the copied ,v files > > 3) cvs rm the old file locations. > > > > This allows you to check out an old branch and still maintain revision > > history on the moved files. It is ugly as sin but works. > > > > OK, that works for me. I'll try to do this ASAP. Sounds good to me too-- this is the same as my suggestion with the addition of step 2, removing the tags from the src/*,v files, right? Still has the size-blowup problem, but not the extra work at check-out of old versions problem. Greg From owner-scwm-discuss@mit.edu Tue Oct 6 15:43:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25967 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:43:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25959; Tue, 6 Oct 1998 15:43:52 -0400 Message-Id: <199810061943.PAA25959@huis-clos.mit.edu> To: Gordon Matzigkeit cc: scwm-discuss@mit.edu Subject: Re: getop-gnu-style.scm In-reply-to: Your message of "06 Oct 1998 13:25:04 MDT." <86k92dpk6n.fsf@trick.fig.org> Date: Tue, 06 Oct 1998 15:43:51 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gord@trick.fig.org writes: > Hi! > > >>>>> Russ McManus writes: > > RM> One caveat; the routines in this source file don't properly > RM> implement complete getopt_long functionality. I think that's why > RM> I didn't call it that to begin with. The big thing that is > RM> missing is support for single letter options. I would add this > RM> code if someone requested it. > > In GUSH, I'm reimplementing the GNU Argp functions in Scheme (see your > favorite glibc-2.1 reference manual, or Hurd sources). > > Once we have argp, it makes sense to implement both getopt-long and > getopt in terms of it. > I'm familiar with argp, it seems to have a fiar bit of conceptual complexity overhead though. > BTW, my convention has been to use the (gnu ...) packages as Scheme > equivalents of C header files on a GNU system. So (gnu argp) contains > the stuff that would be in , (gnu errno) does , etc. > I would much rather see the module hierarchy organized by functional category than by where it comes from. Indeed, the (gnu) prefix is espcailly bad becasue other systems may well have the same header files shipped with their libcs. I think (getopt std), (getopt long) and possibly (getopt argp) would be better module names (although the last is a bit more questionable). Incidentally, will GUSH-related work that is more generally useful be passed back up to Guile? I'm still not sure what GUSH does exactly, so I don't know how much will be in this area, but from the vague things I've heard GUSH is implementing things that other Guile apps will likely want too. - Maciej (BTW why would Guile apps be interested in the quivalent of errno.h? I'm not objecting to it (yet) nor do I know if you are proposing it as something useful, but it seems to me that in most cases a Guile app can't tell if another libary call has happened between the syscall you care about and when you return, thus making the contents of errno unspecified according to ANSI C.) From owner-scwm-discuss@mit.edu Tue Oct 6 15:43:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA25973 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:43:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA25969 for ; Tue, 6 Oct 1998 15:43:56 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA01520; Tue, 6 Oct 98 15:43:59 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 06 Oct 1998 15:43:16 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 06 Oct 1998 15:43:15 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id PAA28940; Tue, 6 Oct 1998 15:43:55 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: <199810061909.PAA25026@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 15:09:53 EDT" Date: 06 Oct 1998 15:43:55 -0400 Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810061909.PAA25026@huis-clos.mit.edu> >>>> Sent on Tue, 06 Oct 1998 15:09:53 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: scwm/scwm -> scwm/src": >> > Come on! Just cheat: search and replace `scwm' with `src' in the *right >> > places* in the CVS tree. This is not MSjunk, after all, all files are >> > plain text. >> >> I don't like the idea of falsifying old revisions; what can go wrong? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Hard work has a future payoff. Laziness pays off NOW. From owner-scwm-discuss@mit.edu Tue Oct 6 15:52:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA26219 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:52:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA26208; Tue, 6 Oct 1998 15:52:14 -0400 Message-Id: <199810061952.PAA26208@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "06 Oct 1998 12:33:44 PDT." Date: Tue, 06 Oct 1998 15:52:04 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > perry@piermont.com writes: > > > > > > The ugly way we do this in NetBSD is as follows: > > > > > > 1) physically copy the ,v files in the repository to the new location. > > > 2) remove all tags from the copied ,v files > > > 3) cvs rm the old file locations. > > > > > > This allows you to check out an old branch and still maintain revision > > > history on the moved files. It is ugly as sin but works. > > > > > > > OK, that works for me. I'll try to do this ASAP. > > Sounds good to me too-- this is the same as my suggestion with the > addition of step 2, removing the tags from the src/*,v files, right? > Still has the size-blowup problem, but not the extra work at check-out > of old versions problem. > Revision control is a size vs. sanity tradeoff anyway :-) Plus I think being able to skip Attic/ when copying should help somewhat. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 15:58:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA26330 for scwm-discuss-outgoing; Tue, 6 Oct 1998 15:58:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA26322; Tue, 6 Oct 1998 15:58:18 -0400 Message-Id: <199810061958.PAA26322@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src In-reply-to: Your message of "06 Oct 1998 15:43:55 EDT." Date: Tue, 06 Oct 1998 15:58:18 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199810061909.PAA25026@huis-clos.mit.edu> > >>>> Sent on Tue, 06 Oct 1998 15:09:53 EDT > >>>> Honorable Maciej Stachowiak writes > >>>> on the subject of "Re: scwm/scwm -> scwm/src": > >> > Come on! Just cheat: search and replace `scwm' with `src' in the *right > >> > places* in the CVS tree. This is not MSjunk, after all, all files are > >> > plain text. > >> > >> I don't like the idea of falsifying old revisions; > > what can go wrong? > I want old versions to be reproducable _exactly_ from the repository. That's kind of the point of version control. I like Perry's suggestion better, I think it is about as clean as we can get given the constraints of CVS. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 16:03:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26419 for scwm-discuss-outgoing; Tue, 6 Oct 1998 16:03:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26415 for ; Tue, 6 Oct 1998 16:03:04 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA08620; Tue, 6 Oct 98 16:03:07 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 06 Oct 1998 16:02:24 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 06 Oct 1998 16:02:24 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id QAA29067; Tue, 6 Oct 1998 16:03:03 -0400 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: scwm-mode References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "06 Oct 1998 12:26:22 -0700" Date: 06 Oct 1998 16:03:03 -0400 Message-Id: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> Sent on 06 Oct 1998 12:26:22 -0700 >>>> Honorable Greg Badros writes >>>> on the subject of "scwm-mode [was Re: scwm/scwm -> scwm/src]": >> Hey, welcome back! thanks! >> I had a thought about scwm-mode while you were away. It'd be nice to >> have a silly heuristic in the evaluating of scwm sexps that tried to >> reset scwm-obarray to nil (so that it gets re-initialized) any time a >> define is evaluated (thus introducing a new possible completion). >> >> The problem is that, if I evaluate >> >> (define (foo-bar-baz) >> ..... >> ) >> >> any time after the first time I do a completion (which is when the >> scwm-obarray gets initialized), I won't be able to complete to >> foo-bar-baz. I'm willing to live with a conservative (overly-stupid) >> approximation that just resets the obarray to nil whenever a "([ >> \t]*\\(define\\|use-modules\\|load\>)" is in an expression sent to scwm. If all >> the macros/procedures that do a define start with "define" this should >> work reasonably well. (And when it's broken, one can always reset it by >> hand-- I'd just like to reduce the frequency of doing so). done. also, any command which does completion (like `scwm-documentation', `scwm-goto-guile-procedure-node', `scwm-complete-symbol-insert'), when called with a prefix argument, resets `scwm-obarray'. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Microsoft: announce yesterday, code today, think tomorrow. From owner-scwm-discuss@mit.edu Tue Oct 6 16:09:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26590 for scwm-discuss-outgoing; Tue, 6 Oct 1998 16:09:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26587 for ; Tue, 6 Oct 1998 16:09:14 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA11053; Tue, 6 Oct 98 16:09:17 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA17306; Tue, 6 Oct 1998 13:09:09 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: scwm-mode References: From: Greg Badros Date: 06 Oct 1998 13:09:09 -0700 In-Reply-To: Sam Steingold's message of "06 Oct 1998 16:03:03 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> The problem is that, if I evaluate > >> > >> (define (foo-bar-baz) > >> ..... > >> ) > >> > >> any time after the first time I do a completion (which is when the > >> scwm-obarray gets initialized), I won't be able to complete to > >> foo-bar-baz. I'm willing to live with a conservative (overly-stupid) > >> approximation that just resets the obarray to nil whenever a "([ > >> \t]*\\(define\\|use-modules\\|load\>)" is in an expression sent to scwm. If all > >> the macros/procedures that do a define start with "define" this should > >> work reasonably well. (And when it's broken, one can always reset it by > >> hand-- I'd just like to reduce the frequency of doing so). > > done. > > also, any command which does completion (like `scwm-documentation', > `scwm-goto-guile-procedure-node', `scwm-complete-symbol-insert'), when > called with a prefix argument, resets `scwm-obarray'. Great-- thanks! (That was fast!) Greg From owner-scwm-discuss@mit.edu Tue Oct 6 16:10:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26622 for scwm-discuss-outgoing; Tue, 6 Oct 1998 16:10:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26619 for ; Tue, 6 Oct 1998 16:10:21 -0400 Received: from lord.banki.hu by MIT.EDU with SMTP id AA24288; Tue, 6 Oct 98 16:10:14 EDT Received: (qmail 9518 invoked by uid 5002); 6 Oct 1998 20:10:17 -0000 Date: Tue, 6 Oct 1998 22:10:16 +0200 From: Janos Farkas To: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src Message-Id: Mail-Followup-To: scwm-discuss@mit.edu References: <199810061844.OAA26138@jekyll.piermont.com> <199810061917.PAA25229@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.94.3i In-Reply-To: <199810061917.PAA25229@huis-clos.mit.edu>; from Maciej Stachowiak on Tue, Oct 06, 1998 at 03:17:43PM -0400 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 1998-10-06 at 15:17:43, Maciej Stachowiak wrote: > perry@piermont.com writes: > > The ugly way we do this in NetBSD is as follows: > > > > 1) physically copy the ,v files in the repository to the new location. > > 2) remove all tags from the copied ,v files > > 3) cvs rm the old file locations. > > > > This allows you to check out an old branch and still maintain revision > > history on the moved files. It is ugly as sin but works. > OK, that works for me. I'll try to do this ASAP. Aha! What would happen if even the time stamps are massaged for the ,v files in the new place? (I.e. set to a "flag-day" stamp.) That way, a checkout for a previous date won't get older files, but revision history would be available only for version numbers (which might be the real goal). Of course if it really works at all.. :) -- Janos - Don't worry, my address is real. I'm just bored of spam. From owner-scwm-discuss@mit.edu Tue Oct 6 16:11:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA26643 for scwm-discuss-outgoing; Tue, 6 Oct 1998 16:11:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA26640 for ; Tue, 6 Oct 1998 16:11:18 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA11784; Tue, 6 Oct 98 16:11:19 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 06 Oct 1998 16:10:36 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 06 Oct 1998 16:10:36 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id QAA29105; Tue, 6 Oct 1998 16:11:15 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm/scwm -> scwm/src References: <199810061958.PAA26322@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 15:58:18 EDT" Date: 06 Oct 1998 16:11:15 -0400 Message-Id: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810061958.PAA26322@huis-clos.mit.edu> >>>> Sent on Tue, 06 Oct 1998 15:58:18 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: scwm/scwm -> scwm/src": >> sds@goems.com writes: >> > >>>> In message <199810061909.PAA25026@huis-clos.mit.edu> >> > >>>> Sent on Tue, 06 Oct 1998 15:09:53 EDT >> > >>>> Honorable Maciej Stachowiak writes >> > >>>> on the subject of "Re: scwm/scwm -> scwm/src": >> > >> > Come on! Just cheat: search and replace `scwm' with `src' in the *right >> > >> > places* in the CVS tree. This is not MSjunk, after all, all files are >> > >> > plain text. >> > >> >> > >> I don't like the idea of falsifying old revisions; >> > >> > what can go wrong? >> > >> >> I want old versions to be reproducable _exactly_ from the >> repository. That's kind of the point of version control. The old versions will be reproducible exactly, but they will reside in scwm/src, not scwm/scwm. Again, I want to fool CVS into thinking that scwm/scwm was scwm/src from the creation of the universe. what's wrong with that? Note that cvs 1.10 has a *bad* bug in diff -N: is keeps mentioning removed files long after the time specified in -D has passed. Your solution with massive removals doesn't bode well for those who rely on diff. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. MS DOS: Keyboard not found. Press F1 to continue. From owner-scwm-discuss@mit.edu Tue Oct 6 17:19:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27464 for scwm-discuss-outgoing; Tue, 6 Oct 1998 17:19:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA27459 for ; Tue, 6 Oct 1998 17:19:37 -0400 Received: from talisker.channelpoint.com by MIT.EDU with SMTP id AA18964; Tue, 6 Oct 98 17:19:29 EDT Received: by channelpoint.com (SMI-8.6/SMI-SVR4) id PAA01893; Tue, 6 Oct 1998 15:19:32 -0600 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: perforce (was Re: scwm/scwm -> scwm/src) References: <199810061751.NAA23708@huis-clos.mit.edu> From: Sam Falkner Date: 06 Oct 1998 15:19:30 -600 In-Reply-To: Maciej Stachowiak's message of "Tue, 06 Oct 1998 13:51:27 EDT" Message-Id: Lines: 53 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > [ . . . ] > I really wish CVS properly supported renames... just to throw in a wrinkle, i believe that perforce (www.perforce.com) allows unlimited use of their source control product, provided you're `doing free stuff'. i'm pretty sure we'd qualify. i know that a rather large project in the perl community uses perforce, and i'd love to see scwm switch to it (even though i've been too bogged down at work to do any work on scwm so far ;-( ). i'm good friends with brian berliner, the original author of CVS. when i rolled out perforce into the place where we work, he off-handedly described it as `CVS done right', but don't quote either one of us on that! perforce's look-and-feel is an awful lot like CVS. you have one command-line command (p4), and lots of subcommands (e.g. `p4 edit ', do some work, and `p4 submit' will putback your changes to the server). i don't work for perforce; i'm just a happy customer. my sales pitch follows: it's very easy to set up. one daemon executable for the server, and one command-line client. they probably have scripts for auto-importing the existing RCS (CVS) stuff. it runs on many, many platforms. just about every unix i can think of, at least, as well as many non-unix things. i'm not sure how it compares to CVS, or if this would be at issue. it's transaction based. one thing that scares me about doing stuff with CVS, especially `over the internet', is that a putback can be partially completed. e.g. if a kitten pulls the power cord on your machine just as you're putting back a big change to scwm, it gets partially completed. with perforce, this won't happen; it's all or nothing. of course, it *does* properly support renames. :-) many other nice things, but i'm running too long. if you want, i can check further into getting an unlimited license for the machine where the current CVS server runs. i'd urge you to look at perforce's online docs at their website (www.perforce.com), and look at the available platforms. comments? - sam From owner-scwm-discuss@mit.edu Tue Oct 6 17:41:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27737 for scwm-discuss-outgoing; Tue, 6 Oct 1998 17:41:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA27730; Tue, 6 Oct 1998 17:41:10 -0400 Message-Id: <199810062141.RAA27730@huis-clos.mit.edu> To: Sam Falkner cc: scwm-discuss@mit.edu Subject: Re: perforce (was Re: scwm/scwm -> scwm/src) In-reply-to: Your message of "06 Oct 1998 15:19:30." Date: Tue, 06 Oct 1998 17:41:10 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk samf@channelpoint.com writes: > Maciej Stachowiak writes: > > > [ . . . ] > > > I really wish CVS properly supported renames... > > just to throw in a wrinkle, i believe that perforce (www.perforce.com) > allows unlimited use of their source control product, provided you're > `doing free stuff'. i'm pretty sure we'd qualify. i know that a > rather large project in the perl community uses perforce, and i'd love > to see scwm switch to it (even though i've been too bogged down at > work to do any work on scwm so far ;-( ). > Perforce sounds like a great product, from what you describe below, but I'd rather not use non-free tools for a free software project when free alternatives exist. I'm already embarassed to be using hypermail, but I didn't know about MHonArc at the time. And I'm hoping the GNU ssh clone is ready soon, since the ssh license continues to get less free... I know not all people agree with this attitude, but that's just my personal ethics. I might look into getting it for work, though, the revision control setup we have here is a pathetic kludge. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 6 19:27:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA29174 for scwm-discuss-outgoing; Tue, 6 Oct 1998 19:27:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA29171 for ; Tue, 6 Oct 1998 19:27:01 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22354; Tue, 6 Oct 98 19:26:52 EDT Received: (qmail 8317 invoked by uid 501); 6 Oct 1998 23:26:56 -0000 Message-Id: <19981006162654.A8273@molehill.org> Date: Tue, 6 Oct 1998 16:26:54 -0700 From: Todd Larason To: scwm-discuss list Subject: module & more menu checkin done Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Hah! I've got that animal pegged!" Tom specified. Sender: owner-scwm-discuss@mit.edu Precedence: bulk To use XPM menus, you'll need to add (use-modules (app scwm xpm-menus)) To a limited but useful extent, menulooks can be inherited: (define tekno-menu-look (copy-menu-look xpm-shaped-menu-look "tekno" (xpm-menu-decor-tekno))) and the global default setting works like the other menu settings - any menu created without an explicit menulook will use the default at the time it's popped up (before, it used the default at the time it was created). (menu) has a new tag #:menu-look for setting a particular menu's look. I have a collection of KDE themes and an scwm interface for them at http://fecundity.webcoi.com/~jtl/scwm_themes.tar.gz. The (xpm-menu-decor-tekno) function is defined there. Maybe this (and the screen shot I posted earlier) should move to the scwm website sometime. From owner-scwm-discuss@mit.edu Tue Oct 6 23:06:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA30305 for scwm-discuss-outgoing; Tue, 6 Oct 1998 23:06:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA30299 for ; Tue, 6 Oct 1998 23:05:52 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA05054; Tue, 6 Oct 98 23:05:43 EDT Received: (qmail 16305 invoked by uid 501); 7 Oct 1998 03:05:45 -0000 Message-Id: <19981006200544.A14290@molehill.org> Date: Tue, 6 Oct 1998 20:05:44 -0700 From: Todd Larason To: mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: can't find Guile? References: <6514.199810061603@penelope.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <6514.199810061603@penelope.ecs.soton.ac.uk>; from Mark Toller on Tue, Oct 06, 1998 at 05:03:55PM +0100 X-Tom-Swifty: "Boy, will I give YOU a haircut!" said Tom barbarously. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981006, Mark Toller wrote: > configure: error: Can not find Guile 1.2 or later on the system > > > Guile is installed in /usr/local, and I've tried the --with-guile > options... I just checked in a change that I think will fix this; configure wasn't properly looking in the guile binary directory set with --with-guile. From owner-scwm-discuss@mit.edu Wed Oct 7 00:14:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA30667 for scwm-discuss-outgoing; Wed, 7 Oct 1998 00:14:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from itchy.serv.net (itchy.serv.net [205.153.153.233]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id AAA30664 for ; Wed, 7 Oct 1998 00:14:11 -0400 Received: from localhost (utz@localhost) by itchy.serv.net (8.8.5/8.8.5) with SMTP id VAA28716 for ; Tue, 6 Oct 1998 21:14:09 -0700 (PDT) Date: Tue, 6 Oct 1998 21:14:08 -0700 (PDT) From: John Utz To: scwm-discuss@mit.edu Subject: scwm-0.8a is defeating me :-( Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk hi; i am attempting to build scwm-0.8a, actually it builds with out a hitch, but it wont *run*. i have the latest guile-core snapshot as reccomended in the docs but i keep getting this error on startup: spaz@john$ scwm ld.so failed: Undefined symbol "_rl_completion_entry_function" in scwm:/usr/local/lib/libguile.so.3.0 now the offwending code is in libuile/readline.c as near as i can figure. if i comment out the line that ld is bitching about, it just announcews that it can find the next function in the code :-( this is on a x86 machine running freebsd 2.2.7-RELEASE please cc to me as opposed to just replying to the list, i am not currently subscribed. tnx! john From owner-scwm-discuss@mit.edu Wed Oct 7 02:44:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA31651 for scwm-discuss-outgoing; Wed, 7 Oct 1998 02:44:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA31648 for ; Wed, 7 Oct 1998 02:44:05 -0400 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA09918; Wed, 7 Oct 98 02:43:55 EDT Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id IAA00807; Wed, 7 Oct 1998 08:43:42 +0200 (MET DST) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id IAA06186; Wed, 7 Oct 1998 08:43:26 +0200 (MET DST) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13851.3469.936769.341417@chl> Date: Wed, 7 Oct 1998 08:43:25 +0200 (MET DST) To: Maciej Stachowiak Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: 0.9 release timing, branch In-Reply-To: <199810061528.LAA21998@huis-clos.mit.edu> References: <19981006010732.A24879@molehill.org> <199810061528.LAA21998@huis-clos.mit.edu> X-Mailer: VM 6.59 under Emacs 20.2.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: Maciej> ... it's pretty hard to merge from the trunk to a branch in Maciej> CVS from what I hear. Not in my experience, but of course it depends to some degree on what has happened on the trunk and on the branch. If you are working on branch A and want to update your sandbox to include some delta from the trunk, this could be done as: cvs update -j REL_0_8 -j REL_0_9 provided the trunk has some suitable tags to work on. Merging from the head of the trunk (rather than a specific delta) may be trickier, but then one can always just generate a diff and run patch by hand. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Wed Oct 7 03:29:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA31885 for scwm-discuss-outgoing; Wed, 7 Oct 1998 03:29:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA31882 for ; Wed, 7 Oct 1998 03:29:51 -0400 Received: from mail.ivm.net by MIT.EDU with SMTP id AA14446; Wed, 7 Oct 98 03:29:45 EDT Received: from debian (port9.bn.ivm.de [195.247.226.9]) by aw.ivm.net (8.8.8/8.8.8) with ESMTP id JAA01263; Wed, 7 Oct 1998 09:29:37 +0200 X-To: scwm-discuss@mit.edu Received: by debian id m0zQl73-000TO7C (Debian Smail-3.2 1996-Jul-4 #2); Wed, 7 Oct 1998 06:22:09 +0200 (MET DST) Message-Id: Date: Wed, 7 Oct 1998 06:22:09 +0200 (MET DST) From: Klaus Schilling Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Progress on using FvwmButtons (and some questions) In-Reply-To: References: <199810061619.MAA22545@huis-clos.mit.edu> X-Mailer: VM 6.38 under Emacs 20.2.1 Reply-To: Klaus.Schilling@home.ivm.de Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > > scwm-discuss about avoiding bugs where a long/int is used where an SCM > was meant to be used -- inspired by a hard-to-find bug in Scwm due to > SCM being typedefed to long> > > Maciej Stachowiak writes: > > > Not all SCMs are actually pointers, characters and integers up to 30 > > bits are stored directly in that word, with a type tag. One could come > > up with an assertion based on the possible values of the type tags, > > but this would be pretty complicated. Is that the difference between IMP and NIMP that has to be observed when writing typechecks for wrapper code? > > Which is why we have abstractions like macros and functions. From a > quick look at tags.h, it looks as though the valid SCM values are sparse > enough and well-defined enough that perhaps a macro for validating SCMs > could be written. Then asserting the validity of all SCMs at function > calls in a debug build might help catch some errors dynamically. > Obviously I'd prefer a solution that got us this statically, but it > sounds like that would require more pervasive changes to guile. How is it solved in other scheme implementations? Klaus schilling From owner-scwm-discuss@mit.edu Wed Oct 7 03:39:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA00022 for scwm-discuss-outgoing; Wed, 7 Oct 1998 03:39:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA00016 for ; Wed, 7 Oct 1998 03:39:01 -0400 Received: from smtp7.nwnexus.com by MIT.EDU with SMTP id AA08517; Wed, 7 Oct 98 03:39:06 EDT Received: from pulsar.halcyon.com (chinook.halcyon.com [198.137.231.20]) by smtp7.nwnexus.com (8.8.8/8.8.8) with ESMTP id AAA22780 for ; Wed, 7 Oct 1998 00:38:47 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276516-15622>; Tue, 6 Oct 1998 22:45:22 -0700 To: scwm-discuss@mit.edu Subject: pronuciation Date: Tue, 06 Oct 1998 22:45:17 -0600 From: Ken Pizzini Message-Id: <19981007054522Z276516-15622+57@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sorry for this somewhat irrelevant question, but for some reason this question has been nagging at me for some time now... Is there a "proper" pronunciation for "scwm"? I tend to pronounce it basically as "squim". (Actually, for the benefit of those like Greg who are familiar with Washington place names, I actually pronounce it identically to the way that the town of Sequim is pronounced, which to my ear is subtly different; though I cannot quite say how, as the phoneme difference that I imagine hearing is not one that is actually distinguished in the English language. [Just as I imagine that I hear a whisper of a difference between the pronuciation of "f" and "ph" in words like "fear" and "pheasant", but I ramble...]) --Ken Pizzini From owner-scwm-discuss@mit.edu Wed Oct 7 04:31:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA00473 for scwm-discuss-outgoing; Wed, 7 Oct 1998 04:31:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA00470 for ; Wed, 7 Oct 1998 04:31:27 -0400 Received: from [152.78.71.3] by MIT.EDU with SMTP id AA19296; Wed, 7 Oct 98 04:31:20 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id JAA09808 for ; Wed, 7 Oct 1998 09:28:11 +0100 (BST) Message-Id: <1407.199810070830@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Wed, 7 Oct 1998 09:30:13 +0100 Date: Wed, 7 Oct 1998 09:30:42 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Re: can't find Guile? To: scwm-discuss@mit.edu In-Reply-To: <19981006200544.A14290@molehill.org> Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 6 Oct, Todd Larason wrote: > On 981006, Mark Toller wrote: >> configure: error: Can not find Guile 1.2 or later on the system >> >> >> Guile is installed in /usr/local, and I've tried the --with-guile >> options... > Hmm, it appears from the config.log file that ./configure wasn't linking -lreadline... Mark. From owner-scwm-discuss@mit.edu Wed Oct 7 09:17:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA01706 for scwm-discuss-outgoing; Wed, 7 Oct 1998 09:17:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA01700 for ; Wed, 7 Oct 1998 09:16:56 -0400 Received: from enst.enst.fr by MIT.EDU with SMTP id AA24583; Wed, 7 Oct 98 09:16:48 EDT Received: from ZengHe.augustin.thierry (IDENT:root@zenghe.enst.fr [137.194.192.39]) by enst.enst.fr (8.9.1a/8.9.1) with ESMTP id PAA18067; Wed, 7 Oct 1998 15:16:29 +0200 (MET DST) Received: (from fare@localhost) by ZengHe.augustin.thierry (8.8.7/) id LAA20288; Wed, 7 Oct 1998 11:50:37 +0200 Message-Id: <19981007115035.A20191@ZengHe.enst.fr> Date: Wed, 7 Oct 1998 11:50:35 +0200 From: Francois-Rene Rideau To: jtl@molehill.org, scwm-discuss@mit.edu Subject: Tom Lord's ctool Reply-To: Francois-Rene Rideau References: <19981005224135.A24229@molehill.org> <199810061516.LAA21773@huis-clos.mit.edu> <19981006190137.A16703@ZengHe.issy.cnet.fr> <19981006182023.A8641@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: <19981006182023.A8641@molehill.org>; from Todd Larason on Tue, Oct 06, 1998 at 06:20:23PM -0700 X-Mime-Autoconverted: from 8bit to quoted-printable by enst.enst.fr id PAA18067 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id JAA01701 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, Oct 06, 1998 at 06:20:23PM -0700, Todd Larason wrote: > On 981006, Francois-Rene Rideau wrote: >> Hum. Looks like ctool is no longer available by FTP. > > It was included in the first (only?) issue of ~twaddle, Tom Lord's > electronic magazine. Maybe someone has a copy lying around somewhere? Yes, ~twaddle is where I got it from, but it's no more available from Tord Lord's FTP site. I have kept my copy that I can redistribute, but Tom Lord is definitely the person to contact if we are to use ctool. ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## Life is like an onion: you peel off layer after layer, then you find there is nothing in it. From owner-scwm-discuss@mit.edu Wed Oct 7 09:19:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA01717 for scwm-discuss-outgoing; Wed, 7 Oct 1998 09:19:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA01714 for ; Wed, 7 Oct 1998 09:19:04 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA19541; Wed, 7 Oct 98 09:19:04 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id OAA14889 for ; Wed, 7 Oct 1998 14:15:57 +0100 (BST) Message-Id: <2788.199810071317@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Wed, 7 Oct 1998 14:17:59 +0100 Date: Wed, 7 Oct 1998 14:18:28 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: cvs update, followed by? To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I'm still having problems with the latest scwm... after doing a 'cvs update', I used to do 'aclocal; autoconf; automake'. a) Is this the correct thing to do. b) If not, what shoulf I do to make sure all changes are correctly setup. With the latest cvs scwm, I get :- [mst95r@pyro scwm]# automake configure.in: 470: required file `utilities/dev/scwmdoc.in' not found configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found and ./configure has the following errors... [snip] creating modules/Makefile sed: can't read ./modules/Makefile.in: No such file or directory creating modules/xpm-menus/Makefile sed: can't read ./modules/xpm-menus/Makefile.in: No such file or directory [snip] creating include/config.h cat: ./include/config.h.in: No such file or directory D'oH! I'm reduced to using fvwm2 :-( b.t.w It does now detect guile correctly :) Cheers, Mark. From owner-scwm-discuss@mit.edu Wed Oct 7 10:21:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02443 for scwm-discuss-outgoing; Wed, 7 Oct 1998 10:21:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02435; Wed, 7 Oct 1998 10:21:08 -0400 Message-Id: <199810071421.KAA02435@huis-clos.mit.edu> To: Ken Pizzini cc: scwm-discuss@mit.edu Subject: Re: pronuciation In-reply-to: Your message of "Tue, 06 Oct 1998 22:45:17 MDT." <19981007054522Z276516-15622+57@pulsar.halcyon.com> Date: Wed, 07 Oct 1998 10:21:08 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk ken@halcyon.com writes: > Sorry for this somewhat irrelevant question, but for some reason > this question has been nagging at me for some time now... > > Is there a "proper" pronunciation for "scwm"? I tend to pronounce it > basically as "squim". > That's how I pronounce it, and that's the pronounciation I originally intended. Some people spell it out ([ess see double-you em]), I have no real objection to that either. I was thinking of making a scwm FAQ at some point with this question on it. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 7 10:25:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02548 for scwm-discuss-outgoing; Wed, 7 Oct 1998 10:25:02 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02538; Wed, 7 Oct 1998 10:25:00 -0400 Message-Id: <199810071425.KAA02538@huis-clos.mit.edu> To: mst95r@ecs.soton.ac.uk cc: scwm-discuss@mit.edu Subject: Re: can't find Guile? In-reply-to: Your message of "Wed, 07 Oct 1998 09:30:42 BST." <1407.199810070830@penelope.ecs.soton.ac.uk> Date: Wed, 07 Oct 1998 10:25:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mst95r@ecs.soton.ac.uk writes: > On 6 Oct, Todd Larason wrote: > > On 981006, Mark Toller wrote: > >> configure: error: Can not find Guile 1.2 or later on the system > >> > >> > >> Guile is installed in /usr/local, and I've tried the --with-guile > >> options... > > > > Hmm, it appears from the config.log file that ./configure wasn't > linking -lreadline... > Yes, that is just a symptom, though. The real problem was that it was not finding the right Guile configuration program, which caused it to try to configure Guile the "old style" way, which doesn't check for libreadline because Guile didn't used to have readline support. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 7 10:29:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02626 for scwm-discuss-outgoing; Wed, 7 Oct 1998 10:29:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02619; Wed, 7 Oct 1998 10:29:16 -0400 Message-Id: <199810071429.KAA02619@huis-clos.mit.edu> To: mst95r@ecs.soton.ac.uk cc: scwm-discuss@mit.edu Subject: Re: cvs update, followed by? In-reply-to: Your message of "Wed, 07 Oct 1998 14:18:28 BST." <2788.199810071317@penelope.ecs.soton.ac.uk> Date: Wed, 07 Oct 1998 10:29:16 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mst95r@ecs.soton.ac.uk writes: > Hi, > > I'm still having problems with the latest scwm... after doing a > 'cvs update', I used to do 'aclocal; autoconf; automake'. > > a) Is this the correct thing to do. Almost. > b) If not, what shoulf I do to make sure all changes are correctly > setup. do `cvs update -dP' instead. Also, you don't have to run the auto* commands by hand, `./autogen.sh' in the scwm top-level directory should do the trick. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 7 10:48:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA02984 for scwm-discuss-outgoing; Wed, 7 Oct 1998 10:48:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA02981 for ; Wed, 7 Oct 1998 10:48:01 -0400 Received: from TEQUILA.SYSTEMSZ.CS.YALE.EDU by MIT.EDU with SMTP id AA25513; Wed, 7 Oct 98 10:47:55 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.systemsz.cs.yale.edu (8.8.7/8.8.7) with SMTP id KAA24482 for ; Wed, 7 Oct 1998 10:47:59 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: 0.9 release timing, branch References: <19981006010732.A24879@molehill.org> <199810061528.LAA21998@huis-clos.mit.edu> <13851.3469.936769.341417@chl> Date: 07 Oct 1998 10:47:53 -0400 Message-Id: <5l7lyce8di.fsf@tequila.systemsz.cs.yale.edu> Lines: 12 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.systemsz.cs.yale.edu Nntp-Posting-Host: tequila.systemsz.cs.yale.edu X-Trace: 7 Oct 1998 10:47:53 -0500, tequila.systemsz.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Christian" == Christian Lynbech writes: > Merging from the head of the trunk (rather than a specific delta) may doesn't `cvs update -j REJ_0_8 -j HEAD' do exactly that ? > be trickier, but then one can always just generate a diff and run > patch by hand. YUCK ! Stefan From owner-scwm-discuss@mit.edu Wed Oct 7 11:06:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA03193 for scwm-discuss-outgoing; Wed, 7 Oct 1998 11:06:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA03190 for ; Wed, 7 Oct 1998 11:06:34 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA28533; Wed, 7 Oct 98 11:06:30 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA00042; Wed, 7 Oct 1998 08:06:19 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: pronuciation References: <19981007054522Z276516-15622+57@pulsar.halcyon.com> From: Greg Badros Date: 07 Oct 1998 08:06:19 -0700 In-Reply-To: Ken Pizzini's message of "Tue, 06 Oct 1998 22:45:17 -0600" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > Sorry for this somewhat irrelevant question, but for some reason > this question has been nagging at me for some time now... > > Is there a "proper" pronunciation for "scwm"? I tend to pronounce it > basically as "squim". I do the same. > (Actually, for the benefit of those like Greg who are familiar > with Washington place names, I actually pronounce it identically to > the way that the town of Sequim is pronounced, which to my ear is I never could figure out why that gets pronounced as it does! :-) Greg From owner-scwm-discuss@mit.edu Wed Oct 7 13:00:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA03823 for scwm-discuss-outgoing; Wed, 7 Oct 1998 13:00:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA03820 for ; Wed, 7 Oct 1998 13:00:07 -0400 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA11000; Wed, 7 Oct 98 13:00:01 EDT Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id KAA00465; Wed, 7 Oct 1998 10:00:05 -0700 (PDT) Date: Wed, 7 Oct 1998 10:00:05 -0700 (PDT) From: Jeffrey Nichols To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: cvs update, followed by? In-Reply-To: <199810071429.KAA02619@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, 7 Oct 1998, Maciej Stachowiak wrote: > > mst95r@ecs.soton.ac.uk writes: > > Hi, > > > > I'm still having problems with the latest scwm... after doing a > > 'cvs update', I used to do 'aclocal; autoconf; automake'. > > > > a) Is this the correct thing to do. > > Almost. > > > b) If not, what shoulf I do to make sure all changes are correctly > > setup. > > do `cvs update -dP' instead. Also, you don't have to run the auto* > commands by hand, `./autogen.sh' in the scwm top-level directory > should do the trick. After using the above cvs update command, I still get the following messages when I try to run autogen.sh: configure.in: 470: required file `utilities/dev/scwmdoc.in' not found configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found -Jeff From owner-scwm-discuss@mit.edu Wed Oct 7 14:25:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA04273 for scwm-discuss-outgoing; Wed, 7 Oct 1998 14:25:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA04255; Wed, 7 Oct 1998 14:24:56 -0400 Message-Id: <199810071824.OAA04255@huis-clos.mit.edu> To: Jeffrey Nichols cc: scwm-discuss@mit.edu Subject: Re: cvs update, followed by? In-reply-to: Your message of "Wed, 07 Oct 1998 10:00:05 PDT." Date: Wed, 07 Oct 1998 14:24:56 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jwnichls@cs.washington.edu writes: > On Wed, 7 Oct 1998, Maciej Stachowiak wrote: > > > > > mst95r@ecs.soton.ac.uk writes: > > > Hi, > > > > > > I'm still having problems with the latest scwm... after doing a > > > 'cvs update', I used to do 'aclocal; autoconf; automake'. > > > > > > a) Is this the correct thing to do. > > > > Almost. > > > > > b) If not, what shoulf I do to make sure all changes are correctly > > > setup. > > > > do `cvs update -dP' instead. Also, you don't have to run the auto* > > commands by hand, `./autogen.sh' in the scwm top-level directory > > should do the trick. > > After using the above cvs update command, I still get the > following messages when I try to run autogen.sh: > > configure.in: 470: required file `utilities/dev/scwmdoc.in' not found > configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found > Oh yeah, I forgot. These are spurious error messages caused by a bug in automake. This is mentioned in HACKING. You can safely ignore them. The next automake test release should fix those, and we should probably upgrade at that point. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 7 14:34:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA04348 for scwm-discuss-outgoing; Wed, 7 Oct 1998 14:34:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA04345 for ; Wed, 7 Oct 1998 14:34:20 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA18662; Wed, 7 Oct 98 14:34:11 EDT Received: (qmail 32499 invoked by uid 501); 7 Oct 1998 18:05:29 -0000 Message-Id: <19981007110528.A32462@molehill.org> Date: Wed, 7 Oct 1998 11:05:28 -0700 From: Todd Larason To: Jeffrey Nichols , Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: cvs update, followed by? References: <199810071429.KAA02619@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jeffrey Nichols on Wed, Oct 07, 1998 at 10:00:05AM -0700 X-Tom-Swifty: "I hate bloody French", Tom sang. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981007, Jeffrey Nichols wrote: > After using the above cvs update command, I still get the > following messages when I try to run autogen.sh: > > configure.in: 470: required file `utilities/dev/scwmdoc.in' not found > configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found This is a bug in the released version of either autoconf or automake; the error message is wrong, and everything is fine. For the 0.9 release, autogen should probably have a note that the errors are ignorable. From owner-scwm-discuss@mit.edu Wed Oct 7 17:14:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA05726 for scwm-discuss-outgoing; Wed, 7 Oct 1998 17:14:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA05723 for ; Wed, 7 Oct 1998 17:14:07 -0400 Received: from [209.43.2.137] by MIT.EDU with SMTP id AA20920; Wed, 7 Oct 98 14:23:34 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id NAA13276; Wed, 7 Oct 1998 13:20:13 -0500 To: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Progress on using FvwmButtons (and some questions) References: <199810061619.MAA22545@huis-clos.mit.edu> From: Jim Blandy Date: 07 Oct 1998 13:20:12 -0500 In-Reply-To: Klaus Schilling's message of Wed, 7 Oct 1998 06:22:09 +0200 (MET DST) Message-Id: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > > scwm-discuss about avoiding bugs where a long/int is used where an SCM > > was meant to be used -- inspired by a hard-to-find bug in Scwm due to > > SCM being typedefed to long> One possibility I'm considering (after 1.3) is making SCM be a pointer to a struct which is never defined, and then changing all the accessor macros to cast it to something appropriate. The intent here would be to catch these errors at compile time; there's not a lot you can do with a pointer to an incomplete type. If someone else volunteers to do this, it'll get done sooner. :) From owner-scwm-discuss@mit.edu Wed Oct 7 18:36:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA06277 for scwm-discuss-outgoing; Wed, 7 Oct 1998 18:36:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA06274 for ; Wed, 7 Oct 1998 18:36:36 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA26565; Wed, 7 Oct 98 18:36:40 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA02995; Wed, 7 Oct 1998 15:36:32 -0700 (PDT) To: Maciej Stachowiak Cc: Jeffrey Nichols , scwm-discuss@mit.edu Subject: Re: cvs update, followed by? References: <199810071824.OAA04255@huis-clos.mit.edu> From: Greg Badros Date: 07 Oct 1998 15:36:32 -0700 In-Reply-To: Maciej Stachowiak's message of "Wed, 07 Oct 1998 14:24:56 EDT" Message-Id: Lines: 11 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Oh yeah, I forgot. These are spurious error messages caused by a bug > in automake. This is mentioned in HACKING. You can safely ignore them. > The next automake test release should fix those, and we should > probably upgrade at that point. Are you sure you have your HACKING checked in? I don't see it in my HACKING file (just updated, too). Greg From owner-scwm-discuss@mit.edu Wed Oct 7 19:12:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06567 for scwm-discuss-outgoing; Wed, 7 Oct 1998 19:12:29 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06561 for ; Wed, 7 Oct 1998 19:12:27 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA05996; Wed, 7 Oct 98 19:12:19 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06551; Wed, 7 Oct 1998 19:12:23 -0400 Message-Id: <199810072312.TAA06551@huis-clos.mit.edu> To: Greg Badros Cc: Jeffrey Nichols , scwm-discuss@mit.edu Subject: Re: cvs update, followed by? In-Reply-To: Your message of "07 Oct 1998 15:36:32 PDT." Date: Wed, 07 Oct 1998 19:12:22 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Oh yeah, I forgot. These are spurious error messages caused by a bug > > in automake. This is mentioned in HACKING. You can safely ignore them. > > The next automake test release should fix those, and we should > > probably upgrade at that point. > > Are you sure you have your HACKING checked in? I don't see it in my > HACKING file (just updated, too). > Hmm, it doesn't seem to have the message, I could have sworn I inlcuded it. Will fix shortly. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 7 19:29:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06840 for scwm-discuss-outgoing; Wed, 7 Oct 1998 19:29:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06837 for ; Wed, 7 Oct 1998 19:29:52 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA09680; Wed, 7 Oct 98 19:29:45 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA04182; Wed, 7 Oct 1998 16:29:47 -0700 (PDT) To: scwm-discuss@mit.edu Cc: Todd Larason Subject: dynamic loading and libtool breaks c++ scwm builds From: Greg Badros Date: 07 Oct 1998 16:29:46 -0700 Message-Id: Lines: 27 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk The recent changes to support dynamic loading cause libtool to run with "-export-dynamic" which ends up creating a scwmS.c file listing all of the symbols, including the C++ symbols, as type "extern char". One of those symbols, __throw_type_match_rtti, causes an error when scwmS.c is attempted to be compiled: scwmS.c:642: `char __throw_type_match_rtti' redeclared as different kind of symbol :642: previous declaration of `void * __throw_type_match_rtti(const void *, const void *, void *)' It seems as though -export-dynamic is not handling the C++ code properly. In particular, it doesn't seem to make sense that all the mangled C++ symbol names be included inside an extern "C" declaration. Is anybody enough of a libtool guru to know what we need to do differently to make things work with egcs-1.1b and the C++ code (i.e., if you configure with the constraint solver using --with-cassowary=/path/to/cass/source)? There doesn't appear to be a new libtool, and the info page is rather short on information about dynamic loading of C++ functions. Incidentally, the quick fix if you don't care about dynamic linking support is to report the "-export-dynamic" option from the generated Makefile. Thanks, Greg From owner-scwm-discuss@mit.edu Wed Oct 7 20:03:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07323 for scwm-discuss-outgoing; Wed, 7 Oct 1998 20:03:13 -0400 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA07319 for ; Wed, 7 Oct 1998 20:03:10 -0400 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA15981; Wed, 7 Oct 98 20:03:03 EDT Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id UAA01731 for ; Wed, 7 Oct 1998 20:10:35 -0400 (EDT) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id UAA04714 for ; Wed, 7 Oct 1998 20:03:05 -0400 (EDT) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with SMTP id UAA22029 for ; Wed, 7 Oct 1998 20:03:44 -0400 (EDT) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Wed, 7 Oct 1998 20:03:44 -0400 (EDT) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: modules/xpm-menus Makefile Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi everyone, I just got a CVS update of today's changes and had trouble building the new modules/xpm-menus code. Not all of the include directories are available when compiling in that directory. The simple fix seems to be changing INCLUDES in Makefile.am to INCLUDES = -I$(top_srcdir)/scwm @x_cflags@ @GUILE_INCLUDES@ @CASSOWARY_INCLUDES@ so that all of the include directories are in the compilation command. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Oct 7 20:33:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07592 for scwm-discuss-outgoing; Wed, 7 Oct 1998 20:33:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA07589 for ; Wed, 7 Oct 1998 20:33:51 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA24017; Wed, 7 Oct 98 20:33:54 EDT Received: (qmail 2428 invoked by uid 501); 8 Oct 1998 00:33:46 -0000 Message-Id: <19981007173344.A2242@molehill.org> Date: Wed, 7 Oct 1998 17:33:44 -0700 From: Todd Larason To: Greg Badros , scwm-discuss@mit.edu Cc: automake@gnu.org Subject: Re: dynamic loading and libtool breaks c++ scwm builds References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Oct 07, 1998 at 04:29:46PM -0700 X-Tom-Swifty: "Look what I can do with this eraser!" said Mickey Mouse self- effacingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I don't know of and can't find a libtool mailing list, so I'm taking the librety of sending it to the automake list, as the tools are closely related and libtool is discussed there. On 981007, Greg Badros wrote: > The recent changes to support dynamic loading cause libtool to run with > "-export-dynamic" which ends up creating a scwmS.c file listing all of > the symbols, including the C++ symbols, as type "extern char". One of > those symbols, __throw_type_match_rtti, causes an error when scwmS.c is > attempted to be compiled: > > scwmS.c:642: `char __throw_type_match_rtti' redeclared as different kind of symbol > :642: previous declaration of `void * __throw_type_match_rtti(const void *, const void *, void *)' ^^^^^^^^^^ A smarter compiler is confusing it. > It seems as though -export-dynamic is not handling the C++ code > properly. In particular, it doesn't seem to make sense that all the > mangled C++ symbol names be included inside an extern "C" declaration. As I understand it, it's building a table of name->address mappings for dld to use, and the mangled names are what it wants. The extern "C" is to keep them from getting mangled more, and isn't normally a problem because no headers are included in xxxS.c. But the compiler you're using has internal type information for that symbol. I don't think this table is actually needed for systems that aren't using dld, so I'm not sure why it's being built for you (I'm assuming you're on a fairly modern Linux system, with dlopen et al?). First thoughts: o disable dynamic loading for cassowary builds o hack libtool to ignore this symbol and any other egcs internals o fix libtool to not build the dld symboltable if it's not needed From owner-scwm-discuss@mit.edu Wed Oct 7 21:38:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08231 for scwm-discuss-outgoing; Wed, 7 Oct 1998 21:38:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA08228 for ; Wed, 7 Oct 1998 21:38:03 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA07263; Wed, 7 Oct 98 21:38:06 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA04614; Wed, 7 Oct 1998 18:37:54 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu, automake@gnu.org Subject: Re: dynamic loading and libtool breaks c++ scwm builds References: <19981007173344.A2242@molehill.org> From: Greg Badros Date: 07 Oct 1998 18:37:54 -0700 In-Reply-To: Todd Larason's message of "Wed, 7 Oct 1998 17:33:44 -0700" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > First thoughts: > o disable dynamic loading for cassowary builds Do we have a configure option to do this? > o hack libtool to ignore this symbol and any other egcs internals > o fix libtool to not build the dld symboltable if it's not needed These'd be for the libtool folks.... :-) Thanks... please keep me updated... Greg From owner-scwm-discuss@mit.edu Wed Oct 7 22:13:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA08479 for scwm-discuss-outgoing; Wed, 7 Oct 1998 22:13:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA08476 for ; Wed, 7 Oct 1998 22:13:12 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA14333; Wed, 7 Oct 98 22:13:13 EDT Received: (qmail 2933 invoked by uid 501); 8 Oct 1998 02:13:07 -0000 Message-Id: <19981007191306.A2906@molehill.org> Date: Wed, 7 Oct 1998 19:13:06 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu, automake@gnu.org Subject: Re: dynamic loading and libtool breaks c++ scwm builds References: <19981007173344.A2242@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Oct 07, 1998 at 06:37:54PM -0700 X-Tom-Swifty: "Those bullets can't hurt me", said Tom blankly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981007, Greg Badros wrote: > Todd Larason writes: > > > First thoughts: > > o disable dynamic loading for cassowary builds > > Do we have a configure option to do this? I think --disable-shared should do it, but doesn't now (because of the explicit -export-dynamic) 'NM=/bin/true ./configure yadda yadda' is an ugly but decent workaround. Dynamic loading will still work even; this just breaks libtool's ability to create the dld_preload table, which it handles gracefully. From owner-scwm-discuss@mit.edu Thu Oct 8 05:57:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA11317 for scwm-discuss-outgoing; Thu, 8 Oct 1998 05:57:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA11314 for ; Thu, 8 Oct 1998 05:57:13 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA04151; Thu, 8 Oct 98 05:57:06 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id KAA00160 for ; Thu, 8 Oct 1998 10:54:36 +0100 (BST) Message-Id: <4933.199810080956@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Thu, 8 Oct 1998 10:56:38 +0100 Date: Thu, 8 Oct 1998 10:57:07 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: cvs problem ? To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Doing a cvs update -dP i get :- cvs update: cannot open CVS/Entries for reading: No such file or directory cvs [update aborted]: cannot open CVS/Entries.Log: No such file or directory ./configure reports two problems :- creating modules/Makefile sed: can't read ./modules/Makefile.in: No such file or directory creating modules/xpm-menus/Makefile sed: can't read ./modules/xpm-menus/Makefile.in: No such file or directory and make crashes out on the modules directory... Basically, there's only Makefiles in the modules directory - modules/Makefile modules/xpm-menu/Makefile and thats it.... Maybe because cvs update hasn't got everything ( I know cvs checkout originally bombed - our network is terrible at the mo' ) Cheers, Mark. From owner-scwm-discuss@mit.edu Thu Oct 8 06:23:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA11518 for scwm-discuss-outgoing; Thu, 8 Oct 1998 06:23:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA11515 for ; Thu, 8 Oct 1998 06:23:00 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA06283; Thu, 8 Oct 98 06:22:52 EDT Received: (qmail 4969 invoked by uid 501); 8 Oct 1998 10:23:12 -0000 Message-Id: <19981008032310.A4908@molehill.org> Date: Thu, 8 Oct 1998 03:23:10 -0700 From: Todd Larason To: mst95r@ecs.soton.ac.uk, scwm-discuss@mit.edu Subject: Re: cvs problem ? References: <4933.199810080956@penelope.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <4933.199810080956@penelope.ecs.soton.ac.uk>; from Mark Toller on Thu, Oct 08, 1998 at 10:57:07AM +0100 X-Tom-Swifty: "I don't want a second helping, thank you", said the cannibal manfully. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981008, Mark Toller wrote: > Hi, > > Doing a cvs update -dP i get :- > > cvs update: cannot open CVS/Entries for reading: No such file or directory That's a file that should be in your local sandbox. It being missing is a sign of local trouble, I think. Are you in the right directory? If so, you may need to do another checkout. > Basically, there's only Makefiles in the modules directory - > > modules/Makefile > modules/xpm-menu/Makefile Those were created by the failing configure. There should be Makefile.am files in both, a ChangeLog in modules, and draw-xpm-menus.c in xpm-menu. I've just verified that these are in the anonymous cvs repository. Could you try a fresh checkout and see if that fixes it? From owner-scwm-discuss@mit.edu Thu Oct 8 07:44:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id HAA11877 for scwm-discuss-outgoing; Thu, 8 Oct 1998 07:44:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id HAA11874 for ; Thu, 8 Oct 1998 07:44:17 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA13421; Thu, 8 Oct 98 07:43:50 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id MAA01950 for ; Thu, 8 Oct 1998 12:41:22 +0100 (BST) Message-Id: <18356.199810081143@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Thu, 8 Oct 1998 12:43:23 +0100 Date: Thu, 8 Oct 1998 12:43:53 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: cvs checkout solved probs :) To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Ahh, it seems my local copy of SCWM was dodgy - a fresh checkout has solved the problems! OK, I've been playing around with the menus etc, sorting out what I want to launch from menus, and what I launch from xterms... Generally, any program that I run to view or edit a file (vim, ghostview, latex etc) I run from an xterm, and give the file name as an argument. Now, going back through the mails, I found the info on the cut-buffer :- (X-property-get 'root-window "CUT_BUFFER0") Is there a way in SCWM to have a menu item that launches an application with the current xselection as it's argument - i.e. select the URL/filename from an xterm, and then select the app from the menu ? Thanks, Mark. From owner-scwm-discuss@mit.edu Thu Oct 8 09:15:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA12268 for scwm-discuss-outgoing; Thu, 8 Oct 1998 09:15:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA12265 for ; Thu, 8 Oct 1998 09:15:39 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA01454; Thu, 8 Oct 98 09:15:35 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Thu, 08 Oct 1998 09:15:09 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Thu, 08 Oct 1998 09:15:08 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id JAA07246; Thu, 8 Oct 1998 09:15:29 -0400 To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <18356.199810081143@penelope.ecs.soton.ac.uk> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Mark Toller's message of "Thu, 8 Oct 1998 12:43:53 +0100 (GMT)" Date: 08 Oct 1998 09:15:29 -0400 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <18356.199810081143@penelope.ecs.soton.ac.uk> >>>> Sent on Thu, 8 Oct 1998 12:43:53 +0100 (GMT) >>>> Honorable Mark Toller writes >>>> on the subject of "cvs checkout solved probs :)": >> >> Is there a way in SCWM to have a menu item that launches an application >> with the current xselection as it's argument - i.e. select the >> URL/filename from an xterm, and then select the app from the menu ? (bind-key 'all "H-w" netscape-goto-cut-buffer-url) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. An elephant is a mouse with an operating system. From owner-scwm-discuss@mit.edu Thu Oct 8 11:02:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA12978 for scwm-discuss-outgoing; Thu, 8 Oct 1998 11:02:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA12975 for ; Thu, 8 Oct 1998 11:02:15 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA07049; Thu, 8 Oct 98 11:02:11 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA06658; Thu, 8 Oct 1998 08:01:44 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <18356.199810081143@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 08 Oct 1998 08:01:44 -0700 In-Reply-To: Mark Toller's message of "Thu, 8 Oct 1998 12:43:53 +0100 (GMT)" Message-Id: Lines: 35 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Hi, > > Ahh, it seems my local copy of SCWM was dodgy - a fresh checkout has > solved the problems! > > OK, I've been playing around with the menus etc, sorting out what I > want to launch from menus, and what I launch from xterms... Generally, > any program that I run to view or edit a file (vim, ghostview, latex > etc) I run from an xterm, and give the file name as an argument. Now, > going back through the mails, I found the info on the cut-buffer :- > > (X-property-get 'root-window "CUT_BUFFER0") And note that if you are just interested in the string, you can use the wrapper `X-cut-buffer-string' from module (app scwm flux). > Is there a way in SCWM to have a menu item that launches an application > with the current xselection as it's argument - i.e. select the > URL/filename from an xterm, and then select the app from the menu ? Sure, just make the menuitem do something like this: (menu (list ... (menuitem "Launch Xterm on Host named in Cut Buffer" #:action (lambda () (execute (string-append "xterm " (X-cut-buffer-string))))) .... )) Greg From owner-scwm-discuss@mit.edu Thu Oct 8 11:35:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA13424 for scwm-discuss-outgoing; Thu, 8 Oct 1998 11:35:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA13421 for ; Thu, 8 Oct 1998 11:35:05 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA18807; Thu, 8 Oct 98 11:35:00 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA06897; Thu, 8 Oct 1998 08:34:48 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu, automake@gnu.org Subject: Re: dynamic loading and libtool breaks c++ scwm builds References: <19981007173344.A2242@molehill.org> <19981007191306.A2906@molehill.org> From: Greg Badros Date: 08 Oct 1998 08:34:48 -0700 In-Reply-To: Todd Larason's message of "Wed, 7 Oct 1998 19:13:06 -0700" Message-Id: Lines: 30 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981007, Greg Badros wrote: > > Todd Larason writes: > > > > > First thoughts: > > > o disable dynamic loading for cassowary builds > > > > Do we have a configure option to do this? > > I think --disable-shared should do it, but doesn't now (because of the > explicit -export-dynamic) > > 'NM=/bin/true ./configure yadda yadda' is an ugly but decent workaround. > Dynamic loading will still work even; this just breaks libtool's ability > to create the dld_preload table, which it handles gracefully. Changing libtool's global_symbol_pipe variable to include: grep -v rtti | before the sed command makes the link go through for me. I'm not sure what the "right" excluded symbols should be. My guess is it should either just exclude the one symbol that causes problems, or should exclude all the C++ symbols. BTW, setting the NM var in configure's environment didn't propagate into the libtool NM variable. Greg From owner-scwm-discuss@mit.edu Thu Oct 8 21:24:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA17553 for scwm-discuss-outgoing; Thu, 8 Oct 1998 21:24:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mtiwmhc03.worldnet.att.net (mtiwmhc03.worldnet.att.net [204.127.131.38]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id VAA17550 for ; Thu, 8 Oct 1998 21:24:45 -0400 Received: from brownie.esc.net.worldnet.att.net ([153.37.236.196]) by mtiwmhc03.worldnet.att.net (InterMail v03.02.03 118 118 102) with SMTP id <19981009012442.XIM14150@brownie.esc.net.worldnet.att.net> for ; Fri, 9 Oct 1998 01:24:42 +0000 To: scwm-discuss@mit.edu Subject: scwm documentation trouble X-Face: =zxax\[Gy>RMztF.q3%oOWhwg\venL7mcj)hIi^@p!HA XC:8.(XKL{9e+u8q-C$7vIrC:ri61H'6{xdMQ5<{wxTbM.8#v*7FL>8dy?cJ?Wgi%],n$+mZzGv'%V A|;b%qb2Aw&[3'j*9OM!&JG$ea5af+gFX Date: 08 Oct 1998 21:28:49 -0400 Message-ID: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello fellow scwm users! The sample .scwmrc files in the distribution are a great help for me to try to figure out how to configure scwm, but I'd like more documentation. I've tried making something viewable from the scwm.sgml file included with scwm-0.8a, but the sgmltools like sgml2latex don't seem to work on the file (RedHat 5.1 Linux). I get lots of lines like: /usr/bin/nsgmls:0:240:15:E: element "REFPURPOSE" undefined and then finally: /usr/bin/nsgmls:I: maximum number of errors (200) reached; change with -E option The scwm.sgml file in the scwm CVS server looks nice and big! How can I generate a PostScript file of this? Thanks in advance! From owner-scwm-discuss@mit.edu Thu Oct 8 23:07:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA18247 for scwm-discuss-outgoing; Thu, 8 Oct 1998 23:07:33 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA18244 for ; Thu, 8 Oct 1998 23:07:06 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22941; Thu, 8 Oct 98 23:06:53 EDT Received: (qmail 10810 invoked by uid 501); 9 Oct 1998 03:06:54 -0000 Message-Id: <19981008200654.A10729@molehill.org> Date: Thu, 8 Oct 1998 20:06:54 -0700 From: Todd Larason To: Eric Crampton , scwm-discuss@mit.edu Subject: Re: scwm documentation trouble References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Eric Crampton on Thu, Oct 08, 1998 at 09:28:49PM -0400 X-Tom-Swifty: "I failed my electrocardiogram", said Tom faint-heartedly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981008, Eric Crampton wrote: > I've tried making something viewable from the scwm.sgml file included > with scwm-0.8a, but the sgmltools like sgml2latex don't seem to work > on the file (RedHat 5.1 Linux). I get lots of lines like: > > /usr/bin/nsgmls:0:240:15:E: element "REFPURPOSE" undefined I expect there was an error before that about not being able to find a Docbook DTD? The old Linux 'sgmltools' was poorly named - it was for a particular SGML document type. > The scwm.sgml file in the scwm CVS server looks nice and big! How can > I generate a PostScript file of this? I don't know about PostScript, but I finally managed to get html built today. I made lots of false starts, but what I did that I think is relevant is, on a RedHat 5.1 system: went to ftp://ftp.cygnus.com/pub/home/rosalia/docware/SRPMS/ and downloaded all the SRPMS there, except jadetex. Compiled them, installed the psgml, stylesheets, docbook, sgml-common and and jade packages created. export SGML_CATALOG_FILES=/usr/lib/sgml/CATALOG export DOCBOOK_HOME=/usr/lib/sgml/stylesheets/nwalsh-modular Download a precompiled jade from Greg Badros and put it in my ~/bin directory, which is before /usr/bin in my PATH cd scwm/doc; make html and away it went. The jade binary from the RPM coredumps without giving any good output. Obviously, this isn't as straightforward as it should be. I can make this jade available if it isn't still on Greg's ftp site. From owner-scwm-discuss@mit.edu Fri Oct 9 00:41:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA18885 for scwm-discuss-outgoing; Fri, 9 Oct 1998 00:41:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA18882 for ; Fri, 9 Oct 1998 00:41:53 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA08258; Fri, 9 Oct 98 00:41:51 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA20953; Thu, 8 Oct 1998 21:41:46 -0700 (PDT) To: Todd Larason Cc: Eric Crampton , scwm-discuss@mit.edu Subject: Re: scwm documentation trouble References: <19981008200654.A10729@molehill.org> From: Greg Badros Date: 08 Oct 1998 21:41:45 -0700 In-Reply-To: Todd Larason's message of "Thu, 8 Oct 1998 20:06:54 -0700" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981008, Eric Crampton wrote: > > I've tried making something viewable from the scwm.sgml file included > > with scwm-0.8a, but the sgmltools like sgml2latex don't seem to work > > on the file (RedHat 5.1 Linux). I get lots of lines like: > > > > /usr/bin/nsgmls:0:240:15:E: element "REFPURPOSE" undefined > > I expect there was an error before that about not being able to find > a Docbook DTD? The old Linux 'sgmltools' was poorly named - it was > for a particular SGML document type. Yep. sgmltools 1.1 is supposed to deal w/ DocBook (and possibly have the full generality of handling any DTD), but the version you, Eric, are using is probably insufficient. > I can make this jade available if it isn't still on Greg's ftp site. I believe it's still there. ftp.cs.washington.edu:/homes/gjb Greg From owner-scwm-discuss@mit.edu Fri Oct 9 04:19:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA21610 for scwm-discuss-outgoing; Fri, 9 Oct 1998 04:19:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA21607 for ; Fri, 9 Oct 1998 04:19:09 -0400 From: mal@bewoner.dma.be Received: from dialup315.brussels.skynet.be by MIT.EDU with SMTP id AA04101; Fri, 9 Oct 98 04:19:01 EDT Received: (qmail 29771 invoked by uid 500); 9 Oct 1998 08:45:06 -0000 Date: 9 Oct 1998 08:45:05 -0000 Message-Id: <19981009084505.29758.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: patch for installation scwm-icons-19981008 X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk The install failed for me. This should work better. diff -r -c scwm-icons-19981008-changed/icons/Makefile.in scwm-icons-19981008/icons/Makefile.in *** scwm-icons-19981008-changed/icons/Makefile.in Fri Oct 9 10:02:13 1998 --- scwm-icons-19981008/icons/Makefile.in Sat Nov 29 23:30:45 1997 *************** *** 24,35 **** depend: ! install: $(mkinstalldirs) ${pixmap_dir} ! for i in *.xpm; \ ! do \ ! ${INSTALL_DATA} $$i ${pixmap_dir}; \ ! done mostlyclean: ${RM} *~ core *.bak --- 24,32 ---- depend: ! install: *.xpm $(mkinstalldirs) ${pixmap_dir} ! ${INSTALL_DATA} *.xpm ${pixmap_dir} mostlyclean: ${RM} *~ core *.bak diff -r -c scwm-icons-19981008-changed/mini-icons/Makefile.in scwm-icons-19981008/mini-icons/Makefile.in *** scwm-icons-19981008-changed/mini-icons/Makefile.in Fri Oct 9 10:10:01 1998 --- scwm-icons-19981008/mini-icons/Makefile.in Sat Nov 29 23:31:32 1997 *************** *** 23,34 **** depend: ! install: $(mkinstalldirs) ${mini_icon_dir} ! for i in *.xpm; \ ! do \ ! ${INSTALL_DATA} $$i ${mini_icon_dir}; \ ! done mostlyclean: ${RM} *~ core *.bak --- 23,31 ---- depend: ! install: *.xpm $(mkinstalldirs) ${mini_icon_dir} ! ${INSTALL_DATA} *.xpm ${mini_icon_dir} mostlyclean: ${RM} *~ core *.bak From owner-scwm-discuss@mit.edu Fri Oct 9 05:25:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA22054 for scwm-discuss-outgoing; Fri, 9 Oct 1998 05:25:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA22051 for ; Fri, 9 Oct 1998 05:25:03 -0400 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Fri, 9 Oct 1998 10:24:44 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 25; Fri, 09 Oct 1998 10:24:26 GMT Date: Fri, 09 Oct 1998 10:24:25 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CD6F7.73C129AE.25@hermes.dra.hmg.gb> Subject: Gnome Pager applet for scwm Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am playing round with a little pager applet for Gnome/scwm. I am using scwmexec, and have it working with buttons which swap desktops, much in the spirit of icewm_pager, on which it is based. This much has been easy, but is not very useful yet. What I would like to do is add a pager window for current desktop. This obviously needs two way non-blocking communication, in much the same way as the Fvwm modules. The modules communicate over pipes, but as far as I know you can only use pipes between a process and its descendents; I am not aware of any method of setting up pipes between pre-existing processes. Instead I have chosen sockets. This has a (possibly) useful side effect; the pager need not be running on the same node as the wm. (I cannot think of a case where that would actually be useful, but somebody will use it). The scenario I am trying to implement goes like this. pager applet starts, and uses scwmexec protocol to contact window manager, and negotiate network address and port that the wm will listen on. the pager connects to the wm, and uses a hacked version of fvwm-module.scm to set up the hooks that are needed. As this is my pager, it is going to speak and understand scheme syntax, simplifying the code and side stepping all worries about endianess. Now for my problems. The first step (using scwmexec) needs to tell scwm to wait for a connection, (i.e to wait on accept), AFTER completing the scwmexec interaction. I can see how I might do this using threads, but I don't think that will integrate nicely into the rest of scwm. Presumably I need to set up something like an input hook, to get the socket fitted into scwm's event loop. A more minor point; I thought it would be cute to change the background of different desktops. Is there a change-desk hook to implement this with? Sorry to ask two unrelated questions in one mail. Julian Satchell From owner-scwm-discuss@mit.edu Fri Oct 9 05:29:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA22095 for scwm-discuss-outgoing; Fri, 9 Oct 1998 05:29:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA22092 for ; Fri, 9 Oct 1998 05:29:30 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA08692; Fri, 9 Oct 98 05:29:25 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id KAA16110 for ; Fri, 9 Oct 1998 10:26:53 +0100 (BST) Message-Id: <16679.199810090928@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Fri, 9 Oct 1998 10:28:54 +0100 Date: Fri, 9 Oct 1998 18:34:59 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Re: cvs checkout solved probs :) To: scwm-discuss@mit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk [snip] > And note that if you are just interested in the string, you can use the > wrapper `X-cut-buffer-string' from module (app scwm flux). > >> Is there a way in SCWM to have a menu item that launches an application >> with the current xselection as it's argument - i.e. select the >> URL/filename from an xterm, and then select the app from the menu ? > > Sure, just make the menuitem do something like this: > > (menu (list > ... > (menuitem "Launch Xterm on Host named in Cut Buffer" > #:action > (lambda () (execute (string-append "xterm " (X-cut-buffer-string))))) > .... > )) Exellent, what I have now is :- (define (command-on-buffer arg) (let* ((command-name (string-append arg " " (X-cut-buffer-string)))) (execute command-name))) so that I can do :- (menuitem "Xterm on Cut Buffer" #:action (lambda () (command-on-buffer "xterm -e rlogin"))) and (menuitem "Ghostview" #:action (lambda () (command-on-buffer "ghostview"))) OK, how about dynamic menus? i.e. some way of viewing the cut buffer in the menu item, and it changing as the cut buffer changes? Also, how about a history list off these, with the last few files opened from these menus? Obviously the problem with these is that the cut buffer could be lots of plain text, rather than a filename - anyway of testing if the cut buffer represents a file rather than text? Cheers, Mark. From owner-scwm-discuss@mit.edu Fri Oct 9 05:50:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA22359 for scwm-discuss-outgoing; Fri, 9 Oct 1998 05:50:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA22356 for ; Fri, 9 Oct 1998 05:50:14 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15359; Fri, 9 Oct 98 05:50:09 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id LAA27166; Fri, 9 Oct 1998 11:50:02 +0200 To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <16679.199810090928@penelope.ecs.soton.ac.uk> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 09 Oct 1998 11:50:02 +0200 In-Reply-To: Mark Toller's message of "Fri, 9 Oct 1998 18:34:59 +0100 (GMT)" Message-Id: Lines: 57 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Exellent, what I have now is :- > > (define (command-on-buffer arg) > (let* ((command-name > (string-append arg " " (X-cut-buffer-string)))) > (execute command-name))) > > so that I can do :- > > (menuitem "Xterm on Cut Buffer" #:action (lambda () > (command-on-buffer "xterm -e rlogin"))) > > and > > (menuitem "Ghostview" #:action (lambda () (command-on-buffer "ghostview"))) > > > OK, how about dynamic menus? i.e. some way of viewing the cut buffer > in the menu item, and it changing as the cut buffer changes? Also, how > about a history list off these, with the last few files opened from > these menus? Depends what you want. It'd be problematic to update it while the menu is up, but you can rebuild your menus before poping them up. For example, I have: (define util-menu (menu (list (menuitem "Utilities" #f) menu-title ...))) (define (popup-util) (popup-menu util-menu)) (bind-mouse 'root 1 popup-util) You could easily change that to: (define (generate-new-util-menu) (menu (list (menuitem (X-cut-buffer-string) #:action ...) ...))) (define (reset-util-menu) (set! util-menu (generate-new-util-menu))) (define (popup-util) (reset-util-menu) (popup-menu util-menu)) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Oct 9 05:52:00 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA22385 for scwm-discuss-outgoing; Fri, 9 Oct 1998 05:52:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA22382 for ; Fri, 9 Oct 1998 05:51:59 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA15487; Fri, 9 Oct 98 05:51:57 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id KAA16447 for ; Fri, 9 Oct 1998 10:49:19 +0100 (BST) Message-Id: <19414.199810090951@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Fri, 9 Oct 1998 10:51:21 +0100 Date: Fri, 9 Oct 1998 18:57:26 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: Rhosts in Flux.scm? To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I was browsing through flux.scm, and saw the code for readig the .rhosts file - I can get this to work using scwmrepl by cutting and pasting, but would like it in my .scwmrc under the utils menu, something like :- (menuitem "Remote Login" #:action rhosts-menu) but this doesn't work. I presume it's something to do with both rhosts-menu and make-rhosts-menu not being 'define-public', but just 'define' ? Playing around with it has crashed scwm a couple of times :-( Any ideas? Mark. From owner-scwm-discuss@mit.edu Fri Oct 9 05:58:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA22461 for scwm-discuss-outgoing; Fri, 9 Oct 1998 05:58:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA22458 for ; Fri, 9 Oct 1998 05:58:57 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA10508; Fri, 9 Oct 98 05:58:53 EDT Received: (qmail 2162 invoked by uid 501); 9 Oct 1998 10:00:15 -0000 Message-Id: <19981009030015.A2085@molehill.org> Date: Fri, 9 Oct 1998 03:00:15 -0700 From: Todd Larason To: "merry::satchell"@hermes.dra.hmg.gb, scwm-discuss@mit.edu Subject: Re: Gnome Pager applet for scwm References: <009CD6F7.73C129AE.25@hermes.dra.hmg.gb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <009CD6F7.73C129AE.25@hermes.dra.hmg.gb>; from "merry::satchell"@hermes.dra.hmg.gb on Fri, Oct 09, 1998 at 10:24:25AM +0000 X-Tom-Swifty: "I caught two hares", said Tom abrasively. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981009, "merry::satchell"@hermes.dra.hmg.gb wrote: > I am playing round with a little pager applet for Gnome/scwm. Great! > I am not aware of any method of setting up pipes between > pre-existing processes. There are named pipes that could be used, but there's no obvious advantage over a socket. > A more minor point; I thought it would be cute to change the background of > different desktops. Is there a change-desk hook to implement this with? > Sorry to ask two unrelated questions in one mail. I'm afraid this is the only part I can really help with. There's no hook explicitely for this, but you could hook into the broadcast_hook and watch for broadcasts of event type M_NEW_DESK (2). From owner-scwm-discuss@mit.edu Fri Oct 9 10:27:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA24145 for scwm-discuss-outgoing; Fri, 9 Oct 1998 10:27:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA24141 for ; Fri, 9 Oct 1998 10:27:01 -0400 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Fri, 9 Oct 1998 15:12:24 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 118; Fri, 09 Oct 1998 15:10:25 GMT Date: Fri, 09 Oct 1998 15:10:20 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CD71F.650F148E.118@hermes.dra.hmg.gb> Subject: Giving each desk its own background. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have worked out how to get a different background for each desk. I just redefined set-current-desk! to do my stuff as well. For example (define primitive-set-desk! set-current-desk!) (define desk-back-comms #( "xsetroot -solid cyan4" "xv -root -quit /home/satchell/kde_themes/Factory/gears.jpg" "xearth -once")) (define set-current-desk! (lambda(n) ;; (display n) (newline) ;; for debugging (primitive-set-desk! n) (system (vector-ref desk-back-comms n)) )) xearth -once is marginal; it noticeably slows the desk switch on a 266MHz Pentium II machine. Really big JPEGs might also be be a hassle. Solid colours (or even colors) are probably fine. This seems to interact with the pager code correctly, at least when using the Fvwm_pager. Julian Satchell From owner-scwm-discuss@mit.edu Fri Oct 9 10:59:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA24453 for scwm-discuss-outgoing; Fri, 9 Oct 1998 10:59:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA24449 for ; Fri, 9 Oct 1998 10:59:36 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA10228; Fri, 9 Oct 98 10:59:32 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA24914; Fri, 9 Oct 1998 07:59:26 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Rhosts in Flux.scm? References: <19414.199810090951@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 09 Oct 1998 07:59:25 -0700 In-Reply-To: Mark Toller's message of "Fri, 9 Oct 1998 18:57:26 +0100 (GMT)" Message-Id: Lines: 10 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Playing around with it has crashed scwm a couple of times :-( Can you send in a full bug report, please? We can't do anything w/o knowing more information. (See BUG-REPORTING for details on how to be most helpful.) Thanks, Greg From owner-scwm-discuss@mit.edu Fri Oct 9 11:51:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24875 for scwm-discuss-outgoing; Fri, 9 Oct 1998 11:51:06 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA24872 for ; Fri, 9 Oct 1998 11:51:03 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA27130; Fri, 9 Oct 98 11:51:00 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA25035; Fri, 9 Oct 1998 08:50:33 -0700 (PDT) To: "merry::satchell"@hermes.dra.hmg.gb Cc: scwm-discuss@mit.edu Subject: Re: Giving each desk its own background. References: <009CD71F.650F148E.118@hermes.dra.hmg.gb> From: Greg Badros Date: 09 Oct 1998 08:50:33 -0700 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Fri, 09 Oct 1998 15:10:20 GMT" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > I have worked out how to get a different background for each desk. > I just redefined set-current-desk! to do my stuff as well. For example We should definitely get an advice-like mechanism for Scwm. This pattern has come up before. For this, we may want to add a hook, anyway. > (define primitive-set-desk! set-current-desk!) > (define desk-back-comms > #( > "xsetroot -solid cyan4" > "xv -root -quit /home/satchell/kde_themes/Factory/gears.jpg" > "xearth -once")) > > (define set-current-desk! (lambda(n) > ;; (display n) (newline) ;; for debugging > (primitive-set-desk! n) > (system (vector-ref desk-back-comms n)) > )) > xearth -once is marginal; it noticeably slows the desk switch on a 266MHz > Pentium II machine. Really big JPEGs might also be be a hassle. Solid colours > (or even colors) are probably fine. This seems to interact with the pager > code correctly, at least when using the Fvwm_pager. We could add a primitive that copies an image onto the root window. This would save an exec and a read of the image file (so that the file is read only once, when the image object is created). Greg From owner-scwm-discuss@mit.edu Fri Oct 9 11:52:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24888 for scwm-discuss-outgoing; Fri, 9 Oct 1998 11:52:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24876; Fri, 9 Oct 1998 11:51:52 -0400 Message-Id: <199810091551.LAA24876@huis-clos.mit.edu> To: "merry::satchell"@hermes.dra.hmg.gb cc: scwm-discuss@mit.edu Subject: Re: Gnome Pager applet for scwm In-reply-to: Your message of "Fri, 09 Oct 1998 10:24:25 GMT." <009CD6F7.73C129AE.25@hermes.dra.hmg.gb> Date: Fri, 09 Oct 1998 11:51:52 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > I am playing round with a little pager applet for Gnome/scwm. I am using > scwmexec, and have it working with buttons which swap desktops, much in the > spirit of icewm_pager, on which it is based. This much has been easy, but is > not very useful yet. What I would like to do is add a pager window for current > desktop. This obviously needs two way non-blocking communication, in much > the same way as the Fvwm modules. The modules communicate over pipes, > but as far as I know you can only use pipes between a process and its > descendents; I am not aware of any method of setting up pipes between > pre-existing processes. Instead I have chosen sockets. This has a (possibly) > useful side effect; the pager need not be running on the same node > as the wm. (I cannot think of a case where that would actually be useful, > but somebody will use it). > > The scenario I am trying to implement goes like this. > > pager applet starts, and uses scwmexec protocol to contact window manager, > and negotiate network address and port that the wm will listen on. > > the pager connects to the wm, and uses a hacked version of fvwm-module.scm > to set up the hooks that are needed. As this is my pager, it is going to speak > and understand scheme syntax, simplifying the code and side stepping all > worries about endianess. > > Now for my problems. The first step (using scwmexec) needs to tell scwm to wait > for a connection, (i.e to wait on accept), AFTER completing the scwmexec > interaction. I can see how I might do this using threads, but I don't > think that will integrate nicely into the rest of scwm. Presumably I need > to set up something like an input hook, to get the socket fitted into > scwm's event loop. Actually, a listening socket has the nice property that if you select() on it for input, select() will mark it as ready for input when it is ready to be accep()ed on. However, I'm thinking this whole socket negotiation thing might be a bit over-complicated. How about using the scwmexec protocol for command requests from the application, and for asynchronous notification from the app, establish a hook via scwmexec that sets a relevant property on the app window using X-property-set! (does that work on window IDs?). The app would then select on PropertyChange events in its event loop. I am not sure if this is practical though, especially for your intended application. BTW, I think scwm is trying to support some of the Gnome hints that let the icewm pager work, but obviously a native pager would be cooler. I would be especially psyched if it were possible to get this pager to run it outside the Gnome panel, and even more so if it were possible to build it against Gtk only, perhaps with a compile time option (I support Gnome and am an occasional developer thereof, but it requires too many possibly unstable packages for most users right now). In fact, if you get something nice going I'd be willing to ship it with scwm (although shipping it with Gnome may be better). I do still want to try to write a pager in the scwmrc language using guile-gtk at some point, but this external program approach is the "tried and true" way of doing it. > > A more minor point; I thought it would be cute to change the background of > different desktops. Is there a change-desk hook to implement this with? > Sorry to ask two unrelated questions in one mail. > I don't think so, but there should be. Actually, one of the broadcast-*-notify hook messages is a change of current desktop, but that is an ugly API for anything but the fvwm module stuff to use. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 9 12:04:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25123 for scwm-discuss-outgoing; Fri, 9 Oct 1998 12:04:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25112; Fri, 9 Oct 1998 12:04:31 -0400 Message-Id: <199810091604.MAA25112@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Giving each desk its own background. In-reply-to: Your message of "09 Oct 1998 08:50:33 PDT." Date: Fri, 09 Oct 1998 12:04:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > We could add a primitive that copies an image onto the root window. > This would save an exec and a read of the image file (so that the file > is read only once, when the image object is created). > This has potential problems if the root window's visual is not the same as the one we are using for images. On the other hand, we might already be doing that. On the other other hand, when we have an Imlib image-loading extension, it will almost certainly be using a different visual (probably different from all the ones we are using now in fact). The X concept of visuals is _really_ irritating sometimes. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 9 12:30:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25341 for scwm-discuss-outgoing; Fri, 9 Oct 1998 12:30:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA25338 for ; Fri, 9 Oct 1998 12:30:34 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA22189; Fri, 9 Oct 98 12:30:30 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA26058; Fri, 9 Oct 1998 09:30:11 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: Rhosts in Flux.scm? References: <19414.199810090951@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 09 Oct 1998 09:30:11 -0700 In-Reply-To: Mark Toller's message of "Fri, 9 Oct 1998 18:57:26 +0100 (GMT)" Message-Id: Lines: 13 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > > (menuitem "Remote Login" #:action rhosts-menu) > > but this doesn't work. I presume it's something to do with both > rhosts-menu and make-rhosts-menu not being 'define-public', but just > 'define' ? I'll change them to public def'ns. Thanks, Greg From owner-scwm-discuss@mit.edu Fri Oct 9 12:35:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25401 for scwm-discuss-outgoing; Fri, 9 Oct 1998 12:35:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA25395 for ; Fri, 9 Oct 1998 12:35:29 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA12335; Fri, 9 Oct 98 12:35:24 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA26072; Fri, 9 Oct 1998 09:35:24 -0700 (PDT) To: Maciej Stachowiak Cc: "merry::satchell"@hermes.dra.hmg.gb, scwm-discuss@mit.edu Subject: Re: Gnome Pager applet for scwm References: <199810091551.LAA24876@huis-clos.mit.edu> From: Greg Badros Date: 09 Oct 1998 09:35:24 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 09 Oct 1998 11:51:52 EDT" Message-Id: Lines: 22 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I do still want to try to write a pager in the scwmrc language using > guile-gtk at some point, but this external program approach is the > "tried and true" way of doing it. And has lots of advantages in being a separate process that can crash independently of the wm propert. > > A more minor point; I thought it would be cute to change the background of > > different desktops. Is there a change-desk hook to implement this with? > > Sorry to ask two unrelated questions in one mail. > > > > I don't think so, but there should be. Actually, one of the > broadcast-*-notify hook messages is a change of current desktop, but > that is an ugly API for anything but the fvwm module stuff to use. Yep-- perhaps the auto-raise module should use a real hook too instead of the broadcast-hook hooha. Greg From owner-scwm-discuss@mit.edu Fri Oct 9 13:00:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25627 for scwm-discuss-outgoing; Fri, 9 Oct 1998 13:00:52 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA25621 for ; Fri, 9 Oct 1998 13:00:29 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA11461 for scwm-discuss@huis-clos.mit.edu; Fri, 9 Oct 1998 18:51:56 +0200 (MET DST) Received: (qmail 437 invoked by uid 115); 9 Oct 1998 13:06:45 -0000 To: scwm-discuss@mit.edu Subject: Re: Gnome Pager applet for scwm References: <009CD6F7.73C129AE.25@hermes.dra.hmg.gb> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 09 Oct 1998 15:06:43 +0200 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Fri, 09 Oct 1998 10:24:25 GMT" Message-ID: Lines: 39 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 09 Oct 1998 10:24:25 GMT >>>>> "merry::satchell"@hermes.dra.hmg.gb said: Julian> I am playing round with a little pager applet for Gnome/scwm. Julian> [...] What I would like to do is add a pager window for Julian> current desktop. That's very good. The icewm pager applet is not quite up to the task, because it understands only desktop-switching. OTOH, I'd like Gnome to have one program/applet that could control more than one wm. Ideally, you'd start one applet that'd be able to control all "gnome-compliant" wms. Ok, this is not that relevant right now... Julian> Instead I have chosen sockets. This has a (possibly) useful Julian> side effect; the pager need not be running on the same node Julian> as the wm. (I cannot think of a case where that would Julian> actually be useful, but somebody will use it). I'd actually view this as an essential feature. No X application should depend on another application running on the same host. Julian> Now for my problems. The first step (using scwmexec) needs to Julian> tell scwm to wait for a connection, (i.e to wait on accept), Julian> AFTER completing the scwmexec interaction. I can see how I Julian> might do this using threads, but I don't think that will Julian> integrate nicely into the rest of scwm. This seems indeed tricky. If I read the signs right, you only get a valid scheme port _after_ `accept'ing, and `add-input-hook!' wants a port. I think that we can easily make `add-input-hook!' accept fds (integers) as well, so that this knot is untied. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Oct 9 13:01:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25628 for scwm-discuss-outgoing; Fri, 9 Oct 1998 13:01:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA25623 for ; Fri, 9 Oct 1998 13:00:33 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA11462 for scwm-discuss@huis-clos.mit.edu; Fri, 9 Oct 1998 18:51:57 +0200 (MET DST) Received: (qmail 677 invoked by uid 115); 9 Oct 1998 14:32:24 -0000 To: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <16679.199810090928@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: multipart/mixed; boundary="Multipart_Fri_Oct__9_16:32:23_1998-1" Content-Transfer-Encoding: 7bit From: Robert Bihlmeyer Date: 09 Oct 1998 16:32:23 +0200 In-Reply-To: Mark Toller's message of "Fri, 9 Oct 1998 18:34:59 +0100 (GMT)" Message-ID: Lines: 69 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk --Multipart_Fri_Oct__9_16:32:23_1998-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Fri, 9 Oct 1998 18:34:59 +0100 (GMT) >>>>> Mark Toller will say: [your date header must be wrong, unless I am really prescient] Mark> OK, how about dynamic menus? i.e. some way of viewing the cut Mark> buffer in the menu item, and it changing as the cut buffer Mark> changes? Also, how about a history list off these, with the Mark> last few files opened from these menus? I like this idea so much that I have written something up. The code follows. --Multipart_Fri_Oct__9_16:32:23_1998-1 Content-Type: text/plain; charset=US-ASCII ; An alist; whenever the car (a regexp) matches a filename, the ; menuitem specified by the cdr is added to the context menu. (define context-map `(("\.(txt|pl|c|cc|h)$" "edit" #:action ,(exe-on-selection "gnuclient -q")) ("\.ps$" "view" #:action ,(exe-on-selection "gv")) ("\.(gif|jpg)$" "view" #:action ,(exe-on-selection "ee")) ("\.(gif|jpg|xcf)(\.gz)?$" "edit" #:action ,(exe-on-selection "gimp")) ("\.mpe?g$" "play" #:action ,(exe-on-selection "mpeg_play -dither color")) ("\.mp3$" "play" #:action ,(exe-on-selection "mpg123")))) (define (execute-on-selection command) (execute (string-append command " '" (X-cut-buffer-string) "'"))) (define (exe-on-selection command) (lambda () (execute-on-selection command))) (define (popup-context) (popup-menu (let ((file (X-cut-buffer-string))) (menu (append (list (menuitem (string-append "... " file)) menu-separator) (if (and file (access? file F_OK)) (apply append (map (lambda (entry) (if (not (regexp? (car entry))) (set-car! entry (make-regexp (car entry)))) (if (and (regexp-exec (car entry) file)) (list (apply menuitem (cdr entry))) ())) context-map)) ())))))) (bind-mouse '(all) (super "2") popup-context) --Multipart_Fri_Oct__9_16:32:23_1998-1 Content-Type: text/plain; charset=US-ASCII Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --Multipart_Fri_Oct__9_16:32:23_1998-1-- From owner-scwm-discuss@mit.edu Fri Oct 9 13:07:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA25734 for scwm-discuss-outgoing; Fri, 9 Oct 1998 13:07:58 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA25728 for ; Fri, 9 Oct 1998 13:07:53 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA04681; Fri, 9 Oct 98 13:07:51 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA26721; Fri, 9 Oct 1998 10:07:45 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <16679.199810090928@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 09 Oct 1998 10:07:45 -0700 In-Reply-To: Robert Bihlmeyer's message of "09 Oct 1998 16:32:23 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > --Multipart_Fri_Oct__9_16:32:23_1998-1 > Content-Type: text/plain; charset=US-ASCII > > Hi, > > >>>>> On Fri, 9 Oct 1998 18:34:59 +0100 (GMT) > >>>>> Mark Toller will say: > > [your date header must be wrong, unless I am really prescient] > > Mark> OK, how about dynamic menus? i.e. some way of viewing the cut > Mark> buffer in the menu item, and it changing as the cut buffer > Mark> changes? Also, how about a history list off these, with the > Mark> last few files opened from these menus? > > I like this idea so much that I have written something up. The code > follows. Nifty! Can you package this up and check it in sometime? It'd also be cool to have a menu that gets built up out of a directory's contents and does the right thing with each of the files. Another thing that might help these dynamic menus is permitting the label to be a lambda which returns a string, instead of just a static string... Greg From owner-scwm-discuss@mit.edu Fri Oct 9 13:15:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA26088 for scwm-discuss-outgoing; Fri, 9 Oct 1998 13:15:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA26061; Fri, 9 Oct 1998 13:15:32 -0400 Message-Id: <199810091715.NAA26061@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Gnome Pager applet for scwm In-reply-to: Your message of "09 Oct 1998 09:35:24 PDT." Date: Fri, 09 Oct 1998 13:15:32 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I do still want to try to write a pager in the scwmrc language using > > guile-gtk at some point, but this external program approach is the > > "tried and true" way of doing it. > > And has lots of advantages in being a separate process that can crash > independently of the wm propert. > > > > A more minor point; I thought it would be cute to change the background of > > > different desktops. Is there a change-desk hook to implement this with? > > > Sorry to ask two unrelated questions in one mail. > > > > > > > I don't think so, but there should be. Actually, one of the > > broadcast-*-notify hook messages is a change of current desktop, but > > that is an ugly API for anything but the fvwm module stuff to use. > > Yep-- perhaps the auto-raise module should use a real hook too instead > of the broadcast-hook hooha. Yes, it should. There are a number of places where scwm should have more convenient hooks so we don't have to depend on that broadcast stuff. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 9 13:16:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA26101 for scwm-discuss-outgoing; Fri, 9 Oct 1998 13:16:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA26081 for ; Fri, 9 Oct 1998 13:15:54 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA25374; Fri, 9 Oct 98 13:15:51 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA26739; Fri, 9 Oct 1998 10:15:38 -0700 (PDT) To: mal@bewoner.dma.be Cc: scwm-discuss@mit.edu Subject: Re: patch for installation scwm-icons-19981008 References: <19981009084505.29758.qmail@localhost.localdomain> From: Greg Badros Date: 09 Oct 1998 10:15:38 -0700 In-Reply-To: mal@bewoner.dma.be's message of "9 Oct 1998 08:45:05 -0000" Message-Id: Lines: 69 X-Mailer: Gnus v5.4.65/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > The install failed for me. This should work better. > > diff -r -c scwm-icons-19981008-changed/icons/Makefile.in scwm-icons-19981008/icons/Makefile.in It looks like this is a backwards patch... you want the use of the for loop, correct? How does the other way fail? Also, why do we need to drop the *.xpm dependency list from the install: target? Thanks, Greg > *** scwm-icons-19981008-changed/icons/Makefile.in Fri Oct 9 10:02:13 1998 > --- scwm-icons-19981008/icons/Makefile.in Sat Nov 29 23:30:45 1997 > *************** > *** 24,35 **** > > depend: > > ! install: > $(mkinstalldirs) ${pixmap_dir} > ! for i in *.xpm; \ > ! do \ > ! ${INSTALL_DATA} $$i ${pixmap_dir}; \ > ! done > > mostlyclean: > ${RM} *~ core *.bak > --- 24,32 ---- > > depend: > > ! install: *.xpm > $(mkinstalldirs) ${pixmap_dir} > ! ${INSTALL_DATA} *.xpm ${pixmap_dir} > > mostlyclean: > ${RM} *~ core *.bak > diff -r -c scwm-icons-19981008-changed/mini-icons/Makefile.in scwm-icons-19981008/mini-icons/Makefile.in > *** scwm-icons-19981008-changed/mini-icons/Makefile.in Fri Oct 9 10:10:01 1998 > --- scwm-icons-19981008/mini-icons/Makefile.in Sat Nov 29 23:31:32 1997 > *************** > *** 23,34 **** > > depend: > > ! install: > $(mkinstalldirs) ${mini_icon_dir} > ! for i in *.xpm; \ > ! do \ > ! ${INSTALL_DATA} $$i ${mini_icon_dir}; \ > ! done > > mostlyclean: > ${RM} *~ core *.bak > --- 23,31 ---- > > depend: > > ! install: *.xpm > $(mkinstalldirs) ${mini_icon_dir} > ! ${INSTALL_DATA} *.xpm ${mini_icon_dir} > > mostlyclean: > ${RM} *~ core *.bak From owner-scwm-discuss@mit.edu Fri Oct 9 14:50:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA26867 for scwm-discuss-outgoing; Fri, 9 Oct 1998 14:50:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA26864 for ; Fri, 9 Oct 1998 14:50:09 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA11893; Fri, 9 Oct 98 14:50:06 EDT Received: (qmail 6571 invoked by uid 501); 9 Oct 1998 18:51:58 -0000 Message-Id: <19981009090827.A5029@molehill.org> Date: Fri, 9 Oct 1998 09:08:27 -0700 From: Todd Larason To: "merry::satchell"@hermes.dra.hmg.gb Subject: Re: Giving each desk its own background. References: <009CD71F.650F148E.118@hermes.dra.hmg.gb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <009CD71F.650F148E.118@hermes.dra.hmg.gb>; from "merry::satchell"@hermes.dra.hmg.gb on Fri, Oct 09, 1998 at 03:10:20PM +0000 X-Tom-Swifty: "Female canines often scratch the parasites on the coats of their young", said Tom dogmatically. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981009, "merry::satchell"@hermes.dra.hmg.gb wrote: > I have worked out how to get a different background for each desk. > I just redefined set-current-desk! to do my stuff as well. For example In this case, this isn't going to do quite what you want I don't think. Besides set-current-desk!, windows being created and windows getting focus can change the current desk, without going through the scheme level. From owner-scwm-discuss@mit.edu Sat Oct 10 00:36:18 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA00790 for scwm-discuss-outgoing; Sat, 10 Oct 1998 00:36:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA00786; Sat, 10 Oct 1998 00:36:12 -0400 Message-Id: <199810100436.AAA00786@huis-clos.mit.edu> To: mstachow@mit.edu cc: scwm-discuss@mit.edu Subject: MSTACHOW_LEGAL_BS_BRANCH Date: Sat, 10 Oct 1998 00:36:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm having my company's lawyers sign a copyright disclaimer for scwm before I incorporate any new code of mine (other than trivial changes which may be considered in the public domain), but on my latest attempt to harass them (today), they said they would get to it "next week." I don't know if I can get them to do it any faster and I don't want to stocpile changes in my working dir, so I have createad a branch MSTACHOW_LEGAL_BS_BRANCH where I will check my work in. I ask others not to check it out until the distributability of this code is clarified (it will be clarified in the positive direction soon or else I will find a new job). I will try to merge changes from the head onto this branch frequently, so that it is easy to merge it back once my company signs the papers. - Maciej From owner-scwm-discuss@mit.edu Sat Oct 10 06:00:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA03246 for scwm-discuss-outgoing; Sat, 10 Oct 1998 06:00:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id GAA03243 for ; Sat, 10 Oct 1998 06:00:21 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id LAA05994 for scwm-discuss@huis-clos.mit.edu; Sat, 10 Oct 1998 11:52:15 +0200 (MET DST) Received: (qmail 766 invoked by uid 115); 10 Oct 1998 09:45:31 -0000 To: scwm-discuss@mit.edu Subject: Re: Giving each desk its own background. References: <009CD71F.650F148E.118@hermes.dra.hmg.gb> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 10 Oct 1998 11:45:29 +0200 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Fri, 09 Oct 1998 15:10:20 GMT" Message-ID: Lines: 26 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 09 Oct 1998 15:10:20 GMT >>>>> "merry::satchell"@hermes.dra.hmg.gb said: Julian> I have worked out how to get a different background for each Julian> desk. I just redefined set-current-desk! to do my stuff as Julian> well. I have started writing an advice mechanism for guile/scheme, which is useful in this cases. It seems like I'm lacking the scheme-prowess to complete it, but I think I will commit this anyway, as common cases are covered and the need is definitely there. However, your solution does not work in all cases. Try issuing xlogo -xrm "*Desk: 1" scwm will switch to desktop 1 without calling your desk-switching-function. We probably need a hook for that. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Oct 10 13:56:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05327 for scwm-discuss-outgoing; Sat, 10 Oct 1998 13:56:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05324 for ; Sat, 10 Oct 1998 13:56:29 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07064; Sat, 10 Oct 98 13:56:20 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA17590; Sat, 10 Oct 1998 10:56:17 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: MSTACHOW_LEGAL_BS_BRANCH References: <199810100436.AAA00786@huis-clos.mit.edu> From: Greg Badros Date: 10 Oct 1998 10:56:17 -0700 In-Reply-To: Maciej Stachowiak's message of "Sat, 10 Oct 1998 00:36:11 EDT" Message-Id: Lines: 11 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I will try to merge changes from the head onto this branch frequently, > so that it is easy to merge it back once my company signs the papers. Though I imagine scwm-commits will still get your check-in messages on your branch, please be sure that they do get mailed to us. I want to be sure not to duplicate effort while we're waiting for your employer to sign the papers. Greg From owner-scwm-discuss@mit.edu Sat Oct 10 14:01:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05386 for scwm-discuss-outgoing; Sat, 10 Oct 1998 14:01:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05379; Sat, 10 Oct 1998 14:01:08 -0400 Message-Id: <199810101801.OAA05379@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: MSTACHOW_LEGAL_BS_BRANCH In-reply-to: Your message of "10 Oct 1998 10:56:17 PDT." Date: Sat, 10 Oct 1998 14:01:06 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I will try to merge changes from the head onto this branch frequently, > > so that it is easy to merge it back once my company signs the papers. > > Though I imagine scwm-commits will still get your check-in messages on > your branch, please be sure that they do get mailed to us. I want to be > sure not to duplicate effort while we're waiting for your employer to > sign the papers. It's the same repository, I am pretty sure it will still send mail. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 11 12:57:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA17676 for scwm-discuss-outgoing; Sun, 11 Oct 1998 12:57:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA17673 for ; Sun, 11 Oct 1998 12:57:08 -0400 Received: from pool02b-194-7-146-158.uunet.be by MIT.EDU with SMTP id AA23741; Sun, 11 Oct 98 12:56:49 EDT Received: (qmail 3990 invoked by uid 500); 10 Oct 1998 22:07:20 -0000 Date: 10 Oct 1998 22:07:20 -0000 Message-Id: <19981010220720.3989.qmail@tower.skynet.be> From: Lieven Marchand Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: patch for installation scwm-icons-19981008 In-Reply-To: References: <19981009084505.29758.qmail@localhost.localdomain> X-Mailer: VM 6.31 under 20.2 XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > mal@bewoner.dma.be writes: > > > The install failed for me. This should work better. > > > > diff -r -c scwm-icons-19981008-changed/icons/Makefile.in scwm-icons-19981008/icons/Makefile.in > > It looks like this is a backwards patch... you want the use of the for > loop, correct? How does the other way fail? > Yes, it's backwards. I always gets them mixed up. The other one fails because install-sh only is written to take care of one file, not a list of files. >From the end of the first blob of comments ... # from scratch. It can only install one file at a time, a restriction # shared with many OS's install programs. > Also, why do we need to drop the *.xpm dependency list from the install: > target? > At least gnumake tries to make the xpm's and fails when it doesn't have a rule for them. If you want to have to automatically reinstalled when something changed you need to use a dummy target that touches a file. There's an example in the GNU make info file. > Thanks, > Greg > Thank you for a great window manager. BTW, I really liked your comment a while ago about the way GWM did something. That was also the WM I had been using for some time before development on it stopped. Judging from comments from some other people, it would seem scwm has gathered a fair percentage of the GWM user community. [patch snipped] Lieven From owner-scwm-discuss@mit.edu Sun Oct 11 15:47:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA18627 for scwm-discuss-outgoing; Sun, 11 Oct 1998 15:47:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA18624 for ; Sun, 11 Oct 1998 15:47:42 -0400 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA12486; Sun, 11 Oct 98 15:47:23 EDT Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id MAA13341; Sun, 11 Oct 1998 12:47:21 -0700 (PDT) Date: Sun, 11 Oct 1998 12:47:20 -0700 (PDT) From: Jeffrey Nichols To: scwm-discuss@mit.edu Cc: Greg Badros Subject: Autogen.sh Problems In-Reply-To: <19981010220720.3989.qmail@tower.skynet.be> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Whenever I run autogen.sh I now get the following message. aclocal: configure.in: 44: macro `AM_PROG_LIBTOOL' not found in library I have installed v1.2 of libtool and it's in my path. Configure also refuses to run, perhaps because of the above error? The output is: loading cache ./config.cache ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, post0.8a)' changed.c is: char *szRepoLastChanged = "Sun Oct 11 13:47:35 EDT 1998 -- $Revision: 1.632 $"; I running a brand new installation of Redhat 5.1 w/ egcs 1.1b and the correct versions of automake, autoconf, and libtool (according to HACKING). Thanx, -Jeff From owner-scwm-discuss@mit.edu Sun Oct 11 16:04:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18760 for scwm-discuss-outgoing; Sun, 11 Oct 1998 16:04:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA18756 for ; Sun, 11 Oct 1998 16:04:00 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22721; Sun, 11 Oct 98 16:03:37 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA23760; Sun, 11 Oct 1998 13:03:36 -0700 (PDT) To: Jeffrey Nichols Cc: scwm-discuss@mit.edu Subject: Re: Autogen.sh Problems References: From: Greg Badros Date: 11 Oct 1998 13:03:36 -0700 In-Reply-To: Jeffrey Nichols's message of "Sun, 11 Oct 1998 12:47:20 -0700 (PDT)" Message-Id: Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jeffrey Nichols writes: > Whenever I run autogen.sh I now get the following message. > > aclocal: configure.in: 44: macro `AM_PROG_LIBTOOL' not found in library What do you get with (from top-level scwm/ directory, using bash/zsh [not [t]csh]): strace aclocal |& grep open aclocal should be accessing a bunch of *.m4 files from, e.g., /usr/local/share/aclocal/ If libtool.m4 is not in that directory, then perhaps it or automake is not installed correctly. I'm no autoXXXX guru, so maybe someone else has more specific suggestions? Greg From owner-scwm-discuss@mit.edu Sun Oct 11 16:29:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19259 for scwm-discuss-outgoing; Sun, 11 Oct 1998 16:29:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA19252 for ; Sun, 11 Oct 1998 16:28:57 -0400 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA25833; Sun, 11 Oct 98 16:28:26 EDT Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id NAA13188; Sun, 11 Oct 1998 13:28:28 -0700 (PDT) Date: Sun, 11 Oct 1998 13:28:28 -0700 (PDT) From: Jeffrey Nichols To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Autogen.sh Problems In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > Whenever I run autogen.sh I now get the following message. > > > > aclocal: configure.in: 44: macro `AM_PROG_LIBTOOL' not found in library > > What do you get with (from top-level scwm/ directory, using bash/zsh > [not [t]csh]): > > strace aclocal |& grep open > > aclocal should be accessing a bunch of *.m4 files from, e.g., > /usr/local/share/aclocal/ > > If libtool.m4 is not in that directory, then perhaps it or automake is > not installed correctly. I guess that libtool's 'make install' does not copy libtool.m4 to /usr/share/aclocal. I did find the file in the libtool build directory and I copied it to the correct location. Everything works fine now. Thanx, -Jeff From owner-scwm-discuss@mit.edu Sun Oct 11 16:45:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19470 for scwm-discuss-outgoing; Sun, 11 Oct 1998 16:45:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA19460; Sun, 11 Oct 1998 16:44:59 -0400 Message-Id: <199810112044.QAA19460@huis-clos.mit.edu> To: Jeffrey Nichols cc: scwm-discuss@mit.edu Subject: Re: Autogen.sh Problems In-reply-to: Your message of "Sun, 11 Oct 1998 12:47:20 PDT." Date: Sun, 11 Oct 1998 16:44:58 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jwnichls@cs.washington.edu writes: > > Whenever I run autogen.sh I now get the following message. > > aclocal: configure.in: 44: macro `AM_PROG_LIBTOOL' not found in library > > I have installed v1.2 of libtool and it's in my path. Configure > also refuses to run, perhaps because of the above error? The output is: > > loading cache ./config.cache > ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' > ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, post0.8a)' > > changed.c is: > > char *szRepoLastChanged = "Sun Oct 11 13:47:35 EDT 1998 -- $Revision: > 1.632 $"; > > I running a brand new installation of Redhat 5.1 w/ egcs 1.1b and > the correct versions of automake, autoconf, and libtool (according to > HACKING). > Are libtool and automake installed in the same $prefix? Unfortunately, they will not interoperate correctly if they aren't, as automake only looks for automake macros in its own ${prefix}. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sun Oct 11 18:33:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA20425 for scwm-discuss-outgoing; Sun, 11 Oct 1998 18:33:08 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA20422 for ; Sun, 11 Oct 1998 18:33:04 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02184; Sun, 11 Oct 98 18:32:43 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA23903; Sun, 11 Oct 1998 15:32:40 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Overlay planes for drawing rubberbands... From: Greg Badros Date: 11 Oct 1998 15:32:39 -0700 Message-Id: Lines: 14 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Does anybody have any experience with using overlay planes in a window manager (or even a normal application, really). I've added some code to a dynamically loaded module (app scwm overlay-plane) to try to use the overlay plane of Xi Graphics' X server, but can't get the behaviour that I expect (mostly because I don't have sufficient documentation to figure out what should be necessary). I know 4dwm uses SGI's overlay plane to draw rubberbands, but I don't have the code to that wm, obviouslyi. Anybody know of any examples or pointers to help me figure this out? The one I've been working from is ORA's Xlib Prg manual Example 7-7 (p213-215). Thanks, Greg From owner-scwm-discuss@mit.edu Tue Oct 13 09:08:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA02783 for scwm-discuss-outgoing; Tue, 13 Oct 1998 09:08:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA02780 for ; Tue, 13 Oct 1998 09:08:34 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA01460; Tue, 13 Oct 98 09:07:37 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id OAA09157 for ; Tue, 13 Oct 1998 14:05:14 +0100 (BST) Message-Id: <3428.199810131307@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Tue, 13 Oct 1998 14:07:10 +0100 Date: Tue, 13 Oct 1998 22:13:31 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: X-synthetic-send-string? To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I've been playing around with SCWM so that when mail arrives and is filtered by procmail, I can get SCWM to bring my e-mail program (TkRat) to the front - that was fairly strightforward - the problem is that I'd also like to make TkRat change to the correct folder in which the mail arrived. I see two ways of doing this - by sending TkRat the correct X events (X-synthetic-send-string?) or by creating a sort of macro which moves the mouse around and send mouse click events...? OK - 3 ways - by hacking TkRat to accept some form of commands ala netsape? Any thoughts? Mark. From owner-scwm-discuss@mit.edu Tue Oct 13 11:07:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA03442 for scwm-discuss-outgoing; Tue, 13 Oct 1998 11:07:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA03439 for ; Tue, 13 Oct 1998 11:07:08 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA29350; Tue, 13 Oct 98 11:06:17 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28418; Tue, 13 Oct 1998 08:05:45 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: X-synthetic-send-string? References: <3428.199810131307@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 13 Oct 1998 08:05:45 -0700 In-Reply-To: Mark Toller's message of "Tue, 13 Oct 1998 22:13:31 +0100 (GMT)" Message-Id: Lines: 26 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Hi, > > I've been playing around with SCWM so that when mail arrives and is > filtered by procmail, I can get SCWM to bring my e-mail program (TkRat) > to the front - that was fairly strightforward - the problem is that I'd > also like to make TkRat change to the correct folder in which the mail > arrived. > > I see two ways of doing this - by sending TkRat the correct X events > (X-synthetic-send-string?) or by creating a sort of macro which moves > the mouse around and send mouse click events...? OK - 3 ways - by > hacking TkRat to accept some form of commands ala netsape? > > Any thoughts? The third way is the best solution, IMO. You don't rely on your emailer being in the proper state before the keystrokes are sent, and you don't force yourself to open up your mailer to arbitrary synthetic events. If you didn't have the source code to the mailer, I'd go with the key based solution over the mouse based solution as it's less affected by changes in display, or other interactive changes (like stacking order, layout, etc.) Greg From owner-scwm-discuss@mit.edu Wed Oct 14 02:45:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA09487 for scwm-discuss-outgoing; Wed, 14 Oct 1998 02:45:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA09484 for ; Wed, 14 Oct 1998 02:45:44 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id IAA25914 for scwm-discuss@huis-clos.mit.edu; Wed, 14 Oct 1998 08:28:28 +0200 (MET DST) Received: (qmail 5871 invoked by uid 115); 13 Oct 1998 18:50:45 -0000 To: scwm-discuss@mit.edu Subject: Re: cvs checkout solved probs :) References: <16679.199810090928@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 13 Oct 1998 20:50:45 +0200 In-Reply-To: Greg Badros's message of "09 Oct 1998 10:07:45 -0700" Message-ID: Lines: 14 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 09 Oct 1998 10:07:45 -0700 >>>>> Greg Badros said: Greg> Nifty! Can you package this up and check it in sometime? I've put `make-context-menu' into std-menu.scm today. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Oct 14 04:37:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA10950 for scwm-discuss-outgoing; Wed, 14 Oct 1998 04:37:54 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA10947 for ; Wed, 14 Oct 1998 04:37:49 -0400 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Wed, 14 Oct 1998 09:36:57 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 1; Wed, 14 Oct 1998 09:36:38 GMT Date: Wed, 14 Oct 1998 09:36:35 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CDADE.992AF8CE.1@hermes.dra.hmg.gb> Subject: Pager's Progress Sender: owner-scwm-discuss@mit.edu Precedence: bulk A quick update on my hack to make a Gnome pager applet for scwm. It now opens a socket to scwm, and gets stuff from broadcast hook and broadcast config hook. Some of this stuff it can do sane things with, some it ignores, some it does the wrong thing with. When you exit the applet scwm crashes. It looks like this _________ ___ ___ :: | | 1 | 2 | :: | |---|---| :: | | 3 | 4 | --------- --- --- The :: on the left is the handle for detaching it from the panel, so you can have it free standing if you like. The bigger window shows the current desktop, with the viewport highlighted, (and will show the windows, but this is very buggy). The buttons switch viewports. The code is still pre-alpha quality. Somebody asked if the code could be built as a conventional Gnome or Gtk application rather than an applet. I am sure this would be possible, and have avoided the fancy bits of gnome to make this easier. The only thing different would be in the main{}, and obviously includes and libraries. I would love to release this but it will not be easy. I am a public employee, so I need permission to publish, which takes months, and is only possible with our own copyright. (There are legal reasons for this, I understand). It may be faster and better for somebody else who does not have so many restrictions on them to re-invent this wheel, using my example as an existence theorem. I would be very happy to help out where possible. Julian Satchell From owner-scwm-discuss@mit.edu Wed Oct 14 05:02:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA11118 for scwm-discuss-outgoing; Wed, 14 Oct 1998 05:02:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id FAA11115 for ; Wed, 14 Oct 1998 05:02:43 -0400 Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with SMTP id SAA21533 for ; Wed, 14 Oct 1998 18:01:53 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (SMI-8.6/3.5Wbeta) id SAA15480; Wed, 14 Oct 1998 18:01:53 +0900 To: scwm-discuss@mit.edu Subject: #:focus 'none & next-window X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 14 Oct 1998 18:01:53 +0900 Message-ID: Lines: 15 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/21.0 (Poitou) Sender: owner-scwm-discuss@mit.edu Precedence: bulk I use click to focus by default. Am I still the only one? Anyway I have noticed that if I click on a window with #:focus 'none set then I can't use (next-window #:only visible? #:except iconified?) (Alt-Tab) to change the focus to another window on the screen. I will try to investigate more, but maybe someone knows a quick fix so I thought I would post the problem here first. -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Wed Oct 14 05:10:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA11212 for scwm-discuss-outgoing; Wed, 14 Oct 1998 05:10:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA11209 for ; Wed, 14 Oct 1998 05:10:37 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA17578; Wed, 14 Oct 98 05:09:31 EDT Received: (qmail 12857 invoked by uid 501); 14 Oct 1998 09:10:05 -0000 Message-Id: <19981014021004.A12764@molehill.org> Date: Wed, 14 Oct 1998 02:10:04 -0700 From: Todd Larason To: scwm-discuss list Subject: status, ideas Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I could stand to lose 50% of my body weight", said Tom affably. Sender: owner-scwm-discuss@mit.edu Precedence: bulk My work is being very demanding right now, so I haven't had much time to do fun stuff, but there are a couple things I've been working on. Pie menus are the first, and most likely to be done first. Not much of the coding is done yet, but I think I've figured out all the details so that it's just a Simple Matter of Programming at this point. The other is...different. I'm not sure it will ever be possible to do all of it, and I'm not sure if anybody would really be interested if it was, but it's a set of interesting problems and something no other X window manager has, as far as I know. Any of you who use Macs may be familair with an appearance utility called Kaleidoscope (www.kaleidoscope.net for those who aren't). I've been working on a library for using Kaleidoscope theme files with SCWM. Obviously, most of this will have to wait till the decoration rewrite, and quite a bit of what Kaleidoscope does is outside the scope of a window manager on X, but it seems like a good way for me to start thinking about what kinds of things should be possible after the decoration rewrite. I have code that can read AppleSingle and AppleDouble file formats (the official Apple formats for file transfer and for storing Mac files on non-Mac AppleTalk file servers), and can read the resource for sections it finds there. Code is done to read resource types 'clut' (color lookup tables), 'vers' (versions) and 'ics8' (small color 8 bit icons) and 'ics#' (small color icon masks). The other ic[sml][#248] types shoudl be trivial. .xpm files can be created from an ics8/ics# pair, using either a clut from the resource file or the standard system clut. A Kaleidoscope theme consists of a resource file with many ic* and quite a few other resources. Architecture issues: should this resource library be 1) a dynamic module for scwm, used only by another kaleidoscope dynamic module that knows which resources to use and how; 2) a dynamic module for scwm that exports scwm primitives for fetching resource data by type and ID, and primitives for converting from the raw data vectors to various X equivalents, and scheme code to package all of that into an easy-to-use (use-kaleidoscope-theme) package; or 3) an external utility that converts a kaleidoscope theme into (possibly many hundreds) of individual .xpm files and whatever configuration is needed to use those as an scwm theme? Another bonus X question: is there a simpler method to build an X pixmap from some bizarre data format than converting to a .xpm and letting the XPM library deal with it? I really don't want to worry about visuals and color selection and dithering and the like unless it's absolutely required. From owner-scwm-discuss@mit.edu Wed Oct 14 08:46:25 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA12119 for scwm-discuss-outgoing; Wed, 14 Oct 1998 08:46:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA12116 for ; Wed, 14 Oct 1998 08:46:21 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA12731; Wed, 14 Oct 98 08:45:15 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id NAA29982 for ; Wed, 14 Oct 1998 13:42:07 +0100 (BST) Message-Id: <27727.199810141244@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Wed, 14 Oct 1998 13:44:03 +0100 Date: Wed, 14 Oct 1998 21:50:25 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: maximise bug To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I've just noticed a bug in scwm's maxise function - if the window being maximised is partially off the left hand side of the screen, the window is set to the correct size, but not placed in the center of the screen... Mark. From owner-scwm-discuss@mit.edu Wed Oct 14 11:18:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA12942 for scwm-discuss-outgoing; Wed, 14 Oct 1998 11:18:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA12939 for ; Wed, 14 Oct 1998 11:18:07 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07822; Wed, 14 Oct 98 11:17:09 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA02184; Wed, 14 Oct 1998 08:16:59 -0700 (PDT) To: "merry::satchell"@hermes.dra.hmg.gb Cc: scwm-discuss@mit.edu Subject: Re: Pager's Progress References: <009CDADE.992AF8CE.1@hermes.dra.hmg.gb> From: Greg Badros Date: 14 Oct 1998 08:16:58 -0700 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Wed, 14 Oct 1998 09:36:35 GMT" Message-Id: Lines: 12 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > some it ignores, some it does the wrong thing with. When you exit the applet > scwm crashes. Can you send in a full bug report on this crashing of scwm? We need to fix this bug, obviously. See BUG-REPORTING for details. Thanks, Greg P.S. Pager sounds interesting... From owner-scwm-discuss@mit.edu Wed Oct 14 11:36:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA13086 for scwm-discuss-outgoing; Wed, 14 Oct 1998 11:36:20 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA13082 for ; Wed, 14 Oct 1998 11:36:04 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA14942; Wed, 14 Oct 98 11:35:02 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA02187; Wed, 14 Oct 1998 08:35:01 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: status, ideas References: <19981014021004.A12764@molehill.org> From: Greg Badros Date: 14 Oct 1998 08:35:00 -0700 In-Reply-To: Todd Larason's message of "Wed, 14 Oct 1998 02:10:04 -0700" Message-Id: Lines: 74 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > My work is being very demanding right now, so I haven't had much time > to do fun stuff, but there are a couple things I've been working on. > > Pie menus are the first, and most likely to be done first. Not much > of the coding is done yet, but I think I've figured out all the > details so that it's just a Simple Matter of Programming at this > point. You may want to look at piewm for some ideas and code to borrow. (Check the license, though-- I'm not sure what they're under). > The other is...different. I'm not sure it will ever be possible to do > all of it, and I'm not sure if anybody would really be interested if > it was, but it's a set of interesting problems and something no other > X window manager has, as far as I know. > > Any of you who use Macs may be familair with an appearance utility > called Kaleidoscope (www.kaleidoscope.net for those who aren't). I've Unfortunately, the web page "What is kaleidoscope?" is pretty empty. I still don't have much of a clue as to what it is or why I'd want it. (But I'm interested since you think it's worthwhile). > been working on a library for using Kaleidoscope theme files with > SCWM. Obviously, most of this will have to wait till the decoration > rewrite, and quite a bit of what Kaleidoscope does is outside the > scope of a window manager on X, but it seems like a good way for me to > start thinking about what kinds of things should be possible after the > decoration rewrite. This is good to be thinking about post-decoration-rewrite times to figure out the decoration-rewrite. When work lets up for you (and after the pie menus, and whatever else short-term you have planned), perhaps you'd be willing to write a design spec for the decoration rewrite? I'd imagine Maciej has ideas about decorations, too, but I thought the event-rewrite design spec evolved nicely within this mailing list with an initial formal proposal largely authored by an individual. (Now we just need time to implement the new event model). It wouldn't hurt to have the decoration rewrite specified before coding the event rewrite, since there will be some interactions. > Architecture issues: should this resource library be 1) a dynamic > module for scwm, used only by another kaleidoscope dynamic module that > knows which resources to use and how; 2) a dynamic module for scwm > that exports scwm primitives for fetching resource data by type and > ID, and primitives for converting from the raw data vectors to various > X equivalents, and scheme code to package all of that into an > easy-to-use (use-kaleidoscope-theme) package; or 3) an external > utility that converts a kaleidoscope theme into (possibly many > hundreds) of individual .xpm files and whatever configuration is > needed to use those as an scwm theme? Beats me... I'm still clueless as to what kaleidoscope is useful for. Looser coupling is good. Permitting greater reuse is good. But performance has to be good enough that people will use the code, and improving performance often means tighter coupling. > Another bonus X question: is there a simpler method to build an X > pixmap from some bizarre data format than converting to a .xpm and > letting the XPM library deal with it? I really don't want to worry > about visuals and color selection and dithering and the like unless > it's absolutely required. You can create a pixmap which XCreatePixmap, but you may want to use XImage structures instead. I'd read through the Xlib Prg manual (ORA) about this stuff... I never knew all the details... Greg From owner-scwm-discuss@mit.edu Wed Oct 14 11:41:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA13134 for scwm-discuss-outgoing; Wed, 14 Oct 1998 11:41:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA13131 for ; Wed, 14 Oct 1998 11:41:12 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16686; Wed, 14 Oct 98 11:40:15 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA02190; Wed, 14 Oct 1998 08:39:46 -0700 (PDT) To: mst95r@ecs.soton.ac.uk Cc: scwm-discuss@mit.edu Subject: Re: maximise bug References: <27727.199810141244@penelope.ecs.soton.ac.uk> From: Greg Badros Date: 14 Oct 1998 08:39:45 -0700 In-Reply-To: Mark Toller's message of "Wed, 14 Oct 1998 21:50:25 +0100 (GMT)" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mark Toller writes: > Hi, > > I've just noticed a bug in scwm's maxise function - if the window > being maximised is partially off the left hand side of the screen, the > window is set to the correct size, but not placed in the center of the > screen... Same bug if the window is partially off the top side of the screen. There are a couple of cases missing in the maximize code in winops.scm, it appears. Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Wed Oct 14 15:17:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14548 for scwm-discuss-outgoing; Wed, 14 Oct 1998 15:17:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14542 for ; Wed, 14 Oct 1998 15:16:57 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA07526; Wed, 14 Oct 98 15:15:43 EDT Received: (qmail 15531 invoked by uid 501); 14 Oct 1998 19:15:55 -0000 Message-Id: <19981014121554.A15484@molehill.org> Date: Wed, 14 Oct 1998 12:15:54 -0700 From: Todd Larason To: Greg Badros Cc: scwm-discuss list Subject: Re: status, ideas References: <19981014021004.A12764@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Oct 14, 1998 at 08:35:00AM -0700 X-Tom-Swifty: "I got a personal letter from Ann Landers", was Tom's epigraph. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981014, Greg Badros wrote: > You may want to look at piewm for some ideas and code to borrow. (Check > the license, though-- I'm not sure what they're under). I've read that code, and am ready to reimplment if necessary. The README and copyright are clear that the algorithm is free and may be implemented and extended. I already have mail out to Dan Hopkins (? I think that's the right name) asking for clarification on the code license, but haven't had a response yet. > Unfortunately, the web page "What is kaleidoscope?" is pretty empty. I > still don't have much of a clue as to what it is or why I'd want it. > (But I'm interested since you think it's worthwhile). It's a theme manager for MacOS. There's a "Kaleidoscope Theme Archive" link on that page that will show screenshots of the newest themes. Most of them are both boring and ugly, but there are some exceptions out there, and the fairly recent 2.0 upgrade allows for the Mac equivalent of shaped windows, leading finally to some truly somewhat interesting looks. > When work lets up for you (and after the pie menus, and whatever else > short-term you have planned), perhaps you'd be willing to write a design > spec for the decoration rewrite? If nobody beats me to it, I'll write up what thoughts I have as soon as they congeal at all. > It wouldn't hurt to have the decoration rewrite specified > before coding the event rewrite, since there will be some interactions. The only important interaction I see is that it ought to be possible to bind events in an arbitrary subwindow of a window decoration, and I'm pretty sure that was already in the last event spec. > You can create a pixmap which XCreatePixmap, but you may want to use > XImage structures instead. I'd read through the Xlib Prg manual (ORA) > about this stuff... I never knew all the details... Thanks! From owner-scwm-discuss@mit.edu Wed Oct 14 15:21:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14592 for scwm-discuss-outgoing; Wed, 14 Oct 1998 15:21:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14589 for ; Wed, 14 Oct 1998 15:21:12 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA09185; Wed, 14 Oct 98 15:20:04 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA05197; Wed, 14 Oct 1998 12:20:12 -0700 (PDT) To: Todd Larason Cc: scwm-discuss list Subject: Re: status, ideas References: <19981014021004.A12764@molehill.org> <19981014121554.A15484@molehill.org> From: Greg Badros Date: 14 Oct 1998 12:20:11 -0700 In-Reply-To: Todd Larason's message of "Wed, 14 Oct 1998 12:15:54 -0700" Message-Id: Lines: 48 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I've read that code, and am ready to reimplment if necessary. The > README and copyright are clear that the algorithm is free and may be > implemented and extended. I already have mail out to Dan Hopkins (? I > think that's the right name) asking for clarification on the code license, > but haven't had a response yet. Good. > It's a theme manager for MacOS. There's a "Kaleidoscope Theme Archive" > link on that page that will show screenshots of the newest themes. Most > of them are both boring and ugly, but there are some exceptions out there, > and the fairly recent 2.0 upgrade allows for the Mac equivalent of shaped > windows, leading finally to some truly somewhat interesting looks. Maybe we need some sort of unifying theme manager so that all sorts of themes are usable. > > When work lets up for you (and after the pie menus, and whatever else > > short-term you have planned), perhaps you'd be willing to write a design > > spec for the decoration rewrite? > > If nobody beats me to it, I'll write up what thoughts I have as soon > as they congeal at all. Great... apres congeal is good! > > It wouldn't hurt to have the decoration rewrite specified > > before coding the event rewrite, since there will be some interactions. > > The only important interaction I see is that it ought to be possible > to bind events in an arbitrary subwindow of a window decoration, and > I'm pretty sure that was already in the last event spec. And the decoration rewrite needs to have accessor to get at arbitrary subwindows by their X id (or we need to bite the bullet and wrap subwindows as SMOBs [maybe this'd be useful anyway for the decoration rewrite, though I'd really rather not have it happen]). > > You can create a pixmap which XCreatePixmap, but you may want to use > > XImage structures instead. I'd read through the Xlib Prg manual (ORA) > > about this stuff... I never knew all the details... > > Thanks! Good luck, Greg From owner-scwm-discuss@mit.edu Thu Oct 15 02:47:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA18301 for scwm-discuss-outgoing; Thu, 15 Oct 1998 02:47:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA18298 for ; Thu, 15 Oct 1998 02:47:46 -0400 Received: from smtp5.nwnexus.com by MIT.EDU with SMTP id AA18573; Thu, 15 Oct 98 02:46:32 EDT Received: from pulsar.halcyon.com (ken@coho.halcyon.com [198.137.231.21]) by smtp5.nwnexus.com (8.8.8/8.8.8) with ESMTP id XAA20720 for ; Wed, 14 Oct 1998 23:45:53 -0700 Received: from ken@localhost by pulsar.halcyon.com id <276517-271>; Wed, 14 Oct 1998 23:44:59 -0700 To: scwm-discuss@mit.edu Subject: Re: maximise bug References: <27727.199810141244@penelope.ecs.soton.ac.uk> Date: Wed, 14 Oct 1998 23:44:48 -0600 From: Ken Pizzini Message-Id: <19981015064459Z276517-271+10@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 14 Oct 1998 08:39:45 -0700, Greg Badros wrote: >> I've just noticed a bug in scwm's maxise function - if the window >> being maximised is partially off the left hand side of the screen, the >> window is set to the correct size, but not placed in the center of the >> screen... > >Same bug if the window is partially off the top side of the screen. >There are a couple of cases missing in the maximize code in winops.scm, >it appears. I didn't think of those cases as being an issue when making my earlier changes to maximize... Attached is a patch to handle these. --Ken Pizzini --- scwm/scheme/winops.scm-orig Mon Sep 28 19:03:11 1998 +++ scwm/scheme/winops.scm Wed Oct 14 23:37:39 1998 @@ -118,10 +118,12 @@ (ncw (caddr new-client-size)) (nch (cadddr new-client-size)) (nx (cond + ((> 0 x) 0) ((> display-width (+ x nfw)) x) ((> display-width nfw) (- display-width nfw)) (#t 0))) (ny (cond + ((> 0 y) 0) ((> display-height (+ y nfh)) y) ((> display-height nfh) (- display-height nfh)) (#t 0)))) From owner-scwm-discuss@mit.edu Thu Oct 15 03:51:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA19442 for scwm-discuss-outgoing; Thu, 15 Oct 1998 03:51:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA19439 for ; Thu, 15 Oct 1998 03:51:39 -0400 From: mal@bewoner.dma.be Received: from dialup290.brussels.skynet.be by MIT.EDU with SMTP id AA24980; Thu, 15 Oct 98 03:50:18 EDT Received: (qmail 16045 invoked by uid 500); 15 Oct 1998 08:18:28 -0000 Date: 15 Oct 1998 08:18:28 -0000 Message-Id: <19981015081828.16044.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: core dump in garbage collection X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Scwm Version post0.8a compiled on Oct 8 1998 at 14:23:33 RCS_ID=$Id: scwm.c,v 1.139 1998/10/06 22:17:43 jtl Exp $ Repository Timestamp: Wed Oct 7 20:40:33 EDT 1998 -- $Revision: 1.597 $ Backtrace: #0 0x3e6e8 in mark_window (obj=1636968) at window.c:347 #1 0xef42cfec in scm_gc_mark (p=1355744) at gc.c:852 #2 0xef42cbd4 in scm_gc_mark (p=1355728) at gc.c:671 #3 0xef42c774 in scm_igc (what=0xe "") at gc.c:544 #4 0xef42e0f0 in scm_must_malloc (len=68, what=0xef46ecc8 "inferior root continuation") at gc.c:1432 #5 0xef4510cc in scm_internal_cwdr (body=0x2276c , body_data=0xeffff188, handler=0x22650 , handler_data=0x53df8, stack_start=0xeffff20c) at root.c:273 #6 0x227c8 in scm_internal_stack_cwdr (body=0x22754 , body_data=0xeffff210, handler=0x22650 , handler_data=0x53df8, stack_item=0xeffff20c) at callbacks.c:126 #7 0x227fc in scwm_safe_apply (proc=622528, args=1163776) at callbacks.c:141 #8 0x22874 in scwm_safe_call1 (proc=622528, arg=1163800) at callbacks.c:173 #9 0x22c08 in call1_hooks (hook=485848, arg=1163800) at callbacks.c:342 #10 0x1c650 in AddWindow (w=50331901) at add_window.c:265 #11 0x29b28 in HandleMapRequestKeepRaised (KeepRaised=0) at events.c:891 #12 0x29ac8 in HandleMapRequest () at events.c:872 #13 0x28870 in DispatchEvent () at events.c:194 #14 0x288ac in HandleEvents () at events.c:216 #15 0x3b728 in scwm_main (argc=1, argv=0xeffffd84) at scwm.c:959 #16 0x3ab80 in scwm_gh_launch_pad (closure=0x3abd4, argc=1, argv=0xeffffd84) at scwm.c:432 #17 0xef4330d4 in invoke_main_func (body_data=0xeffffc20) at init.c:538 #18 0xef45d240 in scm_internal_catch (tag=9076, body=0xef4330b4 , body_data=0xeffffc20, handler=0xef45d794 , handler_data=0x0) at throw.c:236 #19 0xef433074 in scm_boot_guile_1 (base=0xeffffc1c, closure=0xeffffc20) at init.c:512 #20 0xef432d10 in scm_boot_guile (argc=1, argv=0xeffffd84, main_func=0x3ab64 , closure=0x3abd4) at init.c:377 #21 0x3abac in scwm_gh_enter (argc=1, argv=0xeffffd84, c_main_prog=0x3abd4 ) at scwm.c:439 #22 0x3abcc in main (argc=1, argv=0xeffffd84) at scwm.c:451 This is the first time scwm has core dumped on me. Anybody any idea how to debug these kind of things? Lieven From owner-scwm-discuss@mit.edu Thu Oct 15 04:18:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA19641 for scwm-discuss-outgoing; Thu, 15 Oct 1998 04:18:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA19638 for ; Thu, 15 Oct 1998 04:18:38 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA15571; Thu, 15 Oct 98 04:17:32 EDT Received: (qmail 18532 invoked by uid 501); 15 Oct 1998 08:17:51 -0000 Message-Id: <19981015011749.A18461@molehill.org> Date: Thu, 15 Oct 1998 01:17:49 -0700 From: Todd Larason To: mal@bewoner.dma.be Cc: scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981015081828.16044.qmail@localhost.localdomain>; from mal@bewoner.dma.be on Thu, Oct 15, 1998 at 08:18:28AM -0000 X-Tom-Swifty: "Eating uranium makes me feel funny", said Tom glowingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981015, mal@bewoner.dma.be wrote: > Scwm Version post0.8a compiled on Oct 8 1998 at 14:23:33 > RCS_ID=$Id: scwm.c,v 1.139 1998/10/06 22:17:43 jtl Exp $ > Repository Timestamp: Wed Oct 7 20:40:33 EDT 1998 -- $Revision: 1.597 $ > > Backtrace: > #0 0x3e6e8 in mark_window (obj=1636968) at window.c:347 that's scm_gc_mark(psw->fl->scmdecor); can you print *psw and *psw->fl from the core? Have you made any .scwmrc changes recently? In particular, anything decor-related? > #4 0xef42e0f0 in scm_must_malloc (len=68, > what=0xef46ecc8 "inferior root continuation") at gc.c:1432 ... > #9 0x22c08 in call1_hooks (hook=485848, arg=1163800) at callbacks.c:342 > #10 0x1c650 in AddWindow (w=50331901) at add_window.c:265 ... Any chance a hook is being called with 'fl' on the new window in a bad state? before_new_window_hook is called before fl is set, but since NEW() uses calloc(), fl should be NULL before that, and this mark is guarded by a check against NULL. But maybe I've missed something? From owner-scwm-discuss@mit.edu Thu Oct 15 04:50:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA19829 for scwm-discuss-outgoing; Thu, 15 Oct 1998 04:50:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA19826 for ; Thu, 15 Oct 1998 04:50:04 -0400 From: mal@bewoner.dma.be Received: from dialup290.brussels.skynet.be by MIT.EDU with SMTP id AA28848; Thu, 15 Oct 98 04:48:44 EDT Received: (qmail 12418 invoked by uid 500); 15 Oct 1998 09:16:59 -0000 Date: 15 Oct 1998 09:16:58 -0000 Message-Id: <19981015091658.12407.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Todd Larason Cc: scwm-discuss list Subject: Re: core dump in garbage collection In-Reply-To: <19981015011749.A18461@molehill.org> References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981015, mal@bewoner.dma.be wrote: > > Scwm Version post0.8a compiled on Oct 8 1998 at 14:23:33 > > RCS_ID=$Id: scwm.c,v 1.139 1998/10/06 22:17:43 jtl Exp $ > > Repository Timestamp: Wed Oct 7 20:40:33 EDT 1998 -- $Revision: 1.597 $ > > > > Backtrace: > > #0 0x3e6e8 in mark_window (obj=1636968) at window.c:347 > > that's > scm_gc_mark(psw->fl->scmdecor); > can you print *psw and *psw->fl from the core? > *psw=$1 = {next = 0x0, prev = 0x0, w = 75506865, old_bw = 0, frame = 0, Parent = 0, title_w = 0, sides = {0, 0, 0, 0}, corners = {0, 0, 10612, 4026528788}, nr_left_buttons = 412, nr_right_buttons = 0, left_w = {0, 73, 0, 1630064, 441772}, right_w = {58720682, 0, 20972283, 20972284, 20972289}, fl = 0x1400305, icon_w = 20972294, icon_pixmap_w = 20972295, fShaped = 20972296, frame_x = 20972285, frame_y = 20972286, frame_width = 10612, frame_height = -268438508, pswci = 0x1c2, boundary_width = 0, xboundary_width = 20972291, corner_width = 73, bw = 0, title_x = 0, title_y = 0, title_height = 1568768, title_width = 20972290, icon_x_loc = 1581768, icon_xl_loc = 0, icon_y_loc = 0, icon_w_width = 442536, icon_w_height = 0, icon_t_width = 0, icon_p_height = 0, icon_p_width = 281, name = 0xba "", icon_name = 0x2974
, attr = {x = -268438508, y = 452, width = 0, height = 6, border_width = 73, depth = 1, visual = 0x0, root = 6, class = 1568768, bit_gravity = 610, win_gravity = 1581768, backing_store = 0, backing_planes = 0, backing_pixel = 54, save_under = 20, colormap = 27, map_installed = 54, map_state = 54, all_event_masks = 0, your_event_mask = 10612, do_not_propagate_mask = -268438508, override_redirect = 453, screen = 0x0}, hints = {flags = 644, x = 73, y = 8, width = 0, height = 41, min_width = 1568768, min_height = 0, max_width = 1581768, max_height = 0, width_inc = 0, height_inc = 0, min_aspect = {x = 0, y = 33}, max_aspect = {x = 1, y = 0}, base_width = 14909491, base_height = 10612, win_gravity = -268438508}, wmhints = 0x1c6, classhint = {res_name = 0x0, res_class = 0x358
}, Desk = 73, StartDesk = 0, FocusDesk = 0, DeIconifyDesk = 644, transientfor = 1568768, ttLastFocussed = 59, fStartIconic = 0, fOnTop = 0, fSticky = 0, fWindowListSkip = 0, fSuppressIcon = 0, fNoIconTitle = 0, fLenience = 0, fStickyIcon = 0, fCirculateSkip = 0, fCirculateSkipIcon = 0, fClickToFocus = 0, fSloppyFocus = 1, fShowOnMap = 1, fBorder = 0, fTitle = 0, fMapped = 0, fIconified = 0, fTransient = 0, fRaised = 1, fVisible = 0, fIconOurs = 0, fPixmapOurs = 0, fShapedIcon = 1, fMaximized = 0, fDoesWmTakeFocus = 1, fDoesWmDeleteWindow = 1, fIconMoved = 0, fIconUnmapped = 0, fMapPending = 1, fHintOverride = 0, fMWMButtons = 0, fMWMBorders = 0, fMWMFunctions = 0, fMWMDecor = 0, fDecorateTransient = 0, fWindowShaded = 0, fStartsOnDesk = 0, fRandomPlace = 0, fSmartPlace = 0, fOLDecorHint = 0, fNoPPosition = 0, fForceIcon = 0, mini_icon_image = 0, icon_req_image = 15, icon_image = 0, orig_width = 0, orig_height = 0, grav = {x = 0, y = 0, t = 0}, mwm_hints = 0x17, ol_hints = 10612, functions = -268438508, cmap_windows = 0x1c7, number_cmap_windows = 0, ReliefColor = 1549328, ShadowColor = 73, TextColor = 0, BackColor = 0, HiReliefColor = 0, HiShadowColor = 1568768, HiTextColor = 908438118, HiBackColor = 1581768, buttons = 3766484992, IconBox = {0, 1188520, 8564, 675}, other_properties = 674, schwin = 0} (gdb) print *psw->fl Cannot access memory at address 0x1400305. > Have you made any .scwmrc changes recently? In particular, anything > decor-related? > No, I don't use decoration. My .scwmrc is pretty much the default modulo some rebindings. > > #4 0xef42e0f0 in scm_must_malloc (len=68, > > what=0xef46ecc8 "inferior root continuation") at gc.c:1432 > ... > > #9 0x22c08 in call1_hooks (hook=485848, arg=1163800) at callbacks.c:342 > > #10 0x1c650 in AddWindow (w=50331901) at add_window.c:265 > ... > > Any chance a hook is being called with 'fl' on the new window in a bad > state? before_new_window_hook is called before fl is set, but since > NEW() uses calloc(), fl should be NULL before that, and this mark is > guarded by a check against NULL. But maybe I've missed something? > No hooks set either. From owner-scwm-discuss@mit.edu Thu Oct 15 06:32:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA20259 for scwm-discuss-outgoing; Thu, 15 Oct 1998 06:32:37 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA20256 for ; Thu, 15 Oct 1998 06:32:32 -0400 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Thu, 15 Oct 1998 11:31:03 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 43; Thu, 15 Oct 1998 11:30:52 GMT Date: Thu, 15 Oct 1998 11:30:49 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CDBB7.B8C1C68E.43@hermes.dra.hmg.gb> Subject: Pager induced crash. Sender: owner-scwm-discuss@mit.edu Precedence: bulk The crash occurs after stopping the pager, when it should have rmoved its hooks. I think I have got this wrong. The trigger for the crash is any event which would give a hook callback; usually an enter window. Here is the scheme code that the pager uploads; ; (define recbuf (make-string 1024 " ")) (define connect-pager (lambda () (let ((s (select (list pager-sock) (list ) (list ) 0 ))) (display s ) (newline) (if s (car (accept pager-sock)) #f )))) (sigaction SIGPIPE SIG_IGN) (define app-window "0") (define context "0") ; C_NO_CONTEXT (define sock-hook-handle #f) (define sock-broad-handle #f) (define sock-broad-c-handle #f) (define (shutdown-sock s) (display "Killing a connection")(newline) (catch #t (lambda() (close-port s) (if sock-hook-handle (remove-input-hook! sock-hook-handle)) (set! sock-hook-handle #f)) (lambda args args)) (display "Removed sock-hook-handle ")(newline) (catch #t (lambda() (if sock-broad-handle (remove-hook! broadcast-hook bhook)) (set! sock-broad-handle #f)) (lambda args args)) (display "Removed sock-broad-handle ")(newline) (catch #t (lambda() (if sock-broad-c-handle (remove-hook! broadcast-config-hook bchook)) (set! sock-broad-c-handle #f)) (lambda args args)) (display "Removed sock-broad-c-handle ")(newline) ) (define (mirror-add s) (let ((ss (select (list s) (list ) (list ) 0 ))) (if ss (let* ((nr (recv! s recbuf)) (x ( substring recbuf 0 nr))) (display x ) (newline) (if (string=? "Shutdown" x) (shutdown-sock s) (let ((st (select (list ) (list s) (list ) 0 ))) (if st (send s (string-append "Mirrored by scwm" x)) (shutdown-sock s) ) ) )) (shutdown-sock s)) ) ) (add-timer-hook! 400000 (lambda () (display "got a connection") (let* (( sock-pager (connect-pager)) (shandler (lambda () (catch #t (lambda()(mirror-add sock-pager)) (lambda args (display "Socket death :")(display args) (newline) (shutdown-sock sock-pager) )))) (bhook (lambda (type num-data . args) (catch #t (lambda() (let ((os (call-with-output-string (lambda (sock-port) (display type sock-port) (display " " sock-port) (display num-data sock-port) (display " " sock-port) (display args sock-port) (newline sock-port) )))) (send sock-pager os))) (lambda args (display "Socket death Broadcast") (newline) (shutdown-sock sock-pager) )))) (bchook (lambda (type window) (catch #t (lambda() (let* ((ws (window-size window)) (wp (window-position window)) (os (call-with-output-string (lambda (sock-port) (display type sock-port) (display " " sock-port) (display (window-id window) sock-port) (display " (" sock-port) (display (car wp) sock-port) (display " " sock-port) (display (cadr wp) sock-port) (display " " sock-port) (display (car ws) sock-port) (display " " sock-port) (display (cadr ws) sock-port) (display " " sock-port) (display (caddr ws) sock-port) (display " " sock-port) (display (cadddr ws) sock-port) (display " " sock-port) (display (window-desk window) sock-port) (display ")" sock-port) (newline sock-port) )))) (send sock-pager os))) (lambda args (display "Socket death Broadcast-c") (newline) (shutdown-sock sock-pager) )))) ) (display sock-pager) (newline) (if sock-pager (begin (display "Setting Up hooks") (newline) (set! sock-hook-handle (add-input-hook! sock-pager shandler)) (set! sock-broad-handle (add-hook! broadcast-hook bhook)) (set! sock-broad-c-handle (add-hook! broadcast-config-hook bchook)) (display "Set Up hooks") (newline) ) ) ) )) ---end of pager-support.scm and here is a backtrace from the core dump. If you want more detail please ask, without the pager I expect you can't reproduce the fault. Core was generated by `scwm'. Program terminated with signal 11, Segmentation fault. #0 0x4012b63b in scm_send () at socket.c:508 508 } #0 0x4012b63b in scm_send () at socket.c:508 #1 0x4010d6b5 in scm_gsubr_apply () at gsubr.c:156 #2 0x40104776 in scm_dapply () at eval.c:3232 #3 0x401039ac in scm_deval () at eval.c:3232 #4 0x401049bb in scm_dapply () at eval.c:3232 #5 0x400ffdf5 in scm_apply () at eval.c:1236 #6 0x40132b22 in scm_body_thunk () at throw.c:364 #7 0x401327be in scm_internal_catch () at throw.c:134 #8 0x40132de5 in scm_catch () at throw.c:500 #9 0x40103f09 in scm_deval () at eval.c:3232 #10 0x401049bb in scm_dapply () at eval.c:3232 #11 0x400ffdf5 in scm_apply () at eval.c:1236 #12 0x4010cbda in gh_apply () at gh_funcs.c:169 #13 0x80624da in scwm_body_apply (body_data=0xbfffefe8) at callbacks.c:84 #14 0x401329ac in scm_internal_lazy_catch () at throw.c:300 #15 0x40132aa8 in cwss_body () at throw.c:363 #16 0x401327be in scm_internal_catch () at throw.c:134 #17 0x40132af0 in scm_internal_stack_catch () at throw.c:364 #18 0x80624fc in cwssdr_body (data=0xbfffefb8) at callbacks.c:110 #19 0x401327be in scm_internal_catch () at throw.c:134 #20 0x401286bb in scm_internal_cwdr () at root.c:244 #21 0x8062538 in scm_internal_stack_cwdr (body=0x80624c8 , body_data=0xbfffefe8, handler=0x80623f0 , handler_data=0x8098876, stack_item=0xbfffefe4) at callbacks.c:126 #22 0x8062572 in scwm_safe_apply (proc=1076905616, args=1078540248) at callbacks.c:141 #23 0x8062a08 in apply_hooks (hook=1076392000, args=1078540248) at callbacks.c:403 #24 0x8071645 in Broadcast (event_type=1, num_datum=5, data1=0, data2=0, data3=0, data4=2048, data5=1536, data6=0, data7=0) at module-interface.c:43 #25 0x80780cc in MoveViewport_internal (newx=0, newy=0, grab=0) at virtual.c:382 #26 0x805c7e8 in ChangeVirtualPosition (vx=0, vy=0, fGrab=0) at add_window.c:105 #27 0x8078140 in MoveViewport (newx=0, newy=0, grab=0) at virtual.c:403 #28 0x807717f in Done (restart_or_dump=-1, command=0x0) at shutdown.c:75 #29 0x8076df4 in SigDoneSegv (nonsense=11) at scwm.c:1295 #30 0xbffff19c in ?? () #31 0x4010d6b5 in scm_gsubr_apply () at gsubr.c:156 #32 0x40104776 in scm_dapply () at eval.c:3232 #33 0x401039ac in scm_deval () at eval.c:3232 #34 0x401049bb in scm_dapply () at eval.c:3232 #35 0x400ffdf5 in scm_apply () at eval.c:1236 #36 0x40132b22 in scm_body_thunk () at throw.c:364 #37 0x401327be in scm_internal_catch () at throw.c:134 #38 0x40132de5 in scm_catch () at throw.c:500 #39 0x40103f09 in scm_deval () at eval.c:3232 #40 0x401049bb in scm_dapply () at eval.c:3232 #41 0x400ffdf5 in scm_apply () at eval.c:1236 #42 0x4010cbda in gh_apply () at gh_funcs.c:169 #43 0x80624da in scwm_body_apply (body_data=0xbffff74c) at callbacks.c:84 #44 0x401329ac in scm_internal_lazy_catch () at throw.c:300 #45 0x40132aa8 in cwss_body () at throw.c:363 #46 0x401327be in scm_internal_catch () at throw.c:134 #47 0x40132af0 in scm_internal_stack_catch () at throw.c:364 #48 0x80624fc in cwssdr_body (data=0xbffff71c) at callbacks.c:110 #49 0x401327be in scm_internal_catch () at throw.c:134 #50 0x401286bb in scm_internal_cwdr () at root.c:244 #51 0x8062538 in scm_internal_stack_cwdr (body=0x80624c8 , body_data=0xbffff74c, handler=0x80623f0 , handler_data=0x8098876, stack_item=0xbffff748) at callbacks.c:126 #52 0x8062572 in scwm_safe_apply (proc=1076905616, args=1078549456) at callbacks.c:141 #53 0x8062a08 in apply_hooks (hook=1076392000, args=1078549456) at callbacks.c:403 #54 0x8071645 in Broadcast (event_type=64, num_datum=5, data1=16777229, data2=37748935, data3=135908760, data4=65535, data5=50712, data6=0, data7=0) at module-interface.c:43 #55 0x806776e in HandleFocusIn () at events.c:361 #56 0x8067389 in DispatchEvent () at events.c:195 #57 0x80673ba in HandleEvents () at events.c:217 #58 0x80765f4 in scwm_main (argc=1, argv=0xbffffd08) at scwm.c:960 #59 0x8075a45 in scwm_gh_launch_pad (closure=0x8075a88, argc=1, argv=0xbffffd08) at scwm.c:432 #60 0x4010f151 in invoke_main_func (body_data=0xbffffcac) at init.c:538 #61 0x401327be in scm_internal_catch () at throw.c:134 #62 0x4010f100 in scm_boot_guile_1 (base=0xbffffca8, closure=0xbffffcac) at init.c:512 #63 0x4010eea5 in scm_boot_guile () at init.c:277 #64 0x8075a65 in scwm_gh_enter (argc=1, argv=0xbffffd08, c_main_prog=0x8075a88 ) at scwm.c:439 #65 0x8075a81 in main (argc=1, argv=0xbffffd08) at scwm.c:451 #66 0x805c58e in ___crt_dummy__ () Hope this helps. Julian Satchell From owner-scwm-discuss@mit.edu Thu Oct 15 10:36:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21302 for scwm-discuss-outgoing; Thu, 15 Oct 1998 10:36:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21299 for ; Thu, 15 Oct 1998 10:36:11 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16554; Thu, 15 Oct 98 10:35:00 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA15039; Thu, 15 Oct 1998 07:35:02 -0700 (PDT) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: maximise bug References: <27727.199810141244@penelope.ecs.soton.ac.uk> <19981015064459Z276517-271+10@pulsar.halcyon.com> From: Greg Badros Date: 15 Oct 1998 07:35:01 -0700 In-Reply-To: Ken Pizzini's message of "Wed, 14 Oct 1998 23:44:48 -0600" Message-Id: Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > On 14 Oct 1998 08:39:45 -0700, Greg Badros wrote: > >> I've just noticed a bug in scwm's maxise function - if the window > >> being maximised is partially off the left hand side of the screen, the > >> window is set to the correct size, but not placed in the center of the > >> screen... > > > >Same bug if the window is partially off the top side of the screen. > >There are a couple of cases missing in the maximize code in winops.scm, > >it appears. > > I didn't think of those cases as being an issue when making my > earlier changes to maximize... Attached is a patch to handle > these. Ok... I've patched and will commit sometime today. Greg From owner-scwm-discuss@mit.edu Thu Oct 15 10:41:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21331 for scwm-discuss-outgoing; Thu, 15 Oct 1998 10:41:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21328 for ; Thu, 15 Oct 1998 10:41:30 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA00498; Thu, 15 Oct 98 10:40:13 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA15042; Thu, 15 Oct 1998 07:40:17 -0700 (PDT) To: "merry::satchell"@hermes.dra.hmg.gb Cc: scwm-discuss@mit.edu Subject: Re: Pager induced crash. References: <009CDBB7.B8C1C68E.43@hermes.dra.hmg.gb> From: Greg Badros Date: 15 Oct 1998 07:40:17 -0700 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Thu, 15 Oct 1998 11:30:49 GMT" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > The crash occurs after stopping the pager, when it should have rmoved its > hooks. I think I have got this wrong. The trigger for the crash is any > event which would give a hook callback; usually an enter window. Could this be the old bug whereby guile crashes when hook procedures' arguments do not match the called-with arguments? (If yes, Maciej sent in a patch to the guile folks, but I don't know if it's yet been applied... any news?) If not, I'd have to look more carefully, but can't right now unfortunately. Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Thu Oct 15 10:48:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21404 for scwm-discuss-outgoing; Thu, 15 Oct 1998 10:48:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21401 for ; Thu, 15 Oct 1998 10:48:22 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA03248; Thu, 15 Oct 98 10:47:05 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA15049; Thu, 15 Oct 1998 07:46:55 -0700 (PDT) To: mal@bewoner.dma.be Cc: Todd Larason , scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> From: Greg Badros Date: 15 Oct 1998 07:46:55 -0700 In-Reply-To: mal@bewoner.dma.be's message of "15 Oct 1998 09:16:58 -0000" Message-Id: Lines: 41 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > Todd Larason writes: > > On 981015, mal@bewoner.dma.be wrote: > > > Scwm Version post0.8a compiled on Oct 8 1998 at 14:23:33 > > > RCS_ID=$Id: scwm.c,v 1.139 1998/10/06 22:17:43 jtl Exp $ > > > Repository Timestamp: Wed Oct 7 20:40:33 EDT 1998 -- $Revision: 1.597 $ > > > > > > Backtrace: > > > #0 0x3e6e8 in mark_window (obj=1636968) at window.c:347 > > > > that's > > scm_gc_mark(psw->fl->scmdecor); > > can you print *psw and *psw->fl from the core? > > > *psw=$1 = {next = 0x0, prev = 0x0, w = 75506865, old_bw = 0, frame = 0, Parent = 0, > fl = 0x1400305, icon_w = 20972294, icon_pixmap_w = 20972295, > (gdb) print *psw->fl > Cannot access memory at address 0x1400305. Doh! Looks like we're GCing in the before_new_window_hook, and we hadn't initialized psw->fl to &Scr.DefaultDecor yet. It's just a bad random luck thing which is why the bug didn't get noticed. Maybe we should have a build option that forces a GC at each hook invocation so we're sure data structures are stable then. Or just a way to reduce the heap size so GCs happen a *lot* more frequently so we increase our chances of finding these kinds of problems. I'll check in my fix shortly. Thanks for the bug report! Greg From owner-scwm-discuss@mit.edu Thu Oct 15 11:17:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22060 for scwm-discuss-outgoing; Thu, 15 Oct 1998 11:17:19 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA22057 for ; Thu, 15 Oct 1998 11:17:15 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA13441; Thu, 15 Oct 98 11:15:55 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22046; Thu, 15 Oct 1998 11:16:59 -0400 Message-Id: <199810151516.LAA22046@huis-clos.mit.edu> To: Greg Badros Cc: :"merry::satchell"@hermes.dra.hmg.gb Cc: scwm-discuss@mit.edu Subject: Re: Pager induced crash. In-Reply-To: Your message of "15 Oct 1998 07:40:17 PDT." Date: Thu, 15 Oct 1998 11:16:59 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > "merry::satchell"@hermes.dra.hmg.gb writes: > > > The crash occurs after stopping the pager, when it should have rmoved it > s > > hooks. I think I have got this wrong. The trigger for the crash is any > > event which would give a hook callback; usually an enter window. > > Could this be the old bug whereby guile crashes when hook procedures' > arguments do not match the called-with arguments? (If yes, Maciej sent > in a patch to the guile folks, but I don't know if it's yet been > applied... any news?) > The patch is now in Guile CVS; it should have been in 1.2.90 as well, I think. It was only added recently though. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 15 12:48:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22661 for scwm-discuss-outgoing; Thu, 15 Oct 1998 12:48:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22655 for ; Thu, 15 Oct 1998 12:48:00 -0400 Received: from sl35.modempool.kth.se by MIT.EDU with SMTP id AA02795; Thu, 15 Oct 98 12:46:49 EDT Received: by localhost via sendmail from stdin id (Debian Smail3.2.0.101) for scwm-discuss@mit.edu; Thu, 15 Oct 1998 18:49:37 +0200 (CEST) To: scwm-discuss@mit.edu Subject: sythetic events From: andersl@altavista.net (Anders Lannerbdck) Date: 15 Oct 1998 18:49:37 +0200 Message-Id: <8767dln526.fsf@altavista.net> Lines: 36 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried to make it easy to switch mouse hand using these lines in my .scwmrc: (define southpaw #t) (define (toggle-southpaw) (set! southpaw (not southpaw)) (let ((i (if southpaw 3 1)) (m 2) (a (if southpaw 1 3))) ;; (bind-mouse 'all i (lambda () (send-button-press 1 (get-window) #t #f))) ;; (bind-mouse 'all m (lambda () (send-button-press 2 (get-window) #t #f))) ;; (bind-mouse 'all a (lambda () (send-button-press 3 (get-window) #t #f))) (bind-mouse 'root a popup-util) (bind-mouse 'root m popup-ops) (bind-mouse 'root i (lambda () (show-window-list-menu #:show-geometry #t))) (bind-mouse 'icon i move-or-deiconify) (bind-mouse 'icon m deiconify) (bind-mouse '(frame sidebar title) a popup-ops) (bind-mouse 'frame i resize-or-raise) (bind-mouse 'sidebar i move-or-raise) )) (toggle-southpaw) ;set to right handed initially. However, I can not make the three commented lines to work. The problem is that I need to bind the button-release too, but that isn't possible with 'bind-mouse', is it? So now I wonder: Can I, and if so how, bind a mouse-button-release event? BTW, thank you for the very best WM around! -- =============================== ANDERS LANNERBDCK ============================== ====================== email: andersl@altavista.net ====================== =============== URL: http://www.student.nada.kth.se/~f95-ala =============== From owner-scwm-discuss@mit.edu Thu Oct 15 14:00:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA23159 for scwm-discuss-outgoing; Thu, 15 Oct 1998 14:00:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA23156 for ; Thu, 15 Oct 1998 14:00:20 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA27280; Thu, 15 Oct 98 13:59:08 EDT Received: (qmail 20900 invoked by uid 501); 15 Oct 1998 17:59:10 -0000 Message-Id: <19981015105909.A20827@molehill.org> Date: Thu, 15 Oct 1998 10:59:09 -0700 From: Todd Larason To: Greg Badros , mal@bewoner.dma.be Cc: scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Oct 15, 1998 at 07:46:55AM -0700 X-Tom-Swifty: "Just what kind of show can this troupe 'The Humpty Dumpties' put on?" asked Tom exactingly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981015, Greg Badros wrote: > mal@bewoner.dma.be writes: > > > (gdb) print *psw->fl > > Cannot access memory at address 0x1400305. > > Doh! Looks like we're GCing in the before_new_window_hook, and we hadn't > initialized psw->fl to &Scr.DefaultDecor yet. right, but there was a psw = NEW(ScwmWindow) not far before that, and NEW allocates with calloc(), which should clear the new object to all 0s. The line that crashed is the middle one in if (psw->fl != NULL) { scm_gc_mark(psw->fl->scmdecor); } . The fl initialization probably should move, but I'm afraid that will just mask some other bug. From owner-scwm-discuss@mit.edu Thu Oct 15 14:45:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA23392 for scwm-discuss-outgoing; Thu, 15 Oct 1998 14:45:47 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA23389 for ; Thu, 15 Oct 1998 14:45:42 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA13609; Thu, 15 Oct 98 14:44:31 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA16723; Thu, 15 Oct 1998 11:44:28 -0700 (PDT) To: Todd Larason Cc: mal@bewoner.dma.be, scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> <19981015105909.A20827@molehill.org> From: Greg Badros Date: 15 Oct 1998 11:44:27 -0700 In-Reply-To: Todd Larason's message of "Thu, 15 Oct 1998 10:59:09 -0700" Message-Id: Lines: 27 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > > Doh! Looks like we're GCing in the before_new_window_hook, and we hadn't > > initialized psw->fl to &Scr.DefaultDecor yet. > > right, but there was a psw = NEW(ScwmWindow) not far before that, and > NEW allocates with calloc(), which should clear the new object to all > 0s. The line that crashed is the middle one in > if (psw->fl != NULL) { > scm_gc_mark(psw->fl->scmdecor); > } > . > > The fl initialization probably should move, but I'm afraid that will > just mask some other bug. Yea, you're right. There's an interesting relationship between masking other bugs and defensive programming, though. My guess is that the munging of fl happened in the code that the before-new-window-hook invokes (e.g., one of the window-hint hooks), so maybe this won't mask the problem there. I'm pretty sure that psw->fl should never be NULL, and that the GC code is just being safe (as the GC_MARK_SCM_IF_SET macro does throughout lots of the mark procedures). So, I suppose this is still an open issue... Greg From owner-scwm-discuss@mit.edu Thu Oct 15 23:39:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26556 for scwm-discuss-outgoing; Thu, 15 Oct 1998 23:39:40 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA26552 for ; Thu, 15 Oct 1998 23:39:35 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA03997; Thu, 15 Oct 98 23:38:24 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA26546; Thu, 15 Oct 1998 23:39:32 -0400 Message-Id: <199810160339.XAA26546@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Procedures that return predicates Date: Thu, 15 Oct 1998 23:39:31 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am soon going to start commiting a rewrite of the scwm window style code soon (still on my branch, but my papers should be processed soon). This will address many long-needed changes, among other things, it warn about mis-typed style options, not use more and more memory if you change styles a lot (a key thing if we ever want to have theme support where you can freely change themes every day while running the window manager for weeks), support themes in the sense of self-contained tarballs which contain some scheme code and some image files which can be loaded to set various aspects of the look (supporting foreign theme formats is also important - we should have a discussion at some point of the best way to do that), and allow a greater selection of convenient ways to choose windows for styling. One problem with the last of these is that I've ended up writing a lot of procedures that return predicates on windows. For example (title-regexp ".*[Nn]etscape.*") returns a predicate which returns true for any window with a title that contains "Netscape" or "netscape"; (hostname-exact "foo.ai.mit.edu") will match any window running on a machine named exactly "foo.ai.mit.edu" and so on. I am very happy with the fact that predicates have the convention in Scheme of ending in a `?' character, and unhappy with the fact that meta-predicates, as one might call them, do not. I'd like them to also stand out. I can think of several options: * Just don't name them specially. * End them with a single question mark and ignore the fact that this is not technically correct. * End them with two question marks - I have seen this convention elsewhere. It seems a bit weird, but vaguely makes sense in a way. * Something else entirely that I haven't thought of yet. Does anyone have thoughts or suggestions? I know this is kind of a silly point to worry about, but I am pretty sensitive about naming issues because I think the real power in a programmable tool like scwm is in the usability of its APIs, not just the power of the primitives. There's a lot of stuff I used to show off as features of scwm like multiple window decoration styles, and changing these on the fly, that could have been done with fvwm2 if you really tried, but it would have been so painful that no one bothered. No one ever called me on this. I have to conclude that the power really is in the API. Pardon my lengthy spew here, but my point is, if you have a thought about naming of higher order predicates, please let me know. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 00:52:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA26890 for scwm-discuss-outgoing; Fri, 16 Oct 1998 00:52:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA26887 for ; Fri, 16 Oct 1998 00:52:50 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18161; Fri, 16 Oct 98 00:51:40 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id VAA07690; Thu, 15 Oct 1998 21:51:35 -0700 (PDT) To: andersl@altavista.net (Anders Lannerbdck) Cc: scwm-discuss@mit.edu Subject: Re: sythetic events References: <8767dln526.fsf@altavista.net> From: Greg Badros Date: 15 Oct 1998 21:51:34 -0700 In-Reply-To: andersl@altavista.net's message of "15 Oct 1998 18:49:37 +0200" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk andersl@altavista.net (Anders Lannerbdck) writes: > However, I can not make the three commented lines to work. The problem is that I > need to bind the button-release too, but that isn't possible with 'bind-mouse', > is it? So now I wonder: Can I, and if so how, bind a mouse-button-release event? Nope... you'll need to wait for the event rewrite, I think. Though if you're just trying to swap mouse buttons around, what's wrong with just using xmodmap -e "pointer = 1 2 3" vs. xmodmap -e "pointer = 3 2 1"? > > BTW, thank you for the very best WM around! Glad you like! :-) Greg From owner-scwm-discuss@mit.edu Fri Oct 16 05:07:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA29454 for scwm-discuss-outgoing; Fri, 16 Oct 1998 05:07:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id FAA29451 for ; Fri, 16 Oct 1998 05:07:38 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA14402; Fri, 16 Oct 98 05:06:24 EDT Received: (qmail 1177 invoked by uid 501); 16 Oct 1998 09:06:37 -0000 Message-Id: <19981016020635.A1150@molehill.org> Date: Fri, 16 Oct 1998 02:06:35 -0700 From: Todd Larason To: scwm-discuss list Subject: pie menu module Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "The transit system could reduce its deficit by steeply charging those passengers on their way to rock concerts and sports events", said Tom with considerable fanfare. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've just committed a first cut at a pie menu module. (use-module (app scwm pie-menus)) (set-menu-look! pie-menu-look) to use them. There's at least one flat-out bug in the layout code, and not-yet implemented features include: score lines between pie slices; menu title; packground and side pixmaps. There's no current analogy to the normal menu's pop-right menus. I don't find piewm's very convenient in my (very limited) testing, and am not sure they can be made to work well. And the code's ugly as all get out. I'll work on all of that as time permits. Everyone else should feel free to too, of course. From owner-scwm-discuss@mit.edu Fri Oct 16 09:30:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA30443 for scwm-discuss-outgoing; Fri, 16 Oct 1998 09:30:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA30440 for ; Fri, 16 Oct 1998 09:30:03 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA19128; Fri, 16 Oct 98 09:28:47 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 09:28:37 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 09:28:37 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id JAA28754; Fri, 16 Oct 1998 09:28:45 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Thu, 15 Oct 1998 23:39:31 EDT" Date: 16 Oct 1998 09:28:45 -0400 Message-Id: Lines: 44 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810160339.XAA26546@huis-clos.mit.edu> >>>> Sent on Thu, 15 Oct 1998 23:39:31 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Procedures that return predicates": >> >> * End them with two question marks - I have seen this convention >> elsewhere. It seems a bit weird, but vaguely makes sense in a way. sounds good to me. >> I know this is kind of a silly point to worry about, but I am pretty >> sensitive about naming issues because I think the real power in a >> programmable tool like scwm is in the usability of its APIs, not just >> the power of the primitives. Sure. What about interactive-move/resize? you planned to make it opaque depending on the predicates move/resize-opaquely?, but you were away, and Greg introduced an extra level of calls, creating scheme procedures interactive-move/resize-maybe-opaque, which do what interactive-move/resize were supposed to do. now, despite (define (resize-opaquely? win) #t) (define (move-opaquely? win) #t) some of my moves/resizes are opaque (those I bind to interactive-move/resize-maybe-opaque in .scwmrc) and some rubberband (those bound to interactive-move/resize in a system file, like mouse-1/2 on the title bar etc). Is there a chance that you will ditch interactive-move/resize-maybe-opaque in favor of previously announced behavior of interactive-move/resize? Thanks. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Never succeed from the first try - if you do, nobody will think it was hard. From owner-scwm-discuss@mit.edu Fri Oct 16 10:08:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30657 for scwm-discuss-outgoing; Fri, 16 Oct 1998 10:08:14 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA30654 for ; Fri, 16 Oct 1998 10:08:08 -0400 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA04912; Fri, 16 Oct 98 10:06:52 EDT Received: by tis.bellhow.com; id KAA09713; Fri, 16 Oct 1998 10:06:47 -0400 (EDT) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma009625; Fri, 16 Oct 98 10:05:49 -0400 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id KAA01203 for ; Fri, 16 Oct 1998 10:05:48 -0400 (EDT) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates Date: Fri, 16 Oct 1998 14:05:48 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <36274da1.55145324@smtp> References: <199810160339.XAA26546@huis-clos.mit.edu> In-Reply-To: <199810160339.XAA26546@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id KAA30655 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, 15 Oct 1998 23:39:31 EDT, you wrote: >* End them with two question marks - I have seen this convention >elsewhere. It seems a bit weird, but vaguely makes sense in a way. I like this. One of the good things about scheme is the regularity of names. Seeing '!' '?' or '->' in a name really helps understanding of unfamiliar code. (and scheme is still very unfamiliar to me) >I know this is kind of a silly point to worry about, but I am pretty >sensitive about naming issues because I think the real power in a >programmable tool like scwm is in the usability of its APIs, not just >the power of the primitives. There's a lot of stuff I used to show off >as features of scwm like multiple window decoration styles, and >changing these on the fly, that could have been done with fvwm2 if you >really tried, but it would have been so painful that no one >bothered. No one ever called me on this. I have to conclude that the >power really is in the API. Naming is *very* important. Please be even more sensitive and picky if you can! Scwm needs not only to be powerful, but also intuitive. Dale From owner-scwm-discuss@mit.edu Fri Oct 16 10:55:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30974 for scwm-discuss-outgoing; Fri, 16 Oct 1998 10:55:09 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA30970 for ; Fri, 16 Oct 1998 10:55:06 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA17992; Fri, 16 Oct 98 10:53:51 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA30965; Fri, 16 Oct 1998 10:55:02 -0400 Message-Id: <199810161455.KAA30965@huis-clos.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates In-Reply-To: Your message of "16 Oct 1998 09:28:45 EDT." Date: Fri, 16 Oct 1998 10:55:02 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > What about interactive-move/resize? Yep, I am working on this too. My plans are: Primitives: rubberband-{move,resize} #&optional WIN opaque-{move,resize} #&optional WIN Higher level: interactive-{move,resize} #&optionl WIN (OPAQUE? ({move,resize}-opaquely? WIN)) > you planned to make it opaque depending on the predicates > move/resize-opaquely?, but you were away, and Greg introduced an extra > level of calls, creating scheme procedures > interactive-move/resize-maybe-opaque, which do what > interactive-move/resize were supposed to do. > now, despite > > (define (resize-opaquely? win) #t) > (define (move-opaquely? win) #t) > > some of my moves/resizes are opaque (those I bind to > interactive-move/resize-maybe-opaque in .scwmrc) and some rubberband > (those bound to interactive-move/resize in a system file, like mouse-1/2 > on the title bar etc). Hmm, I think I know what is causing that and how to fix it. > Is there a chance that you will ditch > interactive-move/resize-maybe-opaque in favor of previously announced > behavior of interactive-move/resize? Yep, it's in my working dir, I just want to get the bigger changes of the style stuff checked in and merge the head onto my personal branch first (to make merging my branch back later easier). - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 11:04:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31046 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:04:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31043 for ; Fri, 16 Oct 1998 11:04:46 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA24109; Fri, 16 Oct 98 11:03:30 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20020; Fri, 16 Oct 1998 08:03:28 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 08:03:28 -0700 In-Reply-To: Maciej Stachowiak's message of "Thu, 15 Oct 1998 23:39:31 EDT" Message-Id: Lines: 15 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > * End them with a single question mark and ignore the fact that this > is not technically correct. Absolutely bad. > * End them with two question marks - I have seen this convention > elsewhere. It seems a bit weird, but vaguely makes sense in a way. Seems fine. And we should explain our conventions (even if lots are inherited from the Scheme community -- many of our users aren't necessarily in the know about this stuff (I know I'm still learning). Greg From owner-scwm-discuss@mit.edu Fri Oct 16 11:07:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31085 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:07:59 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31082 for ; Fri, 16 Oct 1998 11:07:56 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22469; Fri, 16 Oct 98 11:06:42 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20023; Fri, 16 Oct 1998 08:06:40 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 08:06:40 -0700 In-Reply-To: Sam Steingold's message of "16 Oct 1998 09:28:45 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > What about interactive-move/resize? > you planned to make it opaque depending on the predicates > move/resize-opaquely?, but you were away, and Greg introduced an extra > level of calls, creating scheme procedures > interactive-move/resize-maybe-opaque, which do what > interactive-move/resize were supposed to do. > now, despite > > (define (resize-opaquely? win) #t) > (define (move-opaquely? win) #t) > > some of my moves/resizes are opaque (those I bind to > interactive-move/resize-maybe-opaque in .scwmrc) and some rubberband > (those bound to interactive-move/resize in a system file, like mouse-1/2 > on the title bar etc). But I want to be able to do exactly that--sometimes say I want an opaque move, and for other bindings I want a rubberband move. I can live with a rename as long as I still have a primitive (or primitives) that let me override my {resize,move}-opaquely? predicate at bind time. Greg From owner-scwm-discuss@mit.edu Fri Oct 16 11:13:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31189 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:13:23 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31186 for ; Fri, 16 Oct 1998 11:13:22 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27327; Fri, 16 Oct 98 11:12:06 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20034; Fri, 16 Oct 1998 08:12:07 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161455.KAA30965@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 08:12:06 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 10:55:02 EDT" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > sds@goems.com writes: > > > > What about interactive-move/resize? > > Yep, I am working on this too. My plans are: > > Primitives: > > rubberband-{move,resize} #&optional WIN > opaque-{move,resize} #&optional WIN > > Higher level: > > interactive-{move,resize} #&optionl WIN > (OPAQUE? ({move,resize}-opaquely? WIN)) Looks good. Greg From owner-scwm-discuss@mit.edu Fri Oct 16 11:15:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31238 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:15:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31232 for ; Fri, 16 Oct 1998 11:15:48 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA25230; Fri, 16 Oct 98 11:14:33 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 11:14:22 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 11:14:22 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id LAA29405; Fri, 16 Oct 1998 11:14:29 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161455.KAA30965@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 10:55:02 EDT" Date: 16 Oct 1998 11:14:29 -0400 Message-Id: Lines: 58 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810161455.KAA30965@huis-clos.mit.edu> >>>> Sent on Fri, 16 Oct 1998 10:55:02 EDT >>>> Honorable Maciej Stachowiak writes >>>> on the subject of "Re: Procedures that return predicates": >> sds@goems.com writes: >> > >> > What about interactive-move/resize? >> >> Yep, I am working on this too. My plans are: >> >> Primitives: >> >> rubberband-{move,resize} #&optional WIN >> opaque-{move,resize} #&optional WIN >> >> Higher level: >> >> interactive-{move,resize} #&optionl WIN >> (OPAQUE? ({move,resize}-opaquely? WIN)) great! A couple of remarks: 1. The last line should probably read: interactive-{move,resize} #&optionl (WIN (get-window)) (OPAQUE? ({move,resize}-opaquely? WIN)) or something similar since otherwise WIN could be nil, in which case {move,resize}-opaquely? would be called with a non-window argument. 2. It could be argued that there should be a more consistent naming: either rubberband-{move,resize} opaque-{move,resize} interactive-{move,resize} opaque-{move,resize}? or {move,resize}-rubberband {move,resize}-opaque {move,resize}-interactive {move,resize}-opaque? advantages - more reasonable `apropos' output disadvantages - little difference between `{move,resize}-opaque' and `{move,resize}-opaque?'. Thanks. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Computer are like air conditioners: they don't work with open windows! From owner-scwm-discuss@mit.edu Fri Oct 16 11:25:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31430 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:25:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA31425 for ; Fri, 16 Oct 1998 11:25:32 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 11:23:54 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 11:23:54 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id LAA29412; Fri, 16 Oct 1998 11:24:02 -0400 To: Maciej Stachowiak Subject: scwm-procedures.txt Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 16 Oct 1998 11:24:01 -0400 Message-ID: Lines: 19 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Since recently, the file reference in scwm-procedures.txt changed: it is now "[From ../scwm/window.c:687]" instead of "[From scwm/window.c:687]". This broke mouse2 in emacs 20.3 (which took you directly to the definition of the function in the appropriate file), since it expects the path to be relative the top of the source tree, not a subdirectory thereof. While it is trivial to fix this in scwm.el, it is my opinion that it is better to revert to the original behavior, when the paths in scwm-procedures.txt were relative to the top of the source tree. Comments? BTW, is anyone using scwm.el with e20.3? Trust me, it's worth upgrading! :-) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Bus error -- driver executed. From owner-scwm-discuss@mit.edu Fri Oct 16 11:37:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31606 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:37:50 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31603 for ; Fri, 16 Oct 1998 11:37:47 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA03148; Fri, 16 Oct 98 11:36:26 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 11:36:17 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 11:36:17 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id LAA29474; Fri, 16 Oct 1998 11:36:24 -0400 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "16 Oct 1998 08:06:40 -0700" Date: 16 Oct 1998 11:36:24 -0400 Message-Id: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: Procedures that return predicates" >>>> Sent on 16 Oct 1998 08:06:40 -0700 >>>> Honorable Greg Badros writes: >> Sam Steingold writes: >> >> > What about interactive-move/resize? >> > you planned to make it opaque depending on the predicates >> > move/resize-opaquely?, but you were away, and Greg introduced an extra >> > level of calls, creating scheme procedures >> > interactive-move/resize-maybe-opaque, which do what >> > interactive-move/resize were supposed to do. >> > now, despite >> > >> > (define (resize-opaquely? win) #t) >> > (define (move-opaquely? win) #t) >> > >> > some of my moves/resizes are opaque (those I bind to >> > interactive-move/resize-maybe-opaque in .scwmrc) and some rubberband >> > (those bound to interactive-move/resize in a system file, like mouse-1/2 >> > on the title bar etc). >> >> But I want to be able to do exactly that--sometimes say I want an opaque >> move, and for other bindings I want a rubberband move. I can live with >> a rename as long as I still have a primitive (or primitives) that let me >> override my {resize,move}-opaquely? predicate at bind time. I think Maciej's model answers your needs - just bind to rubberband-{move,resize} #&optional WIN opaque-{move,resize} #&optional WIN -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A year spent in artificial intelligence is enough to make one believe in God. From owner-scwm-discuss@mit.edu Fri Oct 16 11:47:00 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31752 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:47:00 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31749 for ; Fri, 16 Oct 1998 11:46:58 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA10081; Fri, 16 Oct 98 11:45:42 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20659; Fri, 16 Oct 1998 08:45:41 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161455.KAA30965@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 08:45:39 -0700 In-Reply-To: Sam Steingold's message of "16 Oct 1998 11:14:29 -0400" Message-Id: Lines: 42 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > 2. It could be argued that there should be a more consistent > naming: either > > rubberband-{move,resize} > opaque-{move,resize} > interactive-{move,resize} > opaque-{move,resize}? > > or > > {move,resize}-rubberband > {move,resize}-opaque > {move,resize}-interactive > {move,resize}-opaque? > > advantages - more reasonable `apropos' output > disadvantages - little difference between `{move,resize}-opaque' and > `{move,resize}-opaque?'. What about the names for the non-interactive moves and resizes? Note that there are several orthogonal issues. For moves: * viewport-position-specified? (as opposed to virtual) * animated? * move-pointer-too? For resizes: * frame-size-specified? (as opposed to client window size) * pixel-size-specified? (as opposed to client units) * animated? (not implemented, but it'd be easy enough) * respect-gravity? (or force a specific kind of gravity) (note that using gravity means resizes can also result in a moves) * move-pointer-too? (maybe to preserve the pointer inside the window if the window is resized smaller -- useful for focus-follows mouse) Greg From owner-scwm-discuss@mit.edu Fri Oct 16 11:51:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA31821 for scwm-discuss-outgoing; Fri, 16 Oct 1998 11:51:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA31818 for ; Fri, 16 Oct 1998 11:51:35 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07794; Fri, 16 Oct 98 11:50:20 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA20942; Fri, 16 Oct 1998 08:50:18 -0700 (PDT) To: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 08:50:17 -0700 In-Reply-To: Sam Steingold's message of "16 Oct 1998 11:36:24 -0400" Message-Id: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > I think Maciej's model answers your needs - just bind to > > rubberband-{move,resize} #&optional WIN > opaque-{move,resize} #&optional WIN Yep. Greg From owner-scwm-discuss@mit.edu Fri Oct 16 12:26:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32269 for scwm-discuss-outgoing; Fri, 16 Oct 1998 12:26:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32265 for ; Fri, 16 Oct 1998 12:26:54 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA23695; Fri, 16 Oct 98 12:25:37 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA24650; Fri, 16 Oct 1998 09:25:35 -0700 (PDT) To: Maciej Stachowiak Subject: Re: scwm-procedures.txt References: From: Greg Badros Date: 16 Oct 1998 09:25:34 -0700 In-Reply-To: Sam Steingold's message of "16 Oct 1998 11:24:01 -0400" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > Since recently, the file reference in scwm-procedures.txt changed: it is > now "[From ../scwm/window.c:687]" instead of "[From scwm/window.c:687]". I've changed the makefile rules to get this back to the old (right, IMO too) behaviour. > BTW, is anyone using scwm.el with e20.3? > Trust me, it's worth upgrading! :-) Ahhh, if only it were easy to upgrade-- my configuration doesn't work with GNU Emacs 20.3. I'm not convinced that I'd want to give up a bunch of the XEmacs features I really like, anyway. Again, great job on the Emacs interface to scwm -- it definitely makes a world of difference in the usability of the system! Greg From owner-scwm-discuss@mit.edu Fri Oct 16 12:36:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32458 for scwm-discuss-outgoing; Fri, 16 Oct 1998 12:36:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32446; Fri, 16 Oct 1998 12:35:42 -0400 Message-Id: <199810161635.MAA32446@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates In-reply-to: Your message of "16 Oct 1998 08:03:28 PDT." Date: Fri, 16 Oct 1998 12:35:42 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > * End them with a single question mark and ignore the fact that this > > is not technically correct. > > Absolutely bad. > I generally agree, but I _have_ seen code that does it. > > * End them with two question marks - I have seen this convention > > elsewhere. It seems a bit weird, but vaguely makes sense in a way. > > Seems fine. And we should explain our conventions (even if lots are > inherited from the Scheme community -- many of our users aren't > necessarily in the know about this stuff (I know I'm still learning). > I'm working on documenting various naming and interface conventions, both ones we already more or less use, and ones we should use. I will include even ones that might be considered "obvious" from a Scheme point of view. At least some of the naming convention documentation should percolate into the user docs at some point. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 12:37:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32504 for scwm-discuss-outgoing; Fri, 16 Oct 1998 12:37:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32493 for ; Fri, 16 Oct 1998 12:37:01 -0400 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27261; Fri, 16 Oct 98 12:35:43 EDT Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA25476; Fri, 16 Oct 1998 09:35:37 -0700 (PDT) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: scwm/doc/Makefile.am From: Greg Badros Date: 16 Oct 1998 09:35:32 -0700 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I made some changes to the doc/Makefile.am's build lines for scwm.sgml to run it from the top level so the filenames are scheme/base.scm, not ../scheme/base.scm. Perhaps you could look at the new version and see if it'll still work for your building in a separate directory. (Or let me know how you run configure and I can test it). In particular, I'm pretty skeptical that my change to use: outdir=$$PWD/$(top_builddir)/$(subdir); \ will work if top_builddir is not relative (for me, it's .., as is top_srcdir). Not sure what the best way to manage this is.... perhaps you have some suggestions? Thanks, Greg From owner-scwm-discuss@mit.edu Fri Oct 16 12:54:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA32664 for scwm-discuss-outgoing; Fri, 16 Oct 1998 12:54:35 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA32661 for ; Fri, 16 Oct 1998 12:54:32 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA02953; Fri, 16 Oct 98 12:53:15 EDT Received: (csk@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA12375; Fri, 16 Oct 1998 09:53:14 -0700 (PDT) From: csk@cs.washington.edu (Craig Kaplan) Message-Id: <199810161653.JAA12375@fielder.cs.washington.edu> Subject: Re: Procedures that return predicates To: mstachow@mit.edu (Maciej Stachowiak) Date: Fri, 16 Oct 1998 09:53:12 -0700 (PDT) Cc: scwm-discuss@mit.edu In-Reply-To: <199810160339.XAA26546@huis-clos.mit.edu> from "Maciej Stachowiak" at Oct 15, 98 11:39:31 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk > One problem with the last of these is that I've ended up writing a lot > of procedures that return predicates on windows. For example > (title-regexp ".*[Nn]etscape.*") returns a predicate which returns > true for any window with a title that contains "Netscape" or > "netscape"; (hostname-exact "foo.ai.mit.edu") will match any window > running on a machine named exactly "foo.ai.mit.edu" and so on. > > I am very happy with the fact that predicates have the convention in > Scheme of ending in a `?' character, and unhappy with the fact that > meta-predicates, as one might call them, do not. I'd like them to also > stand out. I can think of several options: > > * Just don't name them specially. > > * End them with a single question mark and ignore the fact that this > is not technically correct. > > * End them with two question marks - I have seen this convention > elsewhere. It seems a bit weird, but vaguely makes sense in a way. > > * Something else entirely that I haven't thought of yet. > > Does anyone have thoughts or suggestions? I have one not very useful thought. I doubt you'll get much mileage out of this, but it's what popped into my head when I read this. Hey -- maybe it will inspire you... What you want is very similar to ML style currying of functions. In ML, a function of two arguments is transparently encoded as a function of one argument that returns a function of one argument. So, for example, I could write fun title_regex_eq rx title = (* return true iff rx matches title *) val my_rx = ".*[Nn]etscape.*"; val my_title = window_title (select_window_interactively()); I could then make an "ordinary" call to title_regex_eq: if title_regex_eq my_rx my_title then ... But I could also do this: val my_pred = title_regex_eq my_rx The object "my_pred" is now a function of one argument ("title") that matches title against the reg. exp. ".*[Nn]etscape.*". title_regex_eq has been partially evaluated at its first argument position. This makes for very elegant code. Currying makes for very elegant uses of higher-order functions like map. I'm not sure how much of this can be translated to Scheme, althouh one could certainly imagine something like (define (uncurry2 func arg1) (lambda (arg2) (func arg1 arg2))) It may also be possible to encode this in a more flexible and prettier macro. If you had this function, you would at least have created a general mechanism that alleviates the need for creating all sorts of meta-predicates. You can revert to keeping around the more natural two-argument versions, and use the uncurry mechanism when needed to build regular predicates. Hope this is useful. -- Craig. http://www.cs.washington.edu/homes/csk/ Counterfactuals: what would the world be like without them? From owner-scwm-discuss@mit.edu Fri Oct 16 13:12:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00078 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:12:55 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00070; Fri, 16 Oct 1998 13:12:51 -0400 Message-Id: <199810161712.NAA00070@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates In-reply-to: Your message of "16 Oct 1998 11:14:29 EDT." Date: Fri, 16 Oct 1998 13:12:51 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > A couple of remarks: > > 1. The last line should probably read: > > interactive-{move,resize} #&optionl (WIN (get-window)) > (OPAQUE? ({move,resize}-opaquely? WIN)) > > or something similar since otherwise WIN could be nil, in which case > {move,resize}-opaquely? would be called with a non-window argument. > Yeah, that's what I meant, I was just too lazy to include that bit. I think get-window actually needs some magical arguments there, but that's a minor issue. I am starting to think more and more that the window defaulting stuff is a hack. It should be easier to get rid of entirely once we do the event rewrite as planned, though. > 2. It could be argued that there should be a more consistent > naming: either > > rubberband-{move,resize} > opaque-{move,resize} > interactive-{move,resize} > opaque-{move,resize}? > > or > > {move,resize}-rubberband > {move,resize}-opaque > {move,resize}-interactive > {move,resize}-opaque? > > advantages - more reasonable `apropos' output > disadvantages - little difference between `{move,resize}-opaque' and > `{move,resize}-opaque?'. > I think it is OK for related actions and predicates to have differently ordered names. For example, if we had an opration called transmorgiy-window, I'd think a matching window-transmorgified? predicate would be OK. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 13:13:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00095 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:13:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00090 for ; Fri, 16 Oct 1998 13:13:27 -0400 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA09000; Fri, 16 Oct 98 13:11:55 EDT Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id KAA29312 for ; Fri, 16 Oct 1998 10:11:50 -0700 (PDT) Date: Fri, 16 Oct 1998 10:11:50 -0700 (PDT) From: Jeffrey Nichols To: scwm-discuss@mit.edu Subject: Make problem Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just updated via cvs, changed.c gives: char *szRepoLastChanged = "Fri Oct 16 12:33:24 EDT 1998 -- $Revision: 1.676 $"; When I run autogen.sh I get: modules/Makefile.am:194: required directory modules/overlay-plane does not exist modules/Makefile.am:194: required directory modules/pie-menus does not exist configure.in: 470: required file `utilities/dev/scwmdoc.in' not found configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found If I ignore that and run make, it reconfigures and then apperas to build fine. make install and make clean fail however for the same reason as about. It appears to me that the distribution is looking for 'scwm/modules/pie-menus' when it should actually be looking for 'scwm/scwm/modules/pie-menus' (which does exist). I'm not too familiar with the directory structure, so I'm not sure if this is a problem with the recent changes to the Makefile or if perhaps the new directories got put in the wrong place. -Jeff From owner-scwm-discuss@mit.edu Fri Oct 16 13:23:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00260 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:23:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00257 for ; Fri, 16 Oct 1998 13:23:55 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA12416; Fri, 16 Oct 98 13:22:37 EDT Received: (qmail 5533 invoked by uid 501); 16 Oct 1998 17:22:37 -0000 Message-Id: <19981016102236.A5506@molehill.org> Date: Fri, 16 Oct 1998 10:22:36 -0700 From: Todd Larason To: Jeffrey Nichols , scwm-discuss@mit.edu Subject: Re: Make problem References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jeffrey Nichols on Fri, Oct 16, 1998 at 10:11:50AM -0700 X-Tom-Swifty: "I love hot dogs", said Tom with relish. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981016, Jeffrey Nichols wrote: > I just updated via cvs, changed.c gives: did you use the '-d' option for update, to create new directories? > modules/Makefile.am:194: required directory modules/overlay-plane does not exist > modules/Makefile.am:194: required directory modules/pie-menus does not exist Those directories are both there. overlay-plane for about a week, and pie-menus since last night. > configure.in: 470: required file `utilities/dev/scwmdoc.in' not found > configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found and those are ignorable From owner-scwm-discuss@mit.edu Fri Oct 16 13:24:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00278 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:24:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00274 for ; Fri, 16 Oct 1998 13:24:10 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA08767; Fri, 16 Oct 98 13:22:55 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13009; Fri, 16 Oct 1998 10:22:52 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161635.MAA32446@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 10:22:51 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 12:35:42 EDT" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > > > Seems fine. And we should explain our conventions (even if lots are > > inherited from the Scheme community -- many of our users aren't > > necessarily in the know about this stuff (I know I'm still learning). > > > > I'm working on documenting various naming and interface conventions, > both ones we already more or less use, and ones we should use. I will > include even ones that might be considered "obvious" from a Scheme > point of view. At least some of the naming convention documentation > should percolate into the user docs at some point. Great! G From owner-scwm-discuss@mit.edu Fri Oct 16 13:28:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00362 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:28:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00359 for ; Fri, 16 Oct 1998 13:28:23 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA10015; Fri, 16 Oct 98 13:27:06 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00351; Fri, 16 Oct 1998 13:28:20 -0400 Message-Id: <199810161728.NAA00351@huis-clos.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates In-Reply-To: Your message of "16 Oct 1998 08:45:39 PDT." Date: Fri, 16 Oct 1998 13:28:20 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > > What about the names for the non-interactive moves and resizes? Note > that there are several orthogonal issues. > > For moves: > * viewport-position-specified? (as opposed to virtual) I don't think this is a useful option; the code should always do one or the other, as the virtual and viewport positions can be near-trivially computed from each other by Scheme code. _Which_ of the possibilities the code should do is a bit more of an open question. > * animated? I think there should be a separate animated-move. > * move-pointer-too? I think this is only useful if you are doing an animated move, otherwise moving the window and imediately warping the pointer would do the exact same thing. Thus animated-move should still have the move-pointer-too? optional argument. > For resizes: This is a bit trickier. Obviously we don't want a billion different resize primitives for each possible combination of the options below. > * frame-size-specified? (as opposed to client window size) > * pixel-size-specified? (as opposed to client units) I need to think about these some more. It's true that you might want various combinations of these (except that it probably makes no sense to resize the frame in client units). I'll get back to you. > * animated? (not implemented, but it'd be easy enough) This would actually be kind of cute for a maximize. I'd handle as above, with an `animated-resize' primitive. > * respect-gravity? (or force a specific kind of gravity) > (note that using gravity means resizes can also result in a moves) I think resizes should always respect gravity. If you want to use a different gravity temporarily, you should set the window gravity explicitly before and after the resize. Actually, come to think of it, there should be a user level move-and-resize; by resizing and moving to the current position you could get the effect of "no" gravity (actually NorthEast in effect). > * move-pointer-too? (maybe to preserve the pointer inside the window > if the window is resized smaller -- useful for > focus-follows mouse) As above, I think this is only useful in the animated case. I'm especially keen on making the animated operations always using a separate primitive so they can be tucked into a loadable module, now that the infrastructure for that is there. I'm also against overloading primitive operators too much. But I will admit that it can't be avoided in some cases. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Oct 16 13:28:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00388 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:28:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00384 for ; Fri, 16 Oct 1998 13:28:52 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA10205; Fri, 16 Oct 98 13:27:37 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13020; Fri, 16 Oct 1998 10:27:34 -0700 (PDT) To: Maciej Stachowiak Subject: Re: scwm-procedures.txt References: From: Greg Badros Date: 16 Oct 1998 10:27:33 -0700 In-Reply-To: Sam Steingold's message of "16 Oct 1998 13:08:07 -0400" Message-Id: Lines: 26 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> Ahhh, if only it were easy to upgrade-- my configuration doesn't > >> work with GNU Emacs 20.3. I'm not convinced that I'd want to give > >> up a bunch of the XEmacs features I really like, anyway. > > What are these features? > For me, it would be --no-mule config option. > Another thing, if ELisp is dropped in favor of CL, I'll switch > immediately to the emacs that will make the switch. :-) > [if ELisp is dropped in favor of guile, I'll commit suicide or switch to > MSjunk, whichever I'll find less painful at the time. :-] Real widgets, gnuclient from text consoles, some of the built-in packages (I can't really remember which any longer) that XEmacs includes but GNU Emacs doesn't, face support on TTYs, variable-size fonts, embedded images, embeddable editing widget, faster. There are definitely some features in GNU Emacs 20.3 that I've been interested in, and I generally agree it's a more stable, less buggy platform, but it's a tradeoff. BTW, doesn't XEmacs dump with the cl library and Emacs doesn't (I know it's not common lisp, but it's a step in the right direction). Greg From owner-scwm-discuss@mit.edu Fri Oct 16 13:34:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00505 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:34:48 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA00502 for ; Fri, 16 Oct 1998 13:34:44 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 13:33:07 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 13:33:07 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id NAA30036; Fri, 16 Oct 1998 13:33:14 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161712.NAA00070@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 13:12:51 EDT" Date: 16 Oct 1998 13:33:13 -0400 Message-ID: Lines: 43 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810161712.NAA00070@huis-clos.mit.edu> >>>> On the subject of "Re: Procedures that return predicates" >>>> Sent on Fri, 16 Oct 1998 13:12:51 EDT >>>> Honorable Maciej Stachowiak writes: >> sds@goems.com writes: >> >> > 2. It could be argued that there should be a more consistent >> > naming: either >> > >> > rubberband-{move,resize} >> > opaque-{move,resize} >> > interactive-{move,resize} >> > opaque-{move,resize}? >> > >> > or >> > >> > {move,resize}-rubberband >> > {move,resize}-opaque >> > {move,resize}-interactive >> > {move,resize}-opaque? >> > >> > advantages - more reasonable `apropos' output >> > disadvantages - little difference between `{move,resize}-opaque' and >> > `{move,resize}-opaque?'. >> > >> >> I think it is OK for related actions and predicates to have >> differently ordered names. For example, if we had an opration called >> transmorgiy-window, I'd think a matching window-transmorgified? >> predicate would be OK. This looks fine except for (apropos "win.*trans") will show only some of the related functions. IMHO, this is a sufficiently important issue to be reckoned with. BTW, why are the list messages comming form scwm-discuss@mit.edu? When I reply, I am told that there is no such user... -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Who is General Failure and why is he reading my hard disk? From owner-scwm-discuss@mit.edu Fri Oct 16 13:38:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00571 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:38:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00562; Fri, 16 Oct 1998 13:38:18 -0400 Message-Id: <199810161738.NAA00562@huis-clos.mit.edu> To: Jeffrey Nichols cc: scwm-discuss@mit.edu Subject: Re: Make problem In-reply-to: Your message of "Fri, 16 Oct 1998 10:11:50 PDT." Date: Fri, 16 Oct 1998 13:38:17 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jwnichls@cs.washington.edu writes: > > I just updated via cvs, changed.c gives: > What command did you use? I reccomend `cvs update -dP' to add and remove directories as appropriate. > char *szRepoLastChanged = "Fri Oct 16 12:33:24 EDT 1998 -- $Revision: > 1.676 $"; > > When I run autogen.sh I get: > > modules/Makefile.am:194: required directory modules/overlay-plane does not > exist > modules/Makefile.am:194: required directory modules/pie-menus does not exi > st > configure.in: 470: required file `utilities/dev/scwmdoc.in' not found > configure.in: 470: required file `utilities/dev/scwmdoc.scm.in' not found > The latter two errors can be ignored, the first two make me think you did not use the -d option to cvs update. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 13:39:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00627 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:39:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00621 for ; Fri, 16 Oct 1998 13:39:20 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA13576; Fri, 16 Oct 98 13:38:04 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA13416; Fri, 16 Oct 1998 10:38:02 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161728.NAA00351@huis-clos.mit.edu> From: Greg Badros Date: 16 Oct 1998 10:38:01 -0700 In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 13:28:20 EDT" Message-Id: Lines: 104 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > What about the names for the non-interactive moves and resizes? Note > > that there are several orthogonal issues. > > > > For moves: > > * viewport-position-specified? (as opposed to virtual) > > I don't think this is a useful option; the code should always do one > or the other, as the virtual and viewport positions can be > near-trivially computed from each other by Scheme code. Sorry, I guess I wasn't clear. I don't mean for the primitives-- I thought we were talking about the interface to moving and resizing windows. Currently, e.g., move-to moves a window to a viewport position, whereas move-window moves a window to a virtual position. The former is implemented in terms of the latter (a primitive). These names are not ideal, though. "move-to" should ideally have "window" in the name. It might be better renamed move-window, and the virtual mover renamed to "move-window-virtual" or something like that. > _Which_ of the possibilities the code should do is a bit more of an > open question. > > > * animated? > > I think there should be a separate animated-move. I buy that. > > * move-pointer-too? > > I think this is only useful if you are doing an animated move, > otherwise moving the window and imediately warping the pointer would > do the exact same thing. But that doesn't mean we should have a scheme procedure that abstracts that coupling. > Thus animated-move should still have the move-pointer-too? optional > argument. Definitely -- that primitive needs to know about it. > > For resizes: > > This is a bit trickier. Obviously we don't want a billion different > resize primitives for each possible combination of the options below. > > > * frame-size-specified? (as opposed to client window size) > > * pixel-size-specified? (as opposed to client units) > > I need to think about these some more. It's true that you might want > various combinations of these (except that it probably makes no sense > to resize the frame in client units). I'll get back to you. Good point. It's either resize-frame (in pixel), or resize-client in pixel, or resize-client in client-units. > > * animated? (not implemented, but it'd be easy enough) > > This would actually be kind of cute for a maximize. I'd handle as > above, with an `animated-resize' primitive. Yep. > > > * respect-gravity? (or force a specific kind of gravity) > > (note that using gravity means resizes can also result in a moves) > > I think resizes should always respect gravity. If you want to use a > different gravity temporarily, you should set the window gravity > explicitly before and after the resize. Actually, come to think of it, > there should be a user level move-and-resize; by resizing and moving > to the current position you could get the effect of "no" gravity > (actually NorthEast in effect). Sounds good to me. > > > * move-pointer-too? (maybe to preserve the pointer inside the window > > if the window is resized smaller -- useful for > > focus-follows mouse) > > As above, I think this is only useful in the animated case. But again, it may make sense to wrap at the scheme level. If I'm resizing the window with the pointer and using focus-follows-mouse, I almost definitely want the pointer to stay in the window I've resized. > I'm especially keen on making the animated operations always using a > separate primitive so they can be tucked into a loadable module, now > that the infrastructure for that is there. Right. A very good motivation. > I'm also against overloading primitive operators too much. But I will > admit that it can't be avoided in some cases. Only when the benefit outweighs the cost. Moves and resizes are pretty cheap in C code, while the animated stuff is more complex, so separation is clearly worthwhile. Greg From owner-scwm-discuss@mit.edu Fri Oct 16 13:54:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00991 for scwm-discuss-outgoing; Fri, 16 Oct 1998 13:54:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00977; Fri, 16 Oct 1998 13:53:55 -0400 Message-Id: <199810161753.NAA00977@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates In-reply-to: Your message of "16 Oct 1998 13:33:13 EDT." Date: Fri, 16 Oct 1998 13:53:55 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199810161712.NAA00070@huis-clos.mit.edu> > >>>> On the subject of "Re: Procedures that return predicates" > >>>> Sent on Fri, 16 Oct 1998 13:12:51 EDT > >>>> Honorable Maciej Stachowiak writes: > >> > >> I think it is OK for related actions and predicates to have > >> differently ordered names. For example, if we had an opration called > >> transmorgify-window, I'd think a matching window-transmorgified? > >> predicate would be OK. > > This looks fine except for (apropos "win.*trans") will show only some of > the related functions. IMHO, this is a sufficiently important issue to > be reckoned with. I suppose it is something of a problem. However, if this is a documented convention, I think users will expect that they should use (apropos "win.*trans|trans.*win") to get the effect they want there. > > BTW, why are the list messages comming form scwm-discuss@mit.edu? > When I reply, I am told that there is no such user... > That address should work fine as an address to send to (it forwards to scwm-discuss@huis-clos.mit.edu). If you're getting bounces please send me a copy. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 16 14:00:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01114 for scwm-discuss-outgoing; Fri, 16 Oct 1998 14:00:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01110 for ; Fri, 16 Oct 1998 14:00:34 -0400 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA24638; Fri, 16 Oct 98 13:59:17 EDT Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id KAA25031 for ; Fri, 16 Oct 1998 10:59:17 -0700 (PDT) Date: Fri, 16 Oct 1998 10:59:17 -0700 (PDT) From: Jeffrey Nichols To: scwm-discuss@mit.edu Subject: Re: Make problem In-Reply-To: <19981016102236.A5506@molehill.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > did you use the '-d' option for update, to create new directories? I apparently didn't make myself very clear. The directories do exist. They are simply in scwm/scwm/modules/ rather than scwm/modules where they are apparently looked for. I did use the '-d' option for update. -Jeff From owner-scwm-discuss@mit.edu Fri Oct 16 14:16:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01465 for scwm-discuss-outgoing; Fri, 16 Oct 1998 14:16:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA01462 for ; Fri, 16 Oct 1998 14:16:35 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 14:14:59 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 14:14:59 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA00866; Fri, 16 Oct 1998 14:15:05 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810161753.NAA00977@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Fri, 16 Oct 1998 13:53:55 EDT" Date: 16 Oct 1998 14:15:05 -0400 Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810161753.NAA00977@huis-clos.mit.edu> >>>> On the subject of "Re: Procedures that return predicates" >>>> Sent on Fri, 16 Oct 1998 13:53:55 EDT >>>> Honorable Maciej Stachowiak writes: >> >> I suppose it is something of a problem. However, if this is a >> documented convention, I think users will expect that they should >> use (apropos "win.*trans|trans.*win") to get the effect they want >> there. I think the inconvenience of having to type the same thing twice overrides other issues. >> > BTW, why are the list messages comming form scwm-discuss@mit.edu? >> > When I reply, I am told that there is no such user... >> >> That address should work fine as an address to send to (it forwards to >> scwm-discuss@huis-clos.mit.edu). If you're getting bounces please send >> me a copy. just did. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Don't use force -- get a bigger hammer. From owner-scwm-discuss@mit.edu Fri Oct 16 14:23:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01522 for scwm-discuss-outgoing; Fri, 16 Oct 1998 14:23:39 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01519 for ; Fri, 16 Oct 1998 14:23:38 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA02413; Fri, 16 Oct 98 14:22:17 EDT Received: (qmail 8153 invoked by uid 501); 16 Oct 1998 18:22:17 -0000 Message-Id: <19981016112217.A8130@molehill.org> Date: Fri, 16 Oct 1998 11:22:17 -0700 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: Make problem References: <19981016102236.A5506@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jeffrey Nichols on Fri, Oct 16, 1998 at 10:59:17AM -0700 X-Tom-Swifty: "I don't want a second helping, thank you", said the cannibal manfully. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981016, Jeffrey Nichols wrote: > > > did you use the '-d' option for update, to create new directories? > > I apparently didn't make myself very clear. The directories do > exist. They are simply in scwm/scwm/modules/ rather than scwm/modules > where they are apparently looked for. I did use the '-d' option for > update. That's bizarre. The repository looks fine. You might try a fresh checkout, unless/until some CVS guru steps up with an obvious-in-hindsight-only explanation. From owner-scwm-discuss@mit.edu Fri Oct 16 14:30:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01667 for scwm-discuss-outgoing; Fri, 16 Oct 1998 14:30:49 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01662 for ; Fri, 16 Oct 1998 14:30:39 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA04888; Fri, 16 Oct 98 14:29:21 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 16 Oct 1998 14:29:09 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 16 Oct 1998 14:29:09 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA00893; Fri, 16 Oct 1998 14:29:15 -0400 To: Greg Badros Cc: Maciej Stachowiak Subject: Re: scwm-procedures.txt References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "16 Oct 1998 10:27:33 -0700" Date: 16 Oct 1998 14:29:15 -0400 Message-Id: Lines: 34 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: scwm-procedures.txt" >>>> Sent on 16 Oct 1998 10:27:33 -0700 >>>> Honorable Greg Badros writes: >> Sam Steingold writes: >> > What are these features? >> >> Real widgets, gnuclient from text consoles, some of the built-in >> packages (I can't really remember which any longer) that XEmacs includes >> but GNU Emacs doesn't, face support on TTYs, variable-size fonts, >> embedded images, embeddable editing widget, I don't use TTY, hate variable-size fonts, don't care about images, and don't know what "embeddable editing widget" is. :-) >> faster. huh?!!! >> BTW, doesn't XEmacs dump with the cl library and Emacs doesn't (I >> know it's not common lisp, but it's a step in the right direction). well, yeah, sort of. many things are missing though - like scope, multiple values etc. In my dream world, there is one multi-threaded CL process serving other applications - like SCWM, Emacs etc... -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. OS/2: Why marketing matters more than technology... From owner-scwm-discuss@mit.edu Fri Oct 16 15:13:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02043 for scwm-discuss-outgoing; Fri, 16 Oct 1998 15:13:44 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02033; Fri, 16 Oct 1998 15:13:39 -0400 Message-Id: <199810161913.PAA02033@huis-clos.mit.edu> To: Jeffrey Nichols cc: scwm-discuss@mit.edu Subject: Re: Make problem In-reply-to: Your message of "Fri, 16 Oct 1998 10:59:17 PDT." Date: Fri, 16 Oct 1998 15:13:39 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jwnichls@cs.washington.edu writes: > > > did you use the '-d' option for update, to create new directories? > > I apparently didn't make myself very clear. The directories do > exist. They are simply in scwm/scwm/modules/ rather than scwm/modules > where they are apparently looked for. I did use the '-d' option for > update. > Hmm, all I can say is that your working directory must be hosed somehow. Mine has these files in the right place (scwm/modules). If you don't have any code that needs saving in your working dir, try removing it and checking out again. I have certainly seen CVS fail in weird ways before, and it's probably better to give up than debug it. If you _do_ have code changes you want to save, cvs diff to find out which files changed and back those up. - Maciej From owner-scwm-discuss@mit.edu Sat Oct 17 04:13:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA06840 for scwm-discuss-outgoing; Sat, 17 Oct 1998 04:13:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA06837 for ; Sat, 17 Oct 1998 04:13:08 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA28870; Sat, 17 Oct 98 04:11:44 EDT Received: (qmail 22182 invoked by uid 501); 17 Oct 1998 08:12:01 -0000 Message-Id: <19981017011159.A22157@molehill.org> Date: Sat, 17 Oct 1998 01:11:59 -0700 From: Todd Larason To: scwm-discuss list Subject: pie menus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I have a B.A. in social work", said Tom with a degree of concern. Sender: owner-scwm-discuss@mit.edu Precedence: bulk Pie menus are better tonight, especially on menus without separators. At this point, they work well enough I'm interested in hearing about problems with them and desired features. I'm not real sure what to do with separators or extra text and would love ideas. Side images, left & above images, and proper title handling just aren't implemented yet. From owner-scwm-discuss@mit.edu Sat Oct 17 16:47:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA10021 for scwm-discuss-outgoing; Sat, 17 Oct 1998 16:47:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA10018 for ; Sat, 17 Oct 1998 16:47:30 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25904; Sat, 17 Oct 98 16:45:59 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA14952; Sat, 17 Oct 1998 22:45:54 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Procedures that return predicates References: <199810160339.XAA26546@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Oct 1998 22:45:54 +0200 In-Reply-To: Maciej Stachowiak's message of "Thu, 15 Oct 1998 23:39:31 EDT" Message-Id: Lines: 41 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > One problem with the last of these is that I've ended up writing a lot > of procedures that return predicates on windows. For example > (title-regexp ".*[Nn]etscape.*") returns a predicate which returns > true for any window with a title that contains "Netscape" or > "netscape"; (hostname-exact "foo.ai.mit.edu") will match any window > running on a machine named exactly "foo.ai.mit.edu" and so on. > > I am very happy with the fact that predicates have the convention in > Scheme of ending in a `?' character, and unhappy with the fact that > meta-predicates, as one might call them, do not. I often prepend fcns that return fcns with "make-" to give the idea that they're returning some sort of object, since a closure is a sort of an object. I might use things like: (make-title-regexp ".*[Nn]etscape.*") or maybe the more verbose: (make-title-regexp-matcher ".*[Nn]etscape.*") or maybe the way too verbose: (make-title-regexp-window-matcher ".*[Nn]etscape.*") Other possibilities: (make-title-regexp-match-fcn ".*[Nn]etscape.*") or even just: (title-regexp-match-fcn ".*[Nn]etscape.*") -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Oct 18 09:22:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA15537 for scwm-discuss-outgoing; Sun, 18 Oct 1998 09:22:21 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA15534 for ; Sun, 18 Oct 1998 09:22:19 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id PAA14731 for scwm-discuss@huis-clos.mit.edu; Sun, 18 Oct 1998 15:12:12 +0200 (MET DST) Received: (qmail 5833 invoked by uid 115); 18 Oct 1998 13:07:27 -0000 To: scwm-discuss@mit.edu Subject: Session Management X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 18 Oct 1998 15:07:21 +0200 Message-ID: Lines: 35 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, a couple of days ago I wanted to test the session management code Greg installed, and discovered that SM is tres cool. Support in scwm was broken, but this is already fixed in my work dir. The status is that it works (I'm running scwm under SM right now), but does not do much. What kind of state would you like to have scwm keep across sessions? Some ideas: * Window geometries An obvious candidate, although it could be argued that clients are themselves responsible for saving placing info. A few clients do that (notably Gnome apps), but the majority does not. Furthermore, this needs a reliable way to identify clients. For example: I start "xedit foo" and "xedit bar", shutdown, and later resume my session. When the xedits are restarted by the session-manager, scwm should place each one at its original position without confusing the two. * Other window-specific state scwm should remember whether a window is iconified, window-shaded, on which desktop it resides, etc. Reliable identification is needed as above. * Internals Very much of scwm internal settings could be convinient to save. Taken to the extreme, no special scwmrc would be necessary. You simply set a key binding, window style, whatever and it automatically persists until you remove it (or start a clean-slate session). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Oct 18 09:22:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA15533 for scwm-discuss-outgoing; Sun, 18 Oct 1998 09:22:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA15530 for ; Sun, 18 Oct 1998 09:22:15 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id PAA14732 for scwm-discuss@huis-clos.mit.edu; Sun, 18 Oct 1998 15:12:13 +0200 (MET DST) Received: (qmail 5841 invoked by uid 115); 18 Oct 1998 13:07:43 -0000 To: scwm-discuss@mit.edu Subject: Outdated files X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 18 Oct 1998 15:07:39 +0200 Message-ID: Lines: 16 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, the contents of "scwm/mwmcom.h" are apperently not used anywhere (and I can't imagine any possible use). I think this and references to it in "scwm/Makefile.am" and "scwm/decorations.c" should be removed. "scwm/makefile.cassowary" is also no longer of much use and can be put to rest. Objections? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Oct 18 10:50:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA16301 for scwm-discuss-outgoing; Sun, 18 Oct 1998 10:50:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA16298 for ; Sun, 18 Oct 1998 10:50:08 -0400 Received: from pool02b-194-7-147-228.uunet.be by MIT.EDU with SMTP id AA23914; Sun, 18 Oct 98 10:48:31 EDT Received: (qmail 4595 invoked by uid 500); 17 Oct 1998 20:36:35 -0000 Date: 17 Oct 1998 20:36:35 -0000 Message-Id: <19981017203635.4594.qmail@tower.skynet.be> From: Lieven Marchand Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-Reply-To: References: X-Mailer: VM 6.31 under 20.2 XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > In my dream world, there is one multi-threaded CL process serving other > applications - like SCWM, Emacs etc... > It's called a Lisp Machine. A pity Open Genera is so damned expensive. Lieven From owner-scwm-discuss@mit.edu Sun Oct 18 11:49:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16648 for scwm-discuss-outgoing; Sun, 18 Oct 1998 11:49:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16641; Sun, 18 Oct 1998 11:49:00 -0400 Message-Id: <199810181549.LAA16641@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: Outdated files In-reply-to: Your message of "18 Oct 1998 15:07:39 +0200." Date: Sun, 18 Oct 1998 11:48:59 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > the contents of "scwm/mwmcom.h" are apperently not used anywhere (and > I can't imagine any possible use). I think this and references to it > in "scwm/Makefile.am" and "scwm/decorations.c" should be removed. > > "scwm/makefile.cassowary" is also no longer of much use and can be put > to rest. > > Objections? > If you do this, please save a copy of mwmcom.h in doc/dev; someday we may want to come up with a way to emulate the Motif behavior of graying certain menu items based on Motif hints, and this file is a good reference to which such items might want to be grayed for what hints. Other than that, no objections. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 11:59:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16958 for scwm-discuss-outgoing; Sun, 18 Oct 1998 11:59:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA16955 for ; Sun, 18 Oct 1998 11:59:50 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA21418; Sun, 18 Oct 98 11:58:10 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA16951; Sun, 18 Oct 1998 11:59:46 -0400 Message-Id: <199810181559.LAA16951@huis-clos.mit.edu> To: Robert Bihlmeyer To: scwm-discuss@mit.edu Subject: Re: Session Management In-Reply-To: Your message of "18 Oct 1998 15:07:21 +0200." Date: Sun, 18 Oct 1998 11:59:46 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > a couple of days ago I wanted to test the session management code Greg > installed, and discovered that SM is tres cool. Support in scwm was > broken, but this is already fixed in my work dir. > > The status is that it works (I'm running scwm under SM right now), but > does not do much. What kind of state would you like to have scwm keep > across sessions? Some ideas: > Cool! I'd want to see your fixes even if SM continues not to do much for the time being. > * Window geometries > An obvious candidate, although it could be argued that clients are > themselves responsible for saving placing info. A few clients do that > (notably Gnome apps), but the majority does not. Furthermore, this > needs a reliable way to identify clients. For example: I start > "xedit foo" and "xedit bar", shutdown, and later resume my session. > When the xedits are restarted by the session-manager, scwm should > place each one at its original position without confusing the two. > > * Other window-specific state > scwm should remember whether a window is iconified, window-shaded, on > which desktop it resides, etc. Reliable > identification is needed as above. Doesn't session management have a way to get unique IDs for SM clients that are persistent across sessions? It seems any IPC would be bound to break across sessions without this. > > * Internals > Very much of scwm internal settings could be convinient to save. Taken > to the extreme, no special scwmrc would be necessary. You simply set a > key binding, window style, whatever and it automatically persists > until you remove it (or start a clean-slate session). > That would be a good goal to shoot for, but I am not sure there is an effective way to do it short of dumping the whole Guile heap. I say this because many settings are in effect implemented as procedures being set as callbacks, and those procedures call other procedures, etc etc. However, one might want this to work across (compatible) scwm and libguile upgrades. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 17:07:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21447 for scwm-discuss-outgoing; Sun, 18 Oct 1998 17:07:16 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21444 for ; Sun, 18 Oct 1998 17:07:12 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA08174; Sun, 18 Oct 98 17:05:29 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 18 Oct 1998 17:04:33 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 18 Oct 1998 17:04:33 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id RAA17741; Sun, 18 Oct 1998 17:05:25 -0400 To: Lieven Marchand Cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <19981017203635.4594.qmail@tower.skynet.be> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Lieven Marchand's message of "17 Oct 1998 20:36:35 -0000" Date: 18 Oct 1998 17:05:25 -0400 Message-Id: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981017203635.4594.qmail@tower.skynet.be> >>>> On the subject of "Re: scwm-procedures.txt" >>>> Sent on 17 Oct 1998 20:36:35 -0000 >>>> Honorable Lieven Marchand writes: >> Sam Steingold writes: >> > In my dream world, there is one multi-threaded CL process serving other >> > applications - like SCWM, Emacs etc... >> >> It's called a Lisp Machine. I was wating for someone to say that... [I must admit that I have never seen - let alone used - a Lisp machine] -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Sex is like air. It's only a big deal if you can't get any. From owner-scwm-discuss@mit.edu Sun Oct 18 17:28:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21599 for scwm-discuss-outgoing; Sun, 18 Oct 1998 17:28:41 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21596 for ; Sun, 18 Oct 1998 17:28:37 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA11637; Sun, 18 Oct 98 17:26:59 EDT Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id RAA11957; Sun, 18 Oct 1998 17:26:05 -0400 (EDT) Message-Id: <199810182126.RAA11957@jekyll.piermont.com> To: sds@goems.com Cc: Lieven Marchand , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-Reply-To: Your message of "18 Oct 1998 17:05:25 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 Oct 1998 17:26:05 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> It's called a Lisp Machine. > > I was wating for someone to say that... > > [I must admit that I have never seen - let alone used - a Lisp machine] You don't know what you missed. Perry From owner-scwm-discuss@mit.edu Sun Oct 18 17:35:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21669 for scwm-discuss-outgoing; Sun, 18 Oct 1998 17:35:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21666 for ; Sun, 18 Oct 1998 17:35:30 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01359; Sun, 18 Oct 98 17:33:45 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA22529; Sun, 18 Oct 1998 23:33:19 +0200 To: perry@piermont.com Cc: sds@goems.com, Lieven Marchand , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <199810182126.RAA11957@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Oct 1998 23:33:19 +0200 In-Reply-To: "Perry E. Metzger"'s message of "Sun, 18 Oct 1998 17:26:05 -0400" Message-Id: Lines: 17 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Sam Steingold writes: > > >> It's called a Lisp Machine. > > > > I was wating for someone to say that... > > > > [I must admit that I have never seen - let alone used - a Lisp machine] > > You don't know what you missed. I used one. They're cool. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Oct 18 17:41:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21751 for scwm-discuss-outgoing; Sun, 18 Oct 1998 17:41:43 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21748 for ; Sun, 18 Oct 1998 17:41:42 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA02092; Sun, 18 Oct 98 17:39:57 EDT Received: (qmail 27682 invoked by uid 501); 18 Oct 1998 21:40:20 -0000 Message-Id: <19981018144020.A27108@molehill.org> Date: Sun, 18 Oct 1998 14:40:20 -0700 From: Todd Larason To: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <199810182126.RAA11957@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810182126.RAA11957@jekyll.piermont.com>; from Perry E. Metzger on Sun, Oct 18, 1998 at 05:26:05PM -0400 X-Tom-Swifty: "It's Jack the Ripper!" said Tom horrendously. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981018, Perry E. Metzger wrote: > > Sam Steingold writes: > > >> It's called a Lisp Machine. > > > > I was wating for someone to say that... > > > > [I must admit that I have never seen - let alone used - a Lisp machine] > > You don't know what you missed. Does anybody have any idea where one might buy one? From what I've read, some of the later models (LK-1201?) are small enough for it to be reasonable to add one to my collection, except that I have *never* found one for sale. From owner-scwm-discuss@mit.edu Sun Oct 18 17:47:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA21889 for scwm-discuss-outgoing; Sun, 18 Oct 1998 17:47:45 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA21880 for ; Sun, 18 Oct 1998 17:47:41 -0400 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA14382; Sun, 18 Oct 98 17:46:03 EDT Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 18 Oct 1998 17:45:13 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 18 Oct 1998 17:45:13 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id RAA18365; Sun, 18 Oct 1998 17:46:05 -0400 To: scwm-discuss@mit.edu Subject: lispm References: <199810182126.RAA11957@jekyll.piermont.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "18 Oct 1998 23:33:19 +0200" Date: 18 Oct 1998 17:46:05 -0400 Message-Id: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: scwm-procedures.txt" >>>> Sent on 18 Oct 1998 23:33:19 +0200 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: >> "Perry E. Metzger" writes: >> > Sam Steingold writes: >> > > [I must admit that I have never seen - >> > > let alone used - a Lisp machine] >> > You don't know what you missed. >> I used one. They're cool. what's so cool about them? look and feel? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Just because you're paranoid doesn't mean they AREN'T after you. From owner-scwm-discuss@mit.edu Sun Oct 18 18:12:18 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22460 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:12:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22453 for ; Sun, 18 Oct 1998 18:12:11 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA06084; Sun, 18 Oct 98 18:10:27 EDT Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA14848; Sun, 18 Oct 1998 18:10:27 -0400 (EDT) Message-Id: <199810182210.SAA14848@jekyll.piermont.com> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: lispm In-Reply-To: Your message of "18 Oct 1998 17:46:05 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 Oct 1998 18:10:26 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> > > [I must admit that I have never seen - > >> > > let alone used - a Lisp machine] > >> > You don't know what you missed. > >> I used one. They're cool. > > what's so cool about them? > look and feel? It was a fully integrated lisp development environment. All docs were online, in hypertext. The editor, everything, it was all part and parcel of one environment. I can't even begin to describe it. Nothing available even now comes close. And this was available fifteen years ago! When I compare the feeble things we develop with now -- like guile, or emacs, gcc and gdb -- to what the lisp machines were like, I almost want to hide my head and mourn. Perry From owner-scwm-discuss@mit.edu Sun Oct 18 18:18:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22548 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:18:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22539; Sun, 18 Oct 1998 18:18:52 -0400 Message-Id: <199810182218.SAA22539@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-reply-to: Your message of "Sun, 18 Oct 1998 14:40:20 PDT." <19981018144020.A27108@molehill.org> Date: Sun, 18 Oct 1998 18:18:52 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981018, Perry E. Metzger wrote: > > > > Sam Steingold writes: > > > >> It's called a Lisp Machine. > > > > > > I was wating for someone to say that... > > > > > > [I must admit that I have never seen - let alone used - a Lisp machine] > > > > You don't know what you missed. > > Does anybody have any idea where one might buy one? From what I've > read, some of the later models (LK-1201?) are small enough for it to > be reasonable to add one to my collection, except that I have *never* > found one for sale. > I've occasionally seen the MIT AI lab give some away, but they go like hot cakes. I think there are also some places that sell them refurbished (my group at the AI Lab bought some) but I don't know the address. Of course, there is also Open Genera, mentioned in an earlier post, which is a port of the LispM operating system, Genera, to the DEC alpha. I think you can still buy it from the company that bought out the remnants of Symbolics. It's pretty expensive though. The Lisp Machine was pretty cool for its time (I've played with some at the MIT AI Lab), but I think a lot of people over-romanticize their memories of them. I found the system awkward in many ways, and the performance seemed rather poor for a system designed optimized to run Lisp. OK, go ahead, burn me as a heretic... - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 18:21:18 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22588 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:21:18 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22582 for ; Sun, 18 Oct 1998 18:21:12 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA18958; Sun, 18 Oct 98 18:19:31 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA22745; Mon, 19 Oct 1998 00:19:25 +0200 To: perry@piermont.com Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: lispm References: <199810182210.SAA14848@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Oct 1998 00:19:25 +0200 In-Reply-To: "Perry E. Metzger"'s message of "Sun, 18 Oct 1998 18:10:26 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Sam Steingold writes: > > >> > > [I must admit that I have never seen - > > >> > > let alone used - a Lisp machine] > > >> > You don't know what you missed. > > >> I used one. They're cool. > > > > what's so cool about them? > > look and feel? > > It was a fully integrated lisp development environment. All docs were > online, in hypertext. The editor, everything, it was all part and > parcel of one environment. I can't even begin to describe it. Nothing > available even now comes close. And this was available fifteen years > ago! Yup. That's about right, except that the smalltalk machines had that except with s/lisp/smalltalk/g. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Oct 18 18:31:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22957 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:31:34 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA22954 for ; Sun, 18 Oct 1998 18:31:31 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA08372; Sun, 18 Oct 98 18:29:47 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA22799; Mon, 19 Oct 1998 00:29:48 +0200 To: Maciej Stachowiak Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <199810182218.SAA22539@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Oct 1998 00:29:48 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 18 Oct 1998 18:18:52 EDT" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > The Lisp Machine was pretty cool for its time (I've played with some > at the MIT AI Lab), but I think a lot of people over-romanticize their > memories of them. I found the system awkward in many ways, and the > performance seemed rather poor for a system designed optimized to run > Lisp. > > OK, go ahead, burn me as a heretic... Performance was lousy compared to the chips comming out - they couldn't compete in silicon, just like BBN couldn't compete with their C machine microcodable CPUs. On the other hand, they're able to work quite efficiently with memory much smaller than the working set. I've heard that they were quite comfortable in little memory with problems that'd bring suns with much more memory to their knees in fits of swapping. I also recall dropping into the debugger all the time, but I think that was the app crashing... It's pretty cool that it'd drop into the debugger on "kernel" crashes too. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Oct 18 18:46:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23288 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:46:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23285 for ; Sun, 18 Oct 1998 18:46:54 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA10329; Sun, 18 Oct 98 18:45:11 EDT Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id SAA15076; Sun, 18 Oct 1998 18:45:06 -0400 (EDT) Message-Id: <199810182245.SAA15076@jekyll.piermont.com> To: Maciej Stachowiak Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-Reply-To: Your message of "Sun, 18 Oct 1998 18:18:52 EDT." <199810182218.SAA22539@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 18 Oct 1998 18:45:06 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > The Lisp Machine was pretty cool for its time (I've played with some > at the MIT AI Lab), but I think a lot of people over-romanticize their > memories of them. I found the system awkward in many ways, and the > performance seemed rather poor for a system designed optimized to run > Lisp. > > OK, go ahead, burn me as a heretic... It isn't that I'd want to go back to a lispm now. It is that when one considers where we should be now given where we were then.... Perry From owner-scwm-discuss@mit.edu Sun Oct 18 18:58:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA23391 for scwm-discuss-outgoing; Sun, 18 Oct 1998 18:58:38 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA23388 for ; Sun, 18 Oct 1998 18:58:33 -0400 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA24195; Sun, 18 Oct 98 18:56:53 EDT Received: (qmail 31043 invoked by uid 501); 18 Oct 1998 22:57:14 -0000 Message-Id: <19981018155714.A30264@molehill.org> Date: Sun, 18 Oct 1998 15:57:14 -0700 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <19981018144020.A27108@molehill.org> <199810182218.SAA22539@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810182218.SAA22539@huis-clos.mit.edu>; from Maciej Stachowiak on Sun, Oct 18, 1998 at 06:18:52PM -0400 X-Tom-Swifty: "I saw that man remove my ballot from the box", said Tom devotedly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981018, Maciej Stachowiak wrote: > I've occasionally seen the MIT AI lab give some away, but they go like > hot cakes. I think there are also some places that sell them > refurbished (my group at the AI Lab bought some) but I don't know the > address. If you happen to run across a name, or some more being given away, I would be very interested. > The Lisp Machine was pretty cool for its time (I've played with some > at the MIT AI Lab), but I think a lot of people over-romanticize their > memories of them. I've never used one; seeing for myself how true the romantic view is is part of why I'm interested in having one. There's also a desire to SEE one of these keyboards, that supposedly actually had enough modifier keys. And also just a desire to have 'one of each', in a world where one architecture is so overwhelmingly dominant. From owner-scwm-discuss@mit.edu Sun Oct 18 19:22:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23660 for scwm-discuss-outgoing; Sun, 18 Oct 1998 19:22:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23653; Sun, 18 Oct 1998 19:22:09 -0400 Message-Id: <199810182322.TAA23653@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-reply-to: Your message of "19 Oct 1998 00:29:48 +0200." Date: Sun, 18 Oct 1998 19:22:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Performance was lousy compared to the chips comming out - they > couldn't compete in silicon, just like BBN couldn't compete with their > C machine microcodable CPUs. > That's true, but I think to a point this is a fundamental flaw of a language-specific architecture as compared to a general-purpose CPU, and not just a random market condition. > On the other hand, they're able to work quite efficiently with memory > much smaller than the working set. I've heard that they were quite > comfortable in little memory with problems that'd bring suns with much > more memory to their knees in fits of swapping. > Hmm, LispMs I've seen generally have 2-4 megs, which I think was typical for Suns of that era as well. But I wouldn't be surprised if they had much better paging behavior than the SunOS pager. > I also recall dropping into the debugger all the time, but I think > that was the app crashing... The annoying part is when one app screws up another, though, makes you regret the integrated environment a bit. I am not sure where the right tradeoff is here, though - I don't like apps crashing each other, but it _would_ be really cool if you could write a program that integrates across multiple apps. > It's pretty cool that it'd drop into the debugger on "kernel" crashes > too. I don't think it would if you crashed the microcode, but hopefully that was small enough not to ever crash. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 19:24:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23696 for scwm-discuss-outgoing; Sun, 18 Oct 1998 19:24:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23686; Sun, 18 Oct 1998 19:24:22 -0400 Message-Id: <199810182324.TAA23686@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-reply-to: Your message of "Sun, 18 Oct 1998 18:45:06 EDT." <199810182245.SAA15076@jekyll.piermont.com> Date: Sun, 18 Oct 1998 19:24:21 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > The Lisp Machine was pretty cool for its time (I've played with some > > at the MIT AI Lab), but I think a lot of people over-romanticize their > > memories of them. I found the system awkward in many ways, and the > > performance seemed rather poor for a system designed optimized to run > > Lisp. > > > > OK, go ahead, burn me as a heretic... > > It isn't that I'd want to go back to a lispm now. > > It is that when one considers where we should be now given where we > were then.... > That I can whole-heartedly agree with. One might wonder how many man-centuries of effort have been wasted due to buffer overflow bugs alone.. - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 19:31:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23828 for scwm-discuss-outgoing; Sun, 18 Oct 1998 19:31:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA23817; Sun, 18 Oct 1998 19:31:12 -0400 Message-Id: <199810182331.TAA23817@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-reply-to: Your message of "Sun, 18 Oct 1998 15:57:14 PDT." <19981018155714.A30264@molehill.org> Date: Sun, 18 Oct 1998 19:31:11 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981018, Maciej Stachowiak wrote: > > I've occasionally seen the MIT AI lab give some away, but they go like > > hot cakes. I think there are also some places that sell them > > refurbished (my group at the AI Lab bought some) but I don't know the > > address. > > If you happen to run across a name, or some more being given away, I > would be very interested. I'll see what I can do. I kind of want one too. I would have tried to get one the last time I saw them being given away, but I was expecting to move cross-country, which didn't actually end up happening. > > The Lisp Machine was pretty cool for its time (I've played with some > > at the MIT AI Lab), but I think a lot of people over-romanticize their > > memories of them. > > I've never used one; seeing for myself how true the romantic view is > is part of why I'm interested in having one. There's also a desire to > SEE one of these keyboards, that supposedly actually had enough > modifier keys. Almost enough. My favorites, I think, are the square, circle and triangle keys which have those shapes on them and exist to be extra user-defined modifiers, IIRC. > And also just a desire to have 'one of each', in a > world where one architecture is so overwhelmingly dominant. > - Maciej From owner-scwm-discuss@mit.edu Sun Oct 18 20:54:13 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA01892 for scwm-discuss-outgoing; Sun, 18 Oct 1998 20:54:13 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA01889 for ; Sun, 18 Oct 1998 20:54:10 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA26889; Sun, 18 Oct 98 20:52:25 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA20788; Sun, 18 Oct 1998 17:52:22 -0700 (PDT) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Session Management References: From: Greg Badros Date: 18 Oct 1998 17:52:22 -0700 In-Reply-To: Robert Bihlmeyer's message of "18 Oct 1998 15:07:21 +0200" Message-Id: Lines: 49 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > a couple of days ago I wanted to test the session management code Greg > installed, and discovered that SM is tres cool. Support in scwm was > broken, but this is already fixed in my work dir. Obviously, I'm curious how bad the sm was.... I was working only from the spec (and another wm) since I've no session manager in use yet. I'd love for the changes to get checked in, even if they are still not very functional. > The status is that it works (I'm running scwm under SM right now), but > does not do much. What kind of state would you like to have scwm keep > across sessions? Some ideas: > > * Window geometries > An obvious candidate, although it could be argued that clients are > themselves responsible for saving placing info. A few clients do that > (notably Gnome apps), but the majority does not. Furthermore, this > needs a reliable way to identify clients. For example: I start > "xedit foo" and "xedit bar", shutdown, and later resume my session. > When the xedits are restarted by the session-manager, scwm should > place each one at its original position without confusing the two. Right-- taking into account their virtual window positions, too. There's a tradeoff between moving all windows back to the home viewport when scwm shuts down vs. leaving them where they were so an immediate restart gets you almost back to where they were. (Last week or so I added some variable for a total hack way to manage this [can't remember name, now, and I'm not at my main machine so it's a pain to check]). > * Other window-specific state > scwm should remember whether a window is iconified, window-shaded, on > which desktop it resides, etc. Reliable > identification is needed as above. > > * Internals > Very much of scwm internal settings could be convinient to save. Taken > to the extreme, no special scwmrc would be necessary. You simply set a > key binding, window style, whatever and it automatically persists > until you remove it (or start a clean-slate session). This might be hard because of the arbitrary scheme objects attached to windows, etc. Greg From owner-scwm-discuss@mit.edu Mon Oct 19 03:49:07 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA09564 for scwm-discuss-outgoing; Mon, 19 Oct 1998 03:49:07 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA09561 for ; Mon, 19 Oct 1998 03:49:05 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24664; Mon, 19 Oct 98 03:48:55 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id JAA25441; Mon, 19 Oct 1998 09:48:55 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <199810182322.TAA23653@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Oct 1998 09:48:55 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 18 Oct 1998 19:22:09 EDT" Message-Id: Lines: 50 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > > On the other hand, they're able to work quite efficiently with memory > > much smaller than the working set. I've heard that they were quite > > comfortable in little memory with problems that'd bring suns with much > > more memory to their knees in fits of swapping. > > > > Hmm, LispMs I've seen generally have 2-4 megs, which I think was > typical for Suns of that era as well. But I wouldn't be surprised if > they had much better paging behavior than the SunOS pager. On the lispos mailing list, some people were reminiscing about being ordered to move from lisp machines to suns. Their apps used many times more memory than was available on the lisp machine, but still worked fine. When moved to the suns they had to buy enough memory so that the entire application could run in ram, and at that point performance was just competitive - not better. > > I also recall dropping into the debugger all the time, but I think > > that was the app crashing... > > The annoying part is when one app screws up another, though, makes you > regret the integrated environment a bit. I am not sure where the right > tradeoff is here, though - I don't like apps crashing each other, but > it _would_ be really cool if you could write a program that integrates > across multiple apps. That's what Richard Stallman said about it when I asked him, that it was so integrated it became impossible to change anything without breaking something. Think about every application's fcns being accessible from all other applications. It gets to the point where all sorts of apps are using functions you wrote so you can't change them any more. It leads to spaghetti. Under unix it's harder to use someone's code - have to snarf it up & compile it in, or link against their library (if they've made a library). In the former case you have a stable version, in the latter it's probably stable - otherwise he wouldn't have made it a library. The whole thing kind of goes against the concept of reuse. But maybe this is more a general programming issue than a lisp machine issue - balance btw making work as accessible as possible on the one hand & not creating spaghetti code on the other. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Oct 19 04:23:17 1998 Received: (from Unknown UID 15@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id EAA09970 for scwm-discuss-outgoing; Mon, 19 Oct 1998 04:23:17 -0400 X-Authentication-Warning: huis-clos.mit.edu: Unknown UID 15 set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id EAA09967 for ; Mon, 19 Oct 1998 04:23:16 -0400 From: mal@bewoner.dma.be Received: from dialup241.brussels.skynet.be by MIT.EDU with SMTP id AA12983; Mon, 19 Oct 98 04:23:13 EDT Received: (qmail 25398 invoked by uid 500); 19 Oct 1998 08:51:32 -0000 Date: 19 Oct 1998 08:51:32 -0000 Message-Id: <19981019085132.25393.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-Reply-To: References: <199810182322.TAA23653@huis-clos.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > Maciej Stachowiak writes: > > > hjstein@bfr.co.il writes: > > > > > On the other hand, they're able to work quite efficiently with memory > > > much smaller than the working set. I've heard that they were quite > > > comfortable in little memory with problems that'd bring suns with much > > > more memory to their knees in fits of swapping. > > > > > > > Hmm, LispMs I've seen generally have 2-4 megs, which I think was > > typical for Suns of that era as well. But I wouldn't be surprised if > > they had much better paging behavior than the SunOS pager. > > On the lispos mailing list, some people were reminiscing about being > ordered to move from lisp machines to suns. Their apps used many > times more memory than was available on the lisp machine, but still > worked fine. When moved to the suns they had to buy enough memory so > that the entire application could run in ram, and at that point > performance was just competitive - not better. In the Unix haters handbook a mail from John Rose is being quoted in the preface about the pros and cons of suns versus Lispms. The suns sure boot fast ;-) Lieven From owner-scwm-discuss@mit.edu Mon Oct 19 15:00:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14618 for scwm-discuss-outgoing; Mon, 19 Oct 1998 15:00:53 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14615 for ; Mon, 19 Oct 1998 15:00:51 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA18895; Mon, 19 Oct 98 15:00:49 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA01943; Mon, 19 Oct 1998 14:00:35 -0500 To: Greg Badros Cc: mal@bewoner.dma.be, Todd Larason , scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> From: Jim Blandy Date: 19 Oct 1998 14:00:34 -0500 In-Reply-To: Greg Badros's message of 15 Oct 1998 07:46:55 -0700 Message-Id: Lines: 9 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Maybe we should have a build option that forces a GC at each hook > invocation so we're sure data structures are stable then. Or just a way > to reduce the heap size so GCs happen a *lot* more frequently so we > increase our chances of finding these kinds of problems. Not even that. Have a hacked version of SCM_NEWCELL that calls GC every time a cell is allocated. I'm willing to run something overnight if it will guarantee me a bug fix. :) From owner-scwm-discuss@mit.edu Mon Oct 19 15:02:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14641 for scwm-discuss-outgoing; Mon, 19 Oct 1998 15:02:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14638 for ; Mon, 19 Oct 1998 15:02:11 -0400 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA19209; Mon, 19 Oct 98 15:02:08 EDT Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id OAA01946; Mon, 19 Oct 1998 14:01:59 -0500 To: Greg Badros Cc: "merry::satchell"@hermes.dra.hmg.gb, scwm-discuss@mit.edu Subject: Re: Pager induced crash. References: <009CDBB7.B8C1C68E.43@hermes.dra.hmg.gb> From: Jim Blandy Date: 19 Oct 1998 14:01:58 -0500 In-Reply-To: Greg Badros's message of 15 Oct 1998 07:40:17 -0700 Message-Id: Lines: 14 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Could this be the old bug whereby guile crashes when hook procedures' > arguments do not match the called-with arguments? (If yes, Maciej sent > in a patch to the guile folks, but I don't know if it's yet been > applied... any news?) I think so. 1998-10-04 Jim Blandy * backtrace.c (display_error_body): The current frame does not always have a parent frame; consider a function called directly from the MAIN_FUNC passed to scm_boot_guile. (Thanks to Maciej Stachowiak.) From owner-scwm-discuss@mit.edu Mon Oct 19 15:03:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14677 for scwm-discuss-outgoing; Mon, 19 Oct 1998 15:03:24 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14673; Mon, 19 Oct 1998 15:03:23 -0400 Message-Id: <199810191903.PAA14673@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: anoncvs problems Date: Mon, 19 Oct 1998 15:03:23 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk anoncvs was down for a bit there, but it should be back up now. On the plus side, the server has had more memory installed, so access in general, whether anoncvs or ftp or whatever should be much faster. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 19 20:44:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA16643 for scwm-discuss-outgoing; Mon, 19 Oct 1998 20:44:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA16640 for ; Mon, 19 Oct 1998 20:44:12 -0400 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA20526; Mon, 19 Oct 98 20:44:09 EDT Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id UAA18125; Mon, 19 Oct 1998 20:44:02 -0400 (EDT) Message-Id: <199810200044.UAA18125@jekyll.piermont.com> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt In-Reply-To: Your message of "19 Oct 1998 09:48:55 +0200." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 19 Oct 1998 20:44:02 -0400 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Harvey J. Stein writes: > That's what Richard Stallman said about it when I asked him, that it > was so integrated it became impossible to change anything without > breaking something. Think about every application's fcns being > accessible from all other applications. It gets to the point where > all sorts of apps are using functions you wrote so you can't change > them any more. Probably a proper module system, with good versioning, would fix this phenomenon. That doesn't make the integration of the environment bad, though. Perry From owner-scwm-discuss@mit.edu Mon Oct 19 23:50:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA17634 for scwm-discuss-outgoing; Mon, 19 Oct 1998 23:50:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA17631 for ; Mon, 19 Oct 1998 23:50:49 -0400 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA15588; Mon, 19 Oct 98 23:50:44 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA24316; Mon, 19 Oct 1998 20:50:40 -0700 (PDT) To: Jim Blandy Cc: mal@bewoner.dma.be, Todd Larason , scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> From: Greg Badros Date: 19 Oct 1998 20:50:40 -0700 In-Reply-To: Jim Blandy's message of "19 Oct 1998 14:00:34 -0500" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > Not even that. Have a hacked version of SCM_NEWCELL that calls GC > every time a cell is allocated. I'm willing to run something > overnight if it will guarantee me a bug fix. :) A little bit harder w/ an interactive system, though. We'd have to experiment with UI automated stress-testers (xlab? xtest?) to make this tenable, since no one would want to test scwm if the GC is invoked *that* often. SCM_NEWCELL sounds like the right place to be forcing GCs, though. BTW, any thoughts about how best to add a callback at start of GC and end end of GC? Maybe we'd have to restrict what can be done at the start of GC to avoid the already-out-of-memory-and-unable-to-allocate a new cons cell problem. I'm thinking it'd be useful , e.g., change the root cursor, or display a message when scwm GCs (probably only for performance debugging for now). Thanks, Greg From owner-scwm-discuss@mit.edu Tue Oct 20 03:26:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18771 for scwm-discuss-outgoing; Tue, 20 Oct 1998 03:26:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18768 for ; Tue, 20 Oct 1998 03:26:54 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA05505 for scwm-discuss@huis-clos.mit.edu; Tue, 20 Oct 1998 09:09:54 +0200 (MET DST) Received: (qmail 1261 invoked by uid 115); 19 Oct 1998 22:33:27 -0000 To: scwm-discuss@mit.edu Subject: Re: Session Management References: <199810181559.LAA16951@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 20 Oct 1998 00:33:24 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 18 Oct 1998 11:59:46 EDT" Message-ID: Lines: 39 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 18 Oct 1998 11:59:46 EDT >>>>> Maciej Stachowiak said: Maciej> Doesn't session management have a way to get unique IDs for Maciej> SM clients that are persistent across sessions? It seems any Maciej> IPC would be bound to break across sessions without this. As I understand it, the client-id is private between the session manager and the client. I see no clean way to get at this information from another client (scwm). The authors of the SM standard seemed to expect that window managers will play session managers themselves - a thing that I'd rather *not* do. But perhaps there is no choice ... >> * Internals >> Very much of scwm internal settings could be convinient to save. >> Taken to the extreme, no special scwmrc would be necessary. You >> simply set a key binding, window style, whatever and it >> automatically persists until you remove it (or start a clean-slate >> session). Maciej> That would be a good goal to shoot for, but I am not sure Maciej> there is an effective way to do it short of dumping the whole Maciej> Guile heap. I'm not even sure this is fully desirable. It clearly needs much thought, before we can tackle this. Anyway, we can keep it in mind while redesigning other things like the decoration system. For example, the current window-styles do not easily fit a persistant model. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Oct 20 03:27:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18778 for scwm-discuss-outgoing; Tue, 20 Oct 1998 03:27:10 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18775 for ; Tue, 20 Oct 1998 03:27:08 -0400 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA05504 for scwm-discuss@huis-clos.mit.edu; Tue, 20 Oct 1998 09:09:50 +0200 (MET DST) Received: (qmail 1189 invoked by uid 115); 19 Oct 1998 22:11:55 -0000 To: scwm-discuss@mit.edu Subject: Re: Session Management References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 20 Oct 1998 00:11:54 +0200 In-Reply-To: Greg Badros's message of "18 Oct 1998 17:52:22 -0700" Message-ID: Lines: 51 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) X-Now-Playing: In The Nursery - Sense (12,12) - Contre-coeur Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 18 Oct 1998 17:52:22 -0700 >>>>> Greg Badros said: Greg> Obviously, I'm curious how bad the sm was.... I was working Greg> only from the spec (and another wm) [...] The main bug was the use of "&props" in the `SmcSetProperties' call. This caused a segfault whenever the code was reached - i.e. when SESSION_MANAGER was set. I can't remember other gross bugs although I reworked much of `setSMProperties' to do more useful things. Greg> since I've no session manager in use yet. I recommend you do: A way to emulate the normal X way of life with xsm (I know of no other usabel session manager) is to call only xsm from ".xinitrc"/".xsession" and move any programs calls you had there (scwm, xterms, that stuff) into ".xsmstartup". xsm will use this as your default session. If you never do a checkpoint, it will forever stay so, just like before. A big goodie is that xsm will immediately restart scwm whenever it crashes. (Actually it will restart scwm even if you quit normally - I still have to decide whether this is bug or feature .) Greg> I'd love for the changes to get checked in, even if they are Greg> still not very functional. All I have is checked in now. >> * Window geometries Greg> Right-- taking into account their virtual window positions, Greg> too. There's a tradeoff between moving all windows back to the Greg> home viewport when scwm shuts down vs. leaving them where they Greg> were so an immediate restart gets you almost back to where they Greg> were. That sounds reasonable: move windows back onto the screen on shutdown, but save virtual positions that can be restored on session restart. I still need a way to identify cliente uniquely ... Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Oct 20 09:30:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA21232 for scwm-discuss-outgoing; Tue, 20 Oct 1998 09:30:04 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA21222 for ; Tue, 20 Oct 1998 09:29:59 -0400 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28495; Tue, 20 Oct 98 09:29:48 EDT Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id PAA02439; Tue, 20 Oct 1998 15:29:31 +0200 To: perry@piermont.com Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: scwm-procedures.txt References: <199810200044.UAA18125@jekyll.piermont.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Oct 1998 15:29:31 +0200 In-Reply-To: "Perry E. Metzger"'s message of "Mon, 19 Oct 1998 20:44:02 -0400" Message-Id: Lines: 24 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Harvey J. Stein writes: > > That's what Richard Stallman said about it when I asked him, that it > > was so integrated it became impossible to change anything without > > breaking something. Think about every application's fcns being > > accessible from all other applications. It gets to the point where > > all sorts of apps are using functions you wrote so you can't change > > them any more. > > Probably a proper module system, with good versioning, would fix this > phenomenon. That doesn't make the integration of the environment bad, > though. I don't see why the package system wouldn't deal with it. Maybe they didn't have a package system at the time. As an aside, I've heard it said that a package system is not a module system. Can anyone explain exactly what each is supposed to achieve? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Oct 21 12:21:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14253 for scwm-discuss-outgoing; Wed, 21 Oct 1998 12:21:22 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA14248; Wed, 21 Oct 1998 12:21:18 -0400 Message-Id: <199810211621.MAA14248@huis-clos.mit.edu> To: guile@cygnus.com cc: scwm-discuss@mit.edu Subject: Planned presentation at The Bazaar Date: Wed, 21 Oct 1998 12:21:18 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm planning to submit the following presentation plan for The Bazaar (http://www.thebazaar.org), and possibly other free software type conferences coming up. If anyone has comments on the abstract or would like to join me in writing the paper and doing the presentation, please let me know. I'd be especially interested in being joined by other Guile app developers, so they can add their perspective on using Guile, Title: Extending Applications with Guile Presenters: Maciej Stachowiak Contact Address: Maciej Stachowiak 6 Bristol Street Cambridge, MA 02141 Phone: (work #) (508) 480-0881 x5279 E-Mail: mstachow@mit.edu Abstract: A good extension language is a crucial component of any significant application. While free availability of source code enables any user to customize his copy of an application in theory, in practice, modifying the source code of an application written in a langauge such as C or C++ is an often excessive cost for a small change or addition. Many applications provide at least a configuration language - a way of setting certain options. An extension langauge is the logical next step. It lets the user actually program aspects of an application's functionality in a very high level language and extend aspects of its behavior. In fact, for a very large application, it may be useful to write only the very basic primitves in a low-level language like C and write much of the actual functionality in the extension language. Emacs has used this strategy with great success. Guile is the GNU Project's extension language. It is based on Scheme with numerous extensions, such as a module system and Posix facilities. It features a very easy to use C language API, clear semantics and good support for a wide variety of programming tasks. It is designed to have the power of a full programming language while providing the ease of use of a scripting/extension language. This presentation will show how to add Guile extensibility to an application, starting with the basics and moving on to more advanced concepts like defining new data types, creating dynamically loadable exception handling and how to leverage extensions like guile-gtk. Examples will be used from a number of Guile-enabled applications, including Scwm, SIAG, GnuCash and others. There will also be some discussion of up and coming developments in the Guile world. From owner-scwm-discuss@mit.edu Wed Oct 21 15:24:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA15139 for scwm-discuss-outgoing; Wed, 21 Oct 1998 15:24:05 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA15136; Wed, 21 Oct 1998 15:24:02 -0400 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 21 Oct 1998 15:22:29 -0400 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 21 Oct 1998 15:22:29 -0400 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id PAA04644; Wed, 21 Oct 1998 15:23:25 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Planned presentation at The Bazaar References: <199810211621.MAA14248@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Wed, 21 Oct 1998 12:21:18 EDT" X-Mailer: Gnus v5.5/Emacs 20.3 Date: 21 Oct 1998 15:23:24 -0400 Message-ID: Lines: 35 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810211621.MAA14248@huis-clos.mit.edu> >>>> On the subject of "Planned presentation at The Bazaar" >>>> Sent on Wed, 21 Oct 1998 12:21:18 EDT >>>> Honorable Maciej Stachowiak writes: >> >> Many applications provide at least a configuration language - a way >> of setting certain options. An extension langauge is the logical >> next step. It lets the user actually program aspects of an >> application's functionality in a very high level language and extend >> aspects of its behavior. In fact, for a very large application, it >> may be useful to write only the very basic primitves in a low-level >> language like C and write much of the actual functionality in the >> extension language. Emacs has used this strategy with great success. ... to its logical end. (http://www.goems.com/~sds/tool.html) When a "killer app" (like Emacs) has a reasonably good extension language (like ELisp), people start writing everything in this extension language, like newsreaders (gnus), web browsers (w3), spreadsheets (dismal) and computer algebra systems (calc). It is time to make the next step: from using an "extension" language (like quile) to extend applications to full-fledged powerful general-purpose language with a good library (I hint in the direction of ANSI Common Lisp here, but I would settle for any similarly powerful language). With shared libraries, it doesn't matter whether your applications are extended with a 1MB libguile or 2MB libclisp, but it will matter for the users whether they will have to reinvent hash tables, structures and arrays. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Who is General Failure and why is he reading my hard disk? From owner-scwm-discuss@mit.edu Wed Oct 21 16:57:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA17915 for scwm-discuss-outgoing; Wed, 21 Oct 1998 16:57:11 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA17905; Wed, 21 Oct 1998 16:57:00 -0400 Message-Id: <199810212057.QAA17905@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: Planned presentation at The Bazaar In-reply-to: Your message of "21 Oct 1998 15:23:24 EDT." Date: Wed, 21 Oct 1998 16:57:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > ... to its logical end. (http://www.goems.com/~sds/tool.html) > I love the web pages there! Here is my favorite self-reproducing expression in Lisp (works in Scheme, Common Lisp and Emacs Lisp): ((lambda (x) (list x (list (quote quote) x))) (quote (lambda (x) (list x (list (quote quote) x))))) I think this is cuter than any of your collection because the self-reproduction structure is so transparent. > When a "killer app" (like Emacs) has a reasonably good extension > language (like ELisp), people start writing everything in this extension > language, like newsreaders (gnus), web browsers (w3), spreadsheets > (dismal) and computer algebra systems (calc). > > It is time to make the next step: from using an "extension" language > (like quile) to extend applications to full-fledged powerful > general-purpose language with a good library (I hint in the direction of > ANSI Common Lisp here, but I would settle for any similarly powerful > language). With shared libraries, it doesn't matter whether your > applications are extended with a 1MB libguile or 2MB libclisp, but it > will matter for the users whether they will have to reinvent hash > tables, structures and arrays. I agree with you, but I think Guile is actually moving in this direction, i.e. an embeddable language with the scope of Common Lisp but based on a Scheme core. In particular, it already has hash tables, structures and arrays (all these features could be implemented better, but this is actually being done). However, since core and extensions are clearly partitioned, the library size problem can be finessed entirely using dynamically loadable extensions. (btw, libguile is 380k stripped, not 1M and I'd like to see a libclisp that comes within an order of magnitude of that). I know tastes vary, but I personally would much rather use a hypothetical Common Scheme than Common Lisp. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 21 18:53:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA18774 for scwm-discuss-outgoing; Wed, 21 Oct 1998 18:53:26 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from smtp0-alterdial.uu.net (smtp0-alterdial.UU.NET [192.48.96.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA18771; Wed, 21 Oct 1998 18:53:22 -0400 Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.238]) id QQfmcp16203; Wed, 21 Oct 1998 22:52:58 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id SAA05462; Wed, 21 Oct 1998 18:49:54 -0400 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Planned presentation at The Bazaar References: <199810212057.QAA17905@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Wed, 21 Oct 1998 16:57:00 EDT" Date: 21 Oct 1998 18:49:54 -0400 Message-ID: Lines: 73 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199810212057.QAA17905@huis-clos.mit.edu> >>>> On the subject of "Re: Planned presentation at The Bazaar" >>>> Sent on Wed, 21 Oct 1998 16:57:00 EDT >>>> Honorable Maciej Stachowiak writes: >> sds@goems.com writes: >> > >> > ... to its logical end. (http://www.goems.com/~sds/tool.html) >> I love the web pages there! thanks! >> ((lambda (x) (list x (list (quote quote) x))) >> (quote (lambda (x) (list x (list (quote quote) x))))) cool! can I quote this on my page? (with proper reference, of course; is this original by you?) >> > When a "killer app" (like Emacs) has a reasonably good extension >> > language (like ELisp), people start writing everything in this extension >> > language, like newsreaders (gnus), web browsers (w3), spreadsheets >> > (dismal) and computer algebra systems (calc). >> > >> > It is time to make the next step: from using an "extension" language >> > (like guile) to extend applications to full-fledged powerful >> > general-purpose language with a good library (I hint in the direction of >> > ANSI Common Lisp here, but I would settle for any similarly powerful >> > language). With shared libraries, it doesn't matter whether your >> > applications are extended with a 1MB libguile or 2MB libclisp, but it >> > will matter for the users whether they will have to reinvent hash >> > tables, structures and arrays. >> >> I agree with you, but I think Guile is actually moving in this >> direction, i.e. an embeddable language with the scope of Common Lisp >> but based on a Scheme core. In particular, it already has hash >> tables, structures and arrays (all these features could be >> implemented better, but this is actually being done). These are not standard scheme (R5RS) features. Other R5RS extensions could implement these differently, and voila - we will be with all the different `schemes' where we were with various lisps in the early 80-ies, when CL was started. Why not use the results of 15 years of progress now, instead of reinventing the wheel like MS does? We are getting another ELisp here - a language strongly identified with its implementation. Soon, SCWM et al will not be extensible "with scheme" but only with "Guile", the crucial difference being that you cannot replace implementation - you are stuck. IMO, standardization here is crucial - it makes the application developer independent from from the extension-language developer, so that if someone comes up with a better implementation, you can easily switch. >> (btw, libguile is 380k stripped, not 1M and I'd like to see a >> libclisp that comes within an order of magnitude of that). Well, CLISP is a 1.5 mb executable. Size is not a big deal. An extra MB matter little these days. >> I know tastes vary, but I personally would much rather use a >> hypothetical Common Scheme than Common Lisp. ^^^^^^^^^^^^! Exactly! Now, the only advantages of Scheme over CL are simplicity and smallness. When they are gone from Common Scheme, what will the advantages be? Why not stick with the existing CL, with several robust implementations, rather than reinvent the wheel? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Wed Oct 21 19:24:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA18961 for scwm-discuss-outgoing; Wed, 21 Oct 1998 19:24:57 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA18958 for ; Wed, 21 Oct 1998 19:24:57 -0400 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA11393; Wed, 21 Oct 98 19:24:32 EDT Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id BAA08500; Thu, 22 Oct 1998 01:24:31 +0200 (MET DST) Date: Thu, 22 Oct 1998 01:24:31 +0200 (MET DST) Message-Id: <199810212324.BAA08500@mdj.nada.kth.se> From: Mikael Djurfeldt To: scwm-discuss@mit.edu Subject: scwm-19981020 loads boot-9.scm twice wth new Guile snapshots Reply-To: Mikael Djurfeldt Sender: owner-scwm-discuss@mit.edu Precedence: bulk The reason is to be found in scwm_gh_launch_pad. Best regards, /mdj From owner-scwm-discuss@mit.edu Wed Oct 21 21:13:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA19600 for scwm-discuss-outgoing; Wed, 21 Oct 1998 21:13:30 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA19593; Wed, 21 Oct 1998 21:13:26 -0400 Message-Id: <199810220113.VAA19593@huis-clos.mit.edu> To: Mikael Djurfeldt cc: scwm-discuss@mit.edu Subject: Re: scwm-19981020 loads boot-9.scm twice wth new Guile snapshots In-reply-to: Your message of "Thu, 22 Oct 1998 01:24:31 +0200." <199810212324.BAA08500@mdj.nada.kth.se> Date: Wed, 21 Oct 1998 21:13:26 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mdj@nada.kth.se writes: > The reason is to be found in scwm_gh_launch_pad. Yipe! I'll try to add an autoconf test. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 22 01:49:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA20998 for scwm-discuss-outgoing; Thu, 22 Oct 1998 01:49:15 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA20995 for ; Thu, 22 Oct 1998 01:49:13 -0400 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA12458; Thu, 22 Oct 98 01:48:45 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA20989; Thu, 22 Oct 1998 01:49:09 -0400 Message-Id: <199810220549.BAA20989@huis-clos.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Planned presentation at The Bazaar In-Reply-To: Your message of "21 Oct 1998 18:49:54 EDT." Date: Thu, 22 Oct 1998 01:49:09 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > >> ((lambda (x) (list x (list (quote quote) x))) > >> (quote (lambda (x) (list x (list (quote quote) x))))) > > cool! can I quote this on my page? (with proper reference, of course; is > this original by you?) > I thought it up myself right before posting, but I later found this expression has been reinvented many times. The more I think about this expression, the more I like it: it beautifully demonstrates many of the greatest advantages of the Lisp language family (most notably first-class functions and the tight code/data relationship) in a very small space. Regarding the below: Oh boy. I am really hesitant to get into "my favorite language" discussions. In fact, Common Lisp vs. Scheme is such a classic in this area that it's best avoided. I will outline some reasons why I think Common Scheme will (a) come to pass and become a standard and (b) will be better than Common Lisp. For the sake of fairness I will quote your remarks in full. > >> I agree with you, but I think Guile is actually moving in this > >> direction, i.e. an embeddable language with the scope of Common Lisp > >> but based on a Scheme core. In particular, it already has hash > >> tables, structures and arrays (all these features could be > >> implemented better, but this is actually being done). > > These are not standard scheme (R5RS) features. Other R5RS extensions > could implement these differently, and voila - we will be with all the > different `schemes' where we were with various lisps in the early > 80-ies, when CL was started. Why not use the results of 15 years of > progress now, instead of reinventing the wheel like MS does? > > We are getting another ELisp here - a language strongly identified with > its implementation. Soon, SCWM et al will not be extensible "with > scheme" but only with "Guile", the crucial difference being that you > cannot replace implementation - you are stuck. > > IMO, standardization here is crucial - it makes the application > developer independent from from the extension-language developer, so > that if someone comes up with a better implementation, you can easily > switch. > > >> (btw, libguile is 380k stripped, not 1M and I'd like to see a > >> libclisp that comes within an order of magnitude of that). > > Well, CLISP is a 1.5 mb executable. Size is not a big deal. An extra > MB matter little these days. Yeah, but per-binary runtime size does count somewhat (unless you have a server-based implementation). > > >> I know tastes vary, but I personally would much rather use a > >> hypothetical Common Scheme than Common Lisp. > ^^^^^^^^^^^^! > > Exactly! > Now, the only advantages of Scheme over CL are simplicity and smallness. > When they are gone from Common Scheme, what will the advantages be? > Why not stick with the existing CL, with several robust implementations, > rather than reinvent the wheel? a) Why Common Scheme will, in effect, happen, and will not be tied to a specific implementation: It is true that many Guile features are not R5RS standard. And it is true that the way the Scheme standardization process worked, only a small core typically ended up in the standard. However, in my (somewhat educated) opinion, the Scheme community has been fracturing into at least two camps for some time: the camp that wants a really tiny language of mostly academic interest, and the camp that wants to be able to protably use a wide range of functionality for professional worl. Guy L. Steele himself admited to and somewhat encouraged this process on the rrrs-authors list. Recently, at an ad-hoc meeting for discussing straw-man proposals for possible Scheme standardization, a number of core features were recommended for standardization to the RnRS authors, and more significantly, there was a general agreement to form a repository of documents standardizing various extensions to Scheme; these would not be part of the RnRS standard but so-called RFIs (Requests For Implementation). These will have the net effect of standardizing popular extensions because implementors will be highly motivated to satisfy the RFIs when adding extensions. It may even happen that certain RFIs might get explicit mention in future Scheme standards. b) Why Common Scheme would be better than Common Lisp, in my opinion: * Cleaner semantics. To name a few examples: ** I really dislike the separate function and variable namespaces in CL, the fact that the operator is evaluated by different rules than operands, and the gyrations you have to go through to get around them. ** Scheme has hygienic macros (I admit I haven't yet used them in a significant project, but I am glad they exist). ** I like the Scheme naming conventions better than the CL ones. ** Guaranteed proper tail recursion is good. ** I don't like CL's concept of a symbol having explicit value, function, property list, package etc slots. ** I don't like the way CL handles booleans (neither the fact that they are special symbols or that (eq nil ()). ** I don't like the tangled CL type hierarchy. ** In general, almost anywhere that Scheme and CL both address the same issue, I like the Scheme answer better. (One notable exceptions: I like CL's syntax for complex numbers better). CL's advantage right now is that it addresses many issues in the standard that need to be addressed individually by each Scheme implementation. * I expect features added to Scheme, either the core or standardized libraries, will also be very carefully considered and will have clean semantics as above, as well as being more streamlined. * A small *core* lanaguage. To me, the important thing about Scheme's simplicity and smallness is not so much that the whole language is small (any useful implementation extends it), but that there is a small, well-defined core. If a good set of libraries were standardized in addition to this core (whis is in effect happening) and if a few key features got added to the core (most importantly a module/package system), this property would be preserved, while providing the functionality that the Scheme/Lisp programmers of history have found useful in a neatly partitioned way. Common Lisp, by contrast, is a big, monolithic beast. It is hard to take out a small subset on the basis of which the rest of the language can be understood. I had a hard time reading CLtL the first time because there was just so much, and it was hard to find the important bits. Even the ISO committee standardizing ISLisp is going with the core+libraries/layers approach. With a small core and disciplined extensions, it will still be possible to write a formal semantics for the core fairly easy, and define everything else in terms of that. * Some IMO gratuitously useless and annoying CL features, like the `loop' macro, will hopefully be left out entirely. * More generally, just because we have a good, featureful language in the form of CL, is that a reason not to try to do better in achieving similar goals? You could call this a mere "reinventing [of] the wheel" but I think it is possible to end up with cleaner, nicer semantics by starting from scratch and rethinking everything (on top of an already clean core) than to just accept the effects of evolution and live with them. I think that in some sense GNU/Linux has done this for traditional proprietary Unix - through rethinking of key issues in the GNU tools and the Linux kernel, a much more pleasant and consistent system has resulted. Overall, though, I'd rather use _any_ language in the Lisp family than C/C++/Java for any task not best done with the (semi-)portable assembly languages these in effect are. I think the community centered around various Lisp-family languages really has much more to bring them together than to keep them apart, and that is often forgotten in language wars. I think the page on the Lisp family of languages linked off your homepage has a very good point - Lisp _is_ a family, and there are good reasons to have more than one, just as C, Objective C, C++ and Java all have reasons to exist. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Oct 22 10:09:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA12115 for scwm-discuss-outgoing; Thu, 22 Oct 1998 10:09:36 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA12109 for ; Thu, 22 Oct 1998 10:08:52 -0400 Received: from whirligig.ecs.soton.ac.uk by MIT.EDU with SMTP id AA25310; Thu, 22 Oct 98 10:08:39 EDT Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by whirligig.ecs.soton.ac.uk (8.9.1/8.9.1) with SMTP id PAA01979 for ; Thu, 22 Oct 1998 15:05:40 +0100 (BST) Message-Id: <11434.199810221407@penelope.ecs.soton.ac.uk> Received: from ecs.soton.ac.uk by penelope.ecs.soton.ac.uk; Thu, 22 Oct 1998 15:07:26 +0100 Date: Thu, 22 Oct 1998 23:14:26 +0100 (GMT) From: Mark Toller Reply-To: mst95r@ecs.soton.ac.uk Subject: X Text Selection.... To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I was just playing about with the 'netscape-goto-cut-buffer-url' command, and noticed that it didn't have the current selection - this was selected in a netscape window - middle mouse button could paste it into an xterm etc... I've noticed the same effect selecting text from tkRat - so, if this text isn't what the X-get-cutbuffer returns, then is there another way of getting it (so that select and netscape-goto-cut-buffer-url) are then uniform across xterm, netscape and tkRat)? Cheers, -- Mark Toller http://www.ecs.soton.ac.uk/~mst95r/ Electronics and Computer Science tel +44 01703 594492 University of Southampton Southampton SO17 1BJ. From owner-scwm-discuss@mit.edu Thu Oct 22 10:55:25 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA12348 for scwm-discuss-outgoing; Thu, 22 Oct 1998 10:55:25 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA12345 for ; Thu, 22 Oct 1998 10:55:24 -0400 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA11453; Thu, 22 Oct 98 10:55:22 EDT Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id KAA32104 for ; Thu, 22 Oct 1998 10:55:17 -0400 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Planned presentation at The Bazaar References: <199810212057.QAA17905@huis-clos.mit.edu> Date: 22 Oct 1998 10:55:05 -0400 Message-Id: <5lvhlcr6ie.fsf@tequila.cs.yale.edu> Lines: 10 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 22 Oct 1998 10:55:06 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>> ((lambda (x) (list x (list (quote quote) x))) >>> (quote (lambda (x) (list x (list (quote quote) x))))) > cool! can I quote this on my page? (with proper reference, of course; is > this original by you?) I doubt it is: this looks suspiciously like the Y combinator for strict languages. Stefan From owner-scwm-discuss@mit.edu Thu Oct 22 11:15:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA12497 for scwm-discuss-outgoing; Thu, 22 Oct 1998 11:15:42 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA12494 for ; Thu, 22 Oct 1998 11:15:41 -0400 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Thu, 22 Oct 1998 16:15:24 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 157; Thu, 22 Oct 1998 16:14:57 GMT Date: Thu, 22 Oct 1998 16:14:53 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CE15F.9112DC7E.157@hermes.dra.hmg.gb> Subject: Pager news. (Again) Sender: owner-scwm-discuss@mit.edu Precedence: bulk The pager is working reasonably stably now, but still crashes scwm after exitting. If you want me to send more details please ask; I have already sent a backtrace in from a previous crash. I have also made a little standalone pager that is pure gtk, without gnome. It has about 90% code in common with the gtk one, so I think I can make it a conditional compilation if I can just figure out how to tell that to autoconf/make. What would be nice would be to build only the gtk pager if only gtk can be found, but also to make the pager applet if gnome is found as well. Finally I note that work has started on a Gnome configuration utility for Enlightenment. We can't have the competition sneaking through on the rails; if we were going to have such a thing, as distinct from prefs-menu, what should it do and how? (Apart from using scwmexec to communicate, which I take as given.) My first thoughts would be to have some of the main stylistic choices, like focus type, default decor, default menu style etc settable, and given persistency by writing out a .scwm-options file, which is included by co-operative .scwmrc files. Kind of like (x)emacs with .emacs-options. I am not clear what if any advantages there are in having a configuration utility over what prefs-menu can do. Julian Satchell From owner-scwm-discuss@mit.edu Thu Oct 22 13:54:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA13311 for scwm-discuss-outgoing; Thu, 22 Oct 1998 13:54:03 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA13304; Thu, 22 Oct 1998 13:54:00 -0400 Message-Id: <199810221754.NAA13304@huis-clos.mit.edu> To: Stefan Monnier cc: scwm-discuss@mit.edu Subject: Re: Planned presentation at The Bazaar In-reply-to: Your message of "22 Oct 1998 10:55:05 EDT." <5lvhlcr6ie.fsf@tequila.cs.yale.edu> Date: Thu, 22 Oct 1998 13:54:00 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk monnier+lists/scwm/discuss/news/@tequila.cs.yale.edu writes: > >>> ((lambda (x) (list x (list (quote quote) x))) > >>> (quote (lambda (x) (list x (list (quote quote) x))))) > > cool! can I quote this on my page? (with proper reference, of course; is > > this original by you?) > > I doubt it is: this looks suspiciously like the Y combinator for > strict languages. > I thought the Y operator (for Scheme, applicative order) is: (lambda (f) ((lambda (x) (x x)) (lambda (x) (f (lambda () (x x)))))) That hardly looks similar to me. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Oct 22 20:48:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA15618 for scwm-discuss-outgoing; Thu, 22 Oct 1998 20:48:31 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA15615 for ; Thu, 22 Oct 1998 20:48:28 -0400 Received: from molehill.involved.com by MIT.EDU with SMTP id AA14894; Thu, 22 Oct 98 20:48:25 EDT Received: (qmail 16372 invoked by uid 501); 23 Oct 1998 00:50:50 -0000 Message-Id: <19981022175049.A15194@molehill.org> Date: Thu, 22 Oct 1998 17:50:49 -0700 From: Todd Larason To: scwm-discuss list Subject: Display Ghostscript? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "Listen to my Stallone impression", said Tom slyly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've been corresponding with Don Hopkins, pie menu advocate and author of piewm. He's an old NeWS hacker, and one of his first questions after looking at the scwm webpage is if there were any plans to incorporate Ghostscript libraries and make them accessible from the scheme level. It sounds like an interesting idea, maybe as an alternative to guile-gtk for window drawing. I also have heard that Display Ghostscript is being worked on for the GnuStep project, which might have the full widget-building capability guile-gtk would? This also reminded me of seeing a functional postscript-like language being one of the Scheme Underground wants. Looking now, it looks like it's actually been done. http://www.mit.edu/people/wandy/fps/fps.html described Functional Postscript. Does anybody have any experience with this, and any idea whether moving it from scheme48 to guile would give us any benefits? From owner-scwm-discuss@mit.edu Thu Oct 22 21:15:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15898 for scwm-discuss-outgoing; Thu, 22 Oct 1998 21:15:51 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA15890; Thu, 22 Oct 1998 21:15:43 -0400 Message-Id: <199810230115.VAA15890@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Display Ghostscript? In-reply-to: Your message of "Thu, 22 Oct 1998 17:50:49 PDT." <19981022175049.A15194@molehill.org> Date: Thu, 22 Oct 1998 21:15:40 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I've been corresponding with Don Hopkins, pie menu advocate and author > of piewm. He's an old NeWS hacker, and one of his first questions after > looking at the scwm webpage is if there were any plans to incorporate > Ghostscript libraries and make them accessible from the scheme level. > > It sounds like an interesting idea, maybe as an alternative to guile-gtk > for window drawing. I also have heard that Display Ghostscript is being > worked on for the GnuStep project, which might have the full widget-building > capability guile-gtk would? > One thing I think DPS could be potentially be really good for highly Scheme-customizable decoration drawing code. I was thinking about this issue recently, and I think we need higher level operators for such a thing than just exporting raw Xlib (or gdk). There is also a GtkDPS librarary, it should be feasible to use the guile-gtk .defs-parsing code to make a Guile interface to that. > This also reminded me of seeing a functional postscript-like language being > one of the Scheme Underground wants. Looking now, it looks like it's > actually been done. http://www.mit.edu/people/wandy/fps/fps.html > described Functional Postscript. Does anybody have any experience with > this, and any idea whether moving it from scheme48 to guile would give us > any benefits? Jim Blandy actually mentioned this as a volunteer task that he thinks would be useful to Guile in general (i.e. porting FPS to Guile). I think it would be useful as well, both in generally and potentially for scwm specifically. I think moving it from scheme48 to Guile will have tangible benefits as well: (a) Guile is more easily embeddable, and (b) Guile is acquiring a considerably greater number of extension modules. Thus, it would be very useful to be able to mix the power of FPS with all the other things Guile can integrate with. Another cool idea for drawing is the Gnome Canvas, which is similar to the Tk canvas but has many spiffy features both existing and in development, like fast rendering of vector paths, beziers and images with antialiasing and alpha channel support (I don't think X/DPS has alpha-channel support by default). The only realy hard thing about decoration-drawing stuff is, IMO, handling shapes properly. The XShape API is much too confusing to export literally. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Oct 22 23:41:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA16673 for scwm-discuss-outgoing; Thu, 22 Oct 1998 23:41:56 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA16668; Thu, 22 Oct 1998 23:41:30 -0400 Message-Id: <199810230341.XAA16668@huis-clos.mit.edu> To: "H. Tapio Rummukainen" cc: scwm-discuss@mit.edu Subject: Re: Planned presentation at The Bazaar In-reply-to: Your message of "22 Oct 1998 18:30:27 -0000." <19981022183027.14622.qmail@alpha.guestlink.net> Date: Thu, 22 Oct 1998 23:41:30 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk turvaton@postpoint.com writes: > > significantly, there was a general agreement to form a > repository of > > documents standardizing various extensions to Scheme; > these would not > > be part of the RnRS standard but so-called RFIs > (Requests For > > Implementation). These will have the net effect of > standardizing > > popular extensions because implementors will be highly > motivated to > > satisfy the RFIs when adding extensions. > > That's all fine and well, but supposing that RFI's become > exceedingly popular, what chance is there of Guile giving > up backwards compatibility in favor of RFI compliance? High, I hope (though I'm not the maintainer). Guile has certainly had non-backwards-compatible changes before, several for greater standards compliance. > It'll take a year or two for the RFI process to get up to > speed, and at that stage there will hopefully and > unfortunately be a lot of code depending on traditional > Guile-specific features. All you can do then is either > say goodbye to Common Scheme or severely bloat Guile > by including incompatible versions of several key > libraries. Libraries for compatibility with old code don't have to bloat the Guile core, they can almost certainly be in loadable modules of either Scheme or C code. If backwards compatibility is seen as very important at that stage, that's the solution I'd argue for. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Oct 23 18:47:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22903 for scwm-discuss-outgoing; Fri, 23 Oct 1998 18:47:46 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22898; Fri, 23 Oct 1998 18:47:44 -0400 Message-Id: <199810232247.SAA22898@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: A wonderful set of books on X11 Date: Fri, 23 Oct 1998 18:47:43 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just discovered a wonderful set of books on X11, the ones from "Digital Press". Their documentation of X extensions in particular is really good - I finally know what the difference between the bounding shape and the clipping shape in the XShape extension. - Maciej From owner-scwm-discuss@mit.edu Sat Oct 24 00:46:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01510 for scwm-discuss-outgoing; Sat, 24 Oct 1998 00:46:12 -0400 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01504; Sat, 24 Oct 1998 00:46:08 -0400 Message-Id: <199810240446.AAA01504@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: animated window shading Date: Sat, 24 Oct 1998 00:46:07 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I noticed while experimenting with animated window shading that you can aminatedly shade or unshade a window that is already in that state and it will instantaneously switch states and then roll back to the right one. Is this intentional? It looks a bit entertaining but I can't see it being useful. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 17:39:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29772 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:39:05 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29769 for ; Mon, 26 Oct 1998 17:39:05 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA28520; Sat, 24 Oct 98 23:23:18 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA09587; Sat, 24 Oct 1998 23:23:19 -0400 Message-Id: <199810250323.XAA09587@huis-clos.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: animated window shading In-Reply-To: Your message of "24 Oct 1998 19:17:50 -0800." Date: Sat, 24 Oct 1998 23:23:19 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I noticed while experimenting with animated window shading that you > > can aminatedly shade or unshade a window that is already in that state > > and it will instantaneously switch states and then roll back to the > > right one. Is this intentional? It looks a bit entertaining but I > > can't see it being useful. > > Not intentional by me. Probably should short-circuit out if state is > already satisfied. We'd still be able to get the current behaviour by > non-animatedly changing the state and then animating to the former > state. (Perhaps it's a useful way to call attention to a window? > Entertainment-value alone is a reason to be sure we don't lose the > behaviour! :-) ) > That's pretty much what I figured. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 17:38:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29763 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:38:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29746 for ; Mon, 26 Oct 1998 17:38:45 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA29890; Mon, 26 Oct 98 12:09:06 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id MAA12163; Mon, 26 Oct 1998 12:08:57 -0500 To: Greg Badros Cc: scwm-discuss list Subject: Re: core dump in garbage collection References: <19981015081828.16044.qmail@localhost.localdomain> <19981015011749.A18461@molehill.org> <19981015091658.12407.qmail@localhost.localdomain> From: Jim Blandy Date: 26 Oct 1998 12:08:56 -0500 In-Reply-To: Greg Badros's message of 23 Oct 1998 11:41:57 -0700 Message-Id: Lines: 13 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Jim Blandy writes: > > > I'd be willing to provide C-level hooks, though, and remove the hooks > > while the it's running. So if you don't allocate, fine, and if you > > do, well, the GC will proceed. All you folks want to do is change the > > cursor or pop up a message, which shouldn't require running any Scheme > > code. > > This'd be great. We definitely want some way to know about when GC is > happening that we can rely upon from release to release of guile. Okay. It's on the list, but the list is long. :) From owner-scwm-discuss@mit.edu Mon Oct 26 17:38:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29764 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:38:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29758 for ; Mon, 26 Oct 1998 17:38:47 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA26144; Mon, 26 Oct 98 11:58:34 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id LAA12154; Mon, 26 Oct 1998 11:58:17 -0500 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: MSTACHOW_LEGAL_BS_BRANCH References: <199810100436.AAA00786@huis-clos.mit.edu> From: Jim Blandy Date: 26 Oct 1998 11:58:15 -0500 In-Reply-To: Maciej Stachowiak's message of Sat, 10 Oct 1998 00:36:11 EDT Message-Id: Lines: 24 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > I ask others not to check it out until the distributability of this > code is clarified (it will be clarified in the positive direction > soon or else I will find a new job). Don't budge, man. I turned down a job at a young research lab that would have gotten me a $26k raise, because, as far as I could tell, they wouldn't let me work on free software, on my own time, in my own house, on my own machine. I just wasn't willing to let them own me that way. > I will try to merge changes from the head onto this branch frequently, > so that it is easy to merge it back once my company signs the papers. You've probably thought this through yourself, but anyway: If you're going to do this, the branch will contain a mix of revisions by you, and revisions from other people; you'll need to disentangle them when you merge back. An alternative to disentangling is to make sure you've merged *all changes* from the trunk into your branch, so your branch looks exactly the way the trunk should, with your changes. Then, instead of merging in the usual way (by applying patches), you instead merge just by replacing the trunk files with your text. From owner-scwm-discuss@mit.edu Mon Oct 26 17:38:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29762 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:38:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29750 for ; Mon, 26 Oct 1998 17:38:46 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA29183; Mon, 26 Oct 98 12:07:07 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id MAA12160; Mon, 26 Oct 1998 12:06:49 -0500 To: Todd Larason Cc: scwm-discuss list Subject: Re: status, ideas References: <19981014021004.A12764@molehill.org> From: Jim Blandy Date: 26 Oct 1998 12:06:47 -0500 In-Reply-To: Todd Larason's message of Wed, 14 Oct 1998 02:10:04 -0700 Message-Id: Lines: 24 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Architecture issues: should this resource library be 1) a dynamic > module for scwm, used only by another kaleidoscope dynamic module that > knows which resources to use and how; 2) a dynamic module for scwm > that exports scwm primitives for fetching resource data by type and > ID, and primitives for converting from the raw data vectors to various > X equivalents, and scheme code to package all of that into an > easy-to-use (use-kaleidoscope-theme) package; or 3) an external > utility that converts a kaleidoscope theme into (possibly many > hundreds) of individual .xpm files and whatever configuration is > needed to use those as an scwm theme? I'd split it up this way: 1) A general purpose dynamic module for Guile/SCWM that exports general functions for frobbing Apple resource data files. This could be used by anyone working with Apple resources. 2) A second module that uses the first one to do the right thing to SCWM. I personally like this because it results in a module that other Guile hackers can use, but I think it's also a clean architecture. From owner-scwm-discuss@mit.edu Mon Oct 26 17:38:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29761 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:38:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29754 for ; Mon, 26 Oct 1998 17:38:46 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA29712; Mon, 26 Oct 98 12:08:33 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA28074; Mon, 26 Oct 1998 12:08:29 -0500 Message-Id: <199810261708.MAA28074@huis-clos.mit.edu> To: Jim Blandy Cc: scwm-discuss@mit.edu Subject: Re: MSTACHOW_LEGAL_BS_BRANCH In-Reply-To: Your message of "26 Oct 1998 11:58:15 EST." Date: Mon, 26 Oct 1998 12:08:29 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > > I ask others not to check it out until the distributability of this > > code is clarified (it will be clarified in the positive direction > > soon or else I will find a new job). > > Don't budge, man. > > I turned down a job at a young research lab that would have gotten me > a $26k raise, because, as far as I could tell, they wouldn't let me > work on free software, on my own time, in my own house, on my own > machine. I just wasn't willing to let them own me that way. > The thing is, I am legally allowed to work on and distribute free softeare according to the agreement, there are just annoying disclosure requirements (to make sure the software does not fall in teh category of products they are selling) and I am hoping a signed copyright disclosure will take care of that. Since I effectively distribute my changes to scwm continuously through anoncvs, I don't have the time to run every single patch by legal. They will singn papers supposedly, but the legal dept has been in disarray due to reorganization. I am hoping this will get better soon. > > I will try to merge changes from the head onto this branch frequently, > > so that it is easy to merge it back once my company signs the papers. > > You've probably thought this through yourself, but anyway: > > If you're going to do this, the branch will contain a mix of revisions > by you, and revisions from other people; you'll need to disentangle > them when you merge back. An alternative to disentangling is to make > sure you've merged *all changes* from the trunk into your branch, so > your branch looks exactly the way the trunk should, with your changes. > Then, instead of merging in the usual way (by applying patches), you > instead merge just by replacing the trunk files with your text. I am doing this by merging all changes from the head to my branch periodically. However, as far as I can tell, CVS is smart enough to tell when the same change is made on both branches when merging, so I don't expect there to be problems. The only part that's required any manual tweaking so far is merging the ChangeLogs to thread the entries chronologically (which I think is the right thing to do, though I may reconsider). - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 17:51:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA29935 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:51:10 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29932 for ; Mon, 26 Oct 1998 17:51:09 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22303; Fri, 23 Oct 98 23:23:27 EDT Received: (qmail 32234 invoked by uid 501); 24 Oct 1998 03:27:24 -0000 Message-Id: <19981023202724.A31911@molehill.org> Date: Fri, 23 Oct 1998 20:27:24 -0700 From: Todd Larason To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A wonderful set of books on X11 References: <19981023164204.A30741@molehill.org> <199810240226.WAA23900@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810240226.WAA23900@huis-clos.mit.edu>; from Maciej Stachowiak on Fri, Oct 23, 1998 at 10:26:39PM -0400 X-Tom-Swifty: "If the name 'St. Nicholas' for Santa Claus, and the name 'Old Nick' for the Devil, both derive from the Teutonic sea god Hold Nickar, what does that tell us about Santa Claus?" asked Tom cynically. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981023, Maciej Stachowiak wrote: > Some of it looked like it was probably straight out of the specs, but > I've never seen some of those documents before, and some only in > PostScript format, which is less useful to me than a book (any > non-searchable online format that you can't cut and paste from is just > a paper format that you need to print yourlself). I'm home now and can check. The four volumes I have are: _X Window System: Core Libraries and Standards_ (XLib, ICCCM and XLFD APIs) _X Window System: Extension Libraries_ (the extension APIs) _X Window System: Core And Extension Protocols_ (the X and extension protocols) _X Window System Toolkit_, Second Edition (Xt) The first three are by Robert Scheifler and James Gettys, edited by Al Mento and Donna Converse, and correspond to X11R6.1. The last is by Paul Asente, Donna Converse, and Ralph Swick, and supposedly corresponds to to X11R5-X11R7. As I said, they *are* good books, but they're also spendy, and for some people finding ways of viewing the docs from the X distribution might make more sense. From owner-scwm-discuss@mit.edu Mon Oct 26 17:52:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA30004 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:52:39 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA29925 for ; Mon, 26 Oct 1998 17:50:15 -0500 Received: from terra.nlnet.nf.ca by MIT.EDU with SMTP id AA05943; Sat, 24 Oct 98 01:58:18 EDT Received: from localhost (n254h006.thezone.net [198.165.254.6]) by firma.thezone.net (8.8.8/8.8.8) with ESMTP id DAA30850; Sat, 24 Oct 1998 03:28:17 -0230 (NDT) Received: (from greg@localhost) by localhost (8.8.7/8.8.5) id DAA00306; Sat, 24 Oct 1998 03:28:23 -0230 To: "Wade Humeniuk" Cc: "Maciej Stachowiak" , , , Subject: Re: Planned presentation at The Bazaar References: <001601bdff0c$7c6ab3e0$9341e4cf@default> From: Greg Harvey Date: 24 Oct 1998 03:27:22 -0230 In-Reply-To: "Wade Humeniuk"'s message of "Fri, 23 Oct 1998 23:08:09 -0600" Message-Id: Lines: 46 X-Mailer: Gnus v5.6.43/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Wade Humeniuk" writes: > >It should also be noted that the existance of a group of standardized > >features in scheme would make it quite trivial to implement a cl > >compatable module, so that everyone's tastes can be catered to. I have > >a few modules laying around that provide some cl style things, like > > > Or implement scheme in CL. They are essentially the same language. > A Scheme that implements CL would not be small anymore, but > would be CL. The library approach means it's not all in the core, but there if you want (or need) it. My point here being, that if you really want the features (and misfeatures, like syntax abbhorations) of cl, it should be much easier to accomodate if you already have a standard library available in scheme that implements the same basic functionality (hashtables, struct-like objects, etc). It has no effect on anyone who wants to use the spartan existing features of the core language, but means that those who do want them don't have insane porting headaches between scheme implementations (this goes for all programs, not just a cl-scheme package). It's obviously quite possible to implement cl under any existing scheme implementation, but will require either: 1) Rewriting an awful lot of stuff just using the scheme core, which will likely be slower than any native implementations of the same type of thing. A lot of programming in scheme tends to require wheel inventing, actually, and I feel this is a very big drawback to scheme, which hopefully can be dealt with by having a collection of standard library features. The core will still be the only thing available by default, for teaching and 'real scheme programmers'. 2) Using the native features of a particular scheme, tying you to that scheme, unless you target each individual scheme, which is a lot of work, and probably more than anyone wants to do. It can also break between revisions of any specific scheme. The gist of it is that, without a standardized set of (optional, but available) features, you're better off just using cl (which is an option, but there's a lot about cl to dislike). I'm not suggesting that scheme take the approach of just cloning cl, but to have the useful features available in a well-defined way. -- Greg From owner-scwm-discuss@mit.edu Mon Oct 26 17:54:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA30049 for scwm-discuss-outgoing; Mon, 26 Oct 1998 17:54:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA30046 for ; Mon, 26 Oct 1998 17:54:39 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA11435; Fri, 23 Oct 98 18:36:09 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA22834; Fri, 23 Oct 1998 18:36:03 -0400 Message-Id: <199810232236.SAA22834@huis-clos.mit.edu> To: Todd Larason Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Thu Oct 22 05:52:47 EDT 1998 In-Reply-To: Your message of "Fri, 23 Oct 1998 14:52:04 PDT." <19981023145204.B29271@molehill.org> Date: Fri, 23 Oct 1998 18:35:59 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981022, Maciej Stachowiak wrote: > > `make-resized-image' is also provided; it is used internally by > > set-background-image! to crop or uncrop the image if it is > > centered rather than tiled. > > Does this do only cropping, or does it do rescaling too? If only > cropping, maybe the name could be changed to reflect that? At some point, > I'm going to need a scale-image function (make-scaled-image ?). It makes a cropped copy, but it can also "uncrop" to a larger size, filling with the optional background color. It also only does this centered. It does not rescale. I am planning to write a pair of loadable modules that use Imlib, the image library by Rasterman of Enlightenment fame, one to do image loading using Imlib only (should be _much_ faster than the default, libXpm is _painfully_ slow!) and one to provide a useful set of image-manipulation operations. I am open to renaming that to make-cropped-image or something if people feel that cropping to a larger size counts as cropping too. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 18:03:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30267 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:03:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA30263 for ; Mon, 26 Oct 1998 18:03:29 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA13592 for scwm-discuss@huis-clos.mit.edu; Sat, 24 Oct 1998 09:40:01 +0200 (MET DST) Received: (qmail 21564 invoked by uid 115); 23 Oct 1998 14:14:18 -0000 To: scwm-discuss@mit.edu Subject: `user-name' and `user-home' X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Oct 1998 16:14:09 +0200 Message-ID: Lines: 11 User-Agent: Gnus/5.070036 (Pterodactyl Gnus v0.36) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, the primitives mentioned in the subject have been added. I will eliminate USER and HOME from flux.scm and any references to them in the files under scheme/ and sample.scwmrc/ soon (I hope for tomorrow). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Oct 26 18:03:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30262 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:03:29 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA30258 for ; Mon, 26 Oct 1998 18:03:28 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA13591 for scwm-discuss@huis-clos.mit.edu; Sat, 24 Oct 1998 09:40:00 +0200 (MET DST) Received: (qmail 18618 invoked by uid 115); 23 Oct 1998 14:03:09 -0000 To: scwm-discuss@mit.edu Subject: gzipped xpms X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Oct 1998 16:03:01 +0200 Message-ID: Lines: 11 User-Agent: Gnus/5.070036 (Pterodactyl Gnus v0.36) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, libXpm can handle gzipped xpms. I think it would be useful for `path_expand_image_fname' to also try "/some/path/foo.xpm.gz" when instructed to locate "foo.xpm". Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Oct 26 18:03:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30259 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:03:28 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA30254 for ; Mon, 26 Oct 1998 18:03:26 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id JAA13594 for scwm-discuss@huis-clos.mit.edu; Sat, 24 Oct 1998 09:40:03 +0200 (MET DST) Received: (qmail 26588 invoked by uid 115); 23 Oct 1998 16:07:59 -0000 To: scwm-discuss@mit.edu Subject: list-focus-order X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Oct 1998 18:07:55 +0200 Message-ID: Lines: 9 X-Now-Playing: Another Division Upon a Ground - The Newberry Consort Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I can't get this to work. it always returns the same list - regardless of what I focussed before. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Oct 26 18:09:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30385 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:09:06 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA30382 for ; Mon, 26 Oct 1998 18:09:04 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA12852 for scwm-discuss@huis-clos.mit.edu; Fri, 23 Oct 1998 14:22:10 +0200 (MET DST) Received: (qmail 533 invoked by uid 115); 23 Oct 1998 09:46:04 -0000 To: scwm-discuss@mit.edu Subject: configuration utility References: <009CE15F.9112DC7E.157@hermes.dra.hmg.gb> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 23 Oct 1998 11:46:00 +0200 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Thu, 22 Oct 1998 16:14:53 GMT" Message-ID: Lines: 39 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 22 Oct 1998 16:14:53 GMT >>>>> "merry::satchell"@hermes.dra.hmg.gb said: Julian> Finally I note that work has started on a Gnome configuration Julian> utility for Enlightenment. We can't have the competition Julian> sneaking through on the rails; if we were going to have such Julian> a thing, as distinct from prefs-menu, what should it do and Julian> how? (Apart from using scwmexec to communicate, which I take Julian> as given.) Better than forking off a binary ever so often, is linking in libscwmexec.a (see utilities/libscwmexec). We should perhaps think about making libscwmexec a shared lib if more programs will use it. Julian> My first thoughts would be to have some of the Julian> main stylistic choices, like focus type, default decor, Julian> default menu style etc settable, Sounds good. Julian> and given persistency by writing out a .scwm-options file, Julian> which is included by co-operative .scwmrc files. That's one possiblity. But I like having all settings in one file better, so I put the following unto consideration: Upon saving: (if the .scwmrc file contains begin and end markers) (replace anything between the markers with the new settings) (add the settings surrounded by begin and end markers to the end of the .scwmrc) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Oct 26 18:09:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30393 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:09:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id SAA30390 for ; Mon, 26 Oct 1998 18:09:39 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA29356 for scwm-discuss@huis-clos.mit.edu; Fri, 23 Oct 1998 10:13:47 +0200 (MET DST) Received: (qmail 960 invoked by uid 115); 22 Oct 1998 21:40:42 -0000 To: scwm-discuss@mit.edu Subject: Re: X Text Selection.... References: <11434.199810221407@penelope.ecs.soton.ac.uk> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 22 Oct 1998 23:40:39 +0200 In-Reply-To: Mark Toller's message of "Thu, 22 Oct 1998 23:14:26 +0100 (GMT)" Message-ID: Lines: 19 User-Agent: Gnus/5.070034 (Pterodactyl Gnus v0.34) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 22 Oct 1998 23:14:26 +0100 (GMT) >>>>> Mark Toller said: Mark> Hi, I was just playing about with the Mark> 'netscape-goto-cut-buffer-url' command, and noticed that it Mark> didn't have the current selection - this was selected in a Mark> netscape window - middle mouse button could paste it into an Mark> xterm etc... Could you please check what "xprop -root" reports in this case. You can omitt the RESOURCE_MANAGER property if it is longish. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Oct 26 18:15:27 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30433 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:15:27 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30430 for ; Mon, 26 Oct 1998 18:15:25 -0500 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Fri, 23 Oct 1998 12:06:15 +0100 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 14; Fri, 23 Oct 1998 12:05:48 GMT Date: Fri, 23 Oct 1998 12:05:47 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CE205.EEC7CBEE.14@hermes.dra.hmg.gb> Subject: Pager No longer crashes Scwm on exit Sender: owner-scwm-discuss@mit.edu Precedence: bulk The subject line says it all. I don't want to go into details, as they are deeply stupid, really, really very dumb indeed, (scope, Watson, scope). The hooks were not being removed, but the procedures would die. There may still be a problem that bad hooks show up some kind of weakness in scwm; I looked at callbacks.c but it was beyond me. Anyway you can start and stop the pager several times, and scwm carries on regardless. At present, there is only support for having one pager thing at a time, though it should be easy enough to support arbitrary combinations with a bit of hacking. Why would one want that? The gtk (non-gnome) version is a bit buggy still. Julian Satchell From owner-scwm-discuss@mit.edu Mon Oct 26 18:23:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30568 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:23:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30565 for ; Mon, 26 Oct 1998 18:23:02 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA12696; Sun, 25 Oct 98 05:37:24 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id MAA05926; Sun, 25 Oct 1998 12:35:09 +0200 To: Greg Harvey Cc: Maciej Stachowiak , sds@goems.com, scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Planned presentation at The Bazaar References: <199810220549.BAA20989@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 25 Oct 1998 12:35:09 +0200 Message-Id: Lines: 52 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Harvey writes: > The problem with cl is that the standardization wasn't based so much > on refining the features of the language, as making sure that most of > what already existed in lisp implementations would still exist in > future implementations. A lot of vendors had vested interest here, and > the direction was more one of avoiding breaking existing code, rather > than making cl as consistant (syntactically, at least) as possible. > > Scheme isn't really in the same boat, for a couple of > reasons: > > 1) Any code that's been written for more than one implementation has > basically stuck to the core constructs of the language. Anything > that targetted stuff not in the core were mostly being written for > one implementation > > 2) Less money involved, and therefore a less determined push for one > feature or another (ignoring egos ;). I can think of a couple of > lisp/cl vendors, but no scheme vendors come to mind. Scheme's been > more of an academic language until now, which could actually give > it great advantages when it comes to moving into the 'real world' Firstly, Chez scheme is a commercial scheme. There are others, but I can't think of their names right now. In any case, this is exactly why I think there will be some form of standardization of a larger scheme. It seems to me that scheme is about where lisp was before the Common Lisp standard. There are many implementations, each providing a more complete language in similar but incompatible ways. However, although there doesn't seem to be much money at stake (no big AI contracts, smaller & fewer commercial implementations), there are advantages: 1. R5RS as a core standard. Lisp didn't have a any pre-CL standards, and some lisps were *very* different from others, making developing the CL standard a difficult task. Scheme implementations aren't so different from each other (on the user side) because they all try to be R5RS. 2. The different scheme implementors are interested in a larger standard and are working amongst themselves towards developing consistent libraries. 3. SLIB exists. 4. CL & ANSI CL as prior art/useful ideas & idioms. 5. Lots of prior art wrt foreign fcn interfaces, network interfaces, regexp interfaces, ... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Oct 26 18:26:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30627 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:26:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30624 for ; Mon, 26 Oct 1998 18:26:21 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA16205; Mon, 26 Oct 98 18:26:14 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id SAA05707 for ; Mon, 26 Oct 1998 18:26:11 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: configuration utility References: <009CE15F.9112DC7E.157@hermes.dra.hmg.gb> Date: 26 Oct 1998 18:26:04 -0500 Message-Id: <5l7lxmucqb.fsf@tequila.cs.yale.edu> Lines: 11 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 26 Oct 1998 18:26:04 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Robbe" == Robert Bihlmeyer writes: > Upon saving: > (if the .scwmrc file contains begin and end markers) > (replace anything between the markers with the new settings) > (add the settings surrounded by begin and end markers to the end of > the .scwmrc) And provide the option (as emacs' customize does) to use an alternate file. Stefan From owner-scwm-discuss@mit.edu Mon Oct 26 18:37:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30785 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:37:33 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30782 for ; Mon, 26 Oct 1998 18:37:32 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA14759; Sat, 24 Oct 98 23:17:55 EDT Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id UAA09021; Sat, 24 Oct 1998 20:17:51 -0700 (PDT) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: animated window shading References: <199810240446.AAA01504@huis-clos.mit.edu> From: Greg Badros Date: 24 Oct 1998 19:17:50 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 24 Oct 1998 00:46:07 EDT" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I noticed while experimenting with animated window shading that you > can aminatedly shade or unshade a window that is already in that state > and it will instantaneously switch states and then roll back to the > right one. Is this intentional? It looks a bit entertaining but I > can't see it being useful. Not intentional by me. Probably should short-circuit out if state is already satisfied. We'd still be able to get the current behaviour by non-animatedly changing the state and then animating to the former state. (Perhaps it's a useful way to call attention to a window? Entertainment-value alone is a reason to be sure we don't lose the behaviour! :-) ) Greg From owner-scwm-discuss@mit.edu Mon Oct 26 18:43:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30876 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:43:16 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30873 for ; Mon, 26 Oct 1998 18:43:15 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA29244; Mon, 26 Oct 98 18:43:00 EST Received: (qmail 11061 invoked by uid 501); 26 Oct 1998 23:43:03 -0000 Message-Id: <19981026154303.A10687@molehill.org> Date: Mon, 26 Oct 1998 15:43:03 -0800 From: Todd Larason , Todd Larason To: scwm-discuss list Subject: Re: A wonderful set of books on X11 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: " I do NOT have a multiple personality disorder", said Tom, trying to be frank. X-Tom-Swifty: "I hate sweet potatoes", Tom yammered. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981023, Maciej Stachowiak wrote: > I just discovered a wonderful set of books on X11, the ones from > "Digital Press". Their documentation of X extensions in particular is > really good - I finally know what the difference between the bounding > shape and the clipping shape in the XShape extension. If these are the ones I think they are (by Robert W. Scheifler and James Gettys) they are very good books, but most (all?) of the content seems to be in the X distribution. Not always in a convenient format, though - I think the XSHAPE documentation is in FrameMaker format. From owner-scwm-discuss@mit.edu Mon Oct 26 18:47:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30967 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:47:39 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30963 for ; Mon, 26 Oct 1998 18:47:38 -0500 Received: from huey.cadvision.com by MIT.EDU with SMTP id AA16657; Sat, 24 Oct 98 01:10:09 EDT Received: from default (h-207-228-65-147.dial.cadvision.com [207.228.65.147]) by huey.cadvision.com (8.8.8/8.8.8/CW) with SMTP id XAA875170; Fri, 23 Oct 1998 23:08:39 -0600 Message-Id: <001601bdff0c$7c6ab3e0$9341e4cf@default> From: "Wade Humeniuk" To: "Maciej Stachowiak" , "Greg Harvey" Cc: , , Subject: Re: Planned presentation at The Bazaar Date: Fri, 23 Oct 1998 23:08:09 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >It should also be noted that the existance of a group of standardized >features in scheme would make it quite trivial to implement a cl >compatable module, so that everyone's tastes can be catered to. I have >a few modules laying around that provide some cl style things, like Or implement scheme in CL. They are essentially the same language. A Scheme that implements CL would not be small anymore, but would be CL. Wade From owner-scwm-discuss@mit.edu Mon Oct 26 18:47:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA30971 for scwm-discuss-outgoing; Mon, 26 Oct 1998 18:47:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA30968 for ; Mon, 26 Oct 1998 18:47:39 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA29705; Fri, 23 Oct 98 22:26:45 EDT Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA23900; Fri, 23 Oct 1998 22:26:39 -0400 Message-Id: <199810240226.WAA23900@huis-clos.mit.edu> To: Todd Larason To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: A wonderful set of books on X11 In-Reply-To: Your message of "Fri, 23 Oct 1998 16:42:04 PDT." <19981023164204.A30741@molehill.org> Date: Fri, 23 Oct 1998 22:26:39 EDT From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981023, Maciej Stachowiak wrote: > > I just discovered a wonderful set of books on X11, the ones from > > "Digital Press". Their documentation of X extensions in particular is > > really good - I finally know what the difference between the bounding > > shape and the clipping shape in the XShape extension. > > If these are the ones I think they are (by Robert W. Scheifler and James > Gettys) they are very good books, but most (all?) of the content seems to > be in the X distribution. Not always in a convenient format, though - I > think the XSHAPE documentation is in FrameMaker format. > Some of it looked like it was probably straight out of the specs, but I've never seen some of those documents before, and some only in PostScript format, which is less useful to me than a book (any non-searchable online format that you can't cut and paste from is just a paper format that you need to print yourlself). - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 19:08:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA31234 for scwm-discuss-outgoing; Mon, 26 Oct 1998 19:08:33 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA31231 for ; Mon, 26 Oct 1998 19:08:32 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA04907; Mon, 26 Oct 98 19:08:17 EST Received: (qmail 11255 invoked by uid 501); 27 Oct 1998 00:08:09 -0000 Message-Id: <19981026160808.B10687@molehill.org> Date: Mon, 26 Oct 1998 16:08:08 -0800 From: Todd Larason To: "merry::satchell"@hermes.dra.hmg.gb, scwm-discuss@mit.edu Subject: Re: Pager No longer crashes Scwm on exit References: <009CE205.EEC7CBEE.14@hermes.dra.hmg.gb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <009CE205.EEC7CBEE.14@hermes.dra.hmg.gb>; from "merry::satchell"@hermes.dra.hmg.gb on Fri, Oct 23, 1998 at 12:05:47PM +0000 X-Tom-Swifty: "Hey, like, sailing the seven seas is really far out, man", said Tom hypnotically. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981023, "merry::satchell"@hermes.dra.hmg.gb wrote: > There may still be > a problem that bad hooks show up some kind of weakness in scwm; > I looked at callbacks.c but it was beyond me. Could you try this again with guile 1.3? There were known problems in 1.2 and snapshots up to about 3 weeks ago. I've probably just missed an announcement, but is this available anywhere yet? I'd love to give it a try - I got most of gnome compiled again over the weekend. From owner-scwm-discuss@mit.edu Mon Oct 26 20:04:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31724 for scwm-discuss-outgoing; Mon, 26 Oct 1998 20:04:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31713; Mon, 26 Oct 1998 20:03:58 -0500 Message-Id: <199810270103.UAA31713@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Pager No longer crashes Scwm on exit In-reply-to: Your message of "Mon, 26 Oct 1998 16:08:08 PST." <19981026160808.B10687@molehill.org> Date: Mon, 26 Oct 1998 20:03:58 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981023, "merry::satchell"@hermes.dra.hmg.gb wrote: > > There may still be > > a problem that bad hooks show up some kind of weakness in scwm; > > I looked at callbacks.c but it was beyond me. > > Could you try this again with guile 1.3? There were known problems in > 1.2 and snapshots up to about 3 weeks ago. > > > I've probably just missed an announcement, but is this available > anywhere yet? I'd love to give it a try - I got most of gnome compiled > again over the weekend. Yes, guile-1.3.tar.gz is on ftp.gnu.org and so on. I saw the announcement several places, but I don't think I saw it in comp.os.linux.announce, that is a good place for announcing free software packages. - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 20:09:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31839 for scwm-discuss-outgoing; Mon, 26 Oct 1998 20:09:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA31836 for ; Mon, 26 Oct 1998 20:09:21 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA18297; Mon, 26 Oct 98 20:09:05 EST Received: (qmail 11680 invoked by uid 501); 27 Oct 1998 01:09:07 -0000 Message-Id: <19981026170906.A11655@molehill.org> Date: Mon, 26 Oct 1998 17:09:06 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Pager No longer crashes Scwm on exit References: <19981026160808.B10687@molehill.org> <199810270103.UAA31713@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810270103.UAA31713@huis-clos.mit.edu>; from Maciej Stachowiak on Mon, Oct 26, 1998 at 08:03:58PM -0500 X-Tom-Swifty: "Look at me, ma! I'm on top of the world -- well, chimney, anyway", said Tom superfluously. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981026, Maciej Stachowiak wrote: > > Could you try this again with guile 1.3? There were known problems in > > 1.2 and snapshots up to about 3 weeks ago. > > > > > > I've probably just missed an announcement, but is this available > > anywhere yet? I'd love to give it a try - I got most of gnome compiled > > again over the weekend. > > Yes, guile-1.3.tar.gz is on ftp.gnu.org and so on. Erk...I wasn't very clear, was I? I meant the gtk/gnome scwm pager. I've been using guile 1.3 since the day it was released. (no problems so far, knock on wood) From owner-scwm-discuss@mit.edu Mon Oct 26 20:48:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA32211 for scwm-discuss-outgoing; Mon, 26 Oct 1998 20:48:16 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA32207; Mon, 26 Oct 1998 20:48:15 -0500 Message-Id: <199810270148.UAA32207@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Random X11 question Date: Mon, 26 Oct 1998 20:48:15 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk How do you set the root window back to the default UglyWeave(tm) pattern? I'd like to make the background module capable of setting the default X pattern so it can undo what it does. (I'm also writing a higher-level wrapper on top of it to allow setting a different background per desk or animations of the background). - Maciej From owner-scwm-discuss@mit.edu Mon Oct 26 21:02:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA32357 for scwm-discuss-outgoing; Mon, 26 Oct 1998 21:02:57 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA32354 for ; Mon, 26 Oct 1998 21:02:56 -0500 Received: from quasar.newtonlabs.com by MIT.EDU with SMTP id AA29766; Mon, 26 Oct 98 21:02:39 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id SAA29598; Mon, 26 Oct 1998 18:02:40 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id SAA00989; Mon, 26 Oct 1998 18:02:38 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question References: <199810270148.UAA32207@huis-clos.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 26 Oct 1998 18:02:38 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 26 Oct 1998 20:48:15 EST" Message-Id: Lines: 21 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > How do you set the root window back to the default UglyWeave(tm) > pattern? I'd like to make the background module capable of setting the > default X pattern so it can undo what it does. On my box, you can do: xsetroot -bitmap /usr/X11R6/include/bitmaps/root_weave root_weave is small, so I'll include a copy here: -------------------- cut here -------------------- #define root_weave_width 4 #define root_weave_height 4 static unsigned char root_weave_bits[] = { 0x07, 0x0d, 0x0b, 0x0e}; -------------------- cut here -------------------- Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Tue Oct 27 00:17:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01059 for scwm-discuss-outgoing; Tue, 27 Oct 1998 00:17:42 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA01056 for ; Tue, 27 Oct 1998 00:17:36 -0500 Received: from jason02.u.washington.edu by MIT.EDU with SMTP id AA02065; Tue, 27 Oct 98 00:17:25 EST Received: from dante42.u.washington.edu (bobrink@dante42.u.washington.edu [140.142.15.202]) by jason02.u.washington.edu (8.8.4+UW97.07/8.8.4+UW98.06) with ESMTP id VAA36634; Mon, 26 Oct 1998 21:17:21 -0800 Received: from localhost (bobrink@localhost) by dante42.u.washington.edu (8.8.4+UW97.07/8.8.4+UW98.06) with ESMTP id VAA40980; Mon, 26 Oct 1998 21:17:20 -0800 Date: Mon, 26 Oct 1998 21:17:20 -0800 (PST) From: "'Bo' William Brinkman" To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question In-Reply-To: <199810270148.UAA32207@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On my box, just typing "xsetroot" with no params sets the root back to the default. -- "Pinky, are you pondering what I'm pondering?" "I think so Brain, but if you change the 'P' to an 'O', my name would be 'Oinky'!" -- William "Bo" Brinkman II http://weber.u.washington.edu/~bobrink bobrink@u.washington.edu On Mon, 26 Oct 1998, Maciej Stachowiak wrote: > > How do you set the root window back to the default UglyWeave(tm) > pattern? I'd like to make the background module capable of setting the > default X pattern so it can undo what it does. > > (I'm also writing a higher-level wrapper on top of it to allow setting > a different background per desk or animations of the background). > > - Maciej > > From owner-scwm-discuss@mit.edu Tue Oct 27 00:24:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01224 for scwm-discuss-outgoing; Tue, 27 Oct 1998 00:24:42 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01218; Tue, 27 Oct 1998 00:24:36 -0500 Message-Id: <199810270524.AAA01218@huis-clos.mit.edu> To: "'Bo' William Brinkman" cc: scwm-discuss@mit.edu Subject: Re: Random X11 question In-reply-to: Your message of "Mon, 26 Oct 1998 21:17:20 PST." Date: Tue, 27 Oct 1998 00:24:36 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk bobrink@u.washington.edu writes: > On my box, just typing "xsetroot" with no params sets the root back to the > default. > I was trying to find a way that does not involve calling an external program. I guess I should look at the source to xsetroot. I was hoping there was a way to set the background of a window to a stipple rather than a color or pixmap and a way to get the default root stipple with a simple X call, but maybe it is more involved than that. Yes, the background module _could_ be replaced with calls to xsetroot, but the C loadable module version will be considerably faster both by saving a fork and exec and being able to preload the images. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 27 00:44:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01412 for scwm-discuss-outgoing; Tue, 27 Oct 1998 00:44:23 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA01409 for ; Tue, 27 Oct 1998 00:44:21 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA05835; Tue, 27 Oct 98 00:44:10 EST Received: (qmail 13912 invoked by uid 501); 27 Oct 1998 05:44:08 -0000 Message-Id: <19981026214407.A13839@molehill.org> Date: Mon, 26 Oct 1998 21:44:07 -0800 From: Todd Larason To: Maciej Stachowiak , "'Bo' William Brinkman" Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question References: <199810270524.AAA01218@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810270524.AAA01218@huis-clos.mit.edu>; from Maciej Stachowiak on Tue, Oct 27, 1998 at 12:24:36AM -0500 X-Tom-Swifty: "I'm on welfare", said Tom dolefully. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981027, Maciej Stachowiak wrote: > > I guess I should look at the source to xsetroot. from xc/programs/xsetroot/: /* Handle restore defaults */ if (restore_defaults) { if (!cursor_file) XUndefineCursor(dpy, root); if (!excl) { XSetWindowBackgroundPixmap(dpy, root, (Pixmap) None); XClearWindow(dpy, root); unsave_past = 1; } } Are you aware of the _XSETROOT_ID (set by xsetroot, xpmroot and xloadimage, at least) and _XROOTPMAP_ID and _XROOTCOLOR_PIXEL (set by Enlightenment and Esetroot) root window properties? 'twould have been nice if Raster had known about _XSETROOT_ID. Wonder if it's too late to get the E guys to use it? From owner-scwm-discuss@mit.edu Tue Oct 27 01:22:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA03680 for scwm-discuss-outgoing; Tue, 27 Oct 1998 01:22:04 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA03675 for ; Tue, 27 Oct 1998 01:22:02 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA10340; Tue, 27 Oct 98 01:21:52 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA03663; Tue, 27 Oct 1998 01:21:56 -0500 Message-Id: <199810270621.BAA03663@huis-clos.mit.edu> To: Todd Larason Cc: "'Bo' William Brinkman" Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question In-Reply-To: Your message of "Mon, 26 Oct 1998 21:44:07 PST." <19981026214407.A13839@molehill.org> Date: Tue, 27 Oct 1998 01:21:56 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981027, Maciej Stachowiak wrote: > > > > I guess I should look at the source to xsetroot. > > from xc/programs/xsetroot/: > /* Handle restore defaults */ > if (restore_defaults) { > if (!cursor_file) > XUndefineCursor(dpy, root); > if (!excl) { > XSetWindowBackgroundPixmap(dpy, root, (Pixmap) None); > XClearWindow(dpy, root); > unsave_past = 1; > } > } > > > Are you aware of the _XSETROOT_ID (set by xsetroot, xpmroot and xloadimage, > at least) and _XROOTPMAP_ID and _XROOTCOLOR_PIXEL (set by Enlightenment > and Esetroot) root window properties? No I'm not, do tell. > 'twould have been nice if Raster had known about _XSETROOT_ID. > Wonder if it's too late to get the E guys to use it? I'm sure you could suggest it to them - I have heard from some other people that they can be less than friendly to suggestions or offers off help (this is what scared me off from trying to do scwm as an E fork/extension instead a fvwm2 fork), but they have also been known to take kindly to following known protocols. - Maciej From owner-scwm-discuss@mit.edu Tue Oct 27 02:08:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA04155 for scwm-discuss-outgoing; Tue, 27 Oct 1998 02:08:04 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA04152 for ; Tue, 27 Oct 1998 02:08:02 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA15237; Tue, 27 Oct 98 02:07:49 EST Received: (qmail 14572 invoked by uid 501); 27 Oct 1998 07:07:50 -0000 Message-Id: <19981026230749.A14328@molehill.org> Date: Mon, 26 Oct 1998 23:07:49 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question References: <19981026214407.A13839@molehill.org> <199810270621.BAA03663@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810270621.BAA03663@huis-clos.mit.edu>; from Maciej Stachowiak on Tue, Oct 27, 1998 at 01:21:56AM -0500 X-Tom-Swifty: "All these years prospecting, and all I have to show for it is the deed to this hole in the ground under my outhouse that otherwise ain't worth nuthin'", said Tom single mine diddly squat. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981027, Maciej Stachowiak wrote: > > Are you aware of the _XSETROOT_ID (set by xsetroot, xpmroot and xloadimage, > > at least) and _XROOTPMAP_ID and _XROOTCOLOR_PIXEL (set by Enlightenment > > and Esetroot) root window properties? > > No I'm not, do tell. In some cases, when xsetroot sets the background bitmap or color, it set the _XSETROOT_ID property on the root window (type XA_PIXMAP, format 32) to the new background pixmap. If it's setting the color, it creates a 1-pixel pixmap for this. I don't really understand the case - it's if ((ecolor.pixel != BlackPixel(dpy, screen)) && (ecolor.pixel != WhitePixel(dpy, screen)) && (DefaultVisual(dpy, screen)->class & Dynamic)) save_colors = 1; That code is in the color name->pixel conversion routine; any color setting can trigger it. xpmroot sets it every time, unconditionally. When setting it, the old value is XKillClient()ed. I don't know what it's *used* by. Eterm uses the E-specific verion (_XROOTPMAP_ID) for it's pseudo-transparent windows. From owner-scwm-discuss@mit.edu Tue Oct 27 08:12:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA06689 for scwm-discuss-outgoing; Tue, 27 Oct 1998 08:12:44 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA06686 for ; Tue, 27 Oct 1998 08:12:43 -0500 Received: from kurims.kurims.kyoto-u.ac.jp by MIT.EDU with SMTP id AA24102; Tue, 27 Oct 98 08:12:22 EST Received: from boron.kurims.kyoto-u.ac.jp (boron.kurims.kyoto-u.ac.jp [130.54.16.65]) by kurims.kurims.kyoto-u.ac.jp (8.9.1a/3.6W) with ESMTP id WAA22813 for ; Tue, 27 Oct 1998 22:12:24 +0900 (JST) Received: (from petersen@localhost) by boron.kurims.kyoto-u.ac.jp (8.8.8+Sun/3.5Wbeta) id WAA13280; Tue, 27 Oct 1998 22:12:24 +0900 (JST) To: scwm-discuss@mit.edu Subject: Re: language debate [was: Planned presentation at The Bazaar] References: <199810211621.MAA14248@huis-clos.mit.edu> X-Face: 64N,SZ}bM~X-HZK0w(B)t]7rZ}7_bNq^}A%e7_;~lN3nVJ,50%>pW7y^=\sy2w"7?cu}g@t #JRW\4kvSY8i%OMorx`_I]/5+~db.s\H!)|YE.y#-sFk#]iYRU/w+({~_l-c1uS)s%;72$Nmv>U)ZeyLBdF#c-i.ECMy9>twG+9Ln$ Date: 27 Oct 1998 22:12:23 +0900 In-Reply-To: Sam Steingold's message of "21 Oct 1998 15:23:24 -0400" Message-Id: Lines: 35 User-Agent: Gnus/5.070036 (Pterodactyl Gnus v0.36) XEmacs/21.0 (Poitou) Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Sam" == Sam Steingold writes: Sam> ... to its logical end. (http://www.goems.com/~sds/tool.html) I agree with you that C is basically sugared assembly language (and object oriented assembler doesn't make sense ;-). I have been a long time admirer of Scheme (and Lisp), over the last year I have come to the conclusion that the right way to go is strongly typed (polymorphic) functional programming languages (such as ML (with strict evaluation) (eg SML or Objective CAML ) or with lazy evaluation like Haskell ). Having a powerful static type system is really essential for preventing runtime errors (which will always haunt Lisp/Scheme programs) and weeds out most errors already at compile time. Sam> It is time to make the next step: from using an "extension" Sam> language (like quile) to extend applications to full-fledged Sam> powerful general-purpose language with a good library (I hint Sam> in the direction of ANSI Common Lisp here, but I would settle Sam> for any similarly powerful language). With shared libraries, Sam> it doesn't matter whether your applications are extended with Sam> a 1MB libguile or 2MB libclisp, but it will matter for the Sam> users whether they will have to reinvent hash tables, Sam> structures and arrays. Indeed if the base language is high level and allows extensibility of applications in its only language then that is all one needs. Now we just need to rewrite the whole GNU system in a modern language.... (allowing us to have dynamic shared libraries for our high level language). -- Jens-Ulrik Holger Petersen Research Institute for Mathematical Sciences, Kyoto University From owner-scwm-discuss@mit.edu Tue Oct 27 20:58:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA11477 for scwm-discuss-outgoing; Tue, 27 Oct 1998 20:58:48 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA11474 for ; Tue, 27 Oct 1998 20:58:41 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24749; Tue, 27 Oct 98 20:58:20 EST Received: (qmail 29128 invoked by uid 501); 28 Oct 1998 01:58:14 -0000 Message-Id: <19981027175812.A29058@molehill.org> Date: Tue, 27 Oct 1998 17:58:12 -0800 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: dynamic loading and libtool breaks c++ scwm builds References: <19981007173344.A2242@molehill.org> <19981007191306.A2906@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Thu, Oct 08, 1998 at 08:34:48AM -0700 X-Tom-Swifty: "Use your own hair brush", Tom bristled. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981008, Greg Badros wrote: > Changing libtool's global_symbol_pipe variable to include: > > grep -v rtti | > > before the sed command makes the link go through for me. I'm not sure > what the "right" excluded symbols should be. My guess is it should > either just exclude the one symbol that causes problems, or should > exclude all the C++ symbols. I haven't managed to get a response from either of the new libtool maintainers about this yet, but I have a possible solution. During the interim when there was no official libtool maintainer, Thomas Tanner released an unofficial 1.2c version, with a new -export-symbols switch that can replace -export-dynamic; instead of exporting every symbol found, it exports only those symbols listed in a named file. Tanner has been invited to submit his patch to fold into a future official release of libtool; I assume he'll accept, but he hasn't yet. Cons: o Unless/until this is in an official release, we'd be relying on an unofficial version of libtool. o We'd have to list all the symbols we want exported to dynamically loaded modules (and presumably any C++-containing modules would have to list all the symbols they want exported to main and to other modules) Pros: o It fixes the problem in a relatively clean way o It lets us have more control over what symbols are exported. From owner-scwm-discuss@mit.edu Wed Oct 28 01:49:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA16045 for scwm-discuss-outgoing; Wed, 28 Oct 1998 01:49:23 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA16041; Wed, 28 Oct 1998 01:49:21 -0500 Message-Id: <199810280649.BAA16041@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: cascade Date: Wed, 28 Oct 1998 01:49:21 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just added a cascade.scm module which cascades windows like FvwmCascade, only it's more flexible requires less code, to my branch (appointment with the lawyer tomorrow). I'm gonna do a tile module too. These are basically like the windows "cascade" and "tile" oprations, but obviously much more flexible. I was thinking it would be really darn cool if you could do animated cascades and tiles, and actually see the windows move and possible resize on your screen. Not only would it look really darn cool, it would let you know where your windows came from. I think we need to add an animated-resize just to make this fully functional. If it were possible to undo the cascade or tile, that would be really great too, especially if it were also animated. Shouldn't be too hard to add. Excuse me, I'm having one of those weepy "scwm is so cool" moments right now. Oh yeah, I also moved all the animation stuff to a module, it worked flawlessly. Expect to see base memory footprint fall in the near to mid term future as various features move to loadable modules (mucho thanks to Todd for setting up the infrastructure). - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 11:58:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32736 for scwm-discuss-outgoing; Wed, 28 Oct 1998 11:58:57 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32732; Wed, 28 Oct 1998 11:58:57 -0500 Message-Id: <199810281658.LAA32732@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: New cvsweb Date: Wed, 28 Oct 1998 11:58:57 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I put a new version of the cvsweb repository browser for the scwm source up at http://huis-clos.mit.edu/cgi-bin/cvsweb.new. This version is really slick! - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 12:27:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA00217 for scwm-discuss-outgoing; Wed, 28 Oct 1998 12:27:07 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA00213 for ; Wed, 28 Oct 1998 12:27:06 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA24155; Wed, 28 Oct 98 12:27:09 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id MAA06803 for ; Wed, 28 Oct 1998 12:27:04 -0500 (EST) Received: from yodel.cs.cornell.edu (YODEL.CS.CORNELL.EDU [128.84.218.84]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id MAA02479 for ; Wed, 28 Oct 1998 12:27:02 -0500 (EST) Received: (from eli@localhost) by yodel.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id MAA13821; Wed, 28 Oct 1998 12:27:00 -0500 (EST) X-Authentication-Warning: yodel.cs.cornell.edu: eli set sender to eli@yodel.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13879.21475.703769.603153@yodel.cs.cornell.edu> Date: Wed, 28 Oct 1998 12:26:59 -0500 (EST) To: scwm-discuss@mit.edu Subject: anoncvs X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk There's a problem (since yesterday) that prevents getting the directory using cvs - cvs server: [17:25:01] waiting for uid6159's lock in /anoncvs/scwm/scheme -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Wed Oct 28 12:38:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA00363 for scwm-discuss-outgoing; Wed, 28 Oct 1998 12:38:43 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA00355; Wed, 28 Oct 1998 12:38:41 -0500 Message-Id: <199810281738.MAA00355@huis-clos.mit.edu> To: Eli Barzilay cc: scwm-discuss@mit.edu Subject: Re: anoncvs In-reply-to: Your message of "Wed, 28 Oct 1998 12:26:59 EST." <13879.21475.703769.603153@yodel.cs.cornell.edu> Date: Wed, 28 Oct 1998 12:38:41 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk eli@cs.cornell.edu writes: > There's a problem (since yesterday) that prevents getting the directory using > cvs - > cvs server: [17:25:01] waiting for uid6159's lock in /anoncvs/scwm/scheme Hmm, it seems the rsync process that mirrors the master repository to the anoncvs repository accidentally mirrored a CVS lock file. I removed this. I am not sure what the best way to deal with the problem in general is. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 12:49:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA00553 for scwm-discuss-outgoing; Wed, 28 Oct 1998 12:49:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA00550 for ; Wed, 28 Oct 1998 12:49:18 -0500 Received: from tis.bellhow.com by MIT.EDU with SMTP id AA20312; Wed, 28 Oct 98 12:49:12 EST Received: by tis.bellhow.com; id MAA21299; Wed, 28 Oct 1998 12:49:14 -0500 (EST) Received: from mailhost.bellhow.com(198.30.176.2) by tis.bellhow.com via smap (4.1) id xma021192; Wed, 28 Oct 98 12:48:28 -0500 Received: from pcw3089.systems.bellhow.com (pcw3089.systems.bellhow.com [192.168.33.217]) by mailhost.bellhow.com (8.8.8/8.8.8) with SMTP id MAA01004 for ; Wed, 28 Oct 1998 12:48:28 -0500 (EST) From: smithd@bellhow.com (Dale Smith) To: scwm-discuss@mit.edu Subject: Re: New cvsweb Date: Wed, 28 Oct 1998 17:48:28 GMT Organization: Bell & Howell PSC Reply-To: dale.smith@bellhow.com Message-Id: <363958bb.92782974@smtp> References: <199810281658.LAA32732@huis-clos.mit.edu> In-Reply-To: <199810281658.LAA32732@huis-clos.mit.edu> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id MAA00551 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, 28 Oct 1998 11:58:57 EST, you wrote: > >I put a new version of the cvsweb repository browser for the scwm >source up at http://huis-clos.mit.edu/cgi-bin/cvsweb.new. This version >is really slick! Yes it is! We use this around here at Bell & Howell and it's great. Dale From owner-scwm-discuss@mit.edu Wed Oct 28 12:59:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA00698 for scwm-discuss-outgoing; Wed, 28 Oct 1998 12:59:24 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA00695 for ; Wed, 28 Oct 1998 12:59:23 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA05681; Wed, 28 Oct 98 12:59:26 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA18805; Wed, 28 Oct 1998 12:59:19 -0500 (EST) Message-Id: <199810281759.MAA18805@jekyll.piermont.com> To: Maciej Stachowiak Cc: Eli Barzilay , scwm-discuss@mit.edu Subject: Re: anoncvs In-Reply-To: Your message of "Wed, 28 Oct 1998 12:38:41 EST." <199810281738.MAA00355@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Oct 1998 12:59:19 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > eli@cs.cornell.edu writes: > > There's a problem (since yesterday) that prevents getting the directory usi ng > > cvs - > > cvs server: [17:25:01] waiting for uid6159's lock in /anoncvs/scwm/scheme > > > Hmm, it seems the rsync process that mirrors the master repository to > the anoncvs repository accidentally mirrored a CVS lock file. I > removed this. I am not sure what the best way to deal with the problem > in general is. rsync lets you specify files not to be mirrored. .pm From owner-scwm-discuss@mit.edu Wed Oct 28 13:00:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00757 for scwm-discuss-outgoing; Wed, 28 Oct 1998 13:00:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00750; Wed, 28 Oct 1998 13:00:48 -0500 Message-Id: <199810281800.NAA00750@huis-clos.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: anoncvs In-reply-to: Your message of "Wed, 28 Oct 1998 12:59:19 EST." <199810281759.MAA18805@jekyll.piermont.com> Date: Wed, 28 Oct 1998 13:00:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > eli@cs.cornell.edu writes: > > > There's a problem (since yesterday) that prevents getting the directory usi > ng > > > cvs - > > > cvs server: [17:25:01] waiting for uid6159's lock in /anoncvs/scwm/scheme > > > > > > Hmm, it seems the rsync process that mirrors the master repository to > > the anoncvs repository accidentally mirrored a CVS lock file. I > > removed this. I am not sure what the best way to deal with the problem > > in general is. > > rsync lets you specify files not to be mirrored. > Well, that will avoid copying the lock file but not fix the more general issues of rsync happening in the middle of a commit. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 13:06:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00892 for scwm-discuss-outgoing; Wed, 28 Oct 1998 13:06:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00889 for ; Wed, 28 Oct 1998 13:06:16 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA08038; Wed, 28 Oct 98 13:06:19 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA18881; Wed, 28 Oct 1998 13:06:13 -0500 (EST) Message-Id: <199810281806.NAA18881@jekyll.piermont.com> To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: anoncvs In-Reply-To: Your message of "Wed, 28 Oct 1998 13:00:48 EST." <199810281800.NAA00750@huis-clos.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Wed, 28 Oct 1998 13:06:13 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > rsync lets you specify files not to be mirrored. > > Well, that will avoid copying the lock file but not fix the more > general issues of rsync happening in the middle of a commit. you could lock the whole repository during rsync, or set up a post-commit script that did the sync-up for just that one file at a time (which would have the cool advantage of making the anoncvs repository completely mirror the real one). Perry From owner-scwm-discuss@mit.edu Wed Oct 28 13:21:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA01161 for scwm-discuss-outgoing; Wed, 28 Oct 1998 13:21:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA01158 for ; Wed, 28 Oct 1998 13:21:50 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA18278 for scwm-discuss@huis-clos.mit.edu; Wed, 28 Oct 1998 19:11:05 +0100 (MET) Received: (qmail 462 invoked by uid 115); 28 Oct 1998 14:01:14 -0000 To: scwm-discuss@mit.edu Subject: Re: Random X11 question References: <19981026214407.A13839@molehill.org> <199810270621.BAA03663@huis-clos.mit.edu> <19981026230749.A14328@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Oct 1998 15:01:10 +0100 In-Reply-To: Todd Larason's message of "Mon, 26 Oct 1998 23:07:49 -0800" Message-ID: Lines: 17 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 26 Oct 1998 23:07:49 -0800 >>>>> Todd Larason said: Todd> In some cases, when xsetroot sets the background bitmap or Todd> color, it set the _XSETROOT_ID property on the root window Todd> (type XA_PIXMAP, format 32) to the new background pixmap. It does this on PseudoColor visuals, but not on TrueColor ones. Dubious. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Oct 28 13:32:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA01302 for scwm-discuss-outgoing; Wed, 28 Oct 1998 13:32:26 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA01293; Wed, 28 Oct 1998 13:32:16 -0500 Message-Id: <199810281832.NAA01293@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: Random X11 question In-reply-to: Your message of "28 Oct 1998 15:01:10 +0100." Date: Wed, 28 Oct 1998 13:32:16 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Mon, 26 Oct 1998 23:07:49 -0800 > >>>>> Todd Larason said: > > Todd> In some cases, when xsetroot sets the background bitmap or > Todd> color, it set the _XSETROOT_ID property on the root window > Todd> (type XA_PIXMAP, format 32) to the new background pixmap. > > It does this on PseudoColor visuals, but not on TrueColor ones. > Dubious. > Maybe part of the purpose is to avoid possible colormap problems, then? - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 15:04:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02000 for scwm-discuss-outgoing; Wed, 28 Oct 1998 15:04:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01996 for ; Wed, 28 Oct 1998 15:04:48 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22375; Wed, 28 Oct 98 15:04:43 EST Received: (qmail 11434 invoked by uid 501); 28 Oct 1998 20:04:37 -0000 Message-Id: <19981028120436.B11390@molehill.org> Date: Wed, 28 Oct 1998 12:04:36 -0800 From: Todd Larason To: scwm-discuss list Subject: [sds@mtl.mit.edu: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I was in a riot in Paris", Tom noised abroad. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I responded to a checkin message from Sam Steingold, and evidentally (reasonably) annoyed this person. Can the commit messages somehow get valid email addresses into them? Or at least a reply-to to cut down on the problem? ----- Forwarded message from "Stephen D. Senturia" ----- Return-Path: Delivered-To: jtl@molehill.org Received: (qmail 9172 invoked from network); 28 Oct 1998 14:35:22 -0000 Received: from mtl.mit.edu (18.62.0.45) by molehill.involved.com with SMTP; 28 Oct 1998 14:35:22 -0000 Received: from mtl.mit.edu (LOTUS-ESPRIT.MIT.EDU [18.62.1.191]) by mtl.mit.edu (8.8.8/8.8.8) with ESMTP id JAA17943; Wed, 28 Oct 1998 09:34:52 -0500 (EST) Message-ID: <3636F51A.CC72A0F5@mtl.mit.edu> Date: Wed, 28 Oct 1998 10:42:36 +0000 From: "Stephen D. Senturia" Reply-To: sds@mtl.mit.edu Organization: MIT X-Mailer: Mozilla 4.05 (Macintosh; I; PPC) MIME-Version: 1.0 To: accounts@mit.edu CC: Sam Steingold , scwm-commits@mit.edu, jtl@molehill.org, "Senturia, Stephen" Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810272055.PAA09897@huis-clos.mit.edu> <19981027130253.B21294@molehill.org> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1475 Lines: 41 To MIT Accounts -- please get these people to stop using my logon ID. I have repeatedly asked Sam Steingold to eliminate his improper use of my logon ID, and while he has always said the right things, the use persists. Apparently he distributed this alias to others, and it is now his responsibility to backtrack and correct it. (see below) I wish to ask for your help in getting these folks to clean up their act. /sds -- ============================================================== Stephen D. Senturia,Weller Professor of Electrical Engineering Room 39-567, Massachusetts Institute of Technology Cambridge, MA, 02139 Phone 617-253-6869 sds@mtl.mit.edu FAX 617-253-9606 ============================================================== Here is a copy of the most recent offending e-mail. You will notice Sam Steingold incorrectly identified as sds@mit.edu: Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 Date: Tue, 27 Oct 1998 13:02:53 -0800 From: Todd Larason To: Sam Steingold , scwm-commits@MIT.EDU References: 1 On 981027, Sam Steingold wrote: > [scwm-*.txt have to be rebuilt with root scwm, not scwm/scwm!] Can you amplify on this a bit? Greg and I have been back and forth on this, and I thought we had it right. When I build the docs, I get filenames like "scheme/base.scm". Is this not what you get? ----- End forwarded message ----- From owner-scwm-discuss@mit.edu Wed Oct 28 16:19:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02659 for scwm-discuss-outgoing; Wed, 28 Oct 1998 16:19:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02656 for ; Wed, 28 Oct 1998 16:19:12 -0500 Received: from h-205-217-237-46.netscape.com by MIT.EDU with SMTP id AA08295; Wed, 28 Oct 98 16:18:56 EST Received: from puerco-del-diablo.netscape.com (puerco-del-diablo.mcom.com [205.217.246.163]) by netscape.com (8.8.5/8.8.5) with ESMTP id NAA03180; Wed, 28 Oct 1998 13:18:52 -0800 (PST) Received: (from friedman@localhost) by puerco-del-diablo.netscape.com (8.8.5/8.8.5) id NAA08479; Wed, 28 Oct 1998 13:18:52 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Noah Friedman To: jtl@molehill.org Cc: scwm-discuss@mit.edu Subject: [sds@mtl.mit.edu: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998] Reply-To: Noah Friedman In-Reply-To: Wed, 28 Oct 1998 12:04:36 -0800 References: <19981028120436.B11390@molehill.org> Date: Wed, 28 Oct 1998 13:18:51 -0800 (PST) Message-Id: <19981028131851.859641.FMU573@puerco-del-diablo.netscape.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk At mozilla.org, we have pserver accounts with fully-qualified email addresses as the usernames. So for instance, all my checkins are labeled as coming from `friedman%netscape.com' instead of just `friedman'. (We have to use `%' instead of `@' simply because the latter isn't allowed in the author field of an RCS file.) From owner-scwm-discuss@mit.edu Wed Oct 28 16:27:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02804 for scwm-discuss-outgoing; Wed, 28 Oct 1998 16:27:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02801 for ; Wed, 28 Oct 1998 16:27:33 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA11631; Wed, 28 Oct 98 16:27:25 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02792; Wed, 28 Oct 1998 16:27:26 -0500 Message-Id: <199810282127.QAA02792@huis-clos.mit.edu> To: Todd Larason Cc: scwm-discuss list Subject: Re: [sds@mtl.mit.edu: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998] In-Reply-To: Your message of "Wed, 28 Oct 1998 12:04:36 PST." <19981028120436.B11390@molehill.org> Date: Wed, 28 Oct 1998 16:27:26 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I responded to a checkin message from Sam Steingold, and evidentally > (reasonably) annoyed this person. Can the commit messages somehow get > valid email addresses into them? Or at least a reply-to to cut down on > the problem? > Sorry about that, I just added everyone with CVS accounts to /etc/localusers, if you all set up your .forward files right, everything should work smoothly now (this should be indicated by future commit messages showing the sender as being @huis-clos.mit.edu instead of @mit.edu. Sorry for being too lame to fix this before, I will apologize to the person who complained. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 16:35:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02981 for scwm-discuss-outgoing; Wed, 28 Oct 1998 16:35:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02978 for ; Wed, 28 Oct 1998 16:35:12 -0500 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA14282; Wed, 28 Oct 98 16:34:56 EST Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.238]) id QQfncg06358 for ; Wed, 28 Oct 1998 21:34:59 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id RAA00887; Wed, 28 Oct 1998 17:34:00 -0500 To: scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Wed, 28 Oct 1998 12:04:36 -0800" Date: 28 Oct 1998 17:34:00 -0500 Message-Id: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981028120436.B11390@molehill.org> >>>> On the subject of "[sds@mtl.mit.edu: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998]" >>>> Sent on Wed, 28 Oct 1998 12:04:36 -0800 >>>> Honorable Todd Larason writes: >> >> On 981027, Sam Steingold wrote: >> > [scwm-*.txt have to be rebuilt with root scwm, not scwm/scwm!] >> >> Can you amplify on this a bit? Greg and I have been back and forth on >> this, and I thought we had it right. When I build the docs, I get >> filenames like "scheme/base.scm". Is this not what you get? nope. these files - scwm-*.txt are not regenerated at build time, and the files I get from cvs are: $ head /usr/local/share/scwm/scwm-procedures.txt (%x x) - (app scwm base) Return the number of pixels that is X percent of the display width. [From ../scheme/base.scm:46] (%x- x) - (app scwm base) Return the pixel coordinate X percent of the width away from the right edge. [From ../scheme/base.scm:90] $ (I just did `make install`). therefore they should be either regenerated at build time or rebuilt once by someone who knows how to do this. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Don't use force -- get a bigger hammer. From owner-scwm-discuss@mit.edu Wed Oct 28 16:49:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03194 for scwm-discuss-outgoing; Wed, 28 Oct 1998 16:49:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA03191 for ; Wed, 28 Oct 1998 16:49:33 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA20647; Wed, 28 Oct 98 16:49:27 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA21600; Wed, 28 Oct 1998 13:49:30 -0800 (PST) To: scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> From: Greg Badros Date: 28 Oct 1998 13:49:30 -0800 In-Reply-To: Sam Steingold's message of "28 Oct 1998 17:34:00 -0500" Message-Id: Lines: 27 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <19981028120436.B11390@molehill.org> > >>>> On the subject of "[sds@mtl.mit.edu: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998]" > >>>> Sent on Wed, 28 Oct 1998 12:04:36 -0800 > >>>> Honorable Todd Larason writes: > >> > >> On 981027, Sam Steingold wrote: > >> > [scwm-*.txt have to be rebuilt with root scwm, not scwm/scwm!] > >> > >> Can you amplify on this a bit? Greg and I have been back and forth on > >> this, and I thought we had it right. When I build the docs, I get > >> filenames like "scheme/base.scm". Is this not what you get? > > nope. these files - scwm-*.txt are not regenerated at build time, and > the files I get from cvs are: > > $ head /usr/local/share/scwm/scwm-procedures.txt > therefore they should be either regenerated at build time or rebuilt > once by someone who knows how to do this. I'll regenerate and commit sometime today after updating. Greg From owner-scwm-discuss@mit.edu Wed Oct 28 17:07:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03761 for scwm-discuss-outgoing; Wed, 28 Oct 1998 17:07:33 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03758 for ; Wed, 28 Oct 1998 17:07:32 -0500 Received: from smtp0-alterdial.UU.NET by MIT.EDU with SMTP id AA09766; Wed, 28 Oct 98 17:07:34 EST Received: from eho.eaglets.com by smtp0-alterdial.uu.net with ESMTP (peer crosschecked as: [208.235.77.238]) id QQfnci11601; Wed, 28 Oct 1998 22:07:29 GMT Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id SAA01228; Wed, 28 Oct 1998 18:06:28 -0500 To: Greg Badros Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "28 Oct 1998 13:49:30 -0800" Date: 28 Oct 1998 18:06:27 -0500 Message-Id: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998" >>>> Sent on 28 Oct 1998 13:49:30 -0800 >>>> Honorable Greg Badros writes: >> Sam Steingold writes: >> >> > therefore they should be either regenerated at build time or rebuilt >> > once by someone who knows how to do this. >> >> I'll regenerate and commit sometime today after updating. Thanks! Actually, on a second thought, it would seem to be a good itea - to gegenerate these files on each build. What do you think? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Someone has changed your life. Save? (y/n) From owner-scwm-discuss@mit.edu Wed Oct 28 17:19:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03922 for scwm-discuss-outgoing; Wed, 28 Oct 1998 17:19:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03917 for ; Wed, 28 Oct 1998 17:19:33 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA14042; Wed, 28 Oct 98 17:19:35 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03911; Wed, 28 Oct 1998 17:19:31 -0500 Message-Id: <199810282219.RAA03911@huis-clos.mit.edu> To: sds@goems.com Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-Reply-To: Your message of "28 Oct 1998 18:06:27 EST." Date: Wed, 28 Oct 1998 17:19:31 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message > >>>> On the subject of "Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998" > >>>> Sent on 28 Oct 1998 13:49:30 -0800 > >>>> Honorable Greg Badros writes: > >> Sam Steingold writes: > >> > >> > therefore they should be either regenerated at build time or rebuilt > >> > once by someone who knows how to do this. > >> > >> I'll regenerate and commit sometime today after updating. > > Thanks! > > Actually, on a second thought, it would seem to be a good itea - to > gegenerate these files on each build. > > What do you think? > Personally, I think there should be a `make doc' Makefile rule at some point. I think the rules we have now might be too fragile to ship a Makefile with that rule, but I am not sure. - Maciej From owner-scwm-discuss@mit.edu Wed Oct 28 17:21:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03987 for scwm-discuss-outgoing; Wed, 28 Oct 1998 17:21:56 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA03984 for ; Wed, 28 Oct 1998 17:21:54 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA26670 for scwm-discuss@huis-clos.mit.edu; Wed, 28 Oct 1998 23:20:59 +0100 (MET) Received: (qmail 1291 invoked by uid 115); 28 Oct 1998 18:33:45 -0000 To: scwm-discuss@mit.edu Subject: Re: anoncvs References: <199810281800.NAA00750@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 28 Oct 1998 19:33:44 +0100 In-Reply-To: Maciej Stachowiak's message of "Wed, 28 Oct 1998 13:00:48 EST" Message-ID: Lines: 16 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) X-Now-Playing: Tangerine Dream - Die Sonne =?ISO-8859-1?Q?verd=FCstert?= sich =?ISO-8859-1?Q?allm=E4hlich?= Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 28 Oct 1998 13:00:48 EST >>>>> Maciej Stachowiak said: Maciej> Well, that will avoid copying the lock file but not fix the Maciej> more general issues of rsync happening in the middle of a Maciej> commit. rsync repeatedly every minute until the lock file vanishes? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Oct 28 17:26:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04049 for scwm-discuss-outgoing; Wed, 28 Oct 1998 17:26:43 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA04046 for ; Wed, 28 Oct 1998 17:26:42 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA04964; Wed, 28 Oct 98 17:26:36 EST Received: (qmail 12362 invoked by uid 501); 28 Oct 1998 22:26:38 -0000 Message-Id: <19981028142637.A12307@molehill.org> Date: Wed, 28 Oct 1998 14:26:37 -0800 From: Todd Larason To: sds@goems.com, Greg Badros Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Sam Steingold on Wed, Oct 28, 1998 at 06:06:27PM -0500 X-Tom-Swifty: "Now no-one can detect my halitosis", said Tom breathlessly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981028, Sam Steingold wrote: > Actually, on a second thought, it would seem to be a good itea - to > gegenerate these files on each build. It requires perl, takes a while, and there's no dependancy checking there now (and the way it works now, if there were, it would be dependant on ***/*.{c,scm}). There's a guile version of the extractor; has it kept up with everything the perl version does? That takes care of #1, but it's even slower. On my todo list, I've had an item to split out the source-scanning part from the final building part, with an intermediate *.doc file for each *.c (and *.scm file?), generated as part of the COMPILE rule. This would be somewhat slower for initial builds, but would be faster for incremental, and would encourage us to see any doc errors as soon as we make changes. The final sgml/scwm-*.txt would be dependant on the *.doc files. Anyone wanna take a crack at thsi before I get to it, or think it's a bad idea? From owner-scwm-discuss@mit.edu Wed Oct 28 17:53:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04474 for scwm-discuss-outgoing; Wed, 28 Oct 1998 17:53:56 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA04471 for ; Wed, 28 Oct 1998 17:53:55 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA25199; Wed, 28 Oct 98 17:53:58 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA21701; Wed, 28 Oct 1998 14:53:47 -0800 (PST) To: Todd Larason Cc: sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> From: Greg Badros Date: 28 Oct 1998 14:53:47 -0800 In-Reply-To: Todd Larason's message of "Wed, 28 Oct 1998 14:26:37 -0800" Message-Id: Lines: 43 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981028, Sam Steingold wrote: > > Actually, on a second thought, it would seem to be a good itea - to > > gegenerate these files on each build. > > It requires perl, takes a while, and there's no dependancy checking there now > (and the way it works now, if there were, it would be dependant on > ***/*.{c,scm}). Yea, I agree that I'd rather not bother w/ auto-generating the doc files w/ each build. > There's a guile version of the extractor; has it kept up with everything > the perl version does? That takes care of #1, but it's even slower. No, it's not up to date w/ the perl version. It wouldn't be too bad to update it probably, but Harvey stopped maintaining it after proof-of-concept and some optimization (since it doesn't make sense to maintain both, and I was enhancing the perl version -- I find perl a lot more natural for text processing tasks than guile, and am already knowledgeable about how to use the relevant libraries). > On my todo list, I've had an item to split out the source-scanning part > from the final building part, with an intermediate *.doc file for each > *.c (and *.scm file?), generated as part of the COMPILE rule. This would > be somewhat slower for initial builds, but would be faster for incremental, > and would encourage us to see any doc errors as soon as we make changes. > The final sgml/scwm-*.txt would be dependant on the *.doc files. > > Anyone wanna take a crack at thsi before I get to it, or think it's a > bad idea? Seems like a good idea to me, though I'm not exactly sure what you're planning on doing to combine the *.doc files and to create the scwm.sgml file... It only takes 7 seconds for me to regenerate from scratch on my PPro200... linking scwm w/ constraints takes at least that long, so I'm not sure if separating out the .doc file generation is worth the effort right now. Greg From owner-scwm-discuss@mit.edu Wed Oct 28 20:16:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05301 for scwm-discuss-outgoing; Wed, 28 Oct 1998 20:16:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05298 for ; Wed, 28 Oct 1998 20:16:23 -0500 Received: from pegasus.kuis.kyoto-u.ac.jp by MIT.EDU with SMTP id AA18594; Wed, 28 Oct 98 20:16:17 EST Received: from localhost (virgo.kuis.kyoto-u.ac.jp [130.54.22.207]) by sato.kuis.kyoto-u.ac.jp (8.8.8/3.6W) with ESMTP id KAA09250 for ; Thu, 29 Oct 1998 10:16:19 +0900 (JST) To: scwm-discuss@mit.edu Subject: PanFrame From: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981029101633A.sakurada@kuis.kyoto-u.ac.jp> Date: Thu, 29 Oct 1998 10:16:33 +0900 (JST) X-Dispatcher: imput version 980905(IM100) Lines: 15 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, When I invoke & place a Netscape Communicator window over a PanFrame, I cannot move viewpoint by moving mouse onto the area where the PanFrame and Communicator are overlapped. I find that I can move viewpoint after lowering or raising the Communicator window. It seems that the Communicator window is hiding the PanFrame. Regards, -- Hideki Sakurada From owner-scwm-discuss@mit.edu Wed Oct 28 22:41:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06215 for scwm-discuss-outgoing; Wed, 28 Oct 1998 22:41:53 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06208; Wed, 28 Oct 1998 22:41:49 -0500 Message-Id: <199810290341.WAA06208@huis-clos.mit.edu> To: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) cc: scwm-discuss@mit.edu Subject: Re: PanFrame In-reply-to: Your message of "Thu, 29 Oct 1998 10:16:33 +0900." <19981029101633A.sakurada@kuis.kyoto-u.ac.jp> Date: Wed, 28 Oct 1998 22:41:49 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sakurada@kuis.kyoto-u.ac.jp writes: > > Hi, > > When I invoke & place a Netscape Communicator > window over a PanFrame, I cannot move viewpoint by > moving mouse onto the area where the PanFrame and > Communicator are overlapped. > > I find that I can move viewpoint after lowering > or raising the Communicator window. It seems that > the Communicator window is hiding the PanFrame. This is a longstanding bug that dates back to fvwm2 (and is documeted there). The fvwm2 code said this was due to a problem with Motif. I ignored it at the time because I didn't know what was going on or how to fix it. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 01:34:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA29128 for scwm-discuss-outgoing; Thu, 29 Oct 1998 01:34:43 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA29125 for ; Thu, 29 Oct 1998 01:34:41 -0500 Received: from pegasus.kuis.kyoto-u.ac.jp by MIT.EDU with SMTP id AA28174; Thu, 29 Oct 98 01:34:43 EST Received: from localhost (virgo.kuis.kyoto-u.ac.jp [130.54.22.207]) by sato.kuis.kyoto-u.ac.jp (8.8.8/3.6W) with ESMTP id PAA13739 for ; Thu, 29 Oct 1998 15:34:37 +0900 (JST) To: scwm-discuss@mit.edu Subject: Re: PanFrame From: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) In-Reply-To: Your message of "Wed, 28 Oct 1998 22:41:49 EST" <199810290341.WAA06208@huis-clos.mit.edu> References: <199810290341.WAA06208@huis-clos.mit.edu> X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981029153452Y.sakurada@kuis.kyoto-u.ac.jp> Date: Thu, 29 Oct 1998 15:34:52 +0900 (JST) X-Dispatcher: imput version 980905(IM100) Lines: 41 Sender: owner-scwm-discuss@mit.edu Precedence: bulk From: Maciej Stachowiak Subject: Re: PanFrame > sakurada@kuis.kyoto-u.ac.jp writes: > > > > When I invoke & place a Netscape Communicator > > window over a PanFrame, I cannot move viewpoint by > > moving mouse onto the area where the PanFrame and > > Communicator are overlapped. > > > > I find that I can move viewpoint after lowering > > or raising the Communicator window. It seems that > > the Communicator window is hiding the PanFrame. > > This is a longstanding bug that dates back to fvwm2 (and is documeted > there). The fvwm2 code said this was due to a problem with Motif. I > ignored it at the time because I didn't know what was going on or how > to fix it. The following patch works for me. I don't know if this is the right location to call raisePanFrames. Thanks. -- Hideki Sakurada *** events.c.orig Thu Oct 15 23:12:50 1998 --- events.c Thu Oct 29 15:17:25 1998 *************** *** 956,961 **** --- 956,963 ---- } if (!PPosOverride) KeepOnTop(); + + raisePanFrames(); } From owner-scwm-discuss@mit.edu Thu Oct 29 06:47:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA30907 for scwm-discuss-outgoing; Thu, 29 Oct 1998 06:47:14 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA30904 for ; Thu, 29 Oct 1998 06:47:10 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13249; Thu, 29 Oct 98 06:46:21 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id NAA25811; Thu, 29 Oct 1998 13:45:37 +0200 To: Todd Larason Cc: sds@goems.com, Greg Badros , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Oct 1998 13:45:37 +0200 In-Reply-To: Todd Larason's message of "Wed, 28 Oct 1998 14:26:37 -0800" Message-Id: Lines: 28 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981028, Sam Steingold wrote: > > Actually, on a second thought, it would seem to be a good itea - to > > gegenerate these files on each build. > > It requires perl, takes a while, and there's no dependancy checking there now > (and the way it works now, if there were, it would be dependant on > ***/*.{c,scm}). > > There's a guile version of the extractor; has it kept up with everything > the perl version does? That takes care of #1, but it's even slower. > > On my todo list, I've had an item to split out the source-scanning part > from the final building part, with an intermediate *.doc file for each > *.c (and *.scm file?), generated as part of the COMPILE rule. This would > be somewhat slower for initial builds, but would be faster for incremental, > and would encourage us to see any doc errors as soon as we make changes. > The final sgml/scwm-*.txt would be dependant on the *.doc files. If you process the files independently, then you lose the global checking that the extractor can do (i.e. - check that the same fcn isn't defined twice). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Oct 29 10:31:00 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31883 for scwm-discuss-outgoing; Thu, 29 Oct 1998 10:31:00 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA31871 for ; Thu, 29 Oct 1998 10:29:35 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA14446; Thu, 29 Oct 98 10:29:33 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA22554; Thu, 29 Oct 1998 07:27:07 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Todd Larason , sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> From: Greg Badros Date: 29 Oct 1998 07:27:07 -0800 In-Reply-To: hjstein@bfr.co.il's message of "29 Oct 1998 13:45:37 +0200" Message-Id: Lines: 15 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > If you process the files independently, then you lose the global > checking that the extractor can do (i.e. - check that the same fcn > isn't defined twice). If this is really an i.e. (i.e., not an e.g. -- are there other examples or is this the only global check we could do? [I didn't think I did this, though]), than I wouldn't sweat it. The linker does the same checker re: multiple function defs. I'm not sure that this matters so much except when generating sgml (where we might care to see if something in ` and ' is actually a proc or a symbol and which of those it is, etc.). Greg From owner-scwm-discuss@mit.edu Thu Oct 29 10:33:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31895 for scwm-discuss-outgoing; Thu, 29 Oct 1998 10:33:14 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA31892 for ; Thu, 29 Oct 1998 10:33:13 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA15650; Thu, 29 Oct 98 10:33:11 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA22560; Thu, 29 Oct 1998 07:33:00 -0800 (PST) To: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) Cc: scwm-discuss@mit.edu Subject: Re: PanFrame References: <199810290341.WAA06208@huis-clos.mit.edu> <19981029153452Y.sakurada@kuis.kyoto-u.ac.jp> From: Greg Badros Date: 29 Oct 1998 07:33:00 -0800 In-Reply-To: Hideki Sakurada's message of "Thu, 29 Oct 1998 15:34:52 +0900 (JST)" Message-Id: Lines: 33 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) writes: > From: Maciej Stachowiak > Subject: Re: PanFrame > > > sakurada@kuis.kyoto-u.ac.jp writes: > > > > > > When I invoke & place a Netscape Communicator > > > window over a PanFrame, I cannot move viewpoint by > > > moving mouse onto the area where the PanFrame and > > > Communicator are overlapped. > > > > > > I find that I can move viewpoint after lowering > > > or raising the Communicator window. It seems that > > > the Communicator window is hiding the PanFrame. > > > > This is a longstanding bug that dates back to fvwm2 (and is documeted > > there). The fvwm2 code said this was due to a problem with Motif. I > > ignored it at the time because I didn't know what was going on or how > > to fix it. I can't reproduce this... how do I "place a Netscape Communicator window over a PanFrame"? Do you just mean putting it at the edge of the viewport? > The following patch works for me. > I don't know if this is the right location to call > raisePanFrames. The patch looks fine to me, though I'm curious why things go bad only w/ Netscape Communicator, and why I can't reproduce the behaviour. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Oct 29 10:37:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA31929 for scwm-discuss-outgoing; Thu, 29 Oct 1998 10:37:32 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA31922 for ; Thu, 29 Oct 1998 10:36:54 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA17034; Thu, 29 Oct 98 10:36:47 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id KAA16509; Thu, 29 Oct 1998 10:36:36 -0500 To: SCWM Discussion Subject: Re: core dump in garbage collection From: Jim Blandy Date: 29 Oct 1998 10:36:34 -0500 Message-Id: Lines: 18 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > BTW, any thoughts about how best to add a callback at start of GC and > end end of GC? Maybe we'd have to restrict what can be done at the > start of GC to avoid the already-out-of-memory-and-unable-to-allocate > a new cons cell problem. I'm thinking it'd be useful , e.g., change the > root cursor, or display a message when scwm GCs (probably only for > performance debugging for now). I tend to think that calling Scheme code before and after GC is a bad idea, because of the kind of interference you mention. One should always be very cautious about exposing GC to the Scheme level; even weak pairs take a lot of care to handle correctly. I'd be willing to provide C-level hooks, though, and remove the hooks while the it's running. So if you don't allocate, fine, and if you do, well, the GC will proceed. All you folks want to do is change the cursor or pop up a message, which shouldn't require running any Scheme code. From owner-scwm-discuss@mit.edu Thu Oct 29 11:17:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32449 for scwm-discuss-outgoing; Thu, 29 Oct 1998 11:17:12 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA32438 for ; Thu, 29 Oct 1998 11:15:50 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01751; Thu, 29 Oct 98 11:15:44 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id SAA27908; Thu, 29 Oct 1998 18:13:08 +0200 To: Greg Badros Cc: Todd Larason , sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Oct 1998 18:13:08 +0200 In-Reply-To: Greg Badros's message of "29 Oct 1998 07:27:07 -0800" Message-Id: Lines: 32 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > If you process the files independently, then you lose the global > > checking that the extractor can do (i.e. - check that the same fcn > > isn't defined twice). > > If this is really an i.e. (i.e., not an e.g. -- are there other examples > or is this the only global check we could do? [I didn't think I did > this, though]), than I wouldn't sweat it. The linker does the same > checker re: multiple function defs. I'm not sure that this matters so > much except when generating sgml (where we might care to see if > something in ` and ' is actually a proc or a symbol and which of those > it is, etc.). I only have 1 global check in extract.scm - checking for 2 identical SCWM_PROC scheme names. This was actually occurring in the code when I was running extract.scm, so I don't think it's redundant & I don't think you were doing the same check in your perl version. If we want to do some limited markup to the txt output then it'd also need to read all the code in one run. In any case, even if you can generate scwm-procedures.txt incrementally, you can't generate scwm.sgml incrementally, so what's the point of incrementally building one but building the other in one run? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Oct 29 11:27:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA32579 for scwm-discuss-outgoing; Thu, 29 Oct 1998 11:27:15 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA32563 for ; Thu, 29 Oct 1998 11:25:46 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA05350; Thu, 29 Oct 98 11:25:37 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22648; Thu, 29 Oct 1998 08:24:00 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Todd Larason , sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> From: Greg Badros Date: 29 Oct 1998 08:24:00 -0800 In-Reply-To: hjstein@bfr.co.il's message of "29 Oct 1998 18:13:08 +0200" Message-Id: Lines: 29 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I only have 1 global check in extract.scm - checking for 2 identical > SCWM_PROC scheme names. This was actually occurring in the code when > I was running extract.scm, so I don't think it's redundant & I don't > think you were doing the same check in your perl version. If we want > to do some limited markup to the txt output then it'd also need to > read all the code in one run. I still don't get it. 2 identical SCWM_PROC scheme names would have to map to the same C name (note the inverse isn't true: foo->bar and foo-to-bar both map to foo_to_bar in C), so the linker would catch this. Two identical public scheme procedure names (in *.scm files) could be worthy of warning, and I'd not thought of that. > In any case, even if you can generate scwm-procedures.txt > incrementally, you can't generate scwm.sgml incrementally, so what's > the point of incrementally building one but building the other in one > run? I agree mostly, but there are some important software-engineering assurances that the documentation extractor performs (e.g., consistency of the counts of required, optional, varargs arguments and the formal argument list of the C function) that would be nice to do on every build. Maybe we just want a mode for the extractor to do those tests separate from building the documentation, and have the checks performed on the influenced files at every build. Greg From owner-scwm-discuss@mit.edu Thu Oct 29 13:55:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA00703 for scwm-discuss-outgoing; Thu, 29 Oct 1998 13:55:16 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA00700 for ; Thu, 29 Oct 1998 13:55:14 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA19304; Thu, 29 Oct 98 13:55:00 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA28944; Thu, 29 Oct 1998 20:54:52 +0200 To: Greg Badros Cc: Todd Larason , sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 29 Oct 1998 20:54:52 +0200 In-Reply-To: Greg Badros's message of "29 Oct 1998 08:24:00 -0800" Message-Id: Lines: 47 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > I only have 1 global check in extract.scm - checking for 2 identical > > SCWM_PROC scheme names. This was actually occurring in the code when > > I was running extract.scm, so I don't think it's redundant & I don't > > think you were doing the same check in your perl version. If we want > > to do some limited markup to the txt output then it'd also need to > > read all the code in one run. > > I still don't get it. 2 identical SCWM_PROC scheme names would have to > map to the same C name (note the inverse isn't true: foo->bar and > foo-to-bar both map to foo_to_bar in C), so the linker would catch this. > Two identical public scheme procedure names (in *.scm files) could be > worthy of warning, and I'd not thought of that. It looks like was an extra C file laying around which wasn't getting linked in. I still have an old copy of scwm which reports this. The latest anon cvs repo doesn't report it. Here's what I was getting: hjstein@bacall:~/scwm$ ./extract.scm ~/remote-cvs-pkgs/scwm/scwm/*.c /home/hjstein/remote-cvs-pkgs/scwm/scwm/draw-pie-menu.c:583: Scheme name of make-menus-pie! doesn't match a C name of make_menus_pie_X. /home/hjstein/remote-cvs-pkgs/scwm/scwm/draw-pie-menu.c:583: Procedure make-menus-pie! is not documented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/draw-pie-menu.c:583: Procedure make-menus-pie! doesn't have a FUNC_NAME. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c:188: Procedure menu-properties doesn't have a FUNC_NAME. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c:223: Argument count mismatch in make-menu. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c:223: Argument 11 (MENU-LOOK) of make-menu is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c:223: Procedure make-menu doesn't have a FUNC_NAME. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menulook.c:52: Procedure menulook? is not documented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/menulook.c:52: Argument 1 (SCM) of menulook? is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/resize.c:89: Argument 1 (X) of set-message-window-position! is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/resize.c:89: Argument 2 (Y) of set-message-window-position! is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/resize.c:89: Argument 3 (X-ALIGN) of set-message-window-position! is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/resize.c:89: Argument 4 (Y-ALIGN) of set-message-window-position! is undocumented. /home/hjstein/remote-cvs-pkgs/scwm/scwm/window.c:817: Scheme name of window-context doesn't match a C name of get_window_context. /home/hjstein/remote-cvs-pkgs/scwm/scwm/scwmmenu.c:111: Scheme name menu? redefined. First defined in /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c on line 128. /home/hjstein/remote-cvs-pkgs/scwm/scwm/scwmmenu.c:169: Scheme name menu-properties redefined. First defined in /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c on line 188. /home/hjstein/remote-cvs-pkgs/scwm/scwm/scwmmenu.c:195: Scheme name make-menu redefined. First defined in /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c on line 223. /home/hjstein/remote-cvs-pkgs/scwm/scwm/scwmmenu.c:1235: Scheme name popup-menu redefined. First defined in /home/hjstein/remote-cvs-pkgs/scwm/scwm/menu.c on line 1275. The error messages in question are the four from scwmmenu.c. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Oct 29 16:48:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01654 for scwm-discuss-outgoing; Thu, 29 Oct 1998 16:48:42 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01648 for ; Thu, 29 Oct 1998 16:47:56 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA23902; Thu, 29 Oct 98 16:47:28 EST Received: (qmail 24073 invoked by uid 501); 29 Oct 1998 21:47:31 -0000 Message-Id: <19981029134729.A23871@molehill.org> Date: Thu, 29 Oct 1998 13:47:29 -0800 From: Todd Larason To: "Harvey J. Stein" , Greg Badros Cc: sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Harvey J. Stein on Thu, Oct 29, 1998 at 06:13:08PM +0200 X-Tom-Swifty: "Stop that horse!" cried Tom woefully. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981029, Harvey J. Stein wrote: > In any case, even if you can generate scwm-procedures.txt > incrementally, you can't generate scwm.sgml incrementally, so what's > the point of incrementally building one but building the other in one > run? This puzzles me enough that I'm not sure I should comment further before I find to read the current script in detail. What I was thinking was to split the process much like the compiler/linker split for producing executables. As a side effect of the .c.o make rule, a script would run to read the .c file and produce an easily-parsed .doc file; with not much more work, it could arrange to only update the timestamp on the .doc file if it was actually changed. The scwm.sgml make target would have a dependancy on the executable (to force regeneration of all the .doc files if needed) and the .doc files (to force regeneration of the sgml from the doc files, generating the scwm-*.txt as a side effect, like now). As I said, I'm puzzled by the statemetn that scwm.sgml can't be generated incrementally, and if Greg's timing is what other people are seeing, it isn't worth the effort. From owner-scwm-discuss@mit.edu Thu Oct 29 17:07:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA01799 for scwm-discuss-outgoing; Thu, 29 Oct 1998 17:07:01 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA01793 for ; Thu, 29 Oct 1998 17:06:59 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA00666; Thu, 29 Oct 98 17:06:45 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA28596; Thu, 29 Oct 1998 14:06:43 -0800 (PST) To: Todd Larason Cc: "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> <19981029134729.A23871@molehill.org> From: Greg Badros Date: 29 Oct 1998 14:06:42 -0800 In-Reply-To: Todd Larason's message of "Thu, 29 Oct 1998 13:47:29 -0800" Message-Id: Lines: 46 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981029, Harvey J. Stein wrote: > > In any case, even if you can generate scwm-procedures.txt > > incrementally, you can't generate scwm.sgml incrementally, so what's > > the point of incrementally building one but building the other in one > > run? > > This puzzles me enough that I'm not sure I should comment further before > I find to read the current script in detail. > > What I was thinking was to split the process much like the compiler/linker > split for producing executables. As a side effect of the .c.o make rule, > a script would run to read the .c file and produce an easily-parsed > .doc file; with not much more work, it could arrange to only update the > timestamp on the .doc file if it was actually changed. This all would work, but I'd rather see it be as simple as possible so that we don't slow down the builds... minimally the suggestion will result in a parse by the perl code and a diff (and some extra file operations that will be really fast). Only the consistency checks part of documentation extraction is worth doing all the time, IMO. > The scwm.sgml make target would have a dependancy on the executable (to force > regeneration of all the .doc files if needed) and the .doc files (to force > regeneration of the sgml from the doc files, generating the scwm-*.txt as a > side effect, like now). Sounds like your suggestion was just to pull out the doc comments (i.e., omit the code, but do little else). I'm not sure that this is such a big win. I had thought you meant doing more of the per-doc-comment processing and putting partially-marked-up text in .doc files, or outputting the plaintext version that would then be combined more simply into the scwm-*.txt which is a bit harder to get exactly right (especially the real markup for scwm.sgml because of the global symbol introspection). > As I said, I'm puzzled by the statemetn that scwm.sgml can't be generated > incrementally, and if Greg's timing is what other people are seeing, it > isn't worth the effort. Again, I think a nice "make doc" rule and better enforcement of the software-engineering invariants is sufficient and pretty easy to do. Incremental doc generation won't be that big of a win, IMO. Greg From owner-scwm-discuss@mit.edu Thu Oct 29 17:58:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02181 for scwm-discuss-outgoing; Thu, 29 Oct 1998 17:58:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA02178 for ; Thu, 29 Oct 1998 17:58:50 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15891; Thu, 29 Oct 98 17:58:35 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA30315; Fri, 30 Oct 1998 00:57:44 +0200 To: Todd Larason Cc: "Harvey J. Stein" , Greg Badros , sds@goems.com, scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> <19981028142637.A12307@molehill.org> <19981029134729.A23871@molehill.org> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 30 Oct 1998 00:57:44 +0200 In-Reply-To: Todd Larason's message of "Thu, 29 Oct 1998 13:47:29 -0800" Message-Id: Lines: 48 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981029, Harvey J. Stein wrote: > > In any case, even if you can generate scwm-procedures.txt > > incrementally, you can't generate scwm.sgml incrementally, so what's > > the point of incrementally building one but building the other in one > > run? > > This puzzles me enough that I'm not sure I should comment further before > I find to read the current script in detail. > > What I was thinking was to split the process much like the > compiler/linker split for producing executables. As a side effect > of the .c.o make rule, a script would run to read the .c file and > produce an easily-parsed .doc file; with not much more work, it > could arrange to only update the timestamp on the .doc file if it > was actually changed. Oh. I thought you meant (as a makefile excerpt): %.doc : %.c extract $< >$@ scwm-procedures.txt : cat *.doc > scwm-procedures.txt This almost works exactly right except for the global tests (done by extract.scm but not by the perl version) and any markup of the docs. I guess what you meant instead was to speed up the process by outputting the parsed version of the C files, 1 file per C file & do the final document generation from the parsed data. This would be trivial with the scheme version & would speed it up substantially. I'm parse the data into lists which could just be output. Reading the lists instead of the C code would cut the processing time substantially. But it'd still be slower than the perl version. I don't know if doing this sort of thing would be easy for the perl version & if it'd be much help. Maybe the reading isn't a large part of the time with the perl version. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Oct 29 18:15:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02360 for scwm-discuss-outgoing; Thu, 29 Oct 1998 18:15:31 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA02357 for ; Thu, 29 Oct 1998 18:15:30 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA20158; Thu, 29 Oct 98 18:15:15 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02351; Thu, 29 Oct 1998 18:15:23 -0500 Message-Id: <199810292315.SAA02351@huis-clos.mit.edu> To: Greg Badros To: Todd Larason Cc: "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-Reply-To: Your message of "29 Oct 1998 14:06:42 PST." Date: Thu, 29 Oct 1998 18:15:23 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Todd Larason writes: > > > On 981029, Harvey J. Stein wrote: > > > In any case, even if you can generate scwm-procedures.txt > > > incrementally, you can't generate scwm.sgml incrementally, so what's > > > the point of incrementally building one but building the other in one > > > run? > > > > This puzzles me enough that I'm not sure I should comment further before > > I find to read the current script in detail. > > > > What I was thinking was to split the process much like the compiler/linker > > split for producing executables. As a side effect of the .c.o make rule, > > a script would run to read the .c file and produce an easily-parsed > > .doc file; with not much more work, it could arrange to only update the > > timestamp on the .doc file if it was actually changed. > > This all would work, but I'd rather see it be as simple as possible so > that we don't slow down the builds... minimally the suggestion will > result in a parse by the perl code and a diff (and some extra file > operations that will be really fast). Only the consistency checks part > of documentation extraction is worth doing all the time, IMO. > > > The scwm.sgml make target would have a dependancy on the executable (to force > > regeneration of all the .doc files if needed) and the .doc files (to force > > regeneration of the sgml from the doc files, generating the scwm-*.txt as a > > side effect, like now). > > Sounds like your suggestion was just to pull out the doc comments (i.e., > omit the code, but do little else). I'm not sure that this is such a > big win. I had thought you meant doing more of the per-doc-comment > processing and putting partially-marked-up text in .doc files, or > outputting the plaintext version that would then be combined more simply > into the scwm-*.txt which is a bit harder to get exactly right > (especially the real markup for scwm.sgml because of the global symbol > introspection). > > > As I said, I'm puzzled by the statemetn that scwm.sgml can't be generated > > incrementally, and if Greg's timing is what other people are seeing, it > > isn't worth the effort. > > Again, I think a nice "make doc" rule and better enforcement of the > software-engineering invariants is sufficient and pretty easy to do. > Incremental doc generation won't be that big of a win, IMO. > My take on this discussion: I would like to see us migrate to the Scheme version of the extractor, so timing will be a bit more of an issue for a while at least. I would like to look at integrating our doc system into Guile soon and it would be easier if we made improvements to the Scheme version directly so they don't have to be reimplemented later. The way I imagine the parsing/generating separation is to not just extract the comments but do all the processing short of writing any output, then write out data structures in some trivially parsable format, for example s-expression, to a .doc file for the C file, e.g.: (proc (scheme-name "window-raised?") (c-name "window_raised_p") (file "window.c") (line 750) ;;; I am totally making up that line number (module (app scwm primitives)) ;; Let's pretend scwm primitive bindings will go there ;; someday (purpose "") ;; purpose line (documentation "") ;; rest of docstring ) Or: (concept (name "Hooks") (file "callbacks.c") (line whatever) (documentation "Blah blah blah")) This way, all the parsing would get done, then the output stage would just merge the pre-parsed files by reading them (they would be trivially parseable) and generate appropriate output. As an added bonus, the flat-text docstring database could be generated essentially by concatenating all these .doc files, and the scheme docstring reading code could trivially parse it, assuming that is the primary goal of the flat-text file (maybe human-readability also counts?) Other improvements that, IMO need to be made to the doc extractor system include: * Avoiding hardcoding the names of the output files or anything else so it can be used for Guile, scwm, and potentially other apps or modules. The Guile people especially want to start using this soon, since documentation is now a top priority. (Incidentally, is everyone who has contributed to the extractor willing and able to sign papaers for this code?) * Handling the dynamically linked C modules. * Doing something to avoid retrieving docs from a flat file by symbol - it is perfectly valid for two different modules to have functions with the same name, for instance, they may be non-exported but documented anyway. Or the user may redefine a system function in which case the stored docs should be ignored for doc extraction purposes. This is more an issue for the code that accesses the docstrings than the extractor per se, though. * Avoid necessarily depending on scwm-isms like SCWM_PROC; we should be able to work with Guile's SCM_PROC as well. (As a side note, I have vague feelings that we should reconsider the use of SCWM_PROC entirely - the doc extractor should be able to enforce all of the constraints that SCWM_PROC was designed to make automatic, and I have this feeling that a macro that silently expands to a function declaration might be confusing - but that is a side issue; supporting both would be fine). * Run the files through the C preprocessor before parsing, inhibiting expansion of SCWM_PROC/SCM_PROC and friends. This will probably need changes to guile's snarf.h. Actually, if we don't expand SCM_PROC but _do_ expand SCWM_PROC to the equivalent SCM_PROC, we can simplify the code by that much - no need to handle two cases. Bonus! If others don't think these are good ideas, let me know. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 18:28:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02518 for scwm-discuss-outgoing; Thu, 29 Oct 1998 18:28:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA02515 for ; Thu, 29 Oct 1998 18:28:45 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA23272; Thu, 29 Oct 98 18:28:30 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA05248; Thu, 29 Oct 1998 15:28:34 -0800 (PST) To: Maciej Stachowiak Cc: Todd Larason , "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810292315.SAA02351@huis-clos.mit.edu> From: Greg Badros Date: 29 Oct 1998 15:28:34 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 18:15:23 EST" Message-Id: Lines: 123 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > My take on this discussion: I would like to see us migrate to the > Scheme version of the extractor, so timing will be a bit more of an > issue for a while at least. I would like to look at integrating our > doc system into Guile soon and it would be easier if we made > improvements to the Scheme version directly so they don't have to be > reimplemented later. Certainly using the scheme version will be useful to convincing the Guile folks that this is the right thing (and will continue to provide a useful benchmark for performance enhancements in text processing and regexps). > > The way I imagine the parsing/generating separation is to not just > extract the comments but do all the processing short of writing any > output, then write out data structures in some trivially parsable > format, for example s-expression, to a .doc file for the C file, e.g.: > > > (proc > (scheme-name "window-raised?") > (c-name "window_raised_p") > (file "window.c") > (line 750) ;;; I am totally making up that line number > (module (app scwm primitives)) ;; Let's pretend scwm primitive bindings will go there > ;; someday > (purpose "") ;; purpose line > (documentation "") ;; rest of docstring > ) > > Or: > > (concept > (name "Hooks") > (file "callbacks.c") > (line whatever) > (documentation "Blah blah blah")) Ugh. This looks like a schemified SGML markup. I think we should stick with SGML markup, even if it's slightly incomplete (e.g., the documentation markup might be missing markup for the procs that it references). > This way, all the parsing would get done, then the output stage would > just merge the pre-parsed files by reading them (they would be > trivially parseable) and generate appropriate output. As an added Especially trivially parsable if we write a DTD and use an SGML parser such as nsgmls. > bonus, the flat-text docstring database could be generated essentially > by concatenating all these .doc files, and the scheme docstring > reading code could trivially parse it, assuming that is the primary > goal of the flat-text file (maybe human-readability also counts?) I more and more think that the text file should be generated by using lynx on an SGML-generated file. I do this now to generate the ascii version of my risumi, and I like it a bunch. > Other improvements that, IMO need to be made to the doc extractor system > include: > > * Avoiding hardcoding the names of the output files or anything else > so it can be used for Guile, scwm, and potentially other apps or > modules. The Guile people especially want to start using this soon, > since documentation is now a top priority. (Incidentally, is everyone > who has contributed to the extractor willing and able to sign papaers > for this code?) I didn't write any of the Scheme code, but I'd of course sign papers on the perl version, or if you need me to sign something on the guile version (I don't know why -- it's Harvey's work). > * Handling the dynamically linked C modules. Not sure what you mean here-- the perl version scans all the modules' source. > > * Doing something to avoid retrieving docs from a flat file by symbol > - it is perfectly valid for two different modules to have functions > with the same name, for instance, they may be non-exported but > documented anyway. Or the user may redefine a system function in which > case the stored docs should be ignored for doc extraction purposes. > This is more an issue for the code that accesses the docstrings than > the extractor per se, though. I still like the idea of having Emacs's scwm-mode talk to a netscape with the HTML-formatted documentation. This doesn't do much for program-control of accessing the docstrings, but is better for me than plaintext docs. > * Avoid necessarily depending on scwm-isms like SCWM_PROC; we should > be able to work with Guile's SCM_PROC as well. (As a side note, I have > vague feelings that we should reconsider the use of SCWM_PROC entirely > - the doc extractor should be able to enforce all of the constraints > that SCWM_PROC was designed to make automatic, and I have this feeling > that a macro that silently expands to a function declaration might be > confusing - but that is a side issue; supporting both would be fine). Only confusing until you know about it. Then it helps chunking at a higher level of abstraction. Macros aren't bad, only hard to reason about macros are bad. Etags and other tools (e.g., diff) are sufficiently flexible that the SCWM_PROC doesn't cause me any problems (though it does require some extra configuration to make things easy to use). > * Run the files through the C preprocessor before parsing, inhibiting > expansion of SCWM_PROC/SCM_PROC and friends. This will probably need > changes to guile's snarf.h. Actually, if we don't expand SCM_PROC but > _do_ expand SCWM_PROC to the equivalent SCM_PROC, we can simplify the > code by that much - no need to handle two cases. Bonus! I've posted a couple of times how easy this is to do. For SCWM_PROC, it won't need changes to snarf.h, but for guile it might. > > If others don't think these are good ideas, let me know. All good ideas IMO. Greg From owner-scwm-discuss@mit.edu Thu Oct 29 18:48:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02690 for scwm-discuss-outgoing; Thu, 29 Oct 1998 18:48:09 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02683; Thu, 29 Oct 1998 18:48:06 -0500 Message-Id: <199810292348.SAA02683@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-reply-to: Your message of "29 Oct 1998 15:28:34 PST." Date: Thu, 29 Oct 1998 18:48:06 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Ugh. This looks like a schemified SGML markup. I think we should stick > with SGML markup, even if it's slightly incomplete (e.g., the > documentation markup might be missing markup for the procs that it > references). I think you misunderstand me. That is not supposed to be the final output, or the markup. This is just my suggestion for an _intermediate_ format, to be used to communicate between the parsing front end and the output-generating back-end, sort of like GCC's rtl mechanism. The parser would do the checks, create intermediate data structures, and dump them to disk in the form of s-expression (in Scheme you would just do a `write' of the appropriate data structure). Then, when generating docs from the per-file intermediate files, you read this info back into a data structure (in Scheme you'd use `read') and generate the output. Basically, you are just inserting a `write' to a file and a `read' back between the input and output stages. That wasn't meant to be markup at all, just some incredibly trivial key-value pairs which separate fields that the parsing code separates anyway. The back-end code then reads this in, processes it, and forms marked-up output. > > > This way, all the parsing would get done, then the output stage would > > just merge the pre-parsed files by reading them (they would be > > trivially parseable) and generate appropriate output. As an added > > Especially trivially parsable if we write a DTD and use an SGML parser > such as nsgmls. s-expressions are easier to parse than SGML, even SGML people will admit this. The point of the .doc files is not to be read by humans at all, it is only to have easily linkable pieces that can be merged by the final stage doc generator (which should still output SGML of course). Incidentally, the standard printed representation of GCC RTL is also s-expressions. > > > bonus, the flat-text docstring database could be generated essentially > > by concatenating all these .doc files, and the scheme docstring > > reading code could trivially parse it, assuming that is the primary > > goal of the flat-text file (maybe human-readability also counts?) > > I more and more think that the text file should be generated by using > lynx on an SGML-generated file. I do this now to generate the ascii > version of my risumi, and I like it a bunch. > Well, an important goal for that file right now is to be machine-parseable, I don't think we should rely on a browser's layout policies to maintain consistency in this area. > > Other improvements that, IMO need to be made to the doc extractor system > > include: > > > > * Avoiding hardcoding the names of the output files or anything else > > so it can be used for Guile, scwm, and potentially other apps or > > modules. The Guile people especially want to start using this soon, > > since documentation is now a top priority. (Incidentally, is everyone > > who has contributed to the extractor willing and able to sign papaers > > for this code?) > > I didn't write any of the Scheme code, but I'd of course sign papers on > the perl version, or if you need me to sign something on the guile > version (I don't know why -- it's Harvey's work). > If he did any of it by copying code from you and translating it, or even looked at it a lot, it would probably be safer to have papers from all involved.1w > > * Handling the dynamically linked C modules. > > Not sure what you mean here-- the perl version scans all the modules' > source. OK, I was just unaware that it was doing that then. I didn't think anyone had changed it to look in the modules/ directory. I also didn't think anyone had changed it to report what modules procs from those files are in, like it does when parsing Scheme files. > > > > * Doing something to avoid retrieving docs from a flat file by symbol > > - it is perfectly valid for two different modules to have functions > > with the same name, for instance, they may be non-exported but > > documented anyway. Or the user may redefine a system function in which > > case the stored docs should be ignored for doc extraction purposes. > > This is more an issue for the code that accesses the docstrings than > > the extractor per se, though. > > I still like the idea of having Emacs's scwm-mode talk to a netscape > with the HTML-formatted documentation. This doesn't do much for > program-control of accessing the docstrings, but is better for me than > plaintext docs. > I don't want scwm-mode to have to depend on a browser, but it would be nice if it optionally could use one. > > * Avoid necessarily depending on scwm-isms like SCWM_PROC; we should > > be able to work with Guile's SCM_PROC as well. (As a side note, I have > > vague feelings that we should reconsider the use of SCWM_PROC entirely > > - the doc extractor should be able to enforce all of the constraints > > that SCWM_PROC was designed to make automatic, and I have this feeling > > that a macro that silently expands to a function declaration might be > > confusing - but that is a side issue; supporting both would be fine). > > Only confusing until you know about it. Aye, there's the rub. It certainly doesn't confuse _me_ any more, but I would expect a new person looking at the source to see a SCM_PROC and think "I should figure out what this magic that comes before declarations does" but look at a SCWM_PROC and think "What is this crazy stuff? is this a function declaration or something?". Of course, I have no data on which to base this, and I don't feel that strongly about it. Indeed, my only significant (but still minor) concern is consistency with other Guile apps, but that is not the world's biggest deal. As I said, this is a side discussion. > Then it helps chunking at a > higher level of abstraction. Macros aren't bad, only hard to reason > about macros are bad. Etags and other tools (e.g., diff) are > sufficiently flexible that the SCWM_PROC doesn't cause me any problems > (though it does require some extra configuration to make things easy to > use). > > * Run the files through the C preprocessor before parsing, inhibiting > > expansion of SCWM_PROC/SCM_PROC and friends. This will probably need > > changes to guile's snarf.h. Actually, if we don't expand SCM_PROC but > > _do_ expand SCWM_PROC to the equivalent SCM_PROC, we can simplify the > > code by that much - no need to handle two cases. Bonus! > > I've posted a couple of times how easy this is to do. For SCWM_PROC, it > won't need changes to snarf.h, but for guile it might. > Great. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 18:51:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA02752 for scwm-discuss-outgoing; Thu, 29 Oct 1998 18:51:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA02749 for ; Thu, 29 Oct 1998 18:51:21 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA08096; Thu, 29 Oct 98 18:51:13 EST Received: (qmail 25086 invoked by uid 501); 29 Oct 1998 23:51:07 -0000 Message-Id: <19981029155106.A24891@molehill.org> Date: Thu, 29 Oct 1998 15:51:06 -0800 From: Todd Larason To: Maciej Stachowiak , Greg Badros Cc: "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810292315.SAA02351@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199810292315.SAA02351@huis-clos.mit.edu>; from Maciej Stachowiak on Thu, Oct 29, 1998 at 06:15:23PM -0500 X-Tom-Swifty: "This chicken has no beak", said Tom impeccably. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981029, Maciej Stachowiak wrote: > [ a more fully fleshed out version of what I was talking about, based > on the scheme extractor and s-expressions ] Looks good to me! > * Handling the dynamically linked C modules. The only issues I know of here are adding a suitable glob to the make line so the extractor finds them (and/or coming up with a real way for the extractor to know exactly what files to scan), and letting the extractor know what module the symbols are in. This isn't necessarily a problem just with the dynamically linked modules even - any of the code could put symbols into whatever module or modules it likes. > * Avoid necessarily depending on scwm-isms like SCWM_PROC; we should > be able to work with Guile's SCM_PROC as well. (As a side note, I have > vague feelings that we should reconsider the use of SCWM_PROC entirely > - the doc extractor should be able to enforce all of the constraints > that SCWM_PROC was designed to make automatic, and I have this feeling > that a macro that silently expands to a function declaration might be > confusing - but that is a side issue; supporting both would be fine). I've run into this too when working on the applefile module; quite a bit of it is potentially useful to non-scwm guile programs, but I want it to integrate well & cleanly with scwm. Should I use SCWM_PROC or SCM_PROC? From owner-scwm-discuss@mit.edu Thu Oct 29 19:40:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA03143 for scwm-discuss-outgoing; Thu, 29 Oct 1998 19:40:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA03140 for ; Thu, 29 Oct 1998 19:40:56 -0500 Received: from pegasus.kuis.kyoto-u.ac.jp by MIT.EDU with SMTP id AA08173; Thu, 29 Oct 98 19:40:33 EST Received: from localhost (virgo.kuis.kyoto-u.ac.jp [130.54.22.207]) by sato.kuis.kyoto-u.ac.jp (8.8.8/3.6W) with ESMTP id JAA19878 for ; Fri, 30 Oct 1998 09:40:27 +0900 (JST) To: scwm-discuss@mit.edu Subject: Re: PanFrame From: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) In-Reply-To: Your message of "29 Oct 1998 07:33:00 -0800" References: X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981030094041A.sakurada@kuis.kyoto-u.ac.jp> Date: Fri, 30 Oct 1998 09:40:41 +0900 (JST) X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-scwm-discuss@mit.edu Precedence: bulk From: Greg Badros > Hideki Sakurada writes: > > > From: Maciej Stachowiak > > Subject: Re: PanFrame > > > > > sakurada@kuis.kyoto-u.ac.jp writes: > > > > > > > > When I invoke & place a Netscape Communicator > > > > window over a PanFrame, I cannot move viewpoint by > > > > moving mouse onto the area where the PanFrame and > > > > Communicator are overlapped. > > > > > > > > I find that I can move viewpoint after lowering > > > > or raising the Communicator window. It seems that > > > > the Communicator window is hiding the PanFrame. > > > > > > This is a longstanding bug that dates back to fvwm2 (and is documeted > > > there). The fvwm2 code said this was due to a problem with Motif. I > > > ignored it at the time because I didn't know what was going on or how > > > to fix it. > > I can't reproduce this... how do I "place a Netscape Communicator window > over a PanFrame"? Do you just mean putting it at the edge of the viewport? Yes, I do. I can reproduce it at least on the following platforms with system.scwmrc. Solaris 2.6 for Intel Solaris 2.6 for SPARC Linux 2.0.34 (libXm is statically linked with Communicator) -- Hideki Sakurada From owner-scwm-discuss@mit.edu Thu Oct 29 20:44:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA03483 for scwm-discuss-outgoing; Thu, 29 Oct 1998 20:44:37 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA03480 for ; Thu, 29 Oct 1998 20:44:36 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA00525; Thu, 29 Oct 98 20:44:30 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA06244; Thu, 29 Oct 1998 17:44:23 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810292348.SAA02683@huis-clos.mit.edu> From: Greg Badros Date: 29 Oct 1998 17:44:22 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 18:48:06 EST" Message-Id: Lines: 161 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > > > > > Ugh. This looks like a schemified SGML markup. I think we should stick > > with SGML markup, even if it's slightly incomplete (e.g., the > > documentation markup might be missing markup for the procs that it > > references). > > I think you misunderstand me. That is not supposed to be the final > output, or the markup. This is just my suggestion for an > _intermediate_ format, to be used to communicate between the parsing > front end and the output-generating back-end, sort of like GCC's rtl > mechanism. The parser would do the checks, create intermediate data > structures, and dump them to disk in the form of s-expression (in > Scheme you would just do a `write' of the appropriate data structure). No, I understand completely. But my point was that the intermediate format is still just structured text which is exactly what SGML is all about. > Then, when generating docs from the per-file intermediate files, you > read this info back into a data structure (in Scheme you'd use `read') > and generate the output. Basically, you are just inserting a `write' > to a file and a `read' back between the input and output stages. Or you just use an SGML parsing library, and get all the power that those tools already have available. > That wasn't meant to be markup at all, just some incredibly trivial > key-value pairs which separate fields that the parsing code separates That's what markup is, to the first order. > anyway. The back-end code then reads this in, processes it, and forms > marked-up output. > > > > This way, all the parsing would get done, then the output stage would > > > just merge the pre-parsed files by reading them (they would be > > > trivially parseable) and generate appropriate output. As an added > > > > Especially trivially parsable if we write a DTD and use an SGML parser > > such as nsgmls. > > s-expressions are easier to parse than SGML, even SGML people will > admit this. The point of the .doc files is not to be read by humans at > all, it is only to have easily linkable pieces that can be merged by > the final stage doc generator (which should still output SGML of > course). Sure, but then you're still rolling your own. > Incidentally, the standard printed representation of GCC RTL is also > s-expressions. I'd buy this in terms of re-using some scheme-based persistent data structure mechanism. E.g., in perl, I could use DataDumper after reading it into some internal format so that later I could just re-run the program, get those data structures back in internal memory and begin where I left off -- is there a library like that for Guile? > > > bonus, the flat-text docstring database could be generated essentially > > > by concatenating all these .doc files, and the scheme docstring > > > reading code could trivially parse it, assuming that is the primary > > > goal of the flat-text file (maybe human-readability also counts?) > > > > I more and more think that the text file should be generated by using > > lynx on an SGML-generated file. I do this now to generate the ascii > > version of my risumi, and I like it a bunch. > > > > Well, an important goal for that file right now is to be > machine-parseable, I don't think we should rely on a browser's layout > policies to maintain consistency in this area. But it's a browser that is rendering using a style sheet, so it's reliable. > > > Other improvements that, IMO need to be made to the doc extractor system > > > include: > > > > > > * Avoiding hardcoding the names of the output files or anything else > > > so it can be used for Guile, scwm, and potentially other apps or > > > modules. The Guile people especially want to start using this soon, > > > since documentation is now a top priority. (Incidentally, is everyone > > > who has contributed to the extractor willing and able to sign papaers > > > for this code?) > > > > I didn't write any of the Scheme code, but I'd of course sign papers on > > the perl version, or if you need me to sign something on the guile > > version (I don't know why -- it's Harvey's work). > > > > If he did any of it by copying code from you and translating it, or > even looked at it a lot, it would probably be safer to have papers from all involved.1w Sure, that's fine with me. As the only "design" document, the perl implementation most definitely was consulted in writing the guile version (Harvey, please correct me if I'm wrong). > > > * Handling the dynamically linked C modules. > > > > Not sure what you mean here-- the perl version scans all the modules' > > source. > > OK, I was just unaware that it was doing that then. I didn't think > anyone had changed it to look in the modules/ directory. I also didn't > think anyone had changed it to report what modules procs from those > files are in, like it does when parsing Scheme files. Good point-- the latter isn't done. I will do this after I get back from UIST, or maybe tomorrow if time permits. > > > * Doing something to avoid retrieving docs from a flat file by symbol > > > - it is perfectly valid for two different modules to have functions > > > with the same name, for instance, they may be non-exported but > > > documented anyway. Or the user may redefine a system function in which > > > case the stored docs should be ignored for doc extraction purposes. > > > This is more an issue for the code that accesses the docstrings than > > > the extractor per se, though. > > > > I still like the idea of having Emacs's scwm-mode talk to a netscape > > with the HTML-formatted documentation. This doesn't do much for > > program-control of accessing the docstrings, but is better for me than > > plaintext docs. > > > > I don't want scwm-mode to have to depend on a browser, but it would be > nice if it optionally could use one. Right-- agreed completely. > > > * Avoid necessarily depending on scwm-isms like SCWM_PROC; we should > > > be able to work with Guile's SCM_PROC as well. (As a side note, I have > > > vague feelings that we should reconsider the use of SCWM_PROC entirely > > > - the doc extractor should be able to enforce all of the constraints > > > that SCWM_PROC was designed to make automatic, and I have this feeling > > > that a macro that silently expands to a function declaration might be > > > confusing - but that is a side issue; supporting both would be fine). > > > > Only confusing until you know about it. > > Aye, there's the rub. It certainly doesn't confuse _me_ any more, but > I would expect a new person looking at the source to see a SCM_PROC > and think "I should figure out what this magic that comes before > declarations does" but look at a SCWM_PROC and think "What is this > crazy stuff? is this a function declaration or something?". Of course, > I have no data on which to base this, and I don't feel that strongly > about it. Indeed, my only significant (but still minor) concern is > consistency with other Guile apps, but that is not the world's biggest > deal. As I said, this is a side discussion. They just need to read initial code overview documentation, of which we have some, but should perhaps have a pointer in the header of every source file about what to read to begin understanding the code. Certainly in the README and HACKING files, too, if not already. Greg From owner-scwm-discuss@mit.edu Thu Oct 29 20:50:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA03533 for scwm-discuss-outgoing; Thu, 29 Oct 1998 20:50:07 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA03530 for ; Thu, 29 Oct 1998 20:50:07 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA01700; Thu, 29 Oct 98 20:49:59 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA06247; Thu, 29 Oct 1998 17:49:50 -0800 (PST) To: Todd Larason Cc: Maciej Stachowiak , "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810292315.SAA02351@huis-clos.mit.edu> <19981029155106.A24891@molehill.org> From: Greg Badros Date: 29 Oct 1998 17:49:50 -0800 In-Reply-To: Todd Larason's message of "Thu, 29 Oct 1998 15:51:06 -0800" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I've run into this too when working on the applefile module; quite a bit > of it is potentially useful to non-scwm guile programs, but I want it to > integrate well & cleanly with scwm. Should I use SCWM_PROC or SCM_PROC? The main thing that SCWM_PROC gives you is better enforcing of some good invariants and one small convention (the s_ name of the variable containing the stringified primitive name). I think SCM_PROC would be better re-worked to be more like SCWM_PROC -- it didn't go as far as it should've in enforcing the otherwise only implicit constraints on the function headers. Note that within standard C we still have semantically necessary constraints that can't be enforced, which is why I made the documentation extractor double check those things (like argument list consistency with the numbers specified). Greg From owner-scwm-discuss@mit.edu Thu Oct 29 20:50:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA03548 for scwm-discuss-outgoing; Thu, 29 Oct 1998 20:50:55 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA03544 for ; Thu, 29 Oct 1998 20:50:54 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA20691; Thu, 29 Oct 98 20:50:38 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA06253; Thu, 29 Oct 1998 17:50:38 -0800 (PST) To: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) Cc: scwm-discuss@mit.edu Subject: Re: PanFrame References: <19981030094041A.sakurada@kuis.kyoto-u.ac.jp> From: Greg Badros Date: 29 Oct 1998 17:50:38 -0800 In-Reply-To: Hideki Sakurada's message of "Fri, 30 Oct 1998 09:40:41 +0900 (JST)" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) writes: > > I can't reproduce this... how do I "place a Netscape Communicator window > > over a PanFrame"? Do you just mean putting it at the edge of the viewport? > > Yes, I do. I can reproduce it at least on the > following platforms with system.scwmrc. > > Solaris 2.6 for Intel > Solaris 2.6 for SPARC > Linux 2.0.34 (libXm is statically linked with Communicator) Which Communicator? 4.0? Thanks, Greg From owner-scwm-discuss@mit.edu Thu Oct 29 21:02:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA03838 for scwm-discuss-outgoing; Thu, 29 Oct 1998 21:02:31 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id VAA03835 for ; Thu, 29 Oct 1998 21:02:30 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id VAA20278 for ; Thu, 29 Oct 1998 21:02:19 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id VAA24254 for ; Thu, 29 Oct 1998 21:02:17 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with ESMTP id VAA07880 for ; Thu, 29 Oct 1998 21:06:47 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Thu, 29 Oct 1998 21:06:46 -0500 (EST) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: endian.h Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi again, I just updated my CVS tree of scwm and ran across a problem building it because of the inclusion of in scwm/session-manager.c. FreeBSD 2.2.7 doesn't have but does have and the __BYTE_ORDER, __LITTLE_ENDIAN, and __BIG_ENDIAN macros lose the initial __ from their names. changed.c is char *szRepoLastChanged = "Wed Oct 28 17:49:20 EST 1998 -- $Revision: 1.777 $"; I know I've seen this check in other packages (can't remember which ones right now) using autoconf, which is probably the best way to go. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Thu Oct 29 21:08:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA03967 for scwm-discuss-outgoing; Thu, 29 Oct 1998 21:08:20 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA03960 for ; Thu, 29 Oct 1998 21:08:19 -0500 Received: from pegasus.kuis.kyoto-u.ac.jp by MIT.EDU with SMTP id AA05182; Thu, 29 Oct 98 21:08:11 EST Received: from localhost (virgo.kuis.kyoto-u.ac.jp [130.54.22.207]) by sato.kuis.kyoto-u.ac.jp (8.8.8/3.6W) with ESMTP id LAA20708 for ; Fri, 30 Oct 1998 11:08:04 +0900 (JST) To: scwm-discuss@mit.edu Subject: Re: PanFrame From: Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) In-Reply-To: Your message of "29 Oct 1998 17:50:38 -0800" References: X-Mailer: Mew version 1.93 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19981030110817T.sakurada@kuis.kyoto-u.ac.jp> Date: Fri, 30 Oct 1998 11:08:17 +0900 (JST) X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-scwm-discuss@mit.edu Precedence: bulk From: Greg Badros > Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) writes: > > > > I can't reproduce this... how do I "place a Netscape Communicator window > > > over a PanFrame"? Do you just mean putting it at the edge of the viewport? > > > > Yes, I do. I can reproduce it at least on the > > following platforms with system.scwmrc. > > > > Solaris 2.6 for Intel > > Solaris 2.6 for SPARC > > Linux 2.0.34 (libXm is statically linked with Communicator) > > Which Communicator? 4.0? I uses version 4.5(Solaris, Linux) and 4.0 (Linux). -- Hideki Sakurada From owner-scwm-discuss@mit.edu Thu Oct 29 21:32:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA04281 for scwm-discuss-outgoing; Thu, 29 Oct 1998 21:32:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA04277 for ; Thu, 29 Oct 1998 21:32:49 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA09680; Thu, 29 Oct 98 21:32:43 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA04270; Thu, 29 Oct 1998 21:32:47 -0500 Message-Id: <199810300232.VAA04270@huis-clos.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-Reply-To: Your message of "29 Oct 1998 17:44:22 PST." Date: Thu, 29 Oct 1998 21:32:47 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > No, I understand completely. But my point was that the intermediate > format is still just structured text which is exactly what SGML is all > about. > I was thinking of it as "structured data" rather than "structured text". Much of the data coincidentally happens to be text. I suppose you could call it a markup language if you want to, but by that standard almost any human-readable data format is a markup language. > > Then, when generating docs from the per-file intermediate files, you > > read this info back into a data structure (in Scheme you'd use `read') > > and generate the output. Basically, you are just inserting a `write' > > to a file and a `read' back between the input and output stages. > > Or you just use an SGML parsing library, and get all the power that > those tools already have available. SGML is no more powerful than s-expressions, on the superficial syntax level. Further, s-expressions are much easier to parse in general than SGML. Compare the size of any SGML parser to the size of the average Lisp/Scheme `read' implementation. The primary goal of this intermediate format is not to interoperate with a large body of working tools but to be easy to output and parse. > > That wasn't meant to be markup at all, just some incredibly trivial > > key-value pairs which separate fields that the parsing code separates > > That's what markup is, to the first order. That's also what Berkely `db' is to the first order, but I wouldn't suggest using that, either for the doc extractor or for formatting text documents. Nor would I suggest using SGML or s-expressions to store a database of customers. My point being that just because two tools have a superficial similarity, and one is better for some tasks, that does not mean it is better for all tasks. > > anyway. The back-end code then reads this in, processes it, and forms > > marked-up output. > > > > > > This way, all the parsing would get done, then the output stage would > > > > just merge the pre-parsed files by reading them (they would be > > > > trivially parseable) and generate appropriate output. As an added > > > > > > Especially trivially parsable if we write a DTD and use an SGML parser > > > such as nsgmls. > > > > s-expressions are easier to parse than SGML, even SGML people will > > admit this. The point of the .doc files is not to be read by humans at > > all, it is only to have easily linkable pieces that can be merged by > > the final stage doc generator (which should still output SGML of > > course). > > Sure, but then you're still rolling your own. This is the standard way for Lisp code to represent structured data externally. If we forced the program to read and write an intermediate made-up SGML application instead, it would be a bunch of extra work with no real gain. Indeed, any language, Perl included, could parse s-expressions of the type I gave more easily and robustly than SGML. Admittedly, someone has done the SGML work for perl already, but a robust perl s-expression parser could be written in less than 50 lines of perl code, if it takes that much. The function check_balance in scwmrepl.c essentially parses Guile s-expressions to a first approximation in 133 lines of C code, and it is written much more stupidly than it could be (reminds me - I need to rewrite it sensibly). > > Incidentally, the standard printed representation of GCC RTL is also > > s-expressions. > > I'd buy this in terms of re-using some scheme-based persistent data > structure mechanism. E.g., in perl, I could use DataDumper after > reading it into some internal format so that later I could just re-run > the program, get those data structures back in internal memory and > begin where I left off -- is there a library like that for Guile? Yes, it's called `read' and `write'. :-) OK, that doesn't handle shared or circular structures, but we don't care about that for this application. > > > > bonus, the flat-text docstring database could be generated essentially > > > > by concatenating all these .doc files, and the scheme docstring > > > > reading code could trivially parse it, assuming that is the primary > > > > goal of the flat-text file (maybe human-readability also counts?) > > > > > > I more and more think that the text file should be generated by using > > > lynx on an SGML-generated file. I do this now to generate the ascii > > > version of my risumi, and I like it a bunch. > > > > > > > Well, an important goal for that file right now is to be > > machine-parseable, I don't think we should rely on a browser's layout > > policies to maintain consistency in this area. > > But it's a browser that is rendering using a style sheet, so it's reliable. I wasn't aware that style sheets could guarantee a specific layout on a character terminal. Since many aspects are not implementable on a character terminal, I assumed that it was up to the application to decide how to not implement them. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 21:55:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA06076 for scwm-discuss-outgoing; Thu, 29 Oct 1998 21:55:05 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA06068; Thu, 29 Oct 1998 21:55:03 -0500 Message-Id: <199810300255.VAA06068@huis-clos.mit.edu> To: Craig Struble cc: scwm-discuss@mit.edu Subject: Re: endian.h In-reply-to: Your message of "Thu, 29 Oct 1998 21:06:46 EST." Date: Thu, 29 Oct 1998 21:55:03 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > Hi again, I just updated my CVS tree of scwm and ran across a problem > building it because of the inclusion of in > scwm/session-manager.c. FreeBSD 2.2.7 doesn't have but does > have and the __BYTE_ORDER, __LITTLE_ENDIAN, and > __BIG_ENDIAN macros lose the initial __ from their names. changed.c is > > char *szRepoLastChanged = "Wed Oct 28 17:49:20 EST 1998 -- $Revision: 1.777 $"; > > I know I've seen this check in other packages (can't remember which ones > right now) using autoconf, which is probably the best way to go. > Why aren't we just using htonl and ntohl instead of the hton32 and ntoh32 in there that depend on endian.h? I don't think there is any portable way to find a header file with endianness test macros, but I am pretty sure htonl/ntohl portably work on 32 bit quantities on all systems. They have to or else internet protocols would not work. should prototype those portably. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 22:01:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06224 for scwm-discuss-outgoing; Thu, 29 Oct 1998 22:01:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06216; Thu, 29 Oct 1998 22:01:17 -0500 Message-Id: <199810300301.WAA06216@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: PanFrame In-reply-to: Your message of "29 Oct 1998 17:50:38 PST." Date: Thu, 29 Oct 1998 22:01:17 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Hideki Sakurada (=?iso-2022-jp?B?GyRCXS9FRDFRPHkbKEI=?=) writes > : > > > > I can't reproduce this... how do I "place a Netscape Communicator window > > > over a PanFrame"? Do you just mean putting it at the edge of the viewport? > > > > Yes, I do. I can reproduce it at least on the > > following platforms with system.scwmrc. > > > > Solaris 2.6 for Intel > > Solaris 2.6 for SPARC > > Linux 2.0.34 (libXm is statically linked with Communicator) > > Which Communicator? 4.0? > I've observed this problem personally with netscape 3.x and 4.x occasionally myself, but not consistently. And as I said, the fvwm2 source mentions this and blames it on motif. I can't reproduce it I right now though. From owner-scwm-discuss@mit.edu Thu Oct 29 22:04:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06312 for scwm-discuss-outgoing; Thu, 29 Oct 1998 22:04:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA06308 for ; Thu, 29 Oct 1998 22:04:44 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA05311; Thu, 29 Oct 98 22:04:28 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06300; Thu, 29 Oct 1998 22:04:42 -0500 Message-Id: <199810300304.WAA06300@huis-clos.mit.edu> To: Greg Badros Cc: "Todd Larason scwm-discuss list" Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-Reply-To: Your message of "29 Oct 1998 17:49:50 PST." Date: Thu, 29 Oct 1998 22:04:42 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Todd Larason writes: > > > I've run into this too when working on the applefile module; quite a bit > > of it is potentially useful to non-scwm guile programs, but I want it to > > integrate well & cleanly with scwm. Should I use SCWM_PROC or SCM_PROC? > > The main thing that SCWM_PROC gives you is better enforcing of some good > invariants and one small convention (the s_ name of the variable > containing the stringified primitive name). I think SCM_PROC would be > better re-worked to be more like SCWM_PROC -- it didn't go as far as it > should've in enforcing the otherwise only implicit constraints on the > function headers. Note that within standard C we still have > semantically necessary constraints that can't be enforced, which is why > I made the documentation extractor double check those things (like > argument list consistency with the numbers specified). I've been taught that in a software-engineering sense, redundancy of language constructs is good, as long as it is checked - that way you would have to make a mistake more than once in order for it to slip by unnoticed. According to this theory, if we are willing to use the doc extractor as a metaprogramming tool, we should require the redundancy and check it instead of removing it. But then again, the rest of my "software engineering" class was pretty full of it. To address the original point, I'd say use SCM_PROC for stuff you want to be useful outside of scwm, on the theory that it might well get packaged separately someday. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 22:08:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06431 for scwm-discuss-outgoing; Thu, 29 Oct 1998 22:08:52 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06423; Thu, 29 Oct 1998 22:08:48 -0500 Message-Id: <199810300308.WAA06423@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-reply-to: Your message of "Thu, 29 Oct 1998 15:51:06 PST." <19981029155106.A24891@molehill.org> Date: Thu, 29 Oct 1998 22:08:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981029, Maciej Stachowiak wrote: > > [ a more fully fleshed out version of what I was talking about, based > > on the scheme extractor and s-expressions ] > Looks good to me! > > > * Handling the dynamically linked C modules. > > The only issues I know of here are adding a suitable glob to the make > line so the extractor finds them (and/or coming up with a real way for > the extractor to know exactly what files to scan), and letting the > extractor know what module the symbols are in. That's more or less what I had in mind. > This isn't necessarily a problem just with the dynamically linked > modules even - any of the code could put symbols into whatever > module or modules it likes. That's a good point. Maybe a good solution would be to add a /**MODULE: (whatever module declaration) */ dcoumentation comment type that causes anything after it in the same file to be assumed to be in the named module. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 22:33:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06793 for scwm-discuss-outgoing; Thu, 29 Oct 1998 22:33:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06783; Thu, 29 Oct 1998 22:33:10 -0500 Message-Id: <199810300333.WAA06783@huis-clos.mit.edu> To: Jim Blandy cc: scwm-discuss@mit.edu Subject: Re: core dump in garbage collection In-reply-to: Your message of "29 Oct 1998 10:36:34 EST." Date: Thu, 29 Oct 1998 22:33:10 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > > BTW, any thoughts about how best to add a callback at start of GC and > > end end of GC? Maybe we'd have to restrict what can be done at the > > start of GC to avoid the already-out-of-memory-and-unable-to-allocate > > a new cons cell problem. I'm thinking it'd be useful , e.g., change the > > root cursor, or display a message when scwm GCs (probably only for > > performance debugging for now). > > I tend to think that calling Scheme code before and after GC is a bad > idea, because of the kind of interference you mention. One should > always be very cautious about exposing GC to the Scheme level; even > weak pairs take a lot of care to handle correctly. > > I'd be willing to provide C-level hooks, though, and remove the hooks > while the it's running. So if you don't allocate, fine, and if you > do, well, the GC will proceed. All you folks want to do is change the > cursor or pop up a message, which shouldn't require running any Scheme > code. Yeah, but it's nice to generalize such hooks, and Scheme code is the best way to do that. Incidentally, I have never seen scwm pause for GC long enough to notice, so I am not sure the message or cursor change would be helpful.... Is my machine too fast or something? This is on my measly K6/166x32M. - Maciej From owner-scwm-discuss@mit.edu Thu Oct 29 22:38:25 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06878 for scwm-discuss-outgoing; Thu, 29 Oct 1998 22:38:25 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA06870; Thu, 29 Oct 1998 22:38:22 -0500 Message-Id: <199810300338.WAA06870@huis-clos.mit.edu> To: jimb@red-bean.com cc: scwm-discuss@mit.edu Subject: Re: Next SCWM release Date: Thu, 29 Oct 1998 22:38:22 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim tried to send the message quoted below to this list, but majordomo stupidly bounced it, I hope he does not mind me replying here. Jim Blandy > I seem to remember someone saying that the SCWM people were waiting > for a Guile release before they did the next SCWM release. I realize > there are other things in SCWM you want to work on, but I wanted to > make sure: is there anything else you guys want fixed in an officially > released Guile? Any new bugs that make 1.3 unsuitable? > I want to be able to merge my changes with the mainline, after which a beta should be out shortly. I am meeting with the lawyer tomorrow and will not walk out until I get papers signed, so that shouldn't be a problem much longer. I also want to rename a lot of things or otherwise trivially change the interfaces, but I'm waiting until I merge to do the busywork on that, so I don't cause gratuitous merging difficulties. > The 3x increase in startup time is the only major flaw in 1.3 that I > know of. That should be resolved sometime soon. > It would indeed be nice to see that fixed. - Maciej From owner-scwm-discuss@mit.edu Fri Oct 30 06:05:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA09216 for scwm-discuss-outgoing; Fri, 30 Oct 1998 06:05:48 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id GAA09213 for ; Fri, 30 Oct 1998 06:05:41 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id LAA18758 for scwm-discuss@huis-clos.mit.edu; Fri, 30 Oct 1998 11:55:42 +0100 (MET) Received: (qmail 409 invoked by uid 115); 29 Oct 1998 08:19:45 -0000 To: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 29 Oct 1998 09:19:41 +0100 In-Reply-To: Sam Steingold's message of "28 Oct 1998 18:06:27 -0500" Message-ID: Lines: 27 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 28 Oct 1998 18:06:27 -0500 >>>>> Sam Steingold said: Sam> Actually, on a second thought, it would seem to be a good itea - Sam> to gegenerate these files on each build. The only problem is that the (feh!) perl script that generates these files uses the Text::Balanced module, which is not part of the normal perl5 distribution[1]. So we either include this module in utilities/dev, or require all developers to snarf it from somewhere (anybody knows the exact location?). Casual users should be unaffected if the dependencies are done right (i.e. scwm-procedures.txt is only rebuilt if *.c is modified; errors building it are ignored). Robbe [1] I actually failed to find it on CPAN, but that may be just me. -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Oct 30 10:03:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA10704 for scwm-discuss-outgoing; Fri, 30 Oct 1998 10:03:43 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA10701 for ; Fri, 30 Oct 1998 10:03:40 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id QAA02162 for scwm-discuss@huis-clos.mit.edu; Fri, 30 Oct 1998 16:01:14 +0100 (MET) Received: (qmail 2850 invoked by uid 115); 30 Oct 1998 12:44:52 -0000 To: scwm-discuss@mit.edu Subject: Re: endian.h References: <199810300255.VAA06068@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 30 Oct 1998 13:44:49 +0100 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 21:55:03 EST" Message-ID: Lines: 27 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 29 Oct 1998 21:55:03 EST >>>>> Maciej Stachowiak said: Maciej> Why aren't we just using htonl and ntohl instead of the Maciej> hton32 and ntoh32 in there that depend on endian.h? I don't Maciej> think there is any portable way to find a header file with Maciej> endianness test macros, but I am pretty sure htonl/ntohl Maciej> portably work on 32 bit quantities on all systems. They have Maciej> to or else internet protocols would not work. Well, the standard stupidly says that htonl/ntohl take and return "unsigned long". This is of course bogus on 64 bit systems. I know that the GNU libc uses uint32 regardless of platform, but was not sure about beasts like Digital Unix. I concur with your opinion that strict standards-conformance would mean major breakage on these systems. Can someone check out what DU and other 64 bit systems do, and if hton32/ntoh32 can be safely removed? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Oct 30 11:54:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA11559 for scwm-discuss-outgoing; Fri, 30 Oct 1998 11:54:36 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA11556 for ; Fri, 30 Oct 1998 11:54:31 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA28461; Fri, 30 Oct 98 11:51:08 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA07290; Fri, 30 Oct 1998 08:50:55 -0800 (PST) To: Maciej Stachowiak Cc: "Todd Larason scwm-discuss list" Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810300304.WAA06300@huis-clos.mit.edu> From: Greg Badros Date: 30 Oct 1998 08:50:55 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 22:04:42 EST" Message-Id: Lines: 35 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > The main thing that SCWM_PROC gives you is better enforcing of some good > > invariants and one small convention (the s_ name of the variable > > containing the stringified primitive name). I think SCM_PROC would be > > better re-worked to be more like SCWM_PROC -- it didn't go as far as it > > should've in enforcing the otherwise only implicit constraints on the > > function headers. Note that within standard C we still have > > semantically necessary constraints that can't be enforced, which is why > > I made the documentation extractor double check those things (like > > argument list consistency with the numbers specified). > > I've been taught that in a software-engineering sense, redundancy of > language constructs is good, as long as it is checked - that way you > would have to make a mistake more than once in order for it to slip by > unnoticed. According to this theory, if we are willing to use the doc > extractor as a metaprogramming tool, we should require the redundancy > and check it instead of removing it. But then again, the rest of my > "software engineering" class was pretty full of it. Local or superficial redundancies are just a nuisance-- non local redundancy (e.g., types) is a good thing. The bottom line is that C is not an expressive-enough language to directly enforce the coding style we must have, and anything that gets us closer to forcing the invariants we need is useful. > To address the original point, I'd say use SCM_PROC for stuff you want > to be useful outside of scwm, on the theory that it might well get > packaged separately someday. I agree w/ this, at least until guile has revisited SCM_PROC or created a standard tool for checking the redundancy that are by necessity present. Greg From owner-scwm-discuss@mit.edu Fri Oct 30 11:58:32 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA11591 for scwm-discuss-outgoing; Fri, 30 Oct 1998 11:58:32 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA11588 for ; Fri, 30 Oct 1998 11:58:29 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA01716; Fri, 30 Oct 98 11:57:41 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA07281; Fri, 30 Oct 1998 08:46:24 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810300232.VAA04270@huis-clos.mit.edu> From: Greg Badros Date: 30 Oct 1998 08:46:24 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 21:32:47 EST" Message-Id: Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > I was thinking of it as "structured data" rather than "structured > text". Much of the data coincidentally happens to be text. I suppose > you could call it a markup language if you want to, but by that > standard almost any human-readable data format is a markup language. Yea, I see now you are right. Thanks for convincing me. > > > Well, an important goal for that file right now is to be > > > machine-parseable, I don't think we should rely on a browser's layout > > > policies to maintain consistency in this area. > > > > But it's a browser that is rendering using a style sheet, so it's reliable. > > I wasn't aware that style sheets could guarantee a specific layout on > a character terminal. Since many aspects are not implementable on a > character terminal, I assumed that it was up to the application to > decide how to not implement them. Guarantee may be too strong, but the alternative is having markup in the plain text that we present, or writing a docbook->ascii tool. I think in practice the lynx output may be structured enough to use it. Greg From owner-scwm-discuss@mit.edu Fri Oct 30 12:00:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11632 for scwm-discuss-outgoing; Fri, 30 Oct 1998 12:00:55 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11629 for ; Fri, 30 Oct 1998 12:00:53 -0500 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA00253; Fri, 30 Oct 98 12:00:34 EST Received: from localhost by csgrad.cs.vt.edu (5.65v4.0/1.1.10.5/10Mar98-1026AM) id AA04412; Fri, 30 Oct 1998 11:57:48 -0500 Date: Fri, 30 Oct 1998 11:57:48 -0500 (EST) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: endian.h In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hello, On 30 Oct 1998, Robert Bihlmeyer wrote: > Hi, > > >>>>> On Thu, 29 Oct 1998 21:55:03 EST > >>>>> Maciej Stachowiak said: > > Maciej> Why aren't we just using htonl and ntohl instead of the > Maciej> hton32 and ntoh32 in there that depend on endian.h? I don't > Maciej> think there is any portable way to find a header file with > Maciej> endianness test macros, but I am pretty sure htonl/ntohl > Maciej> portably work on 32 bit quantities on all systems. They have > Maciej> to or else internet protocols would not work. > > Well, the standard stupidly says that htonl/ntohl take and return > "unsigned long". This is of course bogus on 64 bit systems. I know > that the GNU libc uses uint32 regardless of platform, but was not sure > about beasts like Digital Unix. > > I concur with your opinion that strict standards-conformance would > mean major breakage on these systems. Can someone check out what DU > and other 64 bit systems do, and if hton32/ntoh32 can be safely > removed? > The declarations for htonl and ntohl on DU 4.0 are (from /usr/include/machine/endian.h): unsigned int ntohl(unsigned int), htonl(unsigned int); so apparently they have things implemented for 32 bits and not 64 bits. The manual page also states it works on 32 bits of data. I could swear I've seen other packages test for endianess using autoconf with a test program, and then set their own endian flags as appropriate. So if it does turn out that ntohl() and htonl() are not portable, even thought they should be, I'll try to track down what packages do this check. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Fri Oct 30 12:04:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11726 for scwm-discuss-outgoing; Fri, 30 Oct 1998 12:04:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11723 for ; Fri, 30 Oct 1998 12:04:30 -0500 Received: from fielder.cs.washington.edu by MIT.EDU with SMTP id AA01475; Fri, 30 Oct 98 12:04:12 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07320; Fri, 30 Oct 1998 09:04:10 -0800 (PST) To: Maciej Stachowiak Cc: Jim Blandy , scwm-discuss@mit.edu Subject: Re: core dump in garbage collection References: <199810300333.WAA06783@huis-clos.mit.edu> From: Greg Badros Date: 30 Oct 1998 09:04:09 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 22:33:10 EST" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Incidentally, I have never seen scwm pause for GC long enough to > notice, so I am not sure the message or cursor change would be > helpful.... Is my machine too fast or something? This is on my measly > K6/166x32M. I've had reports from a user on a P90 that switching windows seems to slow down noticeably after using scwm for a while. Bottom line is it'd be useful to give some simple feedback (optionally) about when GC is occurring so her description can be more precise: perhaps, "the GC phase is taking longer and longer." No biggie, but it seems as though apps generally could want this hook. Greg From owner-scwm-discuss@mit.edu Fri Oct 30 12:12:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA11956 for scwm-discuss-outgoing; Fri, 30 Oct 1998 12:12:07 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA11946 for ; Fri, 30 Oct 1998 12:12:00 -0500 Received: from [128.95.1.123] by MIT.EDU with SMTP id AA07800; Fri, 30 Oct 98 12:11:07 EST Received: (gjb@localhost) by fielder.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA07365; Fri, 30 Oct 1998 09:09:24 -0800 (PST) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> From: Greg Badros Date: 30 Oct 1998 09:09:24 -0800 In-Reply-To: Robert Bihlmeyer's message of "29 Oct 1998 09:19:41 +0100" Message-Id: Lines: 32 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > The only problem is that the (feh!) perl script that generates these > files uses the Text::Balanced module, which is not part of the normal > perl5 distribution[1]. > > So we either include this module in utilities/dev, or require all > developers to snarf it from somewhere (anybody knows the exact > location?). CPAN has it, but I also just copied the Balanced.pm file onto my ftp site -- ftp.cs.washington.edu:/homes/gjb Just stick it in Text/Balanced.pm off of your local shared site-lib directory. > Casual users should be unaffected if the dependencies are done right > (i.e. scwm-procedures.txt is only rebuilt if *.c is modified; errors > building it are ignored). And I or someone else reliably checks in newly created versions. We should definitely provide an HTML distribution (separate .tar.gz file, methinks) of the docs with the next beta release. Generating the HTML is completely non-trivial. > [1] I actually failed to find it on CPAN, but that may be just me. Hmmm... should just by by-module/Text/Balanced.pm or something like that. I know that's where I got it from, but I'm behind a low-speed connection so it's not worth my looking now. Greg From owner-scwm-discuss@mit.edu Fri Oct 30 12:25:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12172 for scwm-discuss-outgoing; Fri, 30 Oct 1998 12:25:30 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA12169 for ; Fri, 30 Oct 1998 12:25:29 -0500 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA13876; Fri, 30 Oct 98 12:25:09 EST Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.9.1a/8.9.1) with SMTP id MAA12069 for ; Fri, 30 Oct 1998 12:25:18 -0500 (EST) Message-Id: <199810301725.MAA12069@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: scwm-discuss@mit.edu Subject: Re: endian.h In-Reply-To: Your message of "Fri, 30 Oct 1998 11:57:48 EST." Date: Fri, 30 Oct 1998 12:25:18 -0500 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk Also, the manpage on DU/4.0d reads: htonl - Converts an unsigned 32-bit integer from host byte order to Inter- net network-byte order LIBRARY Standard C Library (libc.so, libc.a) SYNOPSIS #include in_addr_t htonl ( in_addr_t hostint) ; From owner-scwm-discuss@mit.edu Fri Oct 30 12:27:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12195 for scwm-discuss-outgoing; Fri, 30 Oct 1998 12:27:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA12189; Fri, 30 Oct 1998 12:27:17 -0500 Message-Id: <199810301727.MAA12189@huis-clos.mit.edu> To: "Craig A. Struble" cc: scwm-discuss@mit.edu Subject: Re: endian.h In-reply-to: Your message of "Fri, 30 Oct 1998 11:57:48 EST." Date: Fri, 30 Oct 1998 12:27:17 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > Hello, > > On 30 Oct 1998, Robert Bihlmeyer wrote: > > > > > Well, the standard stupidly says that htonl/ntohl take and return > > "unsigned long". This is of course bogus on 64 bit systems. I know > > that the GNU libc uses uint32 regardless of platform, but was not sure > > about beasts like Digital Unix. > > > > I concur with your opinion that strict standards-conformance would > > mean major breakage on these systems. Can someone check out what DU > > and other 64 bit systems do, and if hton32/ntoh32 can be safely > > removed? > > > The declarations for htonl and ntohl on DU 4.0 are (from > /usr/include/machine/endian.h): > > unsigned int ntohl(unsigned int), htonl(unsigned int); > > so apparently they have things implemented for 32 bits and not 64 bits. > The manual page also states it works on 32 bits of data. > I am pretty sure it has to be that way in order for IP to work. If you tried to byteswap an IP address in a 64-bit wide field you would lose totally. I don't have a copy of the posix networking draft standard around so I can't state what it says, but if it says `unsinged long' then it's just plain broken and should be ignored by all reasonable implementors. > I could swear I've seen other packages test for endianess using autoconf > with a test program, and then set their own endian flags as appropriate. > So if it does turn out that ntohl() and htonl() are not portable, even > thought they should be, I'll try to track down what packages do this > check. That's probably the only portable and reliable way to do it, should it be necessary. - Maciej From owner-scwm-discuss@mit.edu Sat Oct 31 17:25:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA31264 for scwm-discuss-outgoing; Sat, 31 Oct 1998 17:25:14 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA31261 for ; Sat, 31 Oct 1998 17:25:08 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26679; Sat, 31 Oct 98 17:24:35 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA13778; Sun, 1 Nov 1998 00:24:24 +0200 To: Maciej Stachowiak Cc: Greg Badros , Todd Larason , "Harvey J. Stein" , scwm-discuss list Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <199810292315.SAA02351@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 01 Nov 1998 00:24:24 +0200 In-Reply-To: Maciej Stachowiak's message of "Thu, 29 Oct 1998 18:15:23 EST" Message-Id: Lines: 75 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > My take on this discussion: I would like to see us migrate to the > Scheme version of the extractor, so timing will be a bit more of an > issue for a while at least. I would like to look at integrating our > doc system into Guile soon and it would be easier if we made > improvements to the Scheme version directly so they don't have to be > reimplemented later. > > The way I imagine the parsing/generating separation is to not just > extract the comments but do all the processing short of writing any > output, then write out data structures in some trivially parsable > format, for example s-expression, to a .doc file for the C file, e.g.: > > > (proc > (scheme-name "window-raised?") > (c-name "window_raised_p") > (file "window.c") > (line 750) ;;; I am totally making up that line number > (module (app scwm primitives)) ;; Let's pretend scwm primitive bindings will go there > ;; someday > (purpose "") ;; purpose line > (documentation "") ;; rest of docstring > ) > > Or: > > (concept > (name "Hooks") > (file "callbacks.c") > (line whatever) > (documentation "Blah blah blah")) > > > This way, all the parsing would get done, then the output stage would > just merge the pre-parsed files by reading them (they would be > trivially parseable) and generate appropriate output. As an added > bonus, the flat-text docstring database could be generated essentially > by concatenating all these .doc files, and the scheme docstring > reading code could trivially parse it, assuming that is the primary > goal of the flat-text file (maybe human-readability also counts?) That's basically already the structure of extract.scm. The function extract-docs-from-files does this. > Other improvements that, IMO need to be made to the doc extractor system > include: > > * Avoiding hardcoding the names of the output files or anything else > so it can be used for Guile, scwm, and potentially other apps or > modules. The Guile people especially want to start using this soon, > since documentation is now a top priority. (Incidentally, is everyone > who has contributed to the extractor willing and able to sign papaers > for this code?) I'm the only one who's written any code for extract.scm. I should be able to get an appropriate release. extract.scm takes output file names as arguments. The trickier part is making the parsing configurable (assuming that's necessary). The other tricky part is supplying the appropriate sgmlish structures for the chapters of the manual (assuming they'd be different from the scwm one). > * Handling the dynamically linked C modules. What's different for them? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Oct 31 23:15:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA00056 for scwm-discuss-outgoing; Sat, 31 Oct 1998 23:15:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA00050 for ; Sat, 31 Oct 1998 23:14:59 -0500 Received: from smtp6.nwnexus.com by MIT.EDU with SMTP id AA25225; Sat, 31 Oct 98 23:14:23 EST Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by smtp6.nwnexus.com (8.8.8/8.8.8) with ESMTP id UAA23976 for ; Sat, 31 Oct 1998 20:14:18 -0800 (PST) Received: from ken@localhost by pulsar.halcyon.com id <276516-271>; Sat, 31 Oct 1998 20:13:10 -0800 To: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 In-Reply-To: <199810292348.SAA02683@huis-clos.mit.edu> Date: Sat, 31 Oct 1998 20:13:02 -0800 From: Ken Pizzini Message-Id: <19981101041310Z276516-271+28@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk In <199810292348.SAA02683@huis-clos.mit.edu>, Maciej Stachowiak wrote: >Aye, there's the rub. It certainly doesn't confuse _me_ any more, but >I would expect a new person looking at the source to see a SCM_PROC >and think "I should figure out what this magic that comes before >declarations does" but look at a SCWM_PROC and think "What is this >crazy stuff? is this a function declaration or something?". Of course, >I have no data on which to base this, and I don't feel that strongly >about it. Indeed, my only significant (but still minor) concern is >consistency with other Guile apps, but that is not the world's biggest >deal. As I said, this is a side discussion. Perhaps adding a comment describing what SCWM_PROC is all about near its declaration in scwm/scwm-snarf.h is in order? (With a pointer to some further documentation, if it is felt to be necessary.) --Ken Pizzini From owner-scwm-discuss@mit.edu Sun Nov 1 05:02:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id FAA02948 for scwm-discuss-outgoing; Sun, 1 Nov 1998 05:02:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id FAA02945 for ; Sun, 1 Nov 1998 05:02:15 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA27518 for scwm-discuss@huis-clos.mit.edu; Sun, 1 Nov 1998 10:55:50 +0100 (MET) Received: (qmail 1221 invoked by uid 115); 31 Oct 1998 13:52:08 -0000 To: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 31 Oct 1998 14:52:03 +0100 In-Reply-To: Greg Badros's message of "30 Oct 1998 09:09:24 -0800" Message-ID: Lines: 31 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 30 Oct 1998 09:09:24 -0800 >>>>> Greg Badros said: Greg> CPAN has it, but I also just copied the Balanced.pm file onto Greg> my ftp site -- ftp.cs.washington.edu:/homes/gjb Indeed. I was just too dumb to find it on my first attempt. Greg> And I or someone else reliably checks in newly created Greg> versions. If perl on huis-clos is set-up appropriately, we could do this in the snapshot script (with mailing of errors to the developers, perhaps?). Greg> We should definitely provide an HTML distribution Greg> (separate .tar.gz file, methinks) of the docs with the next Greg> beta release. Generating the HTML is completely non-trivial. Yes. I have finally got a non-segfaulting jade on my system, after endless problems. Wow, scwm.html is 546 KB. One nit with the sgml output: There's a space missing after the full-stop of the first sentence in each documentation paragraph. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Nov 1 06:44:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA03372 for scwm-discuss-outgoing; Sun, 1 Nov 1998 06:44:55 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA03369 for ; Sun, 1 Nov 1998 06:44:52 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA24184; Sun, 1 Nov 98 06:44:41 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id GAA17927; Sun, 1 Nov 1998 06:44:41 -0500 Message-Id: <199811011144.GAA17927@M66-080-6.mit.edu> To: scwm-discuss@mit.edu Subject: Release schedule Date: Sun, 01 Nov 1998 06:44:41 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have resolved any outstanding legal issues about my scwm contributions, therefore I would like to plan a release ASAP. Unfortunately I am now leaving for a company conference and will not be back until the 5th. At that time, I will try to quickly integrate my changes and a couple more and release a beta; about a week after the beta, and after I (or others) have done test builds and runs on various systems, I'd like to put out the 0.9 release. I won't have a chance to read comments on this message until the 5th, but feel free to point out any outstanding key release issues. - Maciej From owner-scwm-discuss@mit.edu Sun Nov 1 11:56:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA04525 for scwm-discuss-outgoing; Sun, 1 Nov 1998 11:56:54 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA04522 for ; Sun, 1 Nov 1998 11:56:51 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA08487; Sun, 1 Nov 98 11:56:37 EST Received: (qmail 7747 invoked by uid 501); 1 Nov 1998 16:59:52 -0000 Message-Id: <19981101085951.A7718@molehill.org> Date: Sun, 1 Nov 1998 08:59:51 -0800 From: Todd Larason To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Tue Oct 27 15:55:11 EST 1998 References: <19981028120436.B11390@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Robert Bihlmeyer on Sat, Oct 31, 1998 at 02:52:03PM +0100 X-Tom-Swifty: "The symphony's finale is marked 'Presto'", said Tom with a quick movement. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981031, Robert Bihlmeyer wrote: > Yes. I have finally got a non-segfaulting jade on my system, after > endless problems. Wow, scwm.html is 546 KB. Did you compile this? Any hints for the rest of us? I'm still using Greg's magic working jade. From owner-scwm-discuss@mit.edu Sun Nov 1 13:02:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA04879 for scwm-discuss-outgoing; Sun, 1 Nov 1998 13:02:49 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA04876 for ; Sun, 1 Nov 1998 13:02:46 -0500 Received: from dantooine-1-22.mdm.mke.execpc.com by MIT.EDU with SMTP id AA22499; Sun, 1 Nov 98 13:02:30 EST Received: (qmail 446 invoked by uid 1000); 1 Nov 1998 18:11:03 -0000 Date: 1 Nov 1998 18:11:03 -0000 Message-Id: <19981101181103.445.qmail@debian.localdomain> From: pgarcia@execpc.com To: scwm-discuss@mit.edu Subject: scwm: quick bind-key question Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk When binding keys in fvwm, the X11 modifiers mod1 through mod5 could be specified before the keysym. How do you do this in scwm? (I'm sorry, I haven't looked at the code; I'm just going by the documentation in 0.8a; I'm not sure if what I want is possible in scwm yet, because of the note regarding emacs-style key identification.) Thanks, Phil Garcia From owner-scwm-discuss@mit.edu Sun Nov 1 13:56:04 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA05137 for scwm-discuss-outgoing; Sun, 1 Nov 1998 13:56:04 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA05131 for ; Sun, 1 Nov 1998 13:55:57 -0500 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA28271; Sun, 1 Nov 98 13:55:42 EST Received: from ZengHe.augustin.thierry (139.100.161.84 [139.100.161.84]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id VZR6BH6Z; Sun, 1 Nov 1998 19:55:41 +0100 Received: (from fare@localhost) by ZengHe.augustin.thierry (8.8.7/) id VAA06614; Sun, 1 Nov 1998 21:03:41 +0100 Message-Id: <19981101210339.A6559@ZengHe.issy.cnet.fr> Date: Sun, 1 Nov 1998 21:03:39 +0100 From: Francois-Rene Rideau To: owner-scwm-discuss@mit.edu, jimb@red-bean.com Cc: scwm-discuss@mit.edu Subject: Re: Next SCWM release Reply-To: Francois-Rene Rideau References: <199810300338.WAA06870@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: <199810300338.WAA06870@huis-clos.mit.edu>; from Maciej Stachowiak on Thu, Oct 29, 1998 at 10:38:22PM -0500 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.augustin.thierry id VAA06614 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by huis-clos.mit.edu id NAA05135 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Dear SCWM developers, I've upgraded my guile to 1.3, and my scwm to the 19981027 release char *szRepoLastChanged = "Sat Oct 24 13:23:49 EDT 1998 -- $Revision: 1.747 $"; with my somehow hacked scwmrc.gjb. A few remarks: * The default system.scwmrc still sucks. * when restarting scwm, it goes completely mad and (almost) all windows are being raised/showed in turn on the upper/topmost screen made current; after killing scwm and restarting, those windows are still all stacked on this screen, which is annoying (I then kill X, and let my xinitrc relaunch all my apps). ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## There cannot be Ethics without Models of possible behaviors, and Imagination to explore them. From owner-scwm-discuss@mit.edu Sun Nov 1 14:16:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA05289 for scwm-discuss-outgoing; Sun, 1 Nov 1998 14:16:48 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA05286 for ; Sun, 1 Nov 1998 14:16:45 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA23682; Sun, 1 Nov 98 14:16:32 EST Received: from salvor.dtek.chalmers.se (d4jonas@salvor.dtek.chalmers.se [129.16.30.118]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id UAA20783; Sun, 1 Nov 1998 20:16:29 +0100 (MET) Received: (from d4jonas@localhost) by salvor.dtek.chalmers.se (8.8.8/8.8.8) id UAA25266; Sun, 1 Nov 1998 20:16:28 +0100 (MET) To: pgarcia@execpc.com Cc: scwm-discuss@mit.edu Subject: Re: scwm: quick bind-key question References: <19981101181103.445.qmail@debian.localdomain> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 01 Nov 1998 20:16:28 +0100 In-Reply-To: pgarcia@execpc.com's message of "1 Nov 1998 18:11:03 -0000" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk pgarcia@execpc.com writes: > When binding keys in fvwm, the X11 modifiers mod1 through mod5 could > be specified before the keysym. How do you do this in scwm? (bind-key 'all "H-M-Up" (lambda () (move-pointer 0 (%y -1)))) H = hyper (Mod2 for me, bound to CapsLock with xmodmap) M = Meta Up = uparrow "C-up" is Control-uparrow etc. Hth. /Jonas, quite new to the list (one week) and currently (not) in lurkermode. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Mon Nov 2 03:25:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA01674 for scwm-discuss-outgoing; Mon, 2 Nov 1998 03:25:38 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA01671 for ; Mon, 2 Nov 1998 03:25:36 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA11982; Mon, 2 Nov 98 03:25:19 EST Received: (qmail 13402 invoked by uid 501); 2 Nov 1998 08:29:21 -0000 Message-Id: <19981102002920.A13355@molehill.org> Date: Mon, 2 Nov 1998 00:29:20 -0800 From: Todd Larason To: scwm-discuss list Subject: popup menus with default actions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I'll have a hot dog", said Tom frankly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have some menus (lists of hosts to log into) that I want on submenus, but within each submenu (class of machines), there's one item that is almost always the right choice. What I'd like is a menu that has a child popup AND an action, with the two being separate. I've implemented this, allowing hover-action to be a menu to popup, just like action currently is; I've left the meaning of action just like it is now; if both are menus, the action one rules. (define (menuitem-host machine) (menuitem (car machine) #:action (lambda () (xterm-on-host (cadr machine))))) (define menu-host-home (menu ; are there telnet servers for win95? Or MacOS (yeah right) (map menuitem-host '(("teeny" "teeny.priv.molehill.org") ("bitsy" "bitsy.priv.molehill.org") ("micro" "micro.priv.molehill.org") ("dot" "dot.priv.molehill.org") ("pico" "pico.priv.molehill.org") ("mini" "mini.priv.molehill.org") ("nano" "nano.priv.molehill.org"))))) ... (define menu-host (menu (list (menuitem "Home" #:action (lambda () (xterm-on-host "teeny.molehill.org")) #:hover-action 'menu-host-home) ...))) Does this seem clean enough to check in, or should I not steal Hover for this? Does anyone else even have any desire for this functionality? I'm not sure whether there are many things it would be useful for without being confusing. From owner-scwm-discuss@mit.edu Mon Nov 2 15:02:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA05667 for scwm-discuss-outgoing; Mon, 2 Nov 1998 15:02:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id PAA05664 for ; Mon, 2 Nov 1998 15:02:14 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA06912 for scwm-discuss@huis-clos.mit.edu; Mon, 2 Nov 1998 20:55:07 +0100 (MET) Received: (qmail 7917 invoked by uid 115); 1 Nov 1998 14:12:00 -0000 To: scwm-discuss@mit.edu Subject: Re: endian.h References: <199810301727.MAA12189@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 01 Nov 1998 15:11:57 +0100 Message-ID: Lines: 16 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 30 Oct 1998 12:27:17 EST >>>>> Maciej Stachowiak said: Maciej> I am pretty sure it has to be that way in order for IP to work. If you Maciej> tried to byteswap an IP address in a 64-bit wide field you would lose Maciej> totally. I removed references to endian.h, and rely on ntohl/htonl. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Nov 2 19:02:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA07149 for scwm-discuss-outgoing; Mon, 2 Nov 1998 19:02:57 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id TAA07146 for ; Mon, 2 Nov 1998 19:02:54 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id BAA14929 for scwm-discuss@huis-clos.mit.edu; Tue, 3 Nov 1998 01:00:29 +0100 (MET) Received: (qmail 1001 invoked by uid 115); 2 Nov 1998 20:55:48 -0000 To: scwm-discuss@mit.edu Subject: jade References: <19981028120436.B11390@molehill.org> <19981101085951.A7718@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 02 Nov 1998 21:55:45 +0100 In-Reply-To: Todd Larason's message of "Sun, 1 Nov 1998 08:59:51 -0800" Message-ID: Lines: 17 User-Agent: Gnus/5.07004 (Pterodactyl Gnus v0.40) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 1 Nov 1998 08:59:51 -0800 >>>>> Todd Larason said: Todd> Did you compile this? Any hints for the rest of us? There is a sgmltools 2.0 release (beta I think) on www.sgmltools.org. It contains a jade version that I ripped out (in fact you can seperately download the jade part) and compiled. It works now, while previous versions did not. I suspect it was bad glibc juju before. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Nov 3 06:22:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA12087 for scwm-discuss-outgoing; Tue, 3 Nov 1998 06:22:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mars.zserv.tuwien.ac.at (mars.zserv.tuwien.ac.at [193.170.75.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA12084 for ; Tue, 3 Nov 1998 06:22:12 -0500 Received: (qmail 8129 invoked by uid 524); 3 Nov 1998 11:21:40 -0000 To: scwm-discuss@mit.edu Subject: Missing colors while moving non-opaquely X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Nov 1998 12:21:38 +0100 Message-ID: Lines: 12 Organization: Tessier-Ashpool Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, when all colors are grabbed by color hogs like netscrape, and I try to move/resize a window non-opaquely, scwm fails to get the color for the rubberband, and will go into a catatonic state. Since the server was grabbed, X is not usable until I kill off scwm. Very bad. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Nov 3 06:25:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA12115 for scwm-discuss-outgoing; Tue, 3 Nov 1998 06:25:48 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mars.zserv.tuwien.ac.at (mars.zserv.tuwien.ac.at [193.170.75.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA12108 for ; Tue, 3 Nov 1998 06:25:35 -0500 Received: (qmail 8577 invoked by uid 524); 3 Nov 1998 11:25:25 -0000 To: scwm-discuss@mit.edu Subject: session management X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 03 Nov 1998 12:25:24 +0100 Message-ID: Lines: 15 Organization: Area 51 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, session management support kind of works. For clients that themselves have SM support, scwm will preserve window geometry across sessions. I will add more state information (iconification, which-desk, ...) as I go along. Support for non-SM-aware clients will also happen when I can iron out the bugs. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Nov 3 22:59:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA16024 for scwm-discuss-outgoing; Tue, 3 Nov 1998 22:59:28 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id WAA16021 for ; Tue, 3 Nov 1998 22:59:25 -0500 Received: from dessau.dai.comp.kyutech.ac.jp by MIT.EDU with SMTP id AA18181; Tue, 3 Nov 98 22:59:05 EST Received: by dai.comp.kyutech.ac.jp via sendmail from stdin id (Debian Smail3.2.0.101) for scwm-discuss@mit.edu; Wed, 4 Nov 1998 12:58:52 +0900 (JST) To: scwm-discuss@mit.edu Subject: modules/pie-menus/draw-pie-menu.c with --enable-multibyte From: Shuji Narazaki Date: 04 Nov 1998 12:58:52 +0900 Message-Id: <87btmoglc3.fsf@dessau.dai.comp.kyutech.ac.jp> Lines: 25 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Please apply the following patch to the snapshot. I fail to compile draw-pie-menu.c (in recent snapshots), if scwm is configured with --enable-multibyte . regards, --- draw-pie-menu.c.original Wed Oct 28 16:27:10 1998 +++ draw-pie-menu.c Wed Nov 4 12:44:27 1998 @@ -455,8 +455,9 @@ if (pmi->szLabel) { #ifdef I18N XmbDrawString(dpy, w, scfont->fontset, currentGC, - x_offset,y_offset + label_font_height + cpixExtraYOffset, - pmi->szLabel, pmi->cchLabel); + label_x_offset, + label_y_offset + label_font_height + cpixExtraYOffset, + pmi->szLabel, pmi->cchLabel); #else XDrawString(dpy, w, currentGC, label_x_offset, -- Shuji NARAZAKI From owner-scwm-discuss@mit.edu Tue Nov 3 23:11:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id XAA16314 for scwm-discuss-outgoing; Tue, 3 Nov 1998 23:11:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id XAA16311 for ; Tue, 3 Nov 1998 23:11:17 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA20415; Tue, 3 Nov 98 23:10:56 EST Received: (qmail 27931 invoked by uid 501); 4 Nov 1998 04:10:55 -0000 Message-Id: <19981103201055.A27888@molehill.org> Date: Tue, 3 Nov 1998 20:10:55 -0800 From: Todd Larason To: Shuji Narazaki , scwm-discuss@mit.edu Subject: Re: modules/pie-menus/draw-pie-menu.c with --enable-multibyte References: <87btmoglc3.fsf@dessau.dai.comp.kyutech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <87btmoglc3.fsf@dessau.dai.comp.kyutech.ac.jp>; from Shuji Narazaki on Wed, Nov 04, 1998 at 12:58:52PM +0900 X-Tom-Swifty: "Give me some Chinese food", said Tom wantonly. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981104, Shuji Narazaki wrote: > Hi, > > Please apply the following patch to the snapshot. I fail to compile > draw-pie-menu.c (in recent snapshots), if scwm is configured with > --enable-multibyte . Thanks! I've checked this in, it should make tonight's snapshot. From owner-scwm-discuss@mit.edu Wed Nov 4 09:28:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA01005 for scwm-discuss-outgoing; Wed, 4 Nov 1998 09:28:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA01002 for ; Wed, 4 Nov 1998 09:28:54 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id PAA18922 for scwm-discuss@huis-clos.mit.edu; Wed, 4 Nov 1998 15:03:04 +0100 (MET) Received: (qmail 780 invoked by uid 115); 4 Nov 1998 13:56:41 -0000 To: scwm-discuss@mit.edu Subject: Session Management - Addendum X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 04 Nov 1998 14:56:37 +0100 Message-ID: Lines: 13 X-Now-Playing: 06 - Audio X Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, I forgot to inform you that I placed a small Q&A text regarding SM under "doc/session-management". Robbe P.S.: Does anyone know of a good way to write an arbitrary scheme object (ScwmWindow's other_properties in my case) to a file? -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Nov 4 12:53:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA01834 for scwm-discuss-outgoing; Wed, 4 Nov 1998 12:53:42 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA01831 for ; Wed, 4 Nov 1998 12:53:40 -0500 Received: from CHOPIN.CHEM.CMU.EDU by MIT.EDU with SMTP id AA00848; Wed, 4 Nov 98 12:53:36 EST Received: from localhost (localhost [127.0.0.1]) by chopin.chem.cmu.edu (8.9.1a/8.9.1) with SMTP id MAA03585 for ; Wed, 4 Nov 1998 12:53:45 -0500 (EST) Message-Id: <199811041753.MAA03585@chopin.chem.cmu.edu> X-Authentication-Warning: chopin.chem.cmu.edu: localhost [127.0.0.1] didn't use HELO protocol To: scwm-discuss@mit.edu X-Attribution: Eric Subject: small patch to window.c Date: Wed, 04 Nov 1998 12:53:45 -0500 From: Eric Moore Sender: owner-scwm-discuss@mit.edu Precedence: bulk I use the -name Xt option on a lot of windows to change their .Xresources and the like, so I thouught it'd be nice to have access to the window name as well as class in scwm. Patch to window.c out of current CVS follows :) Index: window.c =================================================================== RCS file: /anoncvs/scwm/scwm/window.c,v retrieving revision 1.169 diff -u -r1.169 window.c --- window.c 1998/10/24 16:55:16 1.169 +++ window.c 1998/11/04 17:50:57 @@ -2754,6 +2754,18 @@ } #undef FUNC_NAME +SCWM_PROC(window_name, "window-name", 0, 1, 0, + (SCM win)) + /** Return the window resource name of WIN. +WIN defaults to the window context in the usual way if not +specified. */ +#define FUNC_NAME s_window_name +{ + VALIDATE(win, FUNC_NAME); + return gh_str02scm(PSWFROMSCMWIN(win)->classhint.res_name); +} +#undef FUNC_NAME + SCWM_PROC(window_resource, "window-resource", 0, 1, 0, (SCM win)) From owner-scwm-discuss@mit.edu Fri Nov 6 19:58:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA19845 for scwm-discuss-outgoing; Fri, 6 Nov 1998 19:58:55 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA19837; Fri, 6 Nov 1998 19:58:48 -0500 Message-Id: <199811070058.TAA19837@huis-clos.mit.edu> To: Eric Moore cc: scwm-discuss@mit.edu Subject: Re: small patch to window.c In-reply-to: Your message of "Wed, 04 Nov 1998 12:53:45 EST." <199811041753.MAA03585@chopin.chem.cmu.edu> Date: Fri, 06 Nov 1998 19:58:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk moore@chem.cmu.edu writes: > I use the -name Xt option on a lot of windows to change their > .Xresources and the like, so I thouught it'd be nice to have access to > the window name as well as class in scwm. Patch to window.c out of > current CVS follows :) > `window-resource' (ironically just below the point you patched :-) does this already. It returns what is called the "resource instance" in most places in the code. However, your post makes clear that there is a naming and documentation issue with `window-class' and `window-resource'. - Maciej PS I had no idea that "resource name" == "resource instance", in fact I would have automatically applied this patch if I hadn't wondered why windows needed to have each of a resource class, instance and name and thus looked at the source. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 10 12:39:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA13118 for scwm-discuss-outgoing; Tue, 10 Nov 1998 12:39:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA13115 for ; Tue, 10 Nov 1998 12:39:33 -0500 Received: from king.halcyon.com by MIT.EDU with SMTP id AA26428; Tue, 10 Nov 98 12:38:42 EST Received: from pulsar.halcyon.com (ken@halcyon.com [198.137.231.20]) by king.halcyon.com (8.8.8/8.8.8) with ESMTP id JAA10254 for ; Tue, 10 Nov 1998 09:38:43 -0800 Received: from ken@localhost by pulsar.halcyon.com id <276516-384>; Tue, 10 Nov 1998 09:35:54 -0800 To: scwm-discuss@mit.edu Subject: problem in current flux.scm Date: Tue, 10 Nov 1998 09:35:50 -0800 From: Ken Pizzini Message-Id: <19981110173554Z276516-384+3@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk The current version of flux.scm (at least on the anoncvs server) is broken --- the define of netscape-new-window is never finished. Attached is the simple-minded patch I made so that I can get my scwm running again; it should at least show where a fix is needed. --Ken Pizzini --- scwm/scheme/flux.scm-orig Tue Nov 10 08:48:00 1998 +++ scwm/scheme/flux.scm Tue Nov 10 09:28:20 1998 @@ -643,8 +643,8 @@ (get-mozilla-hook) #t)) -(define-public netscape-new-window #f - "`netscape-goto-cut-buffer-url' will open the URL in a new window." +;(define-public netscape-new-window #f +; "`netscape-goto-cut-buffer-url' will open the URL in a new window." (define*-public (netscape-goto-cut-buffer-url #&optional (new netscape-new-window)) From owner-scwm-discuss@mit.edu Tue Nov 10 13:04:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA13383 for scwm-discuss-outgoing; Tue, 10 Nov 1998 13:04:57 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA13380 for ; Tue, 10 Nov 1998 13:04:56 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA05086; Tue, 10 Nov 98 13:03:58 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA15344; Tue, 10 Nov 1998 10:03:59 -0800 (PST) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: Re: problem in current flux.scm References: <19981110173554Z276516-384+3@pulsar.halcyon.com> From: Greg Badros Date: 10 Nov 1998 10:03:59 -0800 In-Reply-To: Ken Pizzini's message of "Tue, 10 Nov 1998 09:35:50 -0800" Message-Id: Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > The current version of flux.scm (at least on the anoncvs server) > is broken --- the define of netscape-new-window is never finished. > Attached is the simple-minded patch I made so that I can get my > scwm running again; it should at least show where a fix is needed. I just committed the (hopefully) right fix, using the ;;;**VAR comment docstring style as I'd done before in, e.g., base.scm. Thanks for catchiing this. Greg From owner-scwm-discuss@mit.edu Wed Nov 11 11:54:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA21950 for scwm-discuss-outgoing; Wed, 11 Nov 1998 11:54:44 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id LAA21947 for ; Wed, 11 Nov 1998 11:54:41 -0500 Received: from rukbat.cs.unc.edu (rukbat.cs.unc.edu [152.2.133.170]) by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id LAA24457 for ; Wed, 11 Nov 1998 11:53:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by rukbat.cs.unc.edu (8.8.8/8.8.8) with SMTP id LAA07770 for ; Wed, 11 Nov 1998 11:53:43 -0500 (EST) Date: Wed, 11 Nov 1998 11:53:42 -0500 (EST) From: Stephen Tell To: SCWM Discussion List Subject: problems building scwm-19981111 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I managed to break my trusty old scwm-0.7a binary by cleaning up some shared libraries, so I tried building the current snapshot. 1. configure blew it trying to test for guile features, which I traced to this in configure.in: if test "NONE" = "$exec_prefix"; then guile_lib_path="$ac_default_prefix/lib" else guile_lib_path="$exec_prefix/lib" fi I was specfiying a --prefix but not a --exec_prefix, so this code caused this message and link line for the AC_CHECK_LIB(guile,...) tests checking for guile libraries... -L/usr/local/lib -L/home/msl/tell/hp/lib -lguile -lreadline -ltermcap -lm In /usr/local/lib was an ancient libreadline.a, causing all of the guile lib feature test compiles to fail. 2. I don't seem to have (complete or working) X11 session management stuff. Configure found a libX11SM.a anyway, but there's no X11/SM/SMlib.h. (More accurately, our /usr/local/include/X11R6 is fouled up). This configure.in patch appears to do the right thing for me, but apply it with a serious grain of salt, since I'm not sure what other issues there are here. *** configure.in.orig Sat Oct 24 12:24:51 1998 --- configure.in Wed Nov 11 11:51:41 1998 *************** *** 51,57 **** guile_lib_path="" if test "NONE" = "$exec_prefix"; then ! guile_lib_path="$ac_default_prefix/lib" else guile_lib_path="$exec_prefix/lib" fi --- 51,61 ---- guile_lib_path="" if test "NONE" = "$exec_prefix"; then ! if test "NONE" = "$prefix"; then ! guile_lib_path="$ac_default_prefix/lib" ! else ! guile_lib_path="$prefix/lib" ! fi else guile_lib_path="$exec_prefix/lib" fi *************** *** 212,223 **** SESSION_MANAGER_OBJECTS="" AC_CHECK_LIB(SM, SmcOpenConnection, [ ! AC_CHECK_LIB(ICE, IceAddConnectionWatch, [ ! SM_LIB="-lSM -lICE" ! SESSION_MANAGER_OBJECTS='$(session_manager_objs)' ! AC_DEFINE(HAVE_LIBSM_LIBICE) ! ], AC_MSG_WARN(libICE not found -- no session manager support) ! , $x_libs) ], AC_MSG_WARN(libSM not found -- no session manager support) , $x_libs) --- 216,229 ---- SESSION_MANAGER_OBJECTS="" AC_CHECK_LIB(SM, SmcOpenConnection, [ ! AC_CHECK_HEADERS(X11/SM/SMlib.h, [ ! AC_CHECK_LIB(ICE, IceAddConnectionWatch, [ ! SM_LIB="-lSM -lICE" ! SESSION_MANAGER_OBJECTS='$(session_manager_objs)' ! AC_DEFINE(HAVE_LIBSM_LIBICE) ! ], AC_MSG_WARN(libICE not found -- no session manager support) ! , $x_libs) ! ], AC_MSG_WARN(SMlib.h not found -- no session manager support)) ], AC_MSG_WARN(libSM not found -- no session manager support) , $x_libs) -- Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF Research Associate, Microelectronic Systems Laboratory Computer Science Department, UNC@Chapel Hill. W:919-962-1845 From owner-scwm-discuss@mit.edu Wed Nov 11 12:40:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22203 for scwm-discuss-outgoing; Wed, 11 Nov 1998 12:40:01 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22196 for ; Wed, 11 Nov 1998 12:40:00 -0500 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Wed, 11 Nov 1998 17:38:41 +0000 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 35; Wed, 11 Nov 1998 17:38:22 GMT Date: Wed, 11 Nov 1998 17:38:22 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CF122.8A9DC5C0.35@hermes.dra.hmg.gb> Subject: Pie Menus with Titles Sender: owner-scwm-discuss@mit.edu Precedence: bulk Pie menus are great; I am using one as submenu for moving windows between desks. If I have a title, an extra slice is created for it, which is not quite what I had in mind. Is it possible to have a title, but no associated slice? Julian Satchell From owner-scwm-discuss@mit.edu Wed Nov 11 12:40:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22201 for scwm-discuss-outgoing; Wed, 11 Nov 1998 12:40:01 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22193 for ; Wed, 11 Nov 1998 12:39:59 -0500 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Wed, 11 Nov 1998 17:35:19 +0000 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 18; Wed, 11 Nov 1998 17:35:07 GMT Date: Wed, 11 Nov 1998 17:35:06 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CF122.15F59360.18@hermes.dra.hmg.gb> Subject: CVSWEB Broken??? Sender: owner-scwm-discuss@mit.edu Precedence: bulk At least for me Cvsweb (both old and new) have stopped working. hey were great. Julian Satchell From owner-scwm-discuss@mit.edu Wed Nov 11 15:13:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA23561 for scwm-discuss-outgoing; Wed, 11 Nov 1998 15:13:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA23555; Wed, 11 Nov 1998 15:13:27 -0500 Message-Id: <199811112013.PAA23555@huis-clos.mit.edu> To: "merry::satchell"@hermes.dra.hmg.gb cc: scwm-discuss@mit.edu Subject: Re: CVSWEB Broken??? In-reply-to: Your message of "Wed, 11 Nov 1998 17:35:06 GMT." <009CF122.15F59360.18@hermes.dra.hmg.gb> Date: Wed, 11 Nov 1998 15:13:27 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > At least for me Cvsweb (both old and new) have stopped working. > hey were great. > The web server machine crashed a while ago and messed up the disk a bit, I've forgotten to fix cvsweb since. I will put them back RSN. I have been hosed at work this week, but I'm going to try to devote a lot of time to scwm this weekend, I really want to get things in shape for a beta and a release. To those of you who recently submitted various bug reports, I will make sure to go over them before making a final 0.9 release. (Some things might still be broken in the first beta). - Maciej From owner-scwm-discuss@mit.edu Wed Nov 11 18:39:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA24695 for scwm-discuss-outgoing; Wed, 11 Nov 1998 18:39:20 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA24692 for ; Wed, 11 Nov 1998 18:39:16 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA05120; Wed, 11 Nov 98 18:38:21 EST Received: (qmail 17409 invoked by uid 501); 11 Nov 1998 23:38:16 -0000 Message-Id: <19981111153816.A17339@molehill.org> Date: Wed, 11 Nov 1998 15:38:16 -0800 From: Todd Larason To: "merry::satchell"@hermes.dra.hmg.gb, scwm-discuss@mit.edu Subject: Re: Pie Menus with Titles References: <009CF122.8A9DC5C0.35@hermes.dra.hmg.gb> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <009CF122.8A9DC5C0.35@hermes.dra.hmg.gb>; from "merry::satchell"@hermes.dra.hmg.gb on Wed, Nov 11, 1998 at 05:38:22PM +0000 X-Tom-Swifty: "I meant to pay this year's dues", Tom remembered. X-Kibo: If you want to engulf the shape of everything, relax. X-Kibo: Relaxation makes sense. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981111, "merry::satchell"@hermes.dra.hmg.gb wrote: > Pie menus are great; I am using one as submenu for moving windows between > desks. If I have a title, an extra slice is created for it, which is not > quite what I had in mind. Is it possible to have a title, but no associated > slice? Not yet, but it's planned. I'll probably get this finished up next week. The old menu styles treat a title as just another menu item; I think I've finished the framework for separating it out, but 1) the menu scheme code doesn't support it yet and 2) no menu styles will display the new-style titles yet. From owner-scwm-discuss@mit.edu Thu Nov 12 03:06:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA29701 for scwm-discuss-outgoing; Thu, 12 Nov 1998 03:06:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id DAA29697 for ; Thu, 12 Nov 1998 03:06:07 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id IAA02096 for scwm-discuss@huis-clos.mit.edu; Thu, 12 Nov 1998 08:55:49 +0100 (MET) Received: (qmail 1161 invoked by uid 115); 11 Nov 1998 21:57:09 -0000 To: scwm-discuss@mit.edu Subject: Re: Pie Menus with Titles References: <009CF122.8A9DC5C0.35@hermes.dra.hmg.gb> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 11 Nov 1998 22:57:09 +0100 In-Reply-To: "merry::satchell"@hermes.dra.hmg.gb's message of "Wed, 11 Nov 1998 17:38:22 GMT" Message-ID: Lines: 16 User-Agent: Gnus/5.070042 (Pterodactyl Gnus v0.42) XEmacs/20.4 (Emerald) X-Now-Playing: 08 Babylon System Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 11 Nov 1998 17:38:22 GMT >>>>> "merry::satchell"@hermes.dra.hmg.gb said: Julian> Is it possible to have a title, but no associated Julian> slice? I think putting the title in the hub of the wheel would make a good display. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Nov 12 03:48:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA30797 for scwm-discuss-outgoing; Thu, 12 Nov 1998 03:48:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA30794 for ; Thu, 12 Nov 1998 03:48:49 -0500 Received: from scam.XCF.Berkeley.EDU by MIT.EDU with SMTP id AA05589; Thu, 12 Nov 98 03:47:51 EST Received: (qmail 20143 invoked from network); 12 Nov 1998 08:49:18 -0000 Received: from ip222.san-francisco22.ca.pub-ip.psi.net (HELO yasmeen) (38.28.60.222) by scam.xcf.berkeley.edu with SMTP; 12 Nov 1998 08:49:18 -0000 Message-Id: <014201be0e18$4cfc4e00$de3c1c26@yasmeen.citycom.com> From: "Jason Nordwick" To: Subject: An extra SICP anybody? Date: Thu, 12 Nov 1998 00:41:53 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am looking for any extra copies of SICP for people wanting to learn Scheme and also get a good CS intro at the same time. I bought the newest version and had somebody ask me about my old one, so I gave it to them. Since them I have had about 4 more requests for my copy (that I had already given away). So, if anybody can part with an extra copy for the greater good of the language and CS in general, please message me. Thanks. jay -- 4.4 > 98 http://www.xcf.berkeley.edu From owner-scwm-discuss@mit.edu Thu Nov 12 08:14:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id IAA31984 for scwm-discuss-outgoing; Thu, 12 Nov 1998 08:14:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay.mod.uk (relay.mod.uk [192.5.29.50]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id IAA31978 for ; Thu, 12 Nov 1998 08:13:59 -0500 From: "merry::satchell"@hermes.dra.hmg.gb Received: from hermes.dra.hmg.gb by relay.mod.uk with local SMTP id ; Thu, 12 Nov 1998 13:12:34 +0000 Received: by hermes.dra.hmg.gb (MX V4.2 VAX) id 2; Thu, 12 Nov 1998 13:11:15 GMT Date: Thu, 12 Nov 1998 13:11:13 GMT To: scwm-discuss@mit.edu X-VMSmail-To: HERMES::MX%"scwm-discuss@huis-clos.mit.edu" Message-ID: <009CF1C6.62D97760.2@hermes.dra.hmg.gb> Subject: SCWM crash on repeated Map requests. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I enclose a gdb stack trace of scwm after its most recent crash, triggered by a programme which may have been trying to map an already mapped window. Linux 2.0.30 egcs 1.1b Scwm Version post0.8a compiled on Nov 4 1998 at 18:49:14 RCS_ID=$Id: scwm.c,v 1.146 1998/10/27 13:49:46 robbe Exp $ Repository Timestamp: Tue Nov 3 23:10:39 EST 1998 -- $Revision: 1.786 $ Core was generated by `scwm'. Program terminated with signal 11, Segmentation fault. #0 0x4012b63b in scm_send () at socket.c:508 508 } #0 0x4012b63b in scm_send () at socket.c:508 #1 0x4010d6b5 in scm_gsubr_apply () at gsubr.c:156 #2 0x40104776 in scm_dapply () at eval.c:3232 #3 0x401039ac in scm_deval () at eval.c:3232 #4 0x401049bb in scm_dapply () at eval.c:3232 #5 0x400ffdf5 in scm_apply () at eval.c:1236 #6 0x40132b22 in scm_body_thunk () at throw.c:364 #7 0x401327be in scm_internal_catch () at throw.c:134 #8 0x40132de5 in scm_catch () at throw.c:500 #9 0x40103f09 in scm_deval () at eval.c:3232 #10 0x401049bb in scm_dapply () at eval.c:3232 #11 0x400ffdf5 in scm_apply () at eval.c:1236 #12 0x4010cbda in gh_apply () at gh_funcs.c:169 #13 0x80624da in scwm_body_apply (body_data=0xbfffefe8) at callbacks.c:84 #14 0x401329ac in scm_internal_lazy_catch () at throw.c:300 #15 0x40132aa8 in cwss_body () at throw.c:363 #16 0x401327be in scm_internal_catch () at throw.c:134 #17 0x40132af0 in scm_internal_stack_catch () at throw.c:364 #18 0x80624fc in cwssdr_body (data=0xbfffefb8) at callbacks.c:110 #19 0x401327be in scm_internal_catch () at throw.c:134 #20 0x401286bb in scm_internal_cwdr () at root.c:244 #21 0x8062538 in scm_internal_stack_cwdr (body=0x80624c8 , body_data=0xbfffefe8, handler=0x80623f0 , handler_data=0x8098876, stack_item=0xbfffefe4) at callbacks.c:126 #22 0x8062572 in scwm_safe_apply (proc=1076905616, args=1078540248) at callbacks.c:141 #23 0x8062a08 in apply_hooks (hook=1076392000, args=1078540248) at callbacks.c:403 #24 0x8071645 in Broadcast (event_type=1, num_datum=5, data1=0, data2=0, data3=0, data4=2048, data5=1536, data6=0, data7=0) at module-interface.c:43 #25 0x80780cc in MoveViewport_internal (newx=0, newy=0, grab=0) at virtual.c:382 #26 0x805c7e8 in ChangeVirtualPosition (vx=0, vy=0, fGrab=0) at add_window.c:105 #27 0x8078140 in MoveViewport (newx=0, newy=0, grab=0) at virtual.c:403 #28 0x807717f in Done (restart_or_dump=-1, command=0x0) at shutdown.c:75 #29 0x8076df4 in SigDoneSegv (nonsense=11) at scwm.c:1295 #30 0xbffff19c in ?? () #31 0x4010d6b5 in scm_gsubr_apply () at gsubr.c:156 #32 0x40104776 in scm_dapply () at eval.c:3232 #33 0x401039ac in scm_deval () at eval.c:3232 #34 0x401049bb in scm_dapply () at eval.c:3232 #35 0x400ffdf5 in scm_apply () at eval.c:1236 #36 0x40132b22 in scm_body_thunk () at throw.c:364 #37 0x401327be in scm_internal_catch () at throw.c:134 #38 0x40132de5 in scm_catch () at throw.c:500 #39 0x40103f09 in scm_deval () at eval.c:3232 #40 0x401049bb in scm_dapply () at eval.c:3232 #41 0x400ffdf5 in scm_apply () at eval.c:1236 #42 0x4010cbda in gh_apply () at gh_funcs.c:169 #43 0x80624da in scwm_body_apply (body_data=0xbffff74c) at callbacks.c:84 #44 0x401329ac in scm_internal_lazy_catch () at throw.c:300 #45 0x40132aa8 in cwss_body () at throw.c:363 #46 0x401327be in scm_internal_catch () at throw.c:134 #47 0x40132af0 in scm_internal_stack_catch () at throw.c:364 #48 0x80624fc in cwssdr_body (data=0xbffff71c) at callbacks.c:110 #49 0x401327be in scm_internal_catch () at throw.c:134 #50 0x401286bb in scm_internal_cwdr () at root.c:244 #51 0x8062538 in scm_internal_stack_cwdr (body=0x80624c8 , body_data=0xbffff74c, handler=0x80623f0 , handler_data=0x8098876, stack_item=0xbffff748) at callbacks.c:126 #52 0x8062572 in scwm_safe_apply (proc=1076905616, args=1078549456) at callbacks.c:141 #53 0x8062a08 in apply_hooks (hook=1076392000, args=1078549456) at callbacks.c:403 #54 0x8071645 in Broadcast (event_type=64, num_datum=5, data1=16777229, data2=37748935, data3=135908760, data4=65535, data5=50712, data6=0, data7=0) at module-interface.c:43 #55 0x806776e in HandleFocusIn () at events.c:361 #56 0x8067389 in DispatchEvent () at events.c:195 #57 0x80673ba in HandleEvents () at events.c:217 #58 0x80765f4 in scwm_main (argc=1, argv=0xbffffd08) at scwm.c:960 #59 0x8075a45 in scwm_gh_launch_pad (closure=0x8075a88, argc=1, argv=0xbffffd08) at scwm.c:432 #60 0x4010f151 in invoke_main_func (body_data=0xbffffcac) at init.c:538 #61 0x401327be in scm_internal_catch () at throw.c:134 #62 0x4010f100 in scm_boot_guile_1 (base=0xbffffca8, closure=0xbffffcac) at init.c:512 #63 0x4010eea5 in scm_boot_guile () at init.c:277 #64 0x8075a65 in scwm_gh_enter (argc=1, argv=0xbffffd08, c_main_prog=0x8075a88 ) at scwm.c:439 #65 0x8075a81 in main (argc=1, argv=0xbffffd08) at scwm.c:451 #66 0x805c58e in ___crt_dummy__ () Julian Satchell From owner-scwm-discuss@mit.edu Fri Nov 13 20:15:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05524 for scwm-discuss-outgoing; Fri, 13 Nov 1998 20:15:39 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05520; Fri, 13 Nov 1998 20:15:38 -0500 Message-Id: <199811140115.UAA05520@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: squashed-title Date: Fri, 13 Nov 1998 20:15:38 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just tried this for the first time and it's pretty cool. One shortcoming I noticed: the width of the titlebar won't change when the title text does. Intentional design choice or oversight? - Maciej From owner-scwm-discuss@mit.edu Fri Nov 13 20:27:27 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05698 for scwm-discuss-outgoing; Fri, 13 Nov 1998 20:27:27 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05690 for ; Fri, 13 Nov 1998 20:27:25 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27979; Fri, 13 Nov 98 20:27:30 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA29511; Fri, 13 Nov 1998 17:27:22 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: squashed-title References: <199811140115.UAA05520@huis-clos.mit.edu> From: Greg Badros Date: 13 Nov 1998 17:27:22 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 13 Nov 1998 20:15:38 EST" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I just tried this for the first time and it's pretty cool. One > shortcoming I noticed: the width of the titlebar won't change when the > title text does. Intentional design choice or oversight? Oversight/bug. The problems I know of: Squashed titlebar problems they should resize (width) when title changes, but they don't they should take effect immediately, but require a window resize to notice (can fix this with using set-window-property) they don't have an extra thin border line drawn in the rest of the title bar area to the right of the squashed titlebar it'd also be nice if they could be squashed to the right, or centered, instead of always only left-justified. I just added these to BUGS so that they're there for all to see. Greg From owner-scwm-discuss@mit.edu Sat Nov 14 14:35:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA14086 for scwm-discuss-outgoing; Sat, 14 Nov 1998 14:35:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA14081; Sat, 14 Nov 1998 14:35:00 -0500 Message-Id: <199811141935.OAA14081@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Merged image package Date: Sat, 14 Nov 1998 14:35:00 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've been talking to the fvwm people about setting up a merged package of window manager images, which would contain textures, tiles, icons and mini-icons. Initially, we'd take the images that have at historically shipped with fvwm or the scwm-icons package and remove the redundancies. Also, the install location and process would be much more sane than for the current scwm-icons and fvwm stuff. This would become the icon package that scwm users and fvwm users are pointed to. I wanted to get some feedback from this list on this idea. I can't think of a reason not to do it (shipping different but overlapping images with every window manager in the world is pretty stupid, IMO), but maybe some people feel otherwise. If there is a consensus that this is a good idea, I will try to set up the administrative details. - Maciej From owner-scwm-discuss@mit.edu Sat Nov 14 15:01:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA14418 for scwm-discuss-outgoing; Sat, 14 Nov 1998 15:01:28 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA14415 for ; Sat, 14 Nov 1998 15:01:08 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA00254; Sat, 14 Nov 98 15:00:50 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id PAA05584; Sat, 14 Nov 1998 15:00:45 -0500 Message-Id: <199811142000.PAA05584@w20-575-39.mit.edu> To: scwm-discuss@mit.edu Subject: Fixme comment changes suggested Date: Sat, 14 Nov 1998 15:00:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Our current fixme comment format is annoying in that you only mark who a fixme comment is from or who it is for, but not both. I suggest: /* :FIXME:: */ For example: /* MS:FIXME:: Review this comment format. */ Or (to put words in Greg's mouth): /* GJB:FIXME:MS: Why is this code so boneheaded, Maciej? */ This way a developer can easily grep for fixme comments he wrote, or fixme comments addressed to him. Also, FIXME is a more standard string for fixme comments and therefore more likely to be found by random others looking for them. If people agree this is a good move, I will at some point convert all old comments and document the new format in doc/dev. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sat Nov 14 19:37:24 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA30636 for scwm-discuss-outgoing; Sat, 14 Nov 1998 19:37:24 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id TAA30633 for ; Sat, 14 Nov 1998 19:37:22 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sat, 14 Nov 1998 19:36:42 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sat, 14 Nov 1998 19:36:41 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id UAA01404; Sat, 14 Nov 1998 20:36:11 -0500 To: Maciej Stachowiak Subject: crash Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 14 Nov 1998 20:36:11 -0500 Message-ID: Lines: 74 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I get a very stable crash when trying to run a particular client. Program received signal SIGSEGV, Segmentation fault. 0x807743d in getWindowClientId (psw=0x80f3858) at session-manager.c:118 118 else if (psw->wmhints->flags & WindowGroupHint) (gdb) where #0 0x807743d in getWindowClientId (psw=0x80f3858) at session-manager.c:118 #1 0x80775fe in restoreWindowState (psw=0x80f3858) at session-manager.c:186 #2 0x8054a5e in AddWindow (w=96468994) at add_window.c:282 #3 0x8060034 in HandleMapRequestKeepRaised (KeepRaised=0) at events.c:894 #4 0x805ffe2 in HandleMapRequest () at events.c:875 #5 0x805f0ed in DispatchEvent () at events.c:195 #6 0x805f11d in HandleEvents () at events.c:217 #7 0x806dd5d in scwm_main (argc=1, argv=0xbffff7f0) at scwm.c:984 #8 0x40117a13 in gh_call3 () #9 0x40119bae in scm_boot_guile () #10 0x4013d135 in scm_internal_lazy_catch () #11 0x40119b5f in scm_boot_guile () #12 0x40119915 in scm_boot_guile () #13 0x40117a41 in gh_enter () #14 0x806d2fb in main (argc=1, argv=0xbffff7f0) at scwm.c:462 (gdb) p *psw $1 = {next = 0x0, prev = 0x0, w = 96468994, old_bw = 0, frame = 0, Parent = 0, title_w = 0, sides = {0, 0, 0, 0}, corners = {0, 0, 0, 0}, nr_left_buttons = 3, nr_right_buttons = 2, left_w = {1, 1, 1, 1, 1}, right_w = {0, 1, 1, 1, 1}, fl = 0x80854e8, icon_w = 0, icon_pixmap_w = 0, fShaped = 0, frame_x = 0, frame_y = 0, frame_width = 0, frame_height = 0, pswci = 0x0, boundary_width = 0, xboundary_width = 0, corner_width = 0, bw = 0, title_x = 0, title_y = 0, title_height = 16, title_width = 0, icon_x_loc = 0, icon_xl_loc = 0, icon_y_loc = 0, icon_w_width = 0, icon_w_height = 0, icon_t_width = 0, icon_p_height = 0, icon_p_width = 0, name = 0x80ed9e8 "The Ace of Penguins - freecell", icon_name = 0x0, attr = { x = 0, y = 0, width = 638, height = 464, border_width = 0, depth = 16, visual = 0x80a4438, root = 38, class = 1, bit_gravity = 0, win_gravity = 1, backing_store = 0, backing_planes = 4294967295, backing_pixel = 0, save_under = 0, colormap = 35, map_installed = 1, map_state = 0, all_event_masks = 41101, your_event_mask = 0, do_not_propagate_mask = 0, override_redirect = 0, screen = 0x80a43e0}, hints = {flags = 0, x = 0, y = 0, width = 0, height = 0, min_width = 0, min_height = 0, max_width = 0, max_height = 0, width_inc = 0, height_inc = 0, min_aspect = {x = 0, y = 0}, max_aspect = {x = 0, y = 0}, base_width = 0, base_height = 0, win_gravity = 0}, wmhints = 0x0, classhint = {res_name = 0x8083d41 "NoResource", res_class = 0x8083d39 "NoClass"}, Desk = 0, StartDesk = 0, FocusDesk = 0, DeIconifyDesk = 0, transientfor = 0, ttLastFocussed = 911093493, fStartIconic = 0, fOnTop = 0, fSticky = 0, fWindowListSkip = 0, fSuppressIcon = 0, fNoIconTitle = 0, fLenience = 0, fStickyIcon = 0, fCirculateSkip = 0, fCirculateSkipIcon = 0, fClickToFocus = 0, fSloppyFocus = 0, fShowOnMap = 0, fBorder = 0, fTitle = 1, fMapped = 0, fIconified = 0, fTransient = 0, fRaised = 0, fVisible = 0, fIconOurs = 0, fPixmapOurs = 0, fShapedIcon = 0, fMaximized = 0, fDoesWmTakeFocus = 0, fDoesWmDeleteWindow = 1, fIconMoved = 0, fIconUnmapped = 0, fMapPending = 0, fHintOverride = 0, fMWMButtons = 0, fMWMBorders = 0, fMWMFunctions = 1, fMWMDecor = 1, fDecorateTransient = 1, fWindowShaded = 0, fStartsOnDesk = 0, fRandomPlace = 1, fSmartPlace = 1, fOLDecorHint = 0, fNoPPosition = 1, fForceIcon = 0, mini_icon_image = 8564, icon_req_image = 8564, icon_image = 8564, orig_width = 0, orig_height = 0, grav = {x = 0, y = 0, t = 0}, mwm_hints = 0x80f7978, ol_hints = 15, functions = 44, cmap_windows = 0x0, number_cmap_windows = 0, ReliefColor = 1076884376, ShadowColor = 1076884328, TextColor = 1076884152, BackColor = 1076896496, HiReliefColor = 8564, HiShadowColor = 8564, HiTextColor = 8564, HiBackColor = 8564, buttons = 0, IconBox = {0, 0, 0, 0}, other_properties = 1076950632, schwin = 1076950640} (gdb) p *psw->wmhints Cannot access memory at address 0x0. (gdb) p psw->wmhints $2 = (XWMHints *) 0x0 -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. When we write programs that "learn", it turns out we do and they don't. From owner-scwm-discuss@mit.edu Sat Nov 14 19:50:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA30775 for scwm-discuss-outgoing; Sat, 14 Nov 1998 19:50:53 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA30771; Sat, 14 Nov 1998 19:50:52 -0500 Message-Id: <199811150050.TAA30771@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Free at last Date: Sat, 14 Nov 1998 19:50:52 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I finally merged my branch to the head. This should add a bunch of new features. I am going to look making a list of what fixes and changes I think should be made before an official release of 0.9 and I will try my best to have a non-feature-complete not-necessarily-portable beta out tomorrow. Here is my essential task list for a final 0.9; if you are aware of any other bugs especially, or think certain things really should be changed, please post to that effect. I will post this list somewhere on the web sometime soon and mark off entries as they are taken care of. - Maciej * Fix Julian Satchell's bug report "Scwm crash on repeated Map requests" at http://huis-clos.mit.edu/scwm-discuss.1998/1698.html * Evaluate and apply Stephen Tell's bug report for build problems at http://huis-clos/scwm-discuss.1998/1691.html * Fix (if I can!) the bug with missing colors when rubberbanding reported by Robert Bihlmeyer at http://huis-clos/scwm-discuss.1998/1682.html * Fix Jens-Ulrik Petersen's bug with next-window at http://huis-clos/scwm-discuss.1998/1479.html * Fix Sam Steingold's session-management crash at * Add a tile.scm to match cascade.scm * Make background.c set the properties that esetroot and xsetroot do as described by http://huis-clos/scwm-discuss.1998/1609.html * higher-level interface to backgrounds. * Do an API change on window.c as follows: all window filed setters get names of the form `set-window-foo!', all filed accessors get named `window-foo' (or `window-foo?' if strictly a predicate), and all actions get named `bar-window'; ensure there are getters for all setters. Make accessors, predicates and setters not take the window argument as optional (i.e. make it mandatory). In my opinion the defaulting can only possibly be sensible for actions. Also make the window argument come first for all setters. It will hurt to make everything work right after this change but it is _definitely_ necessary. * resolve issues with interactive-move vs. rbubberband-move vs. opaque-move. * Regenerate docs. * Test on many platforms. From owner-scwm-discuss@mit.edu Sat Nov 14 20:10:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31019 for scwm-discuss-outgoing; Sat, 14 Nov 1998 20:10:54 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31015; Sat, 14 Nov 1998 20:10:53 -0500 Message-Id: <199811150110.UAA31015@huis-clos.mit.edu> To: Maciej Stachowiak cc: scwm-discuss@mit.edu Subject: Re: Free at last In-reply-to: Your message of "Sat, 14 Nov 1998 19:50:52 EST." <199811150050.TAA30771@huis-clos.mit.edu> Date: Sat, 14 Nov 1998 20:10:53 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mstachow@mit.edu writes: > I will post this list > somewhere on the web sometime soon and mark off entries as they are > taken care of. > OK, I put the list at http://huis-clos.mit.edu/release-todo.html. _Please_ tell me if you have any suggested additions, especially serious or really annoying bugs you know of. - Maciej From owner-scwm-discuss@mit.edu Sat Nov 14 20:59:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA31428 for scwm-discuss-outgoing; Sat, 14 Nov 1998 20:59:45 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA31425 for ; Sat, 14 Nov 1998 20:59:44 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA23454; Sat, 14 Nov 98 20:59:35 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id RAA01041; Sat, 14 Nov 1998 17:59:40 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Fixme comment changes suggested References: <199811142000.PAA05584@w20-575-39.mit.edu> From: Greg Badros Date: 14 Nov 1998 17:59:40 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 14 Nov 1998 15:00:45 EST" Message-Id: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > If people agree this is a good move, I will at some point convert all > old comments and document the new format in doc/dev. Sounds good to me. Be sure to update HACKING w/ essentially the details of this message. Greg From owner-scwm-discuss@mit.edu Sun Nov 15 01:27:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA08011 for scwm-discuss-outgoing; Sun, 15 Nov 1998 01:27:41 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA08008 for ; Sun, 15 Nov 1998 01:27:39 -0500 Received: from M2-032-6.MIT.EDU by MIT.EDU with SMTP id AA17375; Sun, 15 Nov 98 01:27:30 EST Received: by m2-032-6.mit.edu (SMI-8.6/4.7) id BAA03406; Sun, 15 Nov 1998 01:27:38 -0500 Message-Id: <199811150627.BAA03406@m2-032-6.mit.edu> To: scwm-discuss@mit.edu Subject: windows on other desks mapped on shutdown Date: Sun, 15 Nov 1998 01:27:38 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Windows from other desks get mapped on shutdown. What code is doing this? As far as I can tell, every X call made on windows while they are getting released is documented to not map the window if it is unmapped. However iconified windows are also remapped. So _some_thing must be mapping all windows as they are un-reparented. I just can't tell what. Actually, the docs I have for XConfigureWindow don't explicitly say it doens't map unmapped windows, but nor does it say that it does, and X{Move,Resize,etc}Window documented on the same man page are clearly documented as not doing so. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sun Nov 15 13:23:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA11998 for scwm-discuss-outgoing; Sun, 15 Nov 1998 13:23:52 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA11992 for ; Sun, 15 Nov 1998 13:23:48 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA24994 for scwm-discuss@huis-clos.mit.edu; Sun, 15 Nov 1998 19:10:40 +0100 (MET) Received: (qmail 989 invoked by uid 115); 15 Nov 1998 17:33:32 -0000 To: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811150627.BAA03406@m2-032-6.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Nov 1998 18:33:28 +0100 In-Reply-To: Maciej Stachowiak's message of "Sun, 15 Nov 1998 01:27:38 EST" Message-ID: Lines: 17 User-Agent: Gnus/5.070042 (Pterodactyl Gnus v0.42) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 15 Nov 1998 01:27:38 EST >>>>> Maciej Stachowiak said: Maciej> Windows from other desks get mapped on shutdown. What code is Maciej> doing this? I think the XAddToSaveSet() call in `AddWindow' causes this behaviour. When scwm exits, all windows in its save set are mapped. What's wrong with that? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Nov 15 13:23:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12000 for scwm-discuss-outgoing; Sun, 15 Nov 1998 13:23:52 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA11995 for ; Sun, 15 Nov 1998 13:23:50 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA24990 for scwm-discuss@huis-clos.mit.edu; Sun, 15 Nov 1998 19:10:37 +0100 (MET) Received: (qmail 1225 invoked by uid 115); 15 Nov 1998 17:59:31 -0000 To: scwm-discuss@mit.edu Subject: Re: crash References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Nov 1998 18:59:27 +0100 In-Reply-To: Sam Steingold's message of "14 Nov 1998 20:36:11 -0500" Message-ID: Lines: 20 User-Agent: Gnus/5.070042 (Pterodactyl Gnus v0.42) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 14 Nov 1998 20:36:11 -0500 >>>>> Sam Steingold said: Sam> I get a very stable crash when trying to run a particular Sam> client. Sam> Program received signal SIGSEGV, Segmentation fault. Sam> 0x807743d in getWindowClientId (psw=0x80f3858) at Sam> session-manager.c:118 118 else if (psw->wmhints->flags & Sam> WindowGroupHint) Oops. Thanks for the report, a fix will be committed tomorrowish. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Nov 15 13:23:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12003 for scwm-discuss-outgoing; Sun, 15 Nov 1998 13:23:53 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id NAA11999 for ; Sun, 15 Nov 1998 13:23:52 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA24995 for scwm-discuss@huis-clos.mit.edu; Sun, 15 Nov 1998 19:10:40 +0100 (MET) Received: (qmail 998 invoked by uid 115); 15 Nov 1998 17:35:46 -0000 To: scwm-discuss@mit.edu Subject: Re: Merged image package References: <199811141935.OAA14081@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 15 Nov 1998 18:35:43 +0100 In-Reply-To: Maciej Stachowiak's message of "Sat, 14 Nov 1998 14:35:00 EST" Message-ID: Lines: 21 User-Agent: Gnus/5.070042 (Pterodactyl Gnus v0.42) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sat, 14 Nov 1998 14:35:00 EST >>>>> Maciej Stachowiak said: Maciej> I've been talking to the fvwm people about setting up a Maciej> merged package of window manager images, which would contain Maciej> textures, tiles, icons and mini-icons. It's a good idea. Maciej> Also, the install location and process would be much more Maciej> sane than for the current scwm-icons and fvwm stuff. What would that location be? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Nov 15 13:52:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12449 for scwm-discuss-outgoing; Sun, 15 Nov 1998 13:52:45 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA12446 for ; Sun, 15 Nov 1998 13:52:43 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA10661; Sun, 15 Nov 98 13:52:27 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12440; Sun, 15 Nov 1998 13:52:40 -0500 Message-Id: <199811151852.NAA12440@huis-clos.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown In-Reply-To: Your message of "15 Nov 1998 18:33:28 +0100." Date: Sun, 15 Nov 1998 13:52:40 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Sun, 15 Nov 1998 01:27:38 EST > >>>>> Maciej Stachowiak said: > > Maciej> Windows from other desks get mapped on shutdown. What code is > Maciej> doing this? > > I think the XAddToSaveSet() call in `AddWindow' causes this behaviour. > When scwm exits, all windows in its save set are mapped. What's wrong > with that? > I want to make it optional whether to map windows on other desks at shutdown time. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sun Nov 15 13:55:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12489 for scwm-discuss-outgoing; Sun, 15 Nov 1998 13:55:10 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA12483; Sun, 15 Nov 1998 13:55:06 -0500 Message-Id: <199811151855.NAA12483@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: Merged image package In-reply-to: Your message of "15 Nov 1998 18:35:43 +0100." Date: Sun, 15 Nov 1998 13:55:06 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Sat, 14 Nov 1998 14:35:00 EST > >>>>> Maciej Stachowiak said: > > Maciej> I've been talking to the fvwm people about setting up a > Maciej> merged package of window manager images, which would contain > Maciej> textures, tiles, icons and mini-icons. > > It's a good idea. > > Maciej> Also, the install location and process would be much more > Maciej> sane than for the current scwm-icons and fvwm stuff. > > What would that location be? > I'm thinking of ${datadir}/wmicons/icons/ ${datadir}/wmicons/mini-icons/ ${datadir}/wmicons/textures/ ${datadir}/wmicons/tiles/ ${datadir} defaults to /usr/local/share/, and would probably be /usr/share for a package distributed by a Linux vendor or what have you. I think this is better than dumping stuff in the X11 tree. - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 14:15:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA12754 for scwm-discuss-outgoing; Sun, 15 Nov 1998 14:15:03 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id OAA12751 for ; Sun, 15 Nov 1998 14:15:02 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id OAA26685 for ; Sun, 15 Nov 1998 14:14:55 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id OAA03394 for ; Sun, 15 Nov 1998 14:14:53 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with ESMTP id OAA08658 for ; Sun, 15 Nov 1998 14:15:24 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sun, 15 Nov 1998 14:15:24 -0500 (EST) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: window-style matching broken Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just got the latest CVS update, and found that any lines in my .scwmrc file containing (window-style "window" ...) are severely broken, except when "window == "*". To see if this was just my .scwmrc, I also tried the decor.scwmrc file in the distribution and had the same results. A sample backtrace from interpreting (window-style "Gimp" #:start-on-desk 4 #:sticky #f #:mini-icon "gimp.xpm") is Backtrace: 2* [apply # "Gimp" ...] 3 [make-conditional-style "Gimp" #:start-on-desk ...] 4 [simplify-style ... 5* [mcs-parse-args ... 6* [condition->predicate "Gimp"] 7 (cond ((or # #) always?) ((eq? #f condition) never?) ...) ... 8 (let ((pred #)) (hash-set! predicate-hash (list # string ...) ...)) 9* (begin (win-or?? (title-match?? string type ...) (class-match?? string typ e ...) ...)) 10 [win-or?? ... 11* [title-match?? "Gimp"] 12 (let-optional* lambda*:G27 ((type default-matcher-type) (case-sensitive d efault-matcher-case-sensitive)) ...) ... 13 (let ((pred #)) (hash-set! predicate-hash (list # string ...) ...)) 14* (begin "Return a predicate that tests a window's title. When applied to a window, this precicate will return true if the title matches STRING in the manner specified by the optional argument TYPE, which may be 'exact, 'regexp, or 'wildcard. The optional CASE-SENSITIVE argument determines whether the matching is case-sensitive or not." (case type (# #) ...)) 15 (case type ((exact) (let # #)) ...) ... 16 (let ((pred #)) (hash-set! predicate-hash (list # string ...) ...)) 17* (begin "Return a predicate that tests a window's title. When applied to a window, this precicate will return true if the title matches STRING in the manner specified by the optional argument TYPE, which may be 'exact, 'regexp, or 'wildcard. The optional CASE-SENSITIVE argument determines whether the matching is case-sensitive or not." (case type (# #) ...)) 18 (case type ((exact) (let # #)) ...) 19 (let ((match-regexp #)) (lambda (win) (let* # #))) 20* [make-regexp "Gimp" (regexp/icase)] 21* [gsubr-apply #> "Gimp " ...] ERROR: In procedure gsubr-apply in expression (make-regexp string (if case-sensi tive # ...)): ERROR: out of memory Note that although it says "out of memory", scwm isn't even close to using up all available memory (and I've made sure to unlimit memory usage so it can use quite a bit if it needs to). Other lines produce similar backtraces but different errors: "invalid argument to regex routine" and "invalid character range". This is on a FreeBSD 2.2.7 machine, and changed.c contains char *szRepoLastChanged = "Sat Nov 14 19:04:26 EST 1998 -- $Revision: 1.859 $"; See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sun Nov 15 14:44:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA13116 for scwm-discuss-outgoing; Sun, 15 Nov 1998 14:44:56 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA13113 for ; Sun, 15 Nov 1998 14:44:56 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA17219; Sun, 15 Nov 98 14:44:30 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id OAA01125 for ; Sun, 15 Nov 1998 14:44:30 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Merged image package References: <199811151855.NAA12483@huis-clos.mit.edu> Date: 15 Nov 1998 14:44:24 -0500 Message-Id: <5lk90w68rr.fsf@tequila.cs.yale.edu> Lines: 13 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 15 Nov 1998 14:44:24 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: > ${datadir}/wmicons/icons/ > ${datadir}/wmicons/mini-icons/ > ${datadir}/wmicons/textures/ > ${datadir}/wmicons/tiles/ Why `wm' ? Those icons can also be used for other applications (file-managers come to mind) ${datadir}/icons/ sounds perfect to me. Stefan From owner-scwm-discuss@mit.edu Sun Nov 15 14:47:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA13176 for scwm-discuss-outgoing; Sun, 15 Nov 1998 14:47:53 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA13173 for ; Sun, 15 Nov 1998 14:47:51 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA17632; Sun, 15 Nov 98 14:47:35 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA13166; Sun, 15 Nov 1998 14:47:40 -0500 Message-Id: <199811151947.OAA13166@huis-clos.mit.edu> To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Merged image package In-Reply-To: Your message of "15 Nov 1998 14:44:24 EST." <5lk90w68rr.fsf@tequila.cs.yale.edu> Date: Sun, 15 Nov 1998 14:47:30 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk monnier+lists/scwm/discuss/news/@tequila.cs.yale.edu writes: > >>>>> "Maciej" == Maciej Stachowiak writes: > > ${datadir}/wmicons/icons/ > > ${datadir}/wmicons/mini-icons/ > > ${datadir}/wmicons/textures/ > > ${datadir}/wmicons/tiles/ > > Why `wm' ? > Those icons can also be used for other applications > (file-managers come to mind) > ${datadir}/icons/ sounds perfect to me. > Er, I mistyped, I mean `wmimages', not `wmicons' since not all images in that package are icons. I'm suggesting this because that is the package name. If you can think of a broader package name that makes sense, I am all ears. Or else we could install in ${datadir} directly, not ${pkgdatadir} as above. - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 16:11:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18385 for scwm-discuss-outgoing; Sun, 15 Nov 1998 16:11:49 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18380; Sun, 15 Nov 1998 16:11:14 -0500 Message-Id: <199811152111.QAA18380@huis-clos.mit.edu> To: "merry::satchell"@hermes.dra.hmg.gb cc: scwm-discuss@mit.edu Subject: Re: SCWM crash on repeated Map requests. In-reply-to: Your message of "Thu, 12 Nov 1998 13:11:13 GMT." <009CF1C6.62D97760.2@hermes.dra.hmg.gb> Date: Sun, 15 Nov 1998 16:11:04 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk "merry::satchell"@hermes.dra.hmg.gb writes: > I enclose a gdb stack trace of scwm after its most recent crash, > triggered by a programme which may have been trying to map an > already mapped window. I am trying to reproduce this bug, but I can't. In particular, the following program, which maps a window twice, does not cause a crash for me. ======================================= #include #include #include #include #include #include Display *display; char *dispName; Window w; int init_display() { if (!(dispName = getenv("DISPLAY"))) return 0; if (!(display = XOpenDisplay(dispName))) return 0; return 1; } int main() { init_display(); w = XCreateSimpleWindow(display, DefaultRootWindow(display), 0, 0, 100, 100, 1, 0, 0); XMapWindow(display, w); sleep(20); XMapWindow(display, w); sleep(20); } ========================================== > Linux 2.0.30 > egcs 1.1b > Scwm Version post0.8a compiled on Nov 4 1998 at 18:49:14 > RCS_ID=$Id: scwm.c,v 1.146 1998/10/27 13:49:46 robbe Exp $ > Repository Timestamp: Tue Nov 3 23:10:39 EST 1998 -- $Revision: 1.786 $ > > Core was generated by `scwm'. > Program terminated with signal 11, Segmentation fault. > #0 0x4012b63b in scm_send () at socket.c:508 > 508 } > #0 0x4012b63b in scm_send () at socket.c:508 It looks like scwm is dying trying to write to a socket. Is there any chance you have code writing to a socket somewhere in a startup hook which might be doing something bad? - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 16:26:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18559 for scwm-discuss-outgoing; Sun, 15 Nov 1998 16:26:38 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA18556 for ; Sun, 15 Nov 1998 16:26:37 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA01877; Sun, 15 Nov 98 16:26:05 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id QAA13777; Sun, 15 Nov 1998 16:25:54 -0500 (EST) Message-Id: <199811152125.QAA13777@jekyll.piermont.com> To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Merged image package In-Reply-To: Your message of "15 Nov 1998 14:44:24 EST." <5lk90w68rr.fsf@tequila.cs.yale.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 15 Nov 1998 16:25:54 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > Why `wm' ? > Those icons can also be used for other applications > (file-managers come to mind) How about "uiimages"? .pm From owner-scwm-discuss@mit.edu Sun Nov 15 16:35:21 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18649 for scwm-discuss-outgoing; Sun, 15 Nov 1998 16:35:21 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA18635; Sun, 15 Nov 1998 16:35:04 -0500 Message-Id: <199811152135.QAA18635@huis-clos.mit.edu> To: cc: scwm-discuss@mit.edu Subject: Re: #:focus 'none & next-window Date: Sun, 15 Nov 1998 16:34:54 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jens-Ulrik Petersen wrote: > I use click to focus by default. Am I still the only one? > > Anyway I have noticed that if I click on a window with #:focus 'none > set then I can't use > > (next-window #:only visible? #:except iconified?) > > (Alt-Tab) to change the focus to another window on the screen. > > I will try to investigate more, but maybe someone knows a quick fix so > I thought I would post the problem here first. I tried to reproduce this (I set the focus style for all windows to 'click except one which I set to 'none) and circulation works fine for me. The only oddity is that if you select a #:focus 'none window by clicking on it and then circulate (so that the previous window still has the input focus), you will initially circulate back to the unfocusable window and then continue from there. Perhaps it would be smart to (unfocus) when trying to focus an unfocusable window, and to keep track of the last window that `focus' was called on, even if it did not end up getting the input focus. What do you think? - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 17:03:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22490 for scwm-discuss-outgoing; Sun, 15 Nov 1998 17:03:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22482; Sun, 15 Nov 1998 17:02:59 -0500 Message-Id: <199811152202.RAA22482@huis-clos.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: gzipped xpms In-reply-to: Your message of "23 Oct 1998 16:03:01 +0200." Date: Sun, 15 Nov 1998 17:02:59 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > libXpm can handle gzipped xpms. I think it would be useful for > `path_expand_image_fname' to also try "/some/path/foo.xpm.gz" when > instructed to locate "foo.xpm". > I'm not sure if doing that is a good idea, but it will already work if you tell it to load "/some/path/foo.xpm.gz". (I'd forgotten that it would). - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 17:09:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22565 for scwm-discuss-outgoing; Sun, 15 Nov 1998 17:09:37 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA22562 for ; Sun, 15 Nov 1998 17:09:36 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA28059; Sun, 15 Nov 98 17:09:27 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA05057; Sun, 15 Nov 1998 14:09:24 -0800 (PST) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811151852.NAA12440@huis-clos.mit.edu> From: Greg Badros Date: 15 Nov 1998 14:09:24 -0800 In-Reply-To: Maciej Stachowiak's message of "Sun, 15 Nov 1998 13:52:40 EST" Message-Id: Lines: 11 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I want to make it optional whether to map windows on other desks at > shutdown time. You can (set! scwm-no-move-windows-on-exit #t) That might not quite be what you want, and likely isn't documented as well as it could be. (Sorry, I'm behind a slow connection right now). Greg From owner-scwm-discuss@mit.edu Sun Nov 15 17:12:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22661 for scwm-discuss-outgoing; Sun, 15 Nov 1998 17:12:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22653; Sun, 15 Nov 1998 17:12:44 -0500 Message-Id: <199811152212.RAA22653@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown In-reply-to: Your message of "15 Nov 1998 14:09:24 PST." Date: Sun, 15 Nov 1998 17:12:44 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I want to make it optional whether to map windows on other desks at > > shutdown time. > > You can (set! scwm-no-move-windows-on-exit #t) > > That might not quite be what you want, and likely isn't documented as > well as it could be. (Sorry, I'm behind a slow connection right now). > That should in theory prevent moving windows from other viewports onto the current one. I just reworked that behavior to make not moving them the default. I was trying to do the equivalent for desks but I have realized it is complicated to do it right so I've ignored the desk issue for now. - Maciej From owner-scwm-discuss@mit.edu Sun Nov 15 17:28:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA22903 for scwm-discuss-outgoing; Sun, 15 Nov 1998 17:28:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA22900 for ; Sun, 15 Nov 1998 17:28:01 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11601; Sun, 15 Nov 98 17:27:52 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA05092; Sun, 15 Nov 1998 14:27:50 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811152212.RAA22653@huis-clos.mit.edu> From: Greg Badros Date: 15 Nov 1998 14:27:49 -0800 In-Reply-To: Maciej Stachowiak's message of "Sun, 15 Nov 1998 17:12:44 EST" Message-Id: Lines: 27 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > > > > I want to make it optional whether to map windows on other desks at > > > shutdown time. > > > > You can (set! scwm-no-move-windows-on-exit #t) > > > > That might not quite be what you want, and likely isn't documented as > > well as it could be. (Sorry, I'm behind a slow connection right now). > > > > That should in theory prevent moving windows from other viewports onto > the current one. I just reworked that behavior to make not moving them > the default. I was trying to do the equivalent for desks but I have > realized it is complicated to do it right so I've ignored the desk > issue for now. What I was ultimately imagining is a property set on the windows so that iff scwm restarts, the windows go back to their viewport positions, otherwise they stay on the home viewport. For desks it is trickier, as you note, since those are managed by the wm. Greg From owner-scwm-discuss@mit.edu Sun Nov 15 21:42:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA23933 for scwm-discuss-outgoing; Sun, 15 Nov 1998 21:42:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA23930 for ; Sun, 15 Nov 1998 21:42:10 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA09456; Sun, 15 Nov 98 21:41:53 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 15 Nov 1998 21:41:30 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 15 Nov 1998 21:41:29 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id VAA03432; Sun, 15 Nov 1998 21:40:20 -0500 To: Greg Badros Cc: Maciej Stachowiak , Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811151852.NAA12440@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "15 Nov 1998 14:09:24 -0800" Date: 15 Nov 1998 21:40:20 -0500 Message-Id: Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: windows on other desks mapped on shutdown" >>>> Sent on 15 Nov 1998 14:09:24 -0800 >>>> Honorable Greg Badros writes: >> Maciej Stachowiak writes: >> >> > I want to make it optional whether to map windows on other desks at >> > shutdown time. >> >> You can (set! scwm-no-move-windows-on-exit #t) scwm> scwm-no-move-windows-on-exit Backtrace: 0* scwm-no-move-windows-on-exit ERROR: In expression scwm-no-move-windows-on-exit: ERROR: Unbound variable: scwm-no-move-windows-on-exit scwm> -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. All generalizations are wrong. Including this. From owner-scwm-discuss@mit.edu Sun Nov 15 22:55:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA24437 for scwm-discuss-outgoing; Sun, 15 Nov 1998 22:55:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA24428; Sun, 15 Nov 1998 22:55:00 -0500 Message-Id: <199811160355.WAA24428@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown In-reply-to: Your message of "15 Nov 1998 14:27:49 PST." Date: Sun, 15 Nov 1998 22:55:00 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > That should in theory prevent moving windows from other viewports onto > > the current one. I just reworked that behavior to make not moving them > > the default. I was trying to do the equivalent for desks but I have > > realized it is complicated to do it right so I've ignored the desk > > issue for now. > > What I was ultimately imagining is a property set on the windows so that > iff scwm restarts, the windows go back to their viewport positions, > otherwise they stay on the home viewport. > > > For desks it is trickier, as you note, since those are managed by the wm. That already happens with desks, sort of (i.e. a property is set that puts them back on the proper desk on restart). What annoys me is that the windows from any desk get dumped all into one screen when, e.g. I kill scwm or a development version crashes on me, which might make it hard to restart it if all my xterms are covered by other stuff. I will probably work on making this behavior optional at some point, but not before the release. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 01:54:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA20592 for scwm-discuss-outgoing; Mon, 16 Nov 1998 01:54:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA20586 for ; Mon, 16 Nov 1998 01:53:53 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22815; Mon, 16 Nov 98 01:53:38 EST Received: (qmail 19895 invoked by uid 501); 16 Nov 1998 06:53:37 -0000 Message-Id: <19981115225336.A19756@molehill.org> Date: Sun, 15 Nov 1998 22:53:36 -0800 From: Todd Larason To: scwm-discuss list Subject: catching up Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "I'll not have you punk rockers making music in MY auditorium", said Tom disconcertingly. X-Kibo: Why not conserve energy? Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm just back from vacation, and was swamped at work before that to get ready for vacation, so I'm just starting to catch up on some of the recent changes/discussion. The merged image package sounds like a very good idea. It would also be nice to try to get some new mini icons developed - I took a stab at making a mini-icon with the Sun and NeXT logos, and rediscovered that icon-drawing is harder than it looks. Anyone with some artistic talent feel like taking a stab at it? The proposed FIXME format looks good. The themes support looks real nice. Unfortunately, the .tar.gz file make rules don't work in build environments where srcdir != builddir. Now, to try running this version... From owner-scwm-discuss@mit.edu Mon Nov 16 10:30:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA23839 for scwm-discuss-outgoing; Mon, 16 Nov 1998 10:30:12 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA23829 for ; Mon, 16 Nov 1998 10:29:36 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07441; Mon, 16 Nov 98 10:29:13 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA06807; Mon, 16 Nov 1998 07:29:11 -0800 (PST) To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811151852.NAA12440@huis-clos.mit.edu> From: Greg Badros Date: 16 Nov 1998 07:29:11 -0800 In-Reply-To: Sam Steingold's message of "15 Nov 1998 21:40:20 -0500" Message-Id: Lines: 35 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> On the subject of "Re: windows on other desks mapped on shutdown" > >>>> Sent on 15 Nov 1998 14:09:24 -0800 > >>>> Honorable Greg Badros writes: > >> Maciej Stachowiak writes: > >> > >> > I want to make it optional whether to map windows on other desks at > >> > shutdown time. > >> > >> You can (set! scwm-no-move-windows-on-exit #t) > > scwm> scwm-no-move-windows-on-exit > > Backtrace: > 0* scwm-no-move-windows-on-exit > > ERROR: In expression scwm-no-move-windows-on-exit: > ERROR: Unbound variable: scwm-no-move-windows-on-exit You need to: (define scwm-no-move-windows-on-exit #t) if your scwmrc hasn't already defined the name. [N.B. I don't think interspersing semi-random gh_lookup calls (as I did for this) is a good way to define a user-variable; we should figure out how best to do this and update all user-variables so that they follow the conventions. User-variables defined in Scheme code are at least reasonably structured, but those created in C code are not, AFAIK.] Greg From owner-scwm-discuss@mit.edu Mon Nov 16 11:53:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24841 for scwm-discuss-outgoing; Mon, 16 Nov 1998 11:53:26 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA24838 for ; Mon, 16 Nov 1998 11:53:25 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA05740; Mon, 16 Nov 98 11:53:07 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 16 Nov 1998 11:52:57 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 16 Nov 1998 11:52:57 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id LAA04533; Mon, 16 Nov 1998 11:53:06 -0500 To: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811151852.NAA12440@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "16 Nov 1998 07:29:11 -0800" Date: 16 Nov 1998 11:53:06 -0500 Message-Id: Lines: 48 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: windows on other desks mapped on shutdown" >>>> Sent on 16 Nov 1998 07:29:11 -0800 >>>> Honorable Greg Badros writes: >> Sam Steingold writes: >> >> > >>>> In message >> > >>>> On the subject of "Re: windows on other desks mapped on shutdown" >> > >>>> Sent on 15 Nov 1998 14:09:24 -0800 >> > >>>> Honorable Greg Badros writes: >> > >> Maciej Stachowiak writes: >> > >> >> > >> > I want to make it optional whether to map windows on other desks at >> > >> > shutdown time. >> > >> >> > >> You can (set! scwm-no-move-windows-on-exit #t) >> > >> > scwm> scwm-no-move-windows-on-exit >> > >> > Backtrace: >> > 0* scwm-no-move-windows-on-exit >> > >> > ERROR: In expression scwm-no-move-windows-on-exit: >> > ERROR: Unbound variable: scwm-no-move-windows-on-exit >> >> You need to: >> >> (define scwm-no-move-windows-on-exit #t) >> >> if your scwmrc hasn't already defined the name. IMO, this is wrong. If I want documentation for this variable (in emacs), it must be in scwm-obarray, and it is not, because it is undefined. (and the doc is absent anyway) What's the use of an undocumented user variable? (C) me. [Well, I remember the times where I set `gnus-boogaboo' to t in .emacs, it enabled undocumented/unsupported features in an Emacs package - guess which - and it had no docstring too. Still, I prefer the Linux approach, where even undocumented is documented - try `man undocumented`.] -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. The world will end in 5 minutes. Please log out. From owner-scwm-discuss@mit.edu Mon Nov 16 11:59:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24911 for scwm-discuss-outgoing; Mon, 16 Nov 1998 11:59:44 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA24903; Mon, 16 Nov 1998 11:59:37 -0500 Message-Id: <199811161659.LAA24903@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown In-reply-to: Your message of "16 Nov 1998 07:29:11 PST." Date: Mon, 16 Nov 1998 11:59:37 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Sam Steingold writes: > > > >>>> In message > > >>>> On the subject of "Re: windows on other desks mapped on shutdown" > > >>>> Sent on 15 Nov 1998 14:09:24 -0800 > > >>>> Honorable Greg Badros writes: > > >> Maciej Stachowiak writes: > > >> > > >> > I want to make it optional whether to map windows on other desks at > > >> > shutdown time. > > >> > > >> You can (set! scwm-no-move-windows-on-exit #t) > > > > scwm> scwm-no-move-windows-on-exit > > > > Backtrace: > > 0* scwm-no-move-windows-on-exit > > > > ERROR: In expression scwm-no-move-windows-on-exit: > > ERROR: Unbound variable: scwm-no-move-windows-on-exit > > You need to: > > (define scwm-no-move-windows-on-exit #t) > > if your scwmrc hasn't already defined the name. Except that current scwm from CVS will no longer respect that variable. It will not move windows or move the viewport on exit by default; the new `shutdown-options' in the (app scwm shutdown-opts) module allows you to specify those behaviors explicitly. > [N.B. I don't think interspersing semi-random gh_lookup calls (as I did > for this) is a good way to define a user-variable; we should figure out > how best to do this and update all user-variables so that they follow > the conventions. Yes. I have since figured out a better way to do it (the SCM_VAR macro) which I've started using in any new code, I just haven't had the chance to clean up old instances yet. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 12:17:12 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25392 for scwm-discuss-outgoing; Mon, 16 Nov 1998 12:17:12 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA25384; Mon, 16 Nov 1998 12:17:01 -0500 Message-Id: <199811161717.MAA25384@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: catching up In-reply-to: Your message of "Sun, 15 Nov 1998 22:53:36 PST." <19981115225336.A19756@molehill.org> Date: Mon, 16 Nov 1998 12:16:56 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I'm just back from vacation, and was swamped at work before that to get ready > for vacation, so I'm just starting to catch up on some of the recent > changes/discussion. > > The merged image package sounds like a very good idea. It would also be nice > to try to get some new mini icons developed - I took a stab at making a > mini-icon with the Sun and NeXT logos, and rediscovered that icon-drawing is > harder than it looks. Anyone with some artistic talent feel like taking a > stab at it? > Yep, especially for really small icons. I'd ask some of my graphic artist friends, but I'm not sure it would be legal for us to distribute icons that contain the Sun or NeXT logos. Does anyone have the relevant clue about trademark/copyright law? > The proposed FIXME format looks good. > > The themes support looks real nice. Unfortunately, the .tar.gz file make > rules don't work in build environments where srcdir != builddir. > D'oh! I keep forgetting about that. I try to run `make distcheck' regularly nowadays, so I should catch such problems sooner in the future. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 14:59:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA01550 for scwm-discuss-outgoing; Mon, 16 Nov 1998 14:59:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA01547 for ; Mon, 16 Nov 1998 14:59:18 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA16298; Mon, 16 Nov 98 14:58:59 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 16 Nov 1998 14:58:51 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 16 Nov 1998 14:58:50 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA09326; Mon, 16 Nov 1998 14:58:59 -0500 To: scwm-discuss@mit.edu Subject: docs: scwm-procedures.txt Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 16 Nov 1998 14:58:58 -0500 Message-Id: Lines: 9 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is it possible to put the doc-file rebuilds into some cron job? Like add it to the snapshot generation routine. Thanks. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. OS/2: Why marketing matters more than technology... From owner-scwm-discuss@mit.edu Mon Nov 16 15:26:03 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01811 for scwm-discuss-outgoing; Mon, 16 Nov 1998 15:26:03 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01806; Mon, 16 Nov 1998 15:26:01 -0500 Message-Id: <199811162026.PAA01806@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 14:58:58 EST." Date: Mon, 16 Nov 1998 15:26:01 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > Is it possible to put the doc-file rebuilds into some cron job? > Like add it to the snapshot generation routine. > Thanks. > I think the best solution is to make doc-generation happen automatically when you change the source files, using the incremental model as discussed previously. I will probably take a look at doing this after managing the 0.9 release (I have my hands full with http://huis-clos.mit.edu/scwm/release-todo.html for now). - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 15:45:34 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01944 for scwm-discuss-outgoing; Mon, 16 Nov 1998 15:45:34 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01941 for ; Mon, 16 Nov 1998 15:45:34 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05426; Mon, 16 Nov 98 15:45:11 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA05683; Mon, 16 Nov 1998 22:45:08 +0200 To: Maciej Stachowiak Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162026.PAA01806@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Nov 1998 22:45:08 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 15:26:01 EST" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I think the best solution is to make doc-generation happen > automatically when you change the source files, using the incremental > model as discussed previously. I will probably take a look at doing > this after managing the 0.9 release (I have my hands full with > http://huis-clos.mit.edu/scwm/release-todo.html for now). I can make these changes to extract.scm in a few minutes, but extract.scm is out of date compared to the perl version. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Nov 16 15:54:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02104 for scwm-discuss-outgoing; Mon, 16 Nov 1998 15:54:08 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA02084; Mon, 16 Nov 1998 15:53:53 -0500 Message-Id: <199811162053.PAA02084@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 22:45:08 +0200." Date: Mon, 16 Nov 1998 15:53:53 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > I think the best solution is to make doc-generation happen > > automatically when you change the source files, using the incremental > > model as discussed previously. I will probably take a look at doing > > this after managing the 0.9 release (I have my hands full with > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > I can make these changes to extract.scm in a few minutes, but > extract.scm is out of date compared to the perl version. > Please make the changes then. I'll try to bring it up to date with the perl version at some point if you don't have time first. This is necessary anyway because we want to start using this stuff with Guile at some point. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 16:13:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02316 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:13:06 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02313 for ; Mon, 16 Nov 1998 16:12:55 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA16308; Mon, 16 Nov 98 16:12:31 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA05824; Mon, 16 Nov 1998 23:12:29 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162053.PAA02084@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Nov 1998 23:12:29 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 15:53:53 EST" Message-Id: Lines: 40 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > Maciej Stachowiak writes: > > > > > I think the best solution is to make doc-generation happen > > > automatically when you change the source files, using the incremental > > > model as discussed previously. I will probably take a look at doing > > > this after managing the 0.9 release (I have my hands full with > > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > > > I can make these changes to extract.scm in a few minutes, but > > extract.scm is out of date compared to the perl version. > > > > Please make the changes then. I'll try to bring it up to date with the > perl version at some point if you don't have time first. This is > necessary anyway because we want to start using this stuff with Guile > at some point. Just finished. I told you it'd only take a few minutes. You can do: extract.scm --pdoc foo.pdoc foo.c and then later do: extract.scm --proc scwm-procedures.txt *.pdoc I'll try to check it into cvs. I'm willing to bring extract.scm up to date if someone will tell me exactly what features I have to add. I really don't want to sit down with the perl script & try to figure it out. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Nov 16 16:22:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02437 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:22:44 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02434 for ; Mon, 16 Nov 1998 16:22:44 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA20450; Mon, 16 Nov 98 16:22:12 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 16 Nov 1998 16:22:01 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 16 Nov 1998 16:22:00 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id QAA09733; Mon, 16 Nov 1998 16:22:06 -0500 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162026.PAA01806@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 15:26:01 EST" Date: 16 Nov 1998 16:22:06 -0500 Message-Id: Lines: 23 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199811162026.PAA01806@huis-clos.mit.edu> >>>> On the subject of "Re: docs: scwm-procedures.txt" >>>> Sent on Mon, 16 Nov 1998 15:26:01 EST >>>> Honorable Maciej Stachowiak writes: >> sds@goems.com writes: >> > Is it possible to put the doc-file rebuilds into some cron job? >> > Like add it to the snapshot generation routine. >> > Thanks. >> > >> >> I think the best solution is to make doc-generation happen >> automatically when you change the source files, using the incremental >> model as discussed previously. yes, of course. what I meant was a stop-gap temporary solution to a very real current problem. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Diplomacy is the art of saying "nice doggy" until you can find a rock. From owner-scwm-discuss@mit.edu Mon Nov 16 16:30:26 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02541 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:30:26 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02536; Mon, 16 Nov 1998 16:30:25 -0500 Message-Id: <199811162130.QAA02536@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 16:22:06 EST." Date: Mon, 16 Nov 1998 16:30:25 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199811162026.PAA01806@huis-clos.mit.edu> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on Mon, 16 Nov 1998 15:26:01 EST > >>>> Honorable Maciej Stachowiak writes: > >> sds@goems.com writes: > >> > Is it possible to put the doc-file rebuilds into some cron job? > >> > Like add it to the snapshot generation routine. > >> > Thanks. > >> > > >> > >> I think the best solution is to make doc-generation happen > >> automatically when you change the source files, using the incremental > >> model as discussed previously. > > yes, of course. > what I meant was a stop-gap temporary solution to a very real current > problem. > Hmm, I just realized that I don't actually need a working Jade environment set up to build the docs, so this is easier than I thought. However, I don't want to mask the important issue that docs should get regenerated when relevant source files change. Thus, I will regenerate the docs nightly (or more often) by hand so that through suffering I will be reminded to fix this. If I get lame and don't keep up, I'll set up a cron job. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 16:34:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02601 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:34:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02597; Mon, 16 Nov 1998 16:34:41 -0500 Message-Id: <199811162134.QAA02597@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 23:12:29 +0200." Date: Mon, 16 Nov 1998 16:34:41 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > hjstein@bfr.co.il writes: > > > Maciej Stachowiak writes: > > > > > > > I think the best solution is to make doc-generation happen > > > > automatically when you change the source files, using the incremental > > > > model as discussed previously. I will probably take a look at doing > > > > this after managing the 0.9 release (I have my hands full with > > > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > > > > > I can make these changes to extract.scm in a few minutes, but > > > extract.scm is out of date compared to the perl version. > > > > > > > Please make the changes then. I'll try to bring it up to date with the > > perl version at some point if you don't have time first. This is > > necessary anyway because we want to start using this stuff with Guile > > at some point. > > Just finished. I told you it'd only take a few minutes. > > You can do: > > extract.scm --pdoc foo.pdoc foo.c > > and then later do: > > extract.scm --proc scwm-procedures.txt *.pdoc > > I'll try to check it into cvs. > Excellent. I can't believe we debated this for like a week and then waited for sevral more weeks and it just took a few minutes of coding. > I'm willing to bring extract.scm up to date if someone will tell me > exactly what features I have to add. I really don't want to sit down > with the perl script & try to figure it out. > I have no clue of what the two feature lists are, myself. Is there documentation anywhere of what the Perl version does, exactly? - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 16:35:00 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02612 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:35:00 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02609 for ; Mon, 16 Nov 1998 16:34:59 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA24699; Mon, 16 Nov 98 16:34:40 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id QAA15290 for ; Mon, 16 Nov 1998 16:34:39 -0500 (EST) Message-Id: <199811162134.QAA15290@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: Wharf support Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Nov 1998 16:26:56 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've been lurking here for a while. I've decided that it may be time to switch to scwm but I need to know something first. I currently use AfterStep. There are really only two reasons why: 1) I like the polished look of it. 2) The Wharf. Is there support for a wharf in scwm? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Mon Nov 16 16:49:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02829 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:49:47 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02826 for ; Mon, 16 Nov 1998 16:49:46 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA00702; Mon, 16 Nov 98 16:49:25 EST Received: (qmail 27758 invoked by uid 501); 16 Nov 1998 21:49:24 -0000 Message-Id: <19981116134924.A27701@molehill.org> Date: Mon, 16 Nov 1998 13:49:24 -0800 From: Todd Larason To: Arturo Perez , scwm-discuss@mit.edu Subject: Re: Wharf support References: <199811162134.QAA15290@ns1.infonautics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811162134.QAA15290@ns1.infonautics.com>; from Arturo Perez on Mon, Nov 16, 1998 at 04:26:56PM -0500 X-Tom-Swifty: "Why are you lying down so close to me?" asked Adam naively. X-Kibo: You are allowed to be false, because it is allowed. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981116, Arturo Perez wrote: > I've been lurking here for a while. I've decided that it may be time to > switch to scwm but I need to know something first. > > I currently use AfterStep. There are really only two reasons why: > 1) I like the polished look of it. > 2) The Wharf. > > Is there support for a wharf in scwm? Probably not right now. How hard it would be to add would depend on how far AfterStep's module interface has diverged from fvwm's, and exactly what part of fvwm's it uses. It isn't obvious to me why wharf etc. need WM integration. What features do they have that depend on it? From owner-scwm-discuss@mit.edu Mon Nov 16 16:51:31 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA02877 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:51:31 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA02874 for ; Mon, 16 Nov 1998 16:51:31 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA01236; Mon, 16 Nov 98 16:50:55 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA06051; Mon, 16 Nov 1998 23:50:47 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162134.QAA02597@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 16 Nov 1998 23:50:47 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 16:34:41 EST" Message-Id: Lines: 63 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > Maciej Stachowiak writes: > > > > Just finished. I told you it'd only take a few minutes. > > > > You can do: > > > > extract.scm --pdoc foo.pdoc foo.c > > > > and then later do: > > > > extract.scm --proc scwm-procedures.txt *.pdoc > > > > I'll try to check it into cvs. > > > > Excellent. I can't believe we debated this for like a week and then > waited for sevral more weeks and it just took a few minutes of coding. That's because scheme's cool. > > I'm willing to bring extract.scm up to date if someone will tell me > > exactly what features I have to add. I really don't want to sit down > > with the perl script & try to figure it out. > > I have no clue of what the two feature lists are, myself. Is there > documentation anywhere of what the Perl version does, exactly? I *wish*. My version works as in the documentation at the top: ;;; Extracts doc strings from C code which follows scwm conventions: ;;; 1. Procs to document have declarations OTF: ;;; SCWM_PROC(c_name, ;;; "scheme_name", ;;; number_of_required_args, ;;; number_of_optional_args, ;;; ;;; zero_or_one_for_whether_there_are_variable_numbers_of_args, ;;; (SCM arg1, SCM arg2, ...)) ;;; 2. The documentation for said proc starts on the line following ;;; it's ;;; definition, starting with /** & ending with */. ;;; 3. Additional documentation starts with: ;;; /** chapter_name: section_name ;;; & ends with */, but is not preceeded by a SCWM_PROC. ;;; 4. For .scm files, we pull out the sexps matching define*-public & ;;; define-public, but we don't do anything with them yet. So, I still need to add output for the scheme code and I need to add in parsing & output for anything else that's been added since I stopped tracking the perl version. Ideally, I'd like to hear exactly what tags are being used in the source code & exactly what the output is. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Nov 16 16:59:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA03061 for scwm-discuss-outgoing; Mon, 16 Nov 1998 16:59:49 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA03058 for ; Mon, 16 Nov 1998 16:59:49 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA04435; Mon, 16 Nov 98 16:59:28 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA07851; Mon, 16 Nov 1998 13:59:27 -0800 (PST) To: scwm-discuss@mit.edu Subject: Re: windows on other desks mapped on shutdown References: <199811151852.NAA12440@huis-clos.mit.edu> From: Greg Badros Date: 16 Nov 1998 13:59:27 -0800 In-Reply-To: Sam Steingold's message of "16 Nov 1998 11:53:06 -0500" Message-Id: Lines: 29 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >> You need to: > >> > >> (define scwm-no-move-windows-on-exit #t) > >> > >> if your scwmrc hasn't already defined the name. > > IMO, this is wrong. > If I want documentation for this variable (in emacs), it must be in > scwm-obarray, and it is not, because it is undefined. (and the doc is > absent anyway) IMO, too. (You snipped my N.B. where I explain that this is/was an ugly hack -- also, Maciej says it's no longer relevant, anyway). > > What's the use of an undocumented user variable? (C) me. Agreed wholeheartedly. > [Well, I remember the times where I set `gnus-boogaboo' to t in .emacs, > it enabled undocumented/unsupported features in an Emacs package - guess > which - and it had no docstring too. Still, I prefer the Linux > approach, where even undocumented is documented - try `man undocumented`.] :-) Greg From owner-scwm-discuss@mit.edu Mon Nov 16 17:01:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03087 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:01:38 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03084 for ; Mon, 16 Nov 1998 17:01:37 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA05308; Mon, 16 Nov 98 17:01:18 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07876; Mon, 16 Nov 1998 14:01:16 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162026.PAA01806@huis-clos.mit.edu> From: Greg Badros Date: 16 Nov 1998 14:01:16 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 15:26:01 EST" Message-Id: Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I think the best solution is to make doc-generation happen > automatically when you change the source files, using the incremental > model as discussed previously. I will probably take a look at doing > this after managing the 0.9 release (I have my hands full with > http://huis-clos.mit.edu/scwm/release-todo.html for now). Even w/ the incremental model, html file generation (using Jade) takes a long time and is compute-bound. I don't recommend that it get done too frequently, or we'll overstay our welcome on huis-clos. Greg From owner-scwm-discuss@mit.edu Mon Nov 16 17:03:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03112 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:03:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03099; Mon, 16 Nov 1998 17:02:57 -0500 Message-Id: <199811162202.RAA03099@huis-clos.mit.edu> To: Todd Larason cc: Arturo Perez cc: scwm-discuss@mit.edu Subject: Re: Wharf support In-reply-to: Your message of "Mon, 16 Nov 1998 13:49:24 PST." <19981116134924.A27701@molehill.org> Date: Mon, 16 Nov 1998 17:02:57 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981116, Arturo Perez wrote: > > I've been lurking here for a while. I've decided that it may be time to > > switch to scwm but I need to know something first. > > > > I currently use AfterStep. There are really only two reasons why: > > 1) I like the polished look of it. > > 2) The Wharf. > > > > Is there support for a wharf in scwm? > > Probably not right now. How hard it would be to add would depend on how far > AfterStep's module interface has diverged from fvwm's, and exactly what part > of fvwm's it uses. > Actually, recent versions of fvwm2 have an FvwmWharf module backported from AfterStep which should work with scwm. Of cource, using fvwm2 modules is still a bit painful (mainly because you have to write stuff in the icky configuration language of each individual module to configure it). Once I find a free weekend to debug scwm's guile-gtk support, there should be native scwm replacements for the wharf, FvwmTaskBar, FvwmGoodStuff, FvwmButtons, etc. I can't say when that will happen though. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 17:03:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03123 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:03:23 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03120 for ; Mon, 16 Nov 1998 17:03:22 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA05965; Mon, 16 Nov 98 17:03:01 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA07895; Mon, 16 Nov 1998 14:02:47 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162053.PAA02084@huis-clos.mit.edu> From: Greg Badros Date: 16 Nov 1998 14:02:47 -0800 In-Reply-To: hjstein@bfr.co.il's message of "16 Nov 1998 23:12:29 +0200" Message-Id: Lines: 11 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I'm willing to bring extract.scm up to date if someone will tell me > exactly what features I have to add. I really don't want to sit down > with the perl script & try to figure it out. I can do this before the end of the week (I'm at a conference right now, so it'll have to wait until Thursday or Friday). The cvs log may provide enough information to get started on the changes... Greg From owner-scwm-discuss@mit.edu Mon Nov 16 17:06:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03224 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:06:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03214; Mon, 16 Nov 1998 17:06:36 -0500 Message-Id: <199811162206.RAA03214@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 14:01:16 PST." Date: Mon, 16 Nov 1998 17:06:36 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I think the best solution is to make doc-generation happen > > automatically when you change the source files, using the incremental > > model as discussed previously. I will probably take a look at doing > > this after managing the 0.9 release (I have my hands full with > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > Even w/ the incremental model, html file generation (using Jade) takes a > long time and is compute-bound. I don't recommend that it get done too > frequently, or we'll overstay our welcome on huis-clos. > For now I only want to make the sgml get built on each compilation, not the html. I don't have a working Jade setup yet anyway. In the long run, I think I'm satisfied to have html be built only on request or when doing a `make dist'. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 17:23:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03678 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:23:33 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03674 for ; Mon, 16 Nov 1998 17:23:29 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13288; Mon, 16 Nov 98 17:23:01 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA06389; Tue, 17 Nov 1998 00:22:54 +0200 To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162206.RAA03214@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Nov 1998 00:22:53 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 17:06:36 EST" Message-Id: Lines: 32 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > gjb@cs.washington.edu writes: > > Maciej Stachowiak writes: > > > > > I think the best solution is to make doc-generation happen > > > automatically when you change the source files, using the incremental > > > model as discussed previously. I will probably take a look at doing > > > this after managing the 0.9 release (I have my hands full with > > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > > > Even w/ the incremental model, html file generation (using Jade) takes a > > long time and is compute-bound. I don't recommend that it get done too > > frequently, or we'll overstay our welcome on huis-clos. > > > > For now I only want to make the sgml get built on each compilation, > not the html. I don't have a working Jade setup yet anyway. In the > long run, I think I'm satisfied to have html be built only on request > or when doing a `make dist'. Why do you want to build the SGML? The checking that the extractor does is independent of ouput. Or is it that you want it up to date in the repository? I'd think it's the scwm-procedures.txt that needs to be up to date - the emacs interface uses it, doesn't it? Does anyone need the SGML output out of the CVS repository, or can they wait for a snapshot or build it themselves? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Nov 16 17:27:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03789 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:27:52 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03785; Mon, 16 Nov 1998 17:27:51 -0500 Message-Id: <199811162227.RAA03785@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Annoying automake bug Date: Mon, 16 Nov 1998 17:27:51 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk So automake has this annoying bug not fixed in the last release but fixed in CVS that complains about scwmdoc and scwmdoc.scm being generated from extract-docs and extract.scm respectively. I'd ignore this, but it makes `make dist' fail. The options are: * Start using a CVS development version of automake for scwm. * Rename exctract-docs and exctract.scm to scwmdoc.in and scwmdoc.scm.in respectively. This is annoying mainly because CVS can't properly track revision-control info across a delete. I am leaning towards the latter. Any other opinions? This is the only thing I need to resolve before releaseing 0.9beta1 (obviously the rest of my release-todo list still needs to be handled before the final 0.9). - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 17:29:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03876 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:29:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03855; Mon, 16 Nov 1998 17:29:47 -0500 Message-Id: <199811162229.RAA03855@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "17 Nov 1998 00:22:53 +0200." Date: Mon, 16 Nov 1998 17:29:47 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > gjb@cs.washington.edu writes: > > > Maciej Stachowiak writes: > > > > > > > I think the best solution is to make doc-generation happen > > > > automatically when you change the source files, using the incremental > > > > model as discussed previously. I will probably take a look at doing > > > > this after managing the 0.9 release (I have my hands full with > > > > http://huis-clos.mit.edu/scwm/release-todo.html for now). > > > > > > Even w/ the incremental model, html file generation (using Jade) takes a > > > long time and is compute-bound. I don't recommend that it get done too > > > frequently, or we'll overstay our welcome on huis-clos. > > > > > > > For now I only want to make the sgml get built on each compilation, > > not the html. I don't have a working Jade setup yet anyway. In the > > long run, I think I'm satisfied to have html be built only on request > > or when doing a `make dist'. > > Why do you want to build the SGML? The checking that the extractor > does is independent of ouput. Or is it that you want it up to date in > the repository? I'd think it's the scwm-procedures.txt that needs to > be up to date - the emacs interface uses it, doesn't it? Does anyone > need the SGML output out of the CVS repository, or can they wait for a > snapshot or build it themselves? > You're right, only the checking and the .txt files really need to be redone on each compile. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 17:34:45 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03976 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:34:45 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03972 for ; Mon, 16 Nov 1998 17:34:44 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17260; Mon, 16 Nov 98 17:34:20 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA06481; Tue, 17 Nov 1998 00:34:21 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Nov 1998 00:34:21 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 17:29:47 EST" Message-Id: Lines: 14 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > You're right, only the checking and the .txt files really need to be > redone on each compile. The incremental stuff is still going to crawl like a slug because Guile's startup time sucks so bad. BTW, I checked in my changes. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Nov 16 17:38:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04084 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:38:36 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04075; Mon, 16 Nov 1998 17:38:29 -0500 Message-Id: <199811162238.RAA04075@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "17 Nov 1998 00:34:21 +0200." Date: Mon, 16 Nov 1998 17:38:28 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > You're right, only the checking and the .txt files really need to be > > redone on each compile. > > The incremental stuff is still going to crawl like a slug because > Guile's startup time sucks so bad. > I'd momentarily forgotten about that. I won't enable it in the Makefiles until I find a way to deal with the startup issue, then. > BTW, I checked in my changes. > Excellent. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 17:52:23 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04519 for scwm-discuss-outgoing; Mon, 16 Nov 1998 17:52:23 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA04515; Mon, 16 Nov 1998 17:52:23 -0500 Message-Id: <199811162252.RAA04515@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Rubberbanding and color allocation Date: Mon, 16 Nov 1998 17:52:23 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Or, yet another clueless X11 question. Robert Bihlmeyer reported a while back that scwm sometimes crashes on an attempt to do a rubberband move on an 8-bit display because it fails to allocate a color. I've observed this behavior as well. However, I can't figure out why scwm is allocating a color when rubberbanding. There don't appear to be any color-allocating calls in the rubberbanding code, as far as I can tell. Can anyone shed light on this? - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 18:50:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04972 for scwm-discuss-outgoing; Mon, 16 Nov 1998 18:50:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA04969 for ; Mon, 16 Nov 1998 18:50:32 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA09085; Mon, 16 Nov 98 18:50:00 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 16 Nov 1998 18:49:53 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 16 Nov 1998 18:49:53 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id SAA10784; Mon, 16 Nov 1998 18:49:59 -0500 Date: Mon, 16 Nov 1998 18:49:59 -0500 From: "Sam Steingold" Message-Id: <199811162349.SAA10784@eho.eaglets.com> To: mstachow@mit.edu, scwm-discuss@mit.edu Subject: Re: Rubberbanding and color allocation Sender: owner-scwm-discuss@mit.edu Precedence: bulk *without looking at the sources* - it would seem that rubberbanding has to allocate the colors for the rubber band - right? From owner-scwm-discuss@mit.edu Mon Nov 16 18:53:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04986 for scwm-discuss-outgoing; Mon, 16 Nov 1998 18:53:14 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA04980 for ; Mon, 16 Nov 1998 18:52:44 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA09639; Mon, 16 Nov 98 18:52:11 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 16 Nov 1998 18:52:05 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 16 Nov 1998 18:52:05 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id SAA10838; Mon, 16 Nov 1998 18:52:12 -0500 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162238.RAA04075@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 17:38:28 EST" Date: 16 Nov 1998 18:52:12 -0500 Message-Id: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199811162238.RAA04075@huis-clos.mit.edu> >>>> On the subject of "Re: docs: scwm-procedures.txt" >>>> Sent on Mon, 16 Nov 1998 17:38:28 EST >>>> Honorable Maciej Stachowiak writes: >> hjstein@bfr.co.il writes: >> > Maciej Stachowiak writes: >> > >> > The incremental stuff is still going to crawl like a slug because >> > Guile's startup time sucks so bad. >> > >> >> I'd momentarily forgotten about that. I won't enable it in the >> Makefiles until I find a way to deal with the startup issue, then. what about making that optional? or, what about moving that to configure time? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Please wait, MS Windows are preparing the blue screen of death. From owner-scwm-discuss@mit.edu Mon Nov 16 19:58:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA05369 for scwm-discuss-outgoing; Mon, 16 Nov 1998 19:58:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA05363 for ; Mon, 16 Nov 1998 19:57:59 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24995; Mon, 16 Nov 98 19:57:32 EST Received: (qmail 28986 invoked by uid 501); 17 Nov 1998 00:57:30 -0000 Message-Id: <19981116165729.A28935@molehill.org> Date: Mon, 16 Nov 1998 16:57:29 -0800 From: Todd Larason To: Sam Steingold , mstachow@mit.edu, scwm-discuss@mit.edu Subject: Re: Rubberbanding and color allocation References: <199811162349.SAA10784@eho.eaglets.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811162349.SAA10784@eho.eaglets.com>; from Sam Steingold on Mon, Nov 16, 1998 at 06:49:59PM -0500 X-Tom-Swifty: "Now how can I trick Sidney?" Tom considered. X-Kibo: I think you are allowed to be dark part of the time. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981116, Sam Steingold wrote: > *without looking at the sources* - it would seem that rubberbanding > has to allocate the colors for the rubber band - right? No. Or not obviously so. The rubberband is drawn with a GC whose function is GXxor; the 'foreground' field in the GC is a mask to XOR with the source. But maybe XCreateGC allocates a color for foreground even though it isn't actually used as a color? I used a Mac last week rather more than I usually do, and I noticed how much nicer its rubberband-equivalent is. It consists of dashed lines tracing both the outside and inside border of the window decoration; with nonstandard utilities (or the appearance manager in MacOS 8.5 I expect), the outer border isn't necessarily a simple rectangle. I don't like fvwm-style rubberbanding, but I think I could get used to the Mac style. Judging by the comment at the beginning of set_rubber_band_mask_x, this would be expensive on X servers without overlay planes though? From owner-scwm-discuss@mit.edu Mon Nov 16 21:11:33 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05811 for scwm-discuss-outgoing; Mon, 16 Nov 1998 21:11:33 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05804; Mon, 16 Nov 1998 21:11:24 -0500 Message-Id: <199811170211.VAA05804@huis-clos.mit.edu> To: "Sam Steingold" cc: scwm-discuss@mit.edu Subject: Re: Rubberbanding and color allocation In-reply-to: Your message of "Mon, 16 Nov 1998 18:49:59 EST." <199811162349.SAA10784@eho.eaglets.com> Date: Mon, 16 Nov 1998 21:11:24 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@eaglets.com writes: > *without looking at the sources* - it would seem that rubberbanding > has to allocate the colors for the rubber band - right? Actually, no; the rubber band mask is just a value that gets XOR'd with the underlying pixels, and I was pretty sure no color is ever allocated for it. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 21:13:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05847 for scwm-discuss-outgoing; Mon, 16 Nov 1998 21:13:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA05839; Mon, 16 Nov 1998 21:13:20 -0500 Message-Id: <199811170213.VAA05839@huis-clos.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "16 Nov 1998 18:52:12 EST." Date: Mon, 16 Nov 1998 21:13:20 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199811162238.RAA04075@huis-clos.mit.edu> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on Mon, 16 Nov 1998 17:38:28 EST > >>>> Honorable Maciej Stachowiak writes: > >> hjstein@bfr.co.il writes: > >> > Maciej Stachowiak writes: > >> > > >> > The incremental stuff is still going to crawl like a slug because > >> > Guile's startup time sucks so bad. > >> > > >> > >> I'd momentarily forgotten about that. I won't enable it in the > >> Makefiles until I find a way to deal with the startup issue, then. > > what about making that optional? > or, what about moving that to configure time? > When I do enable it, I'll almost certainly set things up so pre-generated doc files are shipped with releases, so this should not affect end-users. Even so, it might be a good plan to enable it as a configure-time option soonish so the functionality can be tested. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 16 21:48:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08301 for scwm-discuss-outgoing; Mon, 16 Nov 1998 21:48:15 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA08295; Mon, 16 Nov 1998 21:48:10 -0500 Message-Id: <199811170248.VAA08295@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Rubberbanding and color allocation In-reply-to: Your message of "Mon, 16 Nov 1998 16:57:29 PST." <19981116165729.A28935@molehill.org> Date: Mon, 16 Nov 1998 21:48:10 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981116, Sam Steingold wrote: > > *without looking at the sources* - it would seem that rubberbanding > > has to allocate the colors for the rubber band - right? > > No. Or not obviously so. > And in fact, I just found where it happens - in DisplayMessage, which gets called to pop up the message window during moves. I don't think it is rubberband-related per se. I will try to make this allocation happen earlier so life can go on if it fails. > > I used a Mac last week rather more than I usually do, and I noticed how much > nicer its rubberband-equivalent is. It consists of dashed lines tracing both > the outside and inside border of the window decoration; with nonstandard > utilities (or the appearance manager in MacOS 8.5 I expect), the outer border > isn't necessarily a simple rectangle. I don't like fvwm-style rubberbanding, > but I think I could get used to the Mac style. > > Judging by the comment at the beginning of set_rubber_band_mask_x, this would > be expensive on X servers without overlay planes though? I don't even know what overlay planes are (the comment seems to be attributed to me but I did not write it). It seems that it would be at least possibly doable by creating a shaped window in the shape of the rubberband, but that would be ugly. Also, it would be possible to just draw the funny shape by xoring like we do now, erase should not be that much more expensive. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 17 03:24:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA17971 for scwm-discuss-outgoing; Tue, 17 Nov 1998 03:24:29 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA17968 for ; Tue, 17 Nov 1998 03:24:28 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA20185; Tue, 17 Nov 98 03:24:12 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA10574; Tue, 17 Nov 1998 10:24:08 +0200 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162238.RAA04075@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 17 Nov 1998 10:24:07 +0200 In-Reply-To: Sam Steingold's message of "16 Nov 1998 18:52:12 -0500" Message-Id: Lines: 61 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message <199811162238.RAA04075@huis-clos.mit.edu> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on Mon, 16 Nov 1998 17:38:28 EST > >>>> Honorable Maciej Stachowiak writes: > >> hjstein@bfr.co.il writes: > >> > Maciej Stachowiak writes: > >> > > >> > The incremental stuff is still going to crawl like a slug because > >> > Guile's startup time sucks so bad. > >> > > >> > >> I'd momentarily forgotten about that. I won't enable it in the > >> Makefiles until I find a way to deal with the startup issue, then. > > what about making that optional? > or, what about moving that to configure time? Well, crawl is subjective. On my office machine (PII 300) it means about 1-2 seconds extra per file compilation. Here are the timings: start & exit (no args) - 1.03 seconds. Generate .pdoc file from window.c - 2.05 seconds. Generate .txt file from window.c - 2.10 seconds. Generate .txt file from window.pdoc - 1.47 seconds. Generate .txt file from window.pdoc, no checking - 0.89 seconds. window.c is the largest C file in the distribution. I don't know why the last one was faster than start & exit. It doesn't make any sense. No checking means not cross-checking the validity of the extracted documentation (bad # args, etc). This need not be done twice. Anyway, the original point was to avoid regenerating scwm-procedures.txt from all the .c code each time one does make. Of course, there's going to be some cost to this, and it's bigger than we'd want because the guile people refuse to follow up on any of the short term guile startup time fixes. But, it still helps: Generate .txt from all .c files - 5.42 seconds. Generate .txt from all .c files, no checking - 4.00 seconds. Generate .txt from all .pdoc files - 2.63 seconds. Generate .txt from all .pdoc files, no checking - 1.14 seconds. So, if it's recreating the .pdoc when a C file is modified & regenerating the scwm-procedures.txt from all the pdoc files vs regenerating scwm-procedures.txt from all the C files whenever you make scwm, it's ~2.5-3 seconds for the former, vs ~5.4 for the latter. Not much of a difference either way on my machine. If it wasn't for the shitty guile startup time, it'd be more like 1 second vs 4.6. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Nov 17 11:44:48 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA20934 for scwm-discuss-outgoing; Tue, 17 Nov 1998 11:44:48 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA20931 for ; Tue, 17 Nov 1998 11:44:45 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA25828; Tue, 17 Nov 98 11:44:41 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA10685; Tue, 17 Nov 1998 08:44:39 -0800 (PST) To: Maciej Stachowiak Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: Rubberbanding and color allocation References: <199811170248.VAA08295@huis-clos.mit.edu> From: Greg Badros Date: 17 Nov 1998 08:44:39 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 21:48:10 EST" Message-Id: Lines: 40 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > jtl wrote: > > I used a Mac last week rather more than I usually do, and I noticed how much > > nicer its rubberband-equivalent is. It consists of dashed lines tracing both > > the outside and inside border of the window decoration; with nonstandard > > utilities (or the appearance manager in MacOS 8.5 I expect), the outer border > > isn't necessarily a simple rectangle. I don't like fvwm-style rubberbanding, > > but I think I could get used to the Mac style. > > > > Judging by the comment at the beginning of set_rubber_band_mask_x, this would > > be expensive on X servers without overlay planes though? > > I don't even know what overlay planes are (the comment seems to be > attributed to me but I did not write it). It seems that it would be at > least possibly doable by creating a shaped window in the shape of the > rubberband, but that would be ugly. Also, it would be possible to just > draw the funny shape by xoring like we do now, erase should not be > that much more expensive. Yea; the big problem w/ no overlay planes is that you have to grab the X server when doing any XOR drawing (otherwise client windows could change their appearance before the rubberband is erased). I've still not figured out how to use overlay planes within the window manager (I only know how within a single client application window). Any pointers or tips are appreciated. Xi Graphics donated their Accelerated X server to me so I could use the overlay plane for some of the constraint representation work I'm going to be doing, but so far this techhnical difficulty has been a show stopper. FYI, overlay planes are reserved bits in video memory that can be drawn to and erased separately from the underlying main image. You can think of it like putting a piece of transparency over the real screen and drawing and erasing to and from that transparency. In general, overlay planes require hardware support and an X server that supports them (e.g., XFree86 v3.0 does *not*). Greg From owner-scwm-discuss@mit.edu Tue Nov 17 15:56:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA28969 for scwm-discuss-outgoing; Tue, 17 Nov 1998 15:56:47 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA28965; Tue, 17 Nov 1998 15:56:46 -0500 Message-Id: <199811172056.PAA28965@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: __FUNCTION__ Date: Tue, 17 Nov 1998 15:56:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I was just doing a test build of the imminent 0.9beta1 on Solaris with the Sun compiler and stumbled over the gcc-ism. Any objections to it going away? I'll use the #define FUNC_NAME convention or something in a hypothetical replacement. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 17 16:43:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA29319 for scwm-discuss-outgoing; Tue, 17 Nov 1998 16:43:29 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA29315 for ; Tue, 17 Nov 1998 16:43:21 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id WAA00683 for scwm-discuss@huis-clos.mit.edu; Tue, 17 Nov 1998 22:30:43 +0100 (MET) Received: (qmail 5363 invoked by uid 115); 17 Nov 1998 19:46:22 -0000 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162134.QAA02597@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 17 Nov 1998 20:46:17 +0100 In-Reply-To: Maciej Stachowiak's message of "Mon, 16 Nov 1998 16:34:41 EST" Message-ID: Lines: 19 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 16 Nov 1998 16:34:41 EST >>>>> Maciej Stachowiak said: Maciej> Excellent. I can't believe we debated this for like a week Maciej> and then waited for sevral more weeks and it just took a few Maciej> minutes of coding. Didn't they teach you in school that time put into systems design will earn you plentiful time savings while implementing the thing? So the event rewrite will be done in about half an hour, won't it? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Nov 17 16:43:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA29322 for scwm-discuss-outgoing; Tue, 17 Nov 1998 16:43:38 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id QAA29318 for ; Tue, 17 Nov 1998 16:43:27 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id WAA00687 for scwm-discuss@huis-clos.mit.edu; Tue, 17 Nov 1998 22:30:45 +0100 (MET) Received: (qmail 5374 invoked by uid 115); 17 Nov 1998 19:50:55 -0000 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 17 Nov 1998 20:50:51 +0100 In-Reply-To: hjstein@bfr.co.il's message of "17 Nov 1998 00:34:21 +0200" Message-ID: Lines: 20 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 17 Nov 1998 00:34:21 +0200 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> Maciej Stachowiak writes: >> You're right, only the checking and the .txt files really need to >> be redone on each compile. Harvey> The incremental stuff is still going to crawl like a slug Harvey> because Guile's startup time sucks so bad. Most of us have guile already loaded - inside our window managers. Why not scwmexec it? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Tue Nov 17 18:07:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31359 for scwm-discuss-outgoing; Tue, 17 Nov 1998 18:07:10 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31353 for ; Tue, 17 Nov 1998 18:06:50 -0500 Received: from bologna.nettuno.it by MIT.EDU with SMTP id AA22986; Tue, 17 Nov 98 18:06:24 EST Received: from mizar (root@ppp21-nas0.vi.nettuno.it [193.207.146.230]) by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id AAA17601 for ; Wed, 18 Nov 1998 00:06:14 +0100 (MET) Received: by mizar via sendmail from stdin id (Debian Smail3.2.0.101) for scwm-discuss@mit.edu; Tue, 17 Nov 1998 22:56:14 +0100 (CET) Message-Id: <19981117225614.A15467@mizar> Date: Tue, 17 Nov 1998 22:56:14 +0100 From: Francesco Tapparo To: scwm-discuss@mit.edu Subject: make distclean Reply-To: f.tapparo@vi.nettuno.it Mail-Followup-To: scwm-discuss@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-scwm-discuss@mit.edu Precedence: bulk I noted that "make distclean" don't remove the symlink app/scwm (created in the build process). This is against the gnu build standards. I admit, this was not a grave issue, but anyway... Moreover this fact was a little annoying, because of some tools I use to produce the scwm .debs (they used to complain about the scwm symlink and then exit with an error). So I applied the following micro-diff: ================================================== --- Makefile.am Sun Sep 20 22:02:43 1998 +++ Makefile.am.patched Sun Sep 20 22:05:32 1998 @@ -1,6 +1,7 @@ noinst_DATA = scwm +DISTCLEANFILES = scwm scwm: ${top_srcdir}/scheme if [ "$(LN_S)" = "ln -s" ]; then \ =================================================== to app/Makefile.am. Now the symlink is removed (and the build process is more conform to the gnu standards, too). Regards Francesco From owner-scwm-discuss@mit.edu Tue Nov 17 18:13:36 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31401 for scwm-discuss-outgoing; Tue, 17 Nov 1998 18:13:36 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31398 for ; Tue, 17 Nov 1998 18:13:36 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16805; Tue, 17 Nov 98 18:13:33 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA13004; Tue, 17 Nov 1998 15:13:31 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ References: <199811172056.PAA28965@huis-clos.mit.edu> From: Greg Badros Date: 17 Nov 1998 15:13:31 -0800 In-Reply-To: Maciej Stachowiak's message of "Tue, 17 Nov 1998 15:56:45 EST" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I was just doing a test build of the imminent 0.9beta1 on Solaris with > the Sun compiler and stumbled over the gcc-ism. Any objections to it > going away? I'll use the #define FUNC_NAME convention or something in > a hypothetical replacement. That's fine. Maybe we can put: #ifndef __FUNCTION__ #define __FUNCTION__ "unknown-function-name-because-not-gcc" #endif somewhere (though the uses in face.c that are for scheme error messages should be fixed more appropriately using FUNC_NAME or a passed string argument). Greg From owner-scwm-discuss@mit.edu Tue Nov 17 18:16:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA31452 for scwm-discuss-outgoing; Tue, 17 Nov 1998 18:16:41 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA31446 for ; Tue, 17 Nov 1998 18:16:37 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26025; Tue, 17 Nov 98 18:16:23 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA13009; Tue, 17 Nov 1998 15:16:08 -0800 (PST) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> From: Greg Badros Date: 17 Nov 1998 15:16:07 -0800 In-Reply-To: Robert Bihlmeyer's message of "17 Nov 1998 20:50:51 +0100" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 17 Nov 1998 00:34:21 +0200 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> Maciej Stachowiak writes: > >> You're right, only the checking and the .txt files really need to > >> be redone on each compile. > > Harvey> The incremental stuff is still going to crawl like a slug > Harvey> because Guile's startup time sucks so bad. > > Most of us have guile already loaded - inside our window managers. Why > not scwmexec it? Because it'll stop interactive response of our windowing system. :-( Some other guile-server approaches exist, though, don't they? Greg From owner-scwm-discuss@mit.edu Tue Nov 17 18:59:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA00591 for scwm-discuss-outgoing; Tue, 17 Nov 1998 18:59:39 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA00583; Tue, 17 Nov 1998 18:59:36 -0500 Message-Id: <199811172359.SAA00583@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ In-reply-to: Your message of "17 Nov 1998 15:13:31 PST." Date: Tue, 17 Nov 1998 18:59:36 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I was just doing a test build of the imminent 0.9beta1 on Solaris with > > the Sun compiler and stumbled over the gcc-ism. Any objections to it > > going away? I'll use the #define FUNC_NAME convention or something in > > a hypothetical replacement. > > That's fine. Maybe we can put: > > #ifndef __FUNCTION__ > #define __FUNCTION__ "unknown-function-name-because-not-gcc" > #endif > > somewhere (though the uses in face.c that are for scheme error messages > should be fixed more appropriately using FUNC_NAME or a passed string argument). > I don't think we should be relying on a gcc-ism for proper warnings or errors (especially since I am going to be personally using Sun Workshop built binaries at work). Hence, I've replaced __FUNCTION__ with FUNC_NAME and appropriate #define/#undef pairs throughout. I'm going to commit it shortly so the release is at least half sane, we can always back it out or otherwise reconsider later. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 17 19:13:53 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06463 for scwm-discuss-outgoing; Tue, 17 Nov 1998 19:13:53 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06460 for ; Tue, 17 Nov 1998 19:13:50 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11298; Tue, 17 Nov 98 19:13:49 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA13132; Tue, 17 Nov 1998 16:13:47 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ References: <199811172359.SAA00583@huis-clos.mit.edu> From: Greg Badros Date: 17 Nov 1998 16:13:47 -0800 In-Reply-To: Maciej Stachowiak's message of "Tue, 17 Nov 1998 18:59:36 EST" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I don't think we should be relying on a gcc-ism for proper warnings or > errors (especially since I am going to be personally using Sun > Workshop built binaries at work). Hence, I've replaced __FUNCTION__ Then you're completely right -- it only makes sense if all the devs are using compilers that support __FUNCTION__ (I'm surprised Sun CC doesn't have that extension). > with FUNC_NAME and appropriate #define/#undef pairs throughout. I'm > going to commit it shortly so the release is at least half sane, we > can always back it out or otherwise reconsider later. Sounds good. Greg From owner-scwm-discuss@mit.edu Tue Nov 17 19:34:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06755 for scwm-discuss-outgoing; Tue, 17 Nov 1998 19:34:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06752 for ; Tue, 17 Nov 1998 19:34:57 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA07363; Tue, 17 Nov 98 19:34:53 EST Received: (qmail 3920 invoked by uid 501); 18 Nov 1998 00:34:54 -0000 Message-Id: <19981117163454.A3889@molehill.org> Date: Tue, 17 Nov 1998 16:34:54 -0800 From: Todd Larason To: Greg Badros , Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ References: <199811172359.SAA00583@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Tue, Nov 17, 1998 at 04:13:47PM -0800 X-Tom-Swifty: "I meant to pay this year's dues", Tom remembered. X-Kibo: I think nobody is false much of the time. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981117, Greg Badros wrote: > Then you're completely right -- it only makes sense if all the devs are > using compilers that support __FUNCTION__ (I'm surprised Sun CC doesn't > have that extension). the C9x draft includes a nearly identical __func__ identifier. Perhaps the newest Sun CC supports it? From owner-scwm-discuss@mit.edu Tue Nov 17 19:34:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06745 for scwm-discuss-outgoing; Tue, 17 Nov 1998 19:34:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06740; Tue, 17 Nov 1998 19:34:38 -0500 Message-Id: <199811180034.TAA06740@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ In-reply-to: Your message of "17 Nov 1998 16:13:47 PST." Date: Tue, 17 Nov 1998 19:34:38 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I don't think we should be relying on a gcc-ism for proper warnings or > > errors (especially since I am going to be personally using Sun > > Workshop built binaries at work). Hence, I've replaced __FUNCTION__ > > Then you're completely right -- it only makes sense if all the devs are > using compilers that support __FUNCTION__ I won't be doing development at work, mind you, but obviously if I see a waning I need to know what to do with/about it. > (I'm surprised Sun CC doesn't have that extension). I think c9x will define a different way to do the same thing, so probably they support that, if anything. > > with FUNC_NAME and appropriate #define/#undef pairs throughout. I'm > > going to commit it shortly so the release is at least half sane, we > > can always back it out or otherwise reconsider later. > > Sounds good. > Cool, well, it's done. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 17 19:40:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA06915 for scwm-discuss-outgoing; Tue, 17 Nov 1998 19:40:42 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA06911 for ; Tue, 17 Nov 1998 19:40:41 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16855; Tue, 17 Nov 98 19:40:39 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA13170; Tue, 17 Nov 1998 16:40:34 -0800 (PST) To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: __FUNCTION__ References: <199811172359.SAA00583@huis-clos.mit.edu> <19981117163454.A3889@molehill.org> From: Greg Badros Date: 17 Nov 1998 16:40:34 -0800 In-Reply-To: Todd Larason's message of "Tue, 17 Nov 1998 16:34:54 -0800" Message-Id: Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981117, Greg Badros wrote: > > Then you're completely right -- it only makes sense if all the devs are > > using compilers that support __FUNCTION__ (I'm surprised Sun CC doesn't > > have that extension). > > the C9x draft includes a nearly identical __func__ identifier. Perhaps the > newest Sun CC supports it? Does gcc/egcs? Greg From owner-scwm-discuss@mit.edu Tue Nov 17 20:21:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07442 for scwm-discuss-outgoing; Tue, 17 Nov 1998 20:21:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07431; Tue, 17 Nov 1998 20:21:45 -0500 Message-Id: <199811180121.UAA07431@huis-clos.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: __FUNCTION__ In-reply-to: Your message of "Tue, 17 Nov 1998 16:34:54 PST." <19981117163454.A3889@molehill.org> Date: Tue, 17 Nov 1998 20:21:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981117, Greg Badros wrote: > > Then you're completely right -- it only makes sense if all the devs are > > using compilers that support __FUNCTION__ (I'm surprised Sun CC doesn't > > have that extension). > > the C9x draft includes a nearly identical __func__ identifier. Perhaps the > newest Sun CC supports it? I was wondering this myself; the answer is no, at least for the version I have. Doing it by hand is painful, 'tis true, but I think it will be a year or two yet before we can realy on __func__ and be sufficently portable. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 17 20:46:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07876 for scwm-discuss-outgoing; Tue, 17 Nov 1998 20:46:07 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA07866; Tue, 17 Nov 1998 20:46:02 -0500 Message-Id: <199811180146.UAA07866@huis-clos.mit.edu> To: f.tapparo@vi.nettuno.it cc: scwm-discuss@mit.edu Subject: Re: make distclean In-reply-to: Your message of "Tue, 17 Nov 1998 22:56:14 +0100." <19981117225614.A15467@mizar> Date: Tue, 17 Nov 1998 20:46:02 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cesco@mizar.mit.edu writes: > I noted that "make distclean" don't remove the symlink app/scwm (created in > the build process). This is against the gnu build standards. I admit, this was > not a grave issue, but anyway... > Moreover this fact was a little annoying, because of some tools I use to > produce the scwm .debs (they used to complain about the scwm symlink and then > exit with an error). So I applied the following micro-diff: > Applied. Thanks! - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 02:20:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA17688 for scwm-discuss-outgoing; Wed, 18 Nov 1998 02:20:30 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id CAA17685 for ; Wed, 18 Nov 1998 02:20:29 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id CAA28247 for ; Wed, 18 Nov 1998 02:20:24 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id CAA07302 for ; Wed, 18 Nov 1998 02:20:23 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with ESMTP id CAA06419 for ; Wed, 18 Nov 1998 02:20:55 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Wed, 18 Nov 1998 02:20:55 -0500 (EST) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Minor bugs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Since the 0.9 release is coming up soon, I figure I'll list a few minor bugs that I have with the current scwm. 1. auto-raise-unfocus isn't working. I tried to figure out how to fix it, but so far haven't gotten it working properly. 2. Menus only appear over kept-on-top windows after the menu has been displayed twice. They should be displayed on the first shot. 3. The session manager code isn't writing out the proper width and height of clients. My xsm window gets sized too tall and wide when I start my session. Just FYI, my changed.c is: char *szRepoLastChanged = "Tue Nov 17 23:45:32 EST 1998 -- $Revision: 1.903 $"; See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Nov 18 02:55:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA18171 for scwm-discuss-outgoing; Wed, 18 Nov 1998 02:55:01 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA18168 for ; Wed, 18 Nov 1998 02:55:00 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA03472; Wed, 18 Nov 98 02:54:55 EST Received: (qmail 5836 invoked by uid 501); 18 Nov 1998 07:54:54 -0000 Message-Id: <19981117235453.A5747@molehill.org> Date: Tue, 17 Nov 1998 23:54:53 -0800 From: Todd Larason To: Craig Struble , scwm-discuss@mit.edu Subject: Re: Minor bugs References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Craig Struble on Wed, Nov 18, 1998 at 02:20:55AM -0500 X-Tom-Swifty: "Crosby is my favourite singer. Is he yours?" asked Tom probingly. X-Kibo: Why not understand everything? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981118, Craig Struble wrote: > 2. Menus only appear over kept-on-top windows after the menu > has been displayed twice. They should be displayed on the > first shot. Can you give more details on this? I can't reproduce it. What other window styles do you use along with keep-on-top? What menu style do you use? How do you open the menu? (keystroke, mouse button on root window, mouse button on window decoration?) Thanks for the report! From owner-scwm-discuss@mit.edu Wed Nov 18 03:04:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18307 for scwm-discuss-outgoing; Wed, 18 Nov 1998 03:04:07 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA18304 for ; Wed, 18 Nov 1998 03:04:06 -0500 From: mal@bewoner.dma.be Received: from dialup545.brussels.skynet.be by MIT.EDU with SMTP id AA04292; Wed, 18 Nov 98 03:03:55 EST Received: (qmail 6791 invoked by uid 500); 18 Nov 1998 08:09:12 -0000 Date: 18 Nov 1998 08:09:12 -0000 Message-Id: <19981118080912.6790.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: __FUNCTION__ In-Reply-To: References: <199811172359.SAA00583@huis-clos.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Maciej Stachowiak writes: > > > I don't think we should be relying on a gcc-ism for proper warnings or > > errors (especially since I am going to be personally using Sun > > Workshop built binaries at work). Hence, I've replaced __FUNCTION__ > > Then you're completely right -- it only makes sense if all the devs are > using compilers that support __FUNCTION__ (I'm surprised Sun CC doesn't > have that extension). > The C9X draft defines __func__ to be almost the same as gcc __FUNCTION__. So in time it will be able to do this portably. Lieven From owner-scwm-discuss@mit.edu Wed Nov 18 03:08:02 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18368 for scwm-discuss-outgoing; Wed, 18 Nov 1998 03:08:02 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA18363; Wed, 18 Nov 1998 03:08:01 -0500 Message-Id: <199811180808.DAA18363@huis-clos.mit.edu> To: Craig Struble cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-reply-to: Your message of "Wed, 18 Nov 1998 02:20:55 EST." Date: Wed, 18 Nov 1998 03:08:01 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > Since the 0.9 release is coming up soon, I figure I'll list a few minor > bugs that I have with the current scwm. > > 1. auto-raise-unfocus isn't working. I tried to figure out how to > fix it, but so far haven't gotten it working properly. Can you give an example of a particular style, what you expect should happen, and what actually happens? > 3. The session manager code isn't writing out the proper width > and height of clients. My xsm window gets sized too tall and > wide when I start my session. Is this the only windo that gets resized wrong? What window-style are you using for it? - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 03:35:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA19593 for scwm-discuss-outgoing; Wed, 18 Nov 1998 03:35:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA19588; Wed, 18 Nov 1998 03:35:16 -0500 Message-Id: <199811180835.DAA19588@huis-clos.mit.edu> To: Craig Struble cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-reply-to: Your message of "Wed, 18 Nov 1998 02:20:55 EST." Date: Wed, 18 Nov 1998 03:35:16 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > Since the 0.9 release is coming up soon, I figure I'll list a few minor > bugs that I have with the current scwm. > > 1. auto-raise-unfocus isn't working. I tried to figure out how to > fix it, but so far haven't gotten it working properly. Nix my request for more info on this, I reproduced it and fixed it. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 06:09:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id GAA20863 for scwm-discuss-outgoing; Wed, 18 Nov 1998 06:09:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from mars.zserv.tuwien.ac.at (mars.zserv.tuwien.ac.at [193.170.75.15]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id GAA20860 for ; Wed, 18 Nov 1998 06:09:28 -0500 Received: (qmail 23149 invoked by uid 524); 18 Nov 1998 11:09:19 -0000 To: scwm-discuss@mit.edu Subject: themes do not work when srcdir!=builddir X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 18 Nov 1998 12:09:19 +0100 Message-ID: Lines: 14 Organization: Order of Hermes Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Wed Nov 18 03:36:37 EST 1998 -- $Revision: 1.905 $ has problems when srcdir!=builddir. The make fails because the theme directory and its corresponding Makefile is not created. Apart from that scwm built correctly on a FreeBSD-2.2.6 box. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Nov 18 10:00:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21770 for scwm-discuss-outgoing; Wed, 18 Nov 1998 10:00:15 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21767 for ; Wed, 18 Nov 1998 10:00:12 -0500 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA02967; Wed, 18 Nov 98 10:00:04 EST Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id JAA02630; Wed, 18 Nov 1998 09:59:56 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id JAA21904; Wed, 18 Nov 1998 09:59:54 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with ESMTP id KAA12016; Wed, 18 Nov 1998 10:00:20 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Wed, 18 Nov 1998 10:00:19 -0500 (EST) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-Reply-To: <19981117235453.A5747@molehill.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Tue, 17 Nov 1998, Todd Larason wrote: > On 981118, Craig Struble wrote: > > 2. Menus only appear over kept-on-top windows after the menu > > has been displayed twice. They should be displayed on the > > first shot. > > Can you give more details on this? I can't reproduce it. > What other window styles do you use along with keep-on-top? What menu style > do you use? How do you open the menu? (keystroke, mouse button on root > window, mouse button on window decoration?) > > Thanks for the report! > Ok, I've seen both Netscape's and xsm's (athena widgets) menus do this when they overlap with my FvwmPager. In both cases I'm opening the menu with the mouse. So now that I look at my email, I should clarify that it's not scwm's menus causing trouble (Doh!). The style options look like: (define craig-grad-decor (make-decor "craig")) (with-decor craig-grad-decor (title-style #:justify 'left #:font comic-14 #:relief 'flat #:pixmap (make-image "/home/cstruble/themes/Swirl/menuback.xpm") #:inactive (list #:h-gradient (list 40 (list "grey50" 20) "grey50" "grey25"))) (border-style #:no-inset #t #:hidden-handles #t #:pixmap (make-image "/home/cstruble/themes/Swirl/bottom.xpm")) (button-style 1 #:relief 'flat #:tiled-pixmap (make-image "/home/cstruble/themes/Swirl/menuback.xpm") #:pixmap 'mini-program-icon #:inactive (list #:solid "grey50" #:pixmap 'mini-program-icon)) (button-style 2 #:relief 'flat #:tiled-pixmap (make-image "/home/cstruble/themes/Swirl/menuback.xpm") #:pixmap "mini-close.xpm" #:inactive (list #:solid "grey15" #:pixmap "mini-close.xpm")) (button-style 4 #:relief 'flat #:tiled-pixmap (make-image "/home/cstruble/themes/Swirl/menuback.xpm") #:pixmap "mini-exp-windows-full.xpm" #:inactive (list #:solid "grey15" #:pixmap "mini-exp-windows-full.xpm")) (button-style 6 #:relief 'flat #:tiled-pixmap (make-image "/home/cstruble/themes/Swirl/menuback.xpm") #:pixmap "mini-shrink-windows-full.xpm" #:inactive (list #:solid "grey25" #:pixmap "mini-shrink-windows-full.xpm")) (set-hilight-foreground! "white") (set-hilight-background! "grey76")) (define craig-grad-style (make-style #:fg "black" #:bg "grey76" #:show-icon #f #:border-width 6 #:mwm-border #f #:mwm-buttons #f #:plain-border #f #:use-decor craig-grad-decor)) (window-style "*" #:icon-box (list (x- 70) 1 69 (y- 141)) #:focus 'mouse #:icon "unknown1.xpm" #:smart-placement #t #:random-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:hint-override #t #:decorate-transient #t #:PPosition-hint #f #:lenience #t #:mini-icon "mini-x.xpm") (window-style "*" #:use-style craig-grad-style) (define desk-widget (make-style #:plain-border #f #:sticky #t #:winlist-skip #t #:border-width 3 #:circulate-skip #t #:focus 'none)) ;; Inherit above style options and specialize (define desk-widget-on-top (make-style #:use-style desk-widget #:kept-on-top #t)) (define desk-widget-on-top-no-titlebar (make-style #:use-style desk-widget-on-top #:no-titlebar #t)) (window-style "xsm" #:plain-border #f #:sticky #t #:winlist-skip #t #:border-width 3 #:circulate-skip #t #:kept-on-top #t #:no-titlebar #t) (window-style "Netscape" #:icon "netscape.xpm" #:mini-icon "mini-nscape.xpm" #:start-on-desk 2) (window-style "FvwmPager" ; #:other-proc start-once #:use-style desk-widget-on-top-no-titlebar) See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Nov 18 10:05:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA21804 for scwm-discuss-outgoing; Wed, 18 Nov 1998 10:05:44 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA21800 for ; Wed, 18 Nov 1998 10:05:29 -0500 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA25199; Wed, 18 Nov 98 10:05:24 EST Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id KAA03953; Wed, 18 Nov 1998 10:05:24 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id KAA25501; Wed, 18 Nov 1998 10:05:23 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.8.8/8.8.8) with ESMTP id KAA12046; Wed, 18 Nov 1998 10:05:59 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Wed, 18 Nov 1998 10:05:58 -0500 (EST) From: Craig Struble X-Sender: cstruble@quirk.struble.c To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-Reply-To: <199811180808.DAA18363@huis-clos.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, 18 Nov 1998, Maciej Stachowiak wrote: > cstruble@vt.edu writes: > > > 3. The session manager code isn't writing out the proper width > > and height of clients. My xsm window gets sized too tall and > > wide when I start my session. > > Is this the only windo that gets resized wrong? What window-style are > you using for it? > > - Maciej > Ok, yes, it's the only window that gets resized because it's the only one currently being handled by scwm under session management. The xsm window is also being moved from its initial position to a new position on the screen (where it was when I checkpointed, so that's cool). The style used is in my previous email responding to Todd, so I'll point to that message as opposed to putting the style in again. Another thing that happens is that the top border gets slightly enlarged and a line showing stickyness appears, where before the window gets moved the top border is the proper size and no sticky line appears. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Nov 18 11:00:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22174 for scwm-discuss-outgoing; Wed, 18 Nov 1998 11:00:08 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA22171 for ; Wed, 18 Nov 1998 11:00:07 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27808; Wed, 18 Nov 98 11:00:06 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA14277; Wed, 18 Nov 1998 07:56:46 -0800 (PST) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: From: Greg Badros Date: 18 Nov 1998 07:56:46 -0800 In-Reply-To: Robert Bihlmeyer's message of "18 Nov 1998 12:09:19 +0100" Message-Id: Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > Wed Nov 18 03:36:37 EST 1998 -- $Revision: 1.905 $ > > has problems when srcdir!=builddir. The make fails because the theme > directory and its corresponding Makefile is not created. > > Apart from that scwm built correctly on a FreeBSD-2.2.6 box. I had to run ./config.status from the top level directory to get a new module directory (modules/xpm-menus for me) to have its Makefile created. Should config.status get run at the end of autogen.sh? I'm using enable-maintainer-mode, and the makefiles don't create the new Makefiles by default, or even after running autogen.sh (unless the config.status line is added to autogen.sh). Greg From owner-scwm-discuss@mit.edu Wed Nov 18 11:21:59 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA22344 for scwm-discuss-outgoing; Wed, 18 Nov 1998 11:21:59 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA22341 for ; Wed, 18 Nov 1998 11:21:58 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07069; Wed, 18 Nov 98 11:21:54 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA14405; Wed, 18 Nov 1998 08:21:47 -0800 (PST) To: Craig Struble Cc: Todd Larason , scwm-discuss@mit.edu Subject: Re: Minor bugs References: From: Greg Badros Date: 18 Nov 1998 08:21:47 -0800 In-Reply-To: Craig Struble's message of "Wed, 18 Nov 1998 10:00:19 -0500 (EST)" Message-Id: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig Struble writes: > when they overlap with my FvwmPager. In both cases I'm opening the menu > with the mouse. So now that I look at my email, I should clarify that > it's not scwm's menus causing trouble (Doh!). The style options look like: ^^^^^^^^^^^^^^^^ Oh. Yes, I can reproduce this, too, with sample.scwmrc/gjb.scwmrc. Greg From owner-scwm-discuss@mit.edu Wed Nov 18 12:24:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22671 for scwm-discuss-outgoing; Wed, 18 Nov 1998 12:24:43 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22668 for ; Wed, 18 Nov 1998 12:24:42 -0500 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA20962; Wed, 18 Nov 98 12:24:39 EST Received: from localhost (cstruble@localhost) by csgrad.cs.vt.edu (8.9.1a/8.9.1) with SMTP id MAA25665; Wed, 18 Nov 1998 12:24:28 -0500 (EST) X-Authentication-Warning: csgrad.cs.vt.edu: cstruble owned process doing -bs Date: Wed, 18 Nov 1998 12:24:28 -0500 (EST) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Greg Badros Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 18 Nov 1998, Greg Badros wrote: > Robert Bihlmeyer writes: > > > Hi, > > > > Wed Nov 18 03:36:37 EST 1998 -- $Revision: 1.905 $ > > > > has problems when srcdir!=builddir. The make fails because the theme > > directory and its corresponding Makefile is not created. > > > > Apart from that scwm built correctly on a FreeBSD-2.2.6 box. > > I had to run ./config.status from the top level directory to get a new > module directory (modules/xpm-menus for me) to have its Makefile > created. Should config.status get run at the end of autogen.sh? I'm > using enable-maintainer-mode, and the makefiles don't create the > new Makefiles by default, or even after running autogen.sh (unless the > config.status line is added to autogen.sh). > > Greg > This would be nice, because I've had similar problems. If I try to make after a new directory is created, the build gets hosed because a Makefile doesn't exist for the new directory. Normally to recover, I have to do a make distclean and then run autogen.sh and configure scwm again. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Nov 18 12:23:49 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA22663 for scwm-discuss-outgoing; Wed, 18 Nov 1998 12:23:49 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA22660 for ; Wed, 18 Nov 1998 12:23:44 -0500 Received: from smtp9.nwnexus.com by MIT.EDU with SMTP id AA00576; Wed, 18 Nov 98 12:23:44 EST Received: from pulsar.halcyon.com (coho.halcyon.com [198.137.231.21]) by smtp9.nwnexus.com (8.8.8/8.8.8) with ESMTP id JAA23154 for ; Wed, 18 Nov 1998 09:23:37 -0800 Received: from ken@localhost by pulsar.halcyon.com id <276516-384>; Tue, 17 Nov 1998 15:22:34 -0800 From: Ken Pizzini To: scwm-discuss@mit.edu Cc: hjstein@bfr.co.il Subject: Re: docs: scwm-procedures.txt In-Reply-To: Reply-To: ken@halcyon.com Message-Id: <19981117232234Z276516-384+27@pulsar.halcyon.com> Date: Tue, 17 Nov 1998 15:22:23 -0800 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On scwm-discuss, message , Harvey J. Stein wrote: >start & exit (no args) - 1.03 seconds. >Generate .pdoc file from window.c - 2.05 seconds. >Generate .txt file from window.c - 2.10 seconds. >Generate .txt file from window.pdoc - 1.47 seconds. >Generate .txt file from window.pdoc, no checking - 0.89 seconds. > >window.c is the largest C file in the distribution. I don't know why >the last one was faster than start & exit. It doesn't make any sense. Warm vs. cold cache? --Ken Pizzini From owner-scwm-discuss@mit.edu Wed Nov 18 13:41:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23108 for scwm-discuss-outgoing; Wed, 18 Nov 1998 13:41:09 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23105 for ; Wed, 18 Nov 1998 13:41:06 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28055; Wed, 18 Nov 98 13:41:02 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA30361; Wed, 18 Nov 1998 20:37:55 +0200 To: ken@halcyon.com Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <19981117232234Z276516-384+27@pulsar.halcyon.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Nov 1998 20:37:55 +0200 In-Reply-To: Ken Pizzini's message of "Tue, 17 Nov 1998 15:22:23 -0800" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > On scwm-discuss, message , > Harvey J. Stein wrote: > >start & exit (no args) - 1.03 seconds. > >Generate .pdoc file from window.c - 2.05 seconds. > >Generate .txt file from window.c - 2.10 seconds. > >Generate .txt file from window.pdoc - 1.47 seconds. > >Generate .txt file from window.pdoc, no checking - 0.89 seconds. > > > >window.c is the largest C file in the distribution. I don't know why > >the last one was faster than start & exit. It doesn't make any sense. > > Warm vs. cold cache? I must have been on drugs. Here's what I'm getting now: start & exit (no args) - 0.77 seconds. Generate .pdoc file from window.c - 1.99 seconds. Generate .txt file from window.c - 2.05 seconds. Generate .txt file from window.pdoc - 1.46 seconds. Generate .txt file from window.pdoc, no checking - 0.90 seconds. This is running multiple times & quoting the best time. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 18 13:51:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id NAA23181 for scwm-discuss-outgoing; Wed, 18 Nov 1998 13:51:35 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id NAA23178 for ; Wed, 18 Nov 1998 13:51:34 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA01813; Wed, 18 Nov 98 13:51:32 EST Received: (qmail 9308 invoked by uid 501); 18 Nov 1998 18:51:29 -0000 Message-Id: <19981118105128.A9081@molehill.org> Date: Wed, 18 Nov 1998 10:51:28 -0800 From: Todd Larason To: Greg Badros , Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Nov 18, 1998 at 07:56:46AM -0800 X-Tom-Swifty: "Ships ahoy!" said Tom fleetingly. X-Kibo: The script we're following in THIS life abounds! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981118, Greg Badros wrote: > I had to run ./config.status from the top level directory to get a new > module directory (modules/xpm-menus for me) to have its Makefile > created. I've had periodic problems with this too. Most recently, I had to wipe my build tree to get libSM linked in properly. > Should config.status get run at the end of autogen.sh? I don't think this is the right solution though - the first time through, there is no config.status, and (sorry to harp on this), where builddir != srcdir, there never is, at least not there. From owner-scwm-discuss@mit.edu Wed Nov 18 14:47:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00426 for scwm-discuss-outgoing; Wed, 18 Nov 1998 14:47:54 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA23395 for ; Wed, 18 Nov 1998 14:16:19 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02143; Wed, 18 Nov 98 14:16:14 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA16272; Wed, 18 Nov 1998 11:16:10 -0800 (PST) To: Todd Larason Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: <19981118105128.A9081@molehill.org> From: Greg Badros Date: 18 Nov 1998 11:16:10 -0800 In-Reply-To: Todd Larason's message of "Wed, 18 Nov 1998 10:51:28 -0800" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981118, Greg Badros wrote: > > I had to run ./config.status from the top level directory to get a new > > module directory (modules/xpm-menus for me) to have its Makefile > > created. > > I've had periodic problems with this too. Most recently, I had to wipe my > build tree to get libSM linked in properly. > > > Should config.status get run at the end of autogen.sh? > > I don't think this is the right solution though - the first time through, > there is no config.status, and (sorry to harp on this), where builddir != > srcdir, there never is, at least not there. I wasn't convinced it was the right solution either, but it was a quick fixed that worked for me once, and have no idea what the "right" way to do this is. Maybe we just run $builddir/config.status iff -x $builddir/config.status? Greg From owner-scwm-discuss@mit.edu Wed Nov 18 14:59:38 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id OAA00653 for scwm-discuss-outgoing; Wed, 18 Nov 1998 14:59:38 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id OAA00650 for ; Wed, 18 Nov 1998 14:59:38 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA18013; Wed, 18 Nov 98 14:59:34 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 18 Nov 1998 14:59:42 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 18 Nov 1998 14:59:42 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id OAA20595; Wed, 18 Nov 1998 14:59:29 -0500 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Greg Badros's message of "17 Nov 1998 15:16:07 -0800" Date: 18 Nov 1998 14:59:28 -0500 Message-Id: Lines: 16 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: docs: scwm-procedures.txt" >>>> Sent on 17 Nov 1998 15:16:07 -0800 >>>> Honorable Greg Badros writes: >> Robert Bihlmeyer writes: >> > Most of us have guile already loaded - inside our window managers. Why >> > not scwmexec it? >> Because it'll stop interactive response of our windowing system. :-( well, isn't multi-threading supposed to prevent this? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. I haven't lost my mind -- it's backed up on tape somewhere. From owner-scwm-discuss@mit.edu Wed Nov 18 15:42:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id PAA01195 for scwm-discuss-outgoing; Wed, 18 Nov 1998 15:42:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id PAA01192 for ; Wed, 18 Nov 1998 15:42:16 -0500 Received: from SCRUBBING-BUBBLES.MIT.EDU by MIT.EDU with SMTP id AA12006; Wed, 18 Nov 98 15:42:17 EST Received: by scrubbing-bubbles.mit.edu (8.8.7/4.7) id PAA15243; Wed, 18 Nov 1998 15:42:15 -0500 (EST) Message-Id: <199811182042.PAA15243@scrubbing-bubbles.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir In-Reply-To: Your message of "18 Nov 1998 12:09:19 +0100." Date: Wed, 18 Nov 1998 15:42:15 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk e9426626@stud2.tuwien.ac.at writes: > Hi, > > Wed Nov 18 03:36:37 EST 1998 -- $Revision: 1.905 $ > > has problems when srcdir!=builddir. The make fails because the theme > directory and its corresponding Makefile is not created. > > Apart from that scwm built correctly on a FreeBSD-2.2.6 box. > That is really weird, because I specifically did a test build with srcdir != buildir (`make distcheck') and it worked fine. Can you tell me what the specific error message is? - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 16:12:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01526 for scwm-discuss-outgoing; Wed, 18 Nov 1998 16:12:37 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01523 for ; Wed, 18 Nov 1998 16:12:36 -0500 Received: from SCRUBBING-BUBBLES.MIT.EDU by MIT.EDU with SMTP id AA23990; Wed, 18 Nov 98 16:12:36 EST Received: by scrubbing-bubbles.mit.edu (8.8.7/4.7) id QAA19611; Wed, 18 Nov 1998 16:12:33 -0500 (EST) Message-Id: <199811182112.QAA19611@scrubbing-bubbles.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir In-Reply-To: Your message of "18 Nov 1998 07:56:46 PST." Date: Wed, 18 Nov 1998 16:12:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Robert Bihlmeyer writes: > > > Hi, > > > > Wed Nov 18 03:36:37 EST 1998 -- $Revision: 1.905 $ > > > > has problems when srcdir!=builddir. The make fails because the theme > > directory and its corresponding Makefile is not created. > > > > Apart from that scwm built correctly on a FreeBSD-2.2.6 box. > > I had to run ./config.status from the top level directory to get a new > module directory (modules/xpm-menus for me) to have its Makefile > created. Should config.status get run at the end of autogen.sh? I'm > using enable-maintainer-mode, and the makefiles don't create the > new Makefiles by default, or even after running autogen.sh (unless the > config.status line is added to autogen.sh). > Good point about the new Makefiles. I think it would be good to add something to autogen.sh that runs config.status if it exists (otherwise you need to run configure anyway, most likely). - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 16:29:01 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01668 for scwm-discuss-outgoing; Wed, 18 Nov 1998 16:29:01 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01665 for ; Wed, 18 Nov 1998 16:29:00 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA00358; Wed, 18 Nov 98 16:29:00 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16595; Wed, 18 Nov 1998 13:28:58 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: <199811182112.QAA19611@scrubbing-bubbles.mit.edu> From: Greg Badros Date: 18 Nov 1998 13:28:58 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 18 Nov 1998 16:12:33 EST" Message-Id: Lines: 10 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Good point about the new Makefiles. I think it would be good to add > something to autogen.sh that runs config.status if it exists > (otherwise you need to run configure anyway, most likely). Does config.status exist only in the build directory? If so, is there any easy way to get that directory path in autogen.sh? Greg From owner-scwm-discuss@mit.edu Wed Nov 18 16:51:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01829 for scwm-discuss-outgoing; Wed, 18 Nov 1998 16:51:41 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01826 for ; Wed, 18 Nov 1998 16:51:36 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00457; Wed, 18 Nov 98 16:51:29 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA31493; Wed, 18 Nov 1998 23:51:27 +0200 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Nov 1998 23:51:27 +0200 In-Reply-To: Sam Steingold's message of "18 Nov 1998 14:59:28 -0500" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on 17 Nov 1998 15:16:07 -0800 > >>>> Honorable Greg Badros writes: > >> Robert Bihlmeyer writes: > >> > Most of us have guile already loaded - inside our window managers. Why > >> > not scwmexec it? > >> Because it'll stop interactive response of our windowing system. :-( > > well, isn't multi-threading supposed to prevent this? Where are the smilies? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 18 16:54:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01843 for scwm-discuss-outgoing; Wed, 18 Nov 1998 16:54:19 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01840 for ; Wed, 18 Nov 1998 16:54:18 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA01520; Wed, 18 Nov 98 16:54:13 EST Received: (qmail 10706 invoked by uid 501); 18 Nov 1998 21:54:14 -0000 Message-Id: <19981118135414.B10502@molehill.org> Date: Wed, 18 Nov 1998 13:54:14 -0800 From: Todd Larason To: Greg Badros , Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: <199811182112.QAA19611@scrubbing-bubbles.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Wed, Nov 18, 1998 at 01:28:58PM -0800 X-Tom-Swifty: "I like modern painting", said Tom abstractly. X-Kibo: Everything can teach us how to stay in our world. X-Kibo: Kibo's best friend is eternal. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981118, Greg Badros wrote: > Maciej Stachowiak writes: > > > Good point about the new Makefiles. I think it would be good to add > > something to autogen.sh that runs config.status if it exists > > (otherwise you need to run configure anyway, most likely). > > Does config.status exist only in the build directory? If so, is there > any easy way to get that directory path in autogen.sh? Yes, and no. There may be multiple build directories, and they may be anywhere (likely not accessible from the machine autogen is running on, even!). That's precisely why I use separate builddirs; I expect others who do do for similar reasons. At home, I have Linux/x86 (both Redhat and Debian now), Linux/PPC, Linux/alpha and Solaris/Sparc machines I compile scwm and other things on at least occasionally. Only one of those machines is kept up-to-date on autoconf/automake/libtool. My home directory from that machine is nfs-mounted onto the other machines, and the source directory is read from that, but build directories are kept on local drives. All that being said, I don't have any objection to running config.status if it exists, but I'm going to keep looking for the root of the problem. From owner-scwm-discuss@mit.edu Wed Nov 18 16:56:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id QAA01964 for scwm-discuss-outgoing; Wed, 18 Nov 1998 16:56:20 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id QAA01961 for ; Wed, 18 Nov 1998 16:56:19 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA10342; Wed, 18 Nov 98 16:56:18 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA16644; Wed, 18 Nov 1998 13:56:12 -0800 (PST) To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir References: <199811182112.QAA19611@scrubbing-bubbles.mit.edu> <19981118135414.B10502@molehill.org> From: Greg Badros Date: 18 Nov 1998 13:56:11 -0800 In-Reply-To: Todd Larason's message of "Wed, 18 Nov 1998 13:54:14 -0800" Message-Id: Lines: 12 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > All that being said, I don't have any objection to running config.status if it > exists, but I'm going to keep looking for the root of the problem. Good. It definitely should be deemed an interim hack; but it did take me longer than I'd've liked to figure out how to get the new modules directories to build the first time I needed them to build. Greg From owner-scwm-discuss@mit.edu Wed Nov 18 17:03:17 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02155 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:03:17 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id RAA02152 for ; Wed, 18 Nov 1998 17:03:15 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA02064 for scwm-discuss@huis-clos.mit.edu; Wed, 18 Nov 1998 23:01:59 +0100 (MET) Received: (qmail 22285 invoked by uid 115); 18 Nov 1998 22:01:21 -0000 To: scwm-discuss@mit.edu Subject: Re: Minor bugs References: X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 18 Nov 1998 23:01:21 +0100 In-Reply-To: Craig Struble's message of "Wed, 18 Nov 1998 02:20:55 -0500 (EST)" Message-ID: Lines: 29 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 18 Nov 1998 02:20:55 -0500 (EST) >>>>> Craig Struble said: Craig> 2. Menus only appear over kept-on-top windows after the menu Craig> has been displayed twice. They should be displayed on the Craig> first shot. This I can't reproduce. Craig> 3. The session manager code isn't writing out the proper width Craig> and height of clients. My xsm window gets sized too tall and Craig> wide when I start my session. I fiddled a lot with this, until it worked for me, but I may well have broken it for the other gadzillion possible window configurations. Could you tell me what exactly you are seeing? How much does the window grow larger? What is your border and title width? Any correlations? I'm glad someone other than me is using session-management at all . Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Nov 18 17:06:14 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02259 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:06:14 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA02256 for ; Wed, 18 Nov 1998 17:06:13 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA13977; Wed, 18 Nov 98 17:06:13 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA16701; Wed, 18 Nov 1998 14:06:10 -0800 (PST) To: scwm-discuss@mit.edu Subject: Qt widget library is going open-source... From: Greg Badros Date: 18 Nov 1998 14:06:10 -0800 Message-Id: Lines: 5 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk In case you haven't yet heard, see: http://www.troll.no/announce/qpl.html Greg From owner-scwm-discuss@mit.edu Wed Nov 18 17:17:22 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02514 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:17:22 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02509; Wed, 18 Nov 1998 17:17:20 -0500 Message-Id: <199811182217.RAA02509@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: themes do not work when srcdir!=builddir In-reply-to: Your message of "18 Nov 1998 13:28:58 PST." Date: Wed, 18 Nov 1998 17:17:20 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Good point about the new Makefiles. I think it would be good to add > > something to autogen.sh that runs config.status if it exists > > (otherwise you need to run configure anyway, most likely). > > Does config.status exist only in the build directory? If so, is there > any easy way to get that directory path in autogen.sh? > No, I think nothing in srcdir knows about builddir by design. We could set things up so that you are supposed to run autogen.sh with a working directory of $builddir and invoked as $srcdir/autogen.sh, that way it could find both paths with a little shell hackery. However, as I've thought about this more, I think it must be some sort of bug in --enable-maintainer-mode. As I understand it, --enable-maintainer mode should set things up so that you should never have to run any of auto* or ./config* if you've only made changes to your source, even if those include new directories. I'll see if this still happens with the latest automake and send something to the automake list if so. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 17:33:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02871 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:33:15 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA02868 for ; Wed, 18 Nov 1998 17:33:14 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14807; Wed, 18 Nov 98 17:33:01 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA31991; Thu, 19 Nov 1998 00:32:44 +0200 To: Greg Badros Cc: scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: Re: Qt widget library is going open-source... From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Nov 1998 00:32:44 +0200 Message-Id: Lines: 78 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > In case you haven't yet heard, see: > > http://www.troll.no/announce/qpl.html Here's a back & forth & back btw me & Eric Raymond on the Qt license. I haven't gotten a reply to my last response yet. ------- Start of forwarded message ------- To: "Eric S. Raymond" Cc: "Harvey J. Stein" Subject: Re: A maze of twisty patches, all of them different. References: <199811181954.VAA30986@blinky.bfr.co.il> <19981118154224.A5186@thyrsus.com> From: hjstein@bfr.co.il (Harvey J. Stein) Date: 18 Nov 1998 23:43:07 +0200 Message-ID: "Eric S. Raymond" writes: > Harvey J. Stein : > > I'm surprised that everyone's so comfortable with the Qt license. It > > seems to me that the restriction that changes be distributed as > > patches will lead to the same distribution nightmare that minix had. > > > > With minix one first had to buy the book to get the source & the > > source wasn't distributable. So, people were forced to distribute > > their changes as patches. This lead to an unweildy patch hell - it > > became impossible to use the patches one wanted/needed because of the > > interdependencies. > > > > With Qt, although the software is distributable, the license requires > > changes to be distributed as patches, effectively causing the same > > problems as minix had. > > This might be a pain if packaging tools like RPM didn't make the pristine- > sources-plus-patches installation trivial. RPM won't make a set of patches coherent. RPM is good for making distribution & building easy when there's a handful of patches, each created relative to the previous. But it *won't* make a set of patches coherent. I'm thinking more along the lines of 20-30 patches, some relying on others, some being incompatible. RPM isn't going to fix this one. This is even a problem with Linux kernel patches on linux-hq. CVS could help, but only if some sort of free-Qt organization makes a publically available CVS site with the official Qt being the vendor branch & everyone working on the main branch. But, a) it requires everyone to agree to work off of this CVS tree and b) it's not clear that this would be acceptable under the given licensing agreement - one would be able to check out the patched source as opposed to being restricted to getting the original plus a patch. It really seems to be a significant curtailing on the amount of free development that can be done on the project. It's effectively an open project where the main line of development doesn't accept patches. This is a recipe for massive forking of development. At best I could only say that while I applaud Troll for making Qt an open source project, I'm concerned that the restriction of distributing changes as patches will seriously hamper free development. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il ------- End of forwarded message ------- -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 18 17:34:29 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02915 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:34:29 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA02908; Wed, 18 Nov 1998 17:34:28 -0500 Message-Id: <199811182234.RAA02908@huis-clos.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Qt widget library is going open-source... In-reply-to: Your message of "18 Nov 1998 14:06:10 PST." Date: Wed, 18 Nov 1998 17:34:28 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > In case you haven't yet heard, see: > > http://www.troll.no/announce/qpl.html > I've heard. I've been thinking what, if anything, we should do about it. It would probably be appropriate to have a module to support KDE window manager hints as well as one to support the GNOME hints. I have been trying to find out on the GNOME mailing lists what hints are actually in use by gnome apps at this time so we can prioritize those. Also, if someone wanted to write a pager that integrated with the KDE panel I'd be willing to add that to the distribution, but I am still personally going to try to do the Gnome/Gtk one. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 17:46:42 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id RAA03158 for scwm-discuss-outgoing; Wed, 18 Nov 1998 17:46:42 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id RAA03154 for ; Wed, 18 Nov 1998 17:46:40 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA28007; Wed, 18 Nov 98 17:46:39 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA32065; Thu, 19 Nov 1998 00:46:29 +0200 Date: Thu, 19 Nov 1998 00:46:29 +0200 Message-Id: <199811182246.AAA32065@blinky.bfr.co.il> From: "Harvey J. Stein" To: scwm-discuss@mit.edu Subject: Scheme documentation question. Sender: owner-scwm-discuss@mit.edu Precedence: bulk Can anyone explain to me why define-public for functions looks like: (define-public (fname arg1 arg2 ...) "quoted string containing documentation..." body) whereas define-public for variables looks like: (define-public variable value) ;;;**VAR ;;; Scheme comment containing documentation... I realize that doing: (define-public variable doc-string value) would break lots of code, but how about: (define-public variable value optional-doc-string) Can't this be made to work? Why am I so concerned? Because scwmdoc.scm can trivially snarf up the documentation for the fcns by just doing (read), but can't get the documentation for the variables this way. It'll have to do all sorts of ugly hacks such as snarfing up the form, then if it's a variable, doing readline for the docs, & if it doesn't start with ;;;**VAR, then do all sorts of messed up stuff to read it as the beginning of a form because one might run into: (define-public variable1 value1) (define-public variable2 value2) Also, an efficiency question. In guile, strings eval to themselves. In the define-public defuns, do the strings become part of the body of the functions & get evaled each time the fcn is executed? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 18 18:05:28 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03434 for scwm-discuss-outgoing; Wed, 18 Nov 1998 18:05:28 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id SAA03431 for ; Wed, 18 Nov 1998 18:05:22 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA25115; Wed, 18 Nov 98 18:05:19 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA16962; Wed, 18 Nov 1998 15:05:09 -0800 (PST) To: "Harvey J. Stein" Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Scheme documentation question. References: <199811182246.AAA32065@blinky.bfr.co.il> From: Greg Badros Date: 18 Nov 1998 15:05:08 -0800 In-Reply-To: "Harvey J. Stein"'s message of "Thu, 19 Nov 1998 00:46:29 +0200" Message-Id: Lines: 50 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Harvey J. Stein" writes: > Can anyone explain to me why define-public for functions looks like: > > (define-public (fname arg1 arg2 ...) > "quoted string containing documentation..." > body) > > whereas define-public for variables looks like: > > (define-public variable value) > ;;;**VAR > ;;; Scheme comment containing documentation... > > I realize that doing: > > (define-public variable doc-string value) > > would break lots of code, but how about: > > (define-public variable value optional-doc-string) > > Can't this be made to work? This is a question more for the guile folks I think. Variables don't have doc strings attached. We could add a syntax: (define-documented-variable VAR DOC-STRING VALUE) I suppose, but I'd rather have something that's guile-supported. (I'd prefer that the order stay the same as for procedures). > Why am I so concerned? Because scwmdoc.scm can trivially snarf up the > documentation for the fcns by just doing (read), but can't get the > documentation for the variables this way. It'll have to do all sorts > of ugly hacks such as snarfing up the form, then if it's a variable, > doing readline for the docs, & if it doesn't start with ;;;**VAR, then > do all sorts of messed up stuff to read it as the beginning of a form > because one might run into: > > (define-public variable1 value1) > (define-public variable2 value2) > > Also, an efficiency question. In guile, strings eval to themselves. > In the define-public defuns, do the strings become part of the body of > the functions & get evaled each time the fcn is executed? (just left this stuff in for guile folks to respond to if they so choose). Greg From owner-scwm-discuss@mit.edu Wed Nov 18 18:17:39 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03698 for scwm-discuss-outgoing; Wed, 18 Nov 1998 18:17:39 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA03692; Wed, 18 Nov 1998 18:17:34 -0500 Message-Id: <199811182317.SAA03692@huis-clos.mit.edu> To: "Harvey J. Stein" cc: scwm-discuss@mit.edu Subject: Re: Scheme documentation question. In-reply-to: Your message of "Thu, 19 Nov 1998 00:46:29 +0200." <199811182246.AAA32065@blinky.bfr.co.il> Date: Wed, 18 Nov 1998 18:17:34 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Can anyone explain to me why define-public for functions looks like: > > (define-public (fname arg1 arg2 ...) > "quoted string containing documentation..." > body) > > whereas define-public for variables looks like: > > (define-public variable value) > ;;;**VAR > ;;; Scheme comment containing documentation... > > I realize that doing: > > (define-public variable doc-string value) > > would break lots of code, but how about: > > (define-public variable value optional-doc-string) > > Can't this be made to work? > I think it can, I'll ask Jim Blandy what he thinks of this (the only thing define and define-public would have to do is ignore the extra form in this case. > Why am I so concerned? Because scwmdoc.scm can trivially snarf up the > documentation for the fcns by just doing (read), but can't get the > documentation for the variables this way. It'll have to do all sorts > of ugly hacks such as snarfing up the form, then if it's a variable, > doing readline for the docs, & if it doesn't start with ;;;**VAR, then > do all sorts of messed up stuff to read it as the beginning of a form > because one might run into: > > (define-public variable1 value1) > (define-public variable2 value2) > > Also, an efficiency question. In guile, strings eval to themselves. > In the define-public defuns, do the strings become part of the body of > the functions & get evaled each time the fcn is executed? Docstrings do consume memory, I am not sure if they also consume compute time. However, both of these are likely to be addressed in Guile at some point. Jim Blandy has expressed a willingness to change it. I think he will probably accept patches to change the way this works when the scwm doc-extraction stuff is incorporated into Guile. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 18:47:43 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04023 for scwm-discuss-outgoing; Wed, 18 Nov 1998 18:47:43 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id SAA04019; Wed, 18 Nov 1998 18:47:42 -0500 Message-Id: <199811182347.SAA04019@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: Red Hat ContribNet Date: Wed, 18 Nov 1998 18:47:42 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk So Red Hat ContribNet is open (see http://developer.redhat.com/). I'd really like a volunteer to maintain an RPM of scwm there. I would do it myself, but I am super hosed between real life and actually working on scwm. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Wed Nov 18 19:18:44 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA04397 for scwm-discuss-outgoing; Wed, 18 Nov 1998 19:18:44 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA04394 for ; Wed, 18 Nov 1998 19:18:43 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA12533; Wed, 18 Nov 98 19:18:40 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id TAA19786; Wed, 18 Nov 1998 19:18:41 -0500 (EST) Message-Id: <199811190018.TAA19786@ns1.infonautics.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Wharf support In-Reply-To: Your message of "Mon, 16 Nov 1998 17:02:57 EST." <199811162202.RAA03099@huis-clos.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Nov 1998 19:18:21 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <199811162202.RAA03099@huis-clos.mit.edu>, Maciej Stachowiak writes: > >jtl@molehill.org writes: >> On 981116, Arturo Perez wrote: >> > I've been lurking here for a while. I've decided that it may be time to >> > switch to scwm but I need to know something first. >> > >> > I currently use AfterStep. There are really only two reasons why: >> > 1) I like the polished look of it. >> > 2) The Wharf. >> > >> > Is there support for a wharf in scwm? >> >> Probably not right now. How hard it would be to add would depend on how far >> AfterStep's module interface has diverged from fvwm's, and exactly what part >> of fvwm's it uses. >> > >Actually, recent versions of fvwm2 have an FvwmWharf module backported >from AfterStep which should work with scwm. Of cource, using fvwm2 >modules is still a bit painful (mainly because you have to write stuff >in the icky configuration language of each individual module to >configure it). > >Once I find a free weekend to debug scwm's guile-gtk support, there >should be native scwm replacements for the wharf, FvwmTaskBar, >FvwmGoodStuff, FvwmButtons, etc. I can't say when that will happen >though. > > - Maciej > Maybe I can lend a hand. What would it take to make a module such as the Wharf? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Wed Nov 18 19:22:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA04420 for scwm-discuss-outgoing; Wed, 18 Nov 1998 19:22:08 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA04417 for ; Wed, 18 Nov 1998 19:22:08 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22894; Wed, 18 Nov 98 19:22:08 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA17552; Wed, 18 Nov 1998 16:22:04 -0800 (PST) To: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811182347.SAA04019@huis-clos.mit.edu> From: Greg Badros Date: 18 Nov 1998 16:22:03 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 18 Nov 1998 18:47:42 EST" Message-Id: Lines: 11 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > So Red Hat ContribNet is open (see http://developer.redhat.com/). I'd > really like a volunteer to maintain an RPM of scwm there. I would do > it myself, but I am super hosed between real life and actually working > on scwm. Speaking of volunteers for things... another project that'd be great to have someone help out with is a FAQ maintainer.... any takers? Greg From owner-scwm-discuss@mit.edu Wed Nov 18 19:43:11 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA04631 for scwm-discuss-outgoing; Wed, 18 Nov 1998 19:43:11 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA04628 for ; Wed, 18 Nov 1998 19:43:10 -0500 Received: from smtp1.nwnexus.com by MIT.EDU with SMTP id AA27689; Wed, 18 Nov 98 19:43:09 EST Received: from pulsar.halcyon.com (coho.halcyon.com [198.137.231.21]) by smtp1.nwnexus.com (8.8.8/8.8.8) with ESMTP id QAA08871 for ; Wed, 18 Nov 1998 16:43:05 -0800 Received: from ken@localhost by pulsar.halcyon.com id <276516-384>; Wed, 18 Nov 1998 09:47:39 -0800 From: Ken Pizzini To: scwm-discuss@mit.edu Subject: a documentation "bug" Message-Id: <19981118174739Z276516-384+28@pulsar.halcyon.com> Date: Wed, 18 Nov 1998 09:47:28 -0800 Sender: owner-scwm-discuss@mit.edu Precedence: bulk (First a disclaimer: I haven't checked carefully in the last week or so, so this may already be fixed...) I wanted to play with the new pie menu code, but had difficulty in figuring out how to use it. Perhaps this is due to obtuseness on my part, but it also suggests a need for better documentation about how to use this feature. --Ken Pizzini From owner-scwm-discuss@mit.edu Wed Nov 18 19:47:30 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id TAA04674 for scwm-discuss-outgoing; Wed, 18 Nov 1998 19:47:30 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id TAA04671 for ; Wed, 18 Nov 1998 19:47:29 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA18349; Wed, 18 Nov 98 19:47:26 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id TAA00025 for ; Wed, 18 Nov 1998 19:47:20 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Qt widget library is going open-source... References: Date: 18 Nov 1998 19:47:13 -0500 Message-Id: <5l67ccjypa.fsf@tequila.cs.yale.edu> Lines: 33 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 18 Nov 1998 19:47:13 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Harvey" == Harvey J Stein writes: > I'm thinking more along the lines of 20-30 patches, some relying on > others, some being incompatible. RPM isn't going to fix this one. > This is even a problem with Linux kernel patches on linux-hq. 1 - download Qt, untar it into `qt' 2 - `cvs import qt VENDOR qt-1_41' it into your personal repository 3 - hack hack hack 4 - (until here, nothing new) Now, to make a distribution of your code: (Time to dig out good ol' /bin/sh) #/bin/sh cvs co -r VENDOR $1 cd $1 cvs rdiff -c -r VENDOR $1 >patch cd .. tar zclf $1-$(date +%Y%b%d).tarpatch.gz $1 rm -r $1 5 - to untar such a distribution #!/bin/sh tarfile=$1 oldifs="$IFS"; IFS='-'; set -- $tarfile; IFS="$oldifs" [ -d $1 ] && (echo "target dir already exist"; exit 1) tar zxvpf $tarfile cd $1 || (echo "can't find target dir"; exit 1) patch -f -p1 ; Wed, 18 Nov 1998 20:09:10 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA22654; Wed, 18 Nov 98 20:09:05 EST Received: (qmail 12521 invoked by uid 501); 19 Nov 1998 01:09:05 -0000 Message-Id: <19981118170905.A12421@molehill.org> Date: Wed, 18 Nov 1998 17:09:05 -0800 From: Todd Larason To: Ken Pizzini , scwm-discuss@mit.edu Subject: Re: a documentation "bug" References: <19981118174739Z276516-384+28@pulsar.halcyon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981118174739Z276516-384+28@pulsar.halcyon.com>; from Ken Pizzini on Wed, Nov 18, 1998 at 09:47:28AM -0800 X-Tom-Swifty: "We can't accommodate any more peripherals", said Tom bus-ily. X-Kibo: Reach out with your understanding of peoples' minds and doubt the the sum of all forms of odyle. X-Kibo: If you are allowed not to know the definition of the reason why, DO IT. Not true.. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981118, Ken Pizzini wrote: > (First a disclaimer: I haven't checked carefully in the last week > or so, so this may already be fixed...) It hasn't been, I'm sure. > I wanted to play with the new pie menu code, but had difficulty > in figuring out how to use it. To make pie menus the default: (use-modules (app scwm pie-menus)) (menu-style #:look pie-menu-look) To make only a particular menu a pie menu: (define menu-blah-blah-blah (menu (list blah blah blah blah) #:menu-look pie-menu-look)) Probably what's needed is a CONCEPT doc for menu-looks? (erk! I just noticed that those keywords don't match, and they should. Expect that to change before 0.9. And worse, #:menu-look isn't documented in menu; I thought I'd done that.) (In all of the above, 'circle-pie-menu-look' can be substituted for 'pie-menu-look' to get a look more like what I had always imagined pie menus were like, but that takes up too much screenspace in my experiments) From owner-scwm-discuss@mit.edu Wed Nov 18 20:09:37 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA04921 for scwm-discuss-outgoing; Wed, 18 Nov 1998 20:09:37 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA04918 for ; Wed, 18 Nov 1998 20:09:36 -0500 Received: from M2-032-6.MIT.EDU by MIT.EDU with SMTP id AA22738; Wed, 18 Nov 98 20:09:32 EST Received: by m2-032-6.mit.edu (SMI-8.6/4.7) id UAA11722; Wed, 18 Nov 1998 20:09:34 -0500 Message-Id: <199811190109.UAA11722@m2-032-6.mit.edu> To: Arturo Perez Cc: scwm-discuss@mit.edu Subject: Re: Wharf support In-Reply-To: Your message of "Wed, 18 Nov 1998 19:18:21 EST." <199811190018.TAA19786@ns1.infonautics.com> Date: Wed, 18 Nov 1998 20:09:34 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > Maybe I can lend a hand. What would it take to make a module such as > the Wharf? The main sticking point is making guile-gtk work with scwm properly, then writing any kind of persistent module that has a GUI will become really easy. Are you willing to delve into Gtk internals a bit to make this work? Right now guile-gtk *almost* works with scwm - you can load the module and create widgets OK, but it will take some work to integrate the Gtk event loop with scwm's. Other than that, you can help write the actual Wharf-like scwmlet once someone (probably me) figures out the integration issues. We're always happy to see more contributors. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 20:15:51 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05015 for scwm-discuss-outgoing; Wed, 18 Nov 1998 20:15:51 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05012 for ; Wed, 18 Nov 1998 20:15:50 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AB04384; Wed, 18 Nov 98 20:15:49 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 18 Nov 1998 20:15:57 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 18 Nov 1998 20:15:56 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id UAA21052; Wed, 18 Nov 1998 20:15:42 -0500 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "18 Nov 1998 23:51:27 +0200" Date: 18 Nov 1998 20:15:42 -0500 Message-Id: Lines: 28 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: docs: scwm-procedures.txt" >>>> Sent on 18 Nov 1998 23:51:27 +0200 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: >> Sam Steingold writes: >> >> > >>>> In message >> > >>>> On the subject of "Re: docs: scwm-procedures.txt" >> > >>>> Sent on 17 Nov 1998 15:16:07 -0800 >> > >>>> Honorable Greg Badros writes: >> > >> Robert Bihlmeyer writes: >> > >> > Most of us have guile already loaded - inside our window managers. Why >> > >> > not scwmexec it? >> > >> Because it'll stop interactive response of our windowing system. :-( >> > >> > well, isn't multi-threading supposed to prevent this? >> >> Where are the smilies? I was serious. I would appreciate an elucidation. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Life is a sexually transmitted disease with 100% mortality. From owner-scwm-discuss@mit.edu Wed Nov 18 20:16:54 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05038 for scwm-discuss-outgoing; Wed, 18 Nov 1998 20:16:54 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05034 for ; Wed, 18 Nov 1998 20:16:53 -0500 Received: from pele.santafe.edu by MIT.EDU with SMTP id AA04644; Wed, 18 Nov 98 20:16:52 EST Received: from chama.santafe.edu (chama.santafe.edu [192.12.12.31]) by pele.santafe.edu (8.9.1/8.9.1) with ESMTP id SAA02586 for ; Wed, 18 Nov 1998 18:16:50 -0700 (MST) Received: (from mgd@localhost) by chama.santafe.edu (8.9.1/8.9.1) id SAA21177; Wed, 18 Nov 1998 18:16:49 -0700 (MST) Date: Wed, 18 Nov 1998 18:16:49 -0700 (MST) Message-Id: <199811190116.SAA21177@chama.santafe.edu> X-Authentication-Warning: chama.santafe.edu: mgd set sender to mgd@chama.santafe.edu using -f From: "Marcus G. Daniels" To: scwm-discuss@mit.edu Subject: Re: Qt widget library is going open-source... References: <5l67ccjypa.fsf@tequila.cs.yale.edu> Gcc: nnml:outgoing.mail Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "SM" == Stefan Monnier writes: SM> Big deal ! Other popular free software licenses already say that is is necessary to pass on credit and to make evident what files were modifed. It seems to me the intent of licenses like this one is just to retain control/seniority for the authors. What if the fvwm parts that scwm uses were under such a license? It seems to me that would be a sigificant obstacle to progress, especially if the original and new hackers didn't get along. From owner-scwm-discuss@mit.edu Wed Nov 18 20:25:58 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05268 for scwm-discuss-outgoing; Wed, 18 Nov 1998 20:25:58 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05265 for ; Wed, 18 Nov 1998 20:25:57 -0500 Received: from M2-032-6.MIT.EDU by MIT.EDU with SMTP id AA06379; Wed, 18 Nov 98 20:25:57 EST Received: by m2-032-6.mit.edu (SMI-8.6/4.7) id UAA11873; Wed, 18 Nov 1998 20:25:56 -0500 Message-Id: <199811190125.UAA11873@m2-032-6.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-Reply-To: Your message of "18 Nov 1998 20:15:42 EST." Date: Wed, 18 Nov 1998 20:25:56 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on 18 Nov 1998 23:51:27 +0200 > >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: > >> Sam Steingold writes: > >> > >> > >>>> In message > >> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >> > >>>> Sent on 17 Nov 1998 15:16:07 -0800 > >> > >>>> Honorable Greg Badros writes: > >> > >> Robert Bihlmeyer writes: > >> > >> > Most of us have guile already loaded - inside our window managers. Why > >> > >> > not scwmexec it? > >> > >> Because it'll stop interactive response of our windowing system. :-( > >> > > >> > well, isn't multi-threading supposed to prevent this? > >> > >> Where are the smilies? > > I was serious. > > I would appreciate an elucidation. The scwmexec protocol handler does not currently spawn a new thread automatically, but I believe if you did so by hand in the code with something like echo `(use-modules (ice-9 threads)) (begin-thread ;;; body of doc-processing code )` | scwmrepl It would not in fact block interactive response (untested). In fact, if you made the code a module and set it up to be thread-safe (mainly no global variables) you could upload the code once and just swapwn I don't think I would personlly feel comfortable doing that sort of thing in my windowmanager, but it should be possible. - Maciej From owner-scwm-discuss@mit.edu Wed Nov 18 20:32:55 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id UAA05406 for scwm-discuss-outgoing; Wed, 18 Nov 1998 20:32:55 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id UAA05402 for ; Wed, 18 Nov 1998 20:32:54 -0500 Received: from M2-032-6.MIT.EDU by MIT.EDU with SMTP id AA27368; Wed, 18 Nov 98 20:32:52 EST Received: by m2-032-6.mit.edu (SMI-8.6/4.7) id UAA11882; Wed, 18 Nov 1998 20:32:54 -0500 Message-Id: <199811190132.UAA11882@m2-032-6.mit.edu> To: "Marcus G. Daniels" Cc: scwm-discuss@mit.edu Subject: Re: Qt widget library is going open-source... In-Reply-To: Your message of "Wed, 18 Nov 1998 18:16:49 MST." <199811190116.SAA21177@chama.santafe.edu> Date: Wed, 18 Nov 1998 20:32:54 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mgd@santafe.edu writes: > >>>>> "SM" == Stefan Monnier writes: > > SM> Big deal ! > > Other popular free software licenses already say that is is necessary > to pass on credit and to make evident what files were modifed. > It seems to me the intent of licenses like this one is just to retain > control/seniority for the authors. What if the fvwm parts that scwm > uses were under such a license? It seems to me that would be a > sigificant obstacle to progress, especially if the original and new hackers > didn't get along. I don't think anyone is considering linking scwm against Qt. Thus, I don't think debating the merits of the upcoming Qt license on this list is appropriate. Actually, I'd ordinarily not worry about off-topic discussions on the list, but I know anything relating to Qt and/or KDE can become a huge flamewar, and I'd rather not have that happen here. If people want to discuss Qt or the new Qt license in a context that is relevant to scwm, e.g. "Should we have a Qt-based pager" or whatever, that is of course welcome and appropriate discussion. - Maciej PS This message is not directed at any individual in particular, I responded to Marcus's post because that was the point when I saw a potential Evil Flamewar(tm) brewing. From owner-scwm-discuss@mit.edu Wed Nov 18 21:43:41 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id VAA26845 for scwm-discuss-outgoing; Wed, 18 Nov 1998 21:43:41 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id VAA26842 for ; Wed, 18 Nov 1998 21:43:39 -0500 Received: from [206.58.36.66] by MIT.EDU with SMTP id AA21901; Wed, 18 Nov 98 21:43:37 EST Received: from andoz.hurrah.com (churchr@localhost) by sandoz.hurrah.com (8.8.8/8.8.8/Debian/GNU) id SAA05556; Wed, 18 Nov 1998 18:43:03 -0800 From: Robert Church Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13907.34221.874445.684775@sandoz.hurrah.com> Date: Wed, 18 Nov 1998 18:42:53 -0800 (PST) To: Ken Pizzini Cc: scwm-discuss@mit.edu Subject: a documentation "bug" In-Reply-To: <19981118174739Z276516-384+28@pulsar.halcyon.com> References: <19981118174739Z276516-384+28@pulsar.halcyon.com> X-Mailer: VM 6.62 under Emacs 20.3.2 X-Mailer: Emacs 20.3.2 (gnu/linux) - The choice of a GNU generation Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ken Pizzini writes: > I wanted to play with the new pie menu code, but had difficulty > in figuring out how to use it. Perhaps this is due to obtuseness > on my part, but it also suggests a need for better documentation > about how to use this feature. I don't think it's documented anywhere. I figured it out after about two hours of trial, error, and reading source code. Here's the relavent bit from my .scwmrc: ;;-------------------------------;; ;; import the scwm modules ;; (define pie-menu-obj (dynamic-link "/usr/local/lib/scwm-modules/app/scwm/libpie-menus.so")) (use-modules (app scwm base) (app scwm winops) (app scwm winlist) (app scwm wininfo) (app scwm style) (app scwm face) (app scwm auto-raise) (app scwm pie-menus)) (set-menu-look! circle-pie-menu-look) That's it. From owner-scwm-discuss@mit.edu Wed Nov 18 22:39:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30237 for scwm-discuss-outgoing; Wed, 18 Nov 1998 22:39:35 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id WAA30233; Wed, 18 Nov 1998 22:39:33 -0500 Message-Id: <199811190339.WAA30233@huis-clos.mit.edu> To: scwm-discuss@mit.edu Subject: scwm and guile-gtk Date: Wed, 18 Nov 1998 22:39:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have code in my working dir for scwm to work almost seamlessly with guile-gtk-0.12 and gtk+-1.0.6. However, I can't guarantee that there might not be potential crashes left, and we have this release thing coming up. Should I commit on the head or on a branch? Either way I would like people to try out the code and play with it as possible. I have to go watch Babylon 5 now but I'll try to do more with this later tonight or tomorrow. - Maciej From owner-scwm-discuss@mit.edu Thu Nov 19 00:33:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id AAA01734 for scwm-discuss-outgoing; Thu, 19 Nov 1998 00:33:08 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id AAA01731 for ; Thu, 19 Nov 1998 00:33:05 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA23978; Thu, 19 Nov 98 00:33:03 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id VAA06646; Wed, 18 Nov 1998 21:32:57 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id VAA08501; Wed, 18 Nov 1998 21:32:57 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm and guile-gtk References: <199811190339.WAA30233@huis-clos.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 18 Nov 1998 21:32:57 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 18 Nov 1998 22:39:33 EST" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I have code in my working dir for scwm to work almost seamlessly with > guile-gtk-0.12 and gtk+-1.0.6. However, I can't guarantee that there > might not be potential crashes left, and we have this release thing > coming up. Should I commit on the head or on a branch? Either way I > would like people to try out the code and play with it as possible. I > have to go watch Babylon 5 now but I'll try to do more with this later > tonight or tomorrow. Would these "potential crashes" affect all scwm users, or can they be avoided just by never using the (app scwm gtk) (or whatever) module? If the crashes only affect people who actually try to use gtk, then by all means, commit on the head. (If I only had time, I'd love to play with gtk in scwm.) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Nov 19 01:26:09 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA02065 for scwm-discuss-outgoing; Thu, 19 Nov 1998 01:26:09 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA02062 for ; Thu, 19 Nov 1998 01:26:05 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA01518; Thu, 19 Nov 98 01:26:03 EST Received: (qmail 14778 invoked by uid 501); 19 Nov 1998 06:26:01 -0000 Message-Id: <19981118222601.A14741@molehill.org> Date: Wed, 18 Nov 1998 22:26:01 -0800 From: Todd Larason To: Robert Church Cc: scwm-discuss@mit.edu Subject: Re: a documentation "bug" References: <19981118174739Z276516-384+28@pulsar.halcyon.com> <13907.34221.874445.684775@sandoz.hurrah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <13907.34221.874445.684775@sandoz.hurrah.com>; from Robert Church on Wed, Nov 18, 1998 at 06:42:53PM -0800 X-Tom-Swifty: "There's no hope we'll get any dope when the captain looks up the periscope", said Tom subversively. X-Kibo: Make life fun with communication! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981118, Robert Church wrote: > I don't think it's documented anywhere. I figured it out after about > two hours of trial, error, and reading source code. Sorry about that, I'll see if I can make it any better. > (define pie-menu-obj (dynamic-link "/usr/local/lib/scwm-modules/app/scwm/libpie-menus.so")) That shouldn't be needed. Can you try removing it and seeing if there are any problems? If it is actually needed, info about your version of guile and libtool would be helpful. Thanks in advance! From owner-scwm-discuss@mit.edu Thu Nov 19 01:56:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id BAA02254 for scwm-discuss-outgoing; Thu, 19 Nov 1998 01:56:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id BAA02251 for ; Thu, 19 Nov 1998 01:56:44 -0500 From: mal@bewoner.dma.be Received: from dialup589.brussels.skynet.be by MIT.EDU with SMTP id AA23943; Thu, 19 Nov 98 01:56:33 EST Received: (qmail 14852 invoked by uid 500); 19 Nov 1998 07:02:08 -0000 Date: 19 Nov 1998 07:02:07 -0000 Message-Id: <19981119070207.14851.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet In-Reply-To: References: <199811182347.SAA04019@huis-clos.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Maciej Stachowiak writes: > > > So Red Hat ContribNet is open (see http://developer.redhat.com/). I'd > > really like a volunteer to maintain an RPM of scwm there. I would do > > it myself, but I am super hosed between real life and actually working > > on scwm. > > Speaking of volunteers for things... another project that'd be great to > have someone help out with is a FAQ maintainer.... any takers? > > Greg I don't see that many Frequently Asked Questions on this list? What kind of questions/document do you have in mind? Lieven From owner-scwm-discuss@mit.edu Thu Nov 19 02:03:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA02301 for scwm-discuss-outgoing; Thu, 19 Nov 1998 02:03:35 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA02298 for ; Thu, 19 Nov 1998 02:03:34 -0500 From: mal@bewoner.dma.be Received: from dialup589.brussels.skynet.be by MIT.EDU with SMTP id AA24795; Thu, 19 Nov 98 02:03:22 EST Received: (qmail 15289 invoked by uid 500); 19 Nov 1998 07:08:59 -0000 Date: 19 Nov 1998 07:08:58 -0000 Message-Id: <19981119070858.15280.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Qt widget library is going open-source... Newsgroups: lists.scwm.discuss In-Reply-To: <5l67ccjypa.fsf@tequila.cs.yale.edu> References: <5l67ccjypa.fsf@tequila.cs.yale.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Harvey" == Harvey J Stein writes: > > I'm thinking more along the lines of 20-30 patches, some relying on > > others, some being incompatible. RPM isn't going to fix this one. > > This is even a problem with Linux kernel patches on linux-hq. > > 1 - download Qt, untar it into `qt' > 2 - `cvs import qt VENDOR qt-1_41' it into your personal repository > 3 - hack hack hack > 4 - (until here, nothing new) Now, to make a distribution of your code: > (Time to dig out good ol' /bin/sh) > > #/bin/sh > cvs co -r VENDOR $1 > cd $1 > cvs rdiff -c -r VENDOR $1 >patch > cd .. > tar zclf $1-$(date +%Y%b%d).tarpatch.gz $1 > rm -r $1 > > 5 - to untar such a distribution > > #!/bin/sh > tarfile=$1 > oldifs="$IFS"; IFS='-'; set -- $tarfile; IFS="$oldifs" > [ -d $1 ] && (echo "target dir already exist"; exit 1) > tar zxvpf $tarfile > cd $1 || (echo "can't find target dir"; exit 1) > patch -f -p1 > Big deal ! > You didn't catch the reference to the minix situation I think. Indeed for one person/group making changes it's trivial. But you soon get to the point one distribution has added X, another Y, yet another has fixed Z and you have to merge the resulting mess yourselves since nobody has distribution rights to a modified global package. As someone else remarked, this really encourages forking. In theory someone could take all these patches, merge them and distribute his merger as one patch, but this is very labor consuming and you get a combinatorial explosion of packages. I think you can find a description of the minix mess in the Linus/Tannenbaum flamewar. Instructions for installing a more or less working minix were of the form: first install the version you bought, then get patch X v1.2.7 from Y, mail Z for his patches, get ..... It can be done, but it's not going to make a popular system. > > Stefan Lieven From owner-scwm-discuss@mit.edu Thu Nov 19 02:37:40 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id CAA02571 for scwm-discuss-outgoing; Thu, 19 Nov 1998 02:37:40 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id CAA02568 for ; Thu, 19 Nov 1998 02:37:39 -0500 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA28519; Thu, 19 Nov 98 02:37:32 EST Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id IAA09416; Thu, 19 Nov 1998 08:37:27 +0100 (MET) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id IAA03755; Thu, 19 Nov 1998 08:37:09 +0100 (MET) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13907.51876.764477.289664@chl> Date: Thu, 19 Nov 1998 08:37:08 +0100 (MET) To: Maciej Stachowiak Cc: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: Scheme documentation question. In-Reply-To: <199811182317.SAA03692@huis-clos.mit.edu> References: <199811182246.AAA32065@blinky.bfr.co.il> <199811182317.SAA03692@huis-clos.mit.edu> X-Mailer: VM 6.59 under Emacs 20.2.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: >> (define-public variable value optional-doc-string) >> >> Can't this be made to work? >> Wouldn't this break if run with older versions of guile? I know things is in such a flux, both with guile and scwm, that backwards compability seems to an ideal currently out of reach, but wouldn't it be better to define a new macro, that accepted the extra parameter, rather than changing guile and hardwiring to that (could even make it a defvar like thing, ala emacs/CL) Another strategy could be to do something like: (define-public variable value) "documentation" Guile won't mind the extra string, and now it would be visible to `read' (at a slight performance cost). Endless variations on the above is possible, such as: (define-public variable value) '(doc-add variable "documentation") ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Thu Nov 19 03:13:57 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA03056 for scwm-discuss-outgoing; Thu, 19 Nov 1998 03:13:57 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA03053 for ; Thu, 19 Nov 1998 03:13:55 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA13714; Thu, 19 Nov 98 03:13:51 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA02424; Thu, 19 Nov 1998 10:13:45 +0200 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Nov 1998 10:13:45 +0200 In-Reply-To: Sam Steingold's message of "18 Nov 1998 20:15:42 -0500" Message-Id: Lines: 39 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Steingold writes: > >>>> In message > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >>>> Sent on 18 Nov 1998 23:51:27 +0200 > >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: > >> Sam Steingold writes: > >> > >> > >>>> In message > >> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > >> > >>>> Sent on 17 Nov 1998 15:16:07 -0800 > >> > >>>> Honorable Greg Badros writes: > >> > >> Robert Bihlmeyer writes: > >> > >> > Most of us have guile already loaded - inside our window managers. Why > >> > >> > not scwmexec it? > >> > >> Because it'll stop interactive response of our windowing system. :-( > >> > > >> > well, isn't multi-threading supposed to prevent this? > >> > >> Where are the smilies? > > I was serious. > > I would appreciate an elucidation. What thread support does guile have? Only this internal threading package, as far as I know. It's still possible for a thread to get blocked in which case all threads get blocked. It's not posix thread based. I'm not even sure they're preemptive threads. I'm not sure they're well supported - they may not even work with the latest version. I'd say that the time frame for having dependable threading in guile is so far in the future that it's not reasonable to wait for it. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Nov 19 03:50:15 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA04140 for scwm-discuss-outgoing; Thu, 19 Nov 1998 03:50:15 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA04136 for ; Thu, 19 Nov 1998 03:50:13 -0500 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA05632; Thu, 19 Nov 98 03:50:08 EST Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id JAA11576; Thu, 19 Nov 1998 09:50:09 +0100 (MET) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id JAA03900; Thu, 19 Nov 1998 09:49:49 +0100 (MET) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13907.56236.859220.261893@chl> Date: Thu, 19 Nov 1998 09:49:48 +0100 (MET) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: threads (was Re: docs: scwm-procedures.txt) In-Reply-To: References: <199811162229.RAA03855@huis-clos.mit.edu> X-Mailer: VM 6.59 under Emacs 20.2.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Harvey" == Harvey J Stein writes: ... Harvey> I'm not even sure they're preemptive threads. It is true that guile threads are not posix threads, and that there parts of the guile kernel that has not been properly threadified yet. However, guile threads are preemptive at the scheme level. Two scheme functions running in separate threads will get preemptively interleaved, in that context switches may happen at each evaluator tick, so to speak. I think most I/O are thread aware. You may hang up one thread in a select or a read, and other threads will happily continue running. Harvey> I'm not sure they're well supported The basics are there. What is missing is mainly inspecting threads and their state (essential when debugging deadlocks). Harvey> they may not even work with the latest version. They most certainly do, we are developing some rather complex code that would not survive without threads. There are a least one bug in the condition variable synchronisation feature, but a patch for that is on its way. Harvey> I'd say that the time frame for having dependable threading in guile Harvey> is so far in the future that it's not reasonable to wait for it. It is always dangerous to hold ones breath, but threads are usable, even today. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Thu Nov 19 03:55:46 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id DAA04191 for scwm-discuss-outgoing; Thu, 19 Nov 1998 03:55:46 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id DAA04188 for ; Thu, 19 Nov 1998 03:55:45 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA17214; Thu, 19 Nov 98 03:55:42 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA02647; Thu, 19 Nov 1998 10:55:30 +0200 To: Christian Lynbech Cc: scwm-discuss@mit.edu Subject: Re: threads (was Re: docs: scwm-procedures.txt) References: <199811162229.RAA03855@huis-clos.mit.edu> <13907.56236.859220.261893@chl> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Nov 1998 10:55:30 +0200 In-Reply-To: Christian Lynbech's message of "Thu, 19 Nov 1998 09:49:48 +0100 (MET)" Message-Id: Lines: 27 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Christian Lynbech writes: > It is true that guile threads are not posix threads, and that there > parts of the guile kernel that has not been properly threadified yet. > > However, guile threads are preemptive at the scheme level. Two scheme > functions running in separate threads will get preemptively > interleaved, in that context switches may happen at each evaluator > tick, so to speak. > > I think most I/O are thread aware. You may hang up one thread in a > select or a read, and other threads will happily continue running. > It is always dangerous to hold ones breath, but threads are usable, > even today. I stand corrected. For once Guile has a working feature that I didn't think it had. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Nov 19 09:14:07 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA05422 for scwm-discuss-outgoing; Thu, 19 Nov 1998 09:14:07 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id JAA05413 for ; Thu, 19 Nov 1998 09:11:59 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id PAA07461 for scwm-discuss@huis-clos.mit.edu; Thu, 19 Nov 1998 15:00:43 +0100 (MET) Received: (qmail 4430 invoked by uid 115); 19 Nov 1998 13:53:01 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm and guile-gtk References: <199811190339.WAA30233@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 19 Nov 1998 14:52:58 +0100 In-Reply-To: cwitty@newtonlabs.com's message of "18 Nov 1998 21:32:57 -0800" Message-ID: Lines: 20 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 18 Nov 1998 21:32:57 -0800 >>>>> cwitty@newtonlabs.com (Carl R. Witty) said: Carl> Would these "potential crashes" affect all scwm users, or can Carl> they be avoided just by never using the (app scwm gtk) (or Carl> whatever) module? If the crashes only affect people who Carl> actually try to use gtk, then by all means, commit on the head. That's also my opinion. Should probably be dubbed "experimental support for guile-gtk" in the NEWS file. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Nov 19 09:57:19 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id JAA05605 for scwm-discuss-outgoing; Thu, 19 Nov 1998 09:57:19 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id JAA05598 for ; Thu, 19 Nov 1998 09:56:49 -0500 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA06820; Thu, 19 Nov 98 09:56:30 EST Received: from localhost (cstruble@localhost) by csgrad.cs.vt.edu (8.9.1a/8.9.1) with SMTP id JAA26728; Thu, 19 Nov 1998 09:56:18 -0500 (EST) X-Authentication-Warning: csgrad.cs.vt.edu: cstruble owned process doing -bs Date: Thu, 19 Nov 1998 09:56:17 -0500 (EST) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 18 Nov 1998, Robert Bihlmeyer wrote: > > Hi, > > >>>>> On Wed, 18 Nov 1998 02:20:55 -0500 (EST) > >>>>> Craig Struble said: > > Craig> 2. Menus only appear over kept-on-top windows after the menu > Craig> has been displayed twice. They should be displayed on the > Craig> first shot. > > This I can't reproduce. > Check my second message about this. I wasn't explicit enough in my statement of menus. I should have said application menus (e.g. Netscape, xsm, and Tcl/Tk applications too). I believe this is probably due to the fact that scwm is seeing the application menus as undecorated windows, so windows kept-on-top are, well, kept on top. The second time the menu is posted, it shows up properly, so it'd be nice to have scwm get it right the first time too. > Craig> 3. The session manager code isn't writing out the proper width > Craig> and height of clients. My xsm window gets sized too tall and > Craig> wide when I start my session. > > I fiddled a lot with this, until it worked for me, but I may well have > broken it for the other gadzillion possible window configurations. > > Could you tell me what exactly you are seeing? How much does the > window grow larger? What is your border and title width? Any > correlations? > I'll get back to you on this with hard numbers. Just guessing, it appears that the window is getting resized by its border width and height, which I found surprising when I read in the Changelog that it was now handled properly. Actually, come to think of it, the sizing was fine BEFORE that change existed. The window itself has no titlebar. It's basically the desk-widget-on-top style ripped from `sample.scwmrc/decor.scm'. > I'm glad someone other than me is using session-management at all . > Well, I wanted to play with it after I kept reading emails that it was supported. I need to hack on smproxy to include the proper patches for scwm and also to figure out why it crashes every time I run Netscape. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Thu Nov 19 10:05:05 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA05642 for scwm-discuss-outgoing; Thu, 19 Nov 1998 10:05:05 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from sig.bsh.com (sig-int-206.33.103.14.sig.bsh.com [206.33.103.14]) by huis-clos.mit.edu (8.8.5/8.8.5) with ESMTP id KAA05639 for ; Thu, 19 Nov 1998 10:04:29 -0500 Received: from jasonk (sig-int-192-233-221-112.sig.bsh.com [192.233.221.112]) by sig.bsh.com (8.8.5/8.7.3/http://www.sig.bsh.com) with SMTP id KAA18900 for ; Thu, 19 Nov 1998 10:04:11 -0500 (EST) From: "jason kirtland" To: Subject: (focus) is tossing windows around Date: Thu, 19 Nov 1998 10:04:05 -0500 Message-ID: <000701be13cd$d9e2dea0$70dde9c0@jasonk.sig.bsh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-scwm-discuss@mit.edu Precedence: bulk (focus) seems to be moving my windows around- which is seems to be designed to do, in a limited sense (aligning in and to viewport snap settings). However, for some reason (focus) is moving my windows _really far_. If the current viewport is somewhere other than 0,0, (focus) will move the window some random number of screens towards 0,0. For example: Starting Position Ending Position Viewport Window Viewport + Window -------- --------- ----------------- 0,0 any,any any,any (proper behavior) 0,1 3,5 3,4 (up 1) 3,4 3,5 1,1 4,1 3,2 0,0 3,5 8,5 5,0 I've also seen- but can't reliably reproduce- the following: single-axis moves, e.g. left 2 screens, or up to the top, and a phenomenon in which calling (focus) on a window which has just warped will move just the viewport one screen above the window location. A dramatic way to test this bug is to set up a window circulation binding with next-window's proc set to only focus. Cycle through for a while and windows will start piling up towards 0,0. As far as configuration goes, I've got Revision 1.903 set up to be as close to an unbounded desktop as possible: big 9x9 desk surface, edge scrolling and x/y wrapping. I've reproduced this bug with my viewports aligned to the snap boundries and offset random amounts. In my ideal world, there would be a focus primitive that _only_ gave focus to the window, and left viewport placement/warping to other procs. For what I'm trying to achieve, viewport snap is counter-productive. -Jason PS- If folks are still wanting to implement true unbounded desktops (ala gwm), I'd be happy to share my thoughts on desired features and behaviors. From owner-scwm-discuss@mit.edu Thu Nov 19 10:27:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id KAA05784 for scwm-discuss-outgoing; Thu, 19 Nov 1998 10:27:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id KAA05780 for ; Thu, 19 Nov 1998 10:27:19 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA17981; Thu, 19 Nov 98 10:27:08 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA18818; Thu, 19 Nov 1998 07:26:55 -0800 (PST) To: mal@bewoner.dma.be Cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> From: Greg Badros Date: 19 Nov 1998 07:26:55 -0800 In-Reply-To: mal@bewoner.dma.be's message of "19 Nov 1998 07:02:07 -0000" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > I don't see that many Frequently Asked Questions on this list? What > kind of questions/document do you have in mind? Anything that a newbie might want to know that might otherwise be hard to find out. (Vague, I know! :-) ). Any question that's been asked on this list more than once probably qualifies. Fake FAQ that point users to special features or narratively describe some simple procedures for customization might be useful. Also, pointers-to-other-information questions like "Where can I learn more about Scheme?" "Where can I find other useful scheme code?". Other suggestions are welcome.... I'd love to see a handful of the above-type questions addressed, and then someone (you???) to watch the list (and maybe pass-over the archive, too) for things that cause difficulties, and ask yourself for each if there is a relevant FAQ-like question that could've eased this person's difficulties. If so, add the question and answer. Greg From owner-scwm-discuss@mit.edu Thu Nov 19 11:29:52 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06463 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:29:52 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06460 for ; Thu, 19 Nov 1998 11:29:51 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA13803; Thu, 19 Nov 98 11:29:46 EST Received: from licia.dtek.chalmers.se (d4jonas@licia.dtek.chalmers.se [129.16.30.88]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA14084 for ; Thu, 19 Nov 1998 17:29:42 +0100 (MET) Received: (from d4jonas@localhost) by licia.dtek.chalmers.se (8.8.8/8.8.8) id RAA27831; Thu, 19 Nov 1998 17:29:41 +0100 (MET) To: scwm-discuss@mit.edu Subject: Documentation (Was: Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 19 Nov 1998 17:29:41 +0100 In-Reply-To: Greg Badros's message of "18 Nov 1998 16:22:03 -0800" Message-Id: Lines: 44 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: [...] > Speaking of volunteers for things... another project that'd be great to > have someone help out with is a FAQ maintainer.... any takers? I don't think that it is only a FAQ that is needed - the entire documentation is ... lacking - to say the least. The scwm[1] I use has - AFAIK - only a buggy info-file with more or less a long list of functions. That is good (sort of) for someone that knows how scwm works and what everything is. What I want is an user-documentation, e.g. "how do I add buttons on the title-bar of a window?", "how do I change the look of the frame of a window?". These are FAQ's but you have a FAQL if there is no manual. I think a manual is - at this stage - more important then a FAQL if we wants more users. They can't ask questions before they know what they should ask about. I've started on a manual but the problem is that I know too little of SCWM to be able to write it, it is a pre-pre-pre-alpha version: I will probably remove the list of functions (the main part as it is now) in the future. That is something that should be automatically generated (as already stated in the list). If someone could send me how to do some of the things I will add them. I don't know when 0.9 is scheduled to ship but it would be nice to have a new-user-manual to send with it. I currently have quite some studying to do (Chalmers Uni. of Technology, Master of Science in Computer Science and Engineering if you have to know) but after X-mas I probably have some time (yeah right!) over for putting together something - with your help - that would look like a manual to the unexpirenced eye. Opinions? [1] % scwm --version Scwm Version 0.8a compiled on Sep 25 1998 at 17:26:00 RCS_ID=$Id: scwm.c,v 1.107 1998/08/13 01:09:39 gjb Exp $ -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Thu Nov 19 11:33:47 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06530 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:33:47 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06527 for ; Thu, 19 Nov 1998 11:33:22 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA15154; Thu, 19 Nov 98 11:33:11 EST Received: from licia.dtek.chalmers.se (d4jonas@licia.dtek.chalmers.se [129.16.30.88]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA14500 for ; Thu, 19 Nov 1998 17:33:08 +0100 (MET) Received: (from d4jonas@localhost) by licia.dtek.chalmers.se (8.8.8/8.8.8) id RAA28410; Thu, 19 Nov 1998 17:33:07 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 19 Nov 1998 17:33:07 +0100 In-Reply-To: mal@bewoner.dma.be's message of "19 Nov 1998 07:02:07 -0000" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: [...] > I don't see that many Frequently Asked Questions on this list? That might be because of 99 % of the posts are made by the developers. A better name of the list would be scwm-devel. You can't have FAQ's before you have users... ;-) (See other post I just made [Documentation].) /Jonas, lurker and newbie. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Thu Nov 19 11:50:16 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06774 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:50:16 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06769 for ; Thu, 19 Nov 1998 11:50:11 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA21489; Thu, 19 Nov 98 11:50:05 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19009; Thu, 19 Nov 1998 08:49:58 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: Documentation (Was: Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> From: Greg Badros Date: 19 Nov 1998 08:49:58 -0800 In-Reply-To: Jonas Steverud's message of "19 Nov 1998 17:29:41 +0100" Message-Id: Lines: 74 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > Greg Badros writes: > > [...] > > > Speaking of volunteers for things... another project that'd be great to > > have someone help out with is a FAQ maintainer.... any takers? > > I don't think that it is only a FAQ that is needed - the entire > documentation is ... lacking - to say the least. The scwm[1] I use has This seems overly critical... have you used the online reference manual or looked over: http://www.cs.washington.edu/homes/gjb/scwm-doc/ > - AFAIK - only a buggy info-file with more or less a long list of > functions. That is good (sort of) for someone that knows how scwm I'm assumming that this means you don't know about the above... there is a link from the web page under "Documentation." I just added a pointer at the top of the README to the docs file. > works and what everything is. What I want is an user-documentation, > e.g. "how do I add buttons on the title-bar of a window?", "how do I > change the look of the frame of a window?". These are FAQ's but you > have a FAQL if there is no manual. I think a manual is - at this stage > - more important then a FAQL if we wants more users. They can't ask > questions before they know what they should ask about. I've started on > a manual but the problem is that I know too little of SCWM to be able > to write it, it is a pre-pre-pre-alpha version: > > > I will probably remove the list of functions (the main part as it is > now) in the future. That is something that should be automatically > generated (as already stated in the list). It is already... > > If someone could send me how to do some of the things I will add > them. I don't know when 0.9 is scheduled to ship but it would be nice > to have a new-user-manual to send with it. We've had at least a reference manual since at least 0.8. > > I currently have quite some studying to do (Chalmers Uni. of > Technology, Master of Science in Computer Science and Engineering if > you have to know) but after X-mas I probably have some time (yeah > right!) over for putting together something - with your help - that > would look like a manual to the unexpirenced eye. > > Opinions? You're right that there needs to be more for the novice user who doesn't even know where to begin. The "Concepts" sections of the current manual are not ideal in that they do not address "how do I..." kinds of questions. You still need some familiarity with Scwm to know where to look. For now, sample.scwmrc/* and doc/scwm-intro-tutorial.scm (incomplete) are attempts to fill these very real voids. It'd be great for others (such as yourself) to pitch in and help with the addition of more introductory material; accumulating a list of things that you had to figure out how to do because the existing documentation was insufficient would be a useful place to start. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Nov 19 11:57:35 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06921 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:57:35 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06918 for ; Thu, 19 Nov 1998 11:57:34 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA12534; Thu, 19 Nov 98 11:57:25 EST Received: from licia.dtek.chalmers.se (d4jonas@licia.dtek.chalmers.se [129.16.30.88]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA17686 for ; Thu, 19 Nov 1998 17:57:25 +0100 (MET) Received: (from d4jonas@localhost) by licia.dtek.chalmers.se (8.8.8/8.8.8) id RAA00846; Thu, 19 Nov 1998 17:57:21 +0100 (MET) To: scwm-discuss@mit.edu Subject: Moving mouse with arrows and menues in netscape X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 19 Nov 1998 17:57:21 +0100 Message-Id: Lines: 26 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Since someone asked for FAQs... ;-) >From .scwmrc: (bind-key 'all "H-M-Left" (lambda () (move-pointer (%x -1) 0))) (bind-key 'all "H-M-Right" (lambda () (move-pointer (%x 1) 0))) (bind-key 'all "H-M-Up" (lambda () (move-pointer 0 (%y -1)))) (bind-key 'all "H-M-Down" (lambda () (move-pointer 0 (%y 1)))) (bind-key 'all "H-M-1" (lambda () (send-button-press 1))) (bind-key 'all "H-M-2" (lambda () (send-button-press 2))) (bind-key 'all "H-M-3" (lambda () (send-button-press 3))) (bind-key 'all "Help" (lambda () (show-window-list-menu #:show-geometry #t))) When I do 'H-M-3' to bring up the little menu in the "background" of Netscape I then can't move the mouse with H-M-arrows, only mouse. Same thing with show-window-list-menu IIRC (but can move with only arrows up and down IIRC). Bug or feature? SCWM 0.8a. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Thu Nov 19 11:57:50 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06937 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:57:50 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06933 for ; Thu, 19 Nov 1998 11:57:49 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA12629; Thu, 19 Nov 98 11:57:40 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA19021; Thu, 19 Nov 1998 08:57:38 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> From: Greg Badros Date: 19 Nov 1998 08:57:38 -0800 In-Reply-To: Jonas Steverud's message of "19 Nov 1998 17:33:07 +0100" Message-Id: Lines: 23 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > mal@bewoner.dma.be writes: > > [...] > > > I don't see that many Frequently Asked Questions on this list? > > That might be because of 99 % of the posts are made by the > developers. A better name of the list would be scwm-devel. > You can't have FAQ's before you have users... ;-) > (See other post I just made [Documentation].) > > /Jonas, lurker and newbie. Well, welcome, and please ask questions. Scwm is in development, so this list certainly will serve to discuss that development, but it most definitely is here to help out people with difficulties using Scwm. I know that nearly every "I can't figure out how to do ..." message gets addressed in some way to make it less likely that some other user will need to ask the same question again. Greg From owner-scwm-discuss@mit.edu Thu Nov 19 11:57:56 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA06957 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:57:56 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id LAA06948 for ; Thu, 19 Nov 1998 11:57:55 -0500 Received: from news.mtu.edu by MIT.EDU with SMTP id AA24558; Thu, 19 Nov 98 11:57:47 EST Received: from mtu.edu (root@mtu.edu [141.219.70.1]) by news.mtu.edu (8.8.8/8.8.8) with ESMTP id LAA23096 for ; Thu, 19 Nov 1998 11:57:43 -0500 (EST) Received: from wiley.sas.it.mtu.edu (wiley.sas.it.mtu.edu [141.219.36.70]) by mtu.edu (8.8.8/8.8.8) with ESMTP id LAA22121 for ; Thu, 19 Nov 1998 11:57:43 -0500 (EST) Received: (from adisaacs@localhost) by wiley.sas.it.mtu.edu (8.8.7/8.8.7/mturelay-1.2) id LAA18063 for scwm-discuss@mit.edu; Thu, 19 Nov 1998 11:57:41 -0500 (EST) Message-Id: <19981119115741.C11920@mtu.edu> Date: Thu, 19 Nov 1998 11:57:41 -0500 From: Andrew Isaacson To: scwm-discuss@mit.edu Subject: Documentation suggestions (was Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: ; from Jonas Steverud on Thu, Nov 19, 1998 at 05:33:07PM +0100 X-Pgp-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-Pgp-Key-Url: http://www.csl.mtu.edu/~adisaacs/pgp.txt Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Nov 19, 1998 at 05:33:07PM +0100, Jonas Steverud wrote: > mal@bewoner.dma.be writes: > > I don't see that many Frequently Asked Questions on this list? > > That might be because of 99 % of the posts are made by the > developers. A better name of the list would be scwm-devel. > You can't have FAQ's before you have users... ;-) > (See other post I just made [Documentation].) > > /Jonas, lurker and newbie. Yeah, me too. I've been interested in scwm for a while, and I just installed it on my new Linux box. It's working pretty well, but some better documentation would be nice. Kind of a how-to, I think. Here's a few things I think should be documented: How do I: - map keybindings to mouse moves (I like mod-hjkl to move the mouse 10% of the screen) - map mouse events to occurrences (I have mod-123 bound to raise-or-lower, move, and resize respectively, with mod-3 on the root window bound to (exec "xterm")) - change the window appearance - change the titlebar button bindings, button looks, etc Some of those I figured out on my own, and I'm not sure just how helpful a how-to document would be long term (if you're not capable of searching the documentation, scwm probably isn't the WM for you, it seems to me), but it sure would be helpful for newbies like me. But then, I learn best from task-oriented howto type of documentation, so maybe I'm just a freak. :) -andy -- Andy Isaacson adisaacs@mtu.edu adi@acm.org Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/ From owner-scwm-discuss@mit.edu Thu Nov 19 11:59:10 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA07052 for scwm-discuss-outgoing; Thu, 19 Nov 1998 11:59:10 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id LAA07018; Thu, 19 Nov 1998 11:58:49 -0500 Message-Id: <199811191658.LAA07018@huis-clos.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) cc: scwm-discuss@mit.edu Subject: Re: scwm and guile-gtk In-reply-to: Your message of "18 Nov 1998 21:32:57 PST." Date: Thu, 19 Nov 1998 11:58:49 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Maciej Stachowiak writes: > > > I have code in my working dir for scwm to work almost seamlessly with > > guile-gtk-0.12 and gtk+-1.0.6. However, I can't guarantee that there > > might not be potential crashes left, and we have this release thing > > coming up. Should I commit on the head or on a branch? Either way I > > would like people to try out the code and play with it as possible. I > > have to go watch Babylon 5 now but I'll try to do more with this later > > tonight or tomorrow. > > Would these "potential crashes" affect all scwm users, or can they be > avoided just by never using the (app scwm gtk) (or whatever) module? > If the crashes only affect people who actually try to use gtk, then by > all means, commit on the head. > > (If I only had time, I'd love to play with gtk in scwm.) > The only potential effects are to people who actually use Gtk (the changes to the core are trivial and harmless, specifically making some static functions have extern linkage). I am still not sure I want a release to have stuff in it that might kill the window manager, but I could always remove relevant files from the distribution, I guess. - Maciej From owner-scwm-discuss@mit.edu Thu Nov 19 12:06:20 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07132 for scwm-discuss-outgoing; Thu, 19 Nov 1998 12:06:20 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07122; Thu, 19 Nov 1998 12:05:31 -0500 Message-Id: <199811191705.MAA07122@huis-clos.mit.edu> To: mal@bewoner.dma.be cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet In-reply-to: Your message of "19 Nov 1998 07:02:07 GMT." <19981119070207.14851.qmail@localhost.localdomain> Date: Thu, 19 Nov 1998 12:05:31 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > Greg Badros writes: > > Maciej Stachowiak writes: > > > > > So Red Hat ContribNet is open (see http://developer.redhat.com/). I'd > > > really like a volunteer to maintain an RPM of scwm there. I would do > > > it myself, but I am super hosed between real life and actually working > > > on scwm. > > > > Speaking of volunteers for things... another project that'd be great to > > have someone help out with is a FAQ maintainer.... any takers? > > > > Greg > > I don't see that many Frequently Asked Questions on this list? What > kind of questions/document do you have in mind? > I imagine Greg means the sort of questions that people who are not yet familiar with scwm might ask. I have a hard time thinking of what those might be myself, though. - Maciej From owner-scwm-discuss@mit.edu Thu Nov 19 12:10:08 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07225 for scwm-discuss-outgoing; Thu, 19 Nov 1998 12:10:08 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA07222 for ; Thu, 19 Nov 1998 12:10:08 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA17993; Thu, 19 Nov 98 12:09:57 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA19057; Thu, 19 Nov 1998 09:09:51 -0800 (PST) To: Andrew Isaacson Cc: scwm-discuss@mit.edu Subject: Re: Documentation suggestions (was Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> <19981119115741.C11920@mtu.edu> From: Greg Badros Date: 19 Nov 1998 09:09:50 -0800 In-Reply-To: Andrew Isaacson's message of "Thu, 19 Nov 1998 11:57:41 -0500" Message-Id: Lines: 64 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Andrew Isaacson writes: > On Thu, Nov 19, 1998 at 05:33:07PM +0100, Jonas Steverud wrote: > > mal@bewoner.dma.be writes: > > > I don't see that many Frequently Asked Questions on this list? > > > > That might be because of 99 % of the posts are made by the > > developers. A better name of the list would be scwm-devel. > > You can't have FAQ's before you have users... ;-) > > (See other post I just made [Documentation].) > > > > /Jonas, lurker and newbie. > > Yeah, me too. I've been interested in scwm for a while, and I just > installed it on my new Linux box. It's working pretty well, but some > better documentation would be nice. Kind of a how-to, I think. > Here's a few things I think should be documented: Cool... the beginnings of a FAQ... > > How do I: > - map keybindings to mouse moves (I like mod-hjkl to move the mouse > 10% of the screen) ;; From sample.scwmrc/gjb.scwmrc (key-mouse-moves "C-M-S" 10 "h" "j" "k" "l") ;; use C-M-S-{h,j,k,l} > - map mouse events to occurrences (I have mod-123 bound to > raise-or-lower, move, and resize respectively, with mod-3 on the > root window bound to (exec "xterm")) See the bind-mouse documentation, or samples in sample.scwmrc. > - change the window appearance The window-style documentation is uniquely bad; the best source of information here is examples in sample.scwmrc/* > - change the titlebar button bindings, button looks, etc bind-mouse with, e.g., 'button-1 as the context setting. Button looks are controlled with make-face, and then set-button-face! See sample.scwmrc/* > Some of those I figured out on my own, and I'm not sure just how > helpful a how-to document would be long term (if you're not capable of > searching the documentation, scwm probably isn't the WM for you, it > seems to me), but it sure would be helpful for newbies like me. But > then, I learn best from task-oriented howto type of documentation, so > maybe I'm just a freak. :) Right, this is exactly the kind of stuff that we need to add so that new users can get a feeling for the right approach to finding solutions to problems. My answers above are by no means the perfect FAQ or task-manual answers, but are sufficient pointers that our hypothetical FAQ maintainer could flesh them out with examples culled from the samples I reference. Your questions are excellent-- some of the things you want to know how to do are definite weak points in our documentation, and the best way to learn how to accomplish the tasks are by reading and studying a sample.scwmrc/* file that does them. Thanks, Greg From owner-scwm-discuss@mit.edu Thu Nov 19 12:21:06 1998 Received: (from mjrdmo@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07519 for scwm-discuss-outgoing; Thu, 19 Nov 1998 12:21:06 -0500 X-Authentication-Warning: huis-clos.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by huis-clos.mit.edu (8.8.5/8.8.5) with SMTP id MAA07516 for ; Thu, 19 Nov 1998 12:21:06 -0500 Received: from HUIS-CLOS.MIT.EDU by MIT.EDU with SMTP id AA22253; Thu, 19 Nov 98 12:20:55 EST Received: (from mstachow@localhost) by huis-clos.mit.edu (8.8.5/8.8.5) id MAA07506; Thu, 19 Nov 1998 12:21:00 -0500 Message-Id: <199811191721.MAA07506@huis-clos.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-Reply-To: Your message of "19 Nov 1998 10:13:45 +0200." Date: Thu, 19 Nov 1998 12:21:00 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Sam Steingold writes: > > > >>>> In message > > >>>> On the subject of "Re: docs: scwm-procedures.txt" > > >>>> Sent on 18 Nov 1998 23:51:27 +0200 > > >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: > > >> Sam Steingold writes: > > >> > > >> > >>>> In message > > >> > >>>> On the subject of "Re: docs: scwm-procedures.txt" > > >> > >>>> Sent on 17 Nov 1998 15:16:07 -0800 > > >> > >>>> Honorable Greg Badros writes: > > >> > >> Robert Bihlmeyer writes: > > >> > >> > Most of us have guile already loaded - inside our window managers. > Why > > >> > >> > not scwmexec it? > > >> > >> Because it'll stop interactive response of our windowing system. :- > ( > > >> > > > >> > well, isn't multi-threading supposed to prevent this? > > >> > > >> Where are the smilies? > > > > I was serious. > > > > I would appreciate an elucidation. > > What thread support does guile have? Only this internal threading > package, as far as I know. It's still possible for a thread to get > blocked in which case all threads get blocked. It's not posix > thread based. I'm not even sure they're preemptive threads. I'm not > sure they're well supported - they may not even work with the latest > version. > Guile threads are cooperative but will yield on (most) blocking operations and potentially other places inside Guile calls. They do work with the latest version. Some people even use Guile threads for real work. > I'd say that the time frame for having dependable threading in guile > is so far in the future that it's not reasonable to wait for it. > I disagree. While having preemptive Posix thread support will be nice, Guile's current threads are in fact usable. - Maciej From owner-scwm-discuss@mit.edu Thu Nov 19 12:41:20 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA07914 for scwm-discuss-outgoing; Thu, 19 Nov 1998 12:41:20 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA07906; Thu, 19 Nov 1998 12:41:18 -0500 Message-Id: <199811191741.MAA07906@VICARIOUS-EXISTENCE.MIT.EDU> To: "jason kirtland" cc: scwm-discuss@mit.edu Subject: Re: (focus) is tossing windows around In-reply-to: Your message of "Thu, 19 Nov 1998 10:04:05 EST." <000701be13cd$d9e2dea0$70dde9c0@jasonk.sig.bsh.com> Date: Thu, 19 Nov 1998 12:41:18 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jkirtland@sig.bsh.com writes: > (focus) seems to be moving my windows around- which is seems to be designed > to do, in a limited sense (aligning in and to viewport snap settings). > However, for some reason (focus) is moving my windows _really far_. > > If the current viewport is somewhere other than 0,0, (focus) will move the > window some random number of screens towards 0,0. For example: > > Starting Position Ending Position > Viewport Window Viewport + Window > -------- --------- ----------------- > 0,0 any,any any,any (proper behavior) > 0,1 3,5 3,4 (up 1) > 3,4 3,5 1,1 > 4,1 3,2 0,0 3,5 8,5 5,0 > > I've also seen- but can't reliably reproduce- the following: single-axis > moves, e.g. left 2 screens, or up to the top, and a phenomenon in which > calling (focus) on a window which has just warped will move just the > viewport one screen above the window location. > > A dramatic way to test this bug is to set up a window circulation binding > with next-window's proc set to only focus. Cycle through for a while and > windows will start piling up towards 0,0. > > As far as configuration goes, I've got Revision 1.903 set up to be as close > to an unbounded desktop as possible: big 9x9 desk surface, edge scrolling > and x/y wrapping. I've reproduced this bug with my viewports aligned to the > snap boundries and offset random amounts. > > In my ideal world, there would be a focus primitive that _only_ gave focus > to the window, and left viewport placement/warping to other procs. For what > I'm trying to achieve, viewport snap is counter-productive. > I agree with you. Since other primitives can be combined to achieve that sort of behavior, focus should do nothing but focus. I'll put this on the bug list for 0.9 (unless someone has fixed it and I just haven't read enough of my mail yet). > PS- If folks are still wanting to implement true unbounded desktops (ala > gwm), I'd be happy to share my thoughts on desired features and behaviors. I'd like to do this eventually, but who knows when. Feel free to share your thoughts, though, this list is archived, and if they are lengthy and useful we can always check them into doc/dev. - Maciej From owner-scwm-discuss@mit.edu Thu Nov 19 17:06:04 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA10734 for scwm-discuss-outgoing; Thu, 19 Nov 1998 17:06:04 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@huis-clos.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA10723; Thu, 19 Nov 1998 17:05:53 -0500 Message-Id: <199811192205.RAA10723@vicarious-existence.mit.edu> To: scwm-discuss@mit.edu Subject: Finding what client a Window belongs to Date: Thu, 19 Nov 1998 17:05:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is there any way to find what client a window belongs to, or specifically for a client to check if a given window was created by itself? I ask because the only major scwm/guile-gtk stability problem remaining that I am aware of is that if you `destroy-window' a scwm/guile-gtk created window, scwm XKillClient()s itself, which is clearly a bad thing. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Fri Nov 20 02:45:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA28086 for scwm-discuss-outgoing; Fri, 20 Nov 1998 02:45:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA28082; Fri, 20 Nov 1998 02:45:21 -0500 Message-Id: <199811200745.CAA28082@vicarious-existence.mit.edu> To: scwm-discuss@mit.edu Subject: guile-gtk support Date: Fri, 20 Nov 1998 02:45:16 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just checked in guile-gtk support on the head, along with two sample guile-gtk based applets for scwm, ScwmClock (xclock -digital replacement) and ScwmDeskButtons (a trivial almost-pager). People who want to play with this should try it, but be forewarned, it is highly experimental. In particular, doing a destroy-window on a scwm/guile-gtk created window will kill scwm, so especially make sure not to do that (close-window or delete-window is OK). Other than that, I have not seen any crashes lately. - Maciej PS the canonical hostname for the scwm-hosting machine is `vicarious-existence', but `huis-clos' is still a valid alias. Also, my apologies for the resultant mailing list problems earlier today. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 03:01:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA28232 for scwm-discuss-outgoing; Fri, 20 Nov 1998 03:01:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA28229 for ; Fri, 20 Nov 1998 03:01:53 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA26748; Fri, 20 Nov 98 03:01:35 EST Received: (qmail 2936 invoked by uid 501); 20 Nov 1998 08:01:38 -0000 Message-Id: <19981120000137.A2901@molehill.org> Date: Fri, 20 Nov 1998 00:01:37 -0800 From: Todd Larason To: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: Moving mouse with arrows and menues in netscape References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jonas Steverud on Thu, Nov 19, 1998 at 05:57:21PM +0100 X-Tom-Swifty: "Let's play a joke on the Sun Users Group", Tom suggested. X-Kibo: Kibology is deadly serious. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981119, Jonas Steverud wrote: > When I do 'H-M-3' to bring up the little menu in the "background" of > Netscape I then can't move the mouse with H-M-arrows, only mouse. > Same thing with show-window-list-menu IIRC (but can move with only > arrows up and down IIRC). > > Bug or feature? I think maybe 'misfeature' is the best description. It's working as designed, and redesigning it isn't trivial, but it also isn't 'right'. I'm hoping the Great Event Rewrite will let this be taken care of. Right now, when a menu is open, the menu code handles all events. I suppose it could pass events it doesn't want on to the real event handler, but it seems cleaner to me for the menu code to be able to register the events it's interested in, and return to the main loop. -- ICQ UIN: 13083807 From owner-scwm-discuss@mit.edu Fri Nov 20 10:29:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA31003 for scwm-discuss-outgoing; Fri, 20 Nov 1998 10:29:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA30999 for ; Fri, 20 Nov 1998 10:29:01 -0500 Received: from p-biset.issy.cnet.fr by MIT.EDU with SMTP id AA03263; Fri, 20 Nov 98 10:28:40 EST Received: from ZengHe.augustin.thierry (139.100.161.88 [139.100.161.88]) by p-biset.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id X2YRZB1Z; Fri, 20 Nov 1998 16:28:48 +0100 Received: (from fare@localhost) by ZengHe.augustin.thierry (8.8.7/) id QAA13028; Fri, 20 Nov 1998 16:37:17 +0100 Message-Id: <19981120163715.A13009@ZengHe.issy.cnet.fr> Date: Fri, 20 Nov 1998 16:37:15 +0100 From: Francois-Rene Rideau To: scwm-discuss@mit.edu Subject: Key bindings? Reply-To: Francois-Rene Rideau References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> <19981119115741.C11920@mtu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Mutt 0.91.1 In-Reply-To: <19981119115741.C11920@mtu.edu>; from Andrew Isaacson on Thu, Nov 19, 1998 at 11:57:41AM -0500 X-Mime-Autoconverted: from 8bit to quoted-printable by ZengHe.augustin.thierry id QAA13028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by vicarious-existence.mit.edu id KAA31001 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I feel the need for Emacs-like major and minor modes for scwm keybindings: indeed, some bindings are interesting only in given windows, while others depend on "look and feel", and some windows (doom, etc) really dislike Ctrl-Alt-Arrow and such to be mapped. Why not "steal" key-binding code from Emacs or EDWIN? Just my Euro .02 worth. ## Faré | VN: Уng-Vû Bân | Join the TUNES project! http://www.tunes.org/ ## ## FR: François-René Rideau | TUNES is a Useful, Not Expedient System ## ## Reflection&Cybernethics | Project for a Free Reflective Computing System ## "I think sex is better than logic, but I can't prove it." From owner-scwm-discuss@mit.edu Fri Nov 20 10:46:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA31151 for scwm-discuss-outgoing; Fri, 20 Nov 1998 10:46:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA31137; Fri, 20 Nov 1998 10:46:05 -0500 Message-Id: <199811201546.KAA31137@vicarious-existence.mit.edu> To: Francois-Rene Rideau cc: scwm-discuss@mit.edu Subject: Re: Key bindings? In-reply-to: Your message of "Fri, 20 Nov 1998 16:37:15 +0100." <19981120163715.A13009@ZengHe.issy.cnet.fr> Date: Fri, 20 Nov 1998 10:46:05 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk fare@tunes.org writes: > I feel the need for Emacs-like major and minor modes for scwm keybindings= > : > indeed, some bindings are interesting only in given windows, > while others depend on "look and feel", and some windows (doom, etc) > really dislike Ctrl-Alt-Arrow and such to be mapped. > > Why not "steal" key-binding code from Emacs or EDWIN? > > Just my Euro .02 worth. > I believe our event model rewrite plan will make major/minor modes and things like that eminently feasible. Our first-class event maps can be seen as roughly equivalent to Emacs keymaps, and modes, multi-event/multi-key bindings, strokes, and all that other gratuitous stuff emacs has should be quite readily implementable on top of them. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 11:17:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31438 for scwm-discuss-outgoing; Fri, 20 Nov 1998 11:17:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA31435 for ; Fri, 20 Nov 1998 11:17:38 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA19906; Fri, 20 Nov 98 11:17:15 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22297; Fri, 20 Nov 1998 08:17:03 -0800 (PST) To: Todd Larason Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: Moving mouse with arrows and menues in netscape References: <19981120000137.A2901@molehill.org> From: Greg Badros Date: 20 Nov 1998 08:17:02 -0800 In-Reply-To: Todd Larason's message of "Fri, 20 Nov 1998 00:01:37 -0800" Message-Id: Lines: 31 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981119, Jonas Steverud wrote: > > When I do 'H-M-3' to bring up the little menu in the "background" of > > Netscape I then can't move the mouse with H-M-arrows, only mouse. > > Same thing with show-window-list-menu IIRC (but can move with only > > arrows up and down IIRC). > > > > Bug or feature? > > I think maybe 'misfeature' is the best description. It's working as designed, > and redesigning it isn't trivial, but it also isn't 'right'. I thought Jonas was talking about the netsape menu that a right click brings up (not a Scwm menu)... I can't reproduce this... my pointer movement keybindings work fine as long as I'm in the main event loop (e.g., not a Scwm menu as you mention below). > I'm hoping the Great Event Rewrite will let this be taken care of. Right now, > when a menu is open, the menu code handles all events. I suppose it could > pass events it doesn't want on to the real event handler, but it seems cleaner > to me for the menu code to be able to register the events it's interested in, > and return to the main loop. Right.. that's the plan. But in reality you would probably rarely want to use real mouse movement when a menu is up-- more semantically-meaningful keybindings such as "next menu item" and "last menu item" are far preferable and currently supported (though not generally programmable yet [until the Great Event Rewrite]). Greg From owner-scwm-discuss@mit.edu Fri Nov 20 11:19:28 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31449 for scwm-discuss-outgoing; Fri, 20 Nov 1998 11:19:28 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA31446 for ; Fri, 20 Nov 1998 11:19:27 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20597; Fri, 20 Nov 98 11:19:06 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22300; Fri, 20 Nov 1998 08:18:49 -0800 (PST) To: Francois-Rene Rideau Cc: scwm-discuss@mit.edu Subject: Re: Key bindings? References: <199811182347.SAA04019@huis-clos.mit.edu> <19981119070207.14851.qmail@localhost.localdomain> <19981119115741.C11920@mtu.edu> <19981120163715.A13009@ZengHe.issy.cnet.fr> From: Greg Badros Date: 20 Nov 1998 08:18:49 -0800 In-Reply-To: Francois-Rene Rideau's message of "Fri, 20 Nov 1998 16:37:15 +0100" Message-Id: Lines: 13 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Francois-Rene Rideau writes: > I feel the need for Emacs-like major and minor modes for scwm keybindings: > indeed, some bindings are interesting only in given windows, > while others depend on "look and feel", and some windows (doom, etc) > really dislike Ctrl-Alt-Arrow and such to be mapped. See doc/dev/events.gjb for notes about our plans for a rewrite of the event mechanism. (Maciej, did you do another revision based on your last comments? I can't remember if the last email or two exchange on the topic got incorporated into this file...) Greg From owner-scwm-discuss@mit.edu Fri Nov 20 11:39:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31684 for scwm-discuss-outgoing; Fri, 20 Nov 1998 11:39:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA31681 for ; Fri, 20 Nov 1998 11:39:26 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA14542; Fri, 20 Nov 98 11:39:07 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA20180 for ; Fri, 20 Nov 1998 17:39:05 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id RAA08820; Fri, 20 Nov 1998 17:39:05 +0100 (MET) To: scwm-discuss@mit.edu Subject: bind-key and CONTEXT; what is button-3,5-9? X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 17:39:05 +0100 Message-Id: Lines: 28 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In the infofile in bind-key it is spoken of CONTEXT and the possible context are: `window', `title', `icon', `root', `frame', `sidebar', `button-1', `button-2', `button-3', `button-4', `button-5', `button-6', `button-7', `button-8', `button-9', `button-10', `all' I've deduced what button-1,2 and 4 are but what are button-3,5-9? The reason is that I want to in my SCWMDoc to give the anatomy of a window (this is the frame, this is the titlebar as SCWM sees it...). A short description of it's anatomy would be great. To be used in (with-decor js-testdecor (title-style #:justify 'center) (button-style 6 ; !? #:relief 'flat #:pixmap "mini-ball.xpm") ) /Jonas, who doesn't have time for this... He should be studying. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 11:48:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31910 for scwm-discuss-outgoing; Fri, 20 Nov 1998 11:48:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA31907 for ; Fri, 20 Nov 1998 11:48:36 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA17703; Fri, 20 Nov 98 11:48:18 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA22337; Fri, 20 Nov 1998 08:48:08 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: From: Greg Badros Date: 20 Nov 1998 08:48:08 -0800 In-Reply-To: Jonas Steverud's message of "20 Nov 1998 17:39:05 +0100" Message-Id: Lines: 57 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > In the infofile in bind-key it is spoken of CONTEXT and the possible > context are: > > `window', `title', `icon', `root', `frame', `sidebar', `button-1', > `button-2', `button-3', `button-4', `button-5', `button-6', > `button-7', `button-8', `button-9', `button-10', `all' > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? They're numbered like so: 1 3 5 7 9 10 8 6 4 2 ^^^ leftmost buttons ^^^ rightmost > > The reason is that I want to in my SCWMDoc to give the anatomy of a > window (this is the frame, this is the titlebar as SCWM sees it...). This is a good goal, but I'd really like to make sure we're not duplicating effort. The description is missing from our extracted documentation, but the right place for this to go is in the source file binding.c after: /**CONCEPT: Event Contexts Though it may be worth ultimately having a tutorial-like manual separate from the reference documentation, I think our time now is better-spent on the more-tightly-coupled documentation that is included in the source code. Things in scwm are still changing pretty quickly, and keeping a slew of side documentation in synch is a pain. I love that you're interested in improving the documentation, but perhaps you could start sending in patches for the in-source DocBook documentation instead of spending a lot of effort on something that will more easily become obsolete. > > A short description of it's anatomy would be great. > > To be used in > (with-decor js-testdecor > (title-style #:justify 'center) > (button-style 6 ; !? > #:relief 'flat > #:pixmap "mini-ball.xpm") > ) > > > /Jonas, who doesn't have time for this... He should be studying. Me too! :-) Thanks! Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:15:15 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32185 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:15:15 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32178; Fri, 20 Nov 1998 12:15:12 -0500 Message-Id: <199811201715.MAA32178@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Key bindings? In-reply-to: Your message of "20 Nov 1998 08:18:49 PST." Date: Fri, 20 Nov 1998 12:15:12 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Francois-Rene Rideau writes: > > > I feel the need for Emacs-like major and minor modes for scwm keybindings: > > indeed, some bindings are interesting only in given windows, > > while others depend on "look and feel", and some windows (doom, etc) > > really dislike Ctrl-Alt-Arrow and such to be mapped. > > See doc/dev/events.gjb for notes about our plans for a rewrite of the > event mechanism. (Maciej, did you do another revision based on your > last comments? I can't remember if the last email or two exchange on > the topic got incorporated into this file...) > I haven't yet done a merged version with all comments. I will check one in when I get a chance. (The list is archived, so the comments are available, just not convenient. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 12:23:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32340 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:23:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA32337 for ; Fri, 20 Nov 1998 12:23:17 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA12604; Fri, 20 Nov 98 12:22:55 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA27287 for ; Fri, 20 Nov 1998 18:22:56 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id SAA08928; Fri, 20 Nov 1998 18:22:56 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 18:22:56 +0100 In-Reply-To: Greg Badros's message of "20 Nov 1998 08:48:08 -0800" Message-Id: Lines: 95 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Jonas Steverud writes: > > > In the infofile in bind-key it is spoken of CONTEXT and the possible > > context are: > > > > `window', `title', `icon', `root', `frame', `sidebar', `button-1', > > `button-2', `button-3', `button-4', `button-5', `button-6', > > `button-7', `button-8', `button-9', `button-10', `all' > > > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > They're numbered like so: > > 1 3 5 7 9 10 8 6 4 2 > ^^^ leftmost buttons ^^^ rightmost I thought so but my little experiment didn't add the buttons to the titlebar. How do I get SCWM to add them? I looked in robbe.scwmrc but it didn't help. This is my entire experimental code: (define js-testdecor (make-decor)) (with-decor js-testdecor (title-style #:justify 'center) (button-style 6 #:relief 'flat #:pixmap "mini-ball.xpm") ) (define js-teststyle (make-style #:fg "black" #:bg "gray" #:show-icon #t #:border-width 6 #:mwm-border #t #:mwm-buttons #t #:use-decor js-testdecor)) (window-style "Calculator" #:use-style js-teststyle) > > The reason is that I want to in my SCWMDoc to give the anatomy of a > > window (this is the frame, this is the titlebar as SCWM sees it...). > > This is a good goal, but I'd really like to make sure we're not > duplicating effort. The description is missing from our extracted > documentation, but the right place for this to go is in the source file > binding.c after: /**CONCEPT: Event Contexts > > Though it may be worth ultimately having a tutorial-like manual separate > from the reference documentation, I think our time now is better-spent > on the more-tightly-coupled documentation that is included in the source > code. Things in scwm are still changing pretty quickly, and keeping a > slew of side documentation in synch is a pain. The problem with helping you with the in-code docs is that I don't got the foggiest what anything does. I have to ask you about what to write... If the general opintion is that we should concentrate on documenting the code and making reference-manuals, just say so and I do a "rm -rf ~/SCWM" and comes back in a couple of years. SCWMDoc is something I can do *now*, DocBook is something I have to learn from the ground up by analysing the code for the next six month - what is "DocBook" to start with? Get the picture? ;-) > I love that you're interested in improving the documentation, but > perhaps you could start sending in patches for the in-source DocBook > documentation instead of spending a lot of effort on something that will > more easily become obsolete. Can't program for X. Don't got the foggiest what a WM should do. (Execept what a ordinary (l)user learns.) No idea how guile interacts with scwm. No C-wizard. (Have to look up strcmp before I use it.) No idea of the design of scwm (how the various c-files interact). How can I then write in-code docs? As it is now I would do more harm then good. Those parts that I put in SCWMDoc will not be in the category rapidily-changing-concepts. SCWMDoc won't cover the last bleeding edge beta-version (like pie-menues) but the last "stable" distribution so I don't see this (the "synch"-issue) as a problem. Or will how to make basic decors change from day to day? ;-) /JS, how knows this sounds like a rant but he hopes noone feels offended. If so: That was not the intention and I apologize. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 12:31:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32423 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:31:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA32418 for ; Fri, 20 Nov 1998 12:31:11 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA03014; Fri, 20 Nov 98 12:30:52 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA00921; Fri, 20 Nov 1998 12:30:44 -0500 (EST) Message-Id: <199811201730.MAA00921@jekyll.piermont.com> To: Greg Badros Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "20 Nov 1998 08:48:08 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Nov 1998 12:30:44 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > They're numbered like so: > > 1 3 5 7 9 10 8 6 4 2 > ^^^ leftmost buttons ^^^ rightmost Is there any reason we couldn't have a more logical numbering scheme used? From owner-scwm-discuss@mit.edu Fri Nov 20 12:32:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32435 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:32:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32427; Fri, 20 Nov 1998 12:32:29 -0500 Message-Id: <199811201732.MAA32427@vicarious-existence.mit.edu> To: Jonas Steverud cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-reply-to: Your message of "20 Nov 1998 17:39:05 +0100." Date: Fri, 20 Nov 1998 12:32:28 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk d4jonas@dtek.chalmers.se writes: > > In the infofile in bind-key it is spoken of CONTEXT and the possible > context are: > > `window', `title', `icon', `root', `frame', `sidebar', `button-1', > `button-2', `button-3', `button-4', `button-5', `button-6', > `button-7', `button-8', `button-9', `button-10', `all' > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > The short answer is that odd-numbered buttons are on the left side and numbered from left to right whereas even-numbered buttons are on the right side and numbered from right to left (see also below). Is this a good naming Scheme? No, it is totally left over from fvwm2, and it sucks. At the very least left buttons should be distinguished from right buttons. > The reason is that I want to in my SCWMDoc to give the anatomy of a > window (this is the frame, this is the titlebar as SCWM sees it...). > I am embarassed to admit I have not looked at your tutorial documentation yet, although we would love to incorporate it. One question though: what format is it written in? We are hoping to standardize on DocBook as the doc format. It doesn't really matter at this stage though - content is more important than markup. > A short description of it's anatomy would be great. > > To be used in > (with-decor js-testdecor > (title-style #:justify 'center) > (button-style 6 ; !? > #:relief 'flat > #:pixmap "mini-ball.xpm") > ) > Here is an ascii-art of window anatomy (under a traditional fvwm-like look): Key: S: sidebar (perhaps should be just "side") C: frame (should be corner or something like that) B1-B10: button1-button10 T: title (probably should be titlebar for consistency) W: window (perhaps should be app-window or client-window?) S----+ | \|/ ______________________________________________________________________________ |C ____|________________________________________________________________|____ C| | | | | | | | | | | | | | | | | B1 | B3 | B5 | B7 | B9 | T |B10 | B8 | B6 | B4 | B2 | | |_|____|____|____|____|____|________________________|____|____|____|____|____|_| | | | | | | | | | | | | |S| | | | | | | | | | | | | | | | | W |S| | | | | | | | | | | | | | | | | | | | | |_| |_| | | | | | | | | |C|__________________________________________________________________________|C| |______|________________________________________________________________|______| ^ /|\ | S----+ - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 12:33:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32467 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:33:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA32464 for ; Fri, 20 Nov 1998 12:33:31 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA03766; Fri, 20 Nov 98 12:33:12 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA28829 for ; Fri, 20 Nov 1998 18:33:10 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id SAA08949; Fri, 20 Nov 1998 18:33:09 +0100 (MET) To: scwm-discuss@mit.edu Subject: Dynamic setting of desk for window when title changes. X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 18:33:09 +0100 Message-Id: Lines: 26 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've have it set up so that when I start Gnus in Emacs it sets the title of the window (by setting the variabel frame-title-format) to "Gnus group". When so is done I want that window moved to desk 5. (window-style "Gnus*" #:use-style js-common-window-style #:start-on-desk WS_News ; 5 ) How is this archieved? The ideal would be some sort of title-has-changed-hook. Did anyone understand the question? Similar to the AutoOccupy in .ctwmrc. As I see it start-on-desk is never trigged since it is _started_ as "emacs@foo.bar" but changes a second or two later. /Jonas, who have to do it by hand by now - but that's what computers are for. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 12:34:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32492 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:34:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA32484 for ; Fri, 20 Nov 1998 12:33:58 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA16092; Fri, 20 Nov 98 12:33:36 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22396; Fri, 20 Nov 1998 09:33:28 -0800 (PST) To: perry@piermont.com Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201730.MAA00921@jekyll.piermont.com> From: Greg Badros Date: 20 Nov 1998 09:33:28 -0800 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 20 Nov 1998 12:30:44 -0500" Message-Id: Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > > > > They're numbered like so: > > > > 1 3 5 7 9 10 8 6 4 2 > > ^^^ leftmost buttons ^^^ rightmost > > Is there any reason we couldn't have a more logical numbering scheme > used? No reason, we just inherited this from fvwm2; the event-rewrite proposal addresses this somewhat, IIRC. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:36:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32563 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:36:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32559; Fri, 20 Nov 1998 12:36:16 -0500 Message-Id: <199811201736.MAA32559@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-reply-to: Your message of "20 Nov 1998 08:48:08 PST." Date: Fri, 20 Nov 1998 12:36:16 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Jonas Steverud writes: > > > In the infofile in bind-key it is spoken of CONTEXT and the possible > > context are: > > > > `window', `title', `icon', `root', `frame', `sidebar', `button-1', > > `button-2', `button-3', `button-4', `button-5', `button-6', > > `button-7', `button-8', `button-9', `button-10', `all' > > > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > They're numbered like so: > > 1 3 5 7 9 10 8 6 4 2 > ^^^ leftmost buttons ^^^ rightmost > > > > > > The reason is that I want to in my SCWMDoc to give the anatomy of a > > window (this is the frame, this is the titlebar as SCWM sees it...). > > This is a good goal, but I'd really like to make sure we're not > duplicating effort. The description is missing from our extracted > documentation, but the right place for this to go is in the source file > binding.c after: /**CONCEPT: Event Contexts > > Though it may be worth ultimately having a tutorial-like manual separate > from the reference documentation, I think our time now is better-spent > on the more-tightly-coupled documentation that is included in the source > code. Things in scwm are still changing pretty quickly, and keeping a > slew of side documentation in synch is a pain. > > I love that you're interested in improving the documentation, but > perhaps you could start sending in patches for the in-source DocBook > documentation instead of spending a lot of effort on something that will > more easily become obsolete. > I disagree, I think a tutorial is also very important. For those getting started it is more important, because once you know how to do basic things, figuring out complicated things is possible, even without very good docs, but a reference manual is not likely to be too helpful to someone getting started. While some aspects of scwm are likely to change radically, this is also likely to be a gradual process and one that will try to make sure to encompass ways of doing things similar to the old way, where this makes sense. > > > > /Jonas, who doesn't have time for this... He should be studying. > > Me too! :-) > I'm glad not to be in school any more... :) - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 12:38:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA32689 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:38:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA32686 for ; Fri, 20 Nov 1998 12:38:33 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA17716; Fri, 20 Nov 98 12:38:12 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA29715 for ; Fri, 20 Nov 1998 18:38:07 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id SAA08958; Fri, 20 Nov 1998 18:38:06 +0100 (MET) To: scwm-discuss@mit.edu Subject: start-on-desk X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 18:38:06 +0100 Message-Id: Lines: 27 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have (window-style "Netscape*" #:use-style js-common-window-style #:start-on-desk WS_WWW ; 6 ) When I start netscape it takes a couple of seconds which I use to work in some other program. Then when netscape starts SCWM automatically swicthes to this new desk but I don't want that. I want SCWM to swicth desks when I tell it so - not when netscape launches it's window. How do I tell SCWM to do as _I_ want? I often starts netscape to "use in the future". Just give me a push in the right direction - no long texts are needed (unless you wants too...). TIA. BTW: That "Netscape*", is it a regexp or a "filename match" like in sh(1)? -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 12:42:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00080 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:42:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00077 for ; Fri, 20 Nov 1998 12:42:39 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18947; Fri, 20 Nov 98 12:42:16 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22412; Fri, 20 Nov 1998 09:42:17 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201736.MAA32559@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 09:42:17 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 12:36:16 EST" Message-Id: Lines: 41 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > This is a good goal, but I'd really like to make sure we're not > > duplicating effort. The description is missing from our extracted > > documentation, but the right place for this to go is in the source file > > binding.c after: /**CONCEPT: Event Contexts > > > > Though it may be worth ultimately having a tutorial-like manual separate > > from the reference documentation, I think our time now is better-spent > > on the more-tightly-coupled documentation that is included in the source > > code. Things in scwm are still changing pretty quickly, and keeping a > > slew of side documentation in synch is a pain. > > > > I love that you're interested in improving the documentation, but > > perhaps you could start sending in patches for the in-source DocBook > > documentation instead of spending a lot of effort on something that will > > more easily become obsolete. > > > > I disagree, I think a tutorial is also very important. For those > getting started it is more important, because once you know how to do > basic things, figuring out complicated things is possible, even > without very good docs, but a reference manual is not likely to be too > helpful to someone getting started. While some aspects of scwm are > likely to change radically, this is also likely to be a gradual > process and one that will try to make sure to encompass ways of doing > things similar to the old way, where this makes sense. My point is that when our reference documentation is lacking, it's far more important to fix that then to put reference material in a tutorial-like document. The tutorial could reference the manual for further details to try to decouple them more (w/ hyperlinks the dynamic usability of the manual isn't hurt that much). (Hopefully) it's indisputable that the reference manual needs the information about event contexts. I'd like to see that get written first, so that people interested in creating more introdutory material have the answers to their questions in an up-to-date, maintained reference. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:42:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00089 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:42:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00086 for ; Fri, 20 Nov 1998 12:42:43 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA06680; Fri, 20 Nov 98 12:42:24 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA00983; Fri, 20 Nov 1998 12:42:14 -0500 (EST) Message-Id: <199811201742.MAA00983@jekyll.piermont.com> To: Greg Badros Cc: perry@piermont.com, Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "20 Nov 1998 09:33:28 PST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Nov 1998 12:42:14 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > > > They're numbered like so: > > > > > > 1 3 5 7 9 10 8 6 4 2 > > > ^^^ leftmost buttons ^^^ rightmost > > > > Is there any reason we couldn't have a more logical numbering scheme > > used? > > No reason, we just inherited this from fvwm2; the event-rewrite > proposal addresses this somewhat, IIRC. Given that the event rewrite is a ways off, could we add more logical alias names for these sooner? .pm From owner-scwm-discuss@mit.edu Fri Nov 20 12:43:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00138 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:43:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00130; Fri, 20 Nov 1998 12:43:29 -0500 Message-Id: <199811201743.MAA00130@vicarious-existence.mit.edu> To: perry@piermont.com cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-reply-to: Your message of "Fri, 20 Nov 1998 12:30:44 EST." <199811201730.MAA00921@jekyll.piermont.com> Date: Fri, 20 Nov 1998 12:43:29 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Greg Badros writes: > > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > > > > They're numbered like so: > > > > 1 3 5 7 9 10 8 6 4 2 > > ^^^ leftmost buttons ^^^ rightmost > > Is there any reason we couldn't have a more logical numbering scheme > used? > No reason we _couldn't_, the reason we don't is that no one has done it yet. Personally I would prefer to number left and right buttons separately. However, as things like right-button-1 are a bit verbose, how about button-l1 - button-l5 and button-r1 - button-r5? (I'd be glad to change this and maybe some of the goofier context names right after the release). - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 12:45:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00176 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:45:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00173 for ; Fri, 20 Nov 1998 12:45:41 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA07709; Fri, 20 Nov 98 12:45:22 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22416; Fri, 20 Nov 1998 09:45:11 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: From: Greg Badros Date: 20 Nov 1998 09:45:11 -0800 In-Reply-To: Jonas Steverud's message of "20 Nov 1998 18:33:09 +0100" Message-Id: Lines: 34 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > I've have it set up so that when I start Gnus in Emacs it sets the > title of the window (by setting the variabel frame-title-format) to > "Gnus group". When so is done I want that window moved to desk 5. > > (window-style "Gnus*" > #:use-style js-common-window-style > #:start-on-desk WS_News ; 5 > ) > > How is this archieved? > > The ideal would be some sort of title-has-changed-hook. > > Did anyone understand the question? > > Similar to the AutoOccupy in .ctwmrc. > > As I see it start-on-desk is never trigged since it is _started_ as > "emacs@foo.bar" but changes a second or two later. You should use window classes, not window titles, then start your emacs as: emacs -name Gnus -f gnus and then use Maciej's new class specification method for window-styles (he'll have to fill in the details -- I haven't looked at the rewrite, but I know I really wanted it!) The point is that the X class is more reliable than the window title, and you can specify it exactly when you start the process. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:46:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00190 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:46:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00186 for ; Fri, 20 Nov 1998 12:46:12 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA20095; Fri, 20 Nov 98 12:45:50 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA01302 for ; Fri, 20 Nov 1998 18:45:51 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id SAA09014; Fri, 20 Nov 1998 18:45:47 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201732.MAA32427@vicarious-existence.mit.edu> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 18:45:47 +0100 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 12:32:28 EST" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > d4jonas@dtek.chalmers.se writes: [...] > question though: what format is it written in? LaTeX. Thanks for the ascii-art. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 12:46:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00201 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:46:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00197 for ; Fri, 20 Nov 1998 12:46:48 -0500 Received: from [206.1.51.15] by MIT.EDU with SMTP id AA08151; Fri, 20 Nov 98 12:46:28 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id MAA01021; Fri, 20 Nov 1998 12:45:20 -0500 (EST) Message-Id: <199811201745.MAA01021@jekyll.piermont.com> To: Maciej Stachowiak Cc: perry@piermont.com, scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "Fri, 20 Nov 1998 12:43:29 EST." <199811201743.MAA00130@vicarious-existence.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 20 Nov 1998 12:45:20 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > No reason we _couldn't_, the reason we don't is that no one has done > it yet. Personally I would prefer to number left and right buttons > separately. However, as things like right-button-1 are a bit verbose, > how about button-l1 - button-l5 and button-r1 - button-r5? Sounds great! I assume we are numbering from the corner towards the center in both cases, right? Perry From owner-scwm-discuss@mit.edu Fri Nov 20 12:47:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00216 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:47:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00213 for ; Fri, 20 Nov 1998 12:47:21 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20666; Fri, 20 Nov 98 12:46:59 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22419; Fri, 20 Nov 1998 09:47:00 -0800 (PST) To: Maciej Stachowiak Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201732.MAA32427@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 09:47:00 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 12:32:28 EST" Message-Id: Lines: 36 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I am embarassed to admit I have not looked at your tutorial > documentation yet, although we would love to incorporate it. One > question though: what format is it written in? We are hoping to > standardize on DocBook as the doc format. It doesn't really matter at > this stage though - content is more important than markup. I tried to look at the .dvi file, but I was missing a *lot* of the fonts and it wouldn't display anything. > > A short description of it's anatomy would be great. > > > > To be used in > > (with-decor js-testdecor > > (title-style #:justify 'center) > > (button-style 6 ; !? > > #:relief 'flat > > #:pixmap "mini-ball.xpm") > > ) > > > > > > Here is an ascii-art of window anatomy (under a traditional fvwm-like > look): This should go in a (or whatever it is -- I've not written DocBook in months) section of the event contexts manual section in bindings.c. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:50:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00248 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:50:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00237 for ; Fri, 20 Nov 1998 12:50:15 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA21655; Fri, 20 Nov 98 12:49:53 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22430; Fri, 20 Nov 1998 09:49:52 -0800 (PST) To: perry@piermont.com Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201742.MAA00983@jekyll.piermont.com> From: Greg Badros Date: 20 Nov 1998 09:49:52 -0800 In-Reply-To: "Perry E. Metzger"'s message of "Fri, 20 Nov 1998 12:42:14 -0500" Message-Id: Lines: 52 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Perry E. Metzger" writes: > Greg Badros writes: > > > > They're numbered like so: > > > > > > > > 1 3 5 7 9 10 8 6 4 2 > > > > ^^^ leftmost buttons ^^^ rightmost > > > > > > Is there any reason we couldn't have a more logical numbering scheme > > > used? > > > > No reason, we just inherited this from fvwm2; the event-rewrite > > proposal addresses this somewhat, IIRC. > > Given that the event rewrite is a ways off, could we add more logical > alias names for these sooner? I've always seen it as a non-issue since I use the abstractions: ;; From gjb.scwmrc (define left-button-number 1) (define right-button-number 2) (define (add-left-button button-face hook) (set-button-face! left-button-number button-face) (bind-mouse (string->symbol (string-append "button-" (number->string left-button-number))) 1 hook) (set! left-button-number (+ 2 left-button-number))) (define (add-right-button button-face hook) (set-button-face! right-button-number button-face) (bind-mouse (string->symbol (string-append "button-" (number->string right-button-number))) 1 hook) (set! right-button-number (+ 2 right-button-number))) ;;and then do things like (add-left-button mini-icon-button-face popup-small-ops-or-close) ;; after define-ing mini-icon-button-face and popup-small-ops-or-close ;; of course This is more the level of abstraction I want when defining buttons. See how I use it to optionally add a close button (in my gjb.scwmrc file). Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:52:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00263 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:52:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00260 for ; Fri, 20 Nov 1998 12:52:18 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA10217; Fri, 20 Nov 98 12:51:59 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA02364 for ; Fri, 20 Nov 1998 18:51:55 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id SAA09032; Fri, 20 Nov 1998 18:51:54 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: Documentation (Was: Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 18:51:53 +0100 In-Reply-To: Greg Badros's message of "19 Nov 1998 08:49:58 -0800" Message-Id: Lines: 43 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk [This is a repost since the first one bounced.] Greg Badros writes: > Jonas Steverud writes: [...] > http://www.cs.washington.edu/homes/gjb/scwm-doc/ Didn't know about it. Just searched in doc/*. Looks nice so far. The "defined in ... at line..." are broken though. > > I will probably remove the list of functions (the main part as it is > > now) in the future. That is something that should be automatically > > generated (as already stated in the list). I should had said: "should be automatically generated and indexed and typset and ... in another file". > It is already... Therefor it is removed now and a new version is avaibale: Started on the decor-thingy but needs help on what goes where. What does the functions expect as it's arguments? (Tried to look thruogh *.scm but didn't get much wiser since they aren't documented/commented.) [...] > It'd be great for others (such as yourself) to pitch in and help with > the addition of more introductory material; accumulating a list of > things that you had to figure out how to do because the existing > documentation was insufficient would be a useful place to start. What issue do you think my scwmdoc.dvi tries to address? ;-) -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 12:55:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00339 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:55:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00319; Fri, 20 Nov 1998 12:55:21 -0500 Message-Id: <199811201755.MAA00319@vicarious-existence.mit.edu> To: Jonas Steverud cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-reply-to: Your message of "20 Nov 1998 18:22:56 +0100." Date: Fri, 20 Nov 1998 12:55:13 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk d4jonas@dtek.chalmers.se writes: > Greg Badros writes: > > > Jonas Steverud writes: > > > > > In the infofile in bind-key it is spoken of CONTEXT and the possible > > > context are: > > > > > > `window', `title', `icon', `root', `frame', `sidebar', `button-1', > > > `button-2', `button-3', `button-4', `button-5', `button-6', > > > `button-7', `button-8', `button-9', `button-10', `all' > > > > > > I've deduced what button-1,2 and 4 are but what are button-3,5-9? > > > > > > They're numbered like so: > > > > 1 3 5 7 9 10 8 6 4 2 > > ^^^ leftmost buttons ^^^ rightmost > > I thought so but my little experiment didn't add the buttons to the > titlebar. How do I get SCWM to add them? I looked in robbe.scwmrc but > it didn't help. > Scwm's method of determining button visibility is pretty goofy. It does the following: * If a button has a bound mouse action when the window is created (which is not merely an `all' action), it is visible when the window comes up. * But you can explicitly override this one way or another with style-commands like: ;; make button 6 visible on all windows (window-style "*" #:button 6) ;; make button 4 invisible on all emacs windows (window-style "emacs" #:no-button 4) All your recent comments have been a great way of figuring out what strange scwm behaviors are confusing, by the way. I am taking them under consideration and making plans to revise things. > The problem with helping you with the in-code docs is that I don't got > the foggiest what anything does. I have to ask you about what to write... > > If the general opintion is that we should concentrate on documenting > the code and making reference-manuals, just say so and I do a > "rm -rf ~/SCWM" and comes back in a couple of years. > > SCWMDoc is something I can do *now*, DocBook is something I have to > learn from the ground up by analysing the code for the next six month > - what is "DocBook" to start with? DocBook is an SGML Document Type Definition (DTD). It is a markup langauge vaguely (but only very vaguely) like HTML. Greg's remarks notwithstanding, I think any documentation work is to be encouraged. In particular, people should write the kinds of docs they feel most comfortable writing. > Or will how to make basic decors change from day to day? > ;-) > Not yet, but it will happen. :-) > /JS, how knows this sounds like a rant but he hopes noone feels > offended. If so: That was not the intention and I apologize. No, it's understandable, IMO. I hope you are not discouraged and will continue working on your scwm documentation. We can work out how to integrate it nicely with the rest of the docs later, for now it is wonderful to have something ready now for new users. Let me know when you feel your docs are ready enough to have a link to them from the scwm home page. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 12:56:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00369 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:56:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00360 for ; Fri, 20 Nov 1998 12:56:05 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA23739; Fri, 20 Nov 98 12:55:42 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA22443; Fri, 20 Nov 1998 09:55:40 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: Documentation (Was: Re: Red Hat ContribNet) References: <199811182347.SAA04019@huis-clos.mit.edu> From: Greg Badros Date: 20 Nov 1998 09:55:39 -0800 In-Reply-To: Jonas Steverud's message of "20 Nov 1998 18:51:53 +0100" Message-Id: Lines: 9 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > What issue do you think my scwmdoc.dvi tries to address? ;-) I can't tell because I lack the fonts... can you point at a pdf file (or postscript)? Thanks, Greg From owner-scwm-discuss@mit.edu Fri Nov 20 12:58:30 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00406 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:58:30 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA00403 for ; Fri, 20 Nov 1998 12:58:29 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA24511; Fri, 20 Nov 98 12:58:07 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id TAA17087; Fri, 20 Nov 1998 19:58:06 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Anon CVS needs a lock broken. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 19:58:06 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 12:43:29 EST" Message-Id: Lines: 40 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't been able to do an anoncvs checkout for the last 8 hrs because uid6159 has a lock in there. 8 hrs ago: hjstein@bacall:~/remote-cvs-pkgs/scwm$ cvs -z4 update -d ? foo.sgml ? scwm-0.7a.tar.gz ? new_scwm.sgml ? new_scwm_proclist.txt ? scwm.sgml ? scwm.txt ? scwm/new_scwm_procedures.txt cvs server: Updating . cvs server: [08:59:51] waiting for uid6159's lock in /anoncvs/scwm cvs server: [09:00:21] waiting for uid6159's lock in /anoncvs/scwm cvs server: [09:00:51] waiting for uid6159's lock in /anoncvs/scwm cvs server: [09:01:21] waiting for uid6159's lock in /anoncvs/scwm cvs server: [09:01:51] waiting for uid6159's lock in /anoncvs/scwm Now: hjstein@bacall:~/remote-cvs-pkgs/scwm$ cvs -z4 update -d ? foo.sgml ? scwm-0.7a.tar.gz ? new_scwm.sgml ? new_scwm_proclist.txt ? scwm.sgml ? scwm.txt ? scwm/new_scwm_procedures.txt cvs server: Updating . cvs server: [17:55:40] waiting for uid6159's lock in /anoncvs/scwm cvs server: [17:56:10] waiting for uid6159's lock in /anoncvs/scwm -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 12:59:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA00428 for scwm-discuss-outgoing; Fri, 20 Nov 1998 12:59:20 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from austin.cs.unc.edu (austin.cs.unc.edu [152.2.128.87]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id MAA00425 for ; Fri, 20 Nov 1998 12:59:19 -0500 Received: from rukbat.cs.unc.edu (rukbat.cs.unc.edu [152.2.133.170]) by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id MAA05822 for ; Fri, 20 Nov 1998 12:59:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by rukbat.cs.unc.edu (8.8.8/8.8.8) with SMTP id MAA13288 for ; Fri, 20 Nov 1998 12:59:00 -0500 (EST) Date: Fri, 20 Nov 1998 12:58:59 -0500 (EST) From: Stephen Tell To: SCWM Discussion List Subject: Subject: Re: docs: scwm-procedures.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk (trying again after a mail bounce) On Mon, 16 Nov 1998, Maciej Stachowiak wrote: [ Concerning scwmdoc.scm ] > Please make the changes then. I'll try to bring it up to date with the > perl version at some point if you don't have time first. This is > necessary anyway because we want to start using this stuff with Guile > at some point. It may be of interest that last week I picked up the whole scwm documentation system and dropped it into another project, including scwmdoc (perl version), guile-snarf, scwm-snarf, generate_scm_init_funcs, SCWM_PROC, etc. It was pretty much a no brainer to get a few new functions I was writing documented this way, so I packed up a patch and shipped it to the gEDA maintainers, who were interested in using it. It seems that SCM_PROC/guile-snarf aren't documented in any of the guile manuals or tutorials, so no wonder the gEDA folks project had been doing everything the hard way without even SCM_PROC(). The only real hangup was that scwmdoc (and scwmdoc.scm) have the with authors names and so on coded right in. Scwm.sgml is rather large already - is there any reason not to split it into multiple files? Scwmdoc.scm could then generate the chapters in seperate files, and a short handcrafted top-level document file could bind them all together along with any hand-written introductory or tutorial chapters that may get written. Catting fragments together into a big file would work, as would using the STML external entity stuff. I just figured this out and tested it with sgmltools on a tiny example. Sorry for the repetition if this is common knowledge, but I think the top-level scwm.sgml would become exactly this: ]> &bookinfo; &ProcAlphaChapter; &ProcByFileChapter; &HooksChapter; &VarsChapter; &ConceptsChapter; Then Bookinfo.sgml file contains " stuff ", and each chapter file contains everything starting from through inclusive. I could have a go at making the changes to the perl scwmdoc, but that would just be another thing to port to scwmdoc.scm. Changing the latter looks more daunting, since I'm not yet as scheme-literate as I am perl-literate. -- Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF Research Associate, Microelectronic Systems Laboratory Computer Science Department, UNC@Chapel Hill. W:919-962-1845 From owner-scwm-discuss@mit.edu Fri Nov 20 13:02:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00487 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:02:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00484 for ; Fri, 20 Nov 1998 13:02:05 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA13846; Fri, 20 Nov 98 13:01:40 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id TAA04281 for ; Fri, 20 Nov 1998 19:01:39 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id TAA09078; Fri, 20 Nov 1998 19:01:38 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201732.MAA32427@vicarious-existence.mit.edu> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 19:01:38 +0100 In-Reply-To: Greg Badros's message of "20 Nov 1998 09:47:00 -0800" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: [...] > I tried to look at the .dvi file, but I was missing a *lot* of the fonts > and it wouldn't display anything. !? I have't used any too fancy not-standard stuff. (\textXX are used but that's it...) Well: Better? -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 13:08:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00626 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:08:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id NAA00616 for ; Fri, 20 Nov 1998 13:07:58 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA15386 for scwm-discuss@huis-clos.mit.edu; Fri, 20 Nov 1998 18:57:18 +0100 (MET) Received: (qmail 11483 invoked by uid 115); 19 Nov 1998 14:52:09 -0000 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811162229.RAA03855@huis-clos.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 19 Nov 1998 15:52:06 +0100 In-Reply-To: hjstein@bfr.co.il's message of "19 Nov 1998 10:13:45 +0200" Message-ID: Lines: 19 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) X-Now-Playing: Endura - A Golden Heresy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 19 Nov 1998 10:13:45 +0200 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> What thread support does guile have? Only this internal Harvey> threading package, as far as I know. It's still possible for Harvey> a thread to get blocked in which case all threads get Harvey> blocked. It's not posix thread based. I'm not even sure Harvey> they're preemptive threads. They're not. Guile threads are viable only for applications where you (yield) very often. I don't think the doc-extractor is such an application. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Nov 20 13:08:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00629 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:08:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id NAA00621 for ; Fri, 20 Nov 1998 13:08:00 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id SAA15381 for scwm-discuss@huis-clos.mit.edu; Fri, 20 Nov 1998 18:57:15 +0100 (MET) Received: (qmail 11476 invoked by uid 115); 19 Nov 1998 14:51:56 -0000 To: scwm-discuss@mit.edu Subject: Re: Scheme documentation question. References: <199811182246.AAA32065@blinky.bfr.co.il> <199811182317.SAA03692@huis-clos.mit.edu> <13907.51876.764477.289664@chl> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Robert Bihlmeyer Date: 19 Nov 1998 15:51:53 +0100 In-Reply-To: Christian Lynbech's message of "Thu, 19 Nov 1998 08:37:08 +0100 (MET)" Message-ID: Lines: 37 User-Agent: Gnus/5.070048 (Pterodactyl Gnus v0.48) XEmacs/20.4 (Emerald) X-Now-Playing: Endura - A Golden Heresy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 19 Nov 1998 08:37:08 +0100 (MET) >>>>> Christian Lynbech said: >>> (define-public variable value optional-doc-string) >>> >>> Can't this be made to work? >>> Christian> Wouldn't this break if run with older versions of guile? No. The above form (with doc-string) throws an error in guile 1.3. As the doc-string is optional, code that has no doc-strings (legacy or not) will work as expected. Christian> Another strategy could be to do something like: Christian> (define-public variable value) "documentation" Christian> Guile won't mind the extra string, and now it would be Christian> visible to `read' (at a slight performance cost). You'd still have to do some magic. No, I don't think this is much better than the current solution (magic comments). Christian> (define-public variable value) '(doc-add variable Christian> "documentation") Doable, but since the Harvey's suggestion *is* backwards-compatible, I'd prefer that. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Nov 20 13:07:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00618 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:07:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00614 for ; Fri, 20 Nov 1998 13:07:58 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA15711; Fri, 20 Nov 98 13:07:39 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA22474; Fri, 20 Nov 1998 10:07:37 -0800 (PST) To: Maciej Stachowiak Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201755.MAA00319@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 10:07:37 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 12:55:13 EST" Message-Id: Lines: 88 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > I thought so but my little experiment didn't add the buttons to the > > titlebar. How do I get SCWM to add them? I looked in robbe.scwmrc but > > it didn't help. > > > > Scwm's method of determining button visibility is pretty goofy. It > does the following: > > * If a button has a bound mouse action when the window is created > (which is not merely an `all' action), it is visible when the window > comes up. > > * But you can explicitly override this one way or another with > style-commands like: > > ;; make button 6 visible on all windows > (window-style "*" #:button 6) > > ;; make button 4 invisible on all emacs windows > (window-style "emacs" #:no-button 4) > > > All your recent comments have been a great way of figuring out what > strange scwm behaviors are confusing, by the way. I am taking them > under consideration and making plans to revise things. This is why the higher-level "add-left-button" and "add-right-button" are less confusing (given the limitations as they exist now). > > The problem with helping you with the in-code docs is that I don't got > > the foggiest what anything does. I have to ask you about what to write... Right, and that's great because as Maciej points out, we lost touch w/ not understanding Scwm a while back, and need your (and other new converts') perspective desperately. But if there's not a good reference section to point you at, we need to *write* that reference section, and *then* point you at it. Or, we need somebody to take these email discussions and send patches in to the in-line source code as well. > > If the general opintion is that we should concentrate on documenting > > the code and making reference-manuals, just say so and I do a > > "rm -rf ~/SCWM" and comes back in a couple of years. > > > > SCWMDoc is something I can do *now*, DocBook is something I have to > > learn from the ground up by analysing the code for the next six month > > - what is "DocBook" to start with? > > DocBook is an SGML Document Type Definition (DTD). It is a markup > langauge vaguely (but only very vaguely) like HTML. Greg's remarks > notwithstanding, I think any documentation work is to be > encouraged. In particular, people should write the kinds of docs they > feel most comfortable writing. I didn't mean to sound as critical as I must have.... I just believe the reference docs are still the more important of the two kinds for now, and they still need some work... the work can go on in parallel, certainly, but I'd really love to see someone writing DocBook for the in-line documentation summarizing what we've discussed today. > > > Or will how to make basic decors change from day to day? > > ;-) > > > > Not yet, but it will happen. :-) > > > /JS, how knows this sounds like a rant but he hopes noone feels > > offended. If so: That was not the intention and I apologize. > > No, it's understandable, IMO. I hope you are not discouraged and will > continue working on your scwm documentation. We can work out how to > integrate it nicely with the rest of the docs later, for now it is > wonderful to have something ready now for new users. Please don't let my remarks discourage you-- that wasn't my intention-- I only am suggesting ways that what you are doing could be *even more* valuable. > Let me know when you feel your docs are ready enough to have a link to > them from the scwm home page. And please make postscript or pdf available. xdvi is not very useful when fonts are not well standardized (an unfortunate situation). Thanks! Greg From owner-scwm-discuss@mit.edu Fri Nov 20 13:09:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00673 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:09:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00670 for ; Fri, 20 Nov 1998 13:09:35 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA16270; Fri, 20 Nov 98 13:09:15 EST Received: (qmail 7085 invoked by uid 501); 20 Nov 1998 18:09:13 -0000 Message-Id: <19981120100913.A7014@molehill.org> Date: Fri, 20 Nov 1998 10:09:13 -0800 From: Todd Larason To: Greg Badros Cc: Jonas Steverud , scwm-discuss@mit.edu Subject: Re: Moving mouse with arrows and menues in netscape References: <19981120000137.A2901@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Nov 20, 1998 at 08:17:02AM -0800 X-Tom-Swifty: "You're busted!" said the policeman to Miss Parton. X-Kibo: Another dimension can teach us how to stay in our world. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981120, Greg Badros wrote: > I thought Jonas was talking about the netsape menu that a right click > brings up (not a Scwm menu)... I can't reproduce this... my pointer > movement keybindings work fine as long as I'm in the main event loop > (e.g., not a Scwm menu as you mention below). Ack, so he was. I read too quickly. Jonas, what version of Netscape are you using? Maybe it's version-dependant? Come to think of it, I've had times when Netscape menus seemed to 'lock up' my window manager. Maybe it's grabbing the server? -- ICQ UIN: 123782926 From owner-scwm-discuss@mit.edu Fri Nov 20 13:10:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00717 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:10:53 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00714 for ; Fri, 20 Nov 1998 13:10:52 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA28588; Fri, 20 Nov 98 13:10:31 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id TAA05395 for ; Fri, 20 Nov 1998 19:10:32 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id TAA09092; Fri, 20 Nov 1998 19:10:31 +0100 (MET) To: scwm-discuss@mit.edu Subject: Duplicates of posts X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 19:10:31 +0100 Message-Id: Lines: 17 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk When people replies to my posts I get one from the list and one Cc:ed. The latter is very annoying so could you please stop that? Thank you. :-) Or is there a reason? (I don't mind that much about the duplicates but you don't have to do it out of courtesy or whatever - I don't mind the lagtime for the list.) /Jonas, not schizofrenic :-) PS. Once again, I hope no one feels offended. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 13:11:30 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00754 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:11:30 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00749 for ; Fri, 20 Nov 1998 13:11:28 -0500 Received: from VICARIOUS-EXISTENCE.MIT.EDU by MIT.EDU with SMTP id AA16902; Fri, 20 Nov 98 13:11:09 EST Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00742; Fri, 20 Nov 1998 13:11:26 -0500 Message-Id: <199811201811.NAA00742@vicarious-existence.mit.edu> To: perry@piermont.com Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "Fri, 20 Nov 1998 12:45:20 EST." <199811201745.MAA01021@jekyll.piermont.com> Date: Fri, 20 Nov 1998 13:11:26 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk perry@piermont.com writes: > > Maciej Stachowiak writes: > > No reason we _couldn't_, the reason we don't is that no one has done > > it yet. Personally I would prefer to number left and right buttons > > separately. However, as things like right-button-1 are a bit verbose, > > how about button-l1 - button-l5 and button-r1 - button-r5? > > Sounds great! I assume we are numbering from the corner towards the > center in both cases, right? > Yes, I think that is most logical, and best admits of generalization to an arbitrary number of buttons. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 13:15:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00841 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:15:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00831; Fri, 20 Nov 1998 13:15:17 -0500 Message-Id: <199811201815.NAA00831@vicarious-existence.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Anon CVS needs a lock broken. In-reply-to: Your message of "20 Nov 1998 19:58:06 +0200." Date: Fri, 20 Nov 1998 13:15:17 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > I haven't been able to do an anoncvs checkout for the last 8 hrs > because uid6159 has a lock in there. > > 8 hrs ago: > > hjstein@bacall:~/remote-cvs-pkgs/scwm$ cvs -z4 update -d > ? foo.sgml > ? scwm-0.7a.tar.gz > ? new_scwm.sgml > ? new_scwm_proclist.txt > ? scwm.sgml > ? scwm.txt > ? scwm/new_scwm_procedures.txt > cvs server: Updating . > cvs server: [08:59:51] waiting for uid6159's lock in /anoncvs/scwm > cvs server: [09:00:21] waiting for uid6159's lock in /anoncvs/scwm > cvs server: [09:00:51] waiting for uid6159's lock in /anoncvs/scwm > cvs server: [09:01:21] waiting for uid6159's lock in /anoncvs/scwm > cvs server: [09:01:51] waiting for uid6159's lock in /anoncvs/scwm > > > Now: > > hjstein@bacall:~/remote-cvs-pkgs/scwm$ cvs -z4 update -d > ? foo.sgml > ? scwm-0.7a.tar.gz > ? new_scwm.sgml > ? new_scwm_proclist.txt > ? scwm.sgml > ? scwm.txt > ? scwm/new_scwm_procedures.txt > cvs server: Updating . > cvs server: [17:55:40] waiting for uid6159's lock in /anoncvs/scwm > cvs server: [17:56:10] waiting for uid6159's lock in /anoncvs/scwm > Should be fixed. I'll try to set up an automated way to avoid this problem in the future RSN. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 13:16:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00857 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:16:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00853 for ; Fri, 20 Nov 1998 13:16:09 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA00281; Fri, 20 Nov 98 13:15:41 EST Received: (qmail 7162 invoked by uid 501); 20 Nov 1998 18:15:43 -0000 Message-Id: <19981120101542.B7014@molehill.org> Date: Fri, 20 Nov 1998 10:15:42 -0800 From: Todd Larason To: scwm-discuss list Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201736.MAA32559@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811201736.MAA32559@vicarious-existence.mit.edu>; from Maciej Stachowiak on Fri, Nov 20, 1998 at 12:36:16PM -0500 X-Tom-Swifty: "I'm a lesbian", Mary mentioned. X-Kibo: Light is like the color ultramarine blue. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981120, Maciej Stachowiak wrote: > I'm glad not to be in school any more... :) Yeah, me too. Now we just have to keep from getting fired! =) -- ICQ UIN: 66884060 From owner-scwm-discuss@mit.edu Fri Nov 20 13:21:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00920 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:21:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA00917 for ; Fri, 20 Nov 1998 13:21:41 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA20460; Fri, 20 Nov 98 13:21:22 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id TAA06660 for ; Fri, 20 Nov 1998 19:21:21 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id TAA09142; Fri, 20 Nov 1998 19:21:20 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: Moving mouse with arrows and menues in netscape References: <19981120000137.A2901@molehill.org> <19981120100913.A7014@molehill.org> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 19:21:20 +0100 In-Reply-To: Todd Larason's message of "Fri, 20 Nov 1998 10:09:13 -0800" Message-Id: Lines: 22 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > Jonas, what version of Netscape are you using? Maybe it's version-dependant? $ netscape -version Netscape 4.5/Export, 13-Oct-98; (c) 1995-1998 Netscape Communications Corp. $ uname -a SunOS bort.dtek.chalmers.se 5.6 Generic_105181-08 sun4u sparc SUNW,Ultra-1 > Come to think of it, I've had times when Netscape menus seemed to 'lock up' my > window manager. Maybe it's grabbing the server? Nestcape is a all-time favorite for a bad-program-example so I might have done you a misfavour by using it in a bugreport... ;-) The interressting thing is that it was the same problem for show-window-list-menu too. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 13:22:35 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00931 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:22:35 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA00921; Fri, 20 Nov 1998 13:21:58 -0500 Message-Id: <199811201821.NAA00921@vicarious-existence.mit.edu> To: Stephen Tell cc: scwm-discuss@mit.edu Subject: Re: Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "Fri, 20 Nov 1998 12:58:59 EST." Date: Fri, 20 Nov 1998 13:21:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk tell@cs.unc.edu writes: > > (trying again after a mail bounce) > > On Mon, 16 Nov 1998, Maciej Stachowiak wrote: > > [ Concerning scwmdoc.scm ] > > > Please make the changes then. I'll try to bring it up to date with the > > perl version at some point if you don't have time first. This is > > necessary anyway because we want to start using this stuff with Guile > > at some point. > > It may be of interest that last week I picked up the whole scwm > documentation system and dropped it into another project, including > scwmdoc (perl version), guile-snarf, scwm-snarf, generate_scm_init_funcs, > SCWM_PROC, etc. It was pretty much a no brainer to get a few new > functions I was writing documented this way, so I packed up a patch and > shipped it to the gEDA maintainers, who were interested in using it. Excellent! A suitably adjusted version of scwdoc will probably go into Guile pretty soon. So this should become become even more convenient. > It seems that SCM_PROC/guile-snarf aren't documented in any of the > guile manuals or tutorials, so no wonder the gEDA folks project had > been doing everything the hard way without even SCM_PROC(). This is planned to be in the new manual already, but something interim is clearly needed. > > The only real hangup was that scwmdoc (and scwmdoc.scm) have the > with authors names and so on coded right in. Obviously the rational and necessary thing is to have that kind of info in an external template. I agree that something in the spirit of what you suggested below (DocBook external entities) is a good thing. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 13:29:06 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01008 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:29:06 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01000; Fri, 20 Nov 1998 13:29:02 -0500 Message-Id: <199811201829.NAA01000@vicarious-existence.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt In-reply-to: Your message of "19 Nov 1998 15:52:06 +0100." Date: Fri, 20 Nov 1998 13:29:02 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > Hi, > > >>>>> On 19 Nov 1998 10:13:45 +0200 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> What thread support does guile have? Only this internal > Harvey> threading package, as far as I know. It's still possible for > Harvey> a thread to get blocked in which case all threads get > Harvey> blocked. It's not posix thread based. I'm not even sure > Harvey> they're preemptive threads. > > They're not. Guile threads are viable only for applications where you > (yield) very often. I don't think the doc-extractor is such an application. > But they also implicitly yield at "evaluator ticks" and on blocking I/O, which should work fine for the purposes of the doc extractor. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 13:29:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01019 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:29:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01015 for ; Fri, 20 Nov 1998 13:29:19 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA22981; Fri, 20 Nov 98 13:28:59 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id TAA07655 for ; Fri, 20 Nov 1998 19:28:59 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id TAA09160; Fri, 20 Nov 1998 19:28:57 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201755.MAA00319@vicarious-existence.mit.edu> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 19:28:57 +0100 In-Reply-To: Greg Badros's message of "20 Nov 1998 10:07:37 -0800" Message-Id: Lines: 34 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: [...] > I didn't mean to sound as critical as I must have.... I just believe the > reference docs are still the more important of the two kinds for now, > and they still need some work... the work can go on in parallel, > certainly, but I'd really love to see someone writing DocBook for the > in-line documentation summarizing what we've discussed today. Correct. A good reference-manual would be GREAT! The problem is that I can't help you with it so I help where I can an that is helping newcommers like myself. You work on the ref.man. and I work on SCWMDoc, ok? :-) > > Let me know when you feel your docs are ready enough to have a link to > > them from the scwm home page. That will happen before x-mas, any x-mas. ;-) > And please make postscript or pdf available. xdvi is not very useful > when fonts are not well standardized (an unfortunate situation). It was a alpha, therefor the dvi. PS are avail. now. (GZip -9) (Don't like pdf since I don't use distiller --> no compression --> pdf.size 4-5 times ps.size. [uses ps2pdf when I have to]) -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 13:30:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01058 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:30:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01054 for ; Fri, 20 Nov 1998 13:30:23 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA05025; Fri, 20 Nov 98 13:30:00 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA19351; Fri, 20 Nov 1998 20:29:36 +0200 To: Stephen Tell Cc: SCWM Discussion List Subject: Re: Subject: Re: docs: scwm-procedures.txt References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 20:29:36 +0200 In-Reply-To: Stephen Tell's message of "Fri, 20 Nov 1998 12:58:59 -0500 (EST)" Message-Id: Lines: 166 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stephen Tell writes: > The only real hangup was that scwmdoc (and scwmdoc.scm) have the > with authors names and so on coded right in. Scwm.sgml is > rather large already - is there any reason not to split it into multiple > files? Scwmdoc.scm could then generate the chapters in seperate files, > and a short handcrafted top-level document file could bind them all > together along with any hand-written introductory or tutorial chapters > that may get written. Sorry about that. I've been planning on putting it in a separate file with cmd line specification, but... In any case, all you have to do is redefine the variable frontpiece: (define frontpiece `((bookinfo) ((title) ((productname) "SCWM Reference Manual")) ((authorgroup) ((author) ((firstname) "Maciej") ((surname) "Stachowiak") ((affiliation) ((shortaffil) "MIT") ((jobtitle) "M.S. Degree Recipient") ((orgname) "Massachusetts Institute of Technology") ((orgdiv) "Department of Computer Science") ((address) ((city) "Cambridge") ((state) "Massachusetts") ((postcode) "12345") ((country) "U.S.A.") ((email) "mstachow@mit.edu")))) ((author) ((firstname) "Greg") ((surname) "Badros") ((affiliation) ((shortaffil) "UWashington") ((jobtitle) "Graduate Research Assistant") ((orgname) "University of Washington") ((orgdiv) "Department of Computer Science and Engineering") ((address) ((city) "Seattle") ((state) "Washington") ((postcode) "98195") ((country) "U.S.A.") ((email) "gjb@cs.washington.edu"))))) ((releaseinfo) "Release pre-0.8") ((pubdate) "28 July 1998") ((copyright) ((year) "1997–1998") ((holder) "Maciej Stachowiak and Greg J. Badros")))) This is in what I call ssgml = Scheme SGML. It should be pretty clear how ssgml maps to sgml. It's just more convenient to work with it internally in this format (as you'd see if you look at the code). I'll add a --frontpiece option to the script to override the above definition. > Catting fragments together into a big file would work, as would using the > STML external entity stuff. I just figured this out and tested it with > sgmltools on a tiny example. Sorry for the repetition if this is common > knowledge, but I think the top-level scwm.sgml would become exactly this: > > > > > > > > ]> > > &bookinfo; > &ProcAlphaChapter; > &ProcByFileChapter; > &HooksChapter; > &VarsChapter; > &ConceptsChapter; > > I suppose it'd be more convenient. It'd be pretty trivial to hack scwmdoc.scm.in for this. (extract-docs-from-files f1 f2 ...) returns a list containing the embedded documentation from the specified files. The sgml output is generated by: (define (docs->sgml frontpiece docs) (display "\n") (sgml (docs->ssgml frontpiece docs) "")) docs->ssgml does the generation of the sgml, but in a scheme list friendly fashion (as in the above frontpiece definition), and the sgml fcn outputs that in actual sgml. So, docs->ssgml looks like: (define (docs->ssgml frontpiece docs) (let ((procs (sort (select-type 'SCWM_PROC docs) scheme-name-ciprimitives-chapter procs) ,(proclist->file-chapter procs) ,@(emblist->ssgml embdocs)))) To do what you want, all you have to do is: (let ((docs (extract-docs-from-files f1 f2 ...))) (with-output-to-file "primitives.sgml" (lambda () (sgml (proclist->primitives-chapter docs)))) (with-output-to-file "primitives-by-file.sgml" (lambda () (sgml (proclist->file-chapter docs)))) (emblist->ssgml-separate-files docs)) One tricky part is that I don't have a predefined set of chapters for the embedded docs (hooks, vars, etc.) I just create whatever I read. So the top level file will also have to be generated based on the topics found. As for the output into separate files, you'll have to do rewrite emblist->ssgml, changing it from this: (define (emblist->ssgml docs) (let ((docs (group (sort docs (lexcmp (list (list (lambda (x) (doc:chapter (docitem:data x))) string-cissgml docs))) to: (define (emblist->ssgml-separate-files docs) (let ((docs (group (sort docs (lexcmp (list (list (lambda (x) (doc:chapter (docitem:data x))) string-cissgml chapter-docs)))) docs))) I guess the thing to *really* do is give a --load option which would just load whatever scheme code you specify, thus allowing you to do arbitrary customizations of the code without bothering with cut & paste. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 13:32:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01163 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:32:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01160 for ; Fri, 20 Nov 1998 13:32:40 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA05686; Fri, 20 Nov 98 13:32:11 EST Received: (qmail 7282 invoked by uid 501); 20 Nov 1998 18:32:12 -0000 Message-Id: <19981120103212.C7014@molehill.org> Date: Fri, 20 Nov 1998 10:32:12 -0800 From: Todd Larason To: Greg Badros , Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Nov 20, 1998 at 09:45:11AM -0800 X-Tom-Swifty: "That laser beam sure took care of MIT!" the mad scientist cackled in Zapotec. X-Kibo: If many flowers could shine, would the Universe, U for Underwhelming, be new? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981120, Greg Badros wrote: > You should use window classes, not window titles, then start your emacs as: > > emacs -name Gnus -f gnus ick! And have more than one emacs running? Couldn't this be done with a hook on X-PropertyNotify-hook? Something like: (add-hook! X-PropertyNotify-hook move-gnus-window) (define (move-gnus-window propname window) (cond ((and () (string=? proprname "WM_NAME") (string=? (X-property-get window "WM_NAME") "Gnus")) ()))) ? There are a few items, marked with <>, I don't know how to do offhand. -- ICQ UIN: 123351674 From owner-scwm-discuss@mit.edu Fri Nov 20 13:38:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01377 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:38:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01374 for ; Fri, 20 Nov 1998 13:38:14 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA25976; Fri, 20 Nov 98 13:37:54 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA22712; Fri, 20 Nov 1998 10:37:50 -0800 (PST) To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <19981120103212.C7014@molehill.org> From: Greg Badros Date: 20 Nov 1998 10:37:50 -0800 In-Reply-To: Todd Larason's message of "Fri, 20 Nov 1998 10:32:12 -0800" Message-Id: Lines: 32 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981120, Greg Badros wrote: > > You should use window classes, not window titles, then start your emacs as: > > > > emacs -name Gnus -f gnus > > ick! And have more than one emacs running? Hell yes... until Emacs is multi-threaded, having multiple makes sense (esp. when one is basically just running gnus as a mail reader) > Couldn't this be done with a hook on X-PropertyNotify-hook? > > Something like: > > (add-hook! X-PropertyNotify-hook move-gnus-window) > (define (move-gnus-window propname window) > (cond ((and () > (string=? proprname "WM_NAME") > (string=? (X-property-get window "WM_NAME") "Gnus")) > ()))) > ? > There are a few items, marked with <>, I don't know how to do offhand. I'm not sure what you're going for here. Once you use the window class instead of just the title, you can reliably tell that it's emacs. I doubt one would want the window to move when "gnus" starts up... that'd be confusing as heck. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 13:43:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01441 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:43:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01438 for ; Fri, 20 Nov 1998 13:43:14 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA09154; Fri, 20 Nov 98 13:42:47 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id TAA09879 for ; Fri, 20 Nov 1998 19:42:47 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id TAA09215; Fri, 20 Nov 1998 19:42:46 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <19981120103212.C7014@molehill.org> X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 20 Nov 1998 19:42:46 +0100 In-Reply-To: Todd Larason's message of "Fri, 20 Nov 1998 10:32:12 -0800" Message-Id: Lines: 23 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981120, Greg Badros wrote: > > You should use window classes, not window titles, then start your emacs as: > > > > emacs -name Gnus -f gnus > > ick! And have more than one emacs running? Although I do think like you I have to use the MSBK for MULE so an Emacs or two I'll bring to you. % kill -9 persons-that-invented-MULE /Jonas, hates to use two Emacsen but has to. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Nov 20 13:51:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01529 for scwm-discuss-outgoing; Fri, 20 Nov 1998 13:51:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01526 for ; Fri, 20 Nov 1998 13:51:33 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA00682; Fri, 20 Nov 98 13:51:11 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id UAA19475; Fri, 20 Nov 1998 20:51:02 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Anon CVS needs a lock broken. References: <199811201815.NAA00831@vicarious-existence.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 20:51:02 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 13:15:17 EST" Message-Id: Lines: 38 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > > > I haven't been able to do an anoncvs checkout for the last 8 hrs > > because uid6159 has a lock in there. > > Should be fixed. I'll try to set up an automated way to avoid this > problem in the future RSN. You should check *all* directories for locks: hjstein@bacall:~/remote-cvs-pkgs/scwm$ cvs -z4 update -d ? foo.sgml ? scwm-0.7a.tar.gz ? new_scwm.sgml ? new_scwm_proclist.txt ? scwm.sgml ? scwm.txt ? scwm/new_scwm_procedures.txt cvs server: Updating . P ChangeLog P README P autogen.sh P configure.in U gtk.m4 cvs server: Updating .##cvs.lock cvs server: Updating app cvs server: [18:48:44] waiting for uid6159's lock in /anoncvs/scwm/app cvs server: [18:49:14] waiting for uid6159's lock in /anoncvs/scwm/app cvs server: [18:49:44] waiting for uid6159's lock in /anoncvs/scwm/app cvs server: [18:50:14] waiting for uid6159's lock in /anoncvs/scwm/app cvs server: [18:50:44] waiting for uid6159's lock in /anoncvs/scwm/app -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 14:02:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01711 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:02:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA01706 for ; Fri, 20 Nov 1998 14:02:05 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15368; Fri, 20 Nov 98 14:01:37 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id VAA20416; Fri, 20 Nov 1998 21:00:56 +0200 Date: Fri, 20 Nov 1998 21:00:56 +0200 Message-Id: <199811201900.VAA20416@blinky.bfr.co.il> From: "Harvey J. Stein" To: Maciej Stachowiak Subject: make bug in doc directory - makeinfo fails on scwm.texi Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have the following make failure: Making all in doc make[1]: Entering directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' cd . \ && makeinfo `echo scwm.texi | sed 's,.*/,,'` Making info file `scwm.info' from `scwm.texi'. scwm.texi:5: Unknown info command `dircategory'. scwm.texi:6: Unknown info command `direntry'. scwm.texi:8: Unmatched `@end'. make[1]: *** [scwm.info] Error 2 make[1]: Leaving directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' make: *** [all-recursive] Error 1 What version of makeinfo do you require? I have: hjstein@blinky:~/remote-cvs-pkgs/scwm$ makeinfo --version This is GNU Makeinfo version 1.64, from texinfo-3.7. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 14:13:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01909 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:13:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01899; Fri, 20 Nov 1998 14:13:21 -0500 Message-Id: <199811201913.OAA01899@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. In-reply-to: Your message of "20 Nov 1998 10:37:50 PST." Date: Fri, 20 Nov 1998 14:13:11 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Todd Larason writes: > > > On 981120, Greg Badros wrote: > > > You should use window classes, not window titles, then start your emacs as: > > > > > > emacs -name Gnus -f gnus > > > > ick! And have more than one emacs running? > > Hell yes... until Emacs is multi-threaded, having multiple makes sense > (esp. when one is basically just running gnus as a mail reader) > > > > Couldn't this be done with a hook on X-PropertyNotify-hook? > > > > Something like: > > > > (add-hook! X-PropertyNotify-hook move-gnus-window) > > (define (move-gnus-window propname window) > > (cond ((and () > > (string=? proprname "WM_NAME") > > (string=? (X-property-get window "WM_NAME") "Gnus")) > > ()))) > > ? > > There are a few items, marked with <>, I don't know how to do offhand. > (define (move-gnus-window propname window) (cond ((and ((class-match?? "emacs") window) (string=? proprname "WM_NAME") (string=? (X-property-get window "WM_NAME") "Gnus")) (move-window-to-desk [...desk number...] window)))) (add-hook! X-PropertyNotify-hook move-gnus-window) But I am not sure this will work because I think scwm's X-PropertyNotify-hook will eat notification about properties that scwm processes itself (I need to check the code). > I'm not sure what you're going for here. Once you use the window class > instead of just the title, you can reliably tell that it's emacs. I > doubt one would want the window to move when "gnus" starts up... that'd > be confusing as heck. > I suspect Todd is thinking of starting Gnus in another emacs frame and making it switch desks automagically then. Can emacs be made to set the resource name of an individual window? Anyway, even if moving windows to different desks based on the title is not always the best solution, it should still be _possible_. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 14:18:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02095 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:18:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02088; Fri, 20 Nov 1998 14:18:25 -0500 Message-Id: <199811201918.OAA02088@vicarious-existence.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: Anon CVS needs a lock broken. In-reply-to: Your message of "20 Nov 1998 20:51:02 +0200." Date: Fri, 20 Nov 1998 14:18:25 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > hjstein@bfr.co.il writes: > > > > > > I haven't been able to do an anoncvs checkout for the last 8 hrs > > > because uid6159 has a lock in there. > > > > Should be fixed. I'll try to set up an automated way to avoid this > > problem in the future RSN. > > You should check *all* directories for locks: > Sorry, now fixed. :-/ - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 14:21:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02211 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:21:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02197; Fri, 20 Nov 1998 14:21:34 -0500 Message-Id: <199811201921.OAA02197@vicarious-existence.mit.edu> To: "Harvey J. Stein" cc: scwm-discuss@mit.edu Subject: Re: make bug in doc directory - makeinfo fails on scwm.texi In-reply-to: Your message of "Fri, 20 Nov 1998 21:00:56 +0200." <199811201900.VAA20416@blinky.bfr.co.il> Date: Fri, 20 Nov 1998 14:21:34 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > I have the following make failure: > > Making all in doc > make[1]: Entering directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' > cd . \ > && makeinfo `echo scwm.texi | sed 's,.*/,,'` > Making info file `scwm.info' from `scwm.texi'. > scwm.texi:5: Unknown info command `dircategory'. > scwm.texi:6: Unknown info command `direntry'. > scwm.texi:8: Unmatched `@end'. > make[1]: *** [scwm.info] Error 2 > make[1]: Leaving directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' > make: *** [all-recursive] Error 1 > > What version of makeinfo do you require? I have: > > hjstein@blinky:~/remote-cvs-pkgs/scwm$ makeinfo --version > This is GNU Makeinfo version 1.64, from texinfo-3.7. > I have: [mstachow@huis-clos] scwm > makeinfo --version GNU Makeinfo (Texinfo 3.9) 1.67 Copyright (C) 1996 Free Software Foundation, Inc. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License. For more information about these matters, see the files named COPYING. I am not sure this is required, but it should probably be documented somewhere in HACKING. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 14:25:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02399 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:25:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA02396 for ; Fri, 20 Nov 1998 14:25:42 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA22992; Fri, 20 Nov 98 14:25:19 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA22860; Fri, 20 Nov 1998 11:25:14 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <199811201913.OAA01899@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 11:25:14 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 14:13:11 EST" Message-Id: Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I suspect Todd is thinking of starting Gnus in another emacs frame and > making it switch desks automagically then. Can emacs be made to set > the resource name of an individual window? Not after creation, I think. Perhaps it can be set using set-frame-property in the emacs create-frame-hook. > Anyway, even if moving windows to different desks based on the title > is not always the best solution, it should still be _possible_. Of course... definitely, but in general for customizations of a class of windows it's more reliable to use -name than to use just the window title. (My window titles change a lot -- e.g., to include the filename for emacs windows, or to show the name of the last long-running command in xterm windows running zsh). Greg From owner-scwm-discuss@mit.edu Fri Nov 20 14:29:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02493 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:29:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02488; Fri, 20 Nov 1998 14:29:01 -0500 Message-Id: <199811201929.OAA02488@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. In-reply-to: Your message of "20 Nov 1998 11:25:14 PST." Date: Fri, 20 Nov 1998 14:29:01 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > I suspect Todd is thinking of starting Gnus in another emacs frame and > > making it switch desks automagically then. Can emacs be made to set > > the resource name of an individual window? > > Not after creation, I think. Perhaps it can be set using > set-frame-property in the emacs create-frame-hook. > > > Anyway, even if moving windows to different desks based on the title > > is not always the best solution, it should still be _possible_. > > Of course... definitely, but in general for customizations of a class of > windows it's more reliable to use -name than to use just the window > title. (My window titles change a lot -- e.g., to include the filename > for emacs windows, or to show the name of the last long-running command > in xterm windows running zsh). > True, but using -name can be annoying, and is not always even supported. For instance, I am not sure gtk-based apps have an equivalent. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 14:29:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02509 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:29:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA02506 for ; Fri, 20 Nov 1998 14:29:26 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14056; Fri, 20 Nov 98 14:29:05 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id VAA21530; Fri, 20 Nov 1998 21:29:03 +0200 Date: Fri, 20 Nov 1998 21:29:03 +0200 Message-Id: <199811201929.VAA21530@blinky.bfr.co.il> From: "Harvey J. Stein" To: Maciej Stachowiak Subject: Trivial makefile patch. Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's a tiny patch for doc/Makefile.am I fixed the documentation to match the new script name & added scwm-variables.txt as a dependency (since it's getting generated). It looks like scheme/user-options.scm should also be in the dependency list, but I thought it strange that the file name is a relative path but not a subdirectory, whereas the other output args are full path names. The make rule kicks around the source tree quite a bit, so it's not completely clear to me how to make scheme/user-options.scm a dependency. I'd check it in myself except that a) I thought you'd want to look at it first, b) I don't want to muck with files I don't "own", and c) I might be wrong. RCS file: /usr/local/repository/scwm/doc/Makefile.am,v retrieving revision 1.18 diff -C4 -r1.18 Makefile.am *** Makefile.am 1998/11/16 22:20:01 1.18 --- Makefile.am 1998/11/20 19:06:18 *************** *** 6,15 **** pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm.sgml EXTRA_DIST=scwm-faq scwm-intro-tutorial.scm session-management smproxy.patch \ theme-howto scwm.1 scwmexec.1 scwmrepl.1 $(pkgdata_DATA) ! # Use extract-docs to build the documentation files ! scwm.sgml scwm-procedures.txt: $(scwm_SOURCES) abs_builddir_doc=`pwd`; \ outdir=$$abs_builddir_doc; \ echo Outputting to directory: $$outdir; \ cd $(top_builddir); abs_top_builddir=`pwd`; \ --- 6,15 ---- pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm.sgml EXTRA_DIST=scwm-faq scwm-intro-tutorial.scm session-management smproxy.patch \ theme-howto scwm.1 scwmexec.1 scwmrepl.1 $(pkgdata_DATA) ! # Use scmdocs to build the documentation files ! scwm.sgml scwm-procedures.txt scwm-variables.txt: $(scwm_SOURCES) abs_builddir_doc=`pwd`; \ outdir=$$abs_builddir_doc; \ echo Outputting to directory: $$outdir; \ cd $(top_builddir); abs_top_builddir=`pwd`; \ -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 14:33:26 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02644 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:33:26 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA02640 for ; Fri, 20 Nov 1998 14:33:25 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AB15482; Fri, 20 Nov 98 14:33:04 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id VAA21609; Fri, 20 Nov 1998 21:33:02 +0200 To: Maciej Stachowiak Cc: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: make bug in doc directory - makeinfo fails on scwm.texi References: <199811201921.OAA02197@vicarious-existence.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 21:33:02 +0200 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 14:21:34 EST" Message-Id: Lines: 46 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > hjstein@bfr.co.il writes: > > > > I have the following make failure: > > > > Making all in doc > > make[1]: Entering directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' > > cd . \ > > && makeinfo `echo scwm.texi | sed 's,.*/,,'` > > Making info file `scwm.info' from `scwm.texi'. > > scwm.texi:5: Unknown info command `dircategory'. > > scwm.texi:6: Unknown info command `direntry'. > > scwm.texi:8: Unmatched `@end'. > > make[1]: *** [scwm.info] Error 2 > > make[1]: Leaving directory `/home/hjstein/remote-cvs-pkgs/scwm/doc' > > make: *** [all-recursive] Error 1 > > > > What version of makeinfo do you require? I have: > > > > hjstein@blinky:~/remote-cvs-pkgs/scwm$ makeinfo --version > > This is GNU Makeinfo version 1.64, from texinfo-3.7. > > > > I have: > > [mstachow@huis-clos] scwm > makeinfo --version > GNU Makeinfo (Texinfo 3.9) 1.67 > Copyright (C) 1996 Free Software Foundation, Inc. > There is NO warranty. You may redistribute this software > under the terms of the GNU General Public License. > For more information about these matters, see the files named COPYING. > > I am not sure this is required, but it should probably be documented > somewhere in HACKING. Doing make again after the failure finishes things up, except for what's probably a hosed scwm.info. I guess there's also a (rather convenient) make dependency or rule bug allowing this, but in any case I guess you can document that 1.67 works, and that 1.64 fails but you can run make again to finish things off. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 14:37:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02796 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:37:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA02782; Fri, 20 Nov 1998 14:37:00 -0500 Message-Id: <199811201937.OAA02782@vicarious-existence.mit.edu> To: "Harvey J. Stein" cc: scwm-discuss@mit.edu Subject: Re: Trivial makefile patch. In-reply-to: Your message of "Fri, 20 Nov 1998 21:29:03 +0200." <199811201929.VAA21530@blinky.bfr.co.il> Date: Fri, 20 Nov 1998 14:37:00 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > > Here's a tiny patch for doc/Makefile.am I fixed the documentation to > match the new script name & added scwm-variables.txt as a dependency > (since it's getting generated). It looks like scheme/user-options.scm > should also be in the dependency list, but I thought it strange that > the file name is a relative path but not a subdirectory, whereas the > other output args are full path names. The make rule kicks around > the source tree quite a bit, so it's not completely clear to me how to > make scheme/user-options.scm a dependency. > I'm not sure iether, but this can be examined later. > I'd check it in myself except that a) I thought you'd want to look at > it first, b) I don't want to muck with files I don't "own", and c) I > might be wrong. > The doc fix is obviously correct. The dependency fix is correct in the long term, but unfortunately scwm_SOURCES is not actually defined in the context of that Makefile.am so it doesn't make much difference for now. (Eventually we will have to duplicate scwm_SOURCES - ugh! - or find some clever hack). Anyway, feel free to apply this patch, else I will do so later tonight or this weekend. - Maciej > RCS file: /usr/local/repository/scwm/doc/Makefile.am,v > retrieving revision 1.18 > diff -C4 -r1.18 Makefile.am > *** Makefile.am 1998/11/16 22:20:01 1.18 > --- Makefile.am 1998/11/20 19:06:18 > *************** > *** 6,15 **** > pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm.sgml > EXTRA_DIST=scwm-faq scwm-intro-tutorial.scm session-management smproxy.patch \ > theme-howto scwm.1 scwmexec.1 scwmrepl.1 $(pkgdata_DATA) > > ! # Use extract-docs to build the documentation files > ! scwm.sgml scwm-procedures.txt: $(scwm_SOURCES) > abs_builddir_doc=`pwd`; \ > outdir=$$abs_builddir_doc; \ > echo Outputting to directory: $$outdir; \ > cd $(top_builddir); abs_top_builddir=`pwd`; \ > --- 6,15 ---- > pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm.sgml > EXTRA_DIST=scwm-faq scwm-intro-tutorial.scm session-management smproxy.patch \ > theme-howto scwm.1 scwmexec.1 scwmrepl.1 $(pkgdata_DATA) > > ! # Use scmdocs to build the documentation files > ! scwm.sgml scwm-procedures.txt scwm-variables.txt: $(scwm_SOURCES) > abs_builddir_doc=`pwd`; \ > outdir=$$abs_builddir_doc; \ > echo Outputting to directory: $$outdir; \ > cd $(top_builddir); abs_top_builddir=`pwd`; \ > From owner-scwm-discuss@mit.edu Fri Nov 20 14:46:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA03032 for scwm-discuss-outgoing; Fri, 20 Nov 1998 14:46:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA03028 for ; Fri, 20 Nov 1998 14:46:04 -0500 Received: from smtp2.dti.ne.jp by MIT.EDU with SMTP id AA29781; Fri, 20 Nov 98 14:45:33 EST Received: from 192.168.1.1 (PPP22.tokyo-ap4.dti.ne.jp [210.170.145.114]) by smtp2.dti.ne.jp (8.9.0/3.7W) with ESMTP id EAA15235 for ; Sat, 21 Nov 1998 04:45:19 +0900 (JST) Received: by 192.168.1.1 (8.8.8/3.6W-ppp) id EAA21754; Sat, 21 Nov 1998 04:45:08 +0900 Message-Id: <199811201945.EAA21754@192.168.1.1> To: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <19981120103212.C7014@molehill.org> X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN) Mime-Version: 1.0 (generated by SEMI 1.8.4 - "Takaoka") Content-Type: text/plain; charset=US-ASCII From: ITANI Eiichiro Date: 21 Nov 1998 04:45:04 +0900 In-Reply-To: Jonas Steverud's message of "20 Nov 1998 19:42:46 +0100" Lines: 9 X-Mailer: Semi-gnus 6.8.14 (based on Gnus 5.6.38; for SEMI 1.8, FLIM 1.8/1.9) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > % kill -9 persons-that-invented-MULE But I can't live without MULE ;) MULE makes my life better... -- Eiichiro ITANI -- one of mule user :) From owner-scwm-discuss@mit.edu Fri Nov 20 15:19:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA03384 for scwm-discuss-outgoing; Fri, 20 Nov 1998 15:19:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA03378 for ; Fri, 20 Nov 1998 15:19:00 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA01409; Fri, 20 Nov 98 15:18:39 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA22978; Fri, 20 Nov 1998 12:18:35 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <199811201929.OAA02488@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 12:18:35 -0800 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 14:29:01 EST" Message-Id: Lines: 9 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > True, but using -name can be annoying, and is not always even > supported. For instance, I am not sure gtk-based apps have an > equivalent. Then that is a bug, and *needs* fixing! Greg From owner-scwm-discuss@mit.edu Fri Nov 20 15:19:45 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA03395 for scwm-discuss-outgoing; Fri, 20 Nov 1998 15:19:45 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA03392 for ; Fri, 20 Nov 1998 15:19:45 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA01641; Fri, 20 Nov 98 15:19:19 EST Received: (qmail 8077 invoked by uid 501); 20 Nov 1998 20:19:19 -0000 Message-Id: <19981120121919.A8008@molehill.org> Date: Fri, 20 Nov 1998 12:19:19 -0800 From: Todd Larason To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <19981120103212.C7014@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Greg Badros on Fri, Nov 20, 1998 at 10:37:50AM -0800 X-Tom-Swifty: "It's $3 to cross the bridge, sir", Tom told him. X-Kibo: Life is not life itself, I witness! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981120, Greg Badros wrote: > I'm not sure what you're going for here. Once you use the window class > instead of just the title, you can reliably tell that it's emacs. I > doubt one would want the window to move when "gnus" starts up... that'd > be confusing as heck. It doesn't seem like something I'd want either, but that's how I read what Jonas is asking for. And it *ought* to be possible, whether it's a good idea or not. It doesn't seem too unreasonable if gnus is always run in a new frame. -- ICQ UIN: 121151682 From owner-scwm-discuss@mit.edu Fri Nov 20 15:20:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA03409 for scwm-discuss-outgoing; Fri, 20 Nov 1998 15:20:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA03406 for ; Fri, 20 Nov 1998 15:20:14 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11727; Fri, 20 Nov 98 15:19:46 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA23038; Fri, 20 Nov 1998 12:19:40 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: Maciej Stachowiak , scwm-discuss@mit.edu, hjstein@bfr.co.il Subject: Re: make bug in doc directory - makeinfo fails on scwm.texi References: <199811201921.OAA02197@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 12:19:40 -0800 In-Reply-To: hjstein@bfr.co.il's message of "20 Nov 1998 21:33:02 +0200" Message-Id: Lines: 12 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Doing make again after the failure finishes things up, except for > what's probably a hosed scwm.info. I guess there's also a (rather > convenient) make dependency or rule bug allowing this, but in any case > I guess you can document that 1.67 works, and that 1.64 fails but you > can run make again to finish things off. You can use 'make -k' to keep going upon encountering errors. Just ensure that you don't let a failed target sneak through w/o noticing. Greg From owner-scwm-discuss@mit.edu Fri Nov 20 15:25:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA03442 for scwm-discuss-outgoing; Fri, 20 Nov 1998 15:25:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA03436 for ; Fri, 20 Nov 1998 15:25:07 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA03391; Fri, 20 Nov 98 15:24:41 EST Received: (qmail 8135 invoked by uid 501); 20 Nov 1998 20:24:41 -0000 Message-Id: <19981120122441.B8008@molehill.org> Date: Fri, 20 Nov 1998 12:24:41 -0800 From: Todd Larason To: Maciej Stachowiak , "Harvey J. Stein" Cc: scwm-discuss@mit.edu Subject: Re: make bug in doc directory - makeinfo fails on scwm.texi References: <199811201900.VAA20416@blinky.bfr.co.il> <199811201921.OAA02197@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811201921.OAA02197@vicarious-existence.mit.edu>; from Maciej Stachowiak on Fri, Nov 20, 1998 at 02:21:34PM -0500 X-Tom-Swifty: "What's the weather like?" the farmer questioned vainly. X-Kibo: Allowedness seems ubiquitous to me! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981120, Maciej Stachowiak wrote: > > hjstein@bfr.co.il writes: > > > > I have the following make failure: > > > > scwm.texi:5: Unknown info command `dircategory'. > > scwm.texi:6: Unknown info command `direntry'. > > scwm.texi:8: Unmatched `@end'. > > What version of makeinfo do you require? I have: > > > > hjstein@blinky:~/remote-cvs-pkgs/scwm$ makeinfo --version > > This is GNU Makeinfo version 1.64, from texinfo-3.7. > > [mstachow@huis-clos] scwm > makeinfo --version > GNU Makeinfo (Texinfo 3.9) 1.67 If there are a lot of people using versions of Makeinfo without dircategory and direntry support, those lines could just be removed. I added them to make install-info happy. Install-info is a partial automated solution for the longstanding info problem where the dir doesn't get updated when info files are installed. RedHat 5.0+ and Debian 2.0 both have and use it. -- ICQ UIN: 99712236 From owner-scwm-discuss@mit.edu Fri Nov 20 15:25:17 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA03439 for scwm-discuss-outgoing; Fri, 20 Nov 1998 15:25:17 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA03434 for ; Fri, 20 Nov 1998 15:25:01 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03360; Fri, 20 Nov 98 15:24:34 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id WAA21955; Fri, 20 Nov 1998 22:24:11 +0200 To: Greg Badros Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: make bug in doc directory - makeinfo fails on scwm.texi References: <199811201921.OAA02197@vicarious-existence.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 22:24:11 +0200 In-Reply-To: Greg Badros's message of "20 Nov 1998 12:19:40 -0800" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Doing make again after the failure finishes things up, except for > > what's probably a hosed scwm.info. I guess there's also a (rather > > convenient) make dependency or rule bug allowing this, but in any case > > I guess you can document that 1.67 works, and that 1.64 fails but you > > can run make again to finish things off. > > You can use 'make -k' to keep going upon encountering errors. Just > ensure that you don't let a failed target sneak through w/o noticing. That's why I never use -k. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 16:36:35 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA04012 for scwm-discuss-outgoing; Fri, 20 Nov 1998 16:36:35 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA04009 for ; Fri, 20 Nov 1998 16:36:31 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA08504; Fri, 20 Nov 98 16:36:08 EST Received: (qmail 30919 invoked by uid 0); 20 Nov 1998 21:36:40 -0000 Received: from isdn-29.canton.northnet.org (HELO desk.crynwr.com) (209.2.153.110) by ns.crynwr.com with SMTP; 20 Nov 1998 21:36:40 -0000 Received: (qmail 23642 invoked by uid 501); 20 Nov 1998 21:36:37 -0000 Date: 20 Nov 1998 21:36:37 -0000 Message-Id: <19981120213637.23641.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: <199811201730.MAA00921@jekyll.piermont.com> References: <199811201730.MAA00921@jekyll.piermont.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q > 1 3 5 7 9 10 8 6 4 2 > > ^^^ leftmost buttons ^^^ rightmost > > Is there any reason we couldn't have a more logical numbering scheme > used? Caution: newbie suggestion below: Why not have code which is called to render the title bar? (defun titlebar '((title-button 'iconify) (title-text "no title") (title-button 'maximize) (title-button 'resize))) -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Fri Nov 20 16:45:04 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA04094 for scwm-discuss-outgoing; Fri, 20 Nov 1998 16:45:04 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA04091 for ; Fri, 20 Nov 1998 16:45:03 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AB11436; Fri, 20 Nov 98 16:44:36 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA22334; Fri, 20 Nov 1998 23:44:26 +0200 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Another make bug in doc directory - incompatible perls? References: <199811201921.OAA02197@vicarious-existence.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Nov 1998 23:44:26 +0200 In-Reply-To: hjstein@bfr.co.il's message of "20 Nov 1998 22:24:11 +0200" Message-Id: Lines: 57 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I wanted to see what the latest scwmdoc perl script was doing, so I tried to do make all in the doc directory, but it failed: hjstein@bacall:~/remote-cvs-pkgs/scwm/doc$ make all abs_builddir_doc=`pwd`; \ outdir=$abs_builddir_doc; \ echo Outputting to directory: $outdir; \ cd ..; abs_top_builddir=`pwd`; \ cd $abs_builddir_doc; cd ..; \ abs_top_srcdir=`pwd`; \ echo 'make[99]: Entering directory `'$abs_top_srcdir"'"; \ perl $abs_top_builddir/utilities/dev/scwmdoc -o $outdir/scwm.sgml -O $outdir/scwm-variables.txt -V scheme/user-options.scm -d ${SCWMDIR:-${abs_top_srcdir}} $outdir/scwm-procedures.txt; \ echo 'make[99]: Leaving directory `'$abs_top_srcdir"'" Outputting to directory: /home/hjstein/remote-cvs-pkgs/scwm/doc make[99]: Entering directory `/home/hjstein/remote-cvs-pkgs/scwm' Can't locate constant.pm in @INC at /home/hjstein/remote-cvs-pkgs/scwm/utilities/dev/scwmdoc line 45. BEGIN failed--compilation aborted at /home/hjstein/remote-cvs-pkgs/scwm/utilities/dev/scwmdoc line 45. make[99]: Leaving directory `/home/hjstein/remote-cvs-pkgs/scwm' hjstein@bacall:~/remote-cvs-pkgs/scwm/doc$ make all abs_builddir_doc=`pwd`; \ outdir=$abs_builddir_doc; \ echo Outputting to directory: $outdir; \ cd ..; abs_top_builddir=`pwd`; \ cd $abs_builddir_doc; cd ..; \ abs_top_srcdir=`pwd`; \ echo 'make[99]: Entering directory `'$abs_top_srcdir"'"; \ perl $abs_top_builddir/utilities/dev/scwmdoc -o $outdir/scwm.sgml -O $outdir/scwm-variables.txt -V scheme/user-options.scm -d ${SCWMDIR:-${abs_top_srcdir}} $outdir/scwm-procedures.txt; \ echo 'make[99]: Leaving directory `'$abs_top_srcdir"'" Outputting to directory: /home/hjstein/remote-cvs-pkgs/scwm/doc make[99]: Entering directory `/home/hjstein/remote-cvs-pkgs/scwm' Can't locate constant.pm in @INC at /home/hjstein/remote-cvs-pkgs/scwm/utilities/dev/scwmdoc line 45. BEGIN failed--compilation aborted at /home/hjstein/remote-cvs-pkgs/scwm/utilities/dev/scwmdoc line 45. make[99]: Leaving directory `/home/hjstein/remote-cvs-pkgs/scwm' I take it we have incompatible perls, with your version having this "constant.pm", and mine not having it? My version is: hjstein@bacall:~/remote-cvs-pkgs/scwm/doc$ perl -v This is perl, version 5.003 with EMBED Locally applied patches: SUIDBUF - Buffer overflow fixes for suidperl security built under linux at Apr 22 1997 10:04:46 + two suidperl security patches Copyright 1987-1996, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5.0 source kit. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Nov 20 17:44:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA04575 for scwm-discuss-outgoing; Fri, 20 Nov 1998 17:44:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA04569 for ; Fri, 20 Nov 1998 17:44:33 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA19146; Fri, 20 Nov 98 17:44:12 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA23694; Fri, 20 Nov 1998 14:44:04 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Another make bug in doc directory - incompatible perls? References: <199811201921.OAA02197@vicarious-existence.mit.edu> From: Greg Badros Date: 20 Nov 1998 14:44:04 -0800 In-Reply-To: hjstein@bfr.co.il's message of "20 Nov 1998 23:44:26 +0200" Message-Id: Lines: 64 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > I wanted to see what the latest scwmdoc perl script was doing, so I > tried to do make all in the doc directory, but it failed: > I take it we have incompatible perls, with your version having this > "constant.pm", and mine not having it? My version is: > > hjstein@bacall:~/remote-cvs-pkgs/scwm/doc$ perl -v > > This is perl, version 5.003 with EMBED > Locally applied patches: > SUIDBUF - Buffer overflow fixes for suidperl security > > built under linux at Apr 22 1997 10:04:46 > + two suidperl security patches > > Copyright 1987-1996, Larry Wall > > Perl may be copied only under the terms of either the Artistic License or the > GNU General Public License, which may be found in the Perl 5.0 source kit. 5.004 definitely has constant.pm standard. I'm using: Summary of my perl5 (5.0 patchlevel 4 subversion 2) configuration: Platform: osname=linux, osvers=2.0.29, archname=i686-linux uname='linux uni 2.0.29 #1 tue mar 11 08:26:04 pst 1997 i686 ' hint=recommended, useposix=true, d_sigaction=define bincompat3=y useperlio=undef d_sfio=undef Compiler: cc='gcc', optimize='-O', gccversion=2.7.2 cppflags='-Dbool=char -DHAS_BOOL -DPERL_CORE -Dbool=char -DHAS_BOOL -I/usr/local/include -DDEBUGGING -DDEBUGGING_MSTATS -I/usr/local/include' ccflags ='-Dbool=char -DHAS_BOOL -DPERL_CORE -Dbool=char -DHAS_BOOL -I/usr/local/include -DDEBUGGING -DDEBUGGING_MSTATS -I/usr/local/include' stdchar='char', d_stdstdio=define, usevfork=false voidflags=15, castflags=0, d_casti32=define, d_castneg=define intsize=4, alignbytes=4, usemymalloc=y, randbits=31 Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -ldl -lm -lc libc=, so=so useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: DEBUGGING Built under linux Compiled at Sep 4 1997 14:37:45 %ENV: PERLLIB="/homes/gws/gjb/macros:/homes/gws/gjb/perl/site-lib" @INC: /homes/gws/gjb/macros /homes/gws/gjb/perl/site-lib /uns/lib/perl5.004_02/arch /uns/share/lib/perl5.004_02 /uns/share/lib/perl5.004_02/site_perl/i686-linux /uns/share/lib/perl5.004_02/site_perl . From owner-scwm-discuss@mit.edu Fri Nov 20 17:55:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA04686 for scwm-discuss-outgoing; Fri, 20 Nov 1998 17:55:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA04683 for ; Fri, 20 Nov 1998 17:55:46 -0500 Received: from smtp7.nwnexus.com by MIT.EDU with SMTP id AA22502; Fri, 20 Nov 98 17:55:25 EST Received: from pulsar.halcyon.com (coho.halcyon.com [198.137.231.21]) by smtp7.nwnexus.com (8.8.8/8.8.8) with ESMTP id OAA24095 for ; Fri, 20 Nov 1998 14:55:22 -0800 Received: from ken@localhost by pulsar.halcyon.com id <276553-384>; Fri, 20 Nov 1998 14:51:26 -0800 To: scwm-discuss@mit.edu Subject: Re: a documentation "bug" In-Reply-To: <19981118170905.A12421@molehill.org> Date: Fri, 20 Nov 1998 14:51:26 -0800 From: Ken Pizzini Message-Id: <19981120225126Z276553-384+34@pulsar.halcyon.com> Sender: owner-scwm-discuss@mit.edu Precedence: bulk On scwm-discuss, message <19981118170905.A12421@molehill.org>, Todd Larason wrote: >To make pie menus the default: > >(use-modules (app scwm pie-menus)) >(menu-style #:look pie-menu-look) > >To make only a particular menu a pie menu: > >(define menu-blah-blah-blah > (menu > (list blah blah blah blah) > #:menu-look pie-menu-look)) Hmmm... I think that points to the problem I was having: I was trying to figure out a way to make one _already_existing_ menu become a pie menu. Thanks for the pointers, --Ken Pizzini From owner-scwm-discuss@mit.edu Fri Nov 20 18:22:26 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA05023 for scwm-discuss-outgoing; Fri, 20 Nov 1998 18:22:26 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA05020 for ; Fri, 20 Nov 1998 18:22:25 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA09335; Fri, 20 Nov 98 18:22:01 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA24108; Fri, 20 Nov 1998 15:22:01 -0800 (PST) To: scwm-discuss@mit.edu Subject: Window placement broken? From: Greg Badros Date: 20 Nov 1998 15:22:00 -0800 Message-Id: Lines: 7 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk in 0.9 beta 1, window placement seems broken -- all my windows get thrown up at 0,0 of the current viewport. I'm using gjb.scwmrc, of course. Are there changes I should've noticed that would explain this? (I don't have time to look into it myself right now...) Greg From owner-scwm-discuss@mit.edu Fri Nov 20 18:34:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA05171 for scwm-discuss-outgoing; Fri, 20 Nov 1998 18:34:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA05165; Fri, 20 Nov 1998 18:34:19 -0500 Message-Id: <199811202334.SAA05165@vicarious-existence.mit.edu> To: Russell Nelson cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-reply-to: Your message of "20 Nov 1998 21:36:37 GMT." <19981120213637.23641.qmail@desk.crynwr.com> Date: Fri, 20 Nov 1998 18:34:19 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nelson@crynwr.com writes: > Perry E. Metzger writes: > > > 1 3 5 7 9 10 8 6 4 2 > > > ^^^ leftmost buttons ^^^ rightmost > > > > Is there any reason we couldn't have a more logical numbering scheme > > used? > > Caution: newbie suggestion below: > > Why not have code which is called to render the title bar? > > (defun titlebar '((title-button 'iconify) > (title-text "no title") > (title-button 'maximize) > (title-button 'resize))) Right now the way the parts of a window's decorations get arranged and redered is pretty much inherited from fvwm2. We plan to change it a lot at some point, even more radically than your suggestion above implies. For instance, to emulate the looks of many window managers we will need to be able to have sideways title bars, buttons on arbitrary sides of the window, etc. I think as far as incremental improvement goes, naming the parts sanely is more important for now than trying to abstract things further. - Maciej From owner-scwm-discuss@mit.edu Fri Nov 20 18:51:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA05733 for scwm-discuss-outgoing; Fri, 20 Nov 1998 18:51:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA05721 for ; Fri, 20 Nov 1998 18:51:35 -0500 Received: from austin.cs.unc.edu by MIT.EDU with SMTP id AA05015; Fri, 20 Nov 98 18:51:13 EST Received: from rukbat.cs.unc.edu (rukbat.cs.unc.edu [152.2.133.170]) by austin.cs.unc.edu (8.8.8/8.8.8) with ESMTP id SAA20857; Fri, 20 Nov 1998 18:51:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by rukbat.cs.unc.edu (8.8.8/8.8.8) with SMTP id SAA17321; Fri, 20 Nov 1998 18:51:10 -0500 (EST) Date: Fri, 20 Nov 1998 18:51:09 -0500 (EST) From: Stephen Tell To: "Harvey J. Stein" Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: Another make bug in doc directory - incompatible perls? In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 20 Nov 1998, Harvey J. Stein wrote: > I take it we have incompatible perls, with your version having this > "constant.pm", and mine not having it? My version is: > > hjstein@bacall:~/remote-cvs-pkgs/scwm/doc$ perl -v > > This is perl, version 5.003 with EMBED looks like it. Perl 5.004 has constant.pm, and that file bears this comment: # Some of this stuff didn't work in version 5.003, alas. require 5.003_96; Steve -- Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF Research Associate, Microelectronic Systems Laboratory Computer Science Department, UNC@Chapel Hill. W:919-962-1845 From owner-scwm-discuss@mit.edu Sat Nov 21 00:47:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA10110 for scwm-discuss-outgoing; Sat, 21 Nov 1998 00:47:20 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA10107 for ; Sat, 21 Nov 1998 00:47:17 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA28550; Sat, 21 Nov 98 00:46:50 EST Received: (qmail 16415 invoked by uid 0); 21 Nov 1998 05:47:22 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 21 Nov 1998 05:47:22 -0000 Received: (qmail 29303 invoked by uid 501); 21 Nov 1998 05:47:19 -0000 Date: 21 Nov 1998 05:47:19 -0000 Message-Id: <19981121054719.29302.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: References: <199811201755.MAA00319@vicarious-existence.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q Right, and that's great because as Maciej points out, we lost touch w/ > not understanding Scwm a while back, and need your (and other new > converts') perspective desperately. I'm an expert at not understanding Scwm! > I didn't mean to sound as critical as I must have.... I just believe the > reference docs are still the more important of the two kinds for now, > and they still need some work... I need more examples of how to do things. scwm-intro-tutorial.scm is a great introduction, but it just stops. Just code snippets, along with an explanation of what they do. -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Sat Nov 21 01:28:10 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA10360 for scwm-discuss-outgoing; Sat, 21 Nov 1998 01:28:10 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA10357 for ; Sat, 21 Nov 1998 01:28:06 -0500 Received: from M66-080-10.MIT.EDU by MIT.EDU with SMTP id AA01857; Sat, 21 Nov 98 01:27:39 EST Received: by M66-080-10.mit.edu (SMI-8.6/4.7) id BAA28410; Sat, 21 Nov 1998 01:27:38 -0500 Message-Id: <199811210627.BAA28410@M66-080-10.mit.edu> To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "21 Nov 1998 05:47:19 GMT." <19981121054719.29302.qmail@desk.crynwr.com> Date: Sat, 21 Nov 1998 01:27:37 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nelson@crynwr.com writes: > Greg Badros writes: > > Right, and that's great because as Maciej points out, we lost touch w/ > > not understanding Scwm a while back, and need your (and other new > > converts') perspective desperately. > > I'm an expert at not understanding Scwm! > > > I didn't mean to sound as critical as I must have.... I just believe the > > reference docs are still the more important of the two kinds for now, > > and they still need some work... > > I need more examples of how to do things. scwm-intro-tutorial.scm is > a great introduction, but it just stops. Just code snippets, along > with an explanation of what they do. > I think a of code snippets withe explanations would be way cool, a sort of "Recipe Book for Scwm". While it could start with examples for beginning users, I think even having vaguely esoteric things would be nice. I personally get a kick out of being surprised by something a user has done with scwm. - Maciej From owner-scwm-discuss@mit.edu Sat Nov 21 02:37:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA10754 for scwm-discuss-outgoing; Sat, 21 Nov 1998 02:37:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA10751 for ; Sat, 21 Nov 1998 02:37:18 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA06909; Sat, 21 Nov 98 02:36:48 EST Received: (qmail 11335 invoked by uid 501); 21 Nov 1998 07:37:03 -0000 Message-Id: <19981120233702.A11301@molehill.org> Date: Fri, 20 Nov 1998 23:37:02 -0800 From: Todd Larason To: Russell Nelson , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201755.MAA00319@vicarious-existence.mit.edu> <19981121054719.29302.qmail@desk.crynwr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981121054719.29302.qmail@desk.crynwr.com>; from Russell Nelson on Sat, Nov 21, 1998 at 05:47:19AM -0000 X-Tom-Swifty: "How many dings you got in your door, there, Tom?" "Ten", Tom replied decadently. X-Kibo: La... Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981121, Russell Nelson wrote: > I need more examples of how to do things. scwm-intro-tutorial.scm is > a great introduction, but it just stops. Just code snippets, along > with an explanation of what they do. To some extent, flux.scm is already helpful in this roll. There's not so much 'what they do' though, aside from the names of the functions. -- ICQ UIN: 43507609 From owner-scwm-discuss@mit.edu Sat Nov 21 05:48:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id FAA12689 for scwm-discuss-outgoing; Sat, 21 Nov 1998 05:48:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id FAA12686 for ; Sat, 21 Nov 1998 05:48:09 -0500 Received: from [141.219.70.11] by MIT.EDU with SMTP id AA17247; Sat, 21 Nov 98 05:47:39 EST Received: from mtu.edu (root@mtu.edu [141.219.70.1]) by news.mtu.edu (8.8.8/8.8.8) with ESMTP id FAA07371 for ; Sat, 21 Nov 1998 05:47:14 -0500 (EST) Received: from wiley.sas.it.mtu.edu (wiley.sas.it.mtu.edu [141.219.36.70]) by mtu.edu (8.8.8/8.8.8) with ESMTP id FAA23061 for ; Sat, 21 Nov 1998 05:47:13 -0500 (EST) Received: (from adisaacs@localhost) by wiley.sas.it.mtu.edu (8.8.7/8.8.7/mturelay-1.2) id FAA15785 for scwm-discuss@mit.edu; Sat, 21 Nov 1998 05:47:10 -0500 (EST) Message-Id: <19981121054710.A14439@mtu.edu> Date: Sat, 21 Nov 1998 05:47:10 -0500 From: Andrew Isaacson To: scwm-discuss@mit.edu Subject: default window context, and mouse contexts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 X-Pgp-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-Pgp-Key-Url: http://www.csl.mtu.edu/~adisaacs/pgp.txt Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is the default window context explained anywhere? I'm trying to set up my mouse bindings, and I've tried the following: My first try was (bind-mouse 'all "M-2" (lambda () (interactive-move (current-window-with-pointer) #t))) on my pentium 100, it takes a good quarter second (subjective measurement) for that (current-window-with-pointer) to get executed, and I've often moved the mouse out of the window I intended, and I end up grabbing a different window. So then I tried: (bind-mouse 'all "M-2" interactive-move) This fixes the latency problems, but I can't figure out how to turn opaque-move back on. Is there any way to get the default window context? It would seem that the best solution would be something like (bind-mouse 'all "M-2" (lambda () (let ((curr (current-window))) (if curr (interactive-move curr #t))))) since then I could do other cool stuff in there if I wanted, but I can't figure out how to get at this window context the documentation keeps talking about. This binding also poses a problem in that M-2 on the root window causes scwm to spew. Makes sense, but is there any way around it without enumerating every context _except_ 'root? -andy -- Andy Isaacson adisaacs@mtu.edu adi@acm.org Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/ From owner-scwm-discuss@mit.edu Sat Nov 21 08:06:17 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA13258 for scwm-discuss-outgoing; Sat, 21 Nov 1998 08:06:17 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id IAA13255 for ; Sat, 21 Nov 1998 08:06:14 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA23785; Sat, 21 Nov 98 08:05:43 EST Received: (qmail 26817 invoked by uid 0); 21 Nov 1998 13:06:10 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 21 Nov 1998 13:06:10 -0000 Received: (qmail 2311 invoked by uid 501); 21 Nov 1998 13:06:07 -0000 Date: 21 Nov 1998 13:06:07 -0000 Message-Id: <19981121130607.2310.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: <19981120233702.A11301@molehill.org> References: <199811201755.MAA00319@vicarious-existence.mit.edu> <19981121054719.29302.qmail@desk.crynwr.com> <19981120233702.A11301@molehill.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q On 981121, Russell Nelson wrote: > > I need more examples of how to do things. scwm-intro-tutorial.scm is > > a great introduction, but it just stops. Just code snippets, along > > with an explanation of what they do. > > To some extent, flux.scm is already helpful in this roll. There's not so much > 'what they do' though, aside from the names of the functions. Oh ugh. Trying to go from fvwm2 to scwm means removing a *lot* of cruft. Like toggle-maximize for example. Instead of keeping a pair of sizes in the C code, every window should have a list of possible sizes, so you could keep a ring, say, of window locations and overlaps, and rotate through them. -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Sat Nov 21 08:48:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA13482 for scwm-discuss-outgoing; Sat, 21 Nov 1998 08:48:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id IAA13479 for ; Sat, 21 Nov 1998 08:48:02 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA07805 for scwm-discuss@huis-clos.mit.edu; Sat, 21 Nov 1998 14:40:36 +0100 (MET) Received: (qmail 919 invoked by uid 115); 21 Nov 1998 10:44:28 -0000 To: scwm-discuss@mit.edu Subject: Re: docs: scwm-procedures.txt References: <199811201829.NAA01000@vicarious-existence.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 11:44:25 +0100 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 13:29:02 EST" Message-ID: Lines: 26 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 20 Nov 1998 13:29:02 EST >>>>> Maciej Stachowiak said: Maciej> robbe@orcus.priv.at writes: >> They're not. Guile threads are viable only for applications where >> you (yield) very often. I don't think the doc-extractor is such an >> application. [Ooops, I thought I cancelled this mail. Anyway ...] Maciej> But they also implicitly yield at "evaluator ticks" and on Maciej> blocking I/O, which should work fine for the purposes of the Maciej> doc extractor. We won't know until we have tried. Since Harvey did timings before, perhaps his interest is piqued enough to try and time it inside scwm. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Nov 21 08:48:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA13486 for scwm-discuss-outgoing; Sat, 21 Nov 1998 08:48:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from relay8.Austria.EU.net (relay8.Austria.EU.net [193.154.160.146]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id IAA13483 for ; Sat, 21 Nov 1998 08:48:20 -0500 Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA07809 for scwm-discuss@huis-clos.mit.edu; Sat, 21 Nov 1998 14:40:37 +0100 (MET) Received: (qmail 955 invoked by uid 115); 21 Nov 1998 10:58:58 -0000 To: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <199811201913.OAA01899@vicarious-existence.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 11:58:55 +0100 In-Reply-To: Maciej Stachowiak's message of "Fri, 20 Nov 1998 14:13:11 EST" Message-ID: Lines: 30 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 20 Nov 1998 14:13:11 EST >>>>> Maciej Stachowiak said: Maciej> I suspect Todd is thinking of starting Gnus in another emacs Maciej> frame and making it switch desks automagically then. That's what Jonas wanted to do. Maciej> Can emacs be made to set the resource name of an individual Maciej> window? Yes. I use the following function to give all emacs "frames" (i.e. top-level windows in X-speak) a different resource name. This makes it possible to specify individual placements for them in my scwmrc. (defun my-make-frame nil "make new frame named `emacsN', where N is the number of frames on this device (including the new one)" (interactive) (make-frame (list 'name (concat "emacs" (1+ (length (device-frame-list))))))) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Nov 21 11:54:30 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA14340 for scwm-discuss-outgoing; Sat, 21 Nov 1998 11:54:30 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA14337 for ; Sat, 21 Nov 1998 11:54:03 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA07347; Sat, 21 Nov 98 11:53:30 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id LAA08011 for ; Sat, 21 Nov 1998 11:53:22 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Dynamic setting of desk for window when title changes. References: <199811201913.OAA01899@vicarious-existence.mit.edu> Date: 21 Nov 1998 11:53:14 -0500 Message-Id: <5lww4p0yyt.fsf@tequila.cs.yale.edu> Lines: 15 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 21 Nov 1998 11:53:15 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Robbe" == Robert Bihlmeyer writes: > (defun my-make-frame nil > "make new frame named `emacsN', > where N is the number of frames on this device (including the new one)" > (interactive) > (make-frame (list 'name (concat "emacs" (1+ (length (device-frame-list))))))) I don't know if this code actually works, but it should really be: ...(make-frame (list (cons 'name )))... aka ...(make-frame `((name . ,)))... -- Stefan From owner-scwm-discuss@mit.edu Sat Nov 21 15:28:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15163 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:28:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15160 for ; Sat, 21 Nov 1998 15:28:39 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA03106; Sat, 21 Nov 98 15:28:08 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id VAA15022 for ; Sat, 21 Nov 1998 21:28:00 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id VAA15633; Sat, 21 Nov 1998 21:27:56 +0100 (MET) To: scwm-discuss@mit.edu Subject: "Image file was not found: " X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 21 Nov 1998 21:27:55 +0100 Message-Id: Lines: 62 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am currently toying around with decors and I stole some from decor.scwmrc, I just did some tweeking and I haven't found any obvious diffrences. When I start scwm I get these errormesssages: ------- [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-cross.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-cross.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-cross.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-cross.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-lower.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-lower.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-lower.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-lower.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-raise.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-raise.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-raise.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 [Scwm][path_expand_image_fname]: <> Image file was not found: `mini-raise.xpm' [Scwm][add_spec_to_face_x]: <> Image not found for argument #3 ------- Line 88+. In ~/Grafik/XIcons the files exist with correct names and permissions what I can see. What have I missed? The sacrifice of the black goat? ;-) It did find the mini-ball.xpm on line 498 (js-testdecor) which is in the same directory. (Just tested.) H-ESC and (display image-load-path) gives: (/users/dtek/d94/d4jonas/Grafik/XIcons /users/dtek/d94/d4jonas/Grafik/XIcons/scwm-icons-0.8/icons /usr/X11/lib/X11/mini-icons /usr/X11/include/X11/pixmaps /usr/lib/icons /usr/pd/X11/include/X11/pixmaps /usr/pd/lib/icons /usr/pd/icons /usr/pd/X11/lib/X11/fvwm/icons /usr/pd/X11/lib/fvwm/icons /usr/openwin/include/X11/bitmaps /usr/openwin/include/X11/pixmaps /X11/mini-icons /usr/pd/include/X11/pixmaps /usr/pd/include/X11/bitmaps /usr/pd/lib/X11/mini-icons) ('Grafik' is Swedish for 'Graphic'.) TIA! -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Sat Nov 21 15:39:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15247 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:39:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15244 for ; Sat, 21 Nov 1998 15:39:49 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA04524; Sat, 21 Nov 98 15:39:19 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA27231; Sat, 21 Nov 1998 12:39:15 -0800 (PST) To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811201755.MAA00319@vicarious-existence.mit.edu> <19981121054719.29302.qmail@desk.crynwr.com> From: Greg Badros Date: 21 Nov 1998 12:39:15 -0800 In-Reply-To: Russell Nelson's message of "21 Nov 1998 05:47:19 -0000" Message-Id: Lines: 23 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Russell Nelson writes: > Greg Badros writes: > > Right, and that's great because as Maciej points out, we lost touch w/ > > not understanding Scwm a while back, and need your (and other new > > converts') perspective desperately. > > I'm an expert at not understanding Scwm! > > > I didn't mean to sound as critical as I must have.... I just believe the > > reference docs are still the more important of the two kinds for now, > > and they still need some work... > > I need more examples of how to do things. scwm-intro-tutorial.scm is > a great introduction, but it just stops. Just code snippets, along > with an explanation of what they do. Right-- I just had a short afternoon that freed up unexpectedly a while back so got started writing it... I'll work on it more over Christmas as I won't need a high bandwidth connection or a fast machine to write more of that tutorial. Greg From owner-scwm-discuss@mit.edu Sat Nov 21 15:40:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15261 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:40:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15258 for ; Sat, 21 Nov 1998 15:40:45 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA04641; Sat, 21 Nov 98 15:40:15 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA27234; Sat, 21 Nov 1998 12:40:13 -0800 (PST) To: Maciej Stachowiak Cc: Russell Nelson , scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? References: <199811210627.BAA28410@M66-080-10.mit.edu> From: Greg Badros Date: 21 Nov 1998 12:40:12 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 21 Nov 1998 01:27:37 EST" Message-Id: Lines: 28 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > nelson@crynwr.com writes: > > Greg Badros writes: > > > Right, and that's great because as Maciej points out, we lost touch w/ > > > not understanding Scwm a while back, and need your (and other new > > > converts') perspective desperately. > > > > I'm an expert at not understanding Scwm! > > > > > I didn't mean to sound as critical as I must have.... I just believe the > > > reference docs are still the more important of the two kinds for now, > > > and they still need some work... > > > > I need more examples of how to do things. scwm-intro-tutorial.scm is > > a great introduction, but it just stops. Just code snippets, along > > with an explanation of what they do. > > > > I think a of code snippets withe explanations would be way cool, a > sort of "Recipe Book for Scwm". While it could start with examples for > beginning users, I think even having vaguely esoteric things would be > nice. I personally get a kick out of being surprised by something a > user has done with scwm. Perhaps _The_Scwm_Cookbook_ (like _The_Perl_Cookbook_)? Greg From owner-scwm-discuss@mit.edu Sat Nov 21 15:44:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15315 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:44:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15312 for ; Sat, 21 Nov 1998 15:44:12 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA05067; Sat, 21 Nov 98 15:43:41 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA27241; Sat, 21 Nov 1998 12:43:37 -0800 (PST) To: Andrew Isaacson Cc: scwm-discuss@mit.edu Subject: Re: default window context, and mouse contexts References: <19981121054710.A14439@mtu.edu> From: Greg Badros Date: 21 Nov 1998 12:43:37 -0800 In-Reply-To: Andrew Isaacson's message of "Sat, 21 Nov 1998 05:47:10 -0500" Message-Id: Lines: 52 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Andrew Isaacson writes: > Is the default window context explained anywhere? I'm trying to set It's partially at: http://www.cs.washington.edu/homes/gjb/scwm-doc/c0517.htm See also the documentation for `get-window'. > up my mouse bindings, and I've tried the following: > > My first try was > (bind-mouse 'all "M-2" > (lambda () (interactive-move (current-window-with-pointer) #t))) > > on my pentium 100, it takes a good quarter second (subjective > measurement) for that (current-window-with-pointer) to get executed, > and I've often moved the mouse out of the window I intended, and I end > up grabbing a different window. > > So then I tried: > (bind-mouse 'all "M-2" interactive-move) > > This fixes the latency problems, but I can't figure out how to turn > opaque-move back on. Use (get-window) instead of (current-window-with-pointer). > Is there any way to get the default window context? It would seem Use scwm-apropos in scwm-mode under emacs on "context" and you'll see `window-context' which does what you want. get-window prompts for a window interactively if the window-context is empty. > that the best solution would be something like > (bind-mouse 'all "M-2" > (lambda () > (let ((curr (current-window))) > (if curr (interactive-move curr #t))))) > since then I could do other cool stuff in there if I wanted, but I > can't figure out how to get at this window context the documentation > keeps talking about. > > This binding also poses a problem in that M-2 on the root window > causes scwm to spew. Makes sense, but is there any way around it > without enumerating every context _except_ 'root? The above should handle that case fine. Greg From owner-scwm-discuss@mit.edu Sat Nov 21 15:50:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15472 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:50:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15469 for ; Sat, 21 Nov 1998 15:50:02 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA12506; Sat, 21 Nov 98 15:49:28 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA27255; Sat, 21 Nov 1998 12:49:24 -0800 (PST) To: Jonas Steverud Cc: scwm-discuss@mit.edu Subject: Re: "Image file was not found: " References: From: Greg Badros Date: 21 Nov 1998 12:49:24 -0800 In-Reply-To: Jonas Steverud's message of "21 Nov 1998 21:27:55 +0100" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jonas Steverud writes: > I am currently toying around with decors and I stole some from > decor.scwmrc, I just did some tweeking and I haven't found any obvious > diffrences. > > > > > Line 88+. > > In ~/Grafik/XIcons the files exist with correct names and permissions > what I can see. What have I missed? The sacrifice of the black goat? ;-) Try using strace or truss to watch what directories it's really searching; also double check that the filenames are right -- sometime mini_foo.xpm and mini-foo.xpm are easily confused. Greg From owner-scwm-discuss@mit.edu Sat Nov 21 15:53:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA15547 for scwm-discuss-outgoing; Sat, 21 Nov 1998 15:53:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA15544 for ; Sat, 21 Nov 1998 15:53:30 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA06240; Sat, 21 Nov 98 15:52:58 EST Received: (qmail 14185 invoked by uid 501); 21 Nov 1998 20:53:31 -0000 Message-Id: <19981121125331.A13966@molehill.org> Date: Sat, 21 Nov 1998 12:53:31 -0800 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: "Image file was not found: " References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Jonas Steverud on Sat, Nov 21, 1998 at 09:27:55PM +0100 X-Tom-Swifty: "I am so singing in tune", Tom sounded off. X-Kibo: Mind control rays is like the inside of a microwave oven. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981121, Jonas Steverud wrote: > In ~/Grafik/XIcons the files exist with correct names and permissions > what I can see. Okay, cause #2 taken care of > It did find the mini-ball.xpm on line 498 (js-testdecor) which is in > the same directory. (Just tested.) Cause #1 taken care of too hmm... Do you have strace or truss or something similar on this system? Something that will let you see the system calls being made? That could show you what directories it's looking in, and what errors it's getting. -- ICQ UIN: 70867622 From owner-scwm-discuss@mit.edu Sat Nov 21 16:07:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA15775 for scwm-discuss-outgoing; Sat, 21 Nov 1998 16:07:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA15772 for ; Sat, 21 Nov 1998 16:07:08 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA14778; Sat, 21 Nov 98 16:06:33 EST Received: from bort.dtek.chalmers.se (d4jonas@bort.dtek.chalmers.se [129.16.30.58]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id WAA19428 for ; Sat, 21 Nov 1998 22:06:34 +0100 (MET) Received: (from d4jonas@localhost) by bort.dtek.chalmers.se (8.8.8/8.8.8) id WAA15773; Sat, 21 Nov 1998 22:06:33 +0100 (MET) To: scwm-discuss@mit.edu Subject: Re: "Image file was not found: " References: X-No-Archive: Yes X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 21 Nov 1998 22:06:33 +0100 In-Reply-To: Greg Badros's message of "21 Nov 1998 12:49:24 -0800" Message-Id: Lines: 19 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Jonas Steverud writes: > > > I am currently toying around with decors and I stole some from > > decor.scwmrc, I just did some tweeking and I haven't found any obvious > > diffrences. Problem found. > also double check that the filenames are right -- sometime > mini_foo.xpm and mini-foo.xpm are easily confused. Nope, that wasn't the problem... /Jonas, a.k.a. redface -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Sat Nov 21 18:29:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA16559 for scwm-discuss-outgoing; Sat, 21 Nov 1998 18:29:52 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA16556 for ; Sat, 21 Nov 1998 18:29:51 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA02145; Sat, 21 Nov 98 18:29:14 EST Received: (qmail 15106 invoked by uid 501); 21 Nov 1998 23:29:56 -0000 Message-Id: <19981121152956.A15042@molehill.org> Date: Sat, 21 Nov 1998 15:29:56 -0800 From: Todd Larason To: scwm-discuss list Subject: Re: SCWM CVS checkin Sat Nov 21 17:47:09 EST 1998 References: <199811212247.RAA16274@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811212247.RAA16274@vicarious-existence.mit.edu>; from Greg J. Badros on Sat, Nov 21, 1998 at 05:47:10PM -0500 Sender: owner-scwm-discuss@mit.edu Precedence: bulk X-Tom-Swifty: "Who stole the last chapter from my book of Fables?", asked Tom, demoralized. X-Kibo: Kibology is not existence. On 981121, Greg J. Badros wrote: > Update of /usr/local/repository/scwm/scwm > In directory vicarious-existence.mit.edu:/tmp/cvs-serv16264 > > Modified Files: > move.c > Log Message: > * move.c (moveLoop): Use gh_int2scm in calling the > interactive_move_new_position_hook so scheme objects are passed; > the raw integers were being passed before in error. This somewhat scares me; this same line of code has now been broken the same way twice. It would be very nice if someone can think of a way to autodetect it when it happens again. To quickly recap for those who may not have been here last time: there are functions (call3_hooks() in this case) that take SCM arguments. Sometimes the arguments are numbers. SCM is a typedef for an unsigned long. It is very easy to pass a number directly (x); the compiler won't warn about it. This causes crashes, as they need to be SCM-ified numbers (gh_int2scm(x)) or the garbage-scanner gets terribly confused, and crashes quickly follow. -- ICQ UIN: 2939189 From owner-scwm-discuss@mit.edu Sat Nov 21 18:57:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA16837 for scwm-discuss-outgoing; Sat, 21 Nov 1998 18:57:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA16834 for ; Sat, 21 Nov 1998 18:57:23 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27731; Sat, 21 Nov 98 18:56:51 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA27533; Sat, 21 Nov 1998 15:56:33 -0800 (PST) To: Todd Larason Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Sat Nov 21 17:47:09 EST 1998 References: <199811212247.RAA16274@vicarious-existence.mit.edu> <19981121152956.A15042@molehill.org> From: Greg Badros Date: 21 Nov 1998 15:56:33 -0800 In-Reply-To: Todd Larason's message of "Sat, 21 Nov 1998 15:29:56 -0800" Message-Id: Lines: 37 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > X-Tom-Swifty: "Who stole the last chapter from my book of Fables?", asked Tom, demoralized. > X-Kibo: Kibology is not existence. > > On 981121, Greg J. Badros wrote: > > Update of /usr/local/repository/scwm/scwm > > In directory vicarious-existence.mit.edu:/tmp/cvs-serv16264 > > > > Modified Files: > > move.c > > Log Message: > > * move.c (moveLoop): Use gh_int2scm in calling the > > interactive_move_new_position_hook so scheme objects are passed; > > the raw integers were being passed before in error. > > This somewhat scares me; this same line of code has now been broken the same > way twice. It would be very nice if someone can think of a way to autodetect > it when it happens again. Yea, this bites... when it last happened, we had a brief thread about what we could do to catch these problems automatically. IIRC, Jim Blandy said before he'd be willing to take patches that make SCM a struct so that they are not type aliases to longs. I'd gladly do this for guile, but only once I have a good chunk of time (it'd best be done in one sitting so other code doesn't move out from underneath). > To quickly recap for those who may not have been here last time: > > there are functions (call3_hooks() in this case) that take SCM arguments. > Sometimes the arguments are numbers. SCM is a typedef for an unsigned long. > It is very easy to pass a number directly (x); the compiler won't warn about it. > This causes crashes, as they need to be SCM-ified numbers (gh_int2scm(x)) or > the garbage-scanner gets terribly confused, and crashes quickly follow. Greg From owner-scwm-discuss@mit.edu Sat Nov 21 21:16:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA17781 for scwm-discuss-outgoing; Sat, 21 Nov 1998 21:16:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA17778 for ; Sat, 21 Nov 1998 21:16:05 -0500 Received: from jason05.u.washington.edu by MIT.EDU with SMTP id AA17162; Sat, 21 Nov 98 21:15:27 EST Received: from dante04.u.washington.edu (bobrink@dante04.u.washington.edu [140.142.15.6]) by jason05.u.washington.edu (8.8.4+UW97.07/8.8.4+UW98.06) with ESMTP id SAA18458 for ; Sat, 21 Nov 1998 18:15:30 -0800 Received: from localhost (bobrink@localhost) by dante04.u.washington.edu (8.8.4+UW97.07/8.8.4+UW98.06) with ESMTP id SAA53716 for ; Sat, 21 Nov 1998 18:15:30 -0800 Date: Sat, 21 Nov 1998 18:15:29 -0800 (PST) From: "'Bo' William Brinkman" To: scwm-discuss@mit.edu Subject: Building Snapshot 981121 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't built SCWM in quite a while: I am trying to do so, but I can't seem to get configure or autogen.sh to run without errors. This does not seem to be an issue with the scwm-0.9beta1 release. (Sorry I don't know anything about automake, or I would go figure it out myself!) # ./configure loading cache ./config.cache ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' # ./autogen.sh aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' aclocal: configure.in: 79: macro `AM_PROG_LIBTOOL' not found in library -- "Pinky, are you pondering what I'm pondering?" "I think so Brain, but if you change the 'P' to an 'O', my name would be 'Oinky'!" -- William "Bo" Brinkman II http://weber.u.washington.edu/~bobrink bobrink@u.washington.edu From owner-scwm-discuss@mit.edu Sat Nov 21 21:25:57 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA17860 for scwm-discuss-outgoing; Sat, 21 Nov 1998 21:25:57 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA17857 for ; Sat, 21 Nov 1998 21:25:56 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11146; Sat, 21 Nov 98 21:25:23 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id SAA27663; Sat, 21 Nov 1998 18:25:20 -0800 (PST) To: "'Bo' William Brinkman" Cc: scwm-discuss@mit.edu Subject: Re: Building Snapshot 981121 References: From: Greg Badros Date: 21 Nov 1998 18:25:20 -0800 In-Reply-To: "'Bo' William Brinkman"'s message of "Sat, 21 Nov 1998 18:15:29 -0800 (PST)" Message-Id: Lines: 27 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "'Bo' William Brinkman" writes: > I haven't built SCWM in quite a while: I am trying to do so, but I can't > seem to get configure or autogen.sh to run without errors. > This does not seem to be an issue with the scwm-0.9beta1 release. > (Sorry I don't know anything about automake, or I would go figure it out > myself!) > > # ./configure > loading cache ./config.cache > ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' > ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' > > # ./autogen.sh > aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' > aclocal: configure.in: 79: macro `AM_PROG_LIBTOOL' not found in library See the HACKING file and ensure your versions are up to snuff: "Scwm requires at least autoconf 2.12, automake 1.3 and libtool 1.2 to generate some of the automatically generated files for the build process." You may not have automake installed (or not installed properly) -- it looks as though the AM_* macros aren't being found. Greg From owner-scwm-discuss@mit.edu Sun Nov 22 00:04:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA18744 for scwm-discuss-outgoing; Sun, 22 Nov 1998 00:04:20 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA18741 for ; Sun, 22 Nov 1998 00:04:17 -0500 Received: from dfw-ix10.ix.netcom.com by MIT.EDU with SMTP id AA01598; Sun, 22 Nov 98 00:03:38 EST Received: (from smap@localhost) by dfw-ix10.ix.netcom.com (8.8.4/8.8.4) id XAA18743 for ; Sat, 21 Nov 1998 23:03:40 -0600 (CST) Received: from sji-ca5-48.ix.netcom.com(209.109.234.48) by dfw-ix10.ix.netcom.com via smap (V1.3) id rma018734; Sat Nov 21 23:03:26 1998 Message-Id: <36579AD9.62C5364B@alum.mit.edu> Date: Sun, 22 Nov 1998 05:02:17 +0000 From: Dale Jordan X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.34 i686) Mime-Version: 1.0 To: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811191705.MAA07122@huis-clos.mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have been lurking hereabouts and happily using scwm 0.7a for about 5 months now. I have hacked up one the sample scwmrc files to produce a fairly simple system to my liking -- not possible with fvwm2, of course. As a newbie to X and Linux I found some of the most impenetrable aspects of scwm were the concepts and features passed through to the user from the X layer, particularly window style options. I don't have a clue what many of them mean. A useful part of the scwm documentation would be a tutorial on the X concepts scwm allows one to manipulate. Some particular items: I would like to add bindings for the "Microsoft" keys for window control functions so as to avoid usurping other keys that Emacs and other programs might use. I have seen a number of posts about ways to do it, but they mostly talk about X modmap and such which I haven't yet mastered. The small glyphs used in title bar buttons are nice but require very careful selection of colors before they are clearly visible. Is there some way their contrast can be adjusted without becoming an X programmer? I am running in 16-bit color depth. Window placement for dialog boxes can be real pain, requiring one to move the mouse across the whole screen. Can scwm intervene in this? How would it know what kind of window is being created? Happily scwm-ing, Dale Jordan From owner-scwm-discuss@mit.edu Sun Nov 22 00:36:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA18933 for scwm-discuss-outgoing; Sun, 22 Nov 1998 00:36:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA18930 for ; Sun, 22 Nov 1998 00:36:46 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA04813; Sun, 22 Nov 98 00:36:07 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id AAA10187; Sun, 22 Nov 1998 00:35:59 -0500 To: Maciej Stachowiak Cc: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: Scheme documentation question. References: <199811182317.SAA03692@huis-clos.mit.edu> From: Jim Blandy Date: 22 Nov 1998 00:35:58 -0500 In-Reply-To: Maciej Stachowiak's message of Wed, 18 Nov 1998 18:17:34 EST Message-Id: Lines: 19 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > (define-public variable value optional-doc-string) > > > > Can't this be made to work? > > > > I think it can, I'll ask Jim Blandy what he thinks of this (the only > thing define and define-public would have to do is ignore the extra > form in this case. Seems fine. It's the way Emacs Lisp does it. > Docstrings do consume memory, I am not sure if they also consume > compute time. However, both of these are likely to be addressed in > Guile at some point. Jim Blandy has expressed a willingness to change > it. I think he will probably accept patches to change the way this > works when the scwm doc-extraction stuff is incorporated into Guile. Yep. From owner-scwm-discuss@mit.edu Sun Nov 22 04:08:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA21107 for scwm-discuss-outgoing; Sun, 22 Nov 1998 04:08:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA21104 for ; Sun, 22 Nov 1998 04:08:06 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA11287; Sun, 22 Nov 98 04:07:29 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id KAA26970 for scwm-discuss@mit.edu; Sun, 22 Nov 1998 10:06:48 +0100 (MET) Received: (qmail 933 invoked by uid 115); 21 Nov 1998 21:17:52 -0000 To: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <199811201913.OAA01899@vicarious-existence.mit.edu> <5lww4p0yyt.fsf@tequila.cs.yale.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 22:17:49 +0100 In-Reply-To: Stefan Monnier's message of "21 Nov 1998 11:53:14 -0500" Message-Id: Lines: 26 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 21 Nov 1998 11:53:14 -0500 >>>>> Stefan Monnier said: >>>>> "Robbe" == Robert Bihlmeyer writes: >> (make-frame (list 'name (concat "emacs" (1+ (length >> (device-frame-list))))))) Stefan> I don't know if this code actually works, but it should Stefan> really be: [...] Stefan> ...(make-frame `((name . ,)))... Can't say about Emacs, but in XEmacs both these forms work. The docs say the parameter is a property list, not an association list ... Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Nov 22 13:47:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA23294 for scwm-discuss-outgoing; Sun, 22 Nov 1998 13:47:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA23291 for ; Sun, 22 Nov 1998 13:47:31 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA29476; Sun, 22 Nov 98 13:46:44 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 22 Nov 1998 13:46:33 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 22 Nov 1998 13:46:32 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1/8.9.1) id NAA00990; Sun, 22 Nov 1998 13:46:45 -0500 To: Dale Jordan Cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811191705.MAA07122@huis-clos.mit.edu> <36579AD9.62C5364B@alum.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Dale Jordan's message of "Sun, 22 Nov 1998 05:02:17 +0000" Date: 22 Nov 1998 13:46:45 -0500 Message-Id: Lines: 42 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <36579AD9.62C5364B@alum.mit.edu> >>>> On the subject of "Re: Red Hat ContribNet" >>>> Sent on Sun, 22 Nov 1998 05:02:17 +0000 >>>> Honorable Dale Jordan writes: >> >> I would like to add bindings for the "Microsoft" keys for window >> control functions so as to avoid usurping other keys that Emacs and >> other programs might use. I have seen a number of posts about ways >> to do it, but they mostly talk about X modmap and such which I >> haven't yet mastered. use xev to find out the keycode of the key you want to rebind. then place this into .xmodmaprc: ------------------------------ ! Left win key (was Meta_L, Menu) <-- comment keycode 115 = Hyper_L ! Right win key (was Meta_R, F19) keycode 116 = Hyper_R ! Menu key (right of the Meta_R) keycode 117 = Super_R add mod3 = Super_L Super_R add mod4 = Hyper_L Hyper_R --------------------------------- then put command "xmodmap ~/.xmodmaprc" into your ~/.xsession. now you can use these keys as super and hyper: (H - hyper, M - meta, C - control, S - shift, s - super). (bind-key 'all "H-F1" popup-util) (bind-key 'all "s-F1" popup-util) >> Window placement for dialog boxes can be real pain, requiring one to >> move the mouse across the whole screen. Can scwm intervene in this? >> How would it know what kind of window is being created? these windows satisfy the `transient?' predicate. there should be a way to tell scwm to use "at-mouse" placement for such windows, but I don't know how. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.1 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. I don't have an attitude problem. You have a perception problem. From owner-scwm-discuss@mit.edu Sun Nov 22 15:18:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA23794 for scwm-discuss-outgoing; Sun, 22 Nov 1998 15:18:53 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id PAA23791 for ; Sun, 22 Nov 1998 15:18:51 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA18046 for ; Sun, 22 Nov 1998 15:18:10 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA05748 for ; Sun, 22 Nov 1998 15:18:07 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id PAA03549 for ; Sun, 22 Nov 1998 15:18:38 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sun, 22 Nov 1998 20:18:37 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Two bugs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk My latest update of scwm has two bugs. The first is in `modules/scwmgtkhelper/scwmgtkhelper.c'. It is looking to include scwmgdkhelper.x, which doesn't exist. Here's the patch to make things compile (I haven't actually tested the GTK module yet though). Index: scwmgtkhelper.c =================================================================== RCS file: /anoncvs/scwm/modules/scwmgtkhelper/scwmgtkhelper.c,v retrieving revision 1.1 diff -r1.1 scwmgtkhelper.c 75c75 < #include "scwmgdkhelper.x" --- > #include "scwmgtkhelper.x" The second bug is that smart window placement no longer seems to work. All of my windows without explicit geometry settings are showing up at 0,0. The changed.c is: char *szRepoLastChanged = "Sat Nov 21 17:47:10 EST 1998 -- $Revision: 1.928 $"; See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sun Nov 22 16:11:29 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA24312 for scwm-discuss-outgoing; Sun, 22 Nov 1998 16:11:29 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA24309 for ; Sun, 22 Nov 1998 16:11:28 -0500 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA09230; Sun, 22 Nov 98 16:10:46 EST Received: from baguette (chlh.tbit.dk [194.182.135.163]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id WAA00246; Sun, 22 Nov 1998 22:10:42 +0100 (MET) Received: by baguette id m0zhfTZ-000ydMC (Debian Smail-3.2.0.101 1997-Dec-17 #2); Sun, 22 Nov 1998 20:47:17 +0100 (CET) From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13912.27204.880826.47213@baguette> Date: Sun, 22 Nov 1998 20:47:16 +0100 (CET) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Scheme documentation question. In-Reply-To: References: <199811182246.AAA32065@blinky.bfr.co.il> <199811182317.SAA03692@huis-clos.mit.edu> <13907.51876.764477.289664@chl> X-Mailer: VM 6.59 under Emacs 20.2.2 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Robbe" == Robert Bihlmeyer writes: Robbe> Hi, >>>>> On Thu, 19 Nov 1998 08:37:08 +0100 (MET) >>>>> Christian Lynbech said: >>>> (define-public variable value optional-doc-string) >>>> >>>> Can't this be made to work? >>>> Christian> Wouldn't this break if run with older versions of guile? Robbe> No. The above form (with doc-string) throws an error in guile 1.3. As Robbe> the doc-string is optional, code that has no doc-strings (legacy or Robbe> not) will work as expected. I actually meant the other way around. If guile is changed to make define-public accept 3 arguments, then code using that feature will fail to work with older versions of guile. Currently a small problem, but still a problem. Christian> (define-public variable value) "documentation" ... Robbe> You'd still have to do some magic. No, I don't think this is much Robbe> better than the current solution (magic comments). Except that the magic now is visible to the `read' function. Comments (magic or not) isn't. Robbe> ... Harvey's suggestion *is* backwards-compatible, I'd prefer Robbe> that. I think I agree. ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Sun Nov 22 18:00:30 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA24859 for scwm-discuss-outgoing; Sun, 22 Nov 1998 18:00:30 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA24856 for ; Sun, 22 Nov 1998 18:00:27 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AB24206; Sun, 22 Nov 98 17:59:45 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id RAA26966 for ; Sun, 22 Nov 1998 17:59:01 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id RAA03640 for ; Sun, 22 Nov 1998 17:59:00 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id RAA01359; Sun, 22 Nov 1998 17:59:00 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13912.38707.968124.498974@horus.cs.cornell.edu> Date: Sun, 22 Nov 1998 17:58:59 -0500 (EST) To: scwm-discuss@mit.edu Subject: Compilation problems X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk When I try to ./configure, I got errors trying to find guile. I think that someone had also a problem with it. Looking in configure.in, I found dnl FIXJTL: readline is sometimes needed too; hopefully anybody with dnl a guile with readline support has a working guile-config or build-guile So I've added GUILE_LIBS_PRE="${GUILE_LIBS_PRE} -lreadline" just before that and it fixed it. The installation I have is the guile-1.3-1 and readline-2.2-4, and I didn't find guile-config anywhere. Another thing is that I modified scwmgtkhelper.c:75 to say scwmgtkhelper.x instead of scwmgdkhelper.x. btw, another warning msg I got from autogen.sh is aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Sun Nov 22 19:54:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA25454 for scwm-discuss-outgoing; Sun, 22 Nov 1998 19:54:52 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA25451 for ; Sun, 22 Nov 1998 19:54:46 -0500 Received: from mun-c45-014-vty153.as.wcom.net by MIT.EDU with SMTP id AA18235; Sun, 22 Nov 98 19:53:56 EST Received: (from forcer@localhost) by forcix.roof.lan (8.9.1/8.9.1) id BAA08217 for scwm-discuss@mit.edu; Mon, 23 Nov 1998 01:53:12 +0100 Message-Id: <19981123015312.A8189@forcix.roof.lan> Date: Mon, 23 Nov 1998 01:53:12 +0100 From: forcer To: scwm-discuss@mit.edu Subject: Re: Two bugs Mail-Followup-To: scwm-discuss@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Craig Struble on Sun, Nov 22, 1998 at 08:18:37PM +0000 X-Operating-System: Linux forcix 2.0.36 X-Url: http://webserver.de/forcer/ Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sun, Nov 22, 1998 at 08:18:37PM +0000, Craig Struble wrote: >My latest update of scwm has two bugs. [scwmgdkhelper.x-bug snipped] >The second bug is that smart window placement no longer seems to work. All >of my windows without explicit geometry settings are showing up at 0,0. Just as a note: Neither does click-to-place. Seems like there's some check missing or wrong. :) A different bug i noticed: Whenever i start SCWM from a different program than directly from the ~/.xinitrc, guile gets a stack overflow: ERROR: In expression (if define? (module-make-local-var! module symbol) ...): ERROR: Stack overflow The same happens when i use (restart "scwm") HTH, -forcer -- ((email . "forcer@mindless.com") (www . "http://webserver.de/forcer/") (irc . "forcer@#StarWars (IRCnet)") (pgp . "key available on my website")) From owner-scwm-discuss@mit.edu Sun Nov 22 20:18:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA25617 for scwm-discuss-outgoing; Sun, 22 Nov 1998 20:18:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA25614 for ; Sun, 22 Nov 1998 20:18:11 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA21586; Sun, 22 Nov 98 20:17:21 EST Received: (qmail 18030 invoked by uid 501); 23 Nov 1998 01:17:27 -0000 Message-Id: <19981122171727.A8836@molehill.org> Date: Sun, 22 Nov 1998 17:17:27 -0800 From: Todd Larason To: Eli Barzilay , scwm-discuss@mit.edu Subject: Re: Compilation problems References: <13912.38707.968124.498974@horus.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <13912.38707.968124.498974@horus.cs.cornell.edu>; from Eli Barzilay on Sun, Nov 22, 1998 at 05:58:59PM -0500 X-Tom-Swifty: "Frankly, my dear, I don't give a damn", said Clark Gable rhetorically. X-Kibo: Let's disappear! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981122, Eli Barzilay wrote: > When I try to ./configure, I got errors trying to find guile. I think that > someone had also a problem with it. Looking in configure.in, I found > dnl FIXJTL: readline is sometimes needed too; hopefully anybody with > dnl a guile with readline support has a working guile-config or build-guile > So I've added > GUILE_LIBS_PRE="${GUILE_LIBS_PRE} -lreadline" > just before that and it fixed it. The installation I have is the guile-1.3-1 > and readline-2.2-4, and I didn't find guile-config anywhere. With Guile 1.3, you should have a 'guile-config' script. That version number looks like an RPM version? The guile-1.3-1 RPM I got from rawhide soon after 1.3 was released doesn't include guile-config. Does anyone have contacts with redhat to get that fixed? I think that this is the right place to fix it - the guile configuration is already complicated enough without trying to support broken installations. If there's interest, I can post the spec file I'm using for guile 1.3. > Another thing is that I modified scwmgtkhelper.c:75 to say scwmgtkhelper.x > instead of scwmgdkhelper.x. This looks like a real bug, I'll check in a fix for it. -- ICQ UIN: 73113888 From owner-scwm-discuss@mit.edu Mon Nov 23 02:18:17 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA27227 for scwm-discuss-outgoing; Mon, 23 Nov 1998 02:18:17 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA27224 for ; Mon, 23 Nov 1998 02:18:12 -0500 Received: from nebula.newtonlabs.com (cwitty@[207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA01139 for ; Sun, 22 Nov 1998 23:17:06 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA18023; Sun, 22 Nov 1998 23:20:31 -0800 Date: Sun, 22 Nov 1998 23:20:31 -0800 Message-Id: <199811230720.XAA18023@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: missing files in install? Sender: owner-scwm-discuss@mit.edu Precedence: bulk The following files from .../scwm/scheme/ are not installed: advice.scm cascade.scm minimal.scm stacking.scm shutdown-opts.scm >From reading the sources, it looks like perhaps minimal.scm should not be installed, but the others should? The first four are not installed because they are missing from Makefile.am; shutdown-opts.scm is not installed because there is a missing backslash in Makefile.am. Carl Witty cwitty@newtonlabs.com Linux nebula 2.0.35 #1 Thu Nov 19 00:04:16 PST 1998 i686 unknown Guile verion: 1.3 Libguile timestamp: Tue Nov 10 21:53:35 PST 1998 SCWM version: 0.9beta1 >From repository date: Sun Nov 22 20:21:22 EST 1998 -- $Revision: 1.934 $ Restarted: true Display Size: 1280x1024 Desk Size: 3x3 Viewport: 0x0 Pointer: 957x460 Current Desk: 0 X vendor: The XFree86 Project, Inc; version: 11.0; release: 3320 X Display: Resolution: 2956x2951 Color: TrueColor (depth: 16; bits per RGB: 6) image-load-path: /usr/X11R6/include/X11/pixmaps usr/X11R6/include/X11/bitmaps /src/icons/icons /src/icons/mini-icons From owner-scwm-discuss@mit.edu Mon Nov 23 06:28:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id GAA29297 for scwm-discuss-outgoing; Mon, 23 Nov 1998 06:28:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id GAA29294 for ; Mon, 23 Nov 1998 06:28:41 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA00276; Mon, 23 Nov 98 06:27:44 EST Received: from licia.dtek.chalmers.se (d4jonas@licia.dtek.chalmers.se [129.16.30.88]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id MAA01795 for ; Mon, 23 Nov 1998 12:27:44 +0100 (MET) Received: (from d4jonas@localhost) by licia.dtek.chalmers.se (8.8.8/8.8.8) id MAA03605; Mon, 23 Nov 1998 12:27:44 +0100 (MET) To: scwm-discuss@mit.edu Subject: SCWMDoc-url X-No-Archive: Yes Mail-Copies-To: never X-Homepage: http://www.dtek.chalmers.se/~d4jonas/index.html Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 23 Nov 1998 12:27:44 +0100 Message-Id: Lines: 9 X-Mailer: Gnus v5.6.38/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In the future SCWMDoc will be found at I removed the old urls I've posted here last week. -- ( Who? Me?: Jonas Steverud ! Wei Wu Wei ) ( My $Home: http://www.dtek.chalmers.se/~d4jonas/ ! To Do Without Do ) From owner-scwm-discuss@mit.edu Mon Nov 23 10:40:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA30738 for scwm-discuss-outgoing; Mon, 23 Nov 1998 10:40:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA30735 for ; Mon, 23 Nov 1998 10:40:06 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA22006; Mon, 23 Nov 98 10:39:16 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id KAA10933 for ; Mon, 23 Nov 1998 10:39:06 -0500 (EST) Message-Id: <199811231539.KAA10933@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: options to window-style. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Nov 1998 10:38:45 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's an FAQ for you: What are the options/keywords to window-style? The manual is not very forthcoming....:-) -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Mon Nov 23 11:27:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31167 for scwm-discuss-outgoing; Mon, 23 Nov 1998 11:27:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA31159; Mon, 23 Nov 1998 11:27:08 -0500 Message-Id: <199811231627.LAA31159@vicarious-existence.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet In-reply-to: Your message of "22 Nov 1998 13:46:45 EST." Date: Mon, 23 Nov 1998 11:27:08 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <36579AD9.62C5364B@alum.mit.edu> > >>>> On the subject of "Re: Red Hat ContribNet" > >>>> Sent on Sun, 22 Nov 1998 05:02:17 +0000 > >>>> Honorable Dale Jordan writes: > >> > >> I would like to add bindings for the "Microsoft" keys for window > >> control functions so as to avoid usurping other keys that Emacs and > >> other programs might use. I have seen a number of posts about ways > >> to do it, but they mostly talk about X modmap and such which I > >> haven't yet mastered. > > use xev to find out the keycode of the key you want to rebind. > then place this into .xmodmaprc: > ------------------------------ > ! Left win key (was Meta_L, Menu) <-- comment > keycode 115 = Hyper_L > ! Right win key (was Meta_R, F19) > keycode 116 = Hyper_R > ! Menu key (right of the Meta_R) > keycode 117 = Super_R > add mod3 = Super_L Super_R > add mod4 = Hyper_L Hyper_R > --------------------------------- > then put command "xmodmap ~/.xmodmaprc" into your ~/.xsession. > now you can use these keys as super and hyper: > (H - hyper, M - meta, C - control, S - shift, s - super). > (bind-key 'all "H-F1" popup-util) > (bind-key 'all "s-F1" popup-util) > > >> Window placement for dialog boxes can be real pain, requiring one to > >> move the mouse across the whole screen. Can scwm intervene in this? > >> How would it know what kind of window is being created? > > these windows satisfy the `transient?' predicate. > there should be a way to tell scwm to use "at-mouse" placement for such > windows, but I don't know how. > Do you mean at-mouse as in placing interactively, or dropping the window wherever the mouse cursor is right now at time of placement? The former: (window-style "*" #:transient-placement-proc interactive-move) The latter: (window-style "*" #:transient-placement-proc ;; this should be provided stock somewhere (lambda (win) (apply move-to (pointer-position) win))) - Maciej Stachowiak From owner-scwm-discuss@mit.edu Mon Nov 23 12:09:04 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA31529 for scwm-discuss-outgoing; Mon, 23 Nov 1998 12:09:04 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA31523 for ; Mon, 23 Nov 1998 12:08:58 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA29778; Mon, 23 Nov 98 12:08:01 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA00758; Mon, 23 Nov 1998 09:07:19 -0800 (PST) To: Maciej Stachowiak Cc: sds@goems.com, scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811231627.LAA31159@vicarious-existence.mit.edu> From: Greg Badros Date: 23 Nov 1998 09:07:19 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 23 Nov 1998 11:27:08 EST" Message-Id: Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Do you mean at-mouse as in placing interactively, or dropping the > window wherever the mouse cursor is right now at time of placement? > > The former: > > (window-style "*" #:transient-placement-proc interactive-move) > > The latter: > > (window-style "*" #:transient-placement-proc > ;; this should be provided stock somewhere > (lambda (win) (apply move-to (pointer-position) win))) The latter's stock implementation should perhaps be parameterized on where in the window the pointer should end up (could permit both % and pixel offsets). Greg From owner-scwm-discuss@mit.edu Mon Nov 23 14:48:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA00097 for scwm-discuss-outgoing; Mon, 23 Nov 1998 14:48:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA00094 for ; Mon, 23 Nov 1998 14:48:35 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA28820; Mon, 23 Nov 98 14:47:32 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA04665 for scwm-discuss@mit.edu; Mon, 23 Nov 1998 20:42:50 +0100 (MET) Received: (qmail 502 invoked by uid 115); 22 Nov 1998 09:56:56 -0000 To: scwm-discuss@mit.edu Subject: Re: Red Hat ContribNet References: <199811191705.MAA07122@huis-clos.mit.edu> <36579AD9.62C5364B@alum.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 22 Nov 1998 10:56:52 +0100 In-Reply-To: Dale Jordan's message of "Sun, 22 Nov 1998 05:02:17 +0000" Message-Id: Lines: 88 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sun, 22 Nov 1998 05:02:17 +0000 >>>>> Dale Jordan said: Dale> I would like to add bindings for the "Microsoft" keys for Dale> window control functions so as to avoid usurping other keys Dale> that Emacs and other programs might use. I have seen a number Dale> of posts about ways to do it, but they mostly talk Dale> about X modmap and such which I haven't yet mastered. I have the "menu" key reserved for scwm. It is done by binding this key to the "Super_R" keycode, adding "Super_R" to your modifier set, and prefixing all of scwm's keybindings with "s-". Following is a step-by-step recipe: 1. Bind the "menu" keycode to "Super_R" xmodmap -e "keycode 117 = Super_R" (117 should work for all PC keyboards with the menu key, but this was only tested on german keyboards.) 2. Find a free modifier bit xmodmap -pm will give you a list of modifier assignments. The output may look like this: xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40) mod2 Num_Lock (0x4d) mod3 Mode_switch (0x71) mod4 mod5 This tells us that Super_R is not assigned to anything (while, for example, Alt_L is assigned to mod1) - so we have to do the assignment. mod4 and mod5 are free. I will choose mod4 in this example; if you have to take another bit, you'll have to modify the following commands. 3. Assign "Super_R" to a modifier bit xmodmap -e "add mod4 = Super_R" (Remember that mod4 is only an example and the right bit must be found out like in step 3). 4. Test it The easiest way to test the new key is probably with Emacs. Type "C-h s" and then Menu-x. You should see S-x runs the command ... or S-x is undefined Other ways to test it use "xev" or scwm itself (see step 6). 5. Make your changes permanent Simply copy the two xmodmap commands from step 1 and 3 into some X startup file of yours (e.g. the one you're starting scwm from). 6. Use your newly gained modifier in scwm Prefixing a key string with "s-" tells scwm that the Super modifier must be pressed. E.g. (bind-key 'all "s-F4" toggle-iconify) will bind Super-F4 to the `toggle-iconify' command. Note that a small "s" stands for Super (because "S" stands for Shift). [If anybody wants to put this into a FAQ file: feel free. Corrections in fact and language are also appreciated.] Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Nov 23 17:04:57 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA00858 for scwm-discuss-outgoing; Mon, 23 Nov 1998 17:04:57 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA00855 for ; Mon, 23 Nov 1998 17:04:19 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA26773; Mon, 23 Nov 98 17:03:21 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id RAA27011 for ; Mon, 23 Nov 1998 17:03:12 -0500 (EST) Message-Id: <199811232203.RAA27011@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: crash switching desks Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Nov 1998 17:02:48 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk I got this crash while switch disks. scwm-0.9beta1, irix 5.3 Script started on Mon Nov 23 16:34:04 1998 $ gdb scwm core.today.scwm GNU gdb 4.17 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mips-sgi-irix5.3"... Core was generated by `scwm'. Program terminated with signal 10, Bus error. Reading symbols from /usr/lib/libXt.so...done. Reading symbols from /usr/lib/libXext.so...done. Reading symbols from /usr/local/lib/libXmu.so...done. Reading symbols from /usr/local/lib/libXpm.so4.10...done. Reading symbols from /usr/lib/libX11.so.1...done. Reading symbols from /usr/local/lib/libguile.so...done. Reading symbols from /usr/local/lib/libqthreads.so...done. Reading symbols from /usr/lib/libdl.so...done. Reading symbols from /usr/lib/libcurses.so...done. Reading symbols from /usr/lib/libm.so...done. Reading symbols from /usr/lib/libc.so.1...done. #0 RestoreWithdrawnLocation (psw=0x7f, fRestart=0) at scwm.c:1218 1218 if (FXGetWindowTopLeft(psw->w, &xwc.x, &xwc.y )) { (gdb) where #0 RestoreWithdrawnLocation (psw=0x7f, fRestart=0) at scwm.c:1218 #1 0x44a538 in Reborder (fRestart=0) at scwm.c:1273 #2 0x44af38 in Done (restart_or_dump=-1, command=0x0) at shutdown.c:75 #3 0x44a6a8 in SigDoneSegv (nonsense=127) at scwm.c:1299 #4 #5 scm_gc_mark (p=528) at gc.c:587 #6 0x5ff77e54 in scm_gc_mark (p=528) at gc.c:671 #7 0x44ed74 in mark_window (obj=269929208) at window.c:410 #8 0x5ff783d8 in scm_gc_mark (p=528) at gc.c:852 #9 0x5ff77e54 in scm_gc_mark (p=528) at gc.c:671 #10 0x5ff77abc in scm_igc (what=0x210
) at gc.c:544 #11 0x5ff777ac in scm_gc_for_alloc (ncells=1, freelistp=0x5ffe0c00) at gc.c:414 #12 0x5ff7793c in scm_gc_for_newcell () at gc.c:427 #13 0x5ff95744 in scm_cons (x=131074, y=10612) at pairs.c:58 #14 0x5ff84070 in scm_listify (elt=528) at list.c:79 #15 0x43fbd0 in Broadcast (event_type=528, num_datum=218, data1=1854, data2=2, data3=269915720, data4=0, data5=463, data6=54, data7=75) at module-interface.c:43 #16 0x43fd3c in BroadcastIconInfo (event_type=528, psw=0x1) at module-interface.c:61 #17 0x44f7d0 in MovePswIconToCurrentPosition (psw=0x10169648) at window.c:587 #18 0x44d090 in MoveViewport_internal (newx=32, newy=1, grab=32) ---Type to continue, or q to quit--- at virtual.c:388 #19 0x412374 in ChangeVirtualPosition (vx=528, vy=1, fGrab=32) at add_window.c:106 #20 0x44d138 in MoveViewport (newx=528, newy=1, grab=32) at virtual.c:403 #21 0x44c7b0 in HandlePaging (HorWarpSize=1280, VertWarpSize=1024, xl=0x1000ebb8, yt=0x1000ebbc, delta_x=0x7fffa9d8, delta_y=0x7fffa9dc, Grab=1) at virtual.c:198 #22 0x42b784 in HandleEnterNotify () at events.c:1313 #23 0x427f90 in DispatchEvent () at events.c:195 #24 0x428020 in HandleEvents () at events.c:217 #25 0x449610 in scwm_main (argc=2, argv=0x7fffaf1c) at scwm.c:986 #26 0x5ff7d900 in gh_launch_pad (closure=0x0, argc=1, argv=0x20) at gh_init.c:60 #27 0x5ff81bf0 in invoke_main_func (body_data=0x7fffaea0) at init.c:539 #28 0x5ffc2140 in scm_internal_lazy_catch (tag=9076, body=0x5ff81b94 , body_data=0x7fffaea0, handler=0, handler_data=0x0) at throw.c:328 #29 0x5ff81b1c in scm_boot_guile_1 (base=0x7fffaeb0, closure=0x7fffaea0) at init.c:513 #30 0x5ff8129c in scm_boot_guile (argc=528, argv=0x1, main_func=0x20, closure=0x0) at init.c:378 #31 0x5ff7d95c in gh_enter (argc=528, argv=0x1, c_main_prog=0) at gh_init.c:70 #32 0x447ccc in main (argc=528, argv=0x1) at scwm.c:464 (gdb) quit $ ^D script done on Mon Nov 23 16:34:27 1998 From owner-scwm-discuss@mit.edu Mon Nov 23 17:09:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA00882 for scwm-discuss-outgoing; Mon, 23 Nov 1998 17:09:52 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA00879 for ; Mon, 23 Nov 1998 17:09:26 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA28595; Mon, 23 Nov 98 17:08:29 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id RAA27189 for ; Mon, 23 Nov 1998 17:08:26 -0500 (EST) Message-Id: <199811232208.RAA27189@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: sticky not for icons Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Nov 1998 17:08:06 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Using scwm-0.9beta1 under irix 5.3 I made an iconified xterm sticky using the menu created by system.scwmrc. I switched desks from 1 to 2. The xterm was not there. The titlebar looks scalloped, which means sticky. And the menu now says unstick. Isn't the icon supposed to follow desk switches? The apps marked as desktools do. -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Mon Nov 23 17:39:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA01175 for scwm-discuss-outgoing; Mon, 23 Nov 1998 17:39:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA01172 for ; Mon, 23 Nov 1998 17:39:23 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA04837; Mon, 23 Nov 98 17:38:22 EST Received: (qmail 8854 invoked by uid 501); 23 Nov 1998 22:38:26 -0000 Message-Id: <19981123143826.A8791@molehill.org> Date: Mon, 23 Nov 1998 14:38:26 -0800 From: Todd Larason To: Arturo Perez , scwm-discuss@mit.edu Subject: Re: crash switching desks References: <199811232203.RAA27011@ns1.infonautics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811232203.RAA27011@ns1.infonautics.com>; from Arturo Perez on Mon, Nov 23, 1998 at 05:02:48PM -0500 X-Tom-Swifty: "I'm such a good marksman that you can throw away your hairbrush", was Tom's parting shot. X-Kibo: Existence makes sense. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981123, Arturo Perez wrote: > #0 RestoreWithdrawnLocation (psw=0x7f, fRestart=0) at scwm.c:1218 ^^^^^^^^ is obviously bad. > #1 0x44a538 in Reborder (fRestart=0) at scwm.c:1273 Reborder walks the psw list, so it's evidentally corrupt by this point > #2 0x44af38 in Done (restart_or_dump=-1, command=0x0) at shutdown.c:75 > #3 0x44a6a8 in SigDoneSegv (nonsense=127) at scwm.c:1299 ack! > #4 > #5 scm_gc_mark (p=528) at gc.c:587 > #6 0x5ff77e54 in scm_gc_mark (p=528) at gc.c:671 > #7 0x44ed74 in mark_window (obj=269929208) at window.c:410 Anybody able to easily decode obj and see if it's reasoanble? If it's just a pointer, tag bits 0 (or low bits?), then it's close but not equal to the psw further down. > #12 0x5ff7793c in scm_gc_for_newcell () at gc.c:427 > #13 0x5ff95744 in scm_cons (x=131074, y=10612) at pairs.c:58 > #14 0x5ff84070 in scm_listify (elt=528) at list.c:79 > #15 0x43fbd0 in Broadcast (event_type=528, num_datum=218, data1=1854, data2=2, > data3=269915720, data4=0, data5=463, data6=54, data7=75) > at module-interface.c:43 > #16 0x43fd3c in BroadcastIconInfo (event_type=528, psw=0x1) > at module-interface.c:61 psw is bad here, too > #17 0x44f7d0 in MovePswIconToCurrentPosition (psw=0x10169648) at window.c:587 but okay here, and it should have been passed straight through What version are you using? The line numbers don't line up well with the snapshot I'm lokoing at, it may be that it's already been fixed. -- ICQ UIN: 81662086 From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01541 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01538 for ; Mon, 23 Nov 1998 18:28:41 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20804; Mon, 23 Nov 98 18:27:40 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11380 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:08 +0100 (MET) Received: (qmail 1376 invoked by uid 115); 23 Nov 1998 20:01:03 -0000 To: scwm-discuss@mit.edu Subject: Re: Window placement broken? References: X-Attribution: Robbe From: Robert Bihlmeyer Date: 21 Nov 1998 14:39:40 +0100 In-Reply-To: Greg Badros's message of "20 Nov 1998 15:22:00 -0800" Message-Id: Lines: 22 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 20 Nov 1998 15:22:00 -0800 >>>>> Greg Badros said: Greg> in 0.9 beta 1, window placement seems broken -- all my windows Greg> get thrown up at 0,0 of the current viewport. I'm using Greg> gjb.scwmrc, of course. Greg> Are there changes I should've noticed that would explain this? SM plays with the window positions. But it should do nothing if not active. You mean that your `placement-proc's are ignored, right? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --KAB26989.911725647/relay8.Austria.EU.net-- From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01546 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01543 for ; Mon, 23 Nov 1998 18:28:46 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20823; Mon, 23 Nov 98 18:27:46 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11382 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:10 +0100 (MET) Received: (qmail 21698 invoked by uid 115); 23 Nov 1998 23:14:50 -0000 To: scwm-discuss@mit.edu Subject: Re: Two bugs References: <19981123015312.A8189@forcix.roof.lan> X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 24 Nov 1998 00:14:47 +0100 In-Reply-To: forcer's message of "Mon, 23 Nov 1998 01:53:12 +0100" Message-Id: Lines: 31 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 23 Nov 1998 01:53:12 +0100 >>>>> forcer said: forcer> On Sun, Nov 22, 1998 at 08:18:37PM +0000, Craig Struble forcer> wrote: >> The second bug is that smart window placement no longer seems to >> work. All of my windows without explicit geometry settings are >> showing up at 0,0. forcer> Just as a note: Neither does click-to-place. Seems like forcer> there's some check missing or wrong. :) Shiver me timbers! Someone put an "extern Bool PPosOverride" into placement.c while PPosOverride is really defined as a "Boolean". If I tell you that Bool is equivalent to int and Boolean is equivalent to char, you'll be able to imagine the rest of the story. I have now replaced the few occurances of "Boolean" in scwm code with "Bool" as a stop-gap-measure. The placement functions work as expected now. Checkin will be done in about ten hours, so this will probably not yet be in the next snapshot. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01551 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01548 for ; Mon, 23 Nov 1998 18:28:48 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20829; Mon, 23 Nov 98 18:27:48 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11373 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:03 +0100 (MET) Received: (qmail 1338 invoked by uid 115); 23 Nov 1998 20:00:01 -0000 To: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811192205.RAA10723@vicarious-existence.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 13:00:11 +0100 In-Reply-To: Maciej Stachowiak's message of "Thu, 19 Nov 1998 17:05:48 EST" Message-Id: Lines: 27 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 19 Nov 1998 17:05:48 EST >>>>> Maciej Stachowiak said: Maciej> Is there any way to find what client a window belongs to, or Maciej> specifically for a client to check if a given window was Maciej> created by itself? I don't think there is an easy way to get this mapping. You could of course do some manual bookkeeping (e.g. remember the windows you created yourself; or set special properties on them). Maciej> I ask because the only major scwm/guile-gtk stability problem Maciej> remaining that I am aware of is that if you `destroy-window' Maciej> a scwm/guile-gtk created window, scwm XKillClient()s itself, Maciej> which is clearly a bad thing. What about creating another connection to the X server for the gtk stuff? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --KAC26989.911725650/relay8.Austria.EU.net-- From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01531 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01528 for ; Mon, 23 Nov 1998 18:28:37 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20774; Mon, 23 Nov 98 18:27:35 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11381 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:09 +0100 (MET) Received: (qmail 20463 invoked by uid 115); 23 Nov 1998 22:24:57 -0000 To: scwm-discuss@mit.edu Subject: shaped pie menus X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 23 Nov 1998 23:24:53 +0100 Message-Id: Lines: 15 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, these are wierd but fun (thanks to Todd - and Russell!). Only two nits: Seperators seem to produce thin vertical artifacts. There should be at least some border (maybe 3D) around the items to set them off the background. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01536 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01533 for ; Mon, 23 Nov 1998 18:28:39 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20785; Mon, 23 Nov 98 18:27:39 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11379 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:07 +0100 (MET) Received: (qmail 1369 invoked by uid 115); 23 Nov 1998 20:00:52 -0000 To: scwm-discuss@mit.edu Subject: Re: a documentation "bug" References: <19981120225126Z276553-384+34@pulsar.halcyon.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 21 Nov 1998 14:37:27 +0100 In-Reply-To: Ken Pizzini's message of "Fri, 20 Nov 1998 14:51:26 -0800" Message-Id: Lines: 16 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 20 Nov 1998 14:51:26 -0800 >>>>> Ken Pizzini said: Ken> I was trying to figure out a way to make one _already_existing_ Ken> menu become a pie menu. `set-menu-menu-look!' is the function you want. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --KAA26989.911725646/relay8.Austria.EU.net-- From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01566 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01563 for ; Mon, 23 Nov 1998 18:28:53 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20848; Mon, 23 Nov 98 18:27:53 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11372 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:02 +0100 (MET) Received: (qmail 1362 invoked by uid 115); 23 Nov 1998 20:00:38 -0000 To: scwm-discuss@mit.edu Subject: Re: Minor bugs References: X-Attribution: Robbe From: Robert Bihlmeyer Date: 21 Nov 1998 14:36:04 +0100 In-Reply-To: "Craig A. Struble"'s message of "Thu, 19 Nov 1998 09:56:17 -0500 (EST)" Message-Id: Lines: 61 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 19 Nov 1998 09:56:17 -0500 (EST) >>>>> "Craig A. Struble" said: Craig> Check my second message about this. I wasn't explicit enough Craig> in my statement of menus. I should have said application menus Craig> (e.g. Netscape, xsm, and Tcl/Tk applications too). Yes, I can see this, too. A perhaps related datapoint: `keep-on-top' a window. Now `lower-window' it. It will flash briefly but stay on top - looks like it being put to the bottom and immediately brought up again, akin to the menu behaviour. Subsequent attempts to `lower-window' it work. (Not sure whether lowering a kept-on-top window should be possible at all.) I also found this while digging in the code: /* FIXMS darn, this is not going to do what we want it to -- must start keeping a general stays on top flag as well a currently on top flag in the window struct, only the latter of which is changed by raises and lowers. */ It looks like the diverse flag-waving does not work in some cases. Can someone shed light on the original design? [session management] Craig> I'll get back to you on this with hard numbers. Just guessing, Craig> it appears that the window is getting resized by its border Craig> width and height, which I found surprising when I read in the Craig> Changelog that it was now handled properly. Well that was probably an euphemism. It works correctly with the styles I tested it with. Craig> Actually, come to think of it, the sizing was fine BEFORE that Craig> change existed. Aaargh. Craig> The window itself has no titlebar. Ah, I see. title_height is bogus when the window has no titlebar. Ok, I will commit the fix ASAP. Craig> I need to hack on smproxy to include the proper patches for Craig> scwm and also to figure out why it crashes every time I run Craig> Netscape. Just keep them bug reports flowing! Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --KAF26989.911725653/relay8.Austria.EU.net-- From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01561 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:52 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01558 for ; Mon, 23 Nov 1998 18:28:51 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20837; Mon, 23 Nov 98 18:27:51 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11378 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:06 +0100 (MET) Received: (qmail 1355 invoked by uid 115); 23 Nov 1998 20:00:16 -0000 To: scwm-discuss@mit.edu Subject: Re: Dynamic setting of desk for window when title changes. References: <19981120103212.C7014@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 12:07:27 +0100 In-Reply-To: Greg Badros's message of "20 Nov 1998 10:37:50 -0800" Message-Id: Lines: 45 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 20 Nov 1998 10:37:50 -0800 >>>>> Greg Badros said: Greg> Todd Larason writes: >> ick! And have more than one emacs running? Greg> Hell yes... until Emacs is multi-threaded, having multiple Greg> makes sense (esp. when one is basically just running gnus as a Greg> mail reader) That's unfortunately a no-no on machines where running *one* 10 MB+ process is getting sneered at. >> Couldn't this be done with a hook on X-PropertyNotify-hook? No, X-PropertyNotify-hook is not called for properties that scwm uses itself. Should I consider this a bug? This could be a useful hook to hang to, although I think it is not the prettiest solution: SCWM_HOOK(broadcast_name_hook, "broadcast-name-hook"); /** This hook is invoked whenever fvwm2 would call BroadcastName. This hook is principally of use in implementing the fvwm2 module interface and for stuff that needs to be notified in ways that can't be done with the proper hooks that have been included so far. The procedures in this hook are passed an event type, three numeric data arguments, and a string. */ Greg> I doubt one would want the window to move when "gnus" starts Greg> up... that'd be confusing as heck. Jonas wanted to do just that (IIUC), so it should be possible. Using the resource name is not possible here, as it can not be changed after window creation. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Nov 23 18:28:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01556 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:28:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01553 for ; Mon, 23 Nov 1998 18:28:50 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20832; Mon, 23 Nov 98 18:27:49 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id AAA11377 for scwm-discuss@mit.edu; Tue, 24 Nov 1998 00:16:05 +0100 (MET) Received: (qmail 1348 invoked by uid 115); 23 Nov 1998 20:00:06 -0000 To: scwm-discuss@mit.edu Subject: Re: Moving mouse with arrows and menues in netscape References: <19981120000137.A2901@molehill.org> <19981120100913.A7014@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 21 Nov 1998 13:45:39 +0100 In-Reply-To: Jonas Steverud's message of "20 Nov 1998 19:21:20 +0100" Message-Id: Lines: 27 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Now-Playing: 01 - Mars, The Bringer of War Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 20 Nov 1998 19:21:20 +0100 >>>>> Jonas Steverud said: Jonas> Nestcape is a all-time favorite for a bad-program-example so I Jonas> might have done you a misfavour by using it in a bugreport... Jonas> ;-) I can reproduce this with Netscape Lit 4.04. It seems not to happen with XEmacs or GTK applications. Maybe Motif is the culprit? Indeed, all Motif applications I have tested (NS and a couple of demos) show this behaviour. We should probably all pray for Motif to die painlessly. Jonas> The interressting thing is that it was the same problem for Jonas> show-window-list-menu too. That's an unrelated misfeature that Todd explained in some detail. Will be gone after the Great Event Rewrite. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! --KAD26989.911725651/relay8.Austria.EU.net-- From owner-scwm-discuss@mit.edu Mon Nov 23 18:39:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01703 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:39:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01700 for ; Mon, 23 Nov 1998 18:39:25 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA23584; Mon, 23 Nov 98 18:38:24 EST Received: (qmail 9378 invoked by uid 501); 23 Nov 1998 23:38:28 -0000 Message-Id: <19981123153828.A9295@molehill.org> Date: Mon, 23 Nov 1998 15:38:28 -0800 From: Todd Larason To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: shaped pie menus References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Robert Bihlmeyer on Mon, Nov 23, 1998 at 11:24:53PM +0100 X-Tom-Swifty: "Why are you writing elegies at THIS hour? You should be in bed, young lady", the curfew told Nell. X-Kibo: Bright sane ideas for today's lifestyle are old. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981123, Robert Bihlmeyer wrote: > these are wierd but fun (thanks to Todd - and Russell!). Only two nits: Russell! I just checked the patch in. > There should be at least some border (maybe 3D) around the items to > set them off the background. I have a background pixmap set for menus, which looked pretty good in my limited testing. Maybe that's good enough? -- ICQ UIN: 96170292 From owner-scwm-discuss@mit.edu Mon Nov 23 18:40:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA01715 for scwm-discuss-outgoing; Mon, 23 Nov 1998 18:40:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA01712 for ; Mon, 23 Nov 1998 18:40:13 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA23754; Mon, 23 Nov 98 18:39:11 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id PAA23854; Mon, 23 Nov 1998 15:39:14 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id PAA17357; Mon, 23 Nov 1998 15:39:13 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811192205.RAA10723@vicarious-existence.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 23 Nov 1998 15:39:13 -0800 In-Reply-To: Maciej Stachowiak's message of "Thu, 19 Nov 1998 17:05:48 EST" Message-Id: Lines: 17 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Is there any way to find what client a window belongs to, or > specifically for a client to check if a given window was created by > itself? I ask because the only major scwm/guile-gtk stability problem > remaining that I am aware of is that if you `destroy-window' a > scwm/guile-gtk created window, scwm XKillClient()s itself, which is > clearly a bad thing. If you can't find a good solution, I have an annoying solution to suggest. Gtk keeps an internal mapping of window ID's to gtk window objects. As far as I could tell, this mapping is not supposed to be available to gtk clients, but you might be able to figure out some way to get at it. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Nov 23 19:09:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA01939 for scwm-discuss-outgoing; Mon, 23 Nov 1998 19:09:08 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id TAA01936 for ; Mon, 23 Nov 1998 19:09:07 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id TAA25252 for ; Mon, 23 Nov 1998 19:08:12 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id TAA12379 for ; Mon, 23 Nov 1998 19:08:11 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id TAA10630 for ; Mon, 23 Nov 1998 19:08:54 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Tue, 24 Nov 1998 00:08:53 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Compilation bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I found a bug in draw-xpm-menu.c when compiling with debugging messages on. The patch is below. (BTW, I'm just using cvs diff for these, but I'm sure somewhere in the archive other options were specified. Could someone put the preferred diff options in BUG-REPORTING or HACKING?) See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu Index: draw-xpm-menu.c =================================================================== RCS file: /anoncvs/scwm/modules/xpm-menus/draw-xpm-menu.c,v retrieving revision 1.8 diff -r1.8 draw-xpm-menu.c 412c412 < #define FUNC_NAME "PaintMenuItem"; --- > #define FUNC_NAME "PaintMenuItem" From owner-scwm-discuss@mit.edu Mon Nov 23 19:17:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA02027 for scwm-discuss-outgoing; Mon, 23 Nov 1998 19:17:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA02022 for ; Mon, 23 Nov 1998 19:17:06 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02176; Mon, 23 Nov 98 19:16:01 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA01575; Mon, 23 Nov 1998 16:16:02 -0800 (PST) To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: Compilation bug References: From: Greg Badros Date: 23 Nov 1998 16:16:02 -0800 In-Reply-To: Craig Struble's message of "Tue, 24 Nov 1998 00:08:53 +0000 ()" Message-Id: Lines: 17 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig Struble writes: > I found a bug in draw-xpm-menu.c when compiling with debugging messages > on. The patch is below. (BTW, I'm just using cvs diff for these, but I'm > sure somewhere in the archive other options were specified. Could someone > put the preferred diff options in BUG-REPORTING or HACKING?) I just added it to both, though any kind of context-preserving diff is fine; my recommendation is: diff -ub for unified diffs, ignoring whitespace differences. Thanks for the patch! Greg From owner-scwm-discuss@mit.edu Mon Nov 23 19:54:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA02448 for scwm-discuss-outgoing; Mon, 23 Nov 1998 19:54:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA02445 for ; Mon, 23 Nov 1998 19:54:07 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA14126; Mon, 23 Nov 98 19:53:13 EST Received: (qmail 15579 invoked by uid 0); 24 Nov 1998 00:53:41 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 24 Nov 1998 00:53:41 -0000 Received: (qmail 23516 invoked by uid 501); 24 Nov 1998 00:53:38 -0000 Date: 24 Nov 1998 00:53:38 -0000 Message-Id: <19981124005338.23515.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Re: shaped pie menus In-Reply-To: References: X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q these are wierd but fun (thanks to Todd - and Russell!). Only two nits: > > Seperators seem to produce thin vertical artifacts. I've got another fix for that -- skip the code which includes the separators in the shape. They're being drawn as zero-width menu items, but a border is being added. > There should be at least some border (maybe 3D) around the items to > set them off the background. Yes, agreed. There's also several operational problems (which Todd and I agree exist): 1) The pie menu should be drawn where the user first clicked, and pie segment calculations should be based on that. 2) The pies should extend into infinity. 3) The shaped pies are only activated when you hit the label. 4) The cursor needs to be warped into the middle of the menu if the center of the menu has been moved. 5) There should be a dead spot in the middle of the menu so you can click, select an item, and go back to the middle to unselect. 6) The shaped pies are calculated as being too big, so they get moved away from the edges unnecessarily. 7) The current code pops up a submenu even if the user hasn't clicked. This doesn't work well with pie menus. You want to always do click, drag, release, click, drag, release. Otherwise you go from a line segment menu to a path menu. I think #2 and #3 can be addressed by doing a global grab. I also think the menu title either shouldn't exist, or should float above the menu. No reason to waste a menu item on the title. Or else, no, you could put the most commonly-used menu item in the *middle*, so that a simple click/release pair gives you that item. A menu cancel would need a click/drag-up/release triple. -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Mon Nov 23 20:10:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA02610 for scwm-discuss-outgoing; Mon, 23 Nov 1998 20:10:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA02607 for ; Mon, 23 Nov 1998 20:10:17 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA14617; Mon, 23 Nov 98 20:09:15 EST Received: (qmail 9976 invoked by uid 501); 24 Nov 1998 01:09:21 -0000 Message-Id: <19981123170920.A9911@molehill.org> Date: Mon, 23 Nov 1998 17:09:20 -0800 From: Todd Larason To: Russell Nelson , scwm-discuss@mit.edu Subject: Re: shaped pie menus References: <19981124005338.23515.qmail@desk.crynwr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <19981124005338.23515.qmail@desk.crynwr.com>; from Russell Nelson on Tue, Nov 24, 1998 at 12:53:38AM -0000 X-Tom-Swifty: "I wonder what sex that cat is", said Tom. X-Kibo: Let's work! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981124, Russell Nelson wrote: > 6) The shaped pies are calculated as being too big, so they get moved > away from the edges unnecessarily. I didn't know about this one. Is it true in the version I checked in? I can see how it would have been in your version, which overloaded circle-pie-menu-look, since that style does add a border not needed for this style. > I also think the menu title either shouldn't exist, or should float > above the menu. No reason to waste a menu item on the title. This has been on my list for ages now. I got halfway through fixing the title support, and haven't had enough time for scwm all in one block since to finish it. Someone (Robbe?) suggested putting the title in the center. I was planning on experimenting with this, and with a separate title bar above the menu, and seeing which seemed to work better. -- ICQ UIN: 2842992 From owner-scwm-discuss@mit.edu Mon Nov 23 21:04:56 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA02988 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:04:56 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA02985 for ; Mon, 23 Nov 1998 21:04:55 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA28895; Mon, 23 Nov 98 21:04:01 EST Received: (qmail 16981 invoked by uid 0); 24 Nov 1998 02:04:23 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 24 Nov 1998 02:04:23 -0000 Received: (qmail 24934 invoked by uid 501); 24 Nov 1998 02:04:19 -0000 Date: 24 Nov 1998 02:04:19 -0000 Message-Id: <19981124020419.24933.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Todd Larason Cc: Russell Nelson , scwm-discuss@mit.edu Subject: Re: shaped pie menus In-Reply-To: <19981123170920.A9911@molehill.org> References: <19981124005338.23515.qmail@desk.crynwr.com> <19981123170920.A9911@molehill.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q On 981124, Russell Nelson wrote: > > 6) The shaped pies are calculated as being too big, so they get moved > > away from the edges unnecessarily. > > I didn't know about this one. Is it true in the version I checked in? I can > see how it would have been in your version, which overloaded > circle-pie-menu-look, since that style does add a border not needed for this > style. Hehe. No, it wouldn't be true in the version you checked in. > Someone (Robbe?) suggested putting the title in the center. I was planning on > experimenting with this, and with a separate title bar above the menu, and > seeing which seemed to work better. I like the way piewm does it, with a title bar above the menu. -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Mon Nov 23 21:18:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03078 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:18:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03075 for ; Mon, 23 Nov 1998 21:18:24 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA28289; Mon, 23 Nov 98 21:17:22 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id VAA31413 for ; Mon, 23 Nov 1998 21:17:21 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Finding what client a Window belongs to References: <199811192205.RAA10723@vicarious-existence.mit.edu> Date: 23 Nov 1998 21:17:14 -0500 Message-Id: <5lzp9hzvf9.fsf@tequila.cs.yale.edu> Lines: 15 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 23 Nov 1998 21:17:14 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: > Is there any way to find what client a window belongs to, or > specifically for a client to check if a given window was created by > itself? I ask because the only major scwm/guile-gtk stability problem > remaining that I am aware of is that if you `destroy-window' a > scwm/guile-gtk created window, scwm XKillClient()s itself, which is > clearly a bad thing. Excuse me for asking a stupid question (I have zero knowledge of Xwindows programming apart from hacking a fancy StayOnTop feature int ctwm), but don't you have already somewhere in scwm a way to map a window-ID to an scwm object ? Stefan "trying to understand the question a little better" From owner-scwm-discuss@mit.edu Mon Nov 23 21:29:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03198 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:29:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03195 for ; Mon, 23 Nov 1998 21:29:03 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA03620; Mon, 23 Nov 98 21:28:08 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10881; Mon, 23 Nov 1998 21:28:06 -0500 Message-Id: <199811240228.VAA10881@w20-575-39.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "21 Nov 1998 13:00:11 +0100." Date: Mon, 23 Nov 1998 21:28:05 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > Hi, > > >>>>> On Thu, 19 Nov 1998 17:05:48 EST > >>>>> Maciej Stachowiak said: > > Maciej> Is there any way to find what client a window belongs to, or > Maciej> specifically for a client to check if a given window was > Maciej> created by itself? > > I don't think there is an easy way to get this mapping. You could of > course do some manual bookkeeping (e.g. remember the windows you > created yourself; or set special properties on them). > This is a problem for the guile-gtk-created ones since I am trying my best not to have to modify guile-gtk to work with scwm. > Maciej> I ask because the only major scwm/guile-gtk stability problem > Maciej> remaining that I am aware of is that if you `destroy-window' > Maciej> a scwm/guile-gtk created window, scwm XKillClient()s itself, > Maciej> which is clearly a bad thing. > > What about creating another connection to the X server for the gtk > stuff? > It _does_ create another connection to the X server. It's indeed possible to have the XIOErrorHandler not bail out if the connection being closed is not scwm's main one, but I'm still not sure killing the whole guile-gtk subsystem if you `destroy-window' any guile-gtk window would be good. I guess it is still better than killing the window manager. What I am going to do for now is make all the guile-gtk scwm applets have a resource class of "scwm", check for this explicitly in the destroy operator, and do a delete instead in that case. It's a kludge but I don't see a better way to deal. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:35:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03268 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:35:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03265 for ; Mon, 23 Nov 1998 21:35:09 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA04743; Mon, 23 Nov 98 21:34:14 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10900; Mon, 23 Nov 1998 21:34:13 -0500 Message-Id: <199811240234.VAA10900@w20-575-39.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Minor bugs In-Reply-To: Your message of "21 Nov 1998 14:36:04 +0100." Date: Mon, 23 Nov 1998 21:34:12 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > Yes, I can see this, too. > > A perhaps related datapoint: `keep-on-top' a window. Now > `lower-window' it. It will flash briefly but stay on top - looks like > it being put to the bottom and immediately brought up again, akin to > the menu behaviour. Subsequent attempts to `lower-window' it work. > > (Not sure whether lowering a kept-on-top window should be possible at > all.) > > I also found this while digging in the code: > > /* FIXMS darn, this is not going to do what we want it to -- must > start keeping a general stays on top flag as well a currently on > top flag in the window struct, only the latter of which is > changed by raises and lowers. */ > > It looks like the diverse flag-waving does not work in some cases. Can > someone shed light on the original design? The original fvwm2 behavior is that if you lower a stays-on-top window explicitly, it will stop staying on top until you raise it again. This can be useful if, e.g. you want to get a pager out of the way temporarily, but I am not sure it is good design overall, nor am I sure we implement it correctly. I just replicated the above described menu behavior with Emacs's menus, and it is definitely annoying and wrong - Emacs's menus are OverrideRedirect so we have no business changing the stacking order when they pop up. The relevant code is somewhat hairy unfortunately. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:36:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03293 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:36:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03289 for ; Mon, 23 Nov 1998 21:36:15 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA01663; Mon, 23 Nov 98 21:35:14 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10915; Mon, 23 Nov 1998 21:35:18 -0500 Message-Id: <199811240235.VAA10915@w20-575-39.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: shaped pie menus In-Reply-To: Your message of "23 Nov 1998 23:24:53 +0100." Date: Mon, 23 Nov 1998 21:35:18 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > Hi, > > these are wierd but fun (thanks to Todd - and Russell!). Only two nits: > Sounds like something we need a screenshot of! :-) - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:39:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03329 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:39:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03326 for ; Mon, 23 Nov 1998 21:39:17 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA02249; Mon, 23 Nov 98 21:38:16 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10935; Mon, 23 Nov 1998 21:38:21 -0500 Message-Id: <199811240238.VAA10935@w20-575-39.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "23 Nov 1998 15:39:13 PST." Date: Mon, 23 Nov 1998 21:38:20 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Maciej Stachowiak writes: > > > Is there any way to find what client a window belongs to, or > > specifically for a client to check if a given window was created by > > itself? I ask because the only major scwm/guile-gtk stability problem > > remaining that I am aware of is that if you `destroy-window' a > > scwm/guile-gtk created window, scwm XKillClient()s itself, which is > > clearly a bad thing. > > If you can't find a good solution, I have an annoying solution to > suggest. Gtk keeps an internal mapping of window ID's to gtk window > objects. As far as I could tell, this mapping is not supposed to be > available to gtk clients, but you might be able to figure out some way > to get at it. > Aha! That's pretty dirty but it sounds less broken than my ideas so far. I think it is generally possible (if perhaps evil) to access private gtk/gdk data structures by #including the proper private header. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:45:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03461 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:45:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03458 for ; Mon, 23 Nov 1998 21:45:27 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA03463; Mon, 23 Nov 98 21:44:25 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10960; Mon, 23 Nov 1998 21:44:30 -0500 Message-Id: <199811240244.VAA10960@w20-575-39.mit.edu> To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: Compilation bug In-Reply-To: Your message of "Tue, 24 Nov 1998 00:08:53 GMT." Date: Mon, 23 Nov 1998 21:44:30 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > I found a bug in draw-xpm-menu.c when compiling with debugging messages > on. The patch is below. (BTW, I'm just using cvs diff for these, but I'm > sure somewhere in the archive other options were specified. Could someone > put the preferred diff options in BUG-REPORTING or HACKING?) > Excellent idea! The problem is that some of us have different preferences. I prefer `diff -uB', some other scwm developers prefer context diffs, though I think. If we could agree on preferred formats per directory, I think that would be best. If other people have different preferences, I'll try to work them out and figure out a way to get it all into "HACKING". - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:47:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03531 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:47:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03528 for ; Mon, 23 Nov 1998 21:47:44 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA03851; Mon, 23 Nov 98 21:46:42 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA10968; Mon, 23 Nov 1998 21:46:46 -0500 Message-Id: <199811240246.VAA10968@w20-575-39.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: Compilation bug In-Reply-To: Your message of "23 Nov 1998 16:16:02 PST." Date: Mon, 23 Nov 1998 21:46:46 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Craig Struble writes: > > > I found a bug in draw-xpm-menu.c when compiling with debugging messages > > on. The patch is below. (BTW, I'm just using cvs diff for these, but I'm > > sure somewhere in the archive other options were specified. Could someone > > put the preferred diff options in BUG-REPORTING or HACKING?) > > I just added it to both, though any kind of context-preserving diff is > fine; my recommendation is: > > diff -ub > > for unified diffs, ignoring whitespace differences. I was reading the diff info page, and thinking about it a bit more, I think -B (ignore adding or removing blank lines) is a good idea but -b is potentially dangerous because whitespace differences in double-quoted strings are definitely significant. Should we just put a warning not to use this behavior if your patch has meaningful whitespace changes? - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 21:59:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA03775 for scwm-discuss-outgoing; Mon, 23 Nov 1998 21:59:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA03772 for ; Mon, 23 Nov 1998 21:59:32 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA06111; Mon, 23 Nov 98 21:58:24 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id VAA11063; Mon, 23 Nov 1998 21:58:29 -0500 Message-Id: <199811240258.VAA11063@w20-575-39.mit.edu> To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "23 Nov 1998 21:17:14 EST." <5lzp9hzvf9.fsf@tequila.cs.yale.edu> Date: Mon, 23 Nov 1998 21:58:29 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk monnier+lists/scwm/discuss/news/@tequila.cs.yale.edu writes: > >>>>> "Maciej" == Maciej Stachowiak writes: > > Is there any way to find what client a window belongs to, or > > specifically for a client to check if a given window was created by > > itself? I ask because the only major scwm/guile-gtk stability problem > > remaining that I am aware of is that if you `destroy-window' a > > scwm/guile-gtk created window, scwm XKillClient()s itself, which is > > clearly a bad thing. > > Excuse me for asking a stupid question (I have zero knowledge of Xwindows > programming apart from hacking a fancy StayOnTop feature int ctwm), but > don't you have already somewhere in scwm a way to map a window-ID to an > scwm object ? > Yes, but that is not helpful. There is a scwm window object for every managed window, whether or not it was created by scwm. The problem comes up when scwm, through guile-gtk, creates its own client windows. It then needs to distinguish these from random other client windows so that it does not improperly kill itself when destroying one of these. (When scwm does `destroy-window' on a window, it calls XKillClient on the client program that created it, with obvious results. When that program is scwm itself, the result is an unfortunate window manager crash.) - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 22:35:45 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA04190 for scwm-discuss-outgoing; Mon, 23 Nov 1998 22:35:45 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA04187 for ; Mon, 23 Nov 1998 22:35:42 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA12813; Mon, 23 Nov 98 22:34:35 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id TAA28477; Mon, 23 Nov 1998 19:34:24 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id TAA19418; Mon, 23 Nov 1998 19:34:23 -0800 To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240228.VAA10881@w20-575-39.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 23 Nov 1998 19:34:23 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 23 Nov 1998 21:28:05 EST" Message-Id: Lines: 31 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > robbe@orcus.priv.at writes: > > What about creating another connection to the X server for the gtk > > stuff? > > It _does_ create another connection to the X server. It's indeed > possible to have the XIOErrorHandler not bail out if the connection > being closed is not scwm's main one, but I'm still not sure killing > the whole guile-gtk subsystem if you `destroy-window' any guile-gtk > window would be good. I'm actually not sure that it is possible to avoid exiting. From the XSetIOErrorHandler man page: > This is assumed to be a fatal condition, and the called routine should > not return. If the I/O error handler does return, the client process > exits. >From the Xlib source (from XFree86 3.3.2.3a): if (_XIOErrorFunction != NULL) (*_XIOErrorFunction)(dpy); else _XDefaultIOError(dpy); exit (1); Maybe you could longjmp() out? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Mon Nov 23 22:52:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA04392 for scwm-discuss-outgoing; Mon, 23 Nov 1998 22:52:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA04389 for ; Mon, 23 Nov 1998 22:52:45 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA19449; Mon, 23 Nov 98 22:51:50 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id WAA11259; Mon, 23 Nov 1998 22:51:48 -0500 Message-Id: <199811240351.WAA11259@w20-575-39.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "23 Nov 1998 19:34:23 PST." Date: Mon, 23 Nov 1998 22:51:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > > From the Xlib source (from XFree86 3.3.2.3a): > > if (_XIOErrorFunction != NULL) > (*_XIOErrorFunction)(dpy); > else > _XDefaultIOError(dpy); > exit (1); > > Maybe you could longjmp() out? > Maybe, but longjmp()ing across arbitrary unknown code is a bad thing. Looking at Gtk internal data structures seems downright tidy by comparison. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 22:58:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA04461 for scwm-discuss-outgoing; Mon, 23 Nov 1998 22:58:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA04458 for ; Mon, 23 Nov 1998 22:58:11 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA20571; Mon, 23 Nov 98 22:57:16 EST Received: (qmail 21100 invoked by uid 0); 24 Nov 1998 03:57:38 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 24 Nov 1998 03:57:38 -0000 Received: (qmail 27599 invoked by uid 501); 24 Nov 1998 03:57:34 -0000 Date: 24 Nov 1998 03:57:34 -0000 Message-Id: <19981124035734.27598.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Maciej Stachowiak Cc: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: shaped pie menus In-Reply-To: <199811240235.VAA10915@w20-575-39.mit.edu> References: <199811240235.VAA10915@w20-575-39.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q > these are wierd but fun (thanks to Todd - and Russell!). Only two nits: > > Sounds like something we need a screenshot of! :-) Nahhhh. Just update to today's version and issue the following to scwmrepl: (use-modules (app scwm pie-menus)) (menu-style #:look shaped-pie-menu-look) -- -russ nelson http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Mon Nov 23 23:07:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04589 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:07:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04586 for ; Mon, 23 Nov 1998 23:06:42 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA18589; Mon, 23 Nov 98 23:05:29 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11300; Mon, 23 Nov 1998 23:05:34 -0500 Message-Id: <199811240405.XAA11300@w20-575-39.mit.edu> To: Arturo Perez Cc: scwm-discuss@mit.edu Subject: Re: sticky not for icons In-Reply-To: Your message of "Mon, 23 Nov 1998 17:08:06 EST." <199811232208.RAA27189@ns1.infonautics.com> Date: Mon, 23 Nov 1998 23:05:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > Using scwm-0.9beta1 under irix 5.3 > > I made an iconified xterm sticky using the menu created by system.scwmrc. > I switched desks from 1 to 2. > The xterm was not there. > > The titlebar looks scalloped, which means sticky. And the menu now says > unstick. > > Isn't the icon supposed to follow desk switches? The apps marked as desktool > s > do. icon stickiness and window stickiness are separate concepts in scwm, following the fvwm precedent. To set the icon stickiness of a window, you can use `stick-icon', `unstick-icon' or `toggle-stick-icon'. Obviously there should be a wrapper somewhere that does both. From owner-scwm-discuss@mit.edu Mon Nov 23 23:09:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04605 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:09:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04599 for ; Mon, 23 Nov 1998 23:08:52 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA19044; Mon, 23 Nov 98 23:07:43 EST Received: (qmail 11033 invoked by uid 501); 24 Nov 1998 04:07:47 -0000 Message-Id: <19981123200747.A11006@molehill.org> Date: Mon, 23 Nov 1998 20:07:47 -0800 From: Todd Larason To: Maciej Stachowiak , "Carl R. Witty" Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240351.WAA11259@w20-575-39.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811240351.WAA11259@w20-575-39.mit.edu>; from Maciej Stachowiak on Mon, Nov 23, 1998 at 10:51:48PM -0500 X-Tom-Swifty: "Please keep Ian on salary even if he does no work; banish not sweet Ian, kind Ian, true Ian, valiant Ian from thy company", was Tom's Falstaffian plea. X-Kibo: The Earth is like the color sky blue. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981123, Maciej Stachowiak wrote: > > cwitty@newtonlabs.com writes: > > > > From the Xlib source (from XFree86 3.3.2.3a): > > > > if (_XIOErrorFunction != NULL) > > (*_XIOErrorFunction)(dpy); > > else > > _XDefaultIOError(dpy); > > exit (1); > > > > Maybe you could longjmp() out? > > > > Maybe, but longjmp()ing across arbitrary unknown code is a bad > thing. Looking at Gtk internal data structures seems downright tidy by > comparison. There was a discussion this summer on the xemacs-beta list that I *think* is applicable here. , search for 'seppuku'. The particular problem they were discussing was what happens when a connection to an X server is closed by the server side, and the fact that Xlib considers this a fatal error. The only serious suggestion offered was setjmp/longjmp to avoid returning from the IO error handler. It isn't clear if this was tried and worked though. -- ICQ UIN: 113398943 From owner-scwm-discuss@mit.edu Mon Nov 23 23:04:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04566 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:04:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04560 for ; Mon, 23 Nov 1998 23:03:56 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA21833; Mon, 23 Nov 98 23:02:56 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11291; Mon, 23 Nov 1998 23:02:53 -0500 Message-Id: <199811240402.XAA11291@w20-575-39.mit.edu> To: Arturo Perez Cc: scwm-discuss@mit.edu Subject: Re: options to window-style. In-Reply-To: Your message of "Mon, 23 Nov 1998 10:38:45 EST." <199811231539.KAA10933@ns1.infonautics.com> Date: Mon, 23 Nov 1998 23:02:52 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > Here's an FAQ for you: > > What are the options/keywords to window-style? > The manual is not very forthcoming....:-) > I agree this needs to be documented. The problem right now is that using various modules can extend the set of style keywords, so they need to be documented separately (it would really help to be able to have the description of `window-style' have a back-link to all modules that define style flags). - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 23:10:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04635 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:10:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04623 for ; Mon, 23 Nov 1998 23:10:21 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA19375; Mon, 23 Nov 98 23:09:19 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11313; Mon, 23 Nov 1998 23:09:20 -0500 Message-Id: <199811240409.XAA11313@w20-575-39.mit.edu> To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: bind-key and CONTEXT; what is button-3,5-9? In-Reply-To: Your message of "21 Nov 1998 13:06:07 GMT." <19981121130607.2310.qmail@desk.crynwr.com> Date: Mon, 23 Nov 1998 23:09:19 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nelson@crynwr.com writes: > Todd Larason writes: > > On 981121, Russell Nelson wrote: > > > I need more examples of how to do things. scwm-intro-tutorial.scm is > > > a great introduction, but it just stops. Just code snippets, along > > > with an explanation of what they do. > > > > To some extent, flux.scm is already helpful in this roll. There's not so > much > > 'what they do' though, aside from the names of the functions. > > Oh ugh. Trying to go from fvwm2 to scwm means removing a *lot* of > cruft. Like toggle-maximize for example. Instead of keeping a pair > of sizes in the C code, Actually, the C code does not track sizes this way, maximize is (almost) entirely a scheme-level abstraction on top of resizing. > every window should have a list of possible sizes, so you could keep > a ring, say, of window locations and overlaps, and rotate through > them. Interesting idea, but where would the sizes and positions come from in the first place? Such a concept is, of course, eminiently codeable on the Scheme level, but I'm not sure where you are trying to go with this. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 23:13:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04688 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:13:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04685 for ; Mon, 23 Nov 1998 23:13:43 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA23739; Mon, 23 Nov 98 23:12:48 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11323; Mon, 23 Nov 1998 23:12:44 -0500 Message-Id: <199811240412.XAA11323@w20-575-39.mit.edu> To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: shaped pie menus In-Reply-To: Your message of "24 Nov 1998 03:57:34 GMT." <19981124035734.27598.qmail@desk.crynwr.com> Date: Mon, 23 Nov 1998 23:12:44 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nelson@crynwr.com writes: > Maciej Stachowiak writes: > > > these are wierd but fun (thanks to Todd - and Russell!). Only two nits: > > > > Sounds like something we need a screenshot of! :-) > > Nahhhh. Just update to today's version and issue the following to scwmrepl: > > (use-modules (app scwm pie-menus)) > (menu-style #:look shaped-pie-menu-look) > I meant for our web page, not for me. I can run that (and will try soon), but Joe Web Surfer can't. Scwm is, of course, a rather less screenshot-oriented window manager than many others, but we do like to put up screenshots that show nice examples of its configurability, when we have the chance. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 23:22:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04778 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:22:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04775 for ; Mon, 23 Nov 1998 23:22:12 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA25259; Mon, 23 Nov 98 23:21:17 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11375; Mon, 23 Nov 1998 23:21:13 -0500 Message-Id: <199811240421.XAA11375@w20-575-39.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "Mon, 23 Nov 1998 20:07:47 PST." <19981123200747.A11006@molehill.org> Date: Mon, 23 Nov 1998 23:21:13 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > > There was a discussion this summer on the xemacs-beta list that I *think* is > applicable here. > > , search for 'seppuku'. > I'll look there. > The particular problem they were discussing was what happes when a connectio > n > to an X server is closed by the server side, and the fact that Xlib considers > this a fatal error. > > The only serious suggestion offered was setjmp/longjmp to avoid returning > from the IO error handler. It isn't clear if this was tried and worked > though. The more I think about this the more I am convinced that it is totally broken of Xlib to do this. If you have a program that connects to multiple displays, say a multiplayer game that uses the X protocol as it's transport, it's pretty obvious it should not be forced to die if it loses connection to any one of the screens. Likewise, a program that runs in console mode and under X simultaneously should not die if it loses the X connection. Not only that, but having to set the XErrorHandler and XIOErrorHandler globally rather than poer-discplay is also obviously losing. Is there a chance in hell of significant X11 design flaws like this ever getting fixed? I wish the X Consortium would just die so XFree86 would be politically free to fix things like this themselves, since they actually care and have a clue. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 23:29:15 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04816 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:29:15 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04809 for ; Mon, 23 Nov 1998 23:28:49 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA26408; Mon, 23 Nov 98 23:27:47 EST Received: (qmail 11209 invoked by uid 501); 24 Nov 1998 04:27:45 -0000 Message-Id: <19981123202745.A11039@molehill.org> Date: Mon, 23 Nov 1998 20:27:45 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <19981123200747.A11006@molehill.org> <199811240421.XAA11375@w20-575-39.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: <199811240421.XAA11375@w20-575-39.mit.edu>; from Maciej Stachowiak on Mon, Nov 23, 1998 at 11:21:13PM -0500 X-Tom-Swifty: "It's better to steal things together", Tom corroborated. X-Kibo: Destinies are not bozos. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981123, Maciej Stachowiak wrote: > The more I think about this the more I am convinced that it is totally > broken of Xlib to do this. Yep! > If you have a program that connects to > multiple displays, say a multiplayer game that uses the X protocol as > it's transport, ... > Likewise, a program > that runs in console mode and under X simultaneously should not die if > it loses the X connection. Exactly the two issues that got XEmacs inolved. It can have simultaneous connections to multiple X servers and TTY devices, and currently dies if any of the X servers it's talking to die. > Is there a chance in hell of significant X11 design flaws like this > ever getting fixed? http://www.xemacs.org/list-archives/xemacs-beta/9808/msg00738.html quotes the Xt FAQ paraphrasing Robert Scheifler as saying "no", back in November 1991. -- ICQ UIN: 71049609 From owner-scwm-discuss@mit.edu Mon Nov 23 23:38:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA04949 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:38:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA04944 for ; Mon, 23 Nov 1998 23:38:53 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA24608; Mon, 23 Nov 98 23:37:51 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id XAA11403; Mon, 23 Nov 1998 23:37:54 -0500 Message-Id: <199811240437.XAA11403@w20-575-39.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "Mon, 23 Nov 1998 20:27:45 PST." <19981123202745.A11039@molehill.org> Date: Mon, 23 Nov 1998 23:37:53 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > > Is there a chance in hell of significant X11 design flaws like this > > ever getting fixed? > > http://www.xemacs.org/list-archives/xemacs-beta/9808/msg00738.html > quotes the Xt FAQ paraphrasing Robert Scheifler as saying "no", back > in November 1991. Perhaps things have changed since then. Maybe the Open Group's X Project Team would actually listen to complaints about this, especially if people cite examples of real apps that this breaks. But I kind of doubt they listen to bug reports from people who don't pay them the $$$ for a membership. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 23 23:56:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA05214 for scwm-discuss-outgoing; Mon, 23 Nov 1998 23:56:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA05211 for ; Mon, 23 Nov 1998 23:56:49 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA27458; Mon, 23 Nov 98 23:55:47 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id XAA00021 for ; Mon, 23 Nov 1998 23:55:46 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: Finding what client a Window belongs to References: <19981123200747.A11006@molehill.org> <199811240421.XAA11375@w20-575-39.mit.edu> Date: 23 Nov 1998 23:55:39 -0500 Message-Id: <5lyap1zo38.fsf@tequila.cs.yale.edu> Lines: 9 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 23 Nov 1998 23:55:39 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: > Is there a chance in hell of significant X11 design flaws like this [ Nitpick ] It's not an X11, but Xlib problem. You could try to convince XFree86 to add such an extension and then use it if available. Stefan From owner-scwm-discuss@mit.edu Tue Nov 24 00:04:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA05272 for scwm-discuss-outgoing; Tue, 24 Nov 1998 00:04:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA05269 for ; Tue, 24 Nov 1998 00:04:39 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA28945; Tue, 24 Nov 98 00:03:36 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id AAA11461; Tue, 24 Nov 1998 00:03:40 -0500 Message-Id: <199811240503.AAA11461@w20-575-39.mit.edu> To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to In-Reply-To: Your message of "23 Nov 1998 23:55:39 EST." <5lyap1zo38.fsf@tequila.cs.yale.edu> Date: Tue, 24 Nov 1998 00:03:40 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk monnier+lists/scwm/discuss/news/@tequila.cs.yale.edu writes: > >>>>> "Maciej" == Maciej Stachowiak writes: > > Is there a chance in hell of significant X11 design flaws like this > > [ Nitpick ] > It's not an X11, but Xlib problem. You could try to convince XFree86 to add > such an extension and then use it if available. > Well, if you're goint to nitpick, I could point out that Xlib is just as much an X Project Team standard as the X protocol. But your point is well-taken. I just sent mail to XFree86@XFree86.org outlining the problem. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 24 00:23:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA05542 for scwm-discuss-outgoing; Tue, 24 Nov 1998 00:23:43 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id AAA05538 for ; Tue, 24 Nov 1998 00:23:42 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id AAA11321 for ; Tue, 24 Nov 1998 00:22:45 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id AAA27014 for ; Tue, 24 Nov 1998 00:22:43 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id AAA26019 for ; Tue, 24 Nov 1998 00:23:28 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Tue, 24 Nov 1998 05:23:28 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Session management and restoring window attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi all, I've been looking into the resizing problem with session management and restoring my checkpointed window sizes, etc. I sent a patch off to Robert for consideration, but I've done some thinking and I'm not sure that in fact it's "the correct solution" to the problem. Here's the patch: Index: session-manager.c =================================================================== RCS file: /anoncvs/scwm/scwm/session-manager.c,v retrieving revision 1.13 diff -u -b -r1.13 session-manager.c --- session-manager.c 1998/11/23 13:09:35 1.13 +++ session-manager.c 1998/11/24 00:26:23 @@ -218,6 +218,9 @@ psw->wmhints->initial_state = isIconicState = IconicState; psw->wmhints->flags |= StateHint; } + if (!psw->fTitle) { + psw->title_height = 0; + } *p = d->next; /* remove from list */ FREE(d); } While the patch does correctly set up the size, the window border and position still is slightly off. I've been looking through the AddWindow function in add_window.c, and outside of being somewhat confused by what's going on, it seems like trying to restore window properties conflicts with the existing code. For example, my Fvwm Pager window has no titlebar, but when it goes through the AddWindow function, it is first assumed to have a titlebar, one is created, then later on the titlebar is removed and the size and position comes out fine. With my xsm window, whose state has been stored by session management, the flag for having a title bar is unset. With the patch above, the titlebar size is set to 0, but it seems like later code in AddWindow really would like to have the titlebar (and flag) there so that it can be corrected for later. This leads to my xsm window not being in quite the right location. So I'm wondering about a few things. Does it really make sense for AddWindow to assume there is a titlebar or borders or anything for that matter, only to correct for the lack of attributes later? Also, is AddWindow really the right place for restoring window attributes? Finally, just how much information should session management save and try to restore? What happens if I edit my .scwmrc file to radically change the style that would normally apply to a stored window? Should the new style be ignored or taken into account? Maybe some of these questions are resolved by the upcoming decoration rewrite, but it seems like session management definitely needs to factor into the design of that rewrite. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Tue Nov 24 01:23:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA05978 for scwm-discuss-outgoing; Tue, 24 Nov 1998 01:23:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA05975 for ; Tue, 24 Nov 1998 01:23:03 -0500 Received: from nebula.newtonlabs.com (cwitty@[207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA31502 for ; Mon, 23 Nov 1998 22:22:01 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA29428; Mon, 23 Nov 1998 22:25:36 -0800 Date: Mon, 23 Nov 1998 22:25:36 -0800 Message-Id: <199811240625.WAA29428@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: patches to scwmdoc.in for better (text) documentation Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried hard--I really did--but I couldn't get the printed documentation out of scwm.sgml. ("jadetex scwm.tex" processes about 7 pages, and then dies with: ! TeX capacity exceeded, sorry [grouping levels=255]. I looked this up in the TeX source code, and this is basically impossible to fix without rewriting huge chunks of TeX, or moving over to a 64-bit basic datatype for TeX.) The HTML is good, but it's not really printable, and I wanted printed documentation; so I decided to just print scwm-variables.txt and scwm-procedures.txt. Eventually, I realized that I was missing important documentation (hooks and concepts). So I patched scwmdoc.in and doc/Makefile.am to generate scwm-hooks.txt and scwm-concepts.txt. I also fixed a couple of places where newlines were getting dropped. Carl Witty cwitty@newtonlabs.com Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/doc/Makefile.am,v retrieving revision 1.19 diff -u -b -r1.19 Makefile.am --- Makefile.am 1998/11/24 03:42:29 1.19 +++ Makefile.am 1998/11/24 06:14:34 @@ -3,12 +3,12 @@ info_TEXINFOS=scwm.texi man_MANS=scwm.1 scwmexec.1 scwmrepl.1 -pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm.sgml +pkgdata_DATA=scwm-procedures.txt scwm-variables.txt scwm-hooks.txt scwm-concepts.txt scwm.sgml EXTRA_DIST=scwm-faq scwm-intro-tutorial.scm session-management smproxy.patch \ theme-howto scwm.1 scwmexec.1 scwmrepl.1 $(pkgdata_DATA) # Use scwmdoc to build the documentation files -scwm.sgml scwm-procedures.txt scwm-variables.txt: $(scwm_SOURCES) +scwm.sgml scwm-procedures.txt scwm-variables.txt scwm-hooks.txt scwm-concepts.txt : $(scwm_SOURCES) abs_builddir_doc=`pwd`; \ outdir=$$abs_builddir_doc; \ echo Outputting to directory: $$outdir; \ @@ -16,7 +16,7 @@ cd $$abs_builddir_doc; cd $(top_srcdir); \ abs_top_srcdir=`pwd`; \ echo 'make[99]: Entering directory `'$$abs_top_srcdir"'"; \ - perl $$abs_top_builddir/utilities/dev/scwmdoc -o $$outdir/scwm.sgml -O $$outdir/scwm-variables.txt -V scheme/user-options.scm -d $${SCWMDIR:-$${abs_top_srcdir}} $$outdir/scwm-procedures.txt; \ + perl $$abs_top_builddir/utilities/dev/scwmdoc -o $$outdir/scwm.sgml -O $$outdir/scwm-variables.txt -H $$outdir/scwm-hooks.txt -N $$outdir/scwm-concepts.txt -V scheme/user-options.scm -d $${SCWMDIR:-$${abs_top_srcdir}} $$outdir/scwm-procedures.txt; \ echo 'make[99]: Leaving directory `'$$abs_top_srcdir"'" html: scwm.sgml Index: scwmdoc.in =================================================================== RCS file: /anoncvs/scwm/utilities/dev/scwmdoc.in,v retrieving revision 1.1 diff -u -b -r1.1 scwmdoc.in --- scwmdoc.in 1998/11/17 03:14:34 1.1 +++ scwmdoc.in 1998/11/24 06:15:06 @@ -46,8 +46,8 @@ use constant FALSE => (1==0); use File::Basename; -my $getopts_option_letters = 'hqQDo:sCd:V:O:'; -use vars qw($opt_h $opt_q $opt_Q $opt_D $opt_o $opt_s $opt_C $opt_d $opt_V $opt_O); +my $getopts_option_letters = 'hqQDo:sCd:V:O:H:N:'; +use vars qw($opt_h $opt_q $opt_Q $opt_D $opt_o $opt_s $opt_C $opt_d $opt_V $opt_O $opt_H $opt_N); my $scwm_version = "post-0.8"; @@ -58,6 +58,8 @@ -D Debugging output on -V file Output user-options scheme module to file -- skip if not given -O file Output user-options documentation to file -- skip if not given +-H file Output user hooks documentation to file -- skip if not given +-N file Output concepts documentation to file -- skip if not given -o file Send sgml output to file -- no sgml output unless this is given -s Run ispell on the comments and reports warnings for its responses -C Only output concepts chapters @@ -501,6 +503,57 @@ } } +if ($opt_H) { + my $file = $opt_H; + open (HOOKS_OUT,">$file") or + die "Could not open $file"; + print STDERR "outputting hooks to $file\n"; + + foreach my $hook (sort { lc($a) cmp lc($b) } keys %hooks ) { + my $comment = $hooks{$hook}{comment}; + my $file = $hooks{$hook}{file}; + my $line = $hooks{$hook}{line}; + my $module = $hooks{$hook}{module}; + + print HOOKS_OUT <$file") or + die "Could not open $file"; + print STDERR "outputting concepts to $file\n"; + + foreach my $concept (sort { lc($a) cmp lc($b) } keys %concepts ) { + my $comment = $concepts{$concept}{comment}; + my $file = $concepts{$concept}{file}; + my $line = $concepts{$concept}{line}; + + print CONCEPTS_OUT <) && m%^;;;\s*(.*)$%) { - $comment .= $1; + $comment .= "$1\n"; if (eof) { close(ARGV); # FIXGJB: this might be wrong-- resetting too early? @@ -791,6 +844,7 @@ } } else { # read rest of C comment + $comment .= "\n"; if ($comment !~ m%\*/%) { while (defined($_ = <>) && $_ !~ m%\*/%) { $comment .= $_; From owner-scwm-discuss@mit.edu Tue Nov 24 01:46:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA06149 for scwm-discuss-outgoing; Tue, 24 Nov 1998 01:46:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA06146 for ; Tue, 24 Nov 1998 01:46:15 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA18347; Tue, 24 Nov 98 01:45:17 EST Received: (qmail 11865 invoked by uid 501); 24 Nov 1998 06:45:17 -0000 Message-Id: <19981123224517.A11752@molehill.org> Date: Mon, 23 Nov 1998 22:45:17 -0800 From: Todd Larason To: Craig Struble , scwm-discuss@mit.edu Subject: Re: Session management and restoring window attributes References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i In-Reply-To: ; from Craig Struble on Tue, Nov 24, 1998 at 05:23:28AM +0000 X-Tom-Swifty: "Alouette, je te plumerai", sang Tom jauntily. X-Kibo: Can you fall in love with deadly radiation that comes out of TV sets? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981124, Craig Struble wrote: > So I'm wondering about a few things. Does it really make sense for > AddWindow to assume there is a titlebar or borders or anything for that > matter, only to correct for the lack of attributes later? This is ALL going to have to be rethought for the GDR. One possibility (influenced heavily by the KDE window manager) would be for the general code to know only how big a border to leave around the client window, the same size in all dimensions. Very simple, but would make things like snap-to-edge more difficult. Only slightly less simple would be a border size along each side. Then there would be a set of look-specific modules that draw inside the border. Of course, we would need a 'classic scwm' module, which would still have these problems needing fixing. > Finally, > just how much information should session management save and try to > restore? What happens if I edit my .scwmrc file to radically change the > style that would normally apply to a stored window? Should the new style > be ignored or taken into account? This seems like a Hard Question(tm). I have menu items to change a window's decor/style set. 'Obviously', if I set a style on a window with the menu, it should be saved. But probably not if I don't. And what should the position of a window be if its border width changes drastically between runs (by editing the .scwmrc)? If it was against the edge before, it probably should be again...but that may require moving it. Maybe constraints would help some? If we put constraints on windows describing what we really want, and the session manager saves the constraints, then solves them again (maybe using the last position as a starting point?), that might work? Note all the question marks there =) -- ICQ UIN: 99450110 From owner-scwm-discuss@mit.edu Tue Nov 24 03:35:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA07772 for scwm-discuss-outgoing; Tue, 24 Nov 1998 03:35:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA07769 for ; Tue, 24 Nov 1998 03:35:28 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA25875; Tue, 24 Nov 98 03:34:22 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA18648; Tue, 24 Nov 1998 10:33:59 +0200 To: Maciej Stachowiak Cc: Craig Struble , scwm-discuss@mit.edu Subject: Re: Compilation bug References: <199811240244.VAA10960@w20-575-39.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 24 Nov 1998 10:33:59 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 23 Nov 1998 21:44:30 EST" Message-Id: Lines: 24 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > cstruble@vt.edu writes: > > I found a bug in draw-xpm-menu.c when compiling with debugging messages > > on. The patch is below. (BTW, I'm just using cvs diff for these, but I'm > > sure somewhere in the archive other options were specified. Could someone > > put the preferred diff options in BUG-REPORTING or HACKING?) > > > > Excellent idea! The problem is that some of us have different > preferences. I prefer `diff -uB', some other scwm developers prefer > context diffs, though I think. If we could agree on preferred formats > per directory, I think that would be best. If other people have > different preferences, I'll try to work them out and figure out a way > to get it all into "HACKING". What if people fix spacing - multiline strings, # of blank lines btw fcns, btw blocks, nonempty blank lines (blank lines with spaces or tabs on them), ...? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Nov 24 03:42:15 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA07804 for scwm-discuss-outgoing; Tue, 24 Nov 1998 03:42:15 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA07801 for ; Tue, 24 Nov 1998 03:42:14 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26511; Tue, 24 Nov 98 03:41:09 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA18680; Tue, 24 Nov 1998 10:41:10 +0200 To: Maciej Stachowiak Cc: Stefan Monnier , scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 24 Nov 1998 10:41:10 +0200 In-Reply-To: Maciej Stachowiak's message of "Tue, 24 Nov 1998 00:03:40 EST" Message-Id: Lines: 26 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > monnier+lists/scwm/discuss/news/@tequila.cs.yale.edu writes: > > >>>>> "Maciej" == Maciej Stachowiak writes: > > > Is there a chance in hell of significant X11 design flaws like this > > > > [ Nitpick ] It's not an X11, but Xlib problem. You could try to > > convince XFree86 to add such an extension and then use it if > > available. > > > > Well, if you're goint to nitpick, I could point out that Xlib is > just as much an X Project Team standard as the X protocol. > > But your point is well-taken. > > I just sent mail to XFree86@XFree86.org outlining the problem. Isn't the existence of this problem a good reason for this gtk window stuff to be a separate process instead of being built into the window manager? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Nov 24 09:05:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA09192 for scwm-discuss-outgoing; Tue, 24 Nov 1998 09:05:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA09189 for ; Tue, 24 Nov 1998 09:05:17 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA03037; Tue, 24 Nov 98 09:04:07 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id JAA14798; Tue, 24 Nov 1998 09:03:27 -0500 (EST) Message-Id: <199811241403.JAA14798@ns1.infonautics.com> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: crash switching desks In-Reply-To: Your message of "Mon, 23 Nov 1998 14:38:26 PST." <19981123143826.A8791@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Nov 1998 09:03:04 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <19981123143826.A8791@molehill.org>, Todd Larason writes: > >What version are you using? The line numbers don't line up well with the >snapshot I'm lokoing at, it may be that it's already been fixed. Sorry, forgot to mention it. scwm-0.9beta1 on irix 5.3. -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Tue Nov 24 09:20:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA09280 for scwm-discuss-outgoing; Tue, 24 Nov 1998 09:20:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA09277 for ; Tue, 24 Nov 1998 09:20:31 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA07539; Tue, 24 Nov 98 09:19:24 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id JAA15398; Tue, 24 Nov 1998 09:19:27 -0500 (EST) Message-Id: <199811241419.JAA15398@ns1.infonautics.com> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: options to window-style. In-Reply-To: Your message of "Mon, 23 Nov 1998 23:02:52 EST." <199811240402.XAA11291@w20-575-39.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Nov 1998 09:19:05 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <199811240402.XAA11291@w20-575-39.mit.edu>, Maciej Stachowiak writes : > >arturo@infonautics.com writes: >> Here's an FAQ for you: >> >> What are the options/keywords to window-style? >> The manual is not very forthcoming....:-) >> > >I agree this needs to be documented. The problem right now is that >using various modules can extend the set of style keywords, so they >need to be documented separately (it would really help to be able to >have the description of `window-style' have a back-link to all modules >that define style flags). > > - Maciej > Well, then how does window-style get extended? (so I can go look for the keywords.) Could the documentation tools recognize window-style getting extended and automagically kick out the links/footnotes? Just to clarify: Documentation tools create window-style.html (or whatever) Documentation tools encounter augmentation of window-style. Tools update window-style.html(or whatever) with footnotes, links, etc. -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Tue Nov 24 10:26:10 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA09685 for scwm-discuss-outgoing; Tue, 24 Nov 1998 10:26:10 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA09675 for ; Tue, 24 Nov 1998 10:25:38 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA02944; Tue, 24 Nov 98 10:24:32 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA02376; Tue, 24 Nov 1998 07:24:28 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Compilation bug References: <199811240246.VAA10968@w20-575-39.mit.edu> From: Greg Badros Date: 24 Nov 1998 07:24:27 -0800 In-Reply-To: Maciej Stachowiak's message of "Mon, 23 Nov 1998 21:46:46 EST" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I was reading the diff info page, and thinking about it a bit more, I > think -B (ignore adding or removing blank lines) is a good idea but -b > is potentially dangerous because whitespace differences in > double-quoted strings are definitely significant. Should we just put a > warning not to use this behavior if your patch has meaningful > whitespace changes? Nah, let's switch to just -u; I think I must've gotten them confused (I was trying to remember your suggestion, which might've been -uB, and got it wrong.) -u seems the safest and nicest, and I think we can assume that all those who'll be applying patches have GNU patch (since some vendor patches can't handle unified diff output). Greg From owner-scwm-discuss@mit.edu Tue Nov 24 10:31:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA09735 for scwm-discuss-outgoing; Tue, 24 Nov 1998 10:31:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA09729 for ; Tue, 24 Nov 1998 10:30:39 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA04589; Tue, 24 Nov 98 10:29:34 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA02389; Tue, 24 Nov 1998 07:29:29 -0800 (PST) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811192205.RAA10723@vicarious-existence.mit.edu> <5lzp9hzvf9.fsf@tequila.cs.yale.edu> From: Greg Badros Date: 24 Nov 1998 07:29:28 -0800 In-Reply-To: Stefan Monnier's message of "23 Nov 1998 21:17:14 -0500" Message-Id: Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Maciej" == Maciej Stachowiak writes: > > Is there any way to find what client a window belongs to, or > > specifically for a client to check if a given window was created by > > itself? I ask because the only major scwm/guile-gtk stability problem > > remaining that I am aware of is that if you `destroy-window' a > > scwm/guile-gtk created window, scwm XKillClient()s itself, which is > > clearly a bad thing. > > Excuse me for asking a stupid question (I have zero knowledge of Xwindows > programming apart from hacking a fancy StayOnTop feature int ctwm), but > don't you have already somewhere in scwm a way to map a window-ID to an > scwm object ? Yes, but here Maciej is wondering how to tell which process created a window; the scheme window objects don't know which client process is responsible for them. I'm not sure why it's relevant, actually, unless we think that it's a mutable parameter that we could then disassociate from the Scwm process... I'll ask on comp.windows.x. Perhaps the easiest solution is to just not permit destroywindow calls on those windows, or intercept them and do our own thing. We are, after alll, coding the window manager... > Stefan "trying to understand the question a little better" Always a good idea! Greg From owner-scwm-discuss@mit.edu Tue Nov 24 10:54:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA09896 for scwm-discuss-outgoing; Tue, 24 Nov 1998 10:54:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA09893 for ; Tue, 24 Nov 1998 10:54:50 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA12945; Tue, 24 Nov 98 10:53:50 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA02439; Tue, 24 Nov 1998 07:53:40 -0800 (PST) To: Todd Larason Cc: Craig Struble , scwm-discuss@mit.edu Subject: Re: Session management and restoring window attributes References: <19981123224517.A11752@molehill.org> From: Greg Badros Date: 24 Nov 1998 07:53:40 -0800 In-Reply-To: Todd Larason's message of "Mon, 23 Nov 1998 22:45:17 -0800" Message-Id: Lines: 37 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > > Finally, > > just how much information should session management save and try to > > restore? What happens if I edit my .scwmrc file to radically change the > > style that would normally apply to a stored window? Should the new style > > be ignored or taken into account? > > This seems like a Hard Question(tm). I have menu items to change a window's > decor/style set. 'Obviously', if I set a style on a window with the menu, it > should be saved. But probably not if I don't. And what should the position > of a window be if its border width changes drastically between runs (by > editing the .scwmrc)? If it was against the edge before, it probably should > be again...but that may require moving it. > > Maybe constraints would help some? If we put constraints on windows > describing what we really want, and the session manager saves the constraints, > then solves them again (maybe using the last position as a starting point?), > that might work? Note all the question marks there =) Here the declarative, semantics-preserving nature of some form of constraints might be useful (but not necessarily the numerical-based constraint solver currently embedded). We'd need a way of separating the idea of "client window at (x,y) where x = horizontal frame border width, y = vertical frame border width" and "client window in the upper left corner". In part, this is one of the things that window gravity can help with. With the embedded solver, when more of the window attributes are constrainable variables, we'll be able to make the window position be constrained relative to border widths. Of course, then we have to persist the constraints, too, to make things come back up in the same semantic state (as opposed to physical configuration). Greg From owner-scwm-discuss@mit.edu Tue Nov 24 11:01:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA10019 for scwm-discuss-outgoing; Tue, 24 Nov 1998 11:01:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA10016 for ; Tue, 24 Nov 1998 11:01:34 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA15393; Tue, 24 Nov 98 11:00:33 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA02461; Tue, 24 Nov 1998 08:00:11 -0800 (PST) To: "Carl R. Witty" Cc: scwm-discuss@mit.edu Subject: Re: patches to scwmdoc.in for better (text) documentation References: <199811240625.WAA29428@nebula.newtonlabs.com> From: Greg Badros Date: 24 Nov 1998 08:00:11 -0800 In-Reply-To: "Carl R. Witty"'s message of "Mon, 23 Nov 1998 22:25:36 -0800" Message-Id: Lines: 8 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ok, thanks for the patches! I'll committ shortly after some testing. That's too bad that jadetex doesn't handle scwm.sgml; anybody know of any other options? There's *must* be a way to print big docbook sgml... maybe there's a nesting bug or something in scwm.sgml that is confusing JadeTeX? Thanks, Greg From owner-scwm-discuss@mit.edu Tue Nov 24 14:00:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA11223 for scwm-discuss-outgoing; Tue, 24 Nov 1998 14:00:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA11220 for ; Tue, 24 Nov 1998 14:00:05 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA20193; Tue, 24 Nov 98 13:59:03 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id NAA24308 for ; Tue, 24 Nov 1998 13:58:50 -0500 (EST) Message-Id: <199811241858.NAA24308@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: icons not returning to their proper position Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="===_0_Tue_Nov_24_13:57:37_EST_1998" Date: Tue, 24 Nov 1998 13:58:28 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk This is a multipart MIME message. --===_0_Tue_Nov_24_13:57:37_EST_1998 Content-Type: text/plain; charset=us-ascii Whenever I de-iconify a "stuck" icon and then re-iconify it, the icon appears at a different position then the one I last placed it it. That is, if I manually position a stuck icon, de-iconify and re-iconify it moves to a position different than the one I placed it at. --===_0_Tue_Nov_24_13:57:37_EST_1998 Content-Type: text/plain; charset=us-ascii Content-Description: version-info uname -a: ------------------ IRIX muesli 5.3 02091401 IP22 mips guile -v: ------------------ Guile 1.3 Copyright (c) 1995, 1996, 1997 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. aclocal --version ------------------ autoconf --version ------------------ automake --version ------------------ libtool --version ------------------ scwm -V: ------------------ Scwm Version 0.9beta1 compiled on Nov 18 1998 at 17:52:36 RCS_ID=$Id: scwm.c,v 1.150 1998/11/18 00:04:17 mstachow Exp $ Repository Timestamp: Tue Nov 17 21:33:27 EST 1998 -- $Revision: 1.900 $ changed.c: ------------------ char *szRepoLastChanged = "Tue Nov 17 21:33:27 EST 1998 -- $Revision: 1.900 $"; scwmpaths.h: ------------------ /* generated by Makefile -- do not edit */ #define SCWM_PREFIX "/usr/local" #define SCWM_EXEC_PREFIX "/usr/local" #define SCWMDIR "/usr/local/lib/X11/scwm" #define SCWMRC ".scwmrc" #define SCWM_LOAD_PATH "/usr/local/share/scwm-modules" #define SCWM_BIN_LOAD_PATH "/usr/local/lib/scwm-modules" #define SCWM_IMAGE_LOAD_PATH "(\"/usr/include/X11/bitmaps\" \"/usr/include/X11/pixmaps\" \"/X11/mini-icons\" \"/usr/local/include/X11/pixmaps\" \"/usr/local/include/X11/bitmaps\" \"/usr/local/lib/X11/mini-icons\")" ldd scwm: ------------------ No ldd on this system. relevant env: ------------------ LD_LIBRARY_PATH=/usr/local/lib PATH=/usr/sbin:/usr/bsd:/sbin:/usr/bin:/bin:/usr/bin/X11:/home/arturo/bin:/usr/local/bin:/usr/local/mh/bin:/usr/lib/Zmail/bin:/home/mblock/bin:/usr/atria/bin:/usr/atria/bin:/usr/atria/bugtrack:/usr/atria/bugtrack/bin:/home/ddts/bin SCWM_LOAD_PATH=/home/arturo/scwm-0.9beta1 config.h: ------------------ /* include/config.h. Generated automatically by configure. */ /* include/config.h.in. Generated automatically from configure.in by autoheader. */ /* Define if on AIX 3. System headers sometimes define this. We just want to avoid a redefinition error message. */ #ifndef _ALL_SOURCE /* #undef _ALL_SOURCE */ #endif /* Define to empty if the keyword does not work. */ /* #undef const */ /* Define as __inline if that's what the C compiler calls it. */ /* #undef inline */ /* Define if on MINIX. */ /* #undef _MINIX */ /* Define if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define if you need to in order for stat and other things to work. */ /* #undef _POSIX_SOURCE */ /* Define if you have the ANSI C header files. */ #define STDC_HEADERS 1 /* Define if the X Window System is missing or not being used. */ /* #undef X_DISPLAY_MISSING */ /* Package and version macros defined by automake */ #define PACKAGE "scwm" #define VERSION "0.9beta1" /* Define this if your Xext library supports the X extension (wether your server does or not will be determined at runtime */ #define HAVE_SHAPE 1 /* Define this if you have libXpm */ #define HAVE_LIBXPM 1 /* Define this if you have libXmu */ #define HAVE_LIBXMU 1 /* Define this if you have libSM and libIce for session manager support */ #define HAVE_LIBSM_LIBICE 1 /* Define this if you have the readline library */ #define HAVE_READLINE 1 /* Define this if your readline also has add_history() */ #define HAVE_HISTORY 1 /* Define this if your libguile has a scm_eval_string that is safe against re-entry by continuations. This should be true of snapshots newer than 970928. */ #define HAVE_SAFE_SCM_EVAL_STRING 1 /* Define this if your libguile exports scm_puts, meaning that scm_gen_puts should no longer be used. This should be true of snapshots newer than 971014. */ #define HAVE_SCM_PUTS 1 /* Define this if your libguile has gh_vector_ref instead of gh_vref, meaning that gh_vref should no longer be used. This should be true of snapshots newer than 971012. */ #define HAVE_GH_VECTOR_REF 1 /* Define this if your libguile has gh_vector_set_x instead of gh_vset, meaning that gh_vset should no longer be used. This should be true of snapshots newer than 971020. */ #define HAVE_GH_VECTOR_SET_X 1 /* Define this if your libguile has readline support. This should be true of snapshots newer than 971023. */ /* #undef HAVE_SCM_READLINE */ /* Define this if your libguile has gh_length and not gh_list_length. This should be true of snapshots newer than 970915. */ #define HAVE_GH_LENGTH 1 /* Define this if your libguile has scm_parse_path. */ #define HAVE_SCM_PARSE_PATH 1 /* Define this if your libguile has scm_parse_path. */ #define HAVE_SCM_INTERNAL_SELECT 1 /* Define this if your libguile has scm_the_last_stack_fluid instead of scm_the_last_stack_var. */ #define HAVE_SCM_THE_LAST_STACK_FLUID 1 /* Define this if your libguile has scm_internal_cwdr. */ #define HAVE_SCM_INTERNAL_CWDR 1 /* Define this if your libguile has scm_internal_stack_catch. */ #define HAVE_SCM_INTERNAL_STACK_CATCH 1 /* Define this if your libguile has scm_internal_parse_path, which should be used instead of scm_parse_path from C. */ #define HAVE_SCM_INTERNAL_PARSE_PATH 1 /* Define this if your libguile has a scm_make_vector, which needs three arguments. This should be true only of older versions. */ /* #undef HAVE_SCM_MAKE_VECTOR_3_ARGS */ /* Define this if your libguile has scm_load_startup_files, which means the hack to get boot-9.scm to be loaded is unnecessary and even dangerous. */ #define HAVE_SCM_LOAD_STARTUP_FILES 1 /* Define this if your system has a header file. */ #define HAVE_GETOPT_H 1 /* Define this if you want multibyte support. */ /* #undef I18N */ /* Define this if you want to compile with X_LOCALE define. */ /* #undef X_LOCALE */ /* Define this and use C++ compiler if you want to use constraint solver */ /* #undef USE_CASSOWARY */ /* Define tihs if you want to turn debug support off for cassowary */ /* #undef CL_NO_TRACE */ /* Define if you have the gethostname function. */ #define HAVE_GETHOSTNAME 1 /* Define if you have the getopt_long function. */ /* #undef HAVE_GETOPT_LONG */ /* Define if you have the setlinebuf function. */ #define HAVE_SETLINEBUF 1 /* Define if you have the setvbuf function. */ #define HAVE_SETVBUF 1 /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 /* Define if you have the strerror function. */ #define HAVE_STRERROR 1 /* Define if you have the strncasecmp function. */ #define HAVE_STRNCASECMP 1 /* Define if you have the sysconf function. */ #define HAVE_SYSCONF 1 /* Define if you have the uname function. */ #define HAVE_UNAME 1 /* Define if you have the usleep function. */ /* #undef HAVE_USLEEP */ /* Define if you have the waitpid function. */ #define HAVE_WAITPID 1 /* Define if you have the header file. */ #define HAVE_X11_SM_SMLIB_H 1 /* Define if you have the header file. */ #define HAVE_GETOPT_H 1 /* Define if you have the m library (-lm). */ #define HAVE_LIBM 1 --===_0_Tue_Nov_24_13:57:37_EST_1998 Content-Type: text/plain; charset=us-ascii ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com --===_0_Tue_Nov_24_13:57:37_EST_1998-- From owner-scwm-discuss@mit.edu Tue Nov 24 14:20:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA11392 for scwm-discuss-outgoing; Tue, 24 Nov 1998 14:20:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA11389 for ; Tue, 24 Nov 1998 14:20:20 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA24838; Tue, 24 Nov 98 14:19:11 EST Received: from muesli.infonautics.com (muesli.infonautics.com [207.17.60.155]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id OAA24946 for ; Tue, 24 Nov 1998 14:19:14 -0500 (EST) Message-Id: <199811241919.OAA24946@ns1.infonautics.com> To: scwm-discuss@mit.edu Subject: scwmrepl doesn't read full s-expressions. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Nov 1998 14:18:52 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is it a feature that scwmrepl stops reading s-expressions at newlines? This is what happened: scwm> (window-style "*" #:border-width 6 #:focus 'mouse #:random-placement #t #:smart-placement #t #:mwm-func-hint #t #:mwm-decor-hint #t #:hint-override #t #:decorate-transient #t #:PPosition-hint #f #:lenience #t )scwm> #:fg "white" #:bg "navy" scwm> #:icon "unknown1.xpm" scwm> ) #:icon-box (list 0 (y- 1) (%y 100)) # #:icon-box (0 1023 1024) scwm> #:border-width 6 #:border-width 6 scwm> #:focus 'mouse #:focus -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Tue Nov 24 14:51:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA11588 for scwm-discuss-outgoing; Tue, 24 Nov 1998 14:51:52 -0500 Received: from quackerjack.cc.vt.edu (quackerjack.cc.vt.edu [198.82.160.250]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id OAA11585 for ; Tue, 24 Nov 1998 14:51:51 -0500 Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id OAA08244 for ; Tue, 24 Nov 1998 14:50:46 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id OAA18413 for ; Tue, 24 Nov 1998 14:50:45 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id OAA15793 for ; Tue, 24 Nov 1998 14:51:31 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Tue, 24 Nov 1998 19:51:30 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: hilight vs. highlight Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I noticed that there are functions (set-hilight-factor! ...) (set-hilight-foreground! ...) (set-hilight-background! ...) and (set-window-highlight-foreground! ...) (set-window-highlight-background! ...) and other various spellings of {hilight, highlight, hilite} for scheme level functions and in the source. Can one spelling be agreed upon, at least at the scheme level? See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Tue Nov 24 15:09:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA11703 for scwm-discuss-outgoing; Tue, 24 Nov 1998 15:09:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA11700 for ; Tue, 24 Nov 1998 15:09:35 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA13710; Tue, 24 Nov 98 15:08:25 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA03031; Tue, 24 Nov 1998 12:08:27 -0800 (PST) To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: hilight vs. highlight References: From: Greg Badros Date: 24 Nov 1998 12:08:27 -0800 In-Reply-To: Craig Struble's message of "Tue, 24 Nov 1998 19:51:30 +0000 ()" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Craig Struble writes: > I noticed that there are functions > > (set-hilight-factor! ...) > (set-hilight-foreground! ...) > (set-hilight-background! ...) > > and > > (set-window-highlight-foreground! ...) > (set-window-highlight-background! ...) > > and other various spellings of {hilight, highlight, hilite} for scheme > level functions and in the source. Can one spelling be agreed upon, at > least at the scheme level? No way! Diversity is the spice of life! :-) I vote for "highlight" since it's the only one that is an English word. Greg From owner-scwm-discuss@mit.edu Tue Nov 24 16:57:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA12587 for scwm-discuss-outgoing; Tue, 24 Nov 1998 16:57:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA12574 for ; Tue, 24 Nov 1998 16:56:50 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA26111; Tue, 24 Nov 98 16:55:42 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id QAA14814; Tue, 24 Nov 1998 16:55:16 -0500 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> From: Jim Blandy Date: 24 Nov 1998 16:55:15 -0500 In-Reply-To: hjstein@bfr.co.il's message of 24 Nov 1998 10:41:10 +0200 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Isn't the existence of this problem a good reason for this gtk window > stuff to be a separate process instead of being built into the window > manager? But one of the most interesting things to do with GTK widgets created by SCWM is have them munge SCWM's data structures. From owner-scwm-discuss@mit.edu Tue Nov 24 17:37:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA12973 for scwm-discuss-outgoing; Tue, 24 Nov 1998 17:37:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA12970 for ; Tue, 24 Nov 1998 17:37:46 -0500 Received: from ns.crynwr.com by MIT.EDU with SMTP id AA07559; Tue, 24 Nov 98 17:37:13 EST Received: (qmail 19291 invoked by uid 0); 24 Nov 1998 22:37:42 -0000 Received: from isdn-8.canton.northnet.org (HELO desk.crynwr.com) (209.2.152.9) by ns.crynwr.com with SMTP; 24 Nov 1998 22:37:42 -0000 Received: (qmail 22339 invoked by uid 501); 24 Nov 1998 22:37:27 -0000 Date: 24 Nov 1998 22:37:27 -0000 Message-Id: <19981124223727.22338.qmail@desk.crynwr.com> From: Russell Nelson Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Scheme tutorial ala scwm-intro-tutorial.scm In-Reply-To: References: <19981123224517.A11752@molehill.org> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid X-Face: $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?" nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace. From owner-scwm-discuss@mit.edu Tue Nov 24 17:45:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA13045 for scwm-discuss-outgoing; Tue, 24 Nov 1998 17:45:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA13042 for ; Tue, 24 Nov 1998 17:45:20 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA11706; Tue, 24 Nov 98 17:45:04 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id OAA03302; Tue, 24 Nov 1998 14:44:58 -0800 (PST) To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: Scheme tutorial ala scwm-intro-tutorial.scm References: <19981123224517.A11752@molehill.org> <19981124223727.22338.qmail@desk.crynwr.com> From: Greg Badros Date: 24 Nov 1998 14:44:57 -0800 In-Reply-To: Russell Nelson's message of "24 Nov 1998 22:37:27 -0000" Message-Id: Lines: 14 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Russell Nelson writes: > scwm-intro-tutorial.scm really appeals to me. I did something similar > for the MINT (MINT Is Not TRAC) language embedded in my Freemacs for > DOS. Is there a similar scheme tutorial?? scwm-intro-tutorial.scm is meant to cover scheme, too. It's targeted for the fvwm2 user who wants to switch to scwm but hasn't a clue where to start. I'll complete the tutorial before the new year. _The_Little_Schemer_ is the standard scheme book mentioned, but I find it's style horribly distasteful... Greg From owner-scwm-discuss@mit.edu Tue Nov 24 18:12:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA13405 for scwm-discuss-outgoing; Tue, 24 Nov 1998 18:12:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA13398; Tue, 24 Nov 1998 18:12:37 -0500 Message-Id: <199811242312.SAA13398@vicarious-existence.mit.edu> To: Arturo Perez cc: scwm-discuss@mit.edu Subject: Re: options to window-style. In-reply-to: Your message of "Tue, 24 Nov 1998 09:19:05 EST." <199811241419.JAA15398@ns1.infonautics.com> Date: Tue, 24 Nov 1998 18:12:37 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > > > Well, then how does window-style get extended? (so I can go look for the keywords.) > With add-window-hint-option or add-window-style-option. > Could the documentation tools recognize window-style getting extended > and automagically kick out the links/footnotes? > Yes, I hope so, this work is not done yet though. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 24 18:12:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA13397 for scwm-discuss-outgoing; Tue, 24 Nov 1998 18:12:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA13394 for ; Tue, 24 Nov 1998 18:12:30 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA18748; Tue, 24 Nov 98 18:12:29 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id BAA27228; Wed, 25 Nov 1998 01:12:09 +0200 To: Jim Blandy Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 25 Nov 1998 01:12:09 +0200 In-Reply-To: Jim Blandy's message of "24 Nov 1998 16:55:15 -0500" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > Isn't the existence of this problem a good reason for this gtk window > > stuff to be a separate process instead of being built into the window > > manager? > > But one of the most interesting things to do with GTK widgets created > by SCWM is have them munge SCWM's data structures. It sucks, doesn't it... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Tue Nov 24 18:24:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA13674 for scwm-discuss-outgoing; Tue, 24 Nov 1998 18:24:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA13663; Tue, 24 Nov 1998 18:23:57 -0500 Message-Id: <199811242323.SAA13663@vicarious-existence.mit.edu> To: Jim Blandy cc: scwm-discuss@mit.edu Subject: Re: Apache In-reply-to: Your message of "24 Nov 1998 13:44:21 EST." Date: Tue, 24 Nov 1998 18:23:57 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jimb@red-bean.com writes: > > > I'm a bigger loser :-) I was going to wrap up my stack test program as > > a configure script and send it to the Guile list, but I got a bad case > > of brain overload this weekend so I spent it playing computer games > > and socializing instead. > > Ahh, it happens to other people. I don't feel like such a loser any > more. > > The plans for gh_init sound good. > > However, I want to turn the gh_ interface into a SRFI. I'm not sure > how the other Scheme people will feel about requiring a function that > requires such hackery to implement. I think we should just call it > scm_init, and if the gh_ group members agree to it, we can add an > alias. That is fine. However, I do not believe the gh_ interface is reasonably implementable as is in any Scheme, because it completely disregards GC issues. In particular, Scheme implementations that don't scan the stack conservatively will require extra stuff to keep the calls around, and the gh_enter-type protocol will not help them. OTOH some other implemenations may be fully conservative and will not need to mark objects on the heap, unlike Guile, so I don't think there is any way to gloss over this difference. Or, in other words, I think gh_init and gh_enter are equally unportable concepts. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 24 18:40:52 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14050 for scwm-discuss-outgoing; Tue, 24 Nov 1998 18:40:52 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14042; Tue, 24 Nov 1998 18:40:50 -0500 Message-Id: <199811242340.SAA14042@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Scheme tutorial ala scwm-intro-tutorial.scm In-reply-to: Your message of "24 Nov 1998 14:44:57 PST." Date: Tue, 24 Nov 1998 18:40:50 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Russell Nelson writes: > > > scwm-intro-tutorial.scm really appeals to me. I did something similar > > for the MINT (MINT Is Not TRAC) language embedded in my Freemacs for > > DOS. Is there a similar scheme tutorial?? > > scwm-intro-tutorial.scm is meant to cover scheme, too. It's targeted > for the fvwm2 user who wants to switch to scwm but hasn't a clue where > to start. I'll complete the tutorial before the new year. > > _The_Little_Schemer_ is the standard scheme book mentioned, but I find > it's style horribly distasteful... > As far as Scheme books go, I generally reccomend Abelson and Sussman's _Structure_and_Interpretation_of_Computer_Programs_, but admittedly this book spends more time covering (fairly advanced for an intro course) programming concepts rather than the Scheme language. - Maciej From owner-scwm-discuss@mit.edu Tue Nov 24 18:50:17 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14234 for scwm-discuss-outgoing; Tue, 24 Nov 1998 18:50:17 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14227; Tue, 24 Nov 1998 18:50:15 -0500 Message-Id: <199811242350.SAA14227@vicarious-existence.mit.edu> To: Elliot Lee cc: scwm-discuss@mit.edu Subject: Re: GNOME themes In-reply-to: Your message of "Tue, 24 Nov 1998 18:34:17 EST." Date: Tue, 24 Nov 1998 18:50:15 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sopwith@redhat.com writes: > Miguel brought up the problem of not having GNOME themes defined well > enough. Right now GNOME theme == gtk theme. Ultimately, a GNOME theme > would include information on: > - Which gtk+ theme is in use > - Which sounds are selected for various sound events. > - Which pixmaps are selected for use as desktop icons & > stock icons. > > We need support both prepackaged themes (user downloads a file and > instantly ) and a user's "custom" theme (whatever the user has set from > the control panels). Not yet sure how the two should interact (e.g. what > happens if a user installs a theme and then changes settings?). > > Suggestions on how best to address this whole can of worms? :) My thoughts: selecting a pre-packaged theme should set all the settings appropriately and the user should be able to edit them afterwards. The user should also be able to save his current settings as a theme package. Added bonus: theme selector == theme editor, with automatic previews. Another concern is: how do window manager themes fit into this? Should each window manager that supports something theme-like have it's own selector applet, or should there be some way to incorporate theme selection for various window managers into Gnome theme selection? - Maciej From owner-scwm-discuss@mit.edu Tue Nov 24 19:59:02 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA14778 for scwm-discuss-outgoing; Tue, 24 Nov 1998 19:59:02 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA14775 for ; Tue, 24 Nov 1998 19:59:01 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA11176; Tue, 24 Nov 98 19:59:01 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA14940; Tue, 24 Nov 1998 19:58:53 -0500 To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> From: Jim Blandy Date: 24 Nov 1998 19:58:52 -0500 In-Reply-To: hjstein@bfr.co.il's message of 25 Nov 1998 01:12:09 +0200 Message-Id: Lines: 7 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > It sucks, doesn't it... Separate Address Spaces Considered Harmful (No joke! Proof-carrying code is the future, man.) From owner-scwm-discuss@mit.edu Tue Nov 24 19:58:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA14770 for scwm-discuss-outgoing; Tue, 24 Nov 1998 19:58:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA14767 for ; Tue, 24 Nov 1998 19:58:07 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA09786; Tue, 24 Nov 98 19:58:00 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id TAA14937; Tue, 24 Nov 1998 19:57:53 -0500 To: Russell Nelson Cc: scwm-discuss@mit.edu Subject: Re: Scheme tutorial ala scwm-intro-tutorial.scm References: <19981123224517.A11752@molehill.org> <19981124223727.22338.qmail@desk.crynwr.com> From: Jim Blandy Date: 24 Nov 1998 19:57:52 -0500 In-Reply-To: Russell Nelson's message of 24 Nov 1998 22:37:27 -0000 Message-Id: Lines: 6 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > scwm-intro-tutorial.scm really appeals to me. I did something similar > for the MINT (MINT Is Not TRAC) language embedded in my Freemacs for > DOS. Is there a similar scheme tutorial?? No, but we are looking for one to include in the Guile manual. From owner-scwm-discuss@mit.edu Wed Nov 25 01:50:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA16612 for scwm-discuss-outgoing; Wed, 25 Nov 1998 01:50:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA16609 for ; Wed, 25 Nov 1998 01:50:36 -0500 From: mal@bewoner.dma.be Received: from dialup131.brussels.skynet.be by MIT.EDU with SMTP id AA09556; Wed, 25 Nov 98 01:50:26 EST Received: (qmail 16155 invoked by uid 500); 25 Nov 1998 06:57:57 -0000 Date: 25 Nov 1998 06:57:57 -0000 Message-Id: <19981125065757.16154.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Greg Badros Cc: Russell Nelson , scwm-discuss@mit.edu Subject: Re: Scheme tutorial ala scwm-intro-tutorial.scm In-Reply-To: References: <19981123224517.A11752@molehill.org> <19981124223727.22338.qmail@desk.crynwr.com> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > Russell Nelson writes: > > > scwm-intro-tutorial.scm really appeals to me. I did something similar > > for the MINT (MINT Is Not TRAC) language embedded in my Freemacs for > > DOS. Is there a similar scheme tutorial?? > > scwm-intro-tutorial.scm is meant to cover scheme, too. It's targeted > for the fvwm2 user who wants to switch to scwm but hasn't a clue where > to start. I'll complete the tutorial before the new year. > > _The_Little_Schemer_ is the standard scheme book mentioned, but I find > it's style horribly distasteful... > > Greg And it's chockfull of food ;-) Perhaps it's not right for everybody but telling people to read SICP simply to configure their window manager is not going to be popular. And Scheme and the Art of Programming, while being lighter is also rather large. The R^nRS are small but denotational semantics is also not for the faint of hart. Any other suggestions? Lieven From owner-scwm-discuss@mit.edu Wed Nov 25 02:30:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA16838 for scwm-discuss-outgoing; Wed, 25 Nov 1998 02:30:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA16835 for ; Wed, 25 Nov 1998 02:30:19 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AB11755; Wed, 25 Nov 98 02:30:12 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id IAA19558 for scwm-discuss@mit.edu; Wed, 25 Nov 1998 08:14:34 +0100 (MET) Received: (qmail 16682 invoked by uid 115); 24 Nov 1998 20:59:24 -0000 To: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 24 Nov 1998 21:59:19 +0100 In-Reply-To: hjstein@bfr.co.il's message of "24 Nov 1998 10:41:10 +0200" Message-Id: Lines: 17 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) X-Now-Playing: Stoa - Stoa Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 24 Nov 1998 10:41:10 +0200 >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: Harvey> Isn't the existence of this problem a good reason for this Harvey> gtk window stuff to be a separate process instead of being Harvey> built into the window manager? Oh, you want fvwm modules? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Nov 25 02:31:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA16856 for scwm-discuss-outgoing; Wed, 25 Nov 1998 02:31:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA16853 for ; Wed, 25 Nov 1998 02:31:43 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA11909; Wed, 25 Nov 98 02:31:37 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id IAA19562 for scwm-discuss@mit.edu; Wed, 25 Nov 1998 08:14:38 +0100 (MET) Received: (qmail 18543 invoked by uid 115); 24 Nov 1998 21:02:53 -0000 To: scwm-discuss@mit.edu Subject: Re: options to window-style. References: <199811240402.XAA11291@w20-575-39.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 24 Nov 1998 22:02:52 +0100 In-Reply-To: Maciej Stachowiak's message of "Mon, 23 Nov 1998 23:02:52 EST" Message-Id: Lines: 22 User-Agent: Gnus/5.070052 (Pterodactyl Gnus v0.52) XEmacs/20.4 (Emerald) X-Now-Playing: Stoa - Captivity Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Mon, 23 Nov 1998 23:02:52 EST >>>>> Maciej Stachowiak said: Maciej> I agree this needs to be documented. The problem right now is Maciej> that using various modules can extend the set of style Maciej> keywords, so they need to be documented separately (it would Maciej> really help to be able to have the description of Maciej> `window-style' have a back-link to all modules that define Maciej> style flags). How about a (mandatory?) argument to `add-window-style-option' that contains documentation for the option to be defined. scwmdoc could snarf these out of scwm/scheme/*.scm. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Nov 25 03:38:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18432 for scwm-discuss-outgoing; Wed, 25 Nov 1998 03:38:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA18429 for ; Wed, 25 Nov 1998 03:38:34 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA22866; Wed, 25 Nov 98 03:38:35 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA30707; Wed, 25 Nov 1998 10:38:16 +0200 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 25 Nov 1998 10:38:16 +0200 In-Reply-To: Robert Bihlmeyer's message of "24 Nov 1998 21:59:19 +0100" Message-Id: Lines: 20 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > >>>>> On 24 Nov 1998 10:41:10 +0200 > >>>>> hjstein@bfr.co.il (Harvey J. Stein) said: > > Harvey> Isn't the existence of this problem a good reason for this > Harvey> gtk window stuff to be a separate process instead of being > Harvey> built into the window manager? > > Oh, you want fvwm modules? Given this X problem, a module solution for things like pagers maybe isn't such a bad idea. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 25 03:39:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18440 for scwm-discuss-outgoing; Wed, 25 Nov 1998 03:39:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA18437 for ; Wed, 25 Nov 1998 03:39:03 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA19857; Wed, 25 Nov 98 03:38:55 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA30714; Wed, 25 Nov 1998 10:38:48 +0200 To: Jim Blandy Cc: scwm-discuss@mit.edu Subject: Re: Finding what client a Window belongs to References: <199811240503.AAA11461@w20-575-39.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 25 Nov 1998 10:38:48 +0200 In-Reply-To: Jim Blandy's message of "24 Nov 1998 19:58:52 -0500" Message-Id: Lines: 14 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jim Blandy writes: > > It sucks, doesn't it... > > Separate Address Spaces Considered Harmful > > (No joke! Proof-carrying code is the future, man.) So you're advocating lisp machines then? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Nov 25 04:04:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA18770 for scwm-discuss-outgoing; Wed, 25 Nov 1998 04:04:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA18767 for ; Wed, 25 Nov 1998 04:04:36 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA25204; Wed, 25 Nov 98 04:04:36 EST Received: (qmail 4628 invoked by uid 501); 25 Nov 1998 09:04:50 -0000 Message-Id: <19981125010450.A4605@molehill.org> Date: Wed, 25 Nov 1998 01:04:50 -0800 From: Todd Larason To: scwm-discuss list Subject: menu titles redux Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91i X-Tom-Swifty: "It's a gift from an Oriental friend", said Tom pleasantly. X-Kibo: Let's warm up to allow all the Bible! Sender: owner-scwm-discuss@mit.edu Precedence: bulk We went through this once before, and I thought I knew what direction to go, but working further on it is leading to either lots of duplicated code, or some incredibly ugly functions. Proposal: there's a new menu item flag fIsTitle. At the scheme level, these could be created with a (menutitle) function instead of the normal (menuitem) function. Including more than one title, or a title other than at the beginning of the menu item list, would be possible but lead to undefined results. Any reactions? -- ICQ UIN: 1440772 From owner-scwm-discuss@mit.edu Wed Nov 25 07:50:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id HAA19719 for scwm-discuss-outgoing; Wed, 25 Nov 1998 07:50:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id HAA19716 for ; Wed, 25 Nov 1998 07:50:06 -0500 From: mal@bewoner.dma.be Received: from dialup131.brussels.skynet.be by MIT.EDU with SMTP id AA16231; Wed, 25 Nov 98 07:50:02 EST Received: (qmail 27208 invoked by uid 500); 25 Nov 1998 12:57:49 -0000 Date: 25 Nov 1998 12:57:49 -0000 Message-Id: <19981125125749.27207.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: problems with latest scwm X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Did anything change with respect to hooks? Scwm Version 0.9beta1 compiled on Nov 25 1998 at 11:26:21 RCS_ID=$Id: scwm.c,v 1.153 1998/11/24 11:35:47 robbe Exp $ Repository Timestamp: Tue Nov 24 12:22:34 EST 1998 -- $Revision: 1.954 $ Guile 1.3.1 Copyright (c) 1995, 1996, 1997 Free Software Foundation Guile may be distributed under the terms of the GNU General Public Licence; certain other uses are permitted as well. For details, see the file `COPYING', which is included in the Guile distribution. There is no warranty, to the extent permitted by law. in style.scm the (add-hook! after-new-window-hook ...) fails with the complaint that the first argument to add-hook! is invalid () Lieven From owner-scwm-discuss@mit.edu Wed Nov 25 09:57:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA20241 for scwm-discuss-outgoing; Wed, 25 Nov 1998 09:57:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA20238 for ; Wed, 25 Nov 1998 09:57:09 -0500 From: mal@bewoner.dma.be Received: from dialup131.brussels.skynet.be by MIT.EDU with SMTP id AA17439; Wed, 25 Nov 98 09:57:04 EST Received: (qmail 30698 invoked by uid 500); 25 Nov 1998 15:04:43 -0000 Date: 25 Nov 1998 15:04:42 -0000 Message-Id: <19981125150442.30697.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Problem with hooks follow up X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk To follow up on my own problem report: It seems with this version hook variables have to initialized with (make-hook). There are still some problems left so no patch yet. Lieven From owner-scwm-discuss@mit.edu Wed Nov 25 10:38:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA20482 for scwm-discuss-outgoing; Wed, 25 Nov 1998 10:38:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA20479 for ; Wed, 25 Nov 1998 10:38:01 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26619; Wed, 25 Nov 98 10:37:54 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id HAA06799; Wed, 25 Nov 1998 07:37:48 -0800 (PST) To: Todd Larason Cc: scwm-discuss list Subject: Re: menu titles redux References: <19981125010450.A4605@molehill.org> From: Greg Badros Date: 25 Nov 1998 07:37:47 -0800 In-Reply-To: Todd Larason's message of "Wed, 25 Nov 1998 01:04:50 -0800" Message-Id: Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > We went through this once before, and I thought I knew what direction to go, > but working further on it is leading to either lots of duplicated code, or > some incredibly ugly functions. > > Proposal: there's a new menu item flag fIsTitle. At the scheme level, these > could be created with a (menutitle) function instead of the normal (menuitem) > function. Including more than one title, or a title other than at the > beginning of the menu item list, would be possible but lead to undefined > results. > > Any reactions? Clearly we need something and this seems reasonable. It's probably easiest if make-menuitem just takes another arg and menutitle is just another wrapper. Greg From owner-scwm-discuss@mit.edu Wed Nov 25 16:20:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA21942 for scwm-discuss-outgoing; Wed, 25 Nov 1998 16:20:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA21939 for ; Wed, 25 Nov 1998 16:20:39 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA18741; Wed, 25 Nov 98 16:20:36 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id QAA04700 for ; Wed, 25 Nov 1998 16:20:04 -0500 (EST) Message-Id: <199811252120.QAA04700@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: scwm-discuss@mit.edu Subject: that unruly netscape Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Nov 1998 16:10:09 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Using netscape4.03 under Irix. Is there any trick to getting it to obey the icon box? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Wed Nov 25 18:23:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA22457 for scwm-discuss-outgoing; Wed, 25 Nov 1998 18:23:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA22454 for ; Wed, 25 Nov 1998 18:23:37 -0500 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA15113; Wed, 25 Nov 98 18:23:37 EST Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id AAA20927; Thu, 26 Nov 1998 00:23:30 +0100 (MET) To: mal@bewoner.dma.be Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <19981125150442.30697.qmail@localhost.localdomain> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 26 Nov 1998 00:23:30 +0100 In-Reply-To: mal@bewoner.dma.be's message of 25 Nov 1998 15:04:42 -0000 Message-Id: Lines: 15 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > To follow up on my own problem report: > > It seems with this version hook variables have to initialized with > (make-hook). There are still some problems left so no patch yet. I've now committed a patch to guile-core in order to be backward compatible for a while until you guys have had time to adapt to the new hooks. (I'm sorry, I had regarded these hook functions as an internal affair, but that was obviously silly.) /mdj From owner-scwm-discuss@mit.edu Thu Nov 26 02:23:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA24528 for scwm-discuss-outgoing; Thu, 26 Nov 1998 02:23:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA24525 for ; Thu, 26 Nov 1998 02:23:35 -0500 From: mal@bewoner.dma.be Received: from dialup431.brussels.skynet.be by MIT.EDU with SMTP id AA24771; Thu, 26 Nov 98 02:23:13 EST Received: (qmail 25560 invoked by uid 500); 26 Nov 1998 07:30:57 -0000 Date: 26 Nov 1998 07:30:57 -0000 Message-Id: <19981126073057.25559.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mikael Djurfeldt Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-Reply-To: References: <19981125150442.30697.qmail@localhost.localdomain> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mikael Djurfeldt writes: > mal@bewoner.dma.be writes: > > > To follow up on my own problem report: > > > > It seems with this version hook variables have to initialized with > > (make-hook). There are still some problems left so no patch yet. > > I've now committed a patch to guile-core in order to be backward > compatible for a while until you guys have had time to adapt to the > new hooks. > > (I'm sorry, I had regarded these hook functions as an internal affair, > but that was obviously silly.) > > /mdj The remaining problem I had was that simply in the .scm writing (define after-new-window-hook (make-hook)) (add-hook! after-new-window-hook ...... didn't work. It works if you start up scwm, and then manually in scwmrepl typed in the define. Do we need to initialize the hooks in the corresponding C code? Now they just get defined as SCM. Lieven From owner-scwm-discuss@mit.edu Sun Nov 29 04:11:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA16737 for scwm-discuss-outgoing; Sun, 29 Nov 1998 04:11:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA16731 for ; Sun, 29 Nov 1998 04:10:59 -0500 Received: from gull58.cruzio.com by MIT.EDU with SMTP id AA02463; Sun, 29 Nov 98 04:09:42 EST Received: (from trux@localhost) by sugar.truxton.com (8.8.7/8.8.7) id BAA30507; Sun, 29 Nov 1998 01:09:04 -0800 To: scwm-discuss@mit.edu Subject: typo in scwm-icons-19981128/mini-icons/Makefile.in From: Truxton King Fulton II Date: 29 Nov 1998 01:09:02 -0800 Message-Id: Lines: 8 X-Mailer: Gnus v5.6.42/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 29c29 < for i in *.xpm; do ${INSTALL_DATA} $$i ${pixmap_dir}; done --- > for i in *.xpm; do ${INSTALL_DATA} $$i ${mini_icon_dir}; done Cheers, -Truxton From owner-scwm-discuss@mit.edu Mon Nov 30 06:08:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id GAA24813 for scwm-discuss-outgoing; Mon, 30 Nov 1998 06:08:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id GAA24810 for ; Mon, 30 Nov 1998 06:08:24 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA11082; Mon, 30 Nov 98 06:07:34 EST Received: (qmail 28687 invoked by uid 501); 30 Nov 1998 11:10:27 -0000 Message-Id: <19981130031026.A28642@molehill.org> Date: Mon, 30 Nov 1998 03:10:26 -0800 From: Todd Larason To: psmith@BayNetworks.COM, Dominik Vogt Cc: fvwm-workers@hpc.uh.edu, scwm-discuss list Subject: Re: future of fvwm2 (featuritis?) References: <19981125202955.R8910@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: ; from Paul D. Smith on Sun, Nov 29, 1998 at 11:07:25PM -0800 X-Kibo: Xibo could seem related to Jesus. Sender: owner-scwm-discuss@mit.edu Precedence: bulk At the risk of boring everyone... On 981129, Paul D. Smith wrote: > 2) Config file syntax. I hate to bring up this bugaboo again, but the > current syntax makes me nuts. Plus, it seems like every time we > turn around someone is adding a new feature that requires some new > syntax, and much of it is added fairly helter-skelter. This is always the problem with configuration languages - they grow, and grow, and grow. And they don't always grow very coherently. > 4) My pet feature request: an icon manager that allows me to "group" > windows by class (or instance, etc.) and, when iconfied, all windows > in that class have only one icon. When that icon is selected, a > popup menu containing a list of windows in that group is provided. In scwm: (define xterm-window? (class-match?? "XTerm")) (define (popup-icon-menu) (cond ((xterm-window? (get-window)) (show-window-list-menu #:only (lambda (win) (and (xterm-window? win) (iconified? win))))) (else (popup-menu 'menu-window-actions)))) (bind-mouse 'icon 3 popup-icon-menu) will give you the kind of menu you're looking for, for xterm icons. Adding a small, straight forward patch: diff -u -p -r1.39 Makefile.am --- Makefile.am 1998/11/16 22:43:11 1.39 +++ Makefile.am 1998/11/30 11:03:32 @@ -89,7 +89,7 @@ guile_snarfs = Grab.x add_window.x bindi decor.x deskpage.x events.x face.x font.x image.x menu.x menuitem.x \ miscprocs.x module-interface.x move.x placement.x resize.x \ screen.x shutdown.x window.x xproperty.x xrm.x constraint-primitives.x \ -drawmenu.x menulook.x virtual.x +drawmenu.x menulook.x virtual.x icons.x BUILT_SOURCES = init_scheme_string.c scwmpaths.h scm_init_funcs.h \ $(guile_snarfs) diff -u -p -r1.47 icons.c --- icons.c 1998/11/18 00:04:15 1.47 +++ icons.c 1998/11/30 11:03:35 @@ -42,6 +42,10 @@ #include "color.h" #include "focus.h" #include "xmisc.h" +#include "callbacks.h" + +static SCM iconify_hook; +static SCM deiconify_hook; /*********************************************************************** * @@ -688,6 +692,7 @@ DeIconify(ScwmWindow *psw) if (t->icon_pixmap_w) XUnmapWindow(dpy, t->icon_pixmap_w); Broadcast(M_DEICONIFY, 3, t->w, t->frame, (unsigned long) t, 0, 0, 0, 0); + call1_hooks(deiconify_hook, t->schwin); } } @@ -749,6 +754,7 @@ Iconify(ScwmWindow *psw, int def_x, int BroadcastIconInfo(M_ICONIFY,t); BroadcastConfig(M_CONFIGURE_WINDOW, t); + call1_hooks(iconify_hook, t->schwin); } } } @@ -771,6 +777,7 @@ Iconify(ScwmWindow *psw, int def_x, int psw->fIconUnmapped = False; BroadcastIconInfo(M_ICONIFY, psw); BroadcastConfig(M_CONFIGURE_WINDOW, psw); + call1_hooks(iconify_hook, psw->schwin); LowerWindow(psw); @@ -831,6 +838,23 @@ SetMapStateProp(ScwmWindow *psw, int sta PropModeReplace, (unsigned char *) data, 2); return; } + +void +init_icons() +{ + SCWM_HOOK(iconify_hook, "iconify-hook"); + /** This hook is invoked when a window is iconified. +It is called with one argument, WINDOW */ + + SCWM_HOOK(deiconify_hook, "deiconify-hook"); + /** This hook is invoked when a window is deiconified. +It is called with one argument, WINDOW */ + +#ifndef SCM_MAGIC_SNARFER +#include "icons.x" +#endif +} + /* Local Variables: */ /* tab-width: 8 */ diff -u -p -r1.153 scwm.c --- scwm.c 1998/11/24 11:35:47 1.153 +++ scwm.c 1998/11/30 11:03:50 @@ -556,6 +556,7 @@ scwm_main(int argc, char **argv) init_placement(); init_Grab(); init_virtual(); + init_icons(); #ifdef USE_CASSOWARY init_constraint_primitives(); #endif And the following comes very close to giving you only one icon for xterms: (define current-xterm-icon-window #f) (define (xterm-iconify-hook window) (cond ((xterm-window? window) (cond ((not current-xterm-icon-window) (set! current-xterm-icon-window window) (map (lambda (win) (cond ((not (eq? win window)) (set-show-icon! #f win)))) (list-windows #:only (lambda (win) (and (xterm-window? win) (not (iconified? win))))))))))) (define (xterm-deiconify-hook window) (cond ((and (xterm-window? window) (eq? window current-xterm-icon-window)) (let ((iconified-xterm-list (list-windows #:only (lambda (win) (and (xterm-window? win) (iconified? win)))))) (cond ((eq? iconified-xterm-list ()) (map (lambda (win) (set-show-icon! #t win)) (list-windows #:only (lambda (win) (and (xterm-window? win) (not (iconified? win))))))) (else (set-show-icon! #t (car iconified-xterm-list)))))))) (add-hook! iconify-hook xterm-iconify-hook) (add-hook! deiconify-hook xterm-deiconify-hook) I think all that's needed to finish it is to hook into new-window and set-show-icon! appropriately for new xterms, depending on whether or not there's currently an xterm icon showing. It's late, though, and I'm supposed to be getting back on a normal schedule... I expect the one-icon part can be done better. I'm not a scheme expert by any means, and this was a half hour hack, C change included. -- ICQ UIN: 37961006 From owner-scwm-discuss@mit.edu Mon Nov 30 16:17:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA27718 for scwm-discuss-outgoing; Mon, 30 Nov 1998 16:17:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id QAA27712 for ; Mon, 30 Nov 1998 16:16:59 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 30 Nov 1998 16:15:48 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 30 Nov 1998 16:15:48 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id VAA06423; Mon, 30 Nov 1998 21:15:46 GMT To: Maciej Stachowiak Subject: `animated-move-to' Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 30 Nov 1998 21:15:46 +0000 Message-ID: Lines: 13 Sender: owner-scwm-discuss@mit.edu Precedence: bulk `animated-move-to' was moved to animation.scm about 10 days ago. at about the same time it became broken in various ways (not accepting 'x and 'y as arguments, doing the wrong thing when given -1 etc). Why was this done? Is it possible to restore the original version? Thanks. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Computer are like air conditioners: they don't work with open windows! From owner-scwm-discuss@mit.edu Mon Nov 30 16:54:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA28213 for scwm-discuss-outgoing; Mon, 30 Nov 1998 16:54:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA28206; Mon, 30 Nov 1998 16:54:44 -0500 Message-Id: <199811302154.QAA28206@vicarious-existence.mit.edu> To: sds@goems.com cc: scwm-discuss@mit.edu Subject: Re: `animated-move-to' In-reply-to: Your message of "30 Nov 1998 21:15:46 GMT." Date: Mon, 30 Nov 1998 16:54:44 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > `animated-move-to' was moved to animation.scm about 10 days ago. > at about the same time it became broken in various ways (not accepting > 'x and 'y as arguments, doing the wrong thing when given -1 etc). > Why was this done? > > Is it possible to restore the original version? I thought that some of the things were inappropriate things to have in this wrapper. In particular: * You can get the effect of 'x/'y by passing #f. I think 'x/'y is misleading because, e.g. (animated-move-to 'y 'x win) will _not_ transpose win's coordinates. Thus we should standardize on #f. Better yet, animated-move-window (the virtual coordinate version) accepts #f as well so there is greater consistency. * I think passing -1 as a way of indicating the right/bottom edge of the window should be aligned with the right/bottom edge of the screen is bad design. For one thing, there is no way to pass -0 and have the right thing happen; for another, I don't like behavior overloading based on the sign of the number like that. Finally, it is a valid and possibly desirable operation to move a window to a negative screen coordinate (maybe I want it exactly half off the current virtual screen). There are ways to work around the lack of the negative coordinate feature presently (see the gjb.scwmrc or sds.scwmrc in CVS) but they are annoyingly verbose. Thus I have thought about this and I think a better and more general solution is to allow passing the gravity of the control point of the move to mover functions. For instance, if you wanted to move the lower right corner of WIN to the lower right corner of the screen, you would do (under this hypothetical interface): (animated-move-to display-width display-height WIN 'south-east) ;; maybe this should be 'southeast or 'se To move the right edge to the right side you would do: (animated-move-to display-width #f WIN 'east) To move the window center to the center of the screen you would do: (animated-move-to (/ display-width 2) (/ display-height 2) WIN 'center) To move to X, Y as normal: (animated-move-to X Y WIN 'north-west) 'north-west should be the default of course. Possible extension: allow the "gravity" specs to optionally be a list of x/y percentages not just one of a corner, an edge or the center. The same thing goes for animated-move-window and the non-animated versions of course. I'm seeing more and more need for {animated-move-}window to take keyword arguments, but that's a pain to do from C right now, sigh. Any comments on this proposed interface? I think it is much more intuitive than the whole negative number thing, as I believe my examples above show. - Maciej From owner-scwm-discuss@mit.edu Mon Nov 30 17:18:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA28414 for scwm-discuss-outgoing; Mon, 30 Nov 1998 17:18:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA28411 for ; Mon, 30 Nov 1998 17:18:03 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA24922; Mon, 30 Nov 98 17:16:54 EST Received: (qmail 59 invoked by uid 501); 30 Nov 1998 22:20:42 -0000 Message-Id: <19981130142042.A32710@molehill.org> Date: Mon, 30 Nov 1998 14:20:42 -0800 From: Todd Larason To: Maciej Stachowiak , sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: `animated-move-to' References: <199811302154.QAA28206@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199811302154.QAA28206@vicarious-existence.mit.edu>; from Maciej Stachowiak on Mon, Nov 30, 1998 at 04:54:44PM -0500 X-Kibo: Vril and odyle are not flowers and all the atoms in the Universe, U for Useless, and television. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981130, Maciej Stachowiak wrote: > For instance, if you wanted to move the lower right corner of WIN to > the lower right corner of the screen, you would do (under this > hypothetical interface): > > (animated-move-to display-width display-height WIN 'south-east) > ;; maybe this should be 'southeast or 'se You might want to look at the message-window positioning (set-message-window-position! primitive and position-message-window! wrapper). The primitive takes two 'multiplier' values, one for x and one for y. The multipliers are multiplied by the width/height of the window and the result added to the coordinate given, to give the final coordinate for the NW corner. Certainly not the most intuitive interface, but it allows all the standard gravities as well as more variety. position-message-window! maps gravity symbols to the multipliers. -- ICQ UIN: 13046735 From owner-scwm-discuss@mit.edu Mon Nov 30 18:31:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA30567 for scwm-discuss-outgoing; Mon, 30 Nov 1998 18:31:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA30564 for ; Mon, 30 Nov 1998 18:31:37 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA17078; Mon, 30 Nov 98 18:30:27 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Tue, 1 Dec 1998 00:30:27 +0100 Received: from enterprise.osterwald.de (root@h08.ts1.uni-hannover.de [130.75.249.8]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id AAA07512 for ; Tue, 1 Dec 1998 00:30:20 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id AAA00617; Tue, 1 Dec 1998 00:12:57 +0100 From: Heiko Muenkel Message-Id: <13923.9848.34695.780686@enterprise.osterwald.de> Date: Tue, 1 Dec 1998 00:12:56 +0100 (MET) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: Problems with scwm and FvwmButtons X-Mailer: VM 6.62 under 21.2 "Aglaophonos-pre1" XEmacs Lucid (beta3) X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H 0 # # #t # . "FvwmButtons"); terminating connection. packet: (0 17 "SET_MASK 9227263 " 1) packet: (0 15 "Send_ConfigInfo" 1) packet: (0 15 "Send_WindowList" 1) Thanks for your help and thank you very much to the people who wrote this nice software, Heiko Footnotes: [1] I use already succesfully the FvwmPager. [2] I use scwm-19981113. [3] I tried it also with a non empty ~/.fvwm2rc-scwm-buttons. In this case (~/.fvwm2rc-scwm-buttons contained the same information as in the function call of `register-fvwm2-module-config', but in FVWM2 syntax) the whole X-server crashed. From owner-scwm-discuss@mit.edu Tue Dec 1 10:25:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA03345 for scwm-discuss-outgoing; Tue, 1 Dec 1998 10:25:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA03342 for ; Tue, 1 Dec 1998 10:25:45 -0500 Received: from dns1.tc.net by MIT.EDU with SMTP id AA05670; Tue, 1 Dec 98 10:24:30 EST Received: from [10.16.190.28] by dns1.tc.net for id KAA03300; Tue Dec 1 10:24:21 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id KAA28600; Tue, 1 Dec 1998 10:24:20 -0500 Subject: Re: Problems with scwm and FvwmButtons References: <13923.9848.34695.780686@enterprise.osterwald.de> Date: 01 Dec 1998 10:24:19 -0500 In-Reply-To: Heiko Muenkel's message of "Tue, 1 Dec 1998 00:12:56 +0100 (MET)" Message-Id: Lines: 57 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: Heiko Muenkel From: Doug McNaught Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Heiko Muenkel writes: > I tried to use the FVWM2 module FvwmButtons together with the scwm > without success. Maciej Stachowiak told me, that he has seen reports > of people successfully doing this (Thank you Maciej). It would be nice > if someone could send me an example configuration. Please reply also > direct to my mail address and not only to this list. Here's the relevant section of my .scwmrc: ;;---------------------------------;; ;; use the fvwm2 pager and buttons ;; (set-desk-size! 8 2) (register-fvwm2-module-config "FvwmPager" "*FvwmPagerBack grey76" "*FvwmPagerFore black" "*FvwmPagerHilight navyblue" "*FvwmPagerFont none" "*FvwmPagerDeskTopScale 40" ;; "*FvwmPagerLabel 0 Top" ;; "*FvwmPagerLabel 1 Bottom" "*FvwmPagerGeometry 250x60-1-60" ;; "*FvwmPagerRows 2" ;; "*FvwmPagerColumns 6" "*FvwmPagerSmallFont 5x8") (register-fvwm2-module-config "FvwmButtons" "*FvwmButtonsBack grey76" "*FvwmButtonsFore black" "*FvwmButtonsGeometry 460x60-1-1" "*FvwmButtonsRows 1" "*FvwmButtons(Swallow xclock 'Exec xclock \ -geometry 60x60 -bg grey76')" "*FvwmButtons(Swallow xbiff 'Exec xbiff \ -bg grey76')" "*FvwmButtons(Swallow XLoad 'Exec xload \ -nolabel -geometry 60x60+0+0 -bg grey76 \ -update 5')" "*FvwmButtons(Title xterm, \ Icon /usr/local/include/X11/pixmaps/xterm-linux.xpm, \ Action 'Eval (start-xterm)'" "*FvwmButtons(4x1,Swallow \"Desk 0\" 'Eval \ (run-fvwm2-module \"FvwmPager\" (quote (\"0\" \ \"0\")))')" ) (define fvwm2-buttons (run-fvwm2-module "FvwmButtons")) (window-style "FvwmButtons" #:sticky #t #:no-titlebar #t #:border-width 0) -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Tue Dec 1 12:52:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA04339 for scwm-discuss-outgoing; Tue, 1 Dec 1998 12:52:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA04336 for ; Tue, 1 Dec 1998 12:52:23 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA28363; Tue, 1 Dec 98 12:51:21 EST Received: (qmail 6264 invoked by uid 501); 1 Dec 1998 17:56:01 -0000 Message-Id: <19981201095601.A6123@molehill.org> Date: Tue, 1 Dec 1998 09:56:01 -0800 From: Todd Larason To: scwm-discuss list Subject: [tromey@cygnus.com: Re: Automake and a 'deep' package] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 X-Kibo: If you always ignore the friend of Kibology, you always learn about the Void. Sender: owner-scwm-discuss@mit.edu Precedence: bulk The end of this is interersting - looks like the autobuild bug we've been seeing. ----- Forwarded message from Tom Tromey ----- To: Jeff Garzik Cc: Ben Elliston , Eleftherios Gkioulekas , Bob Friesenhahn , "David S." , automake@gnu.org Subject: Re: Automake and a 'deep' package X-Zippy: ..Everything is....FLIPPING AROUND!! X-Attribution: Tom From: Tom Tromey Date: 30 Nov 1998 23:54:50 -0700 X-Mailer: Gnus v5.5/Emacs 20.2 Ben> I think (??) that automake obtains the list of directories to Ben> descend > to from configure.in. Jeff> This behaviors sounds incorrect. It does not take into account Jeff> hand-crafted Makefiles. SUBDIRS has always worked for me IIRC, Jeff> but I rarely handcraft Makefiles these days too :) Automake's actual algorithm is to look for AC_OUTPUT in configure.in. If a file FOO is listed there, and `FOO.am' exists, then automake will read `FOO.am' and create `FOO.in'. So you *can* use hand-crafted Makefiles in some directories and automake-created Makefiles in other directories. GNU gettext does this if you gettextize an automake-using package. Automake does not use the value of SUBDIRS statically. Ben> That was my understanding. I've never had any problems adding Ben> subdirectories to an automaked project. There actually is a lingering bug. If you add a new directory (to configure.in and SUBDIRS) and just run `make', the new directory won't build correctly. Instead you must run `automake' and `config.status' by hand. Greg Woods (I believe) sent in a patch a long time ago that fixes this. I'll probably apply it one of these days, given that nobody can seem to explain to me why things are currently set up the way they are. Tom ----- End forwarded message ----- -- ICQ UIN: 112113848 From owner-scwm-discuss@mit.edu Tue Dec 1 13:11:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA04496 for scwm-discuss-outgoing; Tue, 1 Dec 1998 13:11:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA04493 for ; Tue, 1 Dec 1998 13:11:07 -0500 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA10049; Tue, 1 Dec 98 13:09:47 EST Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id TAA13442; Tue, 1 Dec 1998 19:09:47 +0100 (MET) To: mal@bewoner.dma.be Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <19981125150442.30697.qmail@localhost.localdomain> <19981126073057.25559.qmail@localhost.localdomain> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 01 Dec 1998 19:09:47 +0100 In-Reply-To: mal@bewoner.dma.be's message of 26 Nov 1998 07:30:57 -0000 Message-Id: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > The remaining problem I had was that simply in the .scm writing > > (define after-new-window-hook (make-hook)) > > (add-hook! after-new-window-hook ...... > > didn't work. But it should work now. Doesn't it? > Do we need to initialize the hooks in the corresponding C code? Yes. You need to do the things corresponding to the `define' above. The easiest way to do this is: scm_make_named_hook ("after-new-window-hook", 0); This will define `after-new-window-hook' to be a new hook with 0 arguments. > Now they just get defined as SCM. (I believe they are also initialized to SCM_EOL.) /mdj From owner-scwm-discuss@mit.edu Tue Dec 1 13:32:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA04799 for scwm-discuss-outgoing; Tue, 1 Dec 1998 13:32:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA04796 for ; Tue, 1 Dec 1998 13:32:33 -0500 Received: from VICARIOUS-EXISTENCE.MIT.EDU by MIT.EDU with SMTP id AA17833; Tue, 1 Dec 98 13:31:16 EST Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA04787; Tue, 1 Dec 1998 13:32:26 -0500 Message-Id: <199812011832.NAA04787@vicarious-existence.mit.edu> To: Mikael Djurfeldt To: mal@bewoner.dma.be Cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-Reply-To: Your message of "01 Dec 1998 19:09:47 +0100." Date: Tue, 01 Dec 1998 13:32:26 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mdj@nada.kth.se writes: > mal@bewoner.dma.be writes: > > > The remaining problem I had was that simply in the .scm writing > > > > (define after-new-window-hook (make-hook)) > > > > (add-hook! after-new-window-hook ...... > > > > didn't work. > > But it should work now. Doesn't it? > > > Do we need to initialize the hooks in the corresponding C code? > > Yes. > > You need to do the things corresponding to the `define' above. > The easiest way to do this is: > > scm_make_named_hook ("after-new-window-hook", 0); > > This will define `after-new-window-hook' to be a new hook with 0 > arguments. > > > Now they just get defined as SCM. > > (I believe they are also initialized to SCM_EOL.) > It seems Guile's hook system has been changed a lot since I last checked, most notably all the C-level support. Unfortunately the new interface is not backwards-compatible. I will have to figure out some way to make both work before the scwm release I guess, or else document it as not working with recent snapshots. - Maciej From owner-scwm-discuss@mit.edu Tue Dec 1 13:51:57 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA05007 for scwm-discuss-outgoing; Tue, 1 Dec 1998 13:51:57 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA05004 for ; Tue, 1 Dec 1998 13:51:56 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA20819; Tue, 1 Dec 98 13:50:55 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id KAA21853; Tue, 1 Dec 1998 10:50:39 -0800 (PST) To: Maciej Stachowiak Cc: Mikael Djurfeldt , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <199812011832.NAA04787@vicarious-existence.mit.edu> From: Greg Badros Date: 01 Dec 1998 10:50:38 -0800 In-Reply-To: Maciej Stachowiak's message of "Tue, 01 Dec 1998 13:32:26 EST" Message-Id: Lines: 25 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > It seems Guile's hook system has been changed a lot since I last > checked, most notably all the C-level support. Unfortunately the new > interface is not backwards-compatible. I will have to figure out some > way to make both work before the scwm release I guess, or else > document it as not working with recent snapshots. At least we already have SCWM_HOOK in use... we can add an extra arg (at each invocation site) that is the number of parameters, and have the macro do the right thing based on an autoconf test. As this code is re-visited, I'd like to improve the documentation about what the hook's arguments will be -- some convention in the comment following the SCWM_HOOK is easiest, but harder to enforce. It needs to be a no-brainer to figure out what the arguments are to your procedure when you add-hook. On a related note, should we drop support for pre-1.3 guiles? It's gonna get even uglier if we keep supporting both old guiles and new beta guiles as well as the latest stable guile. (This may be something to drop after the 0.9 release since it'll require more global changes). Greg From owner-scwm-discuss@mit.edu Tue Dec 1 14:02:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05143 for scwm-discuss-outgoing; Tue, 1 Dec 1998 14:02:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA05140 for ; Tue, 1 Dec 1998 14:02:02 -0500 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA24926; Tue, 1 Dec 98 14:01:00 EST Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id UAA13503; Tue, 1 Dec 1998 20:00:49 +0100 (MET) To: Maciej Stachowiak Cc: mal@bewoner.dma.be, scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <199812011832.NAA04787@vicarious-existence.mit.edu> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 01 Dec 1998 20:00:48 +0100 In-Reply-To: Maciej Stachowiak's message of Tue, 01 Dec 1998 13:32:26 EST Message-Id: Lines: 20 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > It seems Guile's hook system has been changed a lot since I last > checked, most notably all the C-level support. There was no C-level support for hooks in Guile previously. (Tell me if I'm wrong. Sometimes I have a memory like a swiss cheese.) > Unfortunately the new interface is not backwards-compatible. I will > have to figure out some way to make both work before the scwm > release I guess, or else document it as not working with recent > snapshots. As I said in a previous message, I have put in code in boot-9.scm to make it backwards compatible, so there should be no problem until we decide to remove this extra code from boot-9.scm. Tell me if it is. /mdj From owner-scwm-discuss@mit.edu Tue Dec 1 14:12:29 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05289 for scwm-discuss-outgoing; Tue, 1 Dec 1998 14:12:29 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05268; Tue, 1 Dec 1998 14:12:11 -0500 Message-Id: <199812011912.OAA05268@vicarious-existence.mit.edu> To: Greg Badros cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-reply-to: Your message of "01 Dec 1998 10:50:38 PST." Date: Tue, 01 Dec 1998 14:12:11 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > > > It seems Guile's hook system has been changed a lot since I last > > checked, most notably all the C-level support. Unfortunately the new > > interface is not backwards-compatible. I will have to figure out some > > way to make both work before the scwm release I guess, or else > > document it as not working with recent snapshots. > > At least we already have SCWM_HOOK in use... we can add an extra arg (at > each invocation site) that is the number of parameters, and have the > macro do the right thing based on an autoconf test. Yep, that almost handles it, except that all the callN_hooks functions will have to be adjusted to deal with the new format as appropriate (we can't just use Guile's new run_hooks directly because scwm's versions try to catch and display errors per each hook procedure called). However, one positive consequence of the new non-macro-based hook system is that it will be possible to make input and timer hooks work (almost) just like normal hooks. I consider this a good thing, but I'm not going to make changes dependent on it until there is a stable Guile release with these changes. > As this code is re-visited, I'd like to improve the documentation > about what the hook's arguments will be -- some convention in the > comment following the SCWM_HOOK is easiest, but harder to enforce. > It needs to be a no-brainer to figure out what the arguments are to > your procedure when you add-hook. You're right. I think this information should be in the doc comment, and automated checking can compare the number of arguments as defined in the comment with the number of arguments in the relevant macro. > > On a related note, should we drop support for pre-1.3 guiles? It's > gonna get even uglier if we keep supporting both old guiles and new beta > guiles as well as the latest stable guile. (This may be something to > drop after the 0.9 release since it'll require more global changes). 0.9 will be the last release for which I will care about pre-1.3 versions. I might be too lazy to explicitly remove 1.2, etc support immediately after that, but I would accept patches to do so (such a change would do a lot to clean up configure.in and many areas of the code). - Maciej From owner-scwm-discuss@mit.edu Tue Dec 1 14:16:57 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05386 for scwm-discuss-outgoing; Tue, 1 Dec 1998 14:16:57 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05380; Tue, 1 Dec 1998 14:16:55 -0500 Message-Id: <199812011916.OAA05380@vicarious-existence.mit.edu> To: Mikael Djurfeldt cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-reply-to: Your message of "01 Dec 1998 20:00:48 +0100." Date: Tue, 01 Dec 1998 14:16:55 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mdj@nada.kth.se writes: > Maciej Stachowiak writes: > > > It seems Guile's hook system has been changed a lot since I last > > checked, most notably all the C-level support. > > There was no C-level support for hooks in Guile previously. > (Tell me if I'm wrong. Sometimes I have a memory like a swiss cheese.) > Yes, I meant that all the C-level support is new. > > Unfortunately the new interface is not backwards-compatible. I will > > have to figure out some way to make both work before the scwm > > release I guess, or else document it as not working with recent > > snapshots. > > As I said in a previous message, I have put in code in boot-9.scm to > make it backwards compatible, so there should be no problem until we > decide to remove this extra code from boot-9.scm. > > Tell me if it is. I think I must have missed that message (I should rescan my Guile mailbox). OK, I don't think there will be a problem then. I would appreciate it if you removed the warning (or at least provided an option to silence it somehow) since scwm uses old-style hooks extensively and scwm's C interface to them depends on the old internal representation, so it will take a bit of work to make scwm work nicely with either representation. - Maciej From owner-scwm-discuss@mit.edu Tue Dec 1 14:29:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA05647 for scwm-discuss-outgoing; Tue, 1 Dec 1998 14:29:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA05644 for ; Tue, 1 Dec 1998 14:28:54 -0500 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA09821; Tue, 1 Dec 98 14:27:37 EST Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id UAA13532; Tue, 1 Dec 1998 20:27:39 +0100 (MET) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <199812011916.OAA05380@vicarious-existence.mit.edu> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 01 Dec 1998 20:27:39 +0100 In-Reply-To: Maciej Stachowiak's message of Tue, 01 Dec 1998 14:16:55 EST Message-Id: Lines: 54 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > As I said in a previous message, I have put in code in boot-9.scm to > > make it backwards compatible, so there should be no problem until we > > decide to remove this extra code from boot-9.scm. > > > > Tell me if it is. > > I think I must have missed that message (I should rescan my Guile > mailbox). I was referring to this: ------- Start of forwarded message ------- To: mal@bewoner.dma.be Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up References: <19981125150442.30697.qmail@localhost.localdomain> Cc: mdj@nada.kth.se From: Mikael Djurfeldt Date: 26 Nov 1998 00:23:30 +0100 Message-ID: mal@bewoner.dma.be writes: > To follow up on my own problem report: > > It seems with this version hook variables have to initialized with > (make-hook). There are still some problems left so no patch yet. I've now committed a patch to guile-core in order to be backward compatible for a while until you guys have had time to adapt to the new hooks. (I'm sorry, I had regarded these hook functions as an internal affair, but that was obviously silly.) /mdj ------- End of forwarded message ------- > OK, I don't think there will be a problem then. I would appreciate it > if you removed the warning (or at least provided an option to silence > it somehow) since scwm uses old-style hooks extensively and scwm's C > interface to them depends on the old internal representation, so it > will take a bit of work to make scwm work nicely with either > representation. 1998-12-01 Mikael Djurfeldt * boot-9.scm (*suppress-old-style-hook-warning*): Set this to #t if you don't want the old style hook warnings. /mdj From owner-scwm-discuss@mit.edu Tue Dec 1 16:20:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA06847 for scwm-discuss-outgoing; Tue, 1 Dec 1998 16:20:20 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA06844 for ; Tue, 1 Dec 1998 16:20:16 -0500 Received: from talisker.channelpoint.com by MIT.EDU with SMTP id AA19022; Tue, 1 Dec 98 16:19:06 EST Received: (from samf@localhost) by talisker.channelpoint.com (8.9.1/8.9.1) id OAA14887; Tue, 1 Dec 1998 14:18:57 -0700 (MST) To: scwm-discuss@mit.edu Subject: obscureCursor Mime-Version: 1.0 From: Sam Falkner Date: 01 Dec 1998 14:18:56 -0700 Message-Id: Lines: 25 User-Agent: Gnus/5.070056 (Pterodactyl Gnus v0.56) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk many millions of years ago i wrote a pascal program on my 128k mac, and used a function called `obscureCursor' to make the mouse cursor disappear until the next mouse event. of course, this was just one specific behavior in my puny little application. what i'd like is to be able to, throughout my X session, is to make the mouse cursor disappear when it's not in use, regardless of which app has focus. maybe upon getting a keyboard event, or maybe after a certain time has elapsed with no mouse events, the cursor would disappear. but, upon getting any mouse event (like a move or a button), the mouse cursor would re-appear. about the only downside i can think of is that i wouldn't see an hourglass cursor when xemacs is doing a garbage collect, but i can live with that. in fact, i bet it would be easy in scwm to drop this behavior when certain special windows have focus... call me crazy, but i hate mice. i find them useful about 1% of the time, and would like to live without them the other 99%. i'd really like to do this; is this possible now? if not, can it be kept in mind when designing the great event rewrite, or whatever is needed? thanks in advance for any pointers! - sam From owner-scwm-discuss@mit.edu Tue Dec 1 16:45:04 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA07032 for scwm-discuss-outgoing; Tue, 1 Dec 1998 16:45:04 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA07026 for ; Tue, 1 Dec 1998 16:44:51 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA29862; Tue, 1 Dec 98 16:40:25 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id NAA22257; Tue, 1 Dec 1998 13:40:04 -0800 (PST) To: Sam Falkner Cc: scwm-discuss@mit.edu Subject: Re: obscureCursor References: From: Greg Badros Date: 01 Dec 1998 13:40:03 -0800 In-Reply-To: Sam Falkner's message of "01 Dec 1998 14:18:56 -0700" Message-Id: Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Falkner writes: > many millions of years ago i wrote a pascal program on my 128k mac, > and used a function called `obscureCursor' to make the mouse cursor > disappear until the next mouse event. of course, this was just one > specific behavior in my puny little application. Try searching for 'unclutter' -- probably at X11 contrib mirrors. > call me crazy, but i hate mice. i find them useful about 1% of the me too! Though they're *really* useful that 1% that they are useful. Greg From owner-scwm-discuss@mit.edu Tue Dec 1 17:05:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA07198 for scwm-discuss-outgoing; Tue, 1 Dec 1998 17:05:07 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA07195 for ; Tue, 1 Dec 1998 17:05:05 -0500 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA06444; Tue, 1 Dec 98 17:04:03 EST Received: from ypmaster.artisan.com (ypmaster [172.16.2.1]) by bastion.artisan.com (8.9.1/8.9.0) with ESMTP id OAA01077 for ; Tue, 1 Dec 1998 14:03:42 -0800 (PST) Received: from lamb.artisan.com (lamb [172.16.10.20]) by ypmaster.artisan.com (8.8.4/8.8.4) with ESMTP id OAA15993 for ; Tue, 1 Dec 1998 14:03:54 -0800 (PST) Received: (from alt@localhost) by lamb.artisan.com (8.8.8/8.8.4) id OAA03003; Tue, 1 Dec 1998 14:03:54 -0800 (PST) X-Authentication-Warning: lamb.artisan.com: alt set sender to alt@lamb.artisan.com using -f From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13924.26570.724249.986341@lamb.artisan.com> Date: Tue, 1 Dec 1998 14:03:54 -0800 (PST) To: scwm-discuss@mit.edu Subject: documentation X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't had much luck creating the html files (or any documentation) using sgml/jade. Could you possibly provide the documentation at the scwm web site? Thanks, Albert From owner-scwm-discuss@mit.edu Tue Dec 1 17:09:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA07267 for scwm-discuss-outgoing; Tue, 1 Dec 1998 17:09:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA07264 for ; Tue, 1 Dec 1998 17:09:10 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA09511; Tue, 1 Dec 98 17:07:45 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 01 Dec 1998 16:48:33 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 01 Dec 1998 16:48:32 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id QAA21345; Tue, 1 Dec 1998 16:48:21 -0500 To: scwm-discuss@mit.edu Subject: Re: obscureCursor References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Sam Falkner's message of "01 Dec 1998 14:18:56 -0700" Date: 01 Dec 1998 16:48:21 -0500 Message-Id: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "obscureCursor" >>>> Sent on 01 Dec 1998 14:18:56 -0700 >>>> Honorable Sam Falkner writes: >> many millions of years ago i wrote a pascal program on my 128k mac, I didn't know you were a dinosaur! >> what i'd like is to be able to, throughout my X session, is to make >> the mouse cursor disappear when it's not in use, regardless of which >> app has focus. maybe upon getting a keyboard event, or maybe after a >> certain time has elapsed with no mouse events, the cursor would >> disappear. but, upon getting any mouse event (like a move or a >> button), the mouse cursor would re-appear. This would be nice. Another nice thing would be to duplicate the w3.1 optional behavior: when you hit left (or right?) Ctrl, the mouse pointer is nicely shown (with concentric circles in the MS case, I don't care how it is done in SCWM, but I hate to scan the screen pixel by pixel looking for the X pointer). >> about the only downside i can think of is that i wouldn't see an >> hourglass cursor when xemacs is doing a garbage collect, but i can >> live with that. in fact, i bet it would be easy in scwm to drop this >> behavior when certain special windows have focus... This shouldn't be a problem: when for some reason the mouse pointer's shape changes, it should become visible anyway. >> call me crazy, but i hate mice. You are not alone in you idiosyncrasy: I hate snakes and bee-like insects. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. You can have it good, soon or cheap. Pick two... From owner-scwm-discuss@mit.edu Tue Dec 1 17:30:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA07588 for scwm-discuss-outgoing; Tue, 1 Dec 1998 17:30:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA07578 for ; Tue, 1 Dec 1998 17:29:59 -0500 Received: from mail.citycom.com by MIT.EDU with SMTP id AA18669; Tue, 1 Dec 98 17:28:36 EST Received: from yasmeen (38.28.61.55) by citycom.com with SMTP (Eudora Internet Mail Server 2.2); Tue, 1 Dec 1998 14:27:49 -0800 Message-Id: <000301be1d79$11ee49b0$373d1c26@yasmeen.citycom.com> From: "Jason Nordwick" To: , "Sam Falkner" Subject: Re: obscureCursor Date: Tue, 1 Dec 1998 13:56:06 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk There is a program that already does this. Its called unclutter. I don't know where to find it though (If using FreeBSD, then it is in the ports collection somewhere). -jay From owner-scwm-discuss@mit.edu Tue Dec 1 18:07:56 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA07977 for scwm-discuss-outgoing; Tue, 1 Dec 1998 18:07:56 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA07974 for ; Tue, 1 Dec 1998 18:07:54 -0500 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA01364; Tue, 1 Dec 98 18:06:35 EST Received: from ypmaster.artisan.com (ypmaster [172.16.2.1]) by bastion.artisan.com (8.9.1/8.9.0) with ESMTP id PAA04684 for ; Tue, 1 Dec 1998 15:06:31 -0800 (PST) Received: from lamb.artisan.com (lamb [172.16.10.20]) by ypmaster.artisan.com (8.8.4/8.8.4) with ESMTP id PAA18577 for ; Tue, 1 Dec 1998 15:06:44 -0800 (PST) Received: (from alt@localhost) by lamb.artisan.com (8.8.8/8.8.4) id PAA03560; Tue, 1 Dec 1998 15:06:43 -0800 (PST) X-Authentication-Warning: lamb.artisan.com: alt set sender to alt@lamb.artisan.com using -f From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13924.30339.608731.505973@lamb.artisan.com> Date: Tue, 1 Dec 1998 15:06:43 -0800 (PST) To: scwm-discuss@mit.edu Subject: scwm-19981130 icon-box bug X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, It appears that the #:icon-box property is being ignored if the #:sticky property is set to true. The net result is that scwm iconifies the window at the same (x,y) location as the window. Albert From owner-scwm-discuss@mit.edu Tue Dec 1 18:53:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA08413 for scwm-discuss-outgoing; Tue, 1 Dec 1998 18:53:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA08410 for ; Tue, 1 Dec 1998 18:53:42 -0500 Received: from [206.1.51.15] by MIT.EDU with SMTP id AA26733; Tue, 1 Dec 98 16:43:05 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id QAA25111; Tue, 1 Dec 1998 16:40:55 -0500 (EST) Message-Id: <199812012140.QAA25111@jekyll.piermont.com> To: Sam Falkner Cc: scwm-discuss@mit.edu Subject: Re: obscureCursor In-Reply-To: Your message of "01 Dec 1998 14:18:56 MST." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 01 Dec 1998 16:40:55 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Sam Falkner writes: > many millions of years ago i wrote a pascal program on my 128k mac, > and used a function called `obscureCursor' to make the mouse cursor > disappear until the next mouse event. of course, this was just one > specific behavior in my puny little application. > > what i'd like is to be able to, throughout my X session, is to make > the mouse cursor disappear when it's not in use, regardless of which > app has focus. There's a program to do that out there. Unfortunately, I've forgotten the name, but you should be able to find it in the X contributed software distribution. Perry From owner-scwm-discuss@mit.edu Wed Dec 2 00:43:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA13468 for scwm-discuss-outgoing; Wed, 2 Dec 1998 00:43:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id AAA13465 for ; Wed, 2 Dec 1998 00:42:58 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id VAA12863 for ; Tue, 1 Dec 1998 21:41:41 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id VAA14957; Tue, 1 Dec 1998 21:45:06 -0800 Date: Tue, 1 Dec 1998 21:45:06 -0800 Message-Id: <199812020545.VAA14957@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: CVS question/request Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm trying to keep up with anoncvs over a slow modem line. I've noticed that "cvs update" wastes a lot of time (over a minute for each update) comparing files that were modified by the build process. Does anybody know of a way to get CVS not to care about these files during an update? (.cvsignore doesn't help; I tried it.) If not, could you please remove the automatically-generated files (particularly the documentation) from the CVS tree? Thanks, Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Dec 2 00:46:29 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA13511 for scwm-discuss-outgoing; Wed, 2 Dec 1998 00:46:29 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id AAA13508 for ; Wed, 2 Dec 1998 00:46:27 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id VAA12904 for ; Tue, 1 Dec 1998 21:45:10 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id VAA14967; Tue, 1 Dec 1998 21:48:36 -0800 Date: Tue, 1 Dec 1998 21:48:36 -0800 Message-Id: <199812020548.VAA14967@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: question about bug reports/patches Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm going to be sending in a lot of patches to scwm soon (I spent some time this weekend working on the documentation). Would you rather have them split up as much as possible, or coalesced into one big e-mail? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Dec 2 01:13:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA13753 for scwm-discuss-outgoing; Wed, 2 Dec 1998 01:13:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA13750 for ; Wed, 2 Dec 1998 01:13:44 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA13130 for ; Tue, 1 Dec 1998 22:12:25 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA15853; Tue, 1 Dec 1998 22:15:50 -0800 Date: Tue, 1 Dec 1998 22:15:50 -0800 Message-Id: <199812020615.WAA15853@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: scheme/tile.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk scheme/Makefile.am is looking for a file scheme/tile.scm, which does not seem to exist. Did someone forget to check it in? char *szRepoLastChanged = "Tue Dec 1 21:26:44 EST 1998 -- $Revision: 1.962 $"; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Dec 2 02:06:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA14095 for scwm-discuss-outgoing; Wed, 2 Dec 1998 02:06:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA14092 for ; Wed, 2 Dec 1998 02:06:47 -0500 From: mal@bewoner.dma.be Received: from dialup303.brussels.skynet.be by MIT.EDU with SMTP id AA13122; Wed, 2 Dec 98 02:05:18 EST Received: (qmail 13649 invoked by uid 500); 2 Dec 1998 07:05:54 -0000 Date: 2 Dec 1998 07:05:54 -0000 Message-Id: <19981202070554.13648.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Maciej Stachowiak Cc: Mikael Djurfeldt , scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-Reply-To: <199812011832.NAA04787@vicarious-existence.mit.edu> References: <199812011832.NAA04787@vicarious-existence.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > It seems Guile's hook system has been changed a lot since I last > checked, most notably all the C-level support. Unfortunately the new > interface is not backwards-compatible. I will have to figure out some > way to make both work before the scwm release I guess, or else > document it as not working with recent snapshots. > > - Maciej > With the compatibility code Mikael put in boot-9 in the latest snapshots it works transparently. You can just change to the new way of doing things after guile makes a release with the new hook code. BTW: where does scwm redirect the guile error port to? The compatibility code carps about obsolete interface but I don't see it anywhere when starting up scwm. Lieven From owner-scwm-discuss@mit.edu Wed Dec 2 04:44:55 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA15963 for scwm-discuss-outgoing; Wed, 2 Dec 1998 04:44:55 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA15960 for ; Wed, 2 Dec 1998 04:44:53 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA03090; Wed, 2 Dec 98 04:43:29 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Wed, 2 Dec 1998 10:39:10 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id KAA21638; Wed, 2 Dec 1998 10:39:08 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id KAA19259; Wed, 2 Dec 1998 10:39:06 +0100 Date: Wed, 2 Dec 1998 10:39:06 +0100 Message-Id: <199812020939.KAA19259@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: doug@tc.net Cc: scwm-discuss@mit.edu Subject: Re: Problems with scwm and FvwmButtons In-Reply-To: References: <13923.9848.34695.780686@enterprise.osterwald.de> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Doug" == Doug McNaught writes: Doug> Heiko Muenkel writes: >> I tried to use the FVWM2 module FvwmButtons together with the >> scwm without success. Maciej Stachowiak told me, that he has >> seen reports of people successfully doing this (Thank you >> Maciej). It would be nice if someone could send me an example >> configuration. Please reply also direct to my mail address and >> not only to this list. Doug> Here's the relevant section of my .scwmrc: Doug> ;;---------------------------------;; ;; use the fvwm2 pager Doug> and buttons ;; Doug> (set-desk-size! 8 2) Doug> (register-fvwm2-module-config "FvwmPager" "*FvwmPagerBack Doug> grey76" "*FvwmPagerFore black" "*FvwmPagerHilight navyblue" Doug> "*FvwmPagerFont none" "*FvwmPagerDeskTopScale 40" ;; Doug> "*FvwmPagerLabel 0 Top" ;; "*FvwmPagerLabel 1 Bottom" Doug> "*FvwmPagerGeometry 250x60-1-60" ;; "*FvwmPagerRows 2" ;; Doug> "*FvwmPagerColumns 6" "*FvwmPagerSmallFont 5x8") Doug> (register-fvwm2-module-config "FvwmButtons" Doug> "*FvwmButtonsBack grey76" "*FvwmButtonsFore black" Doug> "*FvwmButtonsGeometry 460x60-1-1" "*FvwmButtonsRows 1" Doug> "*FvwmButtons(Swallow xclock 'Exec xclock \ -geometry 60x60 Doug> -bg grey76')" "*FvwmButtons(Swallow xbiff 'Exec xbiff \ -bg Doug> grey76')" "*FvwmButtons(Swallow XLoad 'Exec xload \ -nolabel Doug> -geometry 60x60+0+0 -bg grey76 \ -update 5')" Doug> "*FvwmButtons(Title xterm, \ Icon Doug> /usr/local/include/X11/pixmaps/xterm-linux.xpm, \ Action Doug> 'Eval (start-xterm)'" "*FvwmButtons(4x1,Swallow \"Desk 0\" Doug> 'Eval \ (run-fvwm2-module \"FvwmPager\" (quote (\"0\" \ Doug> \"0\")))')" ) Doug> (define fvwm2-buttons (run-fvwm2-module "FvwmButtons")) Doug> (window-style "FvwmButtons" #:sticky #t #:no-titlebar #t Doug> #:border-width 0) Thanks Doug. Could you please send me also the contents of your ~/.fvwm2rc file? It seems to me, that the FvwmButtons module reads this file and that it's contents are important. Regards Heiko From owner-scwm-discuss@mit.edu Wed Dec 2 04:49:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA16002 for scwm-discuss-outgoing; Wed, 2 Dec 1998 04:49:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA15999 for ; Wed, 2 Dec 1998 04:49:45 -0500 Received: from mail.citycom.com by MIT.EDU with SMTP id AA29370; Wed, 2 Dec 98 04:48:21 EST Received: from yasmeen (38.28.60.87) by citycom.com with SMTP (Eudora Internet Mail Server 2.2); Wed, 2 Dec 1998 01:47:38 -0800 Message-Id: <012e01be1dd8$e7068c20$573c1c26@yasmeen.citycom.com> From: "Jason Nordwick" To: Subject: Can't build scwm 8a. Date: Wed, 2 Dec 1998 01:48:23 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried to build scwm 8a and it said that it couldn't find guile-build (or was it build-guile). After installing Guile, '(version)' reports "1.3". What are the contents of this file? If possible could somebody send me their copy (I'm assuming that it is just a shell script that spits out various install time constants such as basedir). After installing Guile-1.3, there does appear to be a number of executables installed in /usr/local/bin, such as guile-config, but I don't know if this is the same as the one that scwm wants. thanks -jay From owner-scwm-discuss@mit.edu Wed Dec 2 08:48:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17049 for scwm-discuss-outgoing; Wed, 2 Dec 1998 08:48:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17042; Wed, 2 Dec 1998 08:48:37 -0500 Message-Id: <199812021348.IAA17042@vicarious-existence.mit.edu> To: "Carl R. Witty" cc: scwm-discuss@mit.edu Subject: Re: question about bug reports/patches In-reply-to: Your message of "Tue, 01 Dec 1998 21:48:36 PST." <199812020548.VAA14967@nebula.newtonlabs.com> Date: Wed, 02 Dec 1998 08:48:37 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > I'm going to be sending in a lot of patches to scwm soon (I spent some > time this weekend working on the documentation). Would you rather > have them split up as much as possible, or coalesced into one big > e-mail? > I'd personally prefer smaller pieces as long as each makes sense by itself. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 08:47:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17031 for scwm-discuss-outgoing; Wed, 2 Dec 1998 08:47:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17024; Wed, 2 Dec 1998 08:47:01 -0500 Message-Id: <199812021347.IAA17024@vicarious-existence.mit.edu> To: "Carl R. Witty" cc: scwm-discuss@mit.edu Subject: Re: CVS question/request In-reply-to: Your message of "Tue, 01 Dec 1998 21:45:06 PST." <199812020545.VAA14957@nebula.newtonlabs.com> Date: Wed, 02 Dec 1998 08:47:01 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > I'm trying to keep up with anoncvs over a slow modem line. I've > noticed that "cvs update" wastes a lot of time (over a minute for each > update) comparing files that were modified by the build process. Does > anybody know of a way to get CVS not to care about these files during > an update? (.cvsignore doesn't help; I tried it.) > > If not, could you please remove the automatically-generated files > (particularly the documentation) from the CVS tree? > What auto-generated files, other than the documentation, are there? - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 08:54:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17147 for scwm-discuss-outgoing; Wed, 2 Dec 1998 08:54:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17136; Wed, 2 Dec 1998 08:54:08 -0500 Message-Id: <199812021354.IAA17136@vicarious-existence.mit.edu> To: "Carl R. Witty" cc: scwm-discuss@mit.edu Subject: Re: scheme/tile.scm In-reply-to: Your message of "Tue, 01 Dec 1998 22:15:50 PST." <199812020615.WAA15853@nebula.newtonlabs.com> Date: Wed, 02 Dec 1998 08:54:08 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > scheme/Makefile.am is looking for a file scheme/tile.scm, which does > not seem to exist. Did someone forget to check it in? > > char *szRepoLastChanged = "Tue Dec 1 21:26:44 EST 1998 -- $Revision: 1.962 $"; > I forgot to check it in last night, but I also shouldn't have put it in Makefile.am before it was actually done. Now fixed in CVS (by adding the file). - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 08:58:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17236 for scwm-discuss-outgoing; Wed, 2 Dec 1998 08:58:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA17230; Wed, 2 Dec 1998 08:58:33 -0500 Message-Id: <199812021358.IAA17230@vicarious-existence.mit.edu> To: mal@bewoner.dma.be cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-reply-to: Your message of "02 Dec 1998 07:05:54 GMT." <19981202070554.13648.qmail@localhost.localdomain> Date: Wed, 02 Dec 1998 08:58:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mal@bewoner.dma.be writes: > Maciej Stachowiak writes: > > It seems Guile's hook system has been changed a lot since I last > > checked, most notably all the C-level support. Unfortunately the new > > interface is not backwards-compatible. I will have to figure out some > > way to make both work before the scwm release I guess, or else > > document it as not working with recent snapshots. > > > > - Maciej > > > > With the compatibility code Mikael put in boot-9 in the latest > snapshots it works transparently. You can just change to the new way > of doing things after guile makes a release with the new hook code. > I've read the relevant code since posting that. > BTW: where does scwm redirect the guile error port to? The > compatibility code carps about obsolete interface but I don't see it > anywhere when starting up scwm. How do you start it up? If from .xinitrc, then scwm's errors would go wherever xinit's error output goes. I usually start it from an xterm so I can see any error messages on startup more easily. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 09:07:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA17384 for scwm-discuss-outgoing; Wed, 2 Dec 1998 09:07:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA17369; Wed, 2 Dec 1998 09:06:32 -0500 Message-Id: <199812021406.JAA17369@vicarious-existence.mit.edu> To: "Jason Nordwick" cc: scwm-discuss@mit.edu Subject: Re: Can't build scwm 8a. In-reply-to: Your message of "Wed, 02 Dec 1998 01:48:23 PST." <012e01be1dd8$e7068c20$573c1c26@yasmeen.citycom.com> Date: Wed, 02 Dec 1998 09:06:32 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nordwick@citycom.com writes: > > I tried to build scwm 8a and it said that it > couldn't find guile-build (or was it build-guile). > After installing Guile, '(version)' reports "1.3". > > What are the contents of this file? If possible > could somebody send me their copy (I'm assuming > that it is just a shell script that spits out > various install time constants such as basedir). > After installing Guile-1.3, there does appear to > be a number of executables installed in /usr/local/bin, > such as guile-config, but I don't know if this is > the same as the one that scwm wants. > Scwm 0.8a is unfortunately not compatible with Guile 1.3. scwm 0.9beta1 should be. I'm trying to resolve the remaining problems with that and release 0.9 within the next week or two. (If you want to try patching 0.8a to work with guile 1.3 by hand, you can make it check for guile-config instead of build-guile, it is the same script renamed). - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 10:40:45 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA18222 for scwm-discuss-outgoing; Wed, 2 Dec 1998 10:40:45 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA18219 for ; Wed, 2 Dec 1998 10:40:40 -0500 Received: from dns1.tc.net by MIT.EDU with SMTP id AA05426; Wed, 2 Dec 98 10:39:12 EST Received: from [10.16.190.28] by dns1.tc.net for id KAA29128; Wed Dec 2 10:39:17 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id KAA31919; Wed, 2 Dec 1998 10:39:16 -0500 Subject: Re: Problems with scwm and FvwmButtons References: <13923.9848.34695.780686@enterprise.osterwald.de> <199812020939.KAA19259@ull.tnt.uni-hannover.de> Date: 02 Dec 1998 10:39:16 -0500 In-Reply-To: Heiko Muenkel's message of "Wed, 2 Dec 1998 10:39:06 +0100" Message-Id: Lines: 15 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: Heiko Muenkel From: Doug McNaught Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Heiko Muenkel writes: > Thanks Doug. Could you please send me also the contents of your > ~/.fvwm2rc file? It seems to me, that the FvwmButtons module reads > this file and that it's contents are important. Not as far as I know. The stuff you enter with register-fvwm2-module-config replaces the contents of .fvwm2rc (I don't have that file at all). -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Wed Dec 2 10:41:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA18231 for scwm-discuss-outgoing; Wed, 2 Dec 1998 10:41:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA18228 for ; Wed, 2 Dec 1998 10:41:29 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA05692; Wed, 2 Dec 98 10:40:00 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id QAA06726 for scwm-discuss@mit.edu; Wed, 2 Dec 1998 16:21:19 +0100 (MET) Received: (qmail 976 invoked by uid 115); 2 Dec 1998 10:42:50 -0000 To: scwm-discuss@mit.edu Subject: huis-clos references on the web pages X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 02 Dec 1998 11:42:47 +0100 Message-Id: Lines: 12 User-Agent: Gnus/5.070054 (Pterodactyl Gnus v0.54) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, the scwm web pages still have a lot of references to huis-clos.mit.edu. Since this name is no longer canonical, could someone drive sed over the files? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Dec 2 10:43:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA18284 for scwm-discuss-outgoing; Wed, 2 Dec 1998 10:43:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA18280 for ; Wed, 2 Dec 1998 10:43:49 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA06590; Wed, 2 Dec 98 10:42:21 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id QAA06682 for scwm-discuss@mit.edu; Wed, 2 Dec 1998 16:20:42 +0100 (MET) Received: (qmail 959 invoked by uid 115); 2 Dec 1998 10:39:28 -0000 To: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812020545.VAA14957@nebula.newtonlabs.com> X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 02 Dec 1998 11:39:24 +0100 In-Reply-To: "Carl R. Witty"'s message of "Tue, 1 Dec 1998 21:45:06 -0800" Message-Id: Lines: 20 User-Agent: Gnus/5.070054 (Pterodactyl Gnus v0.54) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 1 Dec 1998 21:45:06 -0800 >>>>> "Carl R. Witty" said: Carl> If not, could you please remove the automatically-generated Carl> files (particularly the documentation) from the CVS tree? I'd also vote for this. We would have to generate these when snapshotting, though. And people who fetch from CVS would have to have Text::Balanced. BTW, what is the status of the scheme-Version of the extractor? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Dec 2 10:54:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA18450 for scwm-discuss-outgoing; Wed, 2 Dec 1998 10:54:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA18447 for ; Wed, 2 Dec 1998 10:54:31 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA14923; Wed, 2 Dec 98 10:53:20 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA29179; Wed, 2 Dec 1998 17:52:43 +0200 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812020545.VAA14957@nebula.newtonlabs.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 02 Dec 1998 17:52:43 +0200 In-Reply-To: Robert Bihlmeyer's message of "02 Dec 1998 11:39:24 +0100" Message-Id: Lines: 14 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > BTW, what is the status of the scheme-Version of the extractor? The status is that it doesn't extract as much stuff as the perl version. It's not clear to me exactly what was added to the perl version since I last updated the scheme version. I was going to start reverse engineering the perl version again, but found I had to upgrade perl & haven't gotten around to that yet. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Wed Dec 2 11:06:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA18652 for scwm-discuss-outgoing; Wed, 2 Dec 1998 11:06:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA18649 for ; Wed, 2 Dec 1998 11:06:10 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA19580; Wed, 2 Dec 98 11:04:59 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id IAA28271; Wed, 2 Dec 1998 08:04:39 -0800 (PST) To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812020545.VAA14957@nebula.newtonlabs.com> From: Greg Badros Date: 02 Dec 1998 08:04:38 -0800 In-Reply-To: hjstein@bfr.co.il's message of "02 Dec 1998 17:52:43 +0200" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Robert Bihlmeyer writes: > > > BTW, what is the status of the scheme-Version of the extractor? > > The status is that it doesn't extract as much stuff as the perl > version. It's not clear to me exactly what was added to the perl > version since I last updated the scheme version. I was going to start > reverse engineering the perl version again, but found I had to upgrade > perl & haven't gotten around to that yet. The log files may be of some use: cvs log extract-docs # it's been renamed, but the related log entries # are for the old name I'd try to explain the changes better now, but I don't remember offhand, and time is especially tight right now. Greg From owner-scwm-discuss@mit.edu Wed Dec 2 11:22:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA18753 for scwm-discuss-outgoing; Wed, 2 Dec 1998 11:22:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA18750 for ; Wed, 2 Dec 1998 11:22:40 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA21416; Wed, 2 Dec 98 11:21:01 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Wed, 2 Dec 1998 17:19:54 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id RAA11289; Wed, 2 Dec 1998 17:19:54 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id RAA23108; Wed, 2 Dec 1998 17:19:53 +0100 Date: Wed, 2 Dec 1998 17:19:53 +0100 Message-Id: <199812021619.RAA23108@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: doug@tc.net Cc: scwm-discuss@mit.edu Subject: Re: Problems with scwm and FvwmButtons In-Reply-To: References: <13923.9848.34695.780686@enterprise.osterwald.de> <199812020939.KAA19259@ull.tnt.uni-hannover.de> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Doug" == Doug McNaught writes: Doug> Heiko Muenkel writes: >> Thanks Doug. Could you please send me also the contents of your >> ~/.fvwm2rc file? It seems to me, that the FvwmButtons module >> reads this file and that it's contents are important. Doug> Not as far as I know. The stuff you enter with Doug> register-fvwm2-module-config replaces the contents of Doug> .fvwm2rc (I don't have that file at all). I don't think so, because there is a difference in the behaviour of the scwm, if I've an empty ~/.fvwmrc or no ~/.fvwmrc. If the file is empty, I won't get a FvwmButtons window, but the scwm will not crash with a segmentation fault. If I've no ~/.fvwmrc, the scwm will crash with a segmentation fault. In the case of no ~/.fvwmrc the FvwmButtons module will probably read the system wide Fvwm configuration file. Do you've a system wide Fvwm configuration file (may be /usr/lib/X11/fvwm/.fvwm2rc or /usr/lib/X11/fvwm2/.fvwm2rc) ? Thanks for your help, Heiko From owner-scwm-discuss@mit.edu Wed Dec 2 14:25:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA27698 for scwm-discuss-outgoing; Wed, 2 Dec 1998 14:25:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA27694 for ; Wed, 2 Dec 1998 14:25:31 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA11152; Wed, 2 Dec 98 14:24:18 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA17331 for scwm-discuss@mit.edu; Wed, 2 Dec 1998 20:20:52 +0100 (MET) Received: (qmail 321 invoked by uid 115); 2 Dec 1998 15:30:04 -0000 To: scwm-discuss@mit.edu Subject: docking windows X-Attribution: Robbe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: Robert Bihlmeyer Date: 02 Dec 1998 16:30:01 +0100 Message-Id: Lines: 25 User-Agent: Gnus/5.070054 (Pterodactyl Gnus v0.54) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, even under windoze there are new ideas to be found for the wm writer. Yesterday, I played around with winamp 2.04. As you may know, this thing bypasses windoze's normal window-decorations, and practically implements it's own window managing (one can move its windows by dragging the title bar, etc.). A nice property of this gizmo is, that when moving one winamp-window close to another one, the one you move jumps to the other one (like attracting magnets). It works a bit like scwm's edge-threshold. With edge-threshold, you can't have a window that is less than X pixels outside of the viewport. With window docking you can't have windows that are less than X pixels apart. The details are configurable. I think this would be a fine feature for the TODO. Hacking it into moveLoop before the GER seems not so good an idea. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Dec 2 14:45:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA28361 for scwm-discuss-outgoing; Wed, 2 Dec 1998 14:45:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA28358 for ; Wed, 2 Dec 1998 14:45:21 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA12251; Wed, 2 Dec 98 14:43:51 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id LAA28521; Wed, 2 Dec 1998 11:43:44 -0800 (PST) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: docking windows References: From: Greg Badros Date: 02 Dec 1998 11:43:43 -0800 In-Reply-To: Robert Bihlmeyer's message of "02 Dec 1998 16:30:01 +0100" Message-Id: Lines: 37 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk > A nice property of this gizmo is, that when moving one winamp-window > close to another one, the one you move jumps to the other one (like > attracting magnets). It works a bit like scwm's edge-threshold. With > edge-threshold, you can't have a window that is less than X pixels > outside of the viewport. With window docking you can't have windows > that are less than X pixels apart. The details are configurable. Fvwm2 just added a FvwmAttraction feature like this in an ad-hoc way. I agree that it's nice, and it's on my mental todo list -- in particular a more principled and possibly constraints-integrated way of doing this could be a big win (see, e.g., Eric Bier's "Snap-Dragging", and Michael Gleicher's Briar drawing program: @InProceedings{Bier86, author = {Bier, Eric. A. and Stone, Maureen C.}, title = {Snap-Dragging}, booktitle = {Proceedings of {SIGGRAPH} 1986}, year = 1986, address = {Dallas}, month = {August} } @Article{Gleicher94, author = {Gleicher, Michael and Witkin, Andrew}, title = {Drawing with Constraints}, journal = {Visual Computer}, year = 1994, volume = 11, number = 1, pages = {39-51} } Greg From owner-scwm-discuss@mit.edu Wed Dec 2 15:12:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA28593 for scwm-discuss-outgoing; Wed, 2 Dec 1998 15:12:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA28590 for ; Wed, 2 Dec 1998 15:12:53 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA22882; Wed, 2 Dec 98 15:11:09 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id MAA23665; Wed, 2 Dec 1998 12:10:59 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id MAA14972; Wed, 2 Dec 1998 12:10:57 -0800 To: Maciej Stachowiak Cc: "Carl R. Witty" , scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812021347.IAA17024@vicarious-existence.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 02 Dec 1998 12:10:56 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 08:47:01 EST" Message-Id: Lines: 14 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > cwitty@newtonlabs.com writes: > > If not, could you please remove the automatically-generated files > > (particularly the documentation) from the CVS tree? > > > > What auto-generated files, other than the documentation, are there? scheme/user-options.scm utilities/dev/{X-error-describe,create-dependency-dot-graph,scwm-usage-counter} Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Dec 2 15:26:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA28903 for scwm-discuss-outgoing; Wed, 2 Dec 1998 15:26:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA28894; Wed, 2 Dec 1998 15:26:08 -0500 Message-Id: <199812022026.PAA28894@vicarious-existence.mit.edu> To: Robert Bihlmeyer cc: scwm-discuss@mit.edu Subject: Re: docking windows In-reply-to: Your message of "02 Dec 1998 16:30:01 +0100." Date: Wed, 02 Dec 1998 15:26:08 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > > Hi, > > even under windoze there are new ideas to be found for the wm writer. > > Yesterday, I played around with winamp 2.04. As you may know, this > thing bypasses windoze's normal window-decorations, and practically > implements it's own window managing (one can move its windows by > dragging the title bar, etc.). > > A nice property of this gizmo is, that when moving one winamp-window > close to another one, the one you move jumps to the other one (like > attracting magnets). It works a bit like scwm's edge-threshold. With > edge-threshold, you can't have a window that is less than X pixels > outside of the viewport. With window docking you can't have windows > that are less than X pixels apart. The details are configurable. > > I think this would be a fine feature for the TODO. Hacking it into > moveLoop before the GER seems not so good an idea. > Fvwm now has implemented a similar feature in the core, called "SnapAttraction". I believe it can already be done in scwm at the Scheme level using only the hooks into the move and resize loops that already exist, without any need for GER. I was planning to implement the feature this way after 0.9. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 15:38:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA29021 for scwm-discuss-outgoing; Wed, 2 Dec 1998 15:38:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA29011; Wed, 2 Dec 1998 15:38:21 -0500 Message-Id: <199812022038.PAA29011@vicarious-existence.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) cc: scwm-discuss@mit.edu Subject: Re: CVS question/request In-reply-to: Your message of "02 Dec 1998 12:10:56 PST." Date: Wed, 02 Dec 1998 15:38:21 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Maciej Stachowiak writes: > > > cwitty@newtonlabs.com writes: > > > If not, could you please remove the automatically-generated files > > > (particularly the documentation) from the CVS tree? > > > > > > > What auto-generated files, other than the documentation, are there? > > scheme/user-options.scm That's also a doc-building side effect. I'm sympathetic to removing all the scwmdoc-generated stuff from CVS, but we will either need to include Text::Balanced in the distribution if we do that, or get the Scheme doc-extractor working. > utilities/dev/{X-error-describe,create-dependency-dot-graph,scwm-usage-counter} > Now that would be a bug if true - these should all be generated by configure from the corresponding .in files and configure-generated files should never be in CVS. However, they do appear to have been deleted from CVS, at least as far as my working directory can tell, and they are in the Attic in the repository. Does cvs update complain about them for you? - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 18:20:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA31258 for scwm-discuss-outgoing; Wed, 2 Dec 1998 18:20:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA31255 for ; Wed, 2 Dec 1998 18:20:08 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA08746; Wed, 2 Dec 98 18:18:55 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id SAA08638 for ; Wed, 2 Dec 1998 18:18:40 -0500 (EST) Message-Id: <199812022318.SAA08638@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: scwm-discuss@mit.edu Subject: icon placement question and netscape 4.03 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Dec 1998 18:08:36 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Using scwm-0.9beta1 on irix 6.5. I tend to create a lot of netscape browser windows. I go to a site with a list of URLs and I middle button click on all of them. That opens a new window with each URL. Then I iconify them and read the page later. The problem I have is that scwm places all the icons one on top of another _and_ places them all at the same location, ignoring the icon-box. (A third problem is that the new windows appear at seemingly random locations but I imagine I can fix that by writing a custom placement proc.) What should I be looking at to get netscape icons to obey the icon-box? Do I need to write a placement-proc for the netscape icons? Is there a window-style directive to do that? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Wed Dec 2 18:29:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA31353 for scwm-discuss-outgoing; Wed, 2 Dec 1998 18:29:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA31350 for ; Wed, 2 Dec 1998 18:29:40 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA01711; Wed, 2 Dec 98 18:27:52 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id PAA27423; Wed, 2 Dec 1998 15:27:44 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id PAA16587; Wed, 2 Dec 1998 15:27:41 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812022038.PAA29011@vicarious-existence.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 02 Dec 1998 15:27:41 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 15:38:21 EST" Message-Id: Lines: 46 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > utilities/dev/{X-error-describe,create-dependency-dot-graph,scwm-usage-counter} > > > > Now that would be a bug if true - these should all be generated by > configure from the corresponding .in files and configure-generated > files should never be in CVS. However, they do appear to have been > deleted from CVS, at least as far as my working directory can tell, > and they are in the Attic in the repository. Does cvs update complain > about them for you? Yes: .../dev> rm X-error-describe .../dev> make X-error-describe cd ../.. && CONFIG_FILES=utilities/dev/X-error-describe CONFIG_HEADERS= ./config.status creating utilities/dev/X-error-describe .../dev> cvs -z3 update -Pd cvs server: Updating . M X-error-describe M scwmdoc.in .../dev> rm X-error-describe .../dev> cvs -z3 update -Pd cvs server: Updating . U X-error-describe M scwmdoc.in .../dev> cvs -z3 update -Pd cvs server: Updating . M scwmdoc.in (Ignore scwmdoc.in; I really did change it.) Here's some more information from the .../CVS directory which might be helpful: .../dev/CVS> cat Repository /anoncvs/scwm/utilities/dev .../dev/CVS> cat Root :pserver:anoncvs@huis-clos.mit.edu:/anoncvs .../dev/CVS> egrep X-error Entries /X-error-describe.in/1.1/Wed Sep 30 23:26:40 1998// /X-error-describe/1.1/Wed Dec 2 23:23:08 1998// Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Wed Dec 2 19:11:08 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32119 for scwm-discuss-outgoing; Wed, 2 Dec 1998 19:11:08 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32107; Wed, 2 Dec 1998 19:10:48 -0500 Message-Id: <199812030010.TAA32107@vicarious-existence.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) cc: scwm-discuss@mit.edu Subject: Re: CVS question/request In-reply-to: Your message of "02 Dec 1998 15:27:41 PST." Date: Wed, 02 Dec 1998 19:10:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > > .../dev/CVS> cat Repository > /anoncvs/scwm/utilities/dev > .../dev/CVS> cat Root > :pserver:anoncvs@huis-clos.mit.edu:/anoncvs > .../dev/CVS> egrep X-error Entries > /X-error-describe.in/1.1/Wed Sep 30 23:26:40 1998// > /X-error-describe/1.1/Wed Dec 2 23:23:08 1998// > I think your working directory must be confused about these files. I just did a fresh checkout and they did not show up. Try removing them from Entries and see if that helps. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 19:12:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32135 for scwm-discuss-outgoing; Wed, 2 Dec 1998 19:12:31 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA32130 for ; Wed, 2 Dec 1998 19:12:05 -0500 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA21500; Wed, 2 Dec 98 19:10:46 EST Received: from ypmaster.artisan.com (ypmaster [172.16.2.1]) by bastion.artisan.com (8.9.1/8.9.0) with ESMTP id QAA13999 for ; Wed, 2 Dec 1998 16:09:57 -0800 (PST) Received: from lamb.artisan.com (lamb [172.16.10.20]) by ypmaster.artisan.com (8.8.4/8.8.4) with ESMTP id QAA16922 for ; Wed, 2 Dec 1998 16:10:21 -0800 (PST) Received: (from alt@localhost) by lamb.artisan.com (8.8.8/8.8.4) id QAA06053; Wed, 2 Dec 1998 16:10:21 -0800 (PST) X-Authentication-Warning: lamb.artisan.com: alt set sender to alt@lamb.artisan.com using -f From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13925.55021.159444.311563@lamb.artisan.com> Date: Wed, 2 Dec 1998 16:10:21 -0800 (PST) To: scwm-discuss@mit.edu Subject: SESSION_MANAGER, what is it? X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've been getting this warning message, could someone explain to me what this environment variable should be set to? > [Scwm][initSM]: <> session manager initialization failed: SESSION_MANAGER environment variable not defined thanks! Albert -- Albert L. M. Ting * alt@artisan.com * 408-548-3111 * http://www.artisan.com Artisan Components, Inc. * 1195 Bordeaux Drive * Sunnyvale, CA 94089 * USA From owner-scwm-discuss@mit.edu Wed Dec 2 19:23:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32275 for scwm-discuss-outgoing; Wed, 2 Dec 1998 19:23:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32264; Wed, 2 Dec 1998 19:23:45 -0500 Message-Id: <199812030023.TAA32264@vicarious-existence.mit.edu> To: "Albert L. Ting" cc: scwm-discuss@mit.edu Subject: Re: SESSION_MANAGER, what is it? In-reply-to: Your message of "Wed, 02 Dec 1998 16:10:21 PST." <13925.55021.159444.311563@lamb.artisan.com> Date: Wed, 02 Dec 1998 19:23:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk alt@artisan.com writes: > > I've been getting this warning message, could someone explain to me what > this environment variable should be set to? > > > [Scwm][initSM]: <> session manager initialization failed: SESSION_MANAGER en > vironment variable not defined > This warning can be safely ignored if you are not running with session management. I think this warning should be disabled, since it is inappropirate IMO to warn on the acceptable normal situation of running without a session manager. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 2 19:39:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA32531 for scwm-discuss-outgoing; Wed, 2 Dec 1998 19:39:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA32528 for ; Wed, 2 Dec 1998 19:39:31 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18048; Wed, 2 Dec 98 19:37:59 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA28923; Wed, 2 Dec 1998 16:38:09 -0800 (PST) To: Maciej Stachowiak Cc: "Albert L. Ting" , scwm-discuss@mit.edu Subject: Re: SESSION_MANAGER, what is it? References: <199812030023.TAA32264@vicarious-existence.mit.edu> From: Greg Badros Date: 02 Dec 1998 16:38:09 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 19:23:45 EST" Message-Id: Lines: 21 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > alt@artisan.com writes: > > > > I've been getting this warning message, could someone explain to me what > > this environment variable should be set to? > > > > > [Scwm][initSM]: <> session manager initialization failed: SESSION_MANAGER en > > vironment variable not defined > > > > This warning can be safely ignored if you are not running with session > management. I think this warning should be disabled, since it is > inappropirate IMO to warn on the acceptable normal situation of > running without a session manager. Then we should celebrate (via a notice message) when the session manager does exist so those wanting a warning will get an implicit one in that the celebratory note did *not* appear. Greg From owner-scwm-discuss@mit.edu Wed Dec 2 21:21:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA00297 for scwm-discuss-outgoing; Wed, 2 Dec 1998 21:21:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA00294 for ; Wed, 2 Dec 1998 21:21:46 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA19538; Wed, 2 Dec 98 21:20:30 EST Received: (qmail 3248 invoked by uid 501); 3 Dec 1998 02:20:22 -0000 Message-Id: <19981202182022.A3048@molehill.org> Date: Wed, 2 Dec 1998 18:20:22 -0800 From: Todd Larason To: scwm-discuss list Subject: gnome WM spec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 X-Kibo: Reality is like the inside of a microwave oven. Sender: owner-scwm-discuss@mit.edu Precedence: bulk http://www.gnome.org/devel/gnomewm/ I haven't read it yet. Hopefully it's an easier read than most of rasterman's writing. -- ICQ UIN: 18141832 From owner-scwm-discuss@mit.edu Wed Dec 2 22:09:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA00713 for scwm-discuss-outgoing; Wed, 2 Dec 1998 22:09:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA00710 for ; Wed, 2 Dec 1998 22:09:33 -0500 Received: from M66-080-1.MIT.EDU by MIT.EDU with SMTP id AA29409; Wed, 2 Dec 98 22:08:14 EST Received: by M66-080-1.mit.edu (SMI-8.6/4.7) id WAA19917; Wed, 2 Dec 1998 22:08:02 -0500 Message-Id: <199812030308.WAA19917@M66-080-1.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: gnome WM spec In-Reply-To: Your message of "Wed, 02 Dec 1998 18:20:22 PST." <19981202182022.A3048@molehill.org> Date: Wed, 02 Dec 1998 22:08:02 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > http://www.gnome.org/devel/gnomewm/ > > I haven't read it yet. Hopefully it's an easier read than most of rasterman' > s > writing. I read it. It is mostly pretty clear except for a few highly opaque points; also, there are a few concerns I have with the standard, namely using client messages and needing to create a random window to indicate compliance. I would rather see everything done with X Properties, as then we can implement at least a prototype scwm implementation entirely in Scheme. - Maciej For reference, here is the message I sent to raster and the gnome-hackers list. It probaby makes no sense unless you have read the spec. -------------------------------- Hi, I just read the latest Gnome window manager compliace spec, and mostly I like it very much. I have a few questions/suggested changes, however. * Chapter 1 Section 1 calls for setting the value of _WIN_SUPPORTING_WM_CHECK to be set to the ID of a special window created for this purpose. Is there a reason for doing this, instead of just having the window manager set this property to nothing when it starts up, and delete it when it exits? I can't see anywhere else in the spec where that window is used. * Chapter 2 Section 2 says a client should request state changes by sending a client_message to its own window giving the new state settings. Wouldn't it be simpler to have the client set the same property on its own window that it set for the initial state setting request? I believe that window managers must listen for PropertyNotify on all managed clients anyway to comply with other standard window manager protocols. Race conditions between the window manager and client can be avoided by doing one of the following: ** always doing a grab, read, update, ungrab sequence ** forbidding the client to change its own state except when unmapped (I believe some standard ICCCM or Motif protocols specify this). ** Using a different property for the last client request and the current state, and having the format for the request property contain the appropriate bitmask of what should be changed. I dislike using client messages for window manager protocols because it adds complexity, since most other protocols are handled solely with properties. The above two suggestions would personally make my life easier. The following are questions on interpretation and semantics of the document: * what does WIN_STATE_HID_TRANSIENT mean? The comment says "/*owner of transient is hidden*/" but I am not sure what it means - does this indicate that the so-described window is transient for a window that is WIN_STATE_HIDDEN? If so, shouldn't the window manager be able to tell that otherwise? And if not, what is the window manager supposed to do when this bit is set? * The following bits may be hard for some window managers to implement (not mine). If window managers do not track horizontal and veritcal maximization separately, how should they treat these? ** WIN_STATE_MAXIMIZED_VERT ** WIN_STATE_MAXIMIZED_HORIZ * What is the "taskbar" mentioned in the comment for WIN_STATE_HIDDEN: is this meant to include only task bars per se, or also window lists/windowlist menus, which are essentially vertically stacked taskbars? Also, I have to say that I don't like this property - I don't think a window should be able to say that it doesn't appear on a window manager's takbar if the wm is managing it. Why would this be useful? * The following bits in _WIN_HINTS are described as settable only by the app, but many window managers allow the user to set these preferences in other ways. Should the window manager refuse to do such operations for windows with this hint, or should they do them anyway but not update the hint? #define WIN_HINTS_SKIP_FOCUS (1<<0) /*"alt-tab" skips this win*/ #define WIN_HINTS_SKIP_WINLIST (1<<1) /*do not show in window list*/ #define WIN_HINTS_SKIP_TASKBAR (1<<2) /*do not show on taskbar*/ #define WIN_HINTS_FOCUS_ON_CLICK (1<<4) /*app only accepts focus if clicked*/ The last in particular, the difference between click-to-focus and mouse-focus, is something that has traditionally been decided by window managers. * _WIN_EXPANDED_SIZE is described as an array of 4 CARDINALs but its semantics are not specified anywhere. * _WIN_APP_STATE and _WIN_ICONS are mentioned in Chapter 1 Section 2 but their format and semantics are not specified anywhere. Finally, a concern that does not apply to me directly at all (since I don't plan to implement the hints in C): what is the license status of the example code? I think X-style or public domain is best, since some WMs are under X-like or BSD-like licenses. Thanks for the excellent standard and I hope to hear back about these issues. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Thu Dec 3 00:26:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA01461 for scwm-discuss-outgoing; Thu, 3 Dec 1998 00:26:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA01456; Thu, 3 Dec 1998 00:25:52 -0500 Message-Id: <199812030525.AAA01456@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Random X11 question In-reply-to: Your message of "Mon, 26 Oct 1998 23:07:49 PST." <19981026230749.A14328@molehill.org> Date: Thu, 03 Dec 1998 00:25:52 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981027, Maciej Stachowiak wrote: > > > Are you aware of the _XSETROOT_ID (set by xsetroot, xpmroot and xloadimage, > > > at least) and _XROOTPMAP_ID and _XROOTCOLOR_PIXEL (set by Enlightenment > > > and Esetroot) root window properties? > > So I'm implementing this now. > > No I'm not, do tell. > > In some cases, when xsetroot sets the background bitmap or color, it set the > _XSETROOT_ID property on the root window (type XA_PIXMAP, format 32) to the > new background pixmap. If it's setting the color, it creates a 1-pixel pixmap > for this. > > I don't really understand the case - it's > if ((ecolor.pixel != BlackPixel(dpy, screen)) && > (ecolor.pixel != WhitePixel(dpy, screen)) && > (DefaultVisual(dpy, screen)->class & Dynamic)) > save_colors = 1; > > That code is in the color name->pixel conversion routine; any color setting > can trigger it. > > xpmroot sets it every time, unconditionally. > > When setting it, the old value is XKillClient()ed. > That's bogus. Why should the *root programs kill your windowmanager when you run them? Why should your windowmanager kill itself if it changes the background? Which of the *root programs do this, all of them? That's a lot of authors to contact... > > I don't know what it's *used* by. Eterm uses the E-specific verion > (_XROOTPMAP_ID) for it's pseudo-transparent windows. That's usefull enough, I'd like some scwm screenshots with pseudo-transparent terminal windows. :-) From owner-scwm-discuss@mit.edu Thu Dec 3 01:46:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA01959 for scwm-discuss-outgoing; Thu, 3 Dec 1998 01:46:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA01956 for ; Thu, 3 Dec 1998 01:46:57 -0500 From: mal@bewoner.dma.be Received: from dialup425.brussels.skynet.be by MIT.EDU with SMTP id AA09651; Thu, 3 Dec 98 01:45:37 EST Received: (qmail 18844 invoked by uid 500); 3 Dec 1998 06:46:08 -0000 Date: 3 Dec 1998 06:46:08 -0000 Message-Id: <19981203064608.18842.qmail@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Problem with hooks follow up In-Reply-To: <199812021358.IAA17230@vicarious-existence.mit.edu> References: <19981202070554.13648.qmail@localhost.localdomain> <199812021358.IAA17230@vicarious-existence.mit.edu> X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > BTW: where does scwm redirect the guile error port to? The > > compatibility code carps about obsolete interface but I don't see it > > anywhere when starting up scwm. > > How do you start it up? If from .xinitrc, then scwm's errors would go > wherever xinit's error output goes. I usually start it from an xterm > so I can see any error messages on startup more easily. I've integrated it in SUN's CDE based login sequence. So beside Openwin and CDE you get SCWM as choice. I'll redirect errors from there. Thanks From owner-scwm-discuss@mit.edu Thu Dec 3 02:19:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA03687 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:19:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA03684 for ; Thu, 3 Dec 1998 02:19:24 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA13792; Thu, 3 Dec 98 02:18:06 EST Received: (qmail 5396 invoked by uid 501); 3 Dec 1998 07:18:05 -0000 Message-Id: <19981202231805.A5357@molehill.org> Date: Wed, 2 Dec 1998 23:18:05 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Random X11 question References: <19981026230749.A14328@molehill.org> <199812030525.AAA01456@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812030525.AAA01456@vicarious-existence.mit.edu>; from Maciej Stachowiak on Thu, Dec 03, 1998 at 12:25:52AM -0500 X-Kibo: See Kibology, and grow! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981203, Maciej Stachowiak wrote: > > When setting it, the old value is XKillClient()ed. > > That's bogus. Why should the *root programs kill your windowmanager > when you run them? Why should your windowmanager kill itself if it > changes the background? Which of the *root programs do this, all of > them? That's a lot of authors to contact... Aha! I think this explains why it sets it. I don't think it's trying to kill the windowmanager, or anything else, but rather is just trying to free the resources a previous invocation of xsetroot left behind. I don't know if all the programs do; the only one I looked at source for last time is xsetroot itself. I just observed the behavior of the others with xprop. This also explains why the E people used a different property. It looks like I may have just wasted your time completely by bringing this all up, eh? > > I don't know what it's *used* by. Eterm uses the E-specific verion > > (_XROOTPMAP_ID) for it's pseudo-transparent windows. > > That's usefull enough, I'd like some scwm screenshots with > pseudo-transparent terminal windows. :-) I really like the pseudo-transparent thing. I wish someone would add that to the real xterm. I took a stab at adding background pixmap support, and figured out why nobody had done so. -- ICQ UIN: 55403361 From owner-scwm-discuss@mit.edu Thu Dec 3 02:24:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA03759 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:24:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA03755 for ; Thu, 3 Dec 1998 02:24:48 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA14430; Thu, 3 Dec 98 02:23:28 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00216; Wed, 2 Dec 1998 23:23:11 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id XAA20650; Wed, 2 Dec 1998 23:23:07 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812030010.TAA32107@vicarious-existence.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 02 Dec 1998 23:23:06 -0800 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 19:10:48 EST" Message-Id: Lines: 19 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > I think your working directory must be confused about these files. I > just did a fresh checkout and they did not show up. Try removing them > from Entries and see if that helps. I tried removing them from Entries; no luck. I then moved my old source tree out of the way and checked out the whole thing from scratch (using the instructions from http://vicarious-existence.mit.edu/scwm/anoncvs.html); those files still showed up. I seem to recall that the anoncvs server is not the master SCWM CVS server, but is mirrored from it on a regular basis. Any chance the mirroring process is somehow broken? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:30:35 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA03883 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:30:35 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA03880 for ; Thu, 3 Dec 1998 02:30:34 -0500 Received: from M2-032-3.MIT.EDU by MIT.EDU with SMTP id AA04911; Thu, 3 Dec 98 02:28:59 EST Received: by m2-032-3.mit.edu (SMI-8.6/4.7) id CAA16325; Thu, 3 Dec 1998 02:29:11 -0500 Message-Id: <199812030729.CAA16325@m2-032-3.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request In-Reply-To: Your message of "02 Dec 1998 23:23:06 PST." Date: Thu, 03 Dec 1998 02:29:10 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Maciej Stachowiak writes: > > > I think your working directory must be confused about these files. I > > just did a fresh checkout and they did not show up. Try removing them > > from Entries and see if that helps. > > I tried removing them from Entries; no luck. I then moved my old > source tree out of the way and checked out the whole thing from > scratch (using the instructions from > http://vicarious-existence.mit.edu/scwm/anoncvs.html); those files > still showed up. > > I seem to recall that the anoncvs server is not the master SCWM CVS > server, but is mirrored from it on a regular basis. Any chance the > mirroring process is somehow broken? > *Slaps own forehead* I need to make it delete files that are not in the non-anon tree. Need sleep now, but I'll do it tomorrow. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 3 02:36:55 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04040 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:36:55 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04032 for ; Thu, 3 Dec 1998 02:36:47 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00354; Wed, 2 Dec 1998 23:35:02 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28412; Wed, 2 Dec 1998 23:38:15 -0800 Date: Wed, 2 Dec 1998 23:38:15 -0800 Message-Id: <199812030738.XAA28412@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: bugfix for scwmdoc.in Sender: owner-scwm-discuss@mit.edu Precedence: bulk If you look at the documentation for bool->str in scwm-procedures.txt (for instance), you'll see that it has \"true\" instead of "true" The following patch fixes this bug. === cd /src/debian/scwm/scwm-cvs/utilities/dev/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u scwmdoc.in Index: scwmdoc.in =================================================================== RCS file: /anoncvs/scwm/utilities/dev/scwmdoc.in,v retrieving revision 1.2 diff -u -r1.2 scwmdoc.in --- scwmdoc.in 1998/11/24 16:17:16 1.2 +++ scwmdoc.in 1998/12/03 07:32:06 @@ -593,6 +593,9 @@ my $usage = $name_and_args; # Remove leading and trailing quote $comment =~ s/^\"(.*)\"$/$1/ms; + # Unquote quoted quotes (CRW:FIXME:GJB: are there other things we + # may need to unquote here?) + $comment =~ s/\\"/"/g; # print STDERR "Scheme Proc: $proc_name\nArgs: @arglist\n$header\n"; # print STDERR "$usage\n\n$comment\n\n \n"; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:38:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04068 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:38:53 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04057 for ; Thu, 3 Dec 1998 02:38:32 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00377; Wed, 2 Dec 1998 23:36:51 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28417; Wed, 2 Dec 1998 23:40:04 -0800 Date: Wed, 2 Dec 1998 23:40:04 -0800 Message-Id: <199812030740.XAA28417@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: political correctness fix :-) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Remember: "It's a window system named X, not a system named X Windows." :-) === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u xproperty.c Index: xproperty.c =================================================================== RCS file: /anoncvs/scwm/scwm/xproperty.c,v retrieving revision 1.29 diff -u -r1.29 xproperty.c --- xproperty.c 1998/11/24 11:35:48 1.29 +++ xproperty.c 1998/12/03 07:36:53 @@ -58,7 +58,7 @@ SCWM_SYMBOL(sym_prepend,"prepend"); /**CONCEPT: X Properties - X windows has a notion of window properties, which live in the X + X has a notion of window properties, which live in the X server. X window properties are often used to implement protocols between applications and the window manager, which can have several levels of standardization, from official X standard, to standardized Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:43:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04456 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:43:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04452 for ; Thu, 3 Dec 1998 02:43:51 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00461; Wed, 2 Dec 1998 23:42:21 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28431; Wed, 2 Dec 1998 23:45:34 -0800 Date: Wed, 2 Dec 1998 23:45:34 -0800 Message-Id: <199812030745.XAA28431@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for window.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Various doc fixes in window.c. Some of these try to make the docs more accurate; others try to make the docs less technical (for instance, I use "show" and "hide" instead of "map" and "unmap"). === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u window.c Index: window.c =================================================================== RCS file: /anoncvs/scwm/scwm/window.c,v retrieving revision 1.174 diff -u -r1.174 window.c --- window.c 1998/11/24 16:18:56 1.174 +++ window.c 1998/12/03 07:39:23 @@ -1873,7 +1873,10 @@ (SCM win)) /** Return #t if WIN is currently raised, #f if not. WIN defaults to the window context in the usual way if not -specified. */ +specified. A window is considered to be raised if the application +window (not the frame) is unobscured (or if this was the last +window you called `raise-window' on). +*/ #define FUNC_NAME s_raised_p { ScwmWindow *psw; @@ -1933,8 +1936,8 @@ SCWM_PROC(iconify, "iconify", 0, 1, 0, (SCM win)) /** Iconify WIN. -Iconifying unmaps the regular window, and map the window's icon -window. WIN defaults to the window context in the usual way if not +Iconifying hides the regular window, and shows the window's icon. +WIN defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_iconify { @@ -1959,8 +1962,8 @@ SCWM_PROC(deiconify, "deiconify", 0, 1, 0, (SCM win)) /** Deiconify WIN. -Unmap its icon window, and map its regular -window. WIN defaults to the window context in the usual way if not +Hides its icon, and shows its regular window. +WIN defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_deiconify { @@ -1987,14 +1990,19 @@ } #undef FUNC_NAME +/**CONCEPT: Sticky + + A "sticky" window will appear on all desktops, and will remain at the +same screen position regardless of scrolling within the current +desktop. +*/ + /* FIXGJB: rename to window-stick */ SCWM_PROC(stick, "stick", 0, 1, 0, (SCM win)) - /** Make WIN "sticky" so that it stays stationary in viewport. -A sticky window will appear on all desktops, and will remain at the -same screen position regardless of scrolling within the current -desktop. WIN defaults to the window context in the usual way if not + /** Make WIN "sticky" so that it stays stationary in the viewport. +WIN defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_stick { @@ -2209,7 +2217,7 @@ SCWM_PROC(move_window, "move-window", 2, 1, 0, (SCM x, SCM y, SCM win)) - /** Move WIN to coordinates virtual coordinates X, Y. + /** Move WIN to virtual coordinates X, Y. If X is #f, then X defaults to the current X position of WIN. If Y is #f, then Y defaults to the current Y position of WIN. WIN defaults to the window context in the usual way if not @@ -2863,6 +2871,7 @@ SCWM_PROC(show_titlebar, "show-titlebar", 0, 1, 0, (SCM win)) /** Cause WIN to be decorated with a titlebar. +See also `hide-titlebar'. WIN defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_show_titlebar @@ -2887,7 +2896,7 @@ SCWM_PROC(hide_titlebar, "hide-titlebar", 0, 1, 0, (SCM win)) /** Cause WIN not to be decorated with a titlebar. - +See also `show-titlebar'. WIN defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_hide_titlebar @@ -2956,9 +2965,8 @@ SCWM_PROC(plain_border, "plain-border", 0, 1, 0, (SCM win)) /** Cause WIN to be decorated with a plain border. -This means that there will be no resize handles in the corners, and the -window . WIN defaults to the window context in the usual way if not -specified. */ +This means that there will be no resize handles in the corners. WIN +defaults to the window context in the usual way if not specified. */ #define FUNC_NAME s_plain_border { ScwmWindow *psw; @@ -2986,9 +2994,10 @@ SCWM_PROC(border_normal_p, "border-normal?", 0, 1, 0, (SCM win)) - /** Return #t if WIN has a normal border, #f otherwise. -WIN defaults to the window context in the usual way if not -specified. */ + /** Return #t if WIN has a normal border, #f if it has +a plain border. WIN defaults to the window context in the +usual way if not specified. See `normal-border' and +`plain-border'. */ #define FUNC_NAME s_border_normal_p { VALIDATE(win, FUNC_NAME); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:46:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04511 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:46:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04508 for ; Thu, 3 Dec 1998 02:46:35 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00498; Wed, 2 Dec 1998 23:45:05 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28443; Wed, 2 Dec 1998 23:48:18 -0800 Date: Wed, 2 Dec 1998 23:48:18 -0800 Message-Id: <199812030748.XAA28443@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: please remove scwmmenu.c from CVS Sender: owner-scwm-discuss@mit.edu Precedence: bulk Please remove scwmmenu.c (and any other dead code) from CVS. It still gets docs extracted by scwmdoc. (Maybe it has already been removed and this is another instance of the CVS bug?) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:48:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04572 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:48:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04565 for ; Thu, 3 Dec 1998 02:48:28 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00517; Wed, 2 Dec 1998 23:46:51 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28450; Wed, 2 Dec 1998 23:50:07 -0800 Date: Wed, 2 Dec 1998 23:50:07 -0800 Message-Id: <199812030750.XAA28450@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: typo fixes in resize.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk One cut-and-paste error; one missing paren. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u resize.c Index: resize.c =================================================================== RCS file: /anoncvs/scwm/scwm/resize.c,v retrieving revision 1.53 diff -u -r1.53 resize.c --- resize.c 1998/11/30 16:46:28 1.53 +++ resize.c 1998/12/03 07:46:59 @@ -738,10 +738,10 @@ This allows the user to drag a rubber band frame to set the size of the window. WIN defaults to the window context in the usual way if not specified. If OPAQUE? is #t, the resize will be done -"opaquely", moving the actual X window, if #f a rubberband will be +"opaquely", resizing the actual X window, if #f a rubberband will be used instead to save on server computation (note that the rubberband requires a server "grab" which means that nothing else changes on -screen while the non-opaque resize takes place. */ +screen while the non-opaque resize takes place). */ #define FUNC_NAME s_interactive_resize { ScwmWindow *psw; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:51:04 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04662 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:51:04 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04651 for ; Thu, 3 Dec 1998 02:50:53 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00548; Wed, 2 Dec 1998 23:49:17 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28455; Wed, 2 Dec 1998 23:52:31 -0800 Date: Wed, 2 Dec 1998 23:52:31 -0800 Message-Id: <199812030752.XAA28455@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for placement.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried to add a little more information about placement procedures. I also added one FIXME comment. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u placement.c Index: placement.c =================================================================== RCS file: /anoncvs/scwm/scwm/placement.c,v retrieving revision 1.47 diff -u -r1.47 placement.c --- placement.c 1998/09/25 06:20:45 1.47 +++ placement.c 1998/12/03 07:48:38 @@ -400,7 +400,11 @@ The placement is just as if SmartPlacementIsReallySmart were not in effect. That is, it tries to place the window so that it does not overlap any other. If it fails to do so, it returns #f; otherwise it -returns #t. */ +returns #t. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_smart_place_window { ScwmWindow *psw; @@ -446,7 +450,11 @@ overlap with other windows. Several parameters give different weight to various kinds of windows, but they are not tunable at runtime currently. If it fails to place the window, it -returns #f; otherwise it returns #t. */ +returns #f; otherwise it returns #t. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_clever_place_window { ScwmWindow *psw; @@ -480,7 +488,11 @@ which are incremented for the x and y coordinates, and which wrap around once a window would be forced off the screen. The placement is fairly arbitrary, but always succeeds, and so avoids user -interaction. #t is always returned. */ +interaction. #t is always returned. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_random_place_window { ScwmWindow *psw; @@ -515,11 +527,13 @@ This is the default placement procedure for non-transient windows. It tries `smart-place-window', `clever-place-window', `random-place-window', or `interactive-move' (to achieve interactive -placement) on WIN depending on several style flags. However, -if one of the following factors holds, the window will instead be -placed exactly as requested by the program: the position was specified -by the user, the position was specified by the program, and -#:no-PPosition-hint is not set, or the window starts iconic. */ +placement) on WIN depending on several style flags. (See +`set-smart-placement-is-really-smart!', `set-smart-placement!', +and `set-random-placement!'). However, if one of the following +factors holds, the window will instead be placed exactly as +requested by the program: the position was specified by the user, +the position was specified by the program and #:no-PPosition-hint +is not set, or the window starts iconic. */ #define FUNC_NAME s_default_placement_proc { ScwmWindow *psw; @@ -586,6 +600,8 @@ /* * Handles initial placement and sizing of a new window * Returns False in the event of a lost window. + * CRW:FIXME:MS: I'm not sure what a "lost window" is, but as far as I can + * tell, this never returns False. */ Bool PlaceWindow(ScwmWindow *psw, int Desk) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:54:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04762 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:54:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04746 for ; Thu, 3 Dec 1998 02:53:54 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00586; Wed, 2 Dec 1998 23:52:19 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28473; Wed, 2 Dec 1998 23:55:32 -0800 Date: Wed, 2 Dec 1998 23:55:32 -0800 Message-Id: <199812030755.XAA28473@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for move.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk A few typo-level fixes for move.c. (I just noticed that one of these changes, changing a comma to a semicolon, should have been made in resize.c as well.) === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u move.c Index: move.c =================================================================== RCS file: /anoncvs/scwm/scwm/move.c,v retrieving revision 1.79 diff -u -r1.79 move.c --- move.c 1998/11/30 16:46:28 1.79 +++ move.c 1998/12/03 07:51:17 @@ -581,7 +581,7 @@ if (!GrabEm(CURSOR_MOVE)) { /* FIXGJB: xmag caused this to run - when click-to place (no auto/smart placemet) + when click-to place (no auto/smart placement) and it should not, IMO --09/22/98 gjb call0_hooks(invalid_interaction_hook); */ @@ -629,10 +629,10 @@ This allows the user to drag a rubber band frame or the window itself around the screen. WIN defaults to the window context in the usual way if not specified. If OPAQUE? is #t, the move will be done -"opaquely", moving the actual X window, if #f a rubberband will be +"opaquely", moving the actual X window; if #f a rubberband will be used instead to save on server computation (note that the rubberband requires a server "grab" which means that nothing else changes on -screen while the non-opaque move takes place. */ +screen while the non-opaque move takes place). */ #define FUNC_NAME s_interactive_move { ScwmWindow *psw; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 02:58:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04811 for scwm-discuss-outgoing; Thu, 3 Dec 1998 02:58:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id CAA04808 for ; Thu, 3 Dec 1998 02:58:06 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00623; Wed, 2 Dec 1998 23:56:37 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id XAA28480; Wed, 2 Dec 1998 23:59:57 -0800 Date: Wed, 2 Dec 1998 23:59:57 -0800 Message-Id: <199812030759.XAA28480@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for miscprocs.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk The only major change here is to change the documentation (and variable names) of set-click-delay! to reflect the fact that it actually takes milliseconds, not microseconds. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u miscprocs.c Index: miscprocs.c =================================================================== RCS file: /anoncvs/scwm/scwm/miscprocs.c,v retrieving revision 1.75 diff -u -r1.75 miscprocs.c --- miscprocs.c 1998/11/14 23:09:07 1.75 +++ miscprocs.c 1998/12/03 07:54:11 @@ -159,7 +159,8 @@ SCWM_PROC(refresh, "refresh", 0, 0, 0, ()) /** Make sure all windows and their decorations are up to date. -This forces a redraw of the entire current viewport. */ +This forces a redraw of the entire current viewport. Should not be +necessary during normal operation. */ #define FUNC_NAME s_refresh { refresh_common(Scr.Root); @@ -169,25 +170,25 @@ SCWM_PROC(set_click_delay_x, "set-click-delay!", 1, 0, 0, - (SCM usec)) + (SCM msec)) /** Set the delay used in identifying mouse clicks and drags. -USEC is specified in microseconds. After USEC microseconds, a mouse-down -without a mouse-up is considered a drag. Also, after USEC microseconds, a +MSEC is specified in milliseconds. After MSEC milliseconds, a mouse-down +without a mouse-up is considered a drag. Also, after MSEC milliseconds, a single click is definitively identified as not a double click. */ #define FUNC_NAME s_set_click_delay_x { - if (!gh_number_p(usec)) { - scm_wrong_type_arg(FUNC_NAME, 1, usec); + if (!gh_number_p(msec)) { + scm_wrong_type_arg(FUNC_NAME, 1, msec); } - Scr.ClickTime = gh_scm2long(usec); + Scr.ClickTime = gh_scm2long(msec); return SCM_UNSPECIFIED; } #undef FUNC_NAME SCWM_PROC(click_delay, "click-delay", 0, 0, 0, ()) - /** Retrun the delay used in identifying mouse clicks and drags, in microseconds. + /** Returns the delay used in identifying mouse clicks and drags, in milliseconds. See also `set-click-delay!' */ #define FUNC_NAME s_click_delay { @@ -199,7 +200,7 @@ (SCM ftype)) /** Set the colormap focus policy to FTYPE. FTYPE can either be 'mouse, indicating that the window under the mouse -pointer should always have it's colormap installed, or 'focus to +pointer should always have its colormap installed, or 'focus to indicate that the window with the input focus should also get the colormap focus. This makes a difference only when using focus policies other than 'mouse. */ @@ -250,7 +251,7 @@ SCWM_PROC(move_pointer_to, "move-pointer-to", 2, 0, 0, (SCM sx, SCM sy)) - /** Move the mouse pointer to SX, SY (given in pixels). */ + /** Move the mouse pointer to viewport coordinates SX, SY. */ #define FUNC_NAME s_move_pointer_to { int x, y; @@ -433,7 +434,7 @@ SCWM_PROC(mouse_focus_click_raises_p, "mouse-focus-click-raises?", 0, 0, 0, ()) - /** Returns a boolean valude indicating whether a mouse-focus-click will raise the window.. */ + /** Returns a boolean value indicating whether a mouse-focus-click will raise the window. */ #define FUNC_NAME s_mouse_focus_click_raises_p { return SCM_BOOL_FromBool(Scr.fMouseFocusClickRaises); @@ -462,6 +463,13 @@ +/* CRW:FIXME:: If CLK_TCK is defined, the following works as documented; +otherwise, it returns the number of milliseconds of CPU time used +by the current process (both user time and system time), divided +by 60. */ +/* CRW:FIXME:MS: Maybe this function should just be deleted? It +doesn't seem to be used anywhere, and (as mentioned above) its implementation +is inconsistent... */ SCWM_PROC (elapsed_time, "elapsed-time", 0, 0, 0, ()) /** Return the elapsed time in milliseconds since O.S. has been up. */ Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:01:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA04839 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:01:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA04835 for ; Thu, 3 Dec 1998 03:01:03 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id XAA00663; Wed, 2 Dec 1998 23:59:24 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28493; Thu, 3 Dec 1998 00:02:38 -0800 Date: Thu, 3 Dec 1998 00:02:38 -0800 Message-Id: <199812030802.AAA28493@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for menulook.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Look this one over before you apply it. The first chunk is pretty minimal; as indicated in my FIXME comment, I'm not sure the second chunk is correct. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menulook.c Index: menulook.c =================================================================== RCS file: /anoncvs/scwm/scwm/menulook.c,v retrieving revision 1.6 diff -u -r1.6 menulook.c --- menulook.c 1998/11/14 23:09:07 1.6 +++ menulook.c 1998/12/03 07:58:12 @@ -76,6 +76,12 @@ return result; } +/**CONCEPT: Menu Looks + + Menus have an associated menu look, which determines how the menus +are drawn. +*/ + SCM make_menulook(char * szName, SCM extra, MenuDrawingVtable * mdvt) { @@ -84,7 +90,12 @@ SCWM_PROC(copy_menu_look, "copy-menu-look", 2, 1, 0, (SCM original_menu_look, SCM name, SCM extra)) -/** Copy menu look ORIGINAL-MENU-LOOK with a new NAME and optional EXTRA. */ +/** Copy menu look ORIGINAL-MENU-LOOK with a new NAME and optional EXTRA. +If EXTRA is not given, the EXTRA information from the original menu is +used. The form and purpose of the EXTRA information varies with the +menu look, and is documented with the original menu looks; currently, +no menu look uses the EXTRA information. */ +/* CRW:FIXME:JTL: Is it true that EXTRA is unused? */ #define FUNC_NAME s_copy_menu_look { int iarg = 0; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:03:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA04857 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:03:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA04854 for ; Thu, 3 Dec 1998 03:03:31 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00707; Thu, 3 Dec 1998 00:01:52 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28501; Thu, 3 Dec 1998 00:05:05 -0800 Date: Thu, 3 Dec 1998 00:05:05 -0800 Message-Id: <199812030805.AAA28501@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: minor doc fixes for menuitem.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Nothing major here... === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menuitem.c Index: menuitem.c =================================================================== RCS file: /anoncvs/scwm/scwm/menuitem.c,v retrieving revision 1.26 diff -u -r1.26 menuitem.c --- menuitem.c 1998/09/25 06:20:41 1.26 +++ menuitem.c 1998/12/03 08:01:06 @@ -96,7 +96,7 @@ '(label action extra-label picture-above picture-left hover-action unhover-action hotkey-preferences) Note that this is the same as the arguments to the `make-menuitem' -primitive */ +primitive. */ #define FUNC_NAME s_menuitem_properties { MenuItem *pmi = SAFE_MENUITEM(menu_item); @@ -135,7 +135,8 @@ over the item, respectively. HOTKEY-PREFS is a string listing preferred alphanumeric shortcut-keys for the given menu-item; the menu creation routine uses these as hints -for assigning shortcut keys to the various menuitems. */ +for assigning shortcut keys to the various menuitems. +For a higher-level interface to this function, see `menuitem'. */ #define FUNC_NAME s_make_menuitem { MenuItem *pmi = NEW(MenuItem); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:05:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA04886 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:05:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA04879 for ; Thu, 3 Dec 1998 03:05:29 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00730; Thu, 3 Dec 1998 00:03:50 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28514; Thu, 3 Dec 1998 00:07:03 -0800 Date: Thu, 3 Dec 1998 00:07:03 -0800 Message-Id: <199812030807.AAA28514@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: minor doc fixes for image.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Cut-and-paste error. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u image.c Index: image.c =================================================================== RCS file: /anoncvs/scwm/scwm/image.c,v retrieving revision 1.50 diff -u -r1.50 image.c --- image.c 1998/11/18 00:04:15 1.50 +++ image.c 1998/12/03 08:03:55 @@ -102,8 +102,8 @@ SCM_SYMBOL (sym_mask,"mask"); /**CONCEPT: Images - Images are first-class objects. However, anywhere that a font is -taken as an argument, a string containing an filename will also be + Images are first-class objects. However, anywhere that an image is +taken as an argument, a string containing a filename will also be accepted, and will be automatically converted to the proper image object by loading the image. Using the same image filename more than once is not inefficient, as caching ensures that image objects are @@ -160,8 +160,8 @@ (SCM image)) /** Return an association list giving some properties of IMAGE. Currently defined properties are 'filename, the fully expanded -pathname of the image, 'width, it's width, 'height, it's height, and -depth, it's color depth. +pathname of the image, 'width, its width, 'height, its height, and +depth, its color depth. */ #define FUNC_NAME s_image_properties { Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:08:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA04991 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:08:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA04974 for ; Thu, 3 Dec 1998 03:07:54 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00773; Thu, 3 Dec 1998 00:06:15 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28521; Thu, 3 Dec 1998 00:09:27 -0800 Date: Thu, 3 Dec 1998 00:09:27 -0800 Message-Id: <199812030809.AAA28521@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: obsolete comments in icons.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Looking at the code, I'm pretty sure that the first (FIXGJB) comment has already been implemented. I think maybe the FIXMS one has as well, but I'm less sure of that. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u icons.c Index: icons.c =================================================================== RCS file: /anoncvs/scwm/scwm/icons.c,v retrieving revision 1.47 diff -u -r1.47 icons.c --- icons.c 1998/11/18 00:04:15 1.47 +++ icons.c 1998/12/03 08:05:59 @@ -248,19 +248,11 @@ psw->fShapedIcon = True; } - /* FIXGJB: we need a way of setting an icon here if we've not got - one already; e.g., a user should be able to specify a default - icon in case none can be found in any of the previous places. - Just using a default as it is now lets that icon take priority - over any icon window or bitmap window that the application might - provide. Perhaps :icon and `:forced-icon' or something like - that, where the #:icon behaviour allows the application to - override, and the forced-icon says we always want a specific icon - */ - /* FIXMS: You should be able to set separately whether you want icon titles or icon images or both. */ + /* CRW:FIXME:MS: Has the above already been implemented? If so, + the comment should be deleted... */ /* figure out the icon window size */ if (!psw->fNoIconTitle || psw->icon_p_height == 0) { Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:09:33 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05076 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:09:33 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05073 for ; Thu, 3 Dec 1998 03:09:17 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00781; Thu, 3 Dec 1998 00:07:37 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28528; Thu, 3 Dec 1998 00:10:48 -0800 Date: Thu, 3 Dec 1998 00:10:48 -0800 Message-Id: <199812030810.AAA28528@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: minor doc fix for font.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Grammar fix. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u font.c Index: font.c =================================================================== RCS file: /anoncvs/scwm/scwm/font.c,v retrieving revision 1.50 diff -u -r1.50 font.c --- font.c 1998/10/06 22:17:36 1.50 +++ font.c 1998/12/03 08:08:03 @@ -239,7 +239,7 @@ (SCM font)) /** Return an association list giving some properties of FONT. Currently defined properties are 'name, the string name of the -color, and 'height, it's total height in pixels. */ +color, and 'height, its total height in pixels. */ #define FUNC_NAME s_font_properties { scwm_font *psfont = SAFE_FONT(font); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:11:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05109 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:11:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05106 for ; Thu, 3 Dec 1998 03:11:20 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00822; Thu, 3 Dec 1998 00:09:44 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28541; Thu, 3 Dec 1998 00:12:57 -0800 Date: Thu, 3 Dec 1998 00:12:57 -0800 Message-Id: <199812030812.AAA28541@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: typo in face.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u face.c Index: face.c =================================================================== RCS file: /anoncvs/scwm/scwm/face.c,v retrieving revision 1.45 diff -u -r1.45 face.c --- face.c 1998/11/18 00:04:15 1.45 +++ face.c 1998/12/03 08:09:51 @@ -786,7 +786,7 @@ /* FIXGJB: I think this should only take pixmap objects; if we want scheme sugar for converting strings into pixmaps, that's fine, too; this works well now, though, - so maybe it's only work changing when make-face is + so maybe it's only worth changing when make-face is wrapped to use keyword arguments */ if (!mini_p) { if (IMAGE_P(arg)) { Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:13:42 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05160 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:13:42 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05152 for ; Thu, 3 Dec 1998 03:13:30 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00844; Thu, 3 Dec 1998 00:11:53 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28549; Thu, 3 Dec 1998 00:15:08 -0800 Date: Thu, 3 Dec 1998 00:15:08 -0800 Message-Id: <199812030815.AAA28549@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: minor doc fix for events.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u events.c Index: events.c =================================================================== RCS file: /anoncvs/scwm/scwm/events.c,v retrieving revision 1.120 diff -u -r1.120 events.c --- events.c 1998/11/24 11:35:47 1.120 +++ events.c 1998/12/03 08:12:08 @@ -466,7 +466,8 @@ For more information on how to make use of this protocol, see the documentation for the scwmexec and scwmrepl programs, the scwm.el emacs interaction mode, the libscwmexec library, and the details of -the SCWMEXEC protocol. Also see doc/scwmexec.proto. +the SCWMEXEC protocol (as documented in +doc/scwmexec.proto). FIXDOC: Link to file! */ Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:16:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05191 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:16:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05188 for ; Thu, 3 Dec 1998 03:16:12 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00885; Thu, 3 Dec 1998 00:14:33 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28556; Thu, 3 Dec 1998 00:17:45 -0800 Date: Thu, 3 Dec 1998 00:17:45 -0800 Message-Id: <199812030817.AAA28556@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fix for deskpage.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk This patch is part of my effort (which you'll also see in other patches) to standardize on the terms "virtual coordinate" and "viewport coordinate". I think we should always use one of these, and never use just the word "coordinate", in the docstrings. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u deskpage.c Index: deskpage.c =================================================================== RCS file: /anoncvs/scwm/scwm/deskpage.c,v retrieving revision 1.35 diff -u -r1.35 deskpage.c --- deskpage.c 1998/09/25 06:20:34 1.35 +++ deskpage.c 1998/12/03 08:13:42 @@ -87,6 +87,11 @@ The current viewport is the area of the current desk that may be seen on the physical screen. Since a desk can be larger than the physical screen size, the viewport can move around the desk. + + Viewports give rise to two concepts of coordinates. A viewport +coordinate is relative to the current viewport (i.e., it is the +coordinate you actually see on the screen). A virtual coordinate +is relative to the origin of the current desk. */ SCWM_PROC(set_viewport_position_x, "set-viewport-position!", 2, 0, 0, Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:19:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05272 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:19:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05256 for ; Thu, 3 Dec 1998 03:19:10 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA00920; Thu, 3 Dec 1998 00:17:32 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28569; Thu, 3 Dec 1998 00:20:44 -0800 Date: Thu, 3 Dec 1998 00:20:44 -0800 Message-Id: <199812030820.AAA28569@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: code simplification in decor.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk The code for initializing a decor was split (in a very odd way) between InitScwmDecor() (a very tiny function which was only called from one place) and decor2scm. I inlined InitScwmDecor() into its only call site and got rid of it. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u decor.c Index: decor.c =================================================================== RCS file: /anoncvs/scwm/scwm/decor.c,v retrieving revision 1.46 diff -u -r1.46 decor.c --- decor.c 1998/11/14 23:09:06 1.46 +++ decor.c 1998/12/03 08:16:22 @@ -54,19 +54,6 @@ } } -/* - * InitScwmDecor -- initializes an ScwmDecor structure to defaults - */ -static void -InitScwmDecor(ScwmDecor * fl) -{ - fl->HiReliefGC = NULL; - fl->HiShadowGC = NULL; - - /* fl->tag = NULL; */ - fl->next = NULL; -} - /**CONCEPT: Decors Decors are a means of managing the abundance of visual appearance @@ -182,7 +169,10 @@ SCWM_NEWCELL_SMOB(answer,scm_tc16_scwm_decor,dec); fl->scmdecor = answer; - InitScwmDecor(fl); + fl->HiReliefGC = NULL; + fl->HiShadowGC = NULL; + + fl->next = NULL; tmpd = current_decor(); set_current_decor_x(answer); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:21:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05363 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:21:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05360 for ; Thu, 3 Dec 1998 03:21:53 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA20252; Thu, 3 Dec 98 03:20:35 EST Received: (qmail 5984 invoked by uid 501); 3 Dec 1998 08:20:35 -0000 Message-Id: <19981203002035.A5954@molehill.org> Date: Thu, 3 Dec 1998 00:20:35 -0800 From: Todd Larason To: "Carl R. Witty" , scwm-discuss@mit.edu Subject: Re: doc fixes for menulook.c References: <199812030802.AAA28493@nebula.newtonlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812030802.AAA28493@nebula.newtonlabs.com>; from Carl R. Witty on Thu, Dec 03, 1998 at 12:02:38AM -0800 X-Kibo: You all are revered, because vrilthought is like sex. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981203, Carl R. Witty wrote: > Look this one over before you apply it. The first chunk is pretty > minimal; as indicated in my FIXME comment, I'm not sure the second > chunk is correct. The EXTRA arguments are used by the XPM menu look, actually. This is checked in with that change, as is the menuitem.c change. Thanks! If nobody beats me to it, or raises objections, I'll check the rest of these in tomorrow. -- ICQ UIN: 70719825 From owner-scwm-discuss@mit.edu Thu Dec 3 03:23:10 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05379 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:23:10 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05373 for ; Thu, 3 Dec 1998 03:22:54 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA01029; Thu, 3 Dec 1998 00:21:10 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28583; Thu, 3 Dec 1998 00:24:22 -0800 Date: Thu, 3 Dec 1998 00:24:22 -0800 Message-Id: <199812030824.AAA28583@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fixes for color.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Mostly just adding a little more information to the docs. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u color.c Index: color.c =================================================================== RCS file: /anoncvs/scwm/scwm/color.c,v retrieving revision 1.53 diff -u -r1.53 color.c --- color.c 1998/11/14 23:09:05 1.53 +++ color.c 1998/12/03 08:19:31 @@ -411,7 +411,10 @@ SCWM_PROC(make_reversed_color, "make-reversed-color", 1, 0, 0, (SCM color)) - /** Return a new color that is opposite COLOR. */ + /** Return a new color that is opposite COLOR. +Note that the returned color will not necessarily contrast with +COLOR; (make-reversed-color "gray50") is almost indistinguishable +from "gray50". */ #define FUNC_NAME s_make_reversed_color { VALIDATE_COLOR (color, FUNC_NAME, 1); @@ -601,7 +604,8 @@ SCWM_PROC(set_hilight_foreground_x, "set-hilight-foreground!", 1, 0, 0, (SCM fg) ) /** Use FG for foreground color of the window with the input focus. -Applies to the current decor. */ +Applies to the current decor. This is used only for windows that don't +have their own foreground color. */ #define FUNC_NAME s_set_hilight_foreground_x { ScwmDecor *fl; @@ -625,7 +629,8 @@ SCWM_PROC (hilight_foreground, "hilight-foreground", 0, 0, 0, () ) /** Return the foreground color of the window with the input focus. -Applies to the focus in the current decor. */ +Applies to the current decor. This is used only for windows that don't +have their own foreground color. */ #define FUNC_NAME s_hilight_foreground { ScwmDecor *fl; @@ -644,7 +649,8 @@ SCWM_PROC(set_hilight_background_x, "set-hilight-background!", 1, 0, 0, (SCM bg)) /** Use BG as the background color for the window with input focus. -Applies to the current decor. */ +Applies to the current decor. This is used only for windows that don't +have their own background color. */ #define FUNC_NAME s_set_hilight_background_x { XGCValues gcv; @@ -698,7 +704,8 @@ SCWM_PROC (hilight_background, "hilight-background", 0, 0, 0, () ) /** Return the background color for windows with the input focus. -Applies to the current decor. */ +Applies to the current decor. This is used only for windows that don't +have their own background color. */ #define FUNC_NAME s_hilight_background { ScwmDecor *fl; @@ -711,7 +718,7 @@ SCWM_PROC(set_not_menu_foreground_x, "set-not-menu-foreground!", 1, 0, 0, (SCM fg) ) - /** Use FG as the default foreground color for non-menus. */ + /** Use FG as the default foreground color for icons, titlebars, etc. */ #define FUNC_NAME s_set_not_menu_foreground_x { VALIDATE_COLOR(fg, FUNC_NAME, 1); @@ -730,7 +737,7 @@ SCWM_PROC (not_menu_foreground, "not-menu-foreground", 0, 0, 0, () ) - /** Return the default foreground color for menus. */ + /** Return the default foreground color for icons, titlebars, etc. */ #define FUNC_NAME s_not_menu_foreground { return (Scr.NotMenuColors.fg); @@ -739,7 +746,7 @@ SCWM_PROC(set_not_menu_background_x, "set-not-menu-background!", 1, 0, 0, (SCM bg) ) - /** Use BG as the default foreground color for menus. */ + /** Use BG as the default background color for icons, window frames, etc. */ #define FUNC_NAME s_set_not_menu_background_x { VALIDATE_COLOR(bg, FUNC_NAME, 1); @@ -765,7 +772,7 @@ SCWM_PROC (not_menu_background, "not-menu-background", 0, 0, 0, () ) - /** Return the default background color for menus. */ + /** Return the default background color for icons, window frames, etc. */ #define FUNC_NAME s_not_menu_background { return (Scr.NotMenuColors.bg); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:25:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05396 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:25:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05390 for ; Thu, 3 Dec 1998 03:24:54 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA01054; Thu, 3 Dec 1998 00:23:15 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28590; Thu, 3 Dec 1998 00:26:29 -0800 Date: Thu, 3 Dec 1998 00:26:29 -0800 Message-Id: <199812030826.AAA28590@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fix for callbacks.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Grammar fix. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u callbacks.c Index: callbacks.c =================================================================== RCS file: /anoncvs/scwm/scwm/callbacks.c,v retrieving revision 1.38 diff -u -r1.38 callbacks.c --- callbacks.c 1998/10/05 19:36:41 1.38 +++ callbacks.c 1998/12/03 08:23:23 @@ -574,7 +574,7 @@ manipulate them. Like regular hooks and unlike timer hooks, input hooks are not one-shot - they trigger every time input is made available on the particular port, and do not go away until explicitly -removed. An input hook may safely remove itself from within it's own +removed. An input hook may safely remove itself from within its own invocation. */ Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:27:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05413 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:27:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05410 for ; Thu, 3 Dec 1998 03:27:28 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA01081; Thu, 3 Dec 1998 00:25:48 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28597; Thu, 3 Dec 1998 00:29:02 -0800 Date: Thu, 3 Dec 1998 00:29:02 -0800 Message-Id: <199812030829.AAA28597@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: doc fix for binding.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk I tried to make the docs a little clearer here... === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u binding.c Index: binding.c =================================================================== RCS file: /anoncvs/scwm/scwm/binding.c,v retrieving revision 1.63 diff -u -r1.63 binding.c --- binding.c 1998/09/25 06:20:26 1.63 +++ binding.c 1998/12/03 08:25:38 @@ -648,7 +648,8 @@ /** Bind the given KEY within the CONTEXTS to invoke PROC. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) KEY is a string giving the key-specifier (e.g., M-Delete for Meta+Delete) -PROC is a procedure (possibly a thunk) that should be invoked */ +PROC is a procedure that will be invoked (with no arguments) when the +specified key is pressed in the specified context. */ #define FUNC_NAME s_bind_key { KeySym keysym; @@ -680,7 +681,7 @@ return SCM_BOOL_F; } /* - * One keycode might map to the same keysym -MS + * More than one keycode might map to the same keysym -MS */ XDisplayKeycodes(dpy, &min, &max); @@ -707,7 +708,8 @@ /** Bind the given mouse BUTTON within the CONTEXTS to invoke PROC. CONTEXTS is a list of event-contexts (e.g., '(button1 sidebar)) BUTTON is a string or integer giving the mouse button number -PROC is a procedure (possibly a thunk) that should be invoked */ +PROC is a procedure that will be invoked (with no arguments) when the +specified button is pressed in the specified context. */ #define FUNC_NAME s_bind_mouse { int bnum = 0; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:29:15 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05429 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:29:15 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA05426 for ; Thu, 3 Dec 1998 03:29:03 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id AAA01110; Thu, 3 Dec 1998 00:27:26 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA28610; Thu, 3 Dec 1998 00:30:39 -0800 Date: Thu, 3 Dec 1998 00:30:39 -0800 Message-Id: <199812030830.AAA28610@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Cc: cwitty@newtonlabs.com Subject: comment change in add_window.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Grammar fix. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u add_window.c Index: add_window.c =================================================================== RCS file: /anoncvs/scwm/scwm/add_window.c,v retrieving revision 1.90 diff -u -r1.90 add_window.c --- add_window.c 1998/11/30 16:45:38 1.90 +++ add_window.c 1998/12/03 08:27:55 @@ -613,7 +613,7 @@ CassowaryNewWindow(psw); /* add the stay constraints in */ /* FIXMS: Hmm, do we need to do any real cleanup if this fails? - _Can_ it fail, in it's new location? + _Can_ it fail, in its new location? -- I think we just have to make PlaceWindow put it somewhere and never fail - that's its current behaviour, but it still returns a Bool that's always just True... --07/27/98 gjb Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 3 03:30:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05463 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:30:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05455 for ; Thu, 3 Dec 1998 03:30:24 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA21087; Thu, 3 Dec 98 03:29:01 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA01899; Thu, 3 Dec 1998 10:28:25 +0200 To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812020545.VAA14957@nebula.newtonlabs.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Dec 1998 10:28:24 +0200 In-Reply-To: Greg Badros's message of "02 Dec 1998 08:04:38 -0800" Message-Id: Lines: 29 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Greg Badros writes: > hjstein@bfr.co.il (Harvey J. Stein) writes: > > > Robert Bihlmeyer writes: > > > > > BTW, what is the status of the scheme-Version of the extractor? > > > > The status is that it doesn't extract as much stuff as the perl > > version. It's not clear to me exactly what was added to the perl > > version since I last updated the scheme version. I was going to start > > reverse engineering the perl version again, but found I had to upgrade > > perl & haven't gotten around to that yet. > > The log files may be of some use: > > cvs log extract-docs # it's been renamed, but the related log entries > # are for the old name > > I'd try to explain the changes better now, but I don't remember offhand, > and time is especially tight right now. I already looked at that. I didn't find it sufficiently descriptive to work with. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Dec 3 03:35:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05555 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:35:50 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05552 for ; Thu, 3 Dec 1998 03:35:34 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA11264; Thu, 3 Dec 98 03:33:59 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id DAA13377 for ; Thu, 3 Dec 1998 03:34:09 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id DAA24475 for ; Thu, 3 Dec 1998 03:34:08 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id DAA11286; Thu, 3 Dec 1998 03:34:08 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13926.19712.349381.447919@horus.cs.cornell.edu> Date: Thu, 3 Dec 1998 03:34:08 -0500 (EST) To: scwm-discuss@mit.edu Subject: Re: SESSION_MANAGER, what is it? X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk > Then we should celebrate (via a notice message) when the session manager > does exist so those wanting a warning will get an implicit one in that the > celebratory note did *not* appear. Why not set a variable, so people can implement their own warnings in case it doesn't fit what they expect? -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Thu Dec 3 03:40:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05579 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:40:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05576 for ; Thu, 3 Dec 1998 03:40:36 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA11720; Thu, 3 Dec 98 03:38:58 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA01959; Thu, 3 Dec 1998 10:38:55 +0200 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: CVS question/request References: <199812020545.VAA14957@nebula.newtonlabs.com> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Dec 1998 10:38:55 +0200 In-Reply-To: hjstein@bfr.co.il's message of "02 Dec 1998 17:52:43 +0200" Message-Id: Lines: 59 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il (Harvey J. Stein) writes: > Robert Bihlmeyer writes: > > > BTW, what is the status of the scheme-Version of the extractor? > > The status is that it doesn't extract as much stuff as the perl > version. It's not clear to me exactly what was added to the perl > version since I last updated the scheme version. I was going to start > reverse engineering the perl version again, but found I had to upgrade > perl & haven't gotten around to that yet. I forgot to mention one additional point. Scheme fcns are documented like: (define-public (foo ...) "Documentation string for foo..." ...) (or with define-public*), whereas variables are documented like: (define-public foo ;;;**VAR ;;; Documentation for foo... ...) When I noticed the 1st form, I started extracting documentation from the scheme code just by using (read). This was easy & convenient. The 2nd form doesn't lend itself to such an easy implementation. I was hoping there'd be a rational move to documentation strings for variables as well as fcns which would make the parsing easier. In fact, it's only reasonable because in scheme there's really no difference btw variables & fcns. I should be able to do: (define-public (foo x y) ...) as well as (define-public foo (lambda (x y) ...)) and get the same result. Why should I be able to give the 1st one a doc string but not the 2nd one? The whole issue could be easily closed by having a scheme interface for the doc strings: (doc-string-set! foo "....") (doc-string-ref foo) Then it's just a matter of when it's decided to make define-public take a doc string argument when it doesn't contain an implied lambda (i.e. - when the 1st arg is a symbol & not a list). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Dec 3 03:42:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05601 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:42:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05598 for ; Thu, 3 Dec 1998 03:42:49 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA22266; Thu, 3 Dec 98 03:41:31 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA01979; Thu, 3 Dec 1998 10:41:17 +0200 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: docking windows References: Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Dec 1998 10:41:16 +0200 In-Reply-To: Robert Bihlmeyer's message of "02 Dec 1998 16:30:01 +0100" Message-Id: Lines: 27 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > even under windoze there are new ideas to be found for the wm writer. > > Yesterday, I played around with winamp 2.04. As you may know, this > thing bypasses windoze's normal window-decorations, and practically > implements it's own window managing (one can move its windows by > dragging the title bar, etc.). > > A nice property of this gizmo is, that when moving one winamp-window > close to another one, the one you move jumps to the other one (like > attracting magnets). It works a bit like scwm's edge-threshold. With > edge-threshold, you can't have a window that is less than X pixels > outside of the viewport. With window docking you can't have windows > that are less than X pixels apart. The details are configurable. > > I think this would be a fine feature for the TODO. Hacking it into > moveLoop before the GER seems not so good an idea. Can't you easily add it on in a move hook? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Dec 3 03:57:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA05856 for scwm-discuss-outgoing; Thu, 3 Dec 1998 03:57:32 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA05853 for ; Thu, 3 Dec 1998 03:57:31 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA13259; Thu, 3 Dec 98 03:55:55 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id DAA14623 for ; Thu, 3 Dec 1998 03:56:06 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id DAA25073 for ; Thu, 3 Dec 1998 03:56:05 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id DAA11302; Thu, 3 Dec 1998 03:56:05 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Message-Id: <13926.21029.537590.916621@horus.cs.cornell.edu> Date: Thu, 3 Dec 1998 03:56:05 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: scwm-discuss@mit.edu Subject: tile.scm X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. Raise is documented & used in tile-windows, that looks like a bug. 2. The doc for tile uses "cascaded" twice. -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Thu Dec 3 09:54:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA07271 for scwm-discuss-outgoing; Thu, 3 Dec 1998 09:54:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA07257; Thu, 3 Dec 1998 09:53:26 -0500 Message-Id: <199812031453.JAA07257@vicarious-existence.mit.edu> To: "Carl R. Witty" cc: scwm-discuss@mit.edu Subject: Re: please remove scwmmenu.c from CVS In-reply-to: Your message of "Wed, 02 Dec 1998 23:48:18 PST." <199812030748.XAA28443@nebula.newtonlabs.com> Date: Thu, 03 Dec 1998 09:53:26 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Please remove scwmmenu.c (and any other dead code) from CVS. It still > gets docs extracted by scwmdoc. > > (Maybe it has already been removed and this is another instance of the > CVS bug?) > Yes, the problem was that I needed to add the --delete option to the rsync cron job. This has now been done, plus I ran it manually so the anoncvs repository should be nicely updated now. This should also solve the lock file problem. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 3 10:04:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA07355 for scwm-discuss-outgoing; Thu, 3 Dec 1998 10:04:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA07352 for ; Thu, 3 Dec 1998 10:04:04 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03226; Thu, 3 Dec 98 10:02:23 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id RAA20727; Thu, 3 Dec 1998 17:02:19 +0200 To: Maciej Stachowiak Cc: "Carl R. Witty" , scwm-discuss@mit.edu Subject: Re: please remove scwmmenu.c from CVS References: <199812031453.JAA07257@vicarious-existence.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 03 Dec 1998 17:02:18 +0200 In-Reply-To: Maciej Stachowiak's message of "Thu, 03 Dec 1998 09:53:26 EST" Message-Id: Lines: 22 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > cwitty@newtonlabs.com writes: > > Please remove scwmmenu.c (and any other dead code) from CVS. It still > > gets docs extracted by scwmdoc. > > > > (Maybe it has already been removed and this is another instance of the > > CVS bug?) > > Yes, the problem was that I needed to add the --delete option to the > rsync cron job. This has now been done, plus I ran it manually so the > anoncvs repository should be nicely updated now. This should also > solve the lock file problem. Unless you update the anon repo when there's a lock in the real repo. Could also be dangerous to step on locks that exist in the anon repo, but I guess these should never exist. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Thu Dec 3 10:26:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA07652 for scwm-discuss-outgoing; Thu, 3 Dec 1998 10:26:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA07647; Thu, 3 Dec 1998 10:26:39 -0500 Message-Id: <199812031526.KAA07647@vicarious-existence.mit.edu> To: Eli Barzilay cc: scwm-discuss@mit.edu Subject: Re: SESSION_MANAGER, what is it? In-reply-to: Your message of "Thu, 03 Dec 1998 03:34:08 EST." <13926.19712.349381.447919@horus.cs.cornell.edu> Date: Thu, 03 Dec 1998 10:26:39 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk eli@cs.cornell.edu writes: > > > Then we should celebrate (via a notice message) when the session manager > > does exist so those wanting a warning will get an implicit one in that the > > celebratory note did *not* appear. > > Why not set a variable, so people can implement their own warnings in case it > doesn't fit what they expect? > Er, yeah, I think there should be a (session-management-active?) predicate or something. That way you can not only display a warning if you want, but you can have arbitrary different behavior based on the difference, or pop up a dialog or something. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 3 10:36:17 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA07745 for scwm-discuss-outgoing; Thu, 3 Dec 1998 10:36:17 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA07742 for ; Thu, 3 Dec 1998 10:36:16 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA15943; Thu, 3 Dec 98 10:34:36 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Thu, 3 Dec 1998 16:33:44 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id QAA28723; Thu, 3 Dec 1998 16:33:40 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id QAA03133; Thu, 3 Dec 1998 16:33:27 +0100 Date: Thu, 3 Dec 1998 16:33:27 +0100 Message-Id: <199812031533.QAA03133@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: doug@tc.net Cc: scwm-discuss@mit.edu Subject: Re: Problems with scwm and FvwmButtons In-Reply-To: References: <13923.9848.34695.780686@enterprise.osterwald.de> <199812020939.KAA19259@ull.tnt.uni-hannover.de> <199812021619.RAA23108@ull.tnt.uni-hannover.de> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Doug" == Doug McNaught writes: Doug> Heiko Muenkel writes: >> I don't think so, because there is a difference in the >> behaviour of the scwm, if I've an empty ~/.fvwmrc or no >> ~/.fvwmrc. If the file is empty, I won't get a FvwmButtons >> window, but the scwm will not crash with a segmentation >> fault. If I've no ~/.fvwmrc, the scwm will crash with a >> segmentation fault. In the case of no ~/.fvwmrc the FvwmButtons >> module will probably read the system wide Fvwm configuration >> file. Do you've a system wide Fvwm configuration file (may be >> /usr/lib/X11/fvwm/.fvwm2rc or /usr/lib/X11/fvwm2/.fvwm2rc) ? Doug> Good point. I have a .fvwmrc file (with no references to Doug> FvwmButtons) and the standard system.fvwm2rc as well. It's Doug> my impression that FvwmButtons just wants the file to be Doug> there, but doesn't have to read anything from it. I haven't Doug> bothered to use strace to figure out what it's exactly Doug> trying to do, though--you might try that. Good idea, I'll try it. What scwm and Guile releases to you use and on which system? Thanks, Heiko From owner-scwm-discuss@mit.edu Thu Dec 3 10:59:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA07993 for scwm-discuss-outgoing; Thu, 3 Dec 1998 10:59:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA07990 for ; Thu, 3 Dec 1998 10:59:24 -0500 Received: from dns1.tc.net by MIT.EDU with SMTP id AA09511; Thu, 3 Dec 98 10:57:01 EST Received: from [10.16.190.28] by dns1.tc.net for id KAA19784; Thu Dec 3 10:56:33 1998 Received: (from doug@localhost) by ono.tc.net (8.8.7/8.8.7) id KAA02749; Thu, 3 Dec 1998 10:56:28 -0500 Subject: Re: Problems with scwm and FvwmButtons References: <13923.9848.34695.780686@enterprise.osterwald.de> <199812020939.KAA19259@ull.tnt.uni-hannover.de> <199812021619.RAA23108@ull.tnt.uni-hannover.de> <199812031533.QAA03133@ull.tnt.uni-hannover.de> Date: 03 Dec 1998 10:56:28 -0500 In-Reply-To: Heiko Muenkel's message of "Thu, 3 Dec 1998 16:33:27 +0100" Message-Id: Lines: 21 X-Mailer: Gnus v5.6.9/XEmacs 20.4 - "Emerald" To: Heiko Muenkel From: Doug McNaught Cc: scwm-discuss@mit.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk Heiko Muenkel writes: > Doug> Good point. I have a .fvwmrc file (with no references to > Doug> FvwmButtons) and the standard system.fvwm2rc as well. It's > Doug> my impression that FvwmButtons just wants the file to be > Doug> there, but doesn't have to read anything from it. I haven't > Doug> bothered to use strace to figure out what it's exactly > Doug> trying to do, though--you might try that. > > Good idea, I'll try it. > > What scwm and Guile releases to you use and on which system? Erm... I'm using a scwm snapshot from a few months ago and a pre-1.3 Guile of the same vintage, under Red Hat 5.2. -Doug -- Doug McNaught doug@tc.net Senior Network Engineer dmcnaught@premtec.com Premiere Communications http://www.premtec.com From owner-scwm-discuss@mit.edu Thu Dec 3 11:31:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA08318 for scwm-discuss-outgoing; Thu, 3 Dec 1998 11:31:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA08312; Thu, 3 Dec 1998 11:30:52 -0500 Message-Id: <199812031630.LAA08312@vicarious-existence.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) cc: scwm-discuss@mit.edu Subject: Re: please remove scwmmenu.c from CVS In-reply-to: Your message of "03 Dec 1998 17:02:18 +0200." Date: Thu, 03 Dec 1998 11:30:52 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > cwitty@newtonlabs.com writes: > > > Please remove scwmmenu.c (and any other dead code) from CVS. It still > > > gets docs extracted by scwmdoc. > > > > > > (Maybe it has already been removed and this is another instance of the > > > CVS bug?) > > > > Yes, the problem was that I needed to add the --delete option to the > > rsync cron job. This has now been done, plus I ran it manually so the > > anoncvs repository should be nicely updated now. This should also > > solve the lock file problem. > > Unless you update the anon repo when there's a lock in the real repo. Actually, I am not too worried about that, if there is a lock in the real repo that means it is in the middle of a checkin and in an inconsistent state, and anyway it should get fixed within 30 minutes when the next anon update happens. I can make it retry after 5 minutes if it finds a lock file if you are concerned. > Could also be dangerous to step on locks that exist in the anon repo, > but I guess these should never exist. Yes, nothing should be writing files there but rsync. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 3 20:53:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA14565 for scwm-discuss-outgoing; Thu, 3 Dec 1998 20:53:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA14562 for ; Thu, 3 Dec 1998 20:53:13 -0500 Received: from M2-032-3.MIT.EDU by MIT.EDU with SMTP id AA13110; Thu, 3 Dec 98 20:51:29 EST Received: by m2-032-3.mit.edu (SMI-8.6/4.7) id UAA26929; Thu, 3 Dec 1998 20:51:40 -0500 Message-Id: <199812040151.UAA26929@m2-032-3.mit.edu> To: scwm-discuss@mit.edu Subject: interactive move and edge scrolling Date: Thu, 03 Dec 1998 20:51:40 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk If you trigger edge scrolling during an interactive-move operation (whether rubber-band or opaque) the old window or rubber-band position is not cleared and the new one is not immediately updated. This leads to excessive flashing when doing the opaque move, and visual artifacts when using the rubber band. Similar bugs appear to plague interactive resizes that trigger edge scrolling. I am reporting this bug here in case anyone knows offhand what is causing it, otherwise I will have to plumb the depths of move.c anr resize.c myself (more than I did already). - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 00:48:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA19353 for scwm-discuss-outgoing; Fri, 4 Dec 1998 00:48:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id AAA19349 for ; Fri, 4 Dec 1998 00:48:33 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id VAA16882 for ; Thu, 3 Dec 1998 21:46:59 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id VAA00685; Thu, 3 Dec 1998 21:50:54 -0800 Date: Thu, 3 Dec 1998 21:50:54 -0800 Message-Id: <199812040550.VAA00685@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for winops.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u winops.scm Index: winops.scm =================================================================== RCS file: /anoncvs/scwm/scheme/winops.scm,v retrieving revision 1.31 diff -u -r1.31 winops.scm --- winops.scm 1998/12/04 02:01:17 1.31 +++ winops.scm 1998/12/04 05:47:40 @@ -31,10 +31,14 @@ ;;; Toggling operations (define*-public ((make-toggling-winop pred neg pos) - #&optional (w (get-window))) - (if w (if (pred w) - (neg w) - (pos w)))) + #&optional (win (get-window))) + "Returns a procedure which takes a window WIN and toggles a property of it. +PRED, NEG, and POS should be functions which take a window and +check whether the property holds for the window, reset the property +on the window, and set the property on the window, respectively." + (if win (if (pred win) + (neg win) + (pos win)))) (define*-public (close-window #&optional (win (get-window #t))) "Close WIN either by deleting it or destroying it. From owner-scwm-discuss@mit.edu Fri Dec 4 01:00:29 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19486 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:00:29 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19483 for ; Fri, 4 Dec 1998 01:00:27 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id VAA16993 for ; Thu, 3 Dec 1998 21:58:53 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01802; Thu, 3 Dec 1998 22:02:49 -0800 Date: Thu, 3 Dec 1998 22:02:49 -0800 Message-Id: <199812040602.WAA01802@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: scwmdoc bug report & doc update for winlist.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk scwmdoc was failing on the documentation for list-windows in winlist.scm, because the docstring had an open-paren in the first column. The following patch works around this scwmdoc bug. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u winlist.scm Index: winlist.scm =================================================================== RCS file: /anoncvs/scwm/scheme/winlist.scm,v retrieving revision 1.23 diff -u -r1.23 winlist.scm --- winlist.scm 1998/11/14 23:08:49 1.23 +++ winlist.scm 1998/12/04 05:59:12 @@ -64,8 +64,8 @@ time (most recently focussed first) if BY-FOCUS is #t. If REVERSE is true, they are returned in the reverse of the usual order. ONLY and EXCEPT each are procedures which take a single window argument and -returns #t if the window should be included (for ONLY) or excluded -(for EXCEPT), or #f otherwise." +returns #t if the window should be included (for ONLY) or +excluded (for EXCEPT), or #f otherwise." ((if reverse local-reverse id) (filter-only-except (if by-stacking Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:01:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19517 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:01:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19514 for ; Fri, 4 Dec 1998 01:01:42 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17022 for ; Thu, 3 Dec 1998 22:00:08 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01814; Thu, 3 Dec 1998 22:04:04 -0800 Date: Thu, 3 Dec 1998 22:04:04 -0800 Message-Id: <199812040604.WAA01814@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: minor doc updates for wininfo.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u wininfo.scm Index: wininfo.scm =================================================================== RCS file: /anoncvs/scwm/scheme/wininfo.scm,v retrieving revision 1.29 diff -u -r1.29 wininfo.scm --- wininfo.scm 1998/11/17 06:25:55 1.29 +++ wininfo.scm 1998/12/04 06:00:31 @@ -35,6 +35,7 @@ (if win (= n (window-desk win)))) (define*-public ((on-desk-n? n) #&optional (win (get-window))) + "Returns a function which takes WIN and returns #t if WIN is on desk N, else #f." (on-desk? n win)) (define*-public (on-current-desk? #&optional (win (get-window))) @@ -100,7 +101,7 @@ (define*-public (percent-visible #&optional (win (get-window))) "Return the percent of WIN currently in the viewport as a real in [0,100]. -Note that this does not discount for other windows which may +Note that this does not consider other windows which may obscure WIN; it only checks what fraction of WIN would be visible if it were on top (unobscured)." (if (not (on-current-desk? win)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:05:28 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19662 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:05:28 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19658 for ; Fri, 4 Dec 1998 01:05:26 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17051 for ; Thu, 3 Dec 1998 22:03:52 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01858; Thu, 3 Dec 1998 22:07:47 -0800 Date: Thu, 3 Dec 1998 22:07:47 -0800 Message-Id: <199812040607.WAA01858@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: docs for themes.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk I threw together some themes-related docs. Unfortunately, too much of the implementation is missing for me to write really good docs... === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u themes.scm Index: themes.scm =================================================================== RCS file: /anoncvs/scwm/scheme/themes.scm,v retrieving revision 1.3 diff -u -r1.3 themes.scm --- themes.scm 1998/11/15 20:38:53 1.3 +++ themes.scm 1998/12/04 06:02:05 @@ -29,6 +29,12 @@ +;;;**CONCEPT:Themes +;;; A theme is a named collection of window manager settings. +;;; Themes are still under development, but they are planned to +;;; affect window styles, menus, icons, backgrounds, and various +;;; global settings. + (define-public theme-path (list (string-append (scwm-path-prefix) "/share/scwm-themes"))) @@ -44,6 +50,15 @@ (for-menus #t) (for-icons #t) (for-background #t) (for-global-settings #t)) + "Use settings from THEME to set up the window manager. +THEME can be either a theme object (as returned by `load-theme') or a +string naming a theme, in which case that theme will be loaded and +used. By default, window styles, menus, icons, backgrounds, and +global settings are all affected; if the FOR-WINDOWS, FOR-MENUS, +FOR-ICONS, FOR-BACKGROUND, or FOR-GLOBAL-SETTINGS arguments are #f, +the corresponding areas are not affected. (Note: at this time, +only windows and backgrounds are affected; the other components +of themes have yet to be implemented.)" (let ((theme (if (string? theme) (load-theme theme) theme))) (if for-windows @@ -55,6 +70,9 @@ ((theme:background-style theme))))) (define-public (load-theme fname) + "Returns a theme FNAME which is loaded from `theme-path'. +The theme should be either a directory, or a (possibly gzipped) +tar file with extension .tar, .tar.gz, or .tgz." (let ((full-fname (or (find-file-in-path fname theme-path) (find-file-in-path (string-append fname ".tar") theme-path) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:08:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19749 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:08:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19746 for ; Fri, 4 Dec 1998 01:08:25 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17086 for ; Thu, 3 Dec 1998 22:06:50 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01887; Thu, 3 Dec 1998 22:10:46 -0800 Date: Thu, 3 Dec 1998 22:10:46 -0800 Message-Id: <199812040610.WAA01887@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: docs for theme-impl.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk Here's some docs for theme-impl.scm. Unfortunately, as with themes.scm, the docs aren't great. There's also a couple of FIXME comments for Maciej. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u theme-impl.scm Index: theme-impl.scm =================================================================== RCS file: /anoncvs/scwm/scheme/theme-impl.scm,v retrieving revision 1.2 diff -u -r1.2 theme-impl.scm --- theme-impl.scm 1998/11/14 23:08:49 1.2 +++ theme-impl.scm 1998/12/04 06:05:29 @@ -26,12 +26,42 @@ +;;;**CONCEPT:Creating themes +;;; Currently, the best documentation on themes is the source code; +;;; however, here are a few notes. +;;; To create a theme, create a new subdirectory of a directory in +;;; `theme-path' (you'll probably want to add a private directory to +;;; `theme-path'). This subdirectory should be named the same as the +;;; theme. This subdirectory must contain (at least) a file named +;;; theme.scm. This file must create a module named +;;; (app scwm theme your-theme-name), and define (in this module) +;;; a theme object named `the-theme'. See the existing themes for +;;; examples of what you can do when building `the-theme'. + +;; CRW:FIXME:MS: I assume that load-theme-image is supposed to be used +;; by a theme file for loading images. However, it only works if +;; the theme loads all its images when the theme itself is loaded. +;; I've got an idea for another implementation: +;; There is a global variable theme-dir (exported from, say, themes.scm). +;; This is dynamically bound to the theme directory when loading +;; .../theme.scm. +;; Each theme module says (define theme-dir theme-dir); now the module +;; has a record of what directory it was loaded from. +;; load-theme-image changes to (load-theme-image theme-dir fname); +;; the first branch of the or changes to (string-append theme-dir fname). +;; Unfortunately, this conflicts with the desire to erase the unpacked +;; forms of .tar/.tar.gz/.tgz themes. (As far as I can tell, these +;; currently stick around forever?) + (define-public (load-theme-image fname) (or (make-image (string-append "./" fname)) (make-image fname))) +;; CRW:FIXME:: The following docstring is totally redundant with the function +;; name and argument list. Can we do better? (define*-public (make-theme name #&key (window-style (make-style #t)) (background-style (lambda () ()))) + "Creates a theme object with the given NAME, WINDOW-STYLE, and BACKGROUND-STYLE." (vector name window-style background-style)) (define-public (theme:name theme) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:10:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19810 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:10:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19806 for ; Fri, 4 Dec 1998 01:10:42 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17121 for ; Thu, 3 Dec 1998 22:09:07 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01916; Thu, 3 Dec 1998 22:13:03 -0800 Date: Thu, 3 Dec 1998 22:13:03 -0800 Message-Id: <199812040613.WAA01916@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc updates for style.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk I actually rearranged some code in style.scm, just to have functions to hang docstrings on. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u style.scm Index: style.scm =================================================================== RCS file: /anoncvs/scwm/scheme/style.scm,v retrieving revision 1.18 diff -u -r1.18 style.scm --- style.scm 1998/11/14 23:08:49 1.18 +++ style.scm 1998/12/04 06:08:30 @@ -231,14 +231,27 @@ (add-window-hint-option #:lenience set-lenience!) +;; CRW:FIXME:GJB: Should there be a way to document window properties? +;; The only reason for the existence of the following functions is to +;; have a place to hang the documentation... + +(define-public (set-window-placement-proc! proc win) + "Set the 'placement-proc property of WIN to PROC. +When the window manager tries to place WIN, it will call PROC to +actually set its position. This function must be called before the +window is placed (i.e., from before-new-window-hook); see `window-style' +for a way to make sure this function is called at the correct time." + (set-object-property! win 'placement-proc proc)) + +(define-public (set-window-transient-placement-proc! proc win) + "Like `set-window-placement-proc!' (which see), but for transient +windows." + (set-object-property! win 'transient-placement-proc proc)) + ;; placement -(add-window-hint-option #:placement-proc - (lambda (val w) - (set-object-property! w 'placement-proc val))) -(add-window-hint-option #:transient-placement-proc - (lambda (val w) - (set-object-property! w 'transient-placement-proc - val))) +(add-window-hint-option #:placement-proc set-window-placement-proc!) +(add-window-hint-option #:transient-placement-proc + set-window-transient-placement-proc!) ;; random stuff (add-boolean-style-option #:start-lowered lower-window raise-window) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:12:40 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19827 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:12:40 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19823 for ; Fri, 4 Dec 1998 01:12:39 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17138 for ; Thu, 3 Dec 1998 22:11:05 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01928; Thu, 3 Dec 1998 22:15:00 -0800 Date: Thu, 3 Dec 1998 22:15:00 -0800 Message-Id: <199812040615.WAA01928@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc updates for std-menus.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk A typo fix, and an attempt at clarifying the docs for make-context-menu. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u std-menus.scm Index: std-menus.scm =================================================================== RCS file: /anoncvs/scwm/scheme/std-menus.scm,v retrieving revision 1.19 diff -u -r1.19 std-menus.scm --- std-menus.scm 1998/11/14 23:08:49 1.19 +++ std-menus.scm 1998/12/04 06:10:43 @@ -80,7 +80,7 @@ (menuitem \"telnet\" #:action (make-hosts-menu '(\"host1\" \"host2\" ...))) An optional USER argument specifies the user to telnet as. The element of the list of hosts can be a host (in which case telnet is -used or a cons of (host . command)." +used) or a cons of (host . command)." (menu (fold-menu-list (map (lambda (hh) (if (pair? hh) @@ -112,8 +112,7 @@ (define-public (make-context-menu) "Create a menu of actions applicable to the filename in the X selection. -The selection is limited to contain one filename, and the full path of the -file must be given." +The selection must contain a single full pathname." (let ((file (X-cut-buffer-string))) (menu (append (list (menuitem (string-append "... " file)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:14:50 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19850 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:14:50 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19846 for ; Fri, 4 Dec 1998 01:14:49 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17167 for ; Thu, 3 Dec 1998 22:13:14 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01943; Thu, 3 Dec 1998 22:17:10 -0800 Date: Thu, 3 Dec 1998 22:17:10 -0800 Message-Id: <199812040617.WAA01943@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: pedantic doc fixes for stacking.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk These are really nitpicking. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u stacking.scm Index: stacking.scm =================================================================== RCS file: /anoncvs/scwm/scheme/stacking.scm,v retrieving revision 1.2 diff -u -r1.2 stacking.scm --- stacking.scm 1998/08/21 23:03:32 1.2 +++ stacking.scm 1998/12/04 06:13:50 @@ -51,12 +51,16 @@ (cdr memq-result) ()))) +;; CRW:FIXME:: The following two procedures are misnamed; `lower-window-below' +;; doesn't necessarily lower the window (it could raise it); +;; `raise-window-above' doesn't necessarily raise the window (it could +;; lower it). Should they be renamed? (define-public (lower-window-below w w2) - "Lower window W immediately below W2." + "Restack window W immediately below W2." (restack-windows (list w2 w))) (define-public (raise-window-above w w2) - "Raise window W immediately above W2." + "Restack window W immediately above W2." (let ((windows-above-w2 (list-windows-above w2))) (if (null? windows-above-w2 w2) (raise-window w) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:16:00 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19867 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:16:00 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19861 for ; Fri, 4 Dec 1998 01:15:48 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17178 for ; Thu, 3 Dec 1998 22:14:09 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01954; Thu, 3 Dec 1998 22:18:05 -0800 Date: Thu, 3 Dec 1998 22:18:05 -0800 Message-Id: <199812040618.WAA01954@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for prefs-menu.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u prefs-menu.scm Index: prefs-menu.scm =================================================================== RCS file: /anoncvs/scwm/scheme/prefs-menu.scm,v retrieving revision 1.24 diff -u -r1.24 prefs-menu.scm --- prefs-menu.scm 1998/11/14 23:08:49 1.24 +++ prefs-menu.scm 1998/12/04 06:14:50 @@ -63,6 +63,7 @@ (set-desk-size! (+ xx dx) (+ yy dx)))) (define-public (help-mesg . funcs) ; return lambda + "Displays help for each element of FUNCS, which should be a list of strings." (lambda () (message (with-output-to-string (lambda () (for-each help funcs)))))) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:16:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19878 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:16:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19874 for ; Fri, 4 Dec 1998 01:16:47 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17205 for ; Thu, 3 Dec 1998 22:15:13 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01960; Thu, 3 Dec 1998 22:19:09 -0800 Date: Thu, 3 Dec 1998 22:19:09 -0800 Message-Id: <199812040619.WAA01960@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: typo fix in module-types.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u module-types.scm Index: module-types.scm =================================================================== RCS file: /anoncvs/scwm/scheme/module-types.scm,v retrieving revision 1.2 diff -u -r1.2 module-types.scm --- module-types.scm 1998/08/21 23:03:32 1.2 +++ module-types.scm 1998/12/04 06:15:45 @@ -57,7 +57,7 @@ (cons 4194304 "M_STRING") (cons 8388608 "M_MINI_ICON") (cons 16777216 "M_WINDOWSHADE") - (cons 3355443 "M_DEWINDOWSHADE"))) + (cons 33554432 "M_DEWINDOWSHADE"))) ;; Usage e.g.: (module-event-name-from-number 8192) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:21:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19955 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:21:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19948 for ; Fri, 4 Dec 1998 01:21:36 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17264 for ; Thu, 3 Dec 1998 22:20:02 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01966; Thu, 3 Dec 1998 22:23:57 -0800 Date: Thu, 3 Dec 1998 22:23:57 -0800 Message-Id: <199812040623.WAA01966@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc fixes for listops.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk Fixes some problems with the documentation of and-map and or-map. (I changed the documentation to match the function; I suppose it would be possible to change the function to match the previous documentation instead, but I actually prefer the current behavior.) === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u listops.scm Index: listops.scm =================================================================== RCS file: /anoncvs/scwm/scheme/listops.scm,v retrieving revision 1.2 diff -u -r1.2 listops.scm --- listops.scm 1998/11/14 23:08:48 1.2 +++ listops.scm 1998/12/04 06:16:48 @@ -110,7 +110,7 @@ "Apply PROC repeatedly, returning the first false value. PROC is applied to elements of FIRST and the lists comprising REST much as `map' would do it. If proc never returns a false value, return -the last value instead. If all the lists are empty, return #t." +#t instead. If all the lists are empty, return #t." (if (null? rest) (let loop ((first first)) (or (null? first) @@ -125,10 +125,10 @@ (define-public (or-map proc first . rest) - "Apply PROC repeatedly, returning the first false value. + "Apply PROC repeatedly, returning the first true value. PROC is applied to elements of FIRST and the lists comprising REST -much as `map' would do it. If PROC never returns a false value, return -the last value instead. If all the lists are empty, return true." +much as `map' would do it. If PROC never returns a true value, return +#f instead. If all the lists are empty, return #f." (if (null? rest) (let loop ((first first)) (and (not (null? first)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:22:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA19994 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:22:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA19991 for ; Fri, 4 Dec 1998 01:22:31 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17274 for ; Thu, 3 Dec 1998 22:20:56 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01977; Thu, 3 Dec 1998 22:24:52 -0800 Date: Thu, 3 Dec 1998 22:24:52 -0800 Message-Id: <199812040624.WAA01977@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: docs for image-loaders.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u image-loaders.scm Index: image-loaders.scm =================================================================== RCS file: /anoncvs/scwm/scheme/image-loaders.scm,v retrieving revision 1.2 diff -u -r1.2 image-loaders.scm --- image-loaders.scm 1998/08/21 23:03:32 1.2 +++ image-loaders.scm 1998/12/04 06:21:40 @@ -23,19 +23,20 @@ -;; Uses the "convert" tool from the ImageMagick package to try to -;; convert the file to an xpm, then attempts to load it as such. (define-public (ImageMagick-loader fname) + "Tries to load an arbitrary image using ImageMagick's `convert'. +Uses `convert' to try to convert the file to an xpm, then +attempts to load it as such." (let ((t (string-append (tmpnam) ".xpm"))) (catch #t (lambda () (system (string-append "convert " fname " " t))) (lambda args #f)) (load-xpm t))) -;; Uses the "anytopnm" and "ppmtoxpm" tools from the netpbm package to -;; try to convert the file to an xpm, then attempts to load it as -;; such. (define-public (netpbm-loader fname) + "Tries to load an arbitrary image using the netpbm packge. +Uses `anytoppm' and `ppmtoxpm' to try to convert the file to an xpm, +then attempts to load it as such." (let ((t (string-append (tmpnam) ".xpm"))) (catch #t (lambda () @@ -43,13 +44,14 @@ (lambda args #f)) (load-xpm t))) -;; Try all available loaders. (define-public (try-everything-loader fname) + "Tries to load an arbitrary image, using any available loader." (cond ((ImageMagick-loader fname) => id) (else (netpbm-loader fname)))) -;; Just a convenience wrapper to make the try-everything-loader -;; the default. (define-public (support-image-conversion) + "Set things up to try to load arbitrary images. +Works by setting `try-everything-loader' as the image loader for +unknown extensions." (register-image-loader "default" try-everything-loader)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:24:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20087 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:24:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20080 for ; Fri, 4 Dec 1998 01:24:20 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17297 for ; Thu, 3 Dec 1998 22:22:44 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01982; Thu, 3 Dec 1998 22:26:39 -0800 Date: Thu, 3 Dec 1998 22:26:39 -0800 Message-Id: <199812040626.WAA01982@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: one fewer undocumented public function in fvwm-module.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u fvwm-module.scm Index: fvwm-module.scm =================================================================== RCS file: /anoncvs/scwm/scheme/fvwm-module.scm,v retrieving revision 1.25 diff -u -r1.25 fvwm-module.scm --- fvwm-module.scm 1998/11/15 20:38:53 1.25 +++ fvwm-module.scm 1998/12/04 06:22:39 @@ -278,8 +278,7 @@ (send-mini-icon-packet win port) )) -;; FIXGJB: not public -(define-public (end-window-list port) +(define (end-window-list port) (fvwm2-module-send-packet M_END_WINDOWLIST "" port)) (define active-modules '()) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:25:18 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20115 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:25:18 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20112 for ; Fri, 4 Dec 1998 01:25:16 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17314 for ; Thu, 3 Dec 1998 22:23:41 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01987; Thu, 3 Dec 1998 22:27:37 -0800 Date: Thu, 3 Dec 1998 22:27:37 -0800 Message-Id: <199812040627.WAA01987@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc fix for fvwm-eval.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u fvwm-eval.scm Index: fvwm-eval.scm =================================================================== RCS file: /anoncvs/scwm/scheme/fvwm-eval.scm,v retrieving revision 1.15 diff -u -r1.15 fvwm-eval.scm --- fvwm-eval.scm 1998/10/05 01:48:14 1.15 +++ fvwm-eval.scm 1998/12/04 06:24:22 @@ -513,6 +513,11 @@ (define*-public (eval-fvwm-command command #&optional (fmod #f) (window #f)) + "Evaluate an fvwm2 command. +Implemented for compatibility with fvwm2 modules, which can send +commands back to the window manager for evaluation. Not all fvwm2 +commands are implemented; see the end of fvwm-eval.scm for a list of +working commands." (let* ((split-result (split-before-char #\space command (lambda args args))) (main-cmd (car split-result)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:27:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20132 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:27:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20128 for ; Fri, 4 Dec 1998 01:27:57 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17352 for ; Thu, 3 Dec 1998 22:26:22 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA01999; Thu, 3 Dec 1998 22:30:18 -0800 Date: Thu, 3 Dec 1998 22:30:18 -0800 Message-Id: <199812040630.WAA01999@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc fixes for flux.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u flux.scm Index: flux.scm =================================================================== RCS file: /anoncvs/scwm/scheme/flux.scm,v retrieving revision 1.72 diff -u -r1.72 flux.scm --- flux.scm 1998/12/04 02:01:17 1.72 +++ flux.scm 1998/12/04 06:25:25 @@ -28,25 +28,25 @@ (define-public (interactive-move-window-with-focus) "Interactively move the window which currently has the focus. -`interactive-move' is used to control whether a rubberband +`move-opaquely?' is used to control whether a rubberband outline or the window itself is moved." (let ((w (current-window-with-focus))) (and w (interactive-move w)))) (define-public (interactive-resize-window-with-focus) "Interactively resize the window which currently has the focus. -`interactive-resize' is used to control whether a rubberband +`resize-opaquely?' is used to control whether a rubberband outline or the window itself is resized." (let ((w (current-window-with-focus))) (and w (interactive-resize w)))) (define-public (interactive-move-window-with-pointer) "Interactively move the window which currently contains the pointer. -`interactive-move-maybe-opaque' is used to control whether a rubberband +`move-opaquely?' is used to control whether a rubberband outline or the window itself is moved." (let ((w (current-window-with-pointer))) (and w (interactive-move w)))) (define-public (interactive-resize-window-with-pointer) "Interactively resize the window which currently contains the pointer. -`interactive-resize-maybe-opaque' is used to control whether a rubberband +`resize-opaquely?' is used to control whether a rubberband outline or the window itself is resized." (let ((w (current-window-with-pointer))) (and w (interactive-resize w)))) @@ -96,7 +96,7 @@ (modulo (cadr pos) display-height)) win))) (define-public (in-viewport xx yy) - "Return a function of a single argument, a window, moving it to the viewport. + "Return a function which takes a window and moves it to the specified viewport. XX and YY are full display-size increments (e.g., (1,0) is the viewport just to the right of the home (0,0) viewport)." (lambda (win) (move-window-to-viewport xx yy win))) @@ -147,6 +147,8 @@ "; bits per RGB: " (number->string (cadddr dd)) ")\nimage-load-path:\n" (map (lambda (st) (string-append "\t" st "\n")) image-load-path)))) +;; CRW:FIXME:: This should be merged with make-context-menu in +;; std-menus.scm (define-public (make-file-menu file . rest) "Return a menu-object for viewing or editing FILE. REST is a list of other menu-items to include in the returned menu." @@ -162,7 +164,8 @@ ;;; FIXGJB: how set width of an xmessage? (define-public (message . str) - "Display the string arguments STR in a message window." + "Display the string arguments STR in a message window. +Requires the program `xmessage'." (execute (string-append "echo -e \'" (quotify-single-quotes (apply string-append str)) "\'| xmessage -file - -default okay -nearmouse"))) @@ -535,6 +538,7 @@ ;;;;;;;; rlogin menu making from .rhosts file ;;;;;;;;; (define-public (make-rhosts-menu) + "Returns a menu which lets you rlogin to each host mentioned in your .rhosts" (false-if-exception (let* ((rhostfn (string-append (user-home) "/.rhosts")) (termprog "xterm") @@ -678,7 +682,7 @@ "Make netscape go to the URL in CUT_BUFFER0. This permits you to just select a URL and use this function to go to that page. -The optional argument specifies whether a new window should be open. +The optional argument specifies whether a new window should be opened. It defaults to `netscape-new-window'." (run-in-netscape (string-append "openURL(" (X-cut-buffer-string) (if new ",new-window)" ")")) @@ -699,7 +703,9 @@ ))) (define*-public (position-message-window! x y gravity) - "Move the message window's GRAVITY point to (X,Y)." + "Move the message window's GRAVITY point to (X,Y). +GRAVITY can be one of 'nw, 'n, 'ne, 'w, 'center, 'e, 'sw, 's, 'se +(or spelled-out versions of these)." (apply (lambda (xa ya) (set-message-window-position! x y xa ya)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:29:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20152 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:29:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20149 for ; Fri, 4 Dec 1998 01:29:10 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17377 for ; Thu, 3 Dec 1998 22:27:36 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA02005; Thu, 3 Dec 1998 22:31:31 -0800 Date: Thu, 3 Dec 1998 22:31:31 -0800 Message-Id: <199812040631.WAA02005@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: minor doc updates in face.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u face.scm Index: face.scm =================================================================== RCS file: /anoncvs/scwm/scheme/face.scm,v retrieving revision 1.7 diff -u -r1.7 face.scm --- face.scm 1998/11/14 23:08:48 1.7 +++ face.scm 1998/12/04 06:28:36 @@ -48,7 +48,7 @@ (define*-public (border-style #&key (active '()) (inactive '()) #&allow-other-keys . rest) - "Set the current border style." + "Set the border style in the current decor." (act-on-face-specs (lambda* (active #&optional ignore inactive) (if (bound? inactive) (set-border-face! active inactive) @@ -61,7 +61,7 @@ (active-up '()) (active-down '()) (inactive '()) #&allow-other-keys . rest) - "Set the current button style for button number BUTTON." + "Set the button style for button number BUTTON in the current decor." (if (bound? mwm) (set-button-mwm-flag! mwm)) (act-on-face-specs (lambda args Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:29:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20163 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:29:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20159 for ; Fri, 4 Dec 1998 01:29:58 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17389 for ; Thu, 3 Dec 1998 22:28:24 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA02010; Thu, 3 Dec 1998 22:32:19 -0800 Date: Thu, 3 Dec 1998 22:32:19 -0800 Message-Id: <199812040632.WAA02010@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for doc.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u doc.scm Index: doc.scm =================================================================== RCS file: /anoncvs/scwm/scheme/doc.scm,v retrieving revision 1.7 diff -u -r1.7 doc.scm --- doc.scm 1998/12/04 02:08:33 1.7 +++ doc.scm 1998/12/04 06:29:10 @@ -24,7 +24,8 @@ (define*-public (documentation func #&optional (port (current-output-port))) "Print the documentation for the string or symbol. -Return #t if found anything, #f if no documentation." +Works by searching through the files listed in `doc-files'. +Returns #t if any documentation was found, #f otherwise." (let* ((head (string-append "(" (if (string? func) func (symbol->string func)))) (len (string-length head)) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:30:45 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20188 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:30:45 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20183 for ; Fri, 4 Dec 1998 01:30:43 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17400 for ; Thu, 3 Dec 1998 22:29:09 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA02015; Thu, 3 Dec 1998 22:33:05 -0800 Date: Thu, 3 Dec 1998 22:33:05 -0800 Message-Id: <199812040633.WAA02015@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc updates for cached-program-exists.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u cached-program-exists.scm Index: cached-program-exists.scm =================================================================== RCS file: /anoncvs/scwm/scheme/cached-program-exists.scm,v retrieving revision 1.2 diff -u -r1.2 cached-program-exists.scm --- cached-program-exists.scm 1998/10/05 00:30:11 1.2 +++ cached-program-exists.scm 1998/12/04 06:29:58 @@ -31,7 +31,9 @@ (define-public (cached-program-exists? program-name) "Return #t if PROGRAM-NAME is in the cache of programs that exist. Returns #f otherwise. If `debug-program-cache' is true, a message will -print to stdout on hits and misses." +print to stdout on hits and misses. You must call +`initialize-programs-that-exist' before calling this function; otherwise, +it reverts to the (inefficient) implementation of `program-exists?'." (if debug-program-cache (if programs-that-exist (if (member program-name programs-that-exist) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:31:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20203 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:31:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20200 for ; Fri, 4 Dec 1998 01:31:23 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17406 for ; Thu, 3 Dec 1998 22:29:48 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA02020; Thu, 3 Dec 1998 22:33:44 -0800 Date: Thu, 3 Dec 1998 22:33:44 -0800 Message-Id: <199812040633.WAA02020@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: minor doc updates for base.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u base.scm Index: base.scm =================================================================== RCS file: /anoncvs/scwm/scheme/base.scm,v retrieving revision 1.72 diff -u -r1.72 base.scm --- base.scm 1998/12/04 02:08:33 1.72 +++ base.scm 1998/12/04 06:30:49 @@ -111,7 +111,8 @@ (define-public (program-exists? program-name) "Return #t if PROGRAM-NAME is found as an executable in the current $PATH. -Returns #f otherwise." +Returns #f otherwise. See `cached-program-exists?' for a more efficient +version of this." (= 0 (system (string-append "which " program-name " >/dev/null" )))) (define-public (set-menu-foreground! fg) @@ -406,7 +407,7 @@ (split-list ml max-lines)))) (define-public (exe command) - "Return a procedure that runs the system command COMMAND." + "Return a procedure that, when invoked, executes COMMAND in the background." (lambda () (execute command))) (define-public xterm-command Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 01:32:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA20217 for scwm-discuss-outgoing; Fri, 4 Dec 1998 01:32:20 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id BAA20213 for ; Fri, 4 Dec 1998 01:32:18 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id WAA17438 for ; Thu, 3 Dec 1998 22:30:44 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id WAA02025; Thu, 3 Dec 1998 22:34:39 -0800 Date: Thu, 3 Dec 1998 22:34:39 -0800 Message-Id: <199812040634.WAA02025@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for animation.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u animation.scm Index: animation.scm =================================================================== RCS file: /anoncvs/scwm/scheme/animation.scm,v retrieving revision 1.4 diff -u -r1.4 animation.scm --- animation.scm 1998/11/20 23:08:04 1.4 +++ animation.scm 1998/12/04 06:31:23 @@ -41,11 +41,11 @@ ;; MS:FIXME:: Figure out why this is needed (as well as move-to in base) (define*-public (animated-move-to x y #&optional (win (get-window)) (move-pointer-too? #t)) - "Move WIN to viewport position x, y animatedly. -If X or Y is 'x or 'y, respectively (or #f), then do not change that -coordinate during the move. At least one of X and Y must be a -number. This moves the pointer with the window unless -MOVE-POINTER-TOO? is #f" + "Move WIN to viewport coordinates X, Y with animation. +If X or Y is #f, then do not change that coordinate during +the move. At least one of X and Y must be a number. This +moves the pointer with the window unless MOVE-POINTER-TOO? +is #f." (let* ((sticky (sticky? win)) (pos (viewport-position)) (x (if x Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Fri Dec 4 03:20:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA21033 for scwm-discuss-outgoing; Fri, 4 Dec 1998 03:20:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA21027 for ; Fri, 4 Dec 1998 03:19:59 -0500 Received: from mail.citycom.com by MIT.EDU with SMTP id AA24267; Fri, 4 Dec 98 03:18:31 EST Received: from yasmeen (38.28.60.81) by citycom.com with SMTP (Eudora Internet Mail Server 2.2); Fri, 4 Dec 1998 00:17:35 -0800 Message-Id: <00ec01be1f5e$a6c77930$513c1c26@yasmeen.citycom.com> From: "Jason Nordwick" To: Subject: CVS log messages Date: Fri, 4 Dec 1998 00:17:13 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Can we put something in the subject line on CVS logs? It would really help with filtering them into a different mailbox. Thanks. From owner-scwm-discuss@mit.edu Fri Dec 4 04:23:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA22217 for scwm-discuss-outgoing; Fri, 4 Dec 1998 04:23:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA22214 for ; Fri, 4 Dec 1998 04:23:10 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA00504; Fri, 4 Dec 98 04:21:34 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Fri, 4 Dec 1998 10:20:27 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id KAA06675; Fri, 4 Dec 1998 10:20:27 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id KAA17323; Fri, 4 Dec 1998 10:20:26 +0100 Date: Fri, 4 Dec 1998 10:20:26 +0100 Message-Id: <199812040920.KAA17323@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: nordwick@xcf.berkeley.edu Cc: scwm-discuss@mit.edu Subject: Re: CVS log messages In-Reply-To: <00ec01be1f5e$a6c77930$513c1c26@yasmeen.citycom.com> References: <00ec01be1f5e$a6c77930$513c1c26@yasmeen.citycom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Jason" == Jason Nordwick writes: Jason> Can we put something in the subject line on CVS logs? It Jason> would really help with filtering them into a different Jason> mailbox. Jason> Thanks. For a local CVS tree I've the following entry in CVSROOT/loginfo, which does this: ALL /prog/util/Global/bin/cvsmail conny '%s' In this line conny is the mailgroup alias and /prog/util/Global/bin/cvsmail is a script with the following contents: #!/bin/sh /usr/bin/mailx -s "CVS-LOG: $2" $1 From owner-scwm-discuss@mit.edu Fri Dec 4 05:33:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id FAA22574 for scwm-discuss-outgoing; Fri, 4 Dec 1998 05:33:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id FAA22571 for ; Fri, 4 Dec 1998 05:33:04 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA06218; Fri, 4 Dec 98 05:31:34 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id LAA24782 for scwm-discuss@mit.edu; Fri, 4 Dec 1998 11:17:35 +0100 (MET) Received: (qmail 692 invoked by uid 115); 3 Dec 1998 22:40:36 -0000 To: scwm-discuss@mit.edu Subject: Re: docking windows References: <199812022026.PAA28894@vicarious-existence.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 03 Dec 1998 23:40:33 +0100 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 15:26:08 EST" Message-Id: Lines: 17 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 02 Dec 1998 15:26:08 EST >>>>> Maciej Stachowiak said: Maciej> I believe it can already be done in scwm at the Scheme level Maciej> using only the hooks into the move and resize loops that Maciej> already exist, without any need for GER. You're right - so I have no excuse for not implementing it. Well, not /this/ weekend, since I will do that get-a-life thing then. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 4 05:35:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id FAA22610 for scwm-discuss-outgoing; Fri, 4 Dec 1998 05:35:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id FAA22604 for ; Fri, 4 Dec 1998 05:35:21 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA06444; Fri, 4 Dec 98 05:33:50 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id LAA24783 for scwm-discuss@mit.edu; Fri, 4 Dec 1998 11:17:38 +0100 (MET) Received: (qmail 706 invoked by uid 115); 3 Dec 1998 22:52:08 -0000 To: scwm-discuss@mit.edu Subject: Re: SESSION_MANAGER, what is it? References: <199812030023.TAA32264@vicarious-existence.mit.edu> X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 03 Dec 1998 23:52:04 +0100 In-Reply-To: Maciej Stachowiak's message of "Wed, 02 Dec 1998 19:23:45 EST" Message-Id: Lines: 28 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 02 Dec 1998 19:23:45 EST >>>>> Maciej Stachowiak said: Maciej> This warning can be safely ignored if you are not running Maciej> with session management. I think this warning should be Maciej> disabled, since it is inappropirate IMO to warn on the Maciej> acceptable normal situation of running without a session Maciej> manager. I agree. Unfortunately SMlib does not return a meaningful error code, but only NULL and this error message. I will disable the output of it - we will miss error conditions other than the usual "S_M not defined", though. Ah, *burning*lightbulb*, I will put it into a scheme variable. So users may query `session-management-active?'[1], and then output `session-management-failure-cause' if they feel like it. Robbe [1] I'll probably make this a #t/#f variable, not a predicate. Should it have a question-mark, then? -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 4 10:18:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA23915 for scwm-discuss-outgoing; Fri, 4 Dec 1998 10:18:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA23908; Fri, 4 Dec 1998 10:18:20 -0500 Message-Id: <199812041518.KAA23908@vicarious-existence.mit.edu> To: "Jason Nordwick" cc: scwm-discuss@mit.edu Subject: Re: CVS log messages In-reply-to: Your message of "Fri, 04 Dec 1998 00:17:13 PST." <00ec01be1f5e$a6c77930$513c1c26@yasmeen.citycom.com> Date: Fri, 04 Dec 1998 10:18:20 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk nordwick@xcf.berkeley.edu writes: > > Can we put something in the subject line > on CVS logs? It would really help with > filtering them into a different mailbox. > Pardon? They all have "SCWM CVS checkin `date`" as the subject line. Did you have something else in mind? From owner-scwm-discuss@mit.edu Fri Dec 4 10:43:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA24155 for scwm-discuss-outgoing; Fri, 4 Dec 1998 10:43:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id KAA24152 for ; Fri, 4 Dec 1998 10:43:04 -0500 Received: from VICARIOUS-EXISTENCE.MIT.EDU by MIT.EDU with SMTP id AA25322; Fri, 4 Dec 98 10:41:12 EST Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA24143; Fri, 4 Dec 1998 10:42:56 -0500 Message-Id: <199812041542.KAA24143@vicarious-existence.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: docking windows In-Reply-To: Your message of "03 Dec 1998 23:40:33 +0100." Date: Fri, 04 Dec 1998 10:42:56 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Wed, 02 Dec 1998 15:26:08 EST > >>>>> Maciej Stachowiak said: > > Maciej> I believe it can already be done in scwm at the Scheme level > Maciej> using only the hooks into the move and resize loops that > Maciej> already exist, without any need for GER. > > You're right - so I have no excuse for not implementing it. Well, not > /this/ weekend, since I will do that get-a-life thing then. > I actually realized that there _is_ one missing feature - the ability to adjust the rubber-band/window position in the middle of an interactive move. I think that should be easy to add, though - just add a bit to the window structure indicating that an interactive operation is in progress, another bit indicating a move/resize has taken place in the middle of interaction, have move-window/resize-window only update the fields of the window struct and that bit during an interactive move, and make the interactive loop code check the bit after calling the hook. I also have done some preliminary design work and even wrote a bit of semi-pseudo-code for the snap feature itself - would you be interested in seeing it? You're welcome to implement it the rest of the way if you want because I have a billion other things to code :-) The only tricky part I ran into was figuring out a data structure and algorithm for finding the nearest applicable snap guide efficiently, but I've asked some theory people to help me out with that. - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 11:07:26 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA24457 for scwm-discuss-outgoing; Fri, 4 Dec 1998 11:07:26 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA24454 for ; Fri, 4 Dec 1998 11:07:18 -0500 Received: from jekyll.piermont.com by MIT.EDU with SMTP id AA05349; Fri, 4 Dec 98 11:05:25 EST Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id LAA05990; Fri, 4 Dec 1998 11:05:25 -0500 (EST) Message-Id: <199812041605.LAA05990@jekyll.piermont.com> To: "Jason Nordwick" Cc: scwm-discuss@mit.edu Subject: Re: CVS log messages In-Reply-To: Your message of "Fri, 04 Dec 1998 00:17:13 PST." <00ec01be1f5e$a6c77930$513c1c26@yasmeen.citycom.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Fri, 04 Dec 1998 11:05:24 -0500 From: "Perry E. Metzger" Sender: owner-scwm-discuss@mit.edu Precedence: bulk "Jason Nordwick" writes: > Can we put something in the subject line > on CVS logs? It would really help with > filtering them into a different mailbox. Isn't the From: or To: address enough? I've never seen a filtering system that could sort on subject but not sender or to: .pm From owner-scwm-discuss@mit.edu Fri Dec 4 12:58:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA25723 for scwm-discuss-outgoing; Fri, 4 Dec 1998 12:58:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id MAA25720 for ; Fri, 4 Dec 1998 12:58:41 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 04 Dec 1998 12:56:22 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 04 Dec 1998 12:56:22 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id MAA18258; Fri, 4 Dec 1998 12:56:47 -0500 To: Maciej Stachowiak Subject: scwm-concepts.txt Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 04 Dec 1998 12:56:47 -0500 Message-ID: Lines: 22 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I just fixed doc.scm to work with non-procedures. This means that you can C-h C-s in Emacs buffer and get help on variables and hooks too. Now, the file scwm-concepts.txt contains useful information too, but it is not accessible from C-h C-s (you can do C-x C-s and type (documentation "Face Flags") at the "scwm> " prompt though). The reason is that things like "Face Flags" are not interned in in guile and thus not in emacs' `scwm-obarray'. I suggest that something like `Face_Flags' be interned in scwm/guile. Note that this means replacing space with underscore. Keeping space will break scwm.el; I can fix it, but why break the thing in the first place? Comments? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Computer are like air conditioners: they don't work with open windows! From owner-scwm-discuss@mit.edu Fri Dec 4 16:17:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA27324 for scwm-discuss-outgoing; Fri, 4 Dec 1998 16:17:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA27313 for ; Fri, 4 Dec 1998 16:17:22 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA28220; Fri, 4 Dec 98 16:15:26 EST Received: (qmail 19341 invoked by uid 501); 4 Dec 1998 21:15:37 -0000 Message-Id: <19981204131537.A19307@molehill.org> Date: Fri, 4 Dec 1998 13:15:37 -0800 From: Todd Larason To: Maciej Stachowiak , scwm-discuss list Subject: Re: SCWM CVS checkin Thu Dec 3 23:39:18 EST 1998 References: <199812040439.XAA18812@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812040439.XAA18812@vicarious-existence.mit.edu>; from Maciej Stachowiak on Thu, Dec 03, 1998 at 11:39:29PM -0500 X-Kibo: If you are allowed not to be inspired by the destiny of Kibo, it's nice to get it over with. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981203, Maciej Stachowiak wrote: > Update of /usr/local/repository/scwm/modules/applefile > In directory vicarious-existence.mit.edu:/usr/local/mstachow/working/scwm/modules/applefile > > Modified Files: > Makefile.am > Log Message: > * applefile/Makefile.am, background/Makefile.am, > c-animation/Makefile.am, overlay-plane/Makefile.am, > pie-menus/Makefile.am, scwmgtkhelper/Makefile.am, > xpm-menus/Makefile.am: Install dynamic link modules in pklibdir > instead of scwm_schemedir, and make the proper symlink in > scwm_schemedir. All files in /usr/share should be > platform-independent. I don't understand this change. Previously, modules were being installed in scwm_moduledir, which would be $(libdir)/scwm-modules unless overridden, which in turn would be in /usr/lib rather than /usr/share, unless overridden. Besides not understanding the motivation for change, it didn't work for me; no binary modules could be loaded. Do others not have this problem? -- ICQ UIN: 15090443 From owner-scwm-discuss@mit.edu Fri Dec 4 19:09:10 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA28936 for scwm-discuss-outgoing; Fri, 4 Dec 1998 19:09:10 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA28933 for ; Fri, 4 Dec 1998 19:09:08 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA27623; Fri, 4 Dec 98 19:07:32 EST Received: (qmail 20460 invoked by uid 501); 5 Dec 1998 00:07:23 -0000 Message-Id: <19981204160723.A20351@molehill.org> Date: Fri, 4 Dec 1998 16:07:23 -0800 From: Todd Larason To: Maciej Stachowiak , scwm-discuss list Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812040208.VAA14938@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812040208.VAA14938@vicarious-existence.mit.edu>; from Maciej Stachowiak on Thu, Dec 03, 1998 at 09:08:44PM -0500 X-Kibo: I think they're old some of the time. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981203, Maciej Stachowiak wrote: > Modified Files: > ChangeLog base.scm doc.scm > Log Message: > * doc.scm, base.scm: Make no attempt to define user-settable > variables in the root module. That was only ever needed for > variables that the C code (brokenly) looked up with gh_lookup, > which we are not doing for any of the affected vars. I had to undo this, too. Menus wouldn't pop up, giving an 'uninterned-symbol? error', when drawmenu.c used DYNAMIC_COLOR_P() to look up a color by symbol. DYNAMIC_COLOR_P uses scm_symbol_binding(). Is this the wrong way to do this? -- ICQ UIN: 115822002 From owner-scwm-discuss@mit.edu Fri Dec 4 19:23:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA29040 for scwm-discuss-outgoing; Fri, 4 Dec 1998 19:23:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA29036 for ; Fri, 4 Dec 1998 19:23:12 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA18791; Fri, 4 Dec 98 19:21:07 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id QAA07999; Fri, 4 Dec 1998 16:21:15 -0800 (PST) To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss list Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812040208.VAA14938@vicarious-existence.mit.edu> <19981204160723.A20351@molehill.org> From: Greg Badros Date: 04 Dec 1998 16:21:14 -0800 In-Reply-To: Todd Larason's message of "Fri, 4 Dec 1998 16:07:23 -0800" Message-Id: Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981203, Maciej Stachowiak wrote: > > Modified Files: > > ChangeLog base.scm doc.scm > > Log Message: > > * doc.scm, base.scm: Make no attempt to define user-settable > > variables in the root module. That was only ever needed for > > variables that the C code (brokenly) looked up with gh_lookup, > > which we are not doing for any of the affected vars. > > I had to undo this, too. Menus wouldn't pop up, giving an 'uninterned-symbol? > error', when drawmenu.c used DYNAMIC_COLOR_P() to look up a color by symbol. > DYNAMIC_COLOR_P uses scm_symbol_binding(). > > Is this the wrong way to do this? Yea, I was getting this too... we need to fix this ASAP.... Greg From owner-scwm-discuss@mit.edu Fri Dec 4 19:54:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA29325 for scwm-discuss-outgoing; Fri, 4 Dec 1998 19:54:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA29315; Fri, 4 Dec 1998 19:54:42 -0500 Message-Id: <199812050054.TAA29315@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 23:39:18 EST 1998 In-reply-to: Your message of "Fri, 04 Dec 1998 13:15:37 PST." <19981204131537.A19307@molehill.org> Date: Fri, 04 Dec 1998 19:54:42 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981203, Maciej Stachowiak wrote: > > Update of /usr/local/repository/scwm/modules/applefile > > In directory vicarious-existence.mit.edu:/usr/local/mstachow/working/scwm/modules/app > lefile > > > > Modified Files: > > Makefile.am > > Log Message: > > * applefile/Makefile.am, background/Makefile.am, > > c-animation/Makefile.am, overlay-plane/Makefile.am, > > pie-menus/Makefile.am, scwmgtkhelper/Makefile.am, > > xpm-menus/Makefile.am: Install dynamic link modules in pklibdir > > instead of scwm_schemedir, and make the proper symlink in > > scwm_schemedir. All files in /usr/share should be > > platform-independent. > > I don't understand this change. Previously, modules were being installed in > scwm_moduledir, which would be $(libdir)/scwm-modules unless overridden, which > in turn would be in /usr/lib rather than /usr/share, unless overridden. > Whoops, I didn't notice that! In that case the change can be safely reverted. All the same, I'd rather take the symlink approach if it can be made to work for everyone because I think it's nicer to have all the modules under one hierarchy somewhere. > Besides not understanding the motivation for change, it didn't work for me; no > binary modules could be loaded. Do others not have this problem? It Works For Me(tm). The relevant code in boot-9.scm does try loading by the .la name, so they should load successfully. - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 20:10:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA29552 for scwm-discuss-outgoing; Fri, 4 Dec 1998 20:10:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA29549 for ; Fri, 4 Dec 1998 20:10:21 -0500 Received: from VICARIOUS-EXISTENCE.MIT.EDU by MIT.EDU with SMTP id AA26284; Fri, 4 Dec 98 20:08:25 EST Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA29539; Fri, 4 Dec 1998 20:10:17 -0500 Message-Id: <199812050110.UAA29539@vicarious-existence.mit.edu> To: Todd Larason Cc: scwm-discuss list Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "Fri, 04 Dec 1998 16:07:23 PST." <19981204160723.A20351@molehill.org> Date: Fri, 04 Dec 1998 20:10:17 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981203, Maciej Stachowiak wrote: > > Modified Files: > > ChangeLog base.scm doc.scm > > Log Message: > > * doc.scm, base.scm: Make no attempt to define user-settable > > variables in the root module. That was only ever needed for > > variables that the C code (brokenly) looked up with gh_lookup, > > which we are not doing for any of the affected vars. > > I had to undo this, too. Menus wouldn't pop up, giving an 'uninterned-symbol? > error', when drawmenu.c used DYNAMIC_COLOR_P() to look up a color by symbol. > DYNAMIC_COLOR_P uses scm_symbol_binding(). > > Is this the wrong way to do this? Hmm, I only searched for gh_lookup and the code ran after I did it, so I expected this to work. Barring a proper fix, I will (if someone hasn't done it already) move back only the variables that are likely to be checked by that code. I have to mention at this point that I never liked the symbol-lookup stuff in the first place, but I let Greg leave it in because I couldn't think of a plausible way to get the same functionality at the time. This problem demonstrates one reason why it is wrong to look up variables by symbol: when you have a module system, the same symbol exists in multiple modules, and you have to make sure to get the right one. More generally it utterly defeats any typechecking at menu creation time, hence complicating both the menu creation and rendering code (as I'm sure people working on that have noticed). Upon further consideration I think the right way to do dynamic stuff like this in the long run is to make the various fields in menu objects (and maybe also menuitems) explicitly mutable, and provide a higher-level "style" layer, allowing multiple menu styles in much the same way window-style does it, except that of course menu styles will probably have to be named by arbitrary strings or something. Stuff like this will be needed anyway once we have pinnable menus that we want to be dynamic. However, I (or someone else) should apply the quick fix for now. Sorry about not testing my commits more thoroughly, I was a bit out of it last night. - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 20:29:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA29812 for scwm-discuss-outgoing; Fri, 4 Dec 1998 20:29:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA29807; Fri, 4 Dec 1998 20:29:33 -0500 Message-Id: <199812050129.UAA29807@vicarious-existence.mit.edu> To: Maciej Stachowiak cc: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-reply-to: Your message of "Fri, 04 Dec 1998 20:10:17 EST." <199812050110.UAA29539@vicarious-existence.mit.edu> Date: Fri, 04 Dec 1998 20:29:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mstachow@mit.edu writes: > > jtl@molehill.org writes: > > On 981203, Maciej Stachowiak wrote: > > > Modified Files: > > > ChangeLog base.scm doc.scm > > > Log Message: > > > * doc.scm, base.scm: Make no attempt to define user-settable > > > variables in the root module. That was only ever needed for > > > variables that the C code (brokenly) looked up with gh_lookup, > > > which we are not doing for any of the affected vars. > > > > I had to undo this, too. Menus wouldn't pop up, giving an 'uninterned-symbol? > > error', when drawmenu.c used DYNAMIC_COLOR_P() to look up a color by symbol. > > DYNAMIC_COLOR_P uses scm_symbol_binding(). > > > > Is this the wrong way to do this? > > Hmm, I only searched for gh_lookup and the code ran after I did it, so > I expected this to work. Barring a proper fix, I will (if someone > hasn't done it already) move back only the variables that are likely > to be checked by that code. > Hmmm, following up on myself, the better fix is to create the appropriate variables in one of the menu*.c files using SCM_VAR or SCM_VAR_INIT (OK, screw it, I'll break Guile 1.2 support in 0.9, I don't want to have to reimplement SCM_VAR_INIT). I'll do that now for all these variables. My previous comments about the long-term fix still apply. - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 20:52:51 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA29997 for scwm-discuss-outgoing; Fri, 4 Dec 1998 20:52:51 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA29994 for ; Fri, 4 Dec 1998 20:52:50 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA02070; Fri, 4 Dec 98 20:50:52 EST Received: (qmail 21104 invoked by uid 501); 5 Dec 1998 01:51:08 -0000 Message-Id: <19981204175108.A21061@molehill.org> Date: Fri, 4 Dec 1998 17:51:08 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812050110.UAA29539@vicarious-existence.mit.edu> <199812050129.UAA29807@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812050129.UAA29807@vicarious-existence.mit.edu>; from Maciej Stachowiak on Fri, Dec 04, 1998 at 08:29:33PM -0500 X-Kibo: Death makes sense. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981204, Maciej Stachowiak wrote: > Hmmm, following up on myself, the better fix is to create the > appropriate variables in one of the menu*.c files using SCM_VAR or > SCM_VAR_INIT (OK, screw it, I'll break Guile 1.2 support in 0.9, I > don't want to have to reimplement SCM_VAR_INIT). I'll do that now for > all these variables. My previous comments about the long-term fix > still apply. Your long-term fix ideas sound good, but this... I'd been careful to keep the C and scheme levels distinct to allow supporting multiple menu styles if anyone wanted to go to the effort. At the C level, there was nothing magic about the symbols being used, and I'd *really* like to keep it that way. -- ICQ UIN: 54629131 From owner-scwm-discuss@mit.edu Fri Dec 4 21:11:38 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA30157 for scwm-discuss-outgoing; Fri, 4 Dec 1998 21:11:38 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA30154 for ; Fri, 4 Dec 1998 21:11:37 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA15260; Fri, 4 Dec 98 21:10:02 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id VAA08174; Fri, 4 Dec 1998 21:09:52 -0500 Message-Id: <199812050209.VAA08174@M66-080-6.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "Fri, 04 Dec 1998 17:51:08 PST." <19981204175108.A21061@molehill.org> Date: Fri, 04 Dec 1998 21:09:52 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981204, Maciej Stachowiak wrote: > > > Hmmm, following up on myself, the better fix is to create the > > appropriate variables in one of the menu*.c files using SCM_VAR or > > SCM_VAR_INIT (OK, screw it, I'll break Guile 1.2 support in 0.9, I > > don't want to have to reimplement SCM_VAR_INIT). I'll do that now for > > all these variables. My previous comments about the long-term fix > > still apply. > > Your long-term fix ideas sound good, but this... > > I'd been careful to keep the C and scheme levels distinct to allow supporting > multiple menu styles if anyone wanted to go to the effort. At the C level, > there was nothing magic about the symbols being used, and I'd *really* like t > o > keep it that way. The symbols have to be defined in one of four ways to let the C code access them as it now does (i.e. so they end up in the root module): * Define them in a .c file * Define them in minimal.scm * Use the "before the module declaration" hack from before. * Define them in the .scwmrc Other variables you define in your scwmrc and pass as symbols to the menu code will work fine, sine that is method 4. The only reason these have to be handled specially is because users (and certain functions in base.scm) expect them to already be defined to sensible defaults. I think the "before the module declaration" method is too ugly to behold, and minimal.scm is too crowded as it is (I need to prune it at some point to actually live up to its name). Hence, option one, declaring them from C, seemed the least messy. And it won't mess with the user's ability to use different variables. I'll give you a chance to object again before committing this change though... - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 21:18:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA30244 for scwm-discuss-outgoing; Fri, 4 Dec 1998 21:18:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA30241 for ; Fri, 4 Dec 1998 21:18:13 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA16155; Fri, 4 Dec 98 21:16:36 EST Received: (qmail 21390 invoked by uid 501); 5 Dec 1998 02:16:32 -0000 Message-Id: <19981204181632.A21347@molehill.org> Date: Fri, 4 Dec 1998 18:16:32 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <19981204175108.A21061@molehill.org> <199812050209.VAA08174@M66-080-6.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812050209.VAA08174@M66-080-6.mit.edu>; from Maciej Stachowiak on Fri, Dec 04, 1998 at 09:09:52PM -0500 X-Kibo: Vril can teach us how to warm up to be inspired by everyone's abilities. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I won't object, but I will give more though to the long term solution and see how quickly I can get it done (yeah, right...I haven't even found half an hour contiguous to do the titles). On 981204, Maciej Stachowiak wrote: > * Define them in a .c file > > * Define them in minimal.scm > > * Use the "before the module declaration" hack from before. > > * Define them in the .scwmrc I do wonder whether a cleaner method could be found to do what this was attempting to do, to pass handle of a binding and/or scheme object from the scheme level to the C level, such that changes made to the binding in scheme are visible in C. The thought's pretty muddy, which is probably a sign it's not a good idea. -- ICQ UIN: 114888716 From owner-scwm-discuss@mit.edu Fri Dec 4 21:32:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA30399 for scwm-discuss-outgoing; Fri, 4 Dec 1998 21:32:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA30396 for ; Fri, 4 Dec 1998 21:32:34 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA17711; Fri, 4 Dec 98 21:30:58 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id VAA08232; Fri, 4 Dec 1998 21:30:49 -0500 Message-Id: <199812050230.VAA08232@M66-080-6.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "Fri, 04 Dec 1998 18:16:32 PST." <19981204181632.A21347@molehill.org> Date: Fri, 04 Dec 1998 21:30:49 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I won't object, but I will give more though to the long term solution and see > how quickly I can get it done (yeah, right...I haven't even found half an hou > r > contiguous to do the titles). > We should try to come up with a more specific design first maybe, and at least give Greg a chance to look over it since he designed the menu stuff originally. I have some ideas I could check in RSN depending on how soon you think you will plausibly have a chance to think about things. > On 981204, Maciej Stachowiak wrote: > > * Define them in a .c file > > > > * Define them in minimal.scm > > > > * Use the "before the module declaration" hack from before. > > > > * Define them in the .scwmrc > > I do wonder whether a cleaner method could be found to do what this was > attempting to do, to pass handle of a binding and/or scheme object from the > scheme level to the C level, such that changes made to the binding in scheme > are visible in C. > > The thought's pretty muddy, which is probably a sign it's not a good idea. Guile does actually have first class variables, so this is in theory possible. (i.e. you can get the variable object for a symbol binding in a module as a Scheme object and pass it around). That will even work with the module system properly. My problems with this are: * Depends heavily on weird Guile internals. * If you accidentally pass a local variable, strange behavior or even total havoc may ensue later. * Guile may want to remove support for first-class variables when the next-generation module system gets written (it will almost certainly be mostly in C and not Scheme so first-class variables won't be critical), and I don't want scwm to be a roadblock on their path to doing that, if they do. * I think a menu-style interface like window-styles that is smart enough to update menus with a given style when that style is changes ia a cleaner and more end-user friendly solution to much the same problem. * As you said the whole thought is pretty muddy. - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 21:57:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA30687 for scwm-discuss-outgoing; Fri, 4 Dec 1998 21:57:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA30684 for ; Fri, 4 Dec 1998 21:57:11 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA20854; Fri, 4 Dec 98 21:55:35 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id VAA08284; Fri, 4 Dec 1998 21:55:26 -0500 Message-Id: <199812050255.VAA08284@M66-080-6.mit.edu> To: scwm-discuss@mit.edu Subject: SCM_REDEFER_INTS before init_* calls in scwm.c Date: Fri, 04 Dec 1998 21:55:26 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is there a reason garbage-collection is inhibited during the various init_ functions in scwm.c? I'm guessing this ChangeLog comment is the relevant one (thank goodness for `cvs annotate' - I need to hack support for that into cvsweb), does anyone remember what safetey was being referred to? I _think_ the init_ functions should be safe to call with GC enabled, or if not we need to figure out why. * scwm.c: reorder some initialization stuff to be a bit safer, drop last arg from CreateMessageWindow since MWMMenus flag was unused by it - Maciej From owner-scwm-discuss@mit.edu Fri Dec 4 22:24:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA00998 for scwm-discuss-outgoing; Fri, 4 Dec 1998 22:24:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA00995 for ; Fri, 4 Dec 1998 22:24:10 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA24029; Fri, 4 Dec 98 22:22:34 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id WAA08316; Fri, 4 Dec 1998 22:22:25 -0500 Message-Id: <199812050322.WAA08316@M66-080-6.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 23:39:18 EST 1998 In-Reply-To: Your message of "Fri, 04 Dec 1998 13:15:37 PST." <19981204131537.A19307@molehill.org> Date: Fri, 04 Dec 1998 22:22:25 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981203, Maciej Stachowiak wrote: > > Update of /usr/local/repository/scwm/modules/applefile > > In directory vicarious-existence.mit.edu:/usr/local/mstachow/working/scwm/m > odules/applefile > > > > Modified Files: > > Makefile.am > > Log Message: > > * applefile/Makefile.am, background/Makefile.am, > > c-animation/Makefile.am, overlay-plane/Makefile.am, > > pie-menus/Makefile.am, scwmgtkhelper/Makefile.am, > > xpm-menus/Makefile.am: Install dynamic link modules in pklibdir > > instead of scwm_schemedir, and make the proper symlink in > > scwm_schemedir. All files in /usr/share should be > > platform-independent. > > I don't understand this change. Previously, modules were being installed in > scwm_moduledir, which would be $(libdir)/scwm-modules unless overridden, whic > h > in turn would be in /usr/lib rather than /usr/share, unless overridden. > > Besides not understanding the motivation for change, it didn't work for me; n > o > binary modules could be loaded. Do others not have this problem? Whoops, I just noticed that the Makefile.am rules to make the .la links are broken! I wonder how it worked for me before? I'd rather keep things this way but obviously I should change the ChangeLog comment to explain what was going on and what is going on more accurately. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 00:33:07 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA03493 for scwm-discuss-outgoing; Sat, 5 Dec 1998 00:33:07 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA03490 for ; Sat, 5 Dec 1998 00:33:06 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA08200; Sat, 5 Dec 98 00:31:27 EST Received: (qmail 22789 invoked by uid 501); 5 Dec 1998 05:31:29 -0000 Message-Id: <19981204213129.A22659@molehill.org> Date: Fri, 4 Dec 1998 21:31:29 -0800 From: Todd Larason To: "Carl R. Witty" , scwm-discuss@mit.edu Subject: Re: typo fixes in resize.c References: <199812030750.XAA28450@nebula.newtonlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812030750.XAA28450@nebula.newtonlabs.com>; from Carl R. Witty on Wed, Dec 02, 1998 at 11:50:07PM -0800 X-Kibo: Every bit of the great the truth about Einstein's destiny is truthful. Sender: owner-scwm-discuss@mit.edu Precedence: bulk one hunk of this, and the move.c patch were rejected and don't seem to apply any more. I've merged and checked in everything else, I think. Carl, if you could verify I didn't miss anything, that'd be great. My scwm mailbox is rather, um, large right now. Thanks for all the fixes! On 981202, Carl R. Witty wrote: > One cut-and-paste error; one missing paren. > > === cd /src/debian/scwm/scwm-cvs/scwm/ > === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u resize.c > > Index: resize.c > =================================================================== > RCS file: /anoncvs/scwm/scwm/resize.c,v > retrieving revision 1.53 > diff -u -r1.53 resize.c > --- resize.c 1998/11/30 16:46:28 1.53 > +++ resize.c 1998/12/03 07:46:59 > @@ -738,10 +738,10 @@ > This allows the user to drag a rubber band frame to set the size of > the window. WIN defaults to the window context in the usual way if not > specified. If OPAQUE? is #t, the resize will be done > -"opaquely", moving the actual X window, if #f a rubberband will be > +"opaquely", resizing the actual X window, if #f a rubberband will be > used instead to save on server computation (note that the rubberband > requires a server "grab" which means that nothing else changes on > -screen while the non-opaque resize takes place. */ > +screen while the non-opaque resize takes place). */ > #define FUNC_NAME s_interactive_resize > { > ScwmWindow *psw; > > > Carl Witty > cwitty@newtonlabs.com -- ICQ UIN: 126065908 From owner-scwm-discuss@mit.edu Sat Dec 5 00:55:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA03737 for scwm-discuss-outgoing; Sat, 5 Dec 1998 00:55:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA03734 for ; Sat, 5 Dec 1998 00:55:48 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA10290; Sat, 5 Dec 98 00:54:11 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id AAA08538; Sat, 5 Dec 1998 00:53:56 -0500 Message-Id: <199812050553.AAA08538@M66-080-6.mit.edu> To: cwitty@newtonlabs.com To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: typo fixes in resize.c In-Reply-To: Your message of "Fri, 04 Dec 1998 21:31:29 PST." <19981204213129.A22659@molehill.org> Date: Sat, 05 Dec 1998 00:53:55 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > one hunk of this, and the move.c patch were rejected and don't seem to apply > any more. > Yeah, those procedures got split in the meantime. > I've merged and checked in everything else, I think. Carl, if you could > verify I didn't miss anything, that'd be great. My scwm mailbox is rather, > um, large right now. > > Thanks for all the fixes! Yes, thanks on my behalf as well. And thanks for mergeing these, Todd. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 01:14:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA03984 for scwm-discuss-outgoing; Sat, 5 Dec 1998 01:14:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA03981 for ; Sat, 5 Dec 1998 01:14:24 -0500 Received: from M66-080-6.MIT.EDU by MIT.EDU with SMTP id AA01266; Sat, 5 Dec 98 01:12:26 EST Received: by M66-080-6.mit.edu (SMI-8.6/4.7) id BAA08557; Sat, 5 Dec 1998 01:12:34 -0500 Message-Id: <199812050612.BAA08557@M66-080-6.mit.edu> To: scwm-discuss@mit.edu Subject: cvsweb is back Date: Sat, 05 Dec 1998 01:12:33 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I have brought back both the classic and the improved cvsweb interfaces from the dead. I have also added blame annotation support to cvsweb.new (by shamelessly stealing code from Bonsai). Try it, it's cool. The only drawback is that blame-annotated pages can come out really huge and thus be slow to download. I find the feature that hovering the mouse over the version diff link in blame-annotated source pops up the cvs log entry pretty cool, even though it requires JavaScript. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Sat Dec 5 11:24:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id LAA07440 for scwm-discuss-outgoing; Sat, 5 Dec 1998 11:24:25 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id LAA07437 for ; Sat, 5 Dec 1998 11:24:22 -0500 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA15767; Sat, 5 Dec 98 11:22:18 EST Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id LAA15609 for ; Sat, 5 Dec 1998 11:22:31 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id LAA31959 for ; Sat, 5 Dec 1998 11:22:30 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id LAA11627 for ; Sat, 5 Dec 1998 11:23:36 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sat, 5 Dec 1998 16:23:36 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Problems with latest source Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I ran into a few problems building and running with the latest source. I think, from reading the emails, I caught the repository in a pretty volatile state, but I'll go ahead and report everything I found. The changed.c is: char *szRepoLastChanged = "Sat Dec 5 00:38:46 EST 1998 -- $Revision: 1.998 $"; There was a typo in menu.c that causes some trouble. There was a call to `make-color' which should be `make_color'. Here's the patch for that: Index: menu.c =================================================================== RCS file: /anoncvs/scwm/scwm/menu.c,v retrieving revision 1.56 diff -u -r1.56 menu.c --- menu.c 1998/12/05 03:44:35 1.56 +++ menu.c 1998/12/05 16:13:23 @@ -56,7 +56,7 @@ SCM_VCELL_INIT(menu_stipple_color, "menu-stipple-color", make_color(gh_str02scm("gray60"))); SCM_VCELL_INIT(menu_font, "menu-font", make_font(gh_str02scm("fixed"))); SCM_VCELL_INIT(menu_side_image, "menu-side-image", SCM_BOOL_F); -SCM_VCELL_INIT(menu_side_bg_color, "menu-side-bg-color", make-color(gh_str02scm("gray80"))); +SCM_VCELL_INIT(menu_side_bg_color, "menu-side-bg-color", make_color(gh_str02scm("gray80"))); SCM_VCELL_INIT(menu_side_bg_color_set, "menu-side-bg-color-set", SCM_BOOL_F); SCM_VCELL_INIT(menu_bg_image, "menu-bg-image", SCM_BOOL_F); SCM_VCELL_INIT(menu_look, "menu-look", drawmenu_menu_look); Also, as you can see in the code above, the variable `drawmenu_menu_look' is accessed in menu.c, but isn't accessible there. The variable is defined as a static variable in drawmenu.c. To get things to compile, I made the following changes to drawmenu.c and drawmenu.h: Index: drawmenu.c =================================================================== RCS file: /anoncvs/scwm/scwm/drawmenu.c,v retrieving revision 1.41 diff -u -r1.41 drawmenu.c --- drawmenu.c 1998/11/18 00:04:14 1.41 +++ drawmenu.c 1998/12/05 16:16:47 @@ -25,7 +25,7 @@ #include "dmalloc.h" #endif -static SCM drawmenu_menu_look = SCM_UNDEFINED; +SCM drawmenu_menu_look = SCM_UNDEFINED; extern SCM sym_top, sym_center, sym_bottom; Index: drawmenu.h =================================================================== RCS file: /anoncvs/scwm/scwm/drawmenu.h,v retrieving revision 1.9 diff -u -r1.9 drawmenu.h --- drawmenu.h 1998/10/01 08:16:15 1.9 +++ drawmenu.h 1998/12/05 16:17:05 @@ -14,6 +14,8 @@ void ConstructDynamicMenu(DynamicMenu *pmd); +extern SCM drawmenu_menu_look; + #endif Now comes the real kicker. I got scwm to compile, but it core dumps immediately. I tracked it down to the fact that init_menu() in menu.c/menu.x is calling make_color() in color.c before the X display is opened. So, the global `dpy' is NULL in make_color(), and scwm dies. I looked in scwm_main(), and sure enough, the X display is opened after all initialization, but you can't create colors before the display is opened. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sat Dec 5 12:16:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA07738 for scwm-discuss-outgoing; Sat, 5 Dec 1998 12:16:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA07735 for ; Sat, 5 Dec 1998 12:16:31 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA21862; Sat, 5 Dec 98 12:14:24 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id JAA07374; Sat, 5 Dec 1998 09:14:30 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id JAA10529; Sat, 5 Dec 1998 09:14:26 -0800 To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <19981204175108.A21061@molehill.org> <199812050209.VAA08174@M66-080-6.mit.edu> <19981204181632.A21347@molehill.org> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 05 Dec 1998 09:14:25 -0800 In-Reply-To: Todd Larason's message of "Fri, 4 Dec 1998 18:16:32 -0800" Message-Id: Lines: 689 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I do wonder whether a cleaner method could be found to do what this was > attempting to do, to pass handle of a binding and/or scheme object from the > scheme level to the C level, such that changes made to the binding in scheme > are visible in C. How about cons cells? I created a patch last night which makes all the DYNAMIC_* menu parameters into cons cells. It seems to work, although I've given it only limited testing. The patch is not quite ready for prime time yet. I need to test it more, and I need to add documentation. Let me know if you want to put this in scwm; if so, I'll finish it up. (If not, I'll probably drop it.) Here's what I have so far. === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u base.scm Index: base.scm =================================================================== RCS file: /anoncvs/scwm/scheme/base.scm,v retrieving revision 1.73 diff -u -r1.73 base.scm --- base.scm 1998/12/05 04:20:50 1.73 +++ base.scm 1998/12/05 17:01:22 @@ -25,15 +25,45 @@ -(define menu-bg-color (make-color "gray80")) -(define menu-text-color (make-color "black")) -(define menu-stipple-color (make-color "grey60")) -(define menu-font (make-font "fixed")) -(define menu-side-image #f) -(define menu-side-bg-color menu-bg-color) +(define (make-dynamic-color color) + (cons 'dynamic-color color)) + +(define (make-dynamic-font font) + (cons 'dynamic-font font)) + +(define (make-dynamic-image image) + (cons 'dynamic-image image)) + +(define (make-dynamic-menu-look look) + (cons 'dynamic-menulook look)) + +(define (set-dynamic-color! dyn color) + (set-cdr! dyn color)) + +(define (set-dynamic-font! dyn font) + (set-cdr! dyn font)) + +(define (set-dynamic-image! dyn image) + (set-cdr! dyn image)) + +(define (set-dynamic-menu-look! dyn look) + (set-cdr! dyn look)) + +(define (copy-dynamic-color color) + (cons (car color) (cdr color))) + +(define (dynamic-color color) + (cdr color)) + +(define menu-bg-color (make-dynamic-color (make-color "gray80"))) +(define menu-text-color (make-dynamic-color (make-color "black"))) +(define menu-stipple-color (make-dynamic-color (make-color "grey60"))) +(define menu-font (make-dynamic-font (make-font "fixed"))) +(define menu-side-image (make-dynamic-image #f)) +(define menu-side-bg-color (copy-dynamic-color menu-bg-color)) (define menu-side-bg-color-set #f) -(define menu-bg-image #f) -(define menu-look scwm-menu-look) +(define menu-bg-image (make-dynamic-image #f)) +(define menu-look (make-dynamic-menu-look scwm-menu-look)) (define-public use-scwm-system-proc ;;;**VAR @@ -117,34 +147,36 @@ (define-public (set-menu-foreground! fg) "Set the default color for menu text to FG." - (set! menu-text-color (if (color? fg) fg (make-color fg)))) + (set-dynamic-color! menu-text-color (if (color? fg) fg (make-color fg)))) (define-public (set-menu-background! bg) "Set the default background for menus to BG." - (set! menu-bg-color (if (color? bg) bg (make-color bg))) - (if (not menu-side-bg-color-set) (set! menu-side-bg-color menu-bg-color))) + (set-dynamic-color! menu-bg-color (if (color? bg) bg (make-color bg))) + (if (not menu-side-bg-color-set) + (set-dynamic-color! menu-side-bg-color (dynamic-color menu-bg-color)))) (define-public (set-menu-stipple! stipple) "Set the default color for stippled (inactive) menu text to STIPPLE." - (set! menu-stipple-color (if (color? stipple) stipple (make-color stipple)))) + (set-dynamic-color! menu-stipple-color (if (color? stipple) stipple (make-color stipple)))) (define-public (set-menu-font! font) "Set the default font for menu text to FONT." - (set! menu-font (if (font? font) font (make-font font)))) + (set-dynamic-font! menu-font (if (font? font) font (make-font font)))) (define-public (set-menu-side-image! image) "Set the default menu side image to IMAGE." - (set! menu-side-image (if (image? image) image (make-image image)))) + (set-dynamic-image! menu-side-image (if (image? image) image (make-image image)))) (define-public (set-menu-side-background! bg) "Set the default background for the menu side image to BG. If BG is #f, use the default menu background" - (cond (bg (set! menu-side-bg-color - (if (color? bg) bg (make-color bg))) + (cond (bg (set-dynamic-color! menu-side-bg-color + (if (color? bg) bg (make-color bg))) (set! menu-side-bg-color-set #t)) - (else (set! menu-side-bg-color menu-bg-color) + (else (set-dynamic-color! menu-side-bg-color + (dynamic-color menu-bg-color)) (set! menu-side-bg-color-set #f)))) (define-public (set-menu-bg-image! image) "Set the default menu background image to IMAGE." - (set! menu-bg-image (if (image? image) image (make-image image)))) + (set-dynamic-image! menu-bg-image (if (image? image) image (make-image image)))) (define-public (set-menu-look! look) "Set the default menu look to LOOK." - (if (menulook? look) (set! menu-look look) (error "bad look"))) + (if (menulook? look) (set-dynamic-menu-look! menu-look look) (error "bad look"))) ;;(define*-public (set-window-foreground! fg #&optional (w (get-window))) ;; (set-window-colors! fg #f w)) @@ -325,15 +357,15 @@ hover-action unhover-action hotkey-prefs)) (define*-public (menu list-of-menuitems #&key - (image-side 'menu-side-image) + (image-side menu-side-image) (image-align 'top) - (color-bg-image-side 'menu-side-bg-color) - (image-bg 'menu-bg-image) - (color-text 'menu-text-color) - (color-bg 'menu-bg-color) - (color-stipple 'menu-stipple-color) - (font 'menu-font) - (look 'menu-look) + (color-bg-image-side menu-side-bg-color) + (image-bg menu-bg-image) + (color-text menu-text-color) + (color-bg menu-bg-color) + (color-stipple menu-stipple-color) + (font menu-font) + (look menu-look) (extra #f)) "Return a menu object with the given attributes. LIST-OF-MENUITEMS is a list of menuitem objects (each created with === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u color.c Index: color.c =================================================================== RCS file: /anoncvs/scwm/scwm/color.c,v retrieving revision 1.54 diff -u -r1.54 color.c --- color.c 1998/12/05 05:18:42 1.54 +++ color.c 1998/12/05 17:01:34 @@ -45,6 +45,7 @@ shared. */ +SCWM_GLOBAL_SYMBOL(sym_dynamic_color, "dynamic-color"); SCM_SYMBOL (sym_name,"name"); === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u color.h Index: color.h =================================================================== RCS file: /anoncvs/scwm/scwm/color.h,v retrieving revision 1.16 diff -u -r1.16 color.h --- color.h 1998/11/14 23:09:05 1.16 +++ color.h 1998/12/05 17:01:40 @@ -47,6 +47,7 @@ #define COLOR(X) ((scwm_color *)(gh_cdr(X))) #define XCOLOR(X) (COLOR(X)->pixel) #define COLORNAME(X) (COLOR(X)->name) +#define COLOR_OR_FALSE_P(X) (COLOR_P(X) || (X) == SCM_BOOL_F) /* Not as inefficient as it looks - comes down to a hash table lookup, after the first time. */ @@ -72,14 +73,14 @@ #define SAFE_XCOLOR_OR_WHITE(X) (COLOR_P((X))?XCOLOR((X)):XCOLOR(WHITE_COLOR)) #define SAFE_XCOLOR_OR_BLACK(X) (COLOR_P((X))?XCOLOR((X)):XCOLOR(BLACK_COLOR)) -#define COLOR_OR_SYMBOL_P(x) (COLOR_P((x)) || gh_symbol_p((x))) +extern SCM sym_dynamic_color; -#define DYNAMIC_COLOR_P(X) (gh_symbol_p((X))? \ - COLOR_P(scm_symbol_binding(SCM_BOOL_F,(X))) : \ - COLOR_P((X))) +#define DYNAMIC_COLOR_OR_FALSE_P(X) (gh_pair_p((X))? \ + gh_car(X) == sym_dynamic_color : \ + COLOR_OR_FALSE_P((X))) -#define DYNAMIC_SAFE_COLOR(X) (gh_symbol_p((X))? \ - SAFE_COLOR(scm_symbol_binding(SCM_BOOL_F,(X))) : \ +#define DYNAMIC_SAFE_COLOR(X) (gh_pair_p((X))? \ + SAFE_COLOR(gh_cdr(X)) : \ SAFE_COLOR((X))) === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u drawmenu.c Index: drawmenu.c =================================================================== RCS file: /anoncvs/scwm/scwm/drawmenu.c,v retrieving revision 1.41 diff -u -r1.41 drawmenu.c --- drawmenu.c 1998/11/18 00:04:14 1.41 +++ drawmenu.c 1998/12/05 17:01:51 @@ -25,7 +25,7 @@ #include "dmalloc.h" #endif -static SCM drawmenu_menu_look = SCM_UNDEFINED; +SCM drawmenu_menu_look = SCM_UNDEFINED; extern SCM sym_top, sym_center, sym_bottom; === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u font.c Index: font.c =================================================================== RCS file: /anoncvs/scwm/scwm/font.c,v retrieving revision 1.51 diff -u -r1.51 font.c --- font.c 1998/12/05 05:18:43 1.51 +++ font.c 1998/12/05 17:01:58 @@ -57,6 +57,8 @@ static SCM font_hash_table = SCM_UNDEFINED; +SCWM_GLOBAL_SYMBOL(sym_dynamic_font, "dynamic-font"); + SCM_SYMBOL (sym_name,"name"); SCM_SYMBOL (sym_height,"height"); === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u font.h Index: font.h =================================================================== RCS file: /anoncvs/scwm/scwm/font.h,v retrieving revision 1.19 diff -u -r1.19 font.h --- font.h 1998/09/25 06:20:38 1.19 +++ font.h 1998/12/05 17:02:04 @@ -74,13 +74,16 @@ #define FONT_P(X) (SCM_NIMP((X)) && gh_car((X)) == (SCM)scm_tc16_scwm_font) #define FONT(X) ((scwm_font *)gh_cdr((X))) #define SAFE_FONT(X) (FONT_P((X))?FONT((X)):NULL) -#define DYNAMIC_FONT_P(X) (gh_symbol_p((X))? \ - FONT_P(scm_symbol_binding(SCM_BOOL_F,(X))) : \ - FONT_P((X))) -#define FONT_OR_SYMBOL_P(x) (FONT_P((x)) || gh_symbol_p((x))) +#define FONT_OR_FALSE_P(X) (FONT_P(X) || (X) == SCM_BOOL_F) -#define DYNAMIC_SAFE_FONT(X) (gh_symbol_p((X))? \ - SAFE_FONT(scm_symbol_binding(SCM_BOOL_F,(X))) : \ +extern SCM sym_dynamic_font; + +#define DYNAMIC_FONT_OR_FALSE_P(X) (gh_pair_p((X))? \ + gh_car(X) == sym_dynamic_font : \ + FONT_OR_FALSE_P((X))) + +#define DYNAMIC_SAFE_FONT(X) (gh_pair_p((X))? \ + SAFE_FONT(gh_cdr(X)) : \ SAFE_FONT((X))) #ifdef I18N === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u image.c Index: image.c =================================================================== RCS file: /anoncvs/scwm/scwm/image.c,v retrieving revision 1.51 diff -u -r1.51 image.c --- image.c 1998/12/05 05:18:44 1.51 +++ image.c 1998/12/05 17:02:14 @@ -94,6 +94,8 @@ static SCM str_default; static SCM str_empty; +SCWM_GLOBAL_SYMBOL(sym_dynamic_image, "dynamic-image"); + SCM_SYMBOL (sym_filename,"filename"); SCM_SYMBOL (sym_width,"width"); SCM_SYMBOL (sym_height,"height"); === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u image.h Index: image.h =================================================================== RCS file: /anoncvs/scwm/scwm/image.h,v retrieving revision 1.16 diff -u -r1.16 image.h --- image.h 1998/11/14 23:09:06 1.16 +++ image.h 1998/12/05 17:02:20 @@ -61,12 +61,16 @@ #define IMAGE_P(X) (SCM_NIMP(X) && gh_car(X) == (SCM)scm_tc16_scwm_image) #define IMAGE(X) ((scwm_image *)gh_cdr(X)) #define SAFE_IMAGE(X) (IMAGE_P((X))? IMAGE((X)) : NULL) -#define DYNAMIC_IMAGE_P(X) (gh_symbol_p(X)? \ - IMAGE_P(scm_symbol_binding(SCM_BOOL_F,(X))) : \ - IMAGE_P(X)) -#define IMAGE_OR_SYMBOL_P(X) (IMAGE_P(X) || gh_symbol_p(X)) +#define IMAGE_OR_FALSE_P(X) (IMAGE_P(X) || (X) == SCM_BOOL_F) + +extern SCM sym_dynamic_image; + +#define DYNAMIC_IMAGE_OR_FALSE_P(X) (gh_pair_p(X)? \ + gh_car(X) == sym_dynamic_image : \ + IMAGE_OR_FALSE_P(X)) + #define DYNAMIC_SAFE_IMAGE(X) (gh_symbol_p(X)? \ - SAFE_IMAGE(scm_symbol_binding(SCM_BOOL_F,(X))):\ + SAFE_IMAGE(gh_cdr(X)):\ SAFE_IMAGE(X)) EXTERN long scm_tc16_scwm_image; === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menu.c Index: menu.c =================================================================== RCS file: /anoncvs/scwm/scwm/menu.c,v retrieving revision 1.56 diff -u -r1.56 menu.c --- menu.c 1998/12/05 03:44:35 1.56 +++ menu.c 1998/12/05 17:02:35 @@ -48,30 +48,18 @@ extern SCM sym_top, sym_center, sym_bottom; -/* MS:FIXME:: These SCM_VAR_INIT's should be removed when we have a -better long-term solution to styling menus. TEMPORARY HACK! */ +SCWM_GLOBAL_SYMBOL(sym_dynamic_menu, "dynamic-menu"); -SCM_VCELL_INIT(menu_bg_color, "menu-bg-color", make_color(gh_str02scm("gray80"))); -SCM_VCELL_INIT(menu_text_color, "menu-text-color", make_color(gh_str02scm("black"))); -SCM_VCELL_INIT(menu_stipple_color, "menu-stipple-color", make_color(gh_str02scm("gray60"))); -SCM_VCELL_INIT(menu_font, "menu-font", make_font(gh_str02scm("fixed"))); -SCM_VCELL_INIT(menu_side_image, "menu-side-image", SCM_BOOL_F); -SCM_VCELL_INIT(menu_side_bg_color, "menu-side-bg-color", make-color(gh_str02scm("gray80"))); -SCM_VCELL_INIT(menu_side_bg_color_set, "menu-side-bg-color-set", SCM_BOOL_F); -SCM_VCELL_INIT(menu_bg_image, "menu-bg-image", SCM_BOOL_F); -SCM_VCELL_INIT(menu_look, "menu-look", drawmenu_menu_look); - - static DynamicMenu *NewDynamicMenu(Menu *pmenu, DynamicMenu *pmdPoppedFrom); static void PopdownMenu(DynamicMenu *pmd); static void FreeDynamicMenu(DynamicMenu *pmd); static SCM -scwm_safe_call0_sym(SCM thunk) +scwm_safe_call0_dynamic(SCM thunk) { - DEREF_IF_SYMBOL(thunk); + if (gh_pair_p(thunk)) thunk = gh_car(thunk); return scwm_safe_call0(thunk); } @@ -288,28 +276,28 @@ /* BG-COLOR: Required */ iarg++; - if (!COLOR_OR_SYMBOL_P(bg_color)) { /* why not DYNAMIC_COLOR_P? */ + if (!DYNAMIC_COLOR_OR_FALSE_P(bg_color)) { scm_wrong_type_arg(FUNC_NAME,iarg,bg_color); } pmenu->scmBGColor = bg_color; /* TEXT-COLOR: Required */ iarg++; - if (!COLOR_OR_SYMBOL_P(text_color)) { /* again */ + if (!DYNAMIC_COLOR_OR_FALSE_P(text_color)) { scm_wrong_type_arg(FUNC_NAME,iarg,text_color); } pmenu->scmTextColor = text_color; /* STIPPLE-COLOR: Required */ iarg++; - if (!COLOR_OR_SYMBOL_P(stipple_color)) { /* And again */ + if (!DYNAMIC_COLOR_OR_FALSE_P(stipple_color)) { scm_wrong_type_arg(FUNC_NAME,iarg,stipple_color); } pmenu->scmStippleColor = stipple_color; /* FONT: Required */ iarg++; - if (!FONT_OR_SYMBOL_P(font)) { /* DYNAMIC_FONT_P ? */ + if (!DYNAMIC_FONT_OR_FALSE_P(font)) { scm_wrong_type_arg(FUNC_NAME,iarg,font); } pmenu->scmFont = font; @@ -319,7 +307,7 @@ iarg++; if (UNSET_SCM(picture_side)) { picture_side = SCM_BOOL_F; - } else if (!IMAGE_OR_SYMBOL_P(picture_side)) { + } else if (!DYNAMIC_IMAGE_OR_FALSE_P(picture_side)) { scm_wrong_type_arg(FUNC_NAME,iarg,picture_side); } pmenu->scmImgSide = picture_side; @@ -341,7 +329,7 @@ iarg++; if (UNSET_SCM(side_bg_color)) { side_bg_color = WHITE_COLOR; - } else if (!COLOR_OR_SYMBOL_P(side_bg_color)) { + } else if (!DYNAMIC_COLOR_OR_FALSE_P(side_bg_color)) { scm_wrong_type_arg(FUNC_NAME,iarg,side_bg_color); } pmenu->scmSideBGColor = side_bg_color; @@ -350,7 +338,7 @@ iarg++; if (UNSET_SCM(picture_bg)) { picture_bg = SCM_BOOL_F; - } else if (!IMAGE_OR_SYMBOL_P(picture_bg)) { + } else if (!DYNAMIC_IMAGE_OR_FALSE_P(picture_bg)) { scm_wrong_type_arg(FUNC_NAME,iarg,picture_bg); } pmenu->scmImgBackground = picture_bg; @@ -416,7 +404,7 @@ } iarg++; - if (!MENULOOK_OR_SYMBOL_P(menu_look)) { + if (!DYNAMIC_MENULOOK_OR_FALSE_P(menu_look)) { scm_wrong_type_arg(FUNC_NAME,iarg,menu_look); } @@ -680,8 +668,8 @@ { MenuItemInMenu *pmiimSelected = PmiimSelectedFromPmd(pmd); /* invoke the un-hover action */ - if (pmiimSelected && !UNSET_SCM(pmiimSelected->pmi->scmUnhover)) { - return scwm_safe_call0_sym(pmiimSelected->pmi->scmUnhover); + if (pmiimSelected && DYNAMIC_PROCEDURE_P(pmiimSelected->pmi->scmUnhover)) { + return scwm_safe_call0_dynamic(pmiimSelected->pmi->scmUnhover); } else { DBUG((DBG,FUNC_NAME,"No unhover hook, %ld",pmiimSelected)); } @@ -1003,7 +991,7 @@ pmd->fHoverActionInvoked = True; /* invoke the hover action */ if (DYNAMIC_PROCEDURE_P(scmHover)) { - scwm_safe_call0_sym(scmHover); + scwm_safe_call0_dynamic(scmHover); } } /* block until there is an interesting event */ @@ -1257,6 +1245,7 @@ pmiim->chShortcut = '\0'; pmiim->ichShortcutOffset = -1; + /* CRW:FIXME:: We shouldn't cache this field; it should be dynamic. */ pmiim->fShowPopupArrow = (DYNAMIC_MENU_P(pmiim->pmi->scmAction)) || (DYNAMIC_MENU_P(pmiim->pmi->scmHover)); if (pmiim->pmi->scmAction == SCM_BOOL_F) @@ -1415,10 +1404,9 @@ PopdownMenu(pmd); PopdownAllPriorMenus(pmd); FreeDynamicMenu(pmd); - DEREF_IF_SYMBOL(scmAction); if (DYNAMIC_PROCEDURE_P(scmAction)) { - return scwm_safe_call0_sym(scmAction); - } else if (DYNAMIC_MENU_P(scmAction)) { + return scwm_safe_call0_dynamic(scmAction); + } else if (DYNAMIC_MENU_OR_FALSE_P(scmAction)) { /* FIXGJB: is this recursion bad? */ return popup_menu(scmAction, SCM_BOOL_FromBool(fWarpToFirst), SCM_BOOL_F, SCM_BOOL_F, SCM_BOOL_F); @@ -1440,9 +1428,7 @@ /* FIXGJB: above needs to be true if we're doing the window list */ int x = -1, y = -1; int iarg = 1; - /* permit 'menu to be used, and look up dynamically */ - DEREF_IF_SYMBOL(menu); - if (!MENU_P(menu)) { + if (!DYNAMIC_MENU_OR_FALSE_P(menu)) { scm_wrong_type_arg(FUNC_NAME, iarg++, menu); } COPY_BOOL_OR_ERROR_DEFAULT_FALSE(fWarpToFirst,warp_to_first_p,iarg++,FUNC_NAME); @@ -1455,7 +1441,7 @@ COPY_BOOL_OR_ERROR_DEFAULT_TRUE(fLeftSide,left_side_p,iarg++,FUNC_NAME); - return PopupGrabMenu(MENU(menu),NULL,fWarpToFirst,fPermitAltReleaseToSelect, + return PopupGrabMenu(DYNAMIC_SAFE_MENU(menu),NULL,fWarpToFirst,fPermitAltReleaseToSelect, x,y, fLeftSide?0:1); } #undef FUNC_NAME === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menu.h Index: menu.h =================================================================== RCS file: /anoncvs/scwm/scwm/menu.h,v retrieving revision 1.18 diff -u -r1.18 menu.h --- menu.h 1998/11/14 23:09:06 1.18 +++ menu.h 1998/12/05 17:02:44 @@ -77,16 +77,20 @@ #define MENU_P(X) (SCM_NIMP((X)) && (gh_car((X)) == (SCM)scm_tc16_scwm_menu)) #define MENU(X) ((Menu *)gh_cdr((X))) +#define MENU_OR_FALSE_P(X) (MENU_P(X) || (X) == SCM_BOOL_F) -#define MENU_OR_SYMBOL_P(X) (MENU_P((X)) || gh_symbol_p((X))) - #define SAFE_MENU(X) (MENU_P((X))? MENU((X)): NULL) + +extern SCM sym_dynamic_menu; -#define DYNAMIC_MENU_P(X) (gh_symbol_p((X))? \ - MENU_P(scm_symbol_binding(SCM_BOOL_F,(X))) : \ +#define DYNAMIC_MENU_P(X) (gh_pair_p((X))? \ + gh_car(X) == sym_dynamic_menu : \ MENU_P((X))) +#define DYNAMIC_MENU_OR_FALSE_P(X) (gh_pair_p((X))? \ + gh_car(X) == sym_dynamic_menu : \ + MENU_OR_FALSE_P((X))) #define DYNAMIC_SAFE_MENU(X) (gh_symbol_p((X))? \ - SAFE_MENU(scm_symbol_binding(SCM_BOOL_F,(X))) : \ + SAFE_MENU(gh_cdr(X)) : \ SAFE_MENU((X))) SCM popup_menu(SCM menu, SCM warp_to_first, SCM x_pos, SCM y_pos, SCM left_side_p); === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menuitem.c Index: menuitem.c =================================================================== RCS file: /anoncvs/scwm/scwm/menuitem.c,v retrieving revision 1.27 diff -u -r1.27 menuitem.c --- menuitem.c 1998/12/03 08:20:12 1.27 +++ menuitem.c 1998/12/05 17:02:50 @@ -185,7 +185,7 @@ iarg++; if (UNSET_SCM(hover_action)) { pmi->scmHover = SCM_BOOL_F; - } else if (!PROCEDURE_OR_SYMBOL_P(hover_action)) { + } else if (!DYNAMIC_PROCEDURE_OR_FALSE_P(hover_action)) { scm_wrong_type_arg(FUNC_NAME,iarg,hover_action); } pmi->scmHover = hover_action; @@ -193,7 +193,7 @@ iarg++; if (UNSET_SCM(unhover_action)) { pmi->scmUnhover = SCM_BOOL_F; - } else if (!PROCEDURE_OR_SYMBOL_P(unhover_action)) { + } else if (!DYNAMIC_PROCEDURE_OR_FALSE_P(unhover_action)) { scm_wrong_type_arg(FUNC_NAME,iarg,unhover_action); } pmi->scmUnhover = unhover_action; === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menulook.c Index: menulook.c =================================================================== RCS file: /anoncvs/scwm/scwm/menulook.c,v retrieving revision 1.7 diff -u -r1.7 menulook.c --- menulook.c 1998/12/03 08:20:12 1.7 +++ menulook.c 1998/12/05 17:02:57 @@ -22,6 +22,8 @@ #include "scwm.h" #include "screen.h" +SCWM_GLOBAL_SYMBOL(sym_dynamic_menulook, "dynamic-menulook"); + SCM mark_menulook(SCM scm) { @@ -101,7 +103,7 @@ scwm_menulook * pmlOrig; iarg++; - if (!DYNAMIC_MENULOOK_P(original_menu_look)) { + if (!DYNAMIC_MENULOOK_OR_FALSE_P(original_menu_look)) { scm_wrong_type_arg(FUNC_NAME,iarg,original_menu_look); } pmlOrig = DYNAMIC_SAFE_MENULOOK(original_menu_look); === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u menulook.h Index: menulook.h =================================================================== RCS file: /anoncvs/scwm/scwm/menulook.h,v retrieving revision 1.2 diff -u -r1.2 menulook.h --- menulook.h 1998/10/06 22:17:39 1.2 +++ menulook.h 1998/12/05 17:03:02 @@ -67,13 +67,16 @@ #define MENULOOK_P(X) (SCM_NIMP(X) && gh_car(X) == (SCM)scm_tc16_scwm_menulook) #define MENULOOK(X) ((scwm_menulook *)gh_cdr(X)) #define SAFE_MENULOOK(X) (MENULOOK_P(X)? MENULOOK(X) : NULL) +#define MENULOOK_OR_FALSE_P(X) (MENULOOK_P(X) || (X) == SCM_BOOL_F) -#define MENULOOK_OR_SYMBOL_P(X) (MENULOOK_P(X) || gh_symbol_p(X)) -#define DYNAMIC_MENULOOK_P(X) (gh_symbol_p(X) ? \ - MENULOOK_P(scm_symbol_binding(SCM_BOOL_F,(X))) :\ - MENULOOK_P(X)) +extern SCM sym_dynamic_menulook; + +#define DYNAMIC_MENULOOK_OR_FALSE_P(X) (gh_pair_p(X) ? \ + gh_car(X) == sym_dynamic_menulook :\ + MENULOOK_OR_FALSE_P(X)) + #define DYNAMIC_SAFE_MENULOOK(X) (gh_symbol_p(X) ? \ - SAFE_MENULOOK(scm_symbol_binding(SCM_BOOL_F,(X))) : \ + SAFE_MENULOOK(gh_cdr(X)) : \ SAFE_MENULOOK(X)) EXTERN long scm_tc16_scwm_menulook; === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u scwm.c Index: scwm.c =================================================================== RCS file: /anoncvs/scwm/scwm/scwm.c,v retrieving revision 1.155 diff -u -r1.155 scwm.c --- scwm.c 1998/12/05 03:44:35 1.155 +++ scwm.c 1998/12/05 17:03:18 @@ -179,6 +179,8 @@ void scwm_main(int, char **); +SCWM_GLOBAL_SYMBOL(sym_dynamic_procedure, "dynamic-procedure"); + Atom XA_MIT_PRIORITY_COLORS; Atom XA_WM_CHANGE_STATE; Atom XA_WM_STATE; === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u scwm.h Index: scwm.h =================================================================== RCS file: /anoncvs/scwm/scwm/scwm.h,v retrieving revision 1.64 diff -u -r1.64 scwm.h --- scwm.h 1998/11/24 11:35:48 1.64 +++ scwm.h 1998/12/05 17:03:26 @@ -172,15 +172,23 @@ SCM_SETCDR((ANSWER),(SCM) (PSMOB)); \ } while (0) +#if 0 #define DEREF_IF_SYMBOL(x) do { if (gh_symbol_p((x))) { \ (x) = scm_symbol_binding(SCM_BOOL_F,(x)); \ } } while (0) +#endif +extern SCM sym_dynamic_procedure; + #define DYNAMIC_PROCEDURE_P(x) (gh_procedure_p((x)) || \ - (gh_symbol_p((x)) && \ - gh_procedure_p(scm_symbol_binding(SCM_BOOL_F,(x))))) + (gh_pair_p((x)) && \ + gh_car(x) == sym_dynamic_procedure && \ + gh_procedure_p(gh_cdr(x)))) -#define PROCEDURE_OR_SYMBOL_P(x) (gh_procedure_p((x)) || gh_symbol_p((x))) +#define DYNAMIC_PROCEDURE_OR_FALSE_P(x) (gh_procedure_p((x)) || \ + (x) == SCM_BOOL_F || \ + (gh_pair_p((x)) && \ + gh_car(x) == sym_dynamic_procedure)) #define RESTP_SCM 1 From owner-scwm-discuss@mit.edu Sat Dec 5 15:04:58 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA09246 for scwm-discuss-outgoing; Sat, 5 Dec 1998 15:04:58 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA09243 for ; Sat, 5 Dec 1998 15:04:57 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA12827; Sat, 5 Dec 98 15:02:51 EST Received: (qmail 29694 invoked by uid 501); 5 Dec 1998 20:03:16 -0000 Message-Id: <19981205120315.A29600@molehill.org> Date: Sat, 5 Dec 1998 12:03:15 -0800 From: Todd Larason To: Craig Struble , scwm-discuss@mit.edu, cwitty@newtonlabs.com Subject: Re: Problems with latest source References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: ; from Craig Struble on Sat, Dec 05, 1998 at 04:23:36PM +0000 X-Kibo: Fiction makes sense. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981205, Craig Struble wrote: > Now comes the real kicker. I got scwm to compile, but it core dumps > immediately. I tracked it down to the fact that init_menu() in > menu.c/menu.x is calling make_color() in color.c before the X display is > opened. So, the global `dpy' is NULL in make_color(), and scwm dies. I > looked in scwm_main(), and sure enough, the X display is opened after all > initialization, but you can't create colors before the display is opened. oh blech. There are some initialization functions called afterwards, but this is just getting messier and messier for what was supposed to be a quick hack Maciej, what do you think of Carl's proposed solution, dynamically updating cons cells? The only non-aesthetic issue I'm troubled with is that there may be other code, either C or Scheme, that assumes that the DYNAMIC_* things work off straight symbols. -- ICQ UIN: 92197374 From owner-scwm-discuss@mit.edu Sat Dec 5 15:27:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA09645 for scwm-discuss-outgoing; Sat, 5 Dec 1998 15:27:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA09642 for ; Sat, 5 Dec 1998 15:27:46 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA24769; Sat, 5 Dec 98 15:26:02 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id MAA09411; Sat, 5 Dec 1998 12:25:52 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: cvsweb is back References: <199812050612.BAA08557@M66-080-6.mit.edu> From: Greg Badros Date: 05 Dec 1998 12:25:51 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 05 Dec 1998 01:12:33 EST" Message-Id: Lines: 25 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Try it, it's cool. The only drawback is that blame-annotated pages > can come out really huge and thus be slow to download. It's not working for me. Standard version: File Not Found The requested URL /cgi-bin/cvsweb was not found on this server. Improved version: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error. Greg From owner-scwm-discuss@mit.edu Sat Dec 5 15:29:06 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA09704 for scwm-discuss-outgoing; Sat, 5 Dec 1998 15:29:06 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA09698 for ; Sat, 5 Dec 1998 15:29:04 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA15884; Sat, 5 Dec 98 15:26:58 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.4/8.8.4) with ESMTP id MAA09325; Sat, 5 Dec 1998 12:26:59 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.5/8.8.5) id MAA14581; Sat, 5 Dec 1998 12:26:56 -0800 To: Todd Larason Cc: Craig Struble , scwm-discuss@mit.edu Subject: Re: Problems with latest source References: <19981205120315.A29600@molehill.org> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 05 Dec 1998 12:26:55 -0800 In-Reply-To: Todd Larason's message of "Sat, 5 Dec 1998 12:03:15 -0800" Message-Id: Lines: 18 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > Maciej, what do you think of Carl's proposed solution, dynamically updating > cons cells? > > The only non-aesthetic issue I'm troubled with is that there may be other > code, either C or Scheme, that assumes that the DYNAMIC_* things work off > straight symbols. I would certainly make an effort to find such code before I submitted the final patch. (I was planning on searching through sample.scwmrc/*, for instance.) Of course, this is not backward-compatible, and so it could break somebody's .scwmrc. But I think it's worth doing anyway. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sat Dec 5 16:56:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA13449 for scwm-discuss-outgoing; Sat, 5 Dec 1998 16:56:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA13446 for ; Sat, 5 Dec 1998 16:56:13 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA06485; Sat, 5 Dec 98 16:54:28 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id QAA04223; Sat, 5 Dec 1998 16:54:18 -0500 Message-Id: <199812052154.QAA04223@M66-080-21.mit.edu> To: Todd Larason To: Craig Struble , scwm-discuss@mit.edu, cwitty@newtonlabs.com Subject: Re: Problems with latest source In-Reply-To: Your message of "Sat, 05 Dec 1998 12:03:15 PST." <19981205120315.A29600@molehill.org> Date: Sat, 05 Dec 1998 16:54:18 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981205, Craig Struble wrote: > > Now comes the real kicker. I got scwm to compile, but it core dumps > > immediately. I tracked it down to the fact that init_menu() in > > menu.c/menu.x is calling make_color() in color.c before the X display is > > opened. So, the global `dpy' is NULL in make_color(), and scwm dies. I > > looked in scwm_main(), and sure enough, the X display is opened after all > > initialization, but you can't create colors before the display is opened. > > oh blech. There are some initialization functions called afterwards, but thi > s > is just getting messier and messier for what was supposed to be a quick hack > I agree, this is clearly a fragile mess, I think the best thing to do is to put things back the way they were until they can be done better; in generally it may also be necessary to give some modules extra initialization functions that get called after the X display is opened, or call all of them at that point. > Maciej, what do you think of Carl's proposed solution, dynamically updating > cons cells? > I'll respond to his message shortly when I think it over. > The only non-aesthetic issue I'm troubled with is that there may be other > code, either C or Scheme, that assumes that the DYNAMIC_* things work off > straight symbols. There is but I don't think changing it will be _too_ hard... - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 17:02:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA13514 for scwm-discuss-outgoing; Sat, 5 Dec 1998 17:02:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA13511; Sat, 5 Dec 1998 17:02:39 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA07379; Sat, 5 Dec 98 17:00:55 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id RAA04249; Sat, 5 Dec 1998 17:00:46 -0500 Message-Id: <199812052200.RAA04249@M66-080-21.mit.edu> To: "Greg J. Badros" Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Sat Dec 5 15:11:44 EST 1998 In-Reply-To: Your message of "Sat, 05 Dec 1998 15:11:44 EST." <199812052011.PAA09454@vicarious-existence.mit.edu> Date: Sat, 05 Dec 1998 17:00:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@vicarious-existence.mit.edu writes: > Update of /usr/local/repository/scwm/scheme > In directory vicarious-existence.mit.edu:/tmp/cvs-serv9432 > > Added Files: > move-resize-message-window.scm move-with-message-window.scm > resize-with-message-window.scm > standard-move-resize-message-window.scm > Log Message: > * move-resize-message-window.scm, move-with-message-window.scm, > resize-with-message-window.scm, > standard-move-resize-message-window.scm: Added -- by Jeff > W. Nichols. Supports previously-built-in support for message > window display of move position and resize size during interactive > moves and resizes. > _Please_ let's not have filenames that long. I like meaningful identifiers as much as the next guy, but I'm sure there must be shorter ways to express these ideas. It also seems to me they could all be merged into one module since they're conceptually similar and you'd rarely want one but not the other. Also, it seems to me that given the hooks in the interactive move and resize loops, it should be possible to set it up so that, given a setting of a particular parameter, _all_ interactive moves and resizes will use a message window. Is Jeff on scwm-discuss? If not, what's his email address so we can discuss this? (In general I think the enhancements here are very cool.) - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 17:10:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA13707 for scwm-discuss-outgoing; Sat, 5 Dec 1998 17:10:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA13703 for ; Sat, 5 Dec 1998 17:10:24 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA29091; Sat, 5 Dec 98 17:08:18 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id RAA04280; Sat, 5 Dec 1998 17:08:31 -0500 Message-Id: <199812052208.RAA04280@M66-080-21.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu Subject: Re: cvsweb is back In-Reply-To: Your message of "05 Dec 1998 12:25:51 PST." Date: Sat, 05 Dec 1998 17:08:29 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > Try it, it's cool. The only drawback is that blame-annotated pages > > can come out really huge and thus be slow to download. > > It's not working for me. Standard version: > > > File Not Found > > The requested URL /cgi-bin/cvsweb was not found on this server. > > Oops - I was running them directly, and I named the file wrong. Now fixed. > Improved version: > > Internal Server Error > > The server encountered an internal error or misconfiguration and was unable t > o complete your request. > > Please contact the server administrator, root@localhost and inform them of th > e time the error occurred, and anything > you might have done that may have caused the error. > An extraneous character made it's way into the script somehow - apparently after I last saved it. Try again, it should work now. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 17:21:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA13884 for scwm-discuss-outgoing; Sat, 5 Dec 1998 17:21:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA13881 for ; Sat, 5 Dec 1998 17:21:22 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA09667; Sat, 5 Dec 98 17:19:38 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id RAA04388; Sat, 5 Dec 1998 17:19:27 -0500 Message-Id: <199812052219.RAA04388@M66-080-21.mit.edu> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Sat Dec 5 15:11:44 EST 1998 In-Reply-To: Your message of "Sat, 05 Dec 1998 17:00:45 EST." <199812052200.RAA04249@M66-080-21.mit.edu> Date: Sat, 05 Dec 1998 17:19:27 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mstachow@mit.edu writes: > > Also, it seems to me that > given the hooks in the interactive move and resize loops, it should be > possible to set it up so that, given a setting of a particular > parameter, _all_ interactive moves and resizes will use a message > window. > Duh, that _is_ the way the modules work, they do it unconditionally though (hence the split). Should've read the code before posting. How about making one module that exports {enable,disable}-{move,resize}-message-window, I think that is a nicer API since you can turn it on and off at any time, and you don't need quite so many modules. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 18:08:19 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14345 for scwm-discuss-outgoing; Sat, 5 Dec 1998 18:08:19 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA14342 for ; Sat, 5 Dec 1998 18:08:18 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA14862; Sat, 5 Dec 98 18:06:33 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id PAA09764; Sat, 5 Dec 1998 15:06:18 -0800 (PST) To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, Jeffrey Nichols Subject: message-window interface and features References: <199812052200.RAA04249@M66-080-21.mit.edu> From: Greg Badros Date: 05 Dec 1998 15:06:18 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 05 Dec 1998 17:00:45 EST" Message-Id: Lines: 60 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > identifiers as much as the next guy, but I'm sure there must be > shorter ways to express these ideas. It also seems to me they could > all be merged into one module since they're conceptually similar and > you'd rarely want one but not the other. Also, it seems to me that > given the hooks in the interactive move and resize loops, it should be > possible to set it up so that, given a setting of a particular > parameter, _all_ interactive moves and resizes will use a message > window. I prefer long and unambiguous names to shorter names. Abbreviations are particularly troublesome because it's ambiguous how something is abbreviated. message could be msg or mesg, etc. Right now if you (use-modules (app scwm standard-move-resize-message-window) then you get all interactive moves and resizes using a message window. The sub-modules are separated so they could be used independently, but the above module is what I added to the .scwmrcs. Their are three open issues with this code: 1) the default attributes for a new message-window are copied from the Scr struct, and there is no way to control those values (in particular, display-message-window-briefly uses those defaults). Perhaps we should have a default message-window object whose attributes are cloned, then permit changing of those attributes to control newly constructed message-windows. 2) when a message-window is shown, but then the object is no longer referenceable, there is no way to hide that message-window, or otherwise talk about it. (Jeff, I added a scm_protect_object in show, and scm_unprotect_object in hide to avoid core dumping if the message-window is GC'd while the window is still up). One possibility is hide message window objects when they are freed. This is a bit weird since the GC runs at an arbitrary time, but at least makes sure that there aren't message-windows that cannot be removed from display. Also, as far as I can figure, if you lose a handle on a message window that is displayed, your code is buggy. Another possibility would be to keep a list of message-windows that are currently shown. Then one could always iterate over the message-windows. This functionality could be written completely in scheme using wrappers over m-w-show! and m-w-hide!. 3) The C primitives should be in a dynamically-loadable module > > Is Jeff on scwm-discuss? If not, what's his email address so we can > discuss this? Yep, he reads it (but it's the end of the quarter here at the UW, so like me he's pretty swamped, so I've cc'd him directly, too). But most of the finer-grained split of the modules, and lengthening of names was my doing as I was preparing the code for the commit and making sure nothing broke. > (In general I think the enhancements here are very cool.) Me too -- nice work Jeff! Greg From owner-scwm-discuss@mit.edu Sat Dec 5 18:33:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA14844 for scwm-discuss-outgoing; Sat, 5 Dec 1998 18:33:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA14841 for ; Sat, 5 Dec 1998 18:33:40 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA17627; Sat, 5 Dec 98 18:31:55 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id SAA04518; Sat, 5 Dec 1998 18:31:45 -0500 Message-Id: <199812052331.SAA04518@M66-080-21.mit.edu> To: Greg Badros Cc: scwm-discuss@mit.edu, Jeffrey Nichols Subject: Re: message-window interface and features In-Reply-To: Your message of "05 Dec 1998 15:06:18 PST." Date: Sat, 05 Dec 1998 18:31:45 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk gjb@cs.washington.edu writes: > Maciej Stachowiak writes: > > > identifiers as much as the next guy, but I'm sure there must be > > shorter ways to express these ideas. It also seems to me they could > > all be merged into one module since they're conceptually similar and > > you'd rarely want one but not the other. Also, it seems to me that > > given the hooks in the interactive move and resize loops, it should be > > possible to set it up so that, given a setting of a particular > > parameter, _all_ interactive moves and resizes will use a message > > window. > > I prefer long and unambiguous names to shorter names. Abbreviations are > particularly troublesome because it's ambiguous how something is > abbreviated. message could be msg or mesg, etc. > I don't find that troublesome as long as the same abbreviation is used consistently for the same thing. I don't think it should necessarily be the case that someone should be able to guess the module name based on the functionality, just (with some approximation) the other way around. I think when identifiers get too long (e.g. it takes 59 characters for the below module use declaration) code readability is negatively impacted. At least this is true for me. > Right now if you (use-modules (app scwm standard-move-resize-message-window) > then you get all interactive moves and resizes using a message window. > The sub-modules are separated so they could be used independently, but > the above module is what I added to the .scwmrcs. > Gotcha. What I'd like to have happen (as described in another message) is that all this stuff should live in one module, and there are splicit calls to enable and disable message windows for moving and/or resizing (I don't even mind if both are turned on by default when you use the module). That way, you have fine-grained behavior control. > Their are three open issues with this code: > > 1) the default attributes for a new message-window are copied from the > Scr struct, and there is no way to control those values (in particular, > display-message-window-briefly uses those defaults). Perhaps we should > have a default message-window object whose attributes are cloned, then > permit changing of those attributes to control newly constructed > message-windows. That's plausible, or else we could add getters and setters for the defaults, or have message-window styles similar to window-styles and my proposed analogous menu-styles (though that may be overkill). > 2) when a message-window is shown, but then the object is no longer > referenceable, there is no way to hide that message-window, or otherwise > talk about it. (Jeff, I added a scm_protect_object in show, and > scm_unprotect_object in hide to avoid core dumping if the message-window > is GC'd while the window is still up). One possibility is hide message > window objects when they are freed. This is a bit weird since the GC > runs at an arbitrary time, but at least makes sure that there aren't > message-windows that cannot be removed from display. Also, as far as I > can figure, if you lose a handle on a message window that is displayed, > your code is buggy. Another possibility would be to keep a list of > message-windows that are currently shown. Then one could always iterate > over the message-windows. This functionality could be written > completely in scheme using wrappers over m-w-show! and m-w-hide!. > I think a list of shown windows is good. Let's see, scm_protect_object and scm_unprotect_object > 3) The C primitives should be in a dynamically-loadable module > Agreed, I don't think this is something we need to hugely worry about though - I am thinking of drawing up a list of all the stuff in core that I think should go into a module and discuss which code this is feasible for and what code it is actually a good idea for. > > > > Is Jeff on scwm-discuss? If not, what's his email address so we can > > discuss this? > > Yep, he reads it (but it's the end of the quarter here at the UW, so > like me he's pretty swamped, so I've cc'd him directly, too). But most > of the finer-grained split of the modules, and lengthening of names was > my doing as I was preparing the code for the commit and making sure > nothing broke. > OK, I'd still like to see Jeff's comments about how the final version should work, if he has any (especially if he disagrees with stuff said here). I'm an opinonated SOB about APIs, but I don't like to rearrange people's code without at least hearing their input. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 20:50:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA25667 for scwm-discuss-outgoing; Sat, 5 Dec 1998 20:50:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA25664 for ; Sat, 5 Dec 1998 20:50:02 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AB21692; Sat, 5 Dec 98 20:47:54 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id UAA04626; Sat, 5 Dec 1998 20:48:07 -0500 Message-Id: <199812060148.UAA04626@M66-080-21.mit.edu> To: Arturo Perez Cc: scwm-discuss@mit.edu Subject: Re: that unruly netscape In-Reply-To: Your message of "Wed, 25 Nov 1998 16:10:09 EST." <199811252120.QAA04700@ns1.infonautics.com> Date: Sat, 05 Dec 1998 20:48:06 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > Using netscape4.03 under Irix. > > Is there any trick to getting it to obey the icon box? > Using system.scwmrc, netscape obeys the icon box just fine on Solaris for me. I will try it on Irix shortly but I don't expect to see a difference. Regarding your other previously reported problem with icons, when I iconify a window with sticky icons, move the icon manually, deiconify the window, and reiconify it, the icon ends up where I moved it manually. It seems that you are seeing all sorts of strange icon behavior that I am not. I wish I could figure out why. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 20:53:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA25781 for scwm-discuss-outgoing; Sat, 5 Dec 1998 20:53:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA25773 for ; Sat, 5 Dec 1998 20:52:54 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA01072; Sat, 5 Dec 98 20:51:03 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id UAA04630; Sat, 5 Dec 1998 20:50:53 -0500 Message-Id: <199812060150.UAA04630@M66-080-21.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "05 Dec 1998 09:14:25 PST." Date: Sat, 05 Dec 1998 20:50:53 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Todd Larason writes: > > > I do wonder whether a cleaner method could be found to do what this was > > attempting to do, to pass handle of a binding and/or scheme object from the > > scheme level to the C level, such that changes made to the binding in schem > e > > are visible in C. > > How about cons cells? > Using cons cells as references is certainly much better than using symbols. However, I think it also loses most of the advantages, because it is no longer as convenient as setting a variable. Indeed, if one is willing to make things more complicated, one may as well add type checking and stuff like that, and then it gets to be almost as much work as the epxlicitly mutable meanu stuff. It certainly is less of a mess than the symbol stuff, and so would be a better interim solution, but I don't know how much effort you want to put into coding something that will be temporary (of course, given the generall hosedness of most scwm developers `temporary' can be a long time). So I guess the answer is, I'd be glad to see it go in, but ultimately I would still rather have menu styles work more like window styles, with explicit mutation and code to manage that automatically when styles change. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 22:15:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA29338 for scwm-discuss-outgoing; Sat, 5 Dec 1998 22:15:21 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA29335 for ; Sat, 5 Dec 1998 22:15:18 -0500 Received: from bastion.artisan.com by MIT.EDU with SMTP id AA08455; Sat, 5 Dec 98 22:13:31 EST Received: from ypmaster.artisan.com (ypmaster [172.16.2.1]) by bastion.artisan.com (8.9.1/8.9.0) with ESMTP id TAA25528 for ; Sat, 5 Dec 1998 19:12:18 -0800 (PST) Received: from lamb.artisan.com (lamb [172.16.10.20]) by ypmaster.artisan.com (8.8.4/8.8.4) with ESMTP id TAA04979 for ; Sat, 5 Dec 1998 19:13:17 -0800 (PST) Received: (from alt@localhost) by lamb.artisan.com (8.8.8/8.8.4) id TAA14061; Sat, 5 Dec 1998 19:13:17 -0800 (PST) X-Authentication-Warning: lamb.artisan.com: alt set sender to alt@lamb.artisan.com using -f From: "Albert L. Ting" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13929.63053.267972.4846@lamb.artisan.com> Date: Sat, 5 Dec 1998 19:13:17 -0800 (PST) To: scwm-discuss@mit.edu Subject: Re: that unruly netscape References: <199811252120.QAA04700@ns1.infonautics.com> <199812060148.UAA04626@M66-080-21.mit.edu> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > From: Maciej Stachowiak > To: Arturo Perez > Cc: scwm-discuss@mit.edu > Subject: Re: that unruly netscape > Date: Sat, 05 Dec 1998 20:48:06 EST > > > arturo@infonautics.com writes: > > Using netscape4.03 under Irix. > > > > Is there any trick to getting it to obey the icon box? > > > > Using system.scwmrc, netscape obeys the icon box just fine on Solaris > for me. I will try it on Irix shortly but I don't expect to see a > difference. > > Regarding your other previously reported problem with icons, when I > iconify a window with sticky icons, move the icon manually, deiconify > the window, and reiconify it, the icon ends up where I moved it > manually. > > It seems that you are seeing all sorts of strange icon behavior that I > am not. I wish I could figure out why. > > - Maciej I have a similar problem on solaris 2.6. I have different icon-boxes for various applications that have sticky icons. Essentially, I've defined several applications (client/server apps) to have the same icon-box, at the upper left hand corner, so that they hide behind my calendar icon, also at the same location. Unfortunately, scwm iconifies each of these windows at the x,y location as the associated window. Clearing the sticky property solves the problem, but it's no longer sticky... Albert From owner-scwm-discuss@mit.edu Sat Dec 5 22:26:26 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA29407 for scwm-discuss-outgoing; Sat, 5 Dec 1998 22:26:26 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA29403 for ; Sat, 5 Dec 1998 22:26:05 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA09399; Sat, 5 Dec 98 22:24:14 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id WAA04714; Sat, 5 Dec 1998 22:24:04 -0500 Message-Id: <199812060324.WAA04714@M66-080-21.mit.edu> To: scwm-discuss@mit.edu Subject: kept-on-top windows rising over menus Date: Sat, 05 Dec 1998 22:24:04 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I figure out the problem with kept-on-top windows being raised over Emacs's menus. The problem turns out to be that scwm handles VisibilityNotify events on kept-on-top windows that become partially or fully obscured by raising the kept-on-top window in question. This is arguably not the right thing to do if the window that caused the obsucrement is an override_redirect window such as a menu. However, I have no idea how to make this work very easily. One possible hack is to remember if the last event that happened was the mapping of an override_redirect window, and if so ignore VisibilityNotify events on kept-on-top windows until something different happens. Another possibility is to write a special raise function that instead restacks to immediately below the next-higher override_redirect window if there is one, by getting the stacking order from the server and going up the list from the kept-on-top window to the next override_redirect window. Another possibility is to eliminate this handling of VisibilityNotify. I am not sure I can think of cases where it is truly necessary; we should only really be putting kept-on-top windows on top when someone (us or otherwise) changes the stacking order, but there might be a valid reason this was coded the way it was - perhaps there is some case I haven't thought of where an on-top window could be obscured and we wouldn't otherwise know it. Any suggestions? - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 22:41:58 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA29875 for scwm-discuss-outgoing; Sat, 5 Dec 1998 22:41:58 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA29872 for ; Sat, 5 Dec 1998 22:41:57 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA01697; Sat, 5 Dec 98 22:39:46 EST Received: from bogomips.newtonlabs.com (root@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id SAA00741; Sat, 5 Dec 1998 18:10:19 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id SAA10116; Sat, 5 Dec 1998 18:05:36 -0800 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060150.UAA04630@M66-080-21.mit.edu> From: cwitty@newtonlabs.com (Carl R. Witty) Date: 05 Dec 1998 18:05:36 -0800 In-Reply-To: Maciej Stachowiak's message of "Sat, 05 Dec 1998 20:50:53 EST" Message-Id: Lines: 20 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > So I guess the answer is, I'd be glad to see it go in, but ultimately > I would still rather have menu styles work more like window styles, > with explicit mutation and code to manage that automatically when > styles change. I guess I'm not convinced that "menu styles" would be better. How would the user mark which menus should have which styles? The title/class/whatever that are used to classify windows are not available for menus. If the user has to mark each menu with an explicit style, I'm not sure that's better than passing in an explicit set of "dynamic" values. Also, there's an important implementation difference. Do you know how hard it is to create a data structure that keeps track of all the menus using weak pointers? I've never done that in guile. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sat Dec 5 23:11:21 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA30111 for scwm-discuss-outgoing; Sat, 5 Dec 1998 23:11:21 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA30108 for ; Sat, 5 Dec 1998 23:11:20 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA04105; Sat, 5 Dec 98 23:09:11 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id XAA04827; Sat, 5 Dec 1998 23:09:24 -0500 Message-Id: <199812060409.XAA04827@M66-080-21.mit.edu> To: cwitty@newtonlabs.com (Carl R. Witty) Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "05 Dec 1998 18:05:36 PST." Date: Sat, 05 Dec 1998 23:09:24 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cwitty@newtonlabs.com writes: > Maciej Stachowiak writes: > > > So I guess the answer is, I'd be glad to see it go in, but ultimately > > I would still rather have menu styles work more like window styles, > > with explicit mutation and code to manage that automatically when > > styles change. > > I guess I'm not convinced that "menu styles" would be better. How > would the user mark which menus should have which styles? The > title/class/whatever that are used to classify windows are not > available for menus. If the user has to mark each menu with an > explicit style, I'm not sure that's better than passing in an explicit > set of "dynamic" values. > Yes, you'd have to mark each manu with an explicit style since there is no classification (I suppose you could do it by menu title but that seems a bit weird). The benefits to the user (IMO) are that the interface works much the same way as window styles and thus is familar, and all aspects of a given menu style are organized under one name, the style name. It is also more convenient The benefits to the implementation are that a menu can type-check and precompute all of its drawing parameters and only needs to recheck and recompute when they are changed, not every time the menu is popped up. Finally, in the future features department, it will be much easier to create a menu style associated with a theme. > Also, there's an important implementation difference. Do you know how > hard it is to create a data structure that keeps track of all the > menus using weak pointers? I've never done that in guile. Pretty easy to keep track of them, I think all it needs is a weak vector per menu style. Access might be a bit messy. As another random thought I think all the various menu style options and menu looks should be unified, and all directly appearance-related data should be kept in a menu-look object. The menu contructor would take only the title, the look, and the items. This would save memory by sparing the menu from having to contain any color/font/etc data internally in each menu struct, which will save memory. That way the menu style code will only have to directly interact with menu-look objects. This way, the first argument to menu-style could be a menu-look object rather than an arbitrary identifier and no weak pointers are needed. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 5 23:16:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA30457 for scwm-discuss-outgoing; Sat, 5 Dec 1998 23:16:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA30454 for ; Sat, 5 Dec 1998 23:16:47 -0500 Received: from M66-080-21.MIT.EDU by MIT.EDU with SMTP id AA04499; Sat, 5 Dec 98 23:14:37 EST Received: by M66-080-21.mit.edu (SMI-8.6/4.7) id XAA04889; Sat, 5 Dec 1998 23:14:50 -0500 Message-Id: <199812060414.XAA04889@M66-080-21.mit.edu> To: "Albert L. Ting" Cc: scwm-discuss@mit.edu Subject: Re: that unruly netscape In-Reply-To: Your message of "Sat, 05 Dec 1998 19:13:17 PST." <13929.63053.267972.4846@lamb.artisan.com> Date: Sat, 05 Dec 1998 23:14:50 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk alt@artisan.com writes: > I have a similar problem on solaris 2.6. I have different icon-boxes for > various applications that have sticky icons. Essentially, I've defined several applications (client/server apps) to have the same icon-box, at the > upper left hand corner, so that they hide behind my calendar icon, also at > the same location. > > Unfortunately, scwm iconifies each of these windows at the x,y location as > the associated window. Clearing the sticky property solves the problem, > but it's no longer sticky... > Maybe I am not understanding the problem correctly. Could you send me a relevant scwmrc snippet and a step-by-step description of how to reproduce the problem? I'd like to get this problem resolved. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 00:20:33 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA01473 for scwm-discuss-outgoing; Sun, 6 Dec 1998 00:20:33 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA01470 for ; Sun, 6 Dec 1998 00:20:30 -0500 Received: from TEQUILA.CS.YALE.EDU by MIT.EDU with SMTP id AA09904; Sun, 6 Dec 98 00:18:20 EST Received: from tequila.cs.yale.edu (localhost [127.0.0.1]) by tequila.cs.yale.edu (8.8.7/8.8.7) with SMTP id AAA24642 for ; Sun, 6 Dec 1998 00:18:27 -0500 To: scwm-discuss@mit.edu From: Stefan Monnier Newsgroups: lists.scwm.discuss Subject: Re: kept-on-top windows rising over menus References: <199812060324.WAA04714@M66-080-21.mit.edu> Date: 06 Dec 1998 00:18:22 -0500 Message-Id: <5lemqdyhk1.fsf@tequila.cs.yale.edu> Lines: 14 X-Newsreader: Gnus v5.5/Emacs 20.3 Path: tequila.cs.yale.edu Nntp-Posting-Host: tequila.cs.yale.edu X-Trace: 6 Dec 1998 00:18:22 -0500, tequila.cs.yale.edu Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Maciej" == Maciej Stachowiak writes: > Another possibility is to eliminate this handling of VisibilityNotify. That's what I'd advise: in my ctwm patch that provides a similar feature, I haven't needed to play with this. Furthermore, it seems kind of dangerous: what if two `kept-on-top' windows stomp on each other ? Are they going to keep getting VisibilityNotify events and raise themselves indefinitely ? Stefan PS: also in ctwm I couldn't use such an event because I had to deal with more than just `kept-on-top' (I kept several "layers" from -8 (kept-on-bottom) to 8 (kept-on-top)). From owner-scwm-discuss@mit.edu Sun Dec 6 00:46:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA03212 for scwm-discuss-outgoing; Sun, 6 Dec 1998 00:46:23 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA03176 for ; Sun, 6 Dec 1998 00:46:20 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA21519; Sun, 6 Dec 98 00:44:29 EST Received: (qmail 18499 invoked by uid 501); 6 Dec 1998 05:44:07 -0000 Message-Id: <19981205214407.A18442@molehill.org> Date: Sat, 5 Dec 1998 21:44:07 -0800 From: Todd Larason To: Maciej Stachowiak , "Carl R. Witty" Cc: scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060409.XAA04827@M66-080-21.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199812060409.XAA04827@M66-080-21.mit.edu>; from Maciej Stachowiak on Sat, Dec 05, 1998 at 11:09:24PM -0500 X-Kibo: Good luck with George's abilities and sharp knives! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981205, Maciej Stachowiak wrote: > As another random thought I think all the various menu style options > and menu looks should be unified, and all directly appearance-related > data should be kept in a menu-look object. The menu contructor would > take only the title, the look, and the items. I really like this idea. Menu look objects would be augmented with the things that are currently stylish things, and would keep their 'extra' argument. There would need to be mutators for the various items, and for whatever else the look supports. -- ICQ UIN: 42896988 From owner-scwm-discuss@mit.edu Sun Dec 6 00:51:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id AAA03665 for scwm-discuss-outgoing; Sun, 6 Dec 1998 00:51:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id AAA03661 for ; Sun, 6 Dec 1998 00:51:23 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA12398; Sun, 6 Dec 98 00:48:53 EST Received: (qmail 18520 invoked by uid 501); 6 Dec 1998 05:48:59 -0000 Message-Id: <19981205214859.B18442@molehill.org> Date: Sat, 5 Dec 1998 21:48:59 -0800 From: Todd Larason To: scwm-discuss list Subject: RedHat|ContribNet Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 X-Kibo: If victories could stay in our world, would the Universe, U for Uranium, be false? Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't seen anyone else volunteer to package scwm up for RHCN, since Maciej first mentioned it several weeks ago, and I think it's vitally important that someone do this. I have some experience writing RPM spec files, so I'm in the process of signing up to do it now, but I will GLADLY step aside if/when someone with either more experience or more time volunteers. My current thinking is to have two packages to choose from, 'scwm' and 'scwm-snap', with versions like 'scwm-0.9-1' and 'scwm-snap-19981205-1', with snapshots made available 'when it seems right' - when new features are available and it's not crashing (for me) on a daily basis. Any objections? -- ICQ UIN: 52921199 From owner-scwm-discuss@mit.edu Sun Dec 6 01:01:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA03955 for scwm-discuss-outgoing; Sun, 6 Dec 1998 01:01:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA03948; Sun, 6 Dec 1998 01:01:01 -0500 Message-Id: <199812060601.BAA03948@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: RedHat|ContribNet In-reply-to: Your message of "Sat, 05 Dec 1998 21:48:59 PST." <19981205214859.B18442@molehill.org> Date: Sun, 06 Dec 1998 01:01:01 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I haven't seen anyone else volunteer to package scwm up for RHCN, since Maciej > first mentioned it several weeks ago, and I think it's vitally important that > someone do this. > > I have some experience writing RPM spec files, so I'm in the process of > signing up to do it now, but I will GLADLY step aside if/when someone with > either more experience or more time volunteers. > > My current thinking is to have two packages to choose from, 'scwm' and > 'scwm-snap', with versions like 'scwm-0.9-1' and 'scwm-snap-19981205-1', > with snapshots made available 'when it seems right' - when new features are > available and it's not crashing (for me) on a daily basis. > > Any objections? None from me, this sounds great. It's also possible someone will Thanks for knocking another item off my pre-release TODO list (items are actually getting removed fater than they are getting added now, wow.) - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 01:20:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id BAA04255 for scwm-discuss-outgoing; Sun, 6 Dec 1998 01:20:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id BAA04252 for ; Sun, 6 Dec 1998 01:20:40 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA24697; Sun, 6 Dec 98 01:18:51 EST Received: (qmail 18750 invoked by uid 501); 6 Dec 1998 06:18:41 -0000 Message-Id: <19981205221841.A18670@molehill.org> Date: Sat, 5 Dec 1998 22:18:41 -0800 From: Todd Larason To: scwm-discuss list Subject: scwm.elc in prepackaged binaries Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 X-Kibo: What they call insanity and zumfing can teach us how to live. X-Kibo: Reach out with your vibrations and listen to the the total of all forms of vril. X-Kibo: Emotions can teach us how to shine. Sender: owner-scwm-discuss@mit.edu Precedence: bulk scwm.elc presents a problem for a precompiled binary build (like an RPM or .deb package). A .elc created with (GNU) Emacs can't be used with XEmacs, and I assume not vice versa. Are there any problems other than a mild speed decrease, in shipping only the .el form? It seems to work for me (XEmacs 20.4). -- ICQ UIN: 121770563 From owner-scwm-discuss@mit.edu Sun Dec 6 02:09:44 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04631 for scwm-discuss-outgoing; Sun, 6 Dec 1998 02:09:44 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA04628 for ; Sun, 6 Dec 1998 02:09:22 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA28346; Sun, 6 Dec 98 02:07:29 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id CAA13216; Sun, 6 Dec 1998 02:07:19 -0500 Message-Id: <199812060707.CAA13216@w20-575-39.mit.edu> To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: RedHat|ContribNet In-Reply-To: Your message of "Sun, 06 Dec 1998 01:01:01 EST." <199812060601.BAA03948@vicarious-existence.mit.edu> Date: Sun, 06 Dec 1998 02:07:19 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mstachow@mit.edu writes: > > > None from me, this sounds great. It's also possible someone will > Argh, I meant to say, "It's also possible someone else will be willing to take over once the spec file exists." But while we're on this topic - I think it could be useful to keep various package control files for scwm (.spec, Debian package-related files, FreeBSD port/package stuff, solaris package stuff, whatever) in CVS. It would probably make it easier to track changes, and allow anyone with the inclination to come up with updates for their particular system's package stuff to track between-release development, rather than placing the whole burden on one maintainer to do the work whenever a release comes out. Package maintainers who think this might be good (I know there's a debian package and I've seen talk of a FreeBSD port but I'm not sure if one exists currently) should feel free to submit the relevant stuff. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 02:12:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA04649 for scwm-discuss-outgoing; Sun, 6 Dec 1998 02:12:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA04646 for ; Sun, 6 Dec 1998 02:12:05 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA18658; Sun, 6 Dec 98 02:09:54 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id CAA13242; Sun, 6 Dec 1998 02:10:07 -0500 Message-Id: <199812060710.CAA13242@w20-575-39.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: Your message of "Sat, 05 Dec 1998 22:18:41 PST." <19981205221841.A18670@molehill.org> Date: Sun, 06 Dec 1998 02:10:07 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > scwm.elc presents a problem for a precompiled binary build (like an RPM or > .deb package). A .elc created with (GNU) Emacs can't be used with XEmacs, an > d > I assume not vice versa. > > Are there any problems other than a mild speed decrease, in shipping only the > .el form? It seems to work for me (XEmacs 20.4). No, the .el should work everywhere. I think Debian has a mechanism in their distribution to install and compile an .el file for use with all installed Emacs packages automatically, but I doubt Red Hat has anything similar. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 02:45:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA08097 for scwm-discuss-outgoing; Sun, 6 Dec 1998 02:45:53 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA08094 for ; Sun, 6 Dec 1998 02:45:50 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA20810; Sun, 6 Dec 98 02:43:39 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id CAA19464 for ; Sun, 6 Dec 1998 02:43:52 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id CAA26496 for ; Sun, 6 Dec 1998 02:43:51 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id CAA13949; Sun, 6 Dec 1998 02:43:51 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13930.13750.756280.45843@horus.cs.cornell.edu> Date: Sun, 6 Dec 1998 02:43:50 -0500 (EST) To: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: <199812060710.CAA13242@w20-575-39.mit.edu> References: <19981205221841.A18670@molehill.org> <199812060710.CAA13242@w20-575-39.mit.edu> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Dec 6, Maciej Stachowiak wrote: > No, the .el should work everywhere. I think Debian has a mechanism in > their distribution to install and compile an .el file for use with all > installed Emacs packages automatically, but I doubt Red Hat has > anything similar. Isn't this easy to do to with an installation script that will check if either emacs or xemacs packages exist, and in each case - compile the file to the appropriate site-lisp directory? (not that I know much about creating rpm's, I just know that they have installation scripts). -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Sun Dec 6 03:23:34 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA13178 for scwm-discuss-outgoing; Sun, 6 Dec 1998 03:23:34 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA13175 for ; Sun, 6 Dec 1998 03:23:32 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA03398; Sun, 6 Dec 98 03:21:42 EST Received: (qmail 22293 invoked by uid 501); 6 Dec 1998 08:21:35 -0000 Message-Id: <19981206002134.A22250@molehill.org> Date: Sun, 6 Dec 1998 00:21:34 -0800 From: Todd Larason To: Eli Barzilay , scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries References: <19981205221841.A18670@molehill.org> <199812060710.CAA13242@w20-575-39.mit.edu> <13930.13750.756280.45843@horus.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <13930.13750.756280.45843@horus.cs.cornell.edu>; from Eli Barzilay on Sun, Dec 06, 1998 at 02:43:50AM -0500 X-Kibo: Relaxation is like a spider's web. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981206, Eli Barzilay wrote: > Isn't this easy to do to with an installation script that will check if either > emacs or xemacs packages exist, and in each case - compile the file to the > appropriate site-lisp directory? (not that I know much about creating rpm's, I > just know that they have installation scripts). Hmm, that is an option. Does anyone know if Emacs deals any better with an XEmacs-compiled scwm.elc than vice versa? -- ICQ UIN: 44125380 From owner-scwm-discuss@mit.edu Sun Dec 6 03:32:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA14147 for scwm-discuss-outgoing; Sun, 6 Dec 1998 03:32:59 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA14144 for ; Sun, 6 Dec 1998 03:32:54 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA03951; Sun, 6 Dec 98 03:31:05 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id DAA20299; Sun, 6 Dec 1998 03:30:50 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id DAA27272; Sun, 6 Dec 1998 03:30:48 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id DAA14134; Sun, 6 Dec 1998 03:30:49 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13930.16568.704414.252138@horus.cs.cornell.edu> Date: Sun, 6 Dec 1998 03:30:48 -0500 (EST) To: Todd Larason Cc: Eli Barzilay , scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: <19981206002134.A22250@molehill.org> References: <19981205221841.A18670@molehill.org> <199812060710.CAA13242@w20-575-39.mit.edu> <13930.13750.756280.45843@horus.cs.cornell.edu> <19981206002134.A22250@molehill.org> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Dec 6, Todd Larason wrote: > Hmm, that is an option. Does anyone know if Emacs deals any better with an > XEmacs-compiled scwm.elc than vice versa? I just tried loading my Emacs-compiled scwm.elc into xemacs, then opened my .scwmrc and evaluating an expression with scwm-eval last. I didn't see any problems at all (Emacs 20.3 & XEmacs 20.4). -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Sun Dec 6 03:35:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA14190 for scwm-discuss-outgoing; Sun, 6 Dec 1998 03:35:53 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA14175; Sun, 6 Dec 1998 03:34:54 -0500 Message-Id: <199812060834.DAA14175@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-reply-to: Your message of "Sun, 06 Dec 1998 00:21:34 PST." <19981206002134.A22250@molehill.org> Date: Sun, 06 Dec 1998 03:34:43 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981206, Eli Barzilay wrote: > > Isn't this easy to do to with an installation script that will check if either > > emacs or xemacs packages exist, and in each case - compile the file to the > > appropriate site-lisp directory? (not that I know much about creating rpm's, I > > just know that they have installation scripts). > > Hmm, that is an option. Does anyone know if Emacs deals any better with an > XEmacs-compiled scwm.elc than vice versa? I am pretty sure scwm.el will lose either way if compiled for the wrong emacs - I don't hack it myself, but it has checks for both FSF-Emacs-isms and XEmacs-isms. It might be good to have an install script that checks for both emacsen, but then you lose if you install an Emacs after installing scwm, unless you have a complicated but complete solution to this problem like Debian does. All in all I'd say it's best to install the uncompiled version somewhere reachable by any emacs, possibly compile to match found emacsen, and just not worry about the user installing a new emacs until and unless Red Hat comes up with a general solution to this. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 03:36:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA14193 for scwm-discuss-outgoing; Sun, 6 Dec 1998 03:36:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA14186 for ; Sun, 6 Dec 1998 03:35:23 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA04078; Sun, 6 Dec 98 03:33:25 EST Received: (qmail 22378 invoked by uid 501); 6 Dec 1998 08:33:17 -0000 Message-Id: <19981206003317.A22354@molehill.org> Date: Sun, 6 Dec 1998 00:33:17 -0800 From: Todd Larason To: Eli Barzilay Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries References: <19981205221841.A18670@molehill.org> <199812060710.CAA13242@w20-575-39.mit.edu> <13930.13750.756280.45843@horus.cs.cornell.edu> <19981206002134.A22250@molehill.org> <13930.16568.704414.252138@horus.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <13930.16568.704414.252138@horus.cs.cornell.edu>; from Eli Barzilay on Sun, Dec 06, 1998 at 03:30:48AM -0500 X-Kibo: Let's support the ideas of the Bible! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981206, Eli Barzilay wrote: > On Dec 6, Todd Larason wrote: > > Hmm, that is an option. Does anyone know if Emacs deals any better with an > > XEmacs-compiled scwm.elc than vice versa? > > I just tried loading my Emacs-compiled scwm.elc into xemacs, then opened my > .scwmrc and evaluating an expression with scwm-eval last. I didn't see any > problems at all (Emacs 20.3 & XEmacs 20.4). The problem I always see is with C-h C-s, with Emacs' thing-at-point not existing in XEmacs. -- ICQ UIN: 35696413 From owner-scwm-discuss@mit.edu Sun Dec 6 03:44:15 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA14567 for scwm-discuss-outgoing; Sun, 6 Dec 1998 03:44:15 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA14563 for ; Sun, 6 Dec 1998 03:44:14 -0500 Received: from W20-575-39.MIT.EDU by MIT.EDU with SMTP id AA04593; Sun, 6 Dec 98 03:42:25 EST Received: by w20-575-39.mit.edu (SMI-8.6/4.7) id DAA13394; Sun, 6 Dec 1998 03:42:14 -0500 Message-Id: <199812060842.DAA13394@w20-575-39.mit.edu> To: Eli Barzilay Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: Your message of "Sun, 06 Dec 1998 03:30:48 EST." <13930.16568.704414.252138@horus.cs.cornell.edu> Date: Sun, 06 Dec 1998 03:42:14 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk eli@cs.cornell.edu writes: > On Dec 6, Todd Larason wrote: > > Hmm, that is an option. Does anyone know if Emacs deals any better with a > n > > XEmacs-compiled scwm.elc than vice versa? > > I just tried loading my Emacs-compiled scwm.elc into xemacs, then opened my > .scwmrc and evaluating an expression with scwm-eval last. I didn't see any > problems at all (Emacs 20.3 & XEmacs 20.4). > I don't know if we should count on that, it's been broken both ways in the past and therefore probably will be again in the future. Also Emacs 20.x had some features for a while that XEmacs didn't, I'm not sure if absence of these would show up at butecode load time, so they may still be missing. Most notable was the hyperlinked help stuff. I also recall XEmacs versions of some functions having different and surprising behavior compared to the Emacs versions. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 04:25:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id EAA14985 for scwm-discuss-outgoing; Sun, 6 Dec 1998 04:25:25 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id EAA14982 for ; Sun, 6 Dec 1998 04:25:24 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA06749; Sun, 6 Dec 98 04:23:35 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id EAA20996; Sun, 6 Dec 1998 04:23:25 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id EAA28100; Sun, 6 Dec 1998 04:23:22 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id EAA14147; Sun, 6 Dec 1998 04:23:23 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13930.19722.334823.676091@horus.cs.cornell.edu> Date: Sun, 6 Dec 1998 04:23:22 -0500 (EST) To: Todd Larason , Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: <19981206003317.A22354@molehill.org> References: <19981206002134.A22250@molehill.org> <199812060834.DAA14175@vicarious-existence.mit.edu> <13930.16568.704414.252138@horus.cs.cornell.edu> <199812060842.DAA13394@w20-575-39.mit.edu> <19981205221841.A18670@molehill.org> <199812060710.CAA13242@w20-575-39.mit.edu> <13930.13750.756280.45843@horus.cs.cornell.edu> <19981206003317.A22354@molehill.org> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Dec 6, Todd Larason wrote: > The problem I always see is with C-h C-s, with Emacs' thing-at-point not > existing in XEmacs. Can you tell me how you get to use this function so I can test it? On Dec 6, Maciej Stachowiak wrote: > I don't know if we should count on that, it's been broken both ways in > the past and therefore probably will be again in the future. > > Also Emacs 20.x had some features for a while that XEmacs didn't, I'm > not sure if absence of these would show up at butecode load time, so > they may still be missing. Most notable was the hyperlinked help > stuff. > > I also recall XEmacs versions of some functions having different and > surprising behavior compared to the Emacs versions. I don't think that there's any problem as long as they both use the same byte code, and I suppose that it is safe to assume that it will stay the same since if it doesn't, there will be enough people to make it the same. I think that the main point is that as long as the compiled code is ok, the rest of the problems should be solved in the code - not using different compiled results. I saw that there's only two places in the file that mention xemacs/emacs things, the one at the bottom shouldn't make any problems, but the thing-at-point thing is a possible problem since it compiles differently. I think that the following should work fine on both. Not sure, since I don't know how you get to actually use this piece of code. ------------------------------------------------------------------------------- (defun scwm-symbol-at-point () "Return symbol at point; look back if not found." (or (if (fboundp 'thing-at-point) (thing-at-point 'symbol) (progn (require 'id-select) (let ((zz (id-select-symbol (point)))) (when zz (buffer-substring-no-properties (car zz) (cdr zz)))))) (save-excursion (skip-syntax-backward "^w") (unless (bobp) (backward-char 1)) (thing-at-point 'symbol)) "")) ------------------------------------------------------------------------------- -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Sun Dec 6 05:22:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id FAA15269 for scwm-discuss-outgoing; Sun, 6 Dec 1998 05:22:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id FAA15266 for ; Sun, 6 Dec 1998 05:22:48 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA09167; Sun, 6 Dec 98 05:20:57 EST Received: (qmail 24813 invoked by uid 501); 6 Dec 1998 10:20:53 -0000 Message-Id: <19981206022052.A24794@molehill.org> Date: Sun, 6 Dec 1998 02:20:52 -0800 From: Todd Larason To: scwm-discuss list Subject: easier-to-use background interface Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Kibo: Language is what it appears. Sender: owner-scwm-discuss@mit.edu Precedence: bulk one item on the release-todo is an easier-to-use interface to per-desktop backgrounds. Is something like this what you have in mind? (use-modules (app scwm background)) (define desktop-background-hooked #f) (define desktop-backgrounds #f) (define-public (set-background! arg) (cond ((string? arg) (if (make-image arg) (set! arg (make-image arg)) (if (make-color arg) (set! arg (make-color arg)))))) (cond ((color? arg) (set-background-color! arg)) ((image? arg) (set-background-image! arg)) ((not arg) (reset-background!)) ((list? arg) (apply set-background-image! arg)))) (define (desktop-background-hook newdesk olddesk) (cond ((list? desktop-backgrounds) (let ((first (car desktop-backgrounds))) (cond ((and (pair? first) (number? (car first))) (let ((entry (assq newdesk desktop-backgrounds))) (cond (entry (set-background! (cdr entry)))))) (else (set-background! (list-ref desktop-backgrounds newdesk)))))))) (define-public (set-desktop-backgrounds! lst) (set! desktop-backgrounds lst) (cond ((not desktop-background-hooked) (add-hook! change-desk-hook desktop-background-hook) (set! desktop-background-hooked #t)))) This allows things like: (set-desktop-backgrounds '("yellow" "red" "desk.xpm" '("slate.xpm" tiled) #f premade-image)) (set-desktop-backgrounds '((0 . "yellow") (1 . "red") (2 . "desk.xpm") (3 . '("slate.xpm" tiled)) (5 . premade-image))) (although both of those will be slow switching to desks 0-3) (set-desktop-backgrounds `((-1 . ,(make-color "green")) (-5 . ,(make-image "desk.xpm")) (3 . '(,(make-image "slate.xpm") tiled)))) Is this worth filing the rough edges off of, or was something else completely desired? -- ICQ UIN: 105091387 From owner-scwm-discuss@mit.edu Sun Dec 6 07:50:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id HAA15851 for scwm-discuss-outgoing; Sun, 6 Dec 1998 07:50:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id HAA15848 for ; Sun, 6 Dec 1998 07:50:14 -0500 Received: from sanjuan.cs.washington.edu by MIT.EDU with SMTP id AA15349; Sun, 6 Dec 98 07:48:22 EST Received: from localhost (jwnichls@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id EAA13991; Sun, 6 Dec 1998 04:48:07 -0800 (PST) Date: Sun, 6 Dec 1998 04:48:06 -0800 (PST) From: Jeffrey Nichols To: Maciej Stachowiak Cc: Greg Badros , scwm-discuss@mit.edu Subject: Re: message-window interface and features In-Reply-To: <199812052331.SAA04518@M66-080-21.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk > > Right now if you (use-modules (app scwm standard-move-resize-message-window) > > then you get all interactive moves and resizes using a message window. > > The sub-modules are separated so they could be used independently, but > > the above module is what I added to the .scwmrcs. > > > > Gotcha. What I'd like to have happen (as described in another message) > is that all this stuff should live in one module, and there are > splicit calls to enable and disable message windows for moving and/or > resizing (I don't even mind if both are turned on by default when you > use the module). That way, you have fine-grained behavior control. This seems like a good idea to me. > > 1) the default attributes for a new message-window are copied from the > > Scr struct, and there is no way to control those values (in particular, > > display-message-window-briefly uses those defaults). Perhaps we should > > have a default message-window object whose attributes are cloned, then > > permit changing of those attributes to control newly constructed > > message-windows. > > That's plausible, or else we could add getters and setters for the > defaults, or have message-window styles similar to window-styles and > my proposed analogous menu-styles (though that may be overkill). Getters and setters for the defaults is what I'd probably do, although I don't know much about the styles stuff. It seems to me that it might be possible to make them work with window-styles directly rather creating a whole new style mechanism. > > 2) when a message-window is shown, but then the object is no longer > > referenceable, there is no way to hide that message-window, or otherwise > > talk about it. (Jeff, I added a scm_protect_object in show, and > > scm_unprotect_object in hide to avoid core dumping if the message-window > > is GC'd while the window is still up). One possibility is hide message > > window objects when they are freed. This is a bit weird since the GC > > runs at an arbitrary time, but at least makes sure that there aren't > > message-windows that cannot be removed from display. Also, as far as I > > can figure, if you lose a handle on a message window that is displayed, > > your code is buggy. Another possibility would be to keep a list of > > message-windows that are currently shown. Then one could always iterate > > over the message-windows. This functionality could be written > > completely in scheme using wrappers over m-w-show! and m-w-hide!. > > > > I think a list of shown windows is good. Let's see, scm_protect_object > and scm_unprotect_object I could go either way on this. It seems to me that you shouldn't be losing your window handles in the first place, so giving people a way out might encourage poor coding. Of course, the list of shown windows would be good for other things potentially too. Sounds like an easy thing to add, so we should probably go for it. > > 3) The C primitives should be in a dynamically-loadable module > > > > Agreed, I don't think this is something we need to hugely worry about > though - I am thinking of drawing up a list of all the stuff in core > that I think should go into a module and discuss which code this is > feasible for and what code it is actually a good idea for. I was going to do this so that I could learn how to write dynamic C modules. > > > Is Jeff on scwm-discuss? If not, what's his email address so we can > > > discuss this? I lurk, but I'm here. -Jeff --- Jeff W. Nichols "There are over forty million lines of code in Windows, UW CSE and I love every one of them." jwnichls@cs - Jean-Louis Gassee CEO, Be Inc. From owner-scwm-discuss@mit.edu Sun Dec 6 12:27:45 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA16923 for scwm-discuss-outgoing; Sun, 6 Dec 1998 12:27:45 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA16920 for ; Sun, 6 Dec 1998 12:27:43 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA26232; Sun, 6 Dec 98 12:25:25 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA10708; Sun, 6 Dec 1998 09:25:37 -0800 (PST) To: Jeffrey Nichols Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: message-window interface and features References: From: Greg Badros Date: 06 Dec 1998 09:25:36 -0800 In-Reply-To: Jeffrey Nichols's message of "Sun, 6 Dec 1998 04:48:06 -0800 (PST)" Message-Id: Lines: 34 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Jeffrey Nichols writes: > Maciej wrote: > > That's plausible, or else we could add getters and setters for the > > defaults, or have message-window styles similar to window-styles and > > my proposed analogous menu-styles (though that may be overkill). > > Getters and setters for the defaults is what I'd probably do, > although I don't know much about the styles stuff. It seems to me that it > might be possible to make them work with window-styles directly rather > creating a whole new style mechanism. I don't like the idea of introducing new getter and setter primitives for defaults when we've already got getter and setters for objects of that type. Then we'd have (nearly) duplicate code with no good way to keep the changes in synch. (Or maybe I'm mis-understanding the suggestion?) > Maciej wrote: > > I think a list of shown windows is good. Let's see, scm_protect_object > > and scm_unprotect_object Is this another trailing off the end disappearing act? > I could go either way on this. It seems to me that you shouldn't > be losing your window handles in the first place, so giving people a way > out might encourage poor coding. Of course, the list of shown windows > would be good for other things potentially too. Sounds like an easy thing > to add, so we should probably go for it. Sure... Greg From owner-scwm-discuss@mit.edu Sun Dec 6 12:38:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA17005 for scwm-discuss-outgoing; Sun, 6 Dec 1998 12:38:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA17002 for ; Sun, 6 Dec 1998 12:38:31 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27507; Sun, 6 Dec 98 12:36:14 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA10711; Sun, 6 Dec 1998 09:35:35 -0800 (PST) To: Stefan Monnier Cc: scwm-discuss@mit.edu Subject: Re: kept-on-top windows rising over menus References: <199812060324.WAA04714@M66-080-21.mit.edu> <5lemqdyhk1.fsf@tequila.cs.yale.edu> From: Greg Badros Date: 06 Dec 1998 09:35:34 -0800 In-Reply-To: Stefan Monnier's message of "06 Dec 1998 00:18:22 -0500" Message-Id: Lines: 29 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Stefan Monnier writes: > >>>>> "Maciej" == Maciej Stachowiak writes: > > Another possibility is to eliminate this handling of VisibilityNotify. > > That's what I'd advise: in my ctwm patch that provides a similar feature, > I haven't needed to play with this. Furthermore, it seems kind of dangerous: > what if two `kept-on-top' windows stomp on each other ? Are they going to keep > getting VisibilityNotify events and raise themselves indefinitely ? > > > Stefan > > PS: also in ctwm I couldn't use such an event because I had to deal with more > than just `kept-on-top' (I kept several "layers" from -8 (kept-on-bottom) > to 8 (kept-on-top)). As a bit of an aside that is more relevant as we start thinking about changing the stacking order code more and more, I've added z-values (similar to what you call layers) to the window structure that are constrainable variables. Thus, I can say "I want my emacs and xterm to be at the same z-value" and thus raising one will raise the other. (Right now the restacking primitives act independently of the z-values because I never got around to changing them. Also, I never quite figured out how I thought the z-values should change on arbitrary raise-to-front and push-to-back commands. Greg From owner-scwm-discuss@mit.edu Sun Dec 6 12:39:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id MAA17018 for scwm-discuss-outgoing; Sun, 6 Dec 1998 12:39:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id MAA17015 for ; Sun, 6 Dec 1998 12:39:11 -0500 Received: from elwha.cs.washington.edu by MIT.EDU with SMTP id AA27607; Sun, 6 Dec 98 12:36:55 EST Received: (gjb@localhost) by elwha.cs.washington.edu (8.8.5+CS/7.2ws+) id JAA10714; Sun, 6 Dec 1998 09:37:03 -0800 (PST) To: Todd Larason Cc: scwm-discuss list Subject: Re: RedHat|ContribNet References: <19981205214859.B18442@molehill.org> From: Greg Badros Date: 06 Dec 1998 09:37:03 -0800 In-Reply-To: Todd Larason's message of "Sat, 5 Dec 1998 21:48:59 -0800" Message-Id: Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > I haven't seen anyone else volunteer to package scwm up for RHCN, since Maciej > first mentioned it several weeks ago, and I think it's vitally important that > someone do this. > > I have some experience writing RPM spec files, so I'm in the process of > signing up to do it now, but I will GLADLY step aside if/when someone with > either more experience or more time volunteers. > > My current thinking is to have two packages to choose from, 'scwm' and > 'scwm-snap', with versions like 'scwm-0.9-1' and 'scwm-snap-19981205-1', > with snapshots made available 'when it seems right' - when new features are > available and it's not crashing (for me) on a daily basis. > > Any objections? I'm all for it. For lots of people, if it isn't available as an RPM, it isn't getting installed. I think with Scwm-0.9 we'll be ready to broaden our audience a bit. Greg From owner-scwm-discuss@mit.edu Sun Dec 6 14:59:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA17856 for scwm-discuss-outgoing; Sun, 6 Dec 1998 14:59:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA17850 for ; Sun, 6 Dec 1998 14:58:59 -0500 Received: from M66-080-3.MIT.EDU by MIT.EDU with SMTP id AA15548; Sun, 6 Dec 98 14:56:41 EST Received: by M66-080-3.mit.edu (SMI-8.6/4.7) id OAA28075; Sun, 6 Dec 1998 14:56:54 -0500 Message-Id: <199812061956.OAA28075@M66-080-3.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: easier-to-use background interface In-Reply-To: Your message of "Sun, 06 Dec 1998 02:20:52 PST." <19981206022052.A24794@molehill.org> Date: Sun, 06 Dec 1998 14:56:54 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > one item on the release-todo is an easier-to-use interface to per-desktop > backgrounds. > > Is something like this what you have in mind? > Yes, that is pretty similar to what I had in mind. On thing I wanted to do is use another style-like interface (OK, call me obsessed, but I think it is a useful design patter for a window manager config file, since it looks declarative), so for your below > (set-desktop-backgrounds '((0 . "yellow") > (1 . "red") > (2 . "desk.xpm") > (3 . '("slate.xpm" tiled)) > (5 . premade-image))) I would have written (background-style 0 #:color "yellow") (background-style 1 #:color "red") (background-style 1 #:image "desk.xpm") (background-style 3 #:image "slate.xpm" #:image-style 'tiled) ;; or maybe (background-style 3 #:tiled-image "slate.xpm") (background-style 5 #:image premade-image) I'd also want a way to set the default background, if you are on a desk other than the specified ones: (background-style #t #:color "black") Arguably this syntax is excessively verbose, but I think it adds clarity. Perhaps it would be best to provide this _and_ something like set-desktop-backgrounds. I think explicitly specifying color or image is good though, as it resolves potential ambiguities between color names and image names. Either way I think it is very important to preload the images at least, and maybe the colors. Right now, loading a big image into scwm is butt-slow (an Imlib module should help as soon as someone has time to do it, but it will still be noticeable for, say a 1280x1024), and the main advantage of built-in background handling to my mind was that it would be easy to keep a set of images preloaded to switch on the fly. Another feature I was thinking of adding at the higher level is some interaction with timer hooks so you can have background images that periodically change, though I haven't thought of a nice syntax for that yet. Admittedly this would be a gratuitous feature, but I think it is a nice way to show off the capabilities scwm gains from having a powerful configuration language. > Is this worth filing the rough edges off of, or was something else > completely desired? Yes, it is. Modulo my slightly different suggested syntax (which would I guess require keeping around a hash table from desk numbers to background specs) that's exactly what I had in mind. If you don't get a chance to polish it up, do you mind if I start with your code and do so? - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 15:12:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA18031 for scwm-discuss-outgoing; Sun, 6 Dec 1998 15:12:05 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA18028 for ; Sun, 6 Dec 1998 15:12:04 -0500 Received: from quackerjack.cc.vt.edu by MIT.EDU with SMTP id AA17274; Sun, 6 Dec 98 15:09:47 EST Received: from sable.cc.vt.edu (sable.cc.vt.edu [128.173.16.30]) by quackerjack.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA18399 for ; Sun, 6 Dec 1998 15:10:00 -0500 (EST) Received: from gingermelt.async.vt.edu (gingermelt.async.vt.edu [128.173.18.125]) by sable.cc.vt.edu (8.8.8/8.8.8) with ESMTP id PAA21002 for ; Sun, 6 Dec 1998 15:09:59 -0500 (EST) Received: from localhost (cstruble@localhost) by gingermelt.async.vt.edu (8.9.1/8.9.1) with ESMTP id PAA29359 for ; Sun, 6 Dec 1998 15:11:17 -0500 (EST) (envelope-from cstruble@vt.edu) X-Authentication-Warning: quirk.struble.c: cstruble owned process doing -bs Date: Sun, 6 Dec 1998 20:11:16 +0000 () From: Craig Struble X-Sender: cstruble@quirk.struble.c To: scwm-discuss@mit.edu Subject: Typo and binary modules Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Ok, I'm happily running scwm again. The obligatory changed.c is: char *szRepoLastChanged = "Sun Dec 6 03:38:08 EST 1998 -- $Revision: 1.1023 $"; I ran into one really minor compilation problem. In scwm.c, there is a #Ifdef instead of #ifdef on line 496. I'm having many problems with the change in location for binary modules. First, there's an installation problem, where the .la files are symbolically linked to where the modules are installed. If the symbolic link exists from a previous installation, the installation fails. Maybe using `ln -sf' is more appropriate than `ln -s', or just ignore the error. Second, the pie-menus module doesn't get its .la file installed in the module directory (it is installed in the library directory where the shared libraries are). Finally, on FreeBSD 3.0, just having links to the .la files (and .so files) in the module directory doesn't work. I had to put symbolic links to the .so.x.x files as well before everything was happy. I don't know enough about the particulars of FreeBSD's shared library implementation or guile 1.3 port to know why the .so.x.x files need to be there too, but I'll be happy to try to figure it out with some direction. Thanks for fixing the application menu/kept-on-top conflict! That makes a world of difference. See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Sun Dec 6 15:51:11 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA18285 for scwm-discuss-outgoing; Sun, 6 Dec 1998 15:51:11 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA18282 for ; Sun, 6 Dec 1998 15:51:10 -0500 Received: from M66-080-3.MIT.EDU by MIT.EDU with SMTP id AA22407; Sun, 6 Dec 98 15:48:52 EST Received: by M66-080-3.mit.edu (SMI-8.6/4.7) id PAA28329; Sun, 6 Dec 1998 15:49:04 -0500 Message-Id: <199812062049.PAA28329@M66-080-3.mit.edu> To: Craig Struble Cc: scwm-discuss@mit.edu Subject: Re: Typo and binary modules In-Reply-To: Your message of "Sun, 06 Dec 1998 20:11:16 GMT." Date: Sun, 06 Dec 1998 15:49:03 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > Ok, I'm happily running scwm again. The obligatory changed.c is: > > char *szRepoLastChanged = "Sun Dec 6 03:38:08 EST 1998 -- $Revision: 1.1023 > $"; > > I ran into one really minor compilation problem. In scwm.c, there is a > #Ifdef instead of #ifdef on line 496. > Whoops, will fix. > I'm having many problems with the change in location for binary modules. > First, there's an installation problem, where the .la files are > symbolically linked to where the modules are installed. If the symbolic > link exists from a previous installation, the installation fails. Maybe > using `ln -sf' is more appropriate than `ln -s', or just ignore the error. > It tries to rm -f the files before linking them, I wonder why it does not work. Is ln -sf portable enough to use in a makefile? > Second, the pie-menus module doesn't get its .la file installed in the > module directory (it is installed in the library directory where the > shared libraries are). > Will fix shortly. > Finally, on FreeBSD 3.0, just having links to the .la files (and .so > files) in the module directory doesn't work. I had to put symbolic links > to the .so.x.x files as well before everything was happy. I don't know > enough about the particulars of FreeBSD's shared library implementation or > guile 1.3 port to know why the .so.x.x files need to be there too, but > I'll be happy to try to figure it out with some direction. > Hmm, I will revert the change if we can't get this working in time for the release. In the meantime, could you show me what the error message is? I _think_ Guile should be able to load a shared library from only the .la file on any platform, but if this is not the case, trying to link all the files generated for a shared library on any given platform is likely to be a losing battle. But I would like to diagnose it. For starters, could you send me an ls -l of the binary module directory and of the scheme module directory (inside app/scwm/ where all the modules actually are) and the error messages when you try to load one of the binary modules? We can take this off the list so as not to bother the list with the details. > Thanks for fixing the application menu/kept-on-top conflict! That makes a > world of difference. You're welcome. Thanks for all your bug reports, they are extremely helpful. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 16:34:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id QAA18584 for scwm-discuss-outgoing; Sun, 6 Dec 1998 16:34:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id QAA18581 for ; Sun, 6 Dec 1998 16:34:39 -0500 Received: from M66-080-3.MIT.EDU by MIT.EDU with SMTP id AA28403; Sun, 6 Dec 98 16:32:22 EST Received: by M66-080-3.mit.edu (SMI-8.6/4.7) id QAA28460; Sun, 6 Dec 1998 16:32:35 -0500 Message-Id: <199812062132.QAA28460@M66-080-3.mit.edu> To: scwm-discuss@mit.edu Subject: combining placement procs Date: Sun, 06 Dec 1998 16:32:34 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk So I'm planning to remove the automatic desk-switching behavior when you place a window in another desk. What I'd like to do to replace that is provide a Scheme module of various placement procs: procedure: place-in-desk DESK Return a procedure which will place the window it gets passed on DESK. procedure: place-in-viewport X Y Return a procedure which will place window relative to the viewport X, Y (might have to hack some of the standard placement proces to interperate with this properly). It should probably use full screen increments rather than pixels. procedure: interactive-place #&optional (resize? $f) Return a procedure which will switch to the desk and viewport the window it gets passed is currently on and use a rubber-band interactive move to let the user place it. If the optional argument resize? is specified and true, immediately follow the move by an interactive rubber-band resize. procedure: interactive-place-and-return #&optional (resize? $f) Return a procedure which will do the same as interactive-place, then return to the original desk and viewport. procedure: place-at-point #&key offset #&key percent-offset Return a procedure which will switch desks and viewports as interactive-place above and then place the window at whatever the current cursor position happens to be. If offset is specified, it is used as a list of x,y pixel offsets to the pointer position. If percent-offset is specified, it is taken as a list of percentages of the window width and height to use. For example, (place-at-point #&key percent-offset (-50 -50)) will place the window centered at the point - possibly useful for some types of dialog boxes, but also potentially annoying. procedure: place-at-point-blind #&key offset #&key percent-offset Returns a procedure which works as place-at-point but does _not_ switch desktops or viewports at all - it places the window at the current position and then switches its desktop and viewport without showing the results. procedure: place-at-point-and-return #&key offset #&key percent-offset Return a procedure which will do the same as place-at-point, then return to the original desk and viewport. The standard placement procs are obviously still available. The problem with this design is that users will obviously want to combine these. What's a good way to do that? Should users write a lambda expression explicitly? Should there be some sort of combination-place that takes a sequence of placement procs and does them in order? Or since users might want conditionals in their placement procs, should it take (predicate consequent-place altrnative-place) triples? Any thoughts? Also, if anyone has ideas for other good placement procs let me know. I tried scouring flux.scm for placement-proc like things already but I may have missed some. Also, the place and return behavior should perhaps be generalized to work with future quasi-interactive placement methods. Another thought is that maybe place-at-point* should be merged into one thing with more keyword arguments, and same for interactive-place*, but I'm not sure if that is useful. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 17:27:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA18907 for scwm-discuss-outgoing; Sun, 6 Dec 1998 17:27:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA18904 for ; Sun, 6 Dec 1998 17:27:04 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA05956; Sun, 6 Dec 98 17:24:44 EST Received: (qmail 29006 invoked by uid 501); 6 Dec 1998 22:24:57 -0000 Message-Id: <19981206142457.A28959@molehill.org> Date: Sun, 6 Dec 1998 14:24:57 -0800 From: Todd Larason To: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: combining placement procs References: <199812062132.QAA28460@M66-080-3.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812062132.QAA28460@M66-080-3.mit.edu>; from Maciej Stachowiak on Sun, Dec 06, 1998 at 04:32:34PM -0500 X-Kibo: If Chinese restaurants could go, would the Universe, U for Unessential, be very spurious? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981206, Maciej Stachowiak wrote: > procedure: place-at-point #&key offset #&key percent-offset > > If > percent-offset is specified, it is taken as a list of percentages of > the window width and height to use. For example, (place-at-point #&key > percent-offset (-50 -50)) will place the window centered at the point It would be nice if this were consistent with the very similar message box placements, which would use (-.5 -.5) rather than (-50 -50). I have no preference which one is chosen, just that only ONE of them is. > The problem with this design is that users will obviously want to > combine these. What's a good way to do that? Should users write a > lambda expression explicitly? > Should there be some sort of > combination-place that takes a sequence of placement procs and does > them in order? Haven't you done something similar to this in winops.scm, with the window predicates? > Or since users might want conditionals in their > placement procs, should it take (predicate consequent-place > altrnative-place) triples? Could this be another meta-placement proc that takes a predicate, a placement proc for true, and an optional PP for false, and be combined like any other? (place-list (place-on-desk 3) (place-on-viewport 1 1) (place-predicate interesting-window? (interactive-place #t))) Could the blind/return/jump versions be removed (or non-primitive) and created from a (place-list (jump) (.....) (return)) form? or (jump-and-return (.....))? -- ICQ UIN: 39832472 From owner-scwm-discuss@mit.edu Sun Dec 6 19:12:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA19525 for scwm-discuss-outgoing; Sun, 6 Dec 1998 19:12:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA19522 for ; Sun, 6 Dec 1998 19:12:15 -0500 Received: from W20-575-103.MIT.EDU by MIT.EDU with SMTP id AA27683; Sun, 6 Dec 98 19:10:18 EST Received: by w20-575-103.mit.edu (950413.SGI.8.6.12/4.7) id TAA29170; Sun, 6 Dec 1998 19:10:09 -0500 Message-Id: <199812070010.TAA29170@w20-575-103.mit.edu> To: Todd Larason Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs In-Reply-To: Your message of "Sun, 06 Dec 1998 14:24:57 PST." <19981206142457.A28959@molehill.org> Date: Sun, 06 Dec 1998 19:10:09 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981206, Maciej Stachowiak wrote: > > procedure: place-at-point #&key offset #&key percent-offset > > > > If > > percent-offset is specified, it is taken as a list of percentages of > > the window width and height to use. For example, (place-at-point #&key > > percent-offset (-50 -50)) will place the window centered at the point > > It would be nice if this were consistent with the very similar message box > placements, which would use (-.5 -.5) rather than (-50 -50). I have no > preference which one is chosen, just that only ONE of them is. > You're right of course. I was actually being intellectually lazy in icking percents over fractions because I could thing of a better name for the window-proportional offset keyword argument - maybe #:proportional-offset or something? > > The problem with this design is that users will obviously want to > > combine these. What's a good way to do that? Should users write a > > lambda expression explicitly? > > > Should there be some sort of > > combination-place that takes a sequence of placement procs and does > > them in order? > > Haven't you done something similar to this in winops.scm, with the window > predicates? > Yes, I haven't shied away from creating embedded sub-languages before but I always hesitate because I don't want there to end up being too many. > > Or since users might want conditionals in their > > placement procs, should it take (predicate consequent-place > > altrnative-place) triples? > > Could this be another meta-placement proc that takes a predicate, a placement > proc for true, and an optional PP for false, and be combined like any other? > > (place-list (place-on-desk 3) (place-on-viewport 1 1) > (place-predicate interesting-window? (interactive-place #t))) > Yeah, but as I said, I worry about creating excessively complex sublanguages. What you wrote is strikingly redundant with what it is syntactic sugar for, i.e. (lambda (w) ((place-on-desk 3) w) ((place-on-viewport 1 1) w) (if (interesting-window? w) ((interactive-place #t) w))) And it's not even that much longer, although it does contain more redundant mentions of the window. On the other hand, it is much more general since you can put any control flow you want inside the lambda. I've tried to design the Scheme-level wrappers in scwm so that users hardly ever have to write lambdas but I worry that creating special-case restricted versions of lambda and if (which is what whta your place-list and place-predicate effectively are) might be going too far. I'd like to hear more thoughts on this. > Could the blind/return/jump versions be removed (or non-primitive) and create > d > from a (place-list (jump) (.....) (return)) form? or (jump-and-return > (.....))? I thought about this, but I couldn't think of a way to make this work that made me happy. The main problem is, where do you hang the data for saving the place? Using a global variable is icky, hanging it off the window is possible though cleanup won't necessarily happen then. Having the specialized versions avoids that. What I _could_ do is add a `save-place-excursion' procedure or something like that which would do the save and restore when wrapped around a placement proc (actually my implementation already has that as a macro to implement the guts of the returning versions), so I guess that could be exposed in an appropriate way, but the returning versions could still be provided for convenience. A similar thing could be done with the blind vs. non-blind versions although I think the blind version of `interactivre-place' would be well-nigh useless. I suppose that might also be true of `place-at-point-blind' but it seemed like it might be useful when I thought of it. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 19:58:12 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA19780 for scwm-discuss-outgoing; Sun, 6 Dec 1998 19:58:12 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA19777 for ; Sun, 6 Dec 1998 19:58:11 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA27711; Sun, 6 Dec 98 19:55:50 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 06 Dec 1998 19:55:58 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 06 Dec 1998 19:55:57 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id TAA03512; Sun, 6 Dec 1998 19:55:59 -0500 To: scwm-discuss@mit.edu Subject: Re: combining placement procs References: <199812062132.QAA28460@M66-080-3.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Sun, 06 Dec 1998 16:32:34 EST" Date: 06 Dec 1998 19:55:58 -0500 Message-Id: Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199812062132.QAA28460@M66-080-3.mit.edu> >>>> On the subject of "combining placement procs" >>>> Sent on Sun, 06 Dec 1998 16:32:34 EST >>>> Honorable Maciej Stachowiak writes: >> >> procedure: place-in-viewport X Y see `in-viewport' in flux.scm >> procedure: place-at-point #&key offset #&key percent-offset see `place-at-point' in flux.scm -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Isn't "Microsoft Works" an advertisement lie? From owner-scwm-discuss@mit.edu Sun Dec 6 20:03:31 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA19812 for scwm-discuss-outgoing; Sun, 6 Dec 1998 20:03:31 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA19809 for ; Sun, 6 Dec 1998 20:03:30 -0500 Received: from totoro.red-bean.com by MIT.EDU with SMTP id AA25762; Sun, 6 Dec 98 20:01:33 EST Received: (from jimb@localhost) by totoro.red-bean.com (8.8.8/8.8.8) id UAA02304; Sun, 6 Dec 1998 20:01:20 -0500 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: gnome WM spec References: <199812030308.WAA19917@M66-080-1.mit.edu> From: Jim Blandy Date: 06 Dec 1998 20:01:19 -0500 In-Reply-To: Maciej Stachowiak's message of Wed, 02 Dec 1998 22:08:02 EST Message-Id: Lines: 13 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk (Trying to decide whether I should get involved, since I probably can't handle the gnome-hackers list...) > * Chapter 1 Section 1 calls for setting the value of > _WIN_SUPPORTING_WM_CHECK to be set to the ID of a special window > created for this purpose. Is there a reason for doing this, instead of > just having the window manager set this property to nothing when it > starts up, and delete it when it exits? I can't see anywhere else in > the spec where that window is used. The nice thing about a window is it gets automatically deleted if the WM exits ungracefully. From owner-scwm-discuss@mit.edu Sun Dec 6 20:04:32 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA19820 for scwm-discuss-outgoing; Sun, 6 Dec 1998 20:04:32 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA19817 for ; Sun, 6 Dec 1998 20:04:31 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA28577; Sun, 6 Dec 98 20:02:10 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 06 Dec 1998 20:02:15 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 06 Dec 1998 20:02:15 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id UAA03518; Sun, 6 Dec 1998 20:02:16 -0500 To: Todd Larason Cc: scwm-discuss list Subject: Re: scwm.elc in prepackaged binaries References: <19981205221841.A18670@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Sat, 5 Dec 1998 22:18:41 -0800" Date: 06 Dec 1998 20:02:16 -0500 Message-Id: Lines: 47 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981205221841.A18670@molehill.org> >>>> On the subject of "scwm.elc in prepackaged binaries" >>>> Sent on Sat, 5 Dec 1998 22:18:41 -0800 >>>> Honorable Todd Larason writes: >> scwm.elc presents a problem for a precompiled binary build (like an RPM or >> .deb package). A .elc created with (GNU) Emacs can't be used with XEmacs, and >> I assume not vice versa. byte-compiled files are mutually incompatible across modern emacsen. (i.e., you cannot use x20 and x21 for e20 and e20 for x20 and x21). >> Are there any problems other than a mild speed decrease, in shipping only the >> .el form? It seems to work for me (XEmacs 20.4). this is wrong ideologically. 1. RPM provides a feature of "installation script". This should try to call `emacs' or `xemacs' (in that order - emacs is a standard part of RH, while xemacs isn't, so it's reasonable to assume that emacs is more widely used), like this: $ emacs --batch -l zz.el || xemacs --batch -l zz.el on the following ELisp code: ------------------------------ zz.el ---------------------------- (require 'cl) (let* ((dd (find-if (lambda (path) (and (string-match "site-lisp.?$" path) (not (string-match (number-to-string emacs-major-version) path)))) load-path)) (fl (expand-file-name "scwm.el" dd))) (copy-file "scwm.el" fl t t) (byte-compile-file fl)) ------------------------------ zz.el ---------------------------- 2. there are packages with Emacs lisp files, like octave; so one might get an idea from looking around - how others are handling the problem. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Stupidity, like virtue, is its own reward. From owner-scwm-discuss@mit.edu Sun Dec 6 20:16:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA19964 for scwm-discuss-outgoing; Sun, 6 Dec 1998 20:16:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA19961 for ; Sun, 6 Dec 1998 20:16:40 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA00631; Sun, 6 Dec 98 20:14:19 EST Received: (qmail 30094 invoked by uid 501); 7 Dec 1998 01:14:33 -0000 Message-Id: <19981206171433.A30061@molehill.org> Date: Sun, 6 Dec 1998 17:14:33 -0800 From: Todd Larason To: sds@goems.com Cc: scwm-discuss list Subject: Re: scwm.elc in prepackaged binaries References: <19981205221841.A18670@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sam Steingold on Sun, Dec 06, 1998 at 08:02:16PM -0500 X-Kibo: What's the opiate of my fate? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981206, Sam Steingold wrote: > 1. RPM provides a feature of "installation script". This should try to > call `emacs' or `xemacs' (in that order - emacs is a standard part of > RH, while xemacs isn't, so it's reasonable to assume that emacs is > more widely used), like this: > > $ emacs --batch -l zz.el || xemacs --batch -l zz.el I would have no problem doing this if it helped the more common case without harming the less common, but with major parts of scwm.el just not *working* in XEmacs when compiled with Emacs, I'm strongly leaning towards just installing the .el file right now. I'll plan on looking at what Octave does, though, as well as seeing if I can find somewhere to install an Emacs scwm.elc where the common RPM-packaged XEmacses won't find it. -- ICQ UIN: 110507073 From owner-scwm-discuss@mit.edu Sun Dec 6 20:21:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA20007 for scwm-discuss-outgoing; Sun, 6 Dec 1998 20:21:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA20003 for ; Sun, 6 Dec 1998 20:21:36 -0500 Received: from molehill.involved.com by MIT.EDU with SMTP id AA01302; Sun, 6 Dec 98 20:19:15 EST Received: (qmail 30117 invoked by uid 501); 7 Dec 1998 01:19:30 -0000 Message-Id: <19981206171930.B30061@molehill.org> Date: Sun, 6 Dec 1998 17:19:30 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs References: <19981206142457.A28959@molehill.org> <199812070010.TAA29170@w20-575-103.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812070010.TAA29170@w20-575-103.mit.edu>; from Maciej Stachowiak on Sun, Dec 06, 1998 at 07:10:09PM -0500 X-Kibo: All what I say and what you hear are arbitrary! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981206, Maciej Stachowiak wrote: > Yeah, but as I said, I worry about creating excessively complex > sublanguages. What you wrote is strikingly redundant with what it is > syntactic sugar for, i.e. you're absolutely right. I had been trying to 'protect' users from having to write lambda expressions, but they're going to have to do that anyway to get anything close to the full advantage of scwm, and once you've learnt to think of a function as an object that can be returned, lambda expressions are pretty simple too. > > from a (place-list (jump) (.....) (return)) form? or (jump-and-return > > (.....))? > > What I _could_ do is add a `save-place-excursion' procedure or > something like that which would do the save and restore when wrapped > around a placement proc that's what I meant with the jump-and-return example above. -- ICQ UIN: 30680014 From owner-scwm-discuss@mit.edu Sun Dec 6 21:35:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA20457 for scwm-discuss-outgoing; Sun, 6 Dec 1998 21:35:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA20448 for ; Sun, 6 Dec 1998 21:34:58 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA11335; Sun, 6 Dec 98 21:32:37 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 06 Dec 1998 21:32:47 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 06 Dec 1998 21:32:47 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id VAA03844; Sun, 6 Dec 1998 21:32:49 -0500 To: scwm-discuss list Subject: Re: scwm.elc in prepackaged binaries References: <19981205221841.A18670@molehill.org> <19981206171433.A30061@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Sun, 6 Dec 1998 17:14:33 -0800" Date: 06 Dec 1998 21:32:49 -0500 Message-Id: Lines: 32 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981206171433.A30061@molehill.org> >>>> On the subject of "Re: scwm.elc in prepackaged binaries" >>>> Sent on Sun, 6 Dec 1998 17:14:33 -0800 >>>> Honorable Todd Larason writes: >> On 981206, Sam Steingold wrote: >> > 1. RPM provides a feature of "installation script". This should try to >> > call `emacs' or `xemacs' (in that order - emacs is a standard part of >> > RH, while xemacs isn't, so it's reasonable to assume that emacs is >> > more widely used), like this: >> > >> > $ emacs --batch -l zz.el || xemacs --batch -l zz.el >> >> I would have no problem doing this if it helped the more common case without >> harming the less common, but with major parts of scwm.el just not *working* in >> XEmacs when compiled with Emacs, I'm strongly leaning towards just installing >> the .el file right now. >> >> I'll plan on looking at what Octave does, though, as well as seeing if I can >> find somewhere to install an Emacs scwm.elc where the common RPM-packaged >> XEmacses won't find it. few people install both emacsen. if you want to cater to the few that do, it should be easy to write code that figures out the directory which is in the XEmacs's load path but not in that of Emacs. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. In every non-trivial program there is at least one bug. From owner-scwm-discuss@mit.edu Sun Dec 6 22:50:16 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id WAA20855 for scwm-discuss-outgoing; Sun, 6 Dec 1998 22:50:16 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id WAA20852 for ; Sun, 6 Dec 1998 22:50:13 -0500 Received: from M66-080-3.MIT.EDU by MIT.EDU with SMTP id AA22625; Sun, 6 Dec 98 22:47:52 EST Received: by M66-080-3.mit.edu (SMI-8.6/4.7) id WAA01489; Sun, 6 Dec 1998 22:48:05 -0500 Message-Id: <199812070348.WAA01489@M66-080-3.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs In-Reply-To: Your message of "06 Dec 1998 19:55:58 EST." Date: Sun, 06 Dec 1998 22:48:05 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > >>>> In message <199812062132.QAA28460@M66-080-3.mit.edu> > >>>> On the subject of "combining placement procs" > >>>> Sent on Sun, 06 Dec 1998 16:32:34 EST > >>>> Honorable Maciej Stachowiak writes: > >> > >> procedure: place-in-viewport X Y > > see `in-viewport' in flux.scm > > >> procedure: place-at-point #&key offset #&key percent-offset > > see `place-at-point' in flux.scm > Yes, in fact that's where I got those from (modulo the desk and viewport switching behavior I described for the latter) - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 23:00:54 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA20929 for scwm-discuss-outgoing; Sun, 6 Dec 1998 23:00:54 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA20926 for ; Sun, 6 Dec 1998 23:00:53 -0500 Received: from M66-080-3.MIT.EDU by MIT.EDU with SMTP id AA10594; Sun, 6 Dec 98 22:58:56 EST Received: by M66-080-3.mit.edu (SMI-8.6/4.7) id WAA01543; Sun, 6 Dec 1998 22:58:46 -0500 Message-Id: <199812070358.WAA01543@M66-080-3.mit.edu> To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries In-Reply-To: Your message of "06 Dec 1998 21:32:49 EST." Date: Sun, 06 Dec 1998 22:58:46 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk sds@goems.com writes: > > few people install both emacsen. > > if you want to cater to the few that do, it should be easy to write code > that figures out the directory which is in the XEmacs's load path but > not in that of Emacs. > People who run multi-user systems definitely do, for instance. If I installed XEmacs on mu box (probably will at some point once it is on the net again) I definitely would not remove Emacs. - Maciej From owner-scwm-discuss@mit.edu Sun Dec 6 23:32:23 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id XAA21173 for scwm-discuss-outgoing; Sun, 6 Dec 1998 23:32:23 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id XAA21170 for ; Sun, 6 Dec 1998 23:32:22 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA29356; Sun, 6 Dec 98 23:30:01 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id XAA04323 for ; Sun, 6 Dec 1998 23:30:14 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id XAA22258 for ; Sun, 6 Dec 1998 23:30:13 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id XAA14503; Sun, 6 Dec 1998 23:30:13 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13931.22996.473631.792162@horus.cs.cornell.edu> Date: Sun, 6 Dec 1998 23:30:12 -0500 (EST) To: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk It seems that a message I've sent yesterday had a mistake in my to filed. Here it is again: On Dec 6, Todd Larason wrote: > in a buffer in scwm-mode, put the cursor over an scwm-defined function name > and hit control-h control-s. The minibuffer should give you an "SCWM symbol:" > prompt with the function name filled in as a default. Hitting return there > will show you documentation on the function. > > When I accidentally get an FSF-compiled scwm.elc loaded into XEmacs, I instead > get an error about id-select not being defined. OK, so I investigated this thing, and saw that there *is* a problem loading fsf-compiled code into xemacs. I took a deep breath and jumped into the elc files to find what the problem is (xemacs complains about invalid read syntax: "#") - I finally saw that fsf compiles into code that contains #1=... #1# and xemacs won't recognize this. XEmacs compilation does not create the same things, and when I tried to find the reason I saw that the problem is with make-symbol - according to the documentation, it is supposed to create an uninterned symbol, and fsf uses #1=#:symbol for this, but xemacs is doing something different, didn't see exactly what. A dirty solution for this will be to create a different macro that will simply use a fixed-symbol - I tried this (editing fsf's byte-code result) and everything worked fine on both (except for a bug in the code I sent - thing-at-point is actually used twice). This solution can be a bit cleaner if the macro will be defined only when compiling, so it wouldn't be visible when loading the file. Also, my problem is that I didn't see any binding for C-h C-s - I tried to grep the source files but couldn't find anything - until I accidently bumped into these things in scwm.el: (define-key scwm-mode-map [(control j)] 'scwm-eval-last) ... These should be rewritten as: (define-key scwm-mode-map [(control ?j)] 'scwm-eval-last) ... so you will get the same behavior also in FSF - XEmacs recognizes the "j" symbol as the "j" character - but FSF doesn't do that (so everyone that uses fsf didn't get to use these). Using ?j works in both (tab is ok with both). If this sound ok, and if you can live with such a hack - I can can fix the whole thing to work on both and send my version. -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Mon Dec 7 02:47:41 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA22414 for scwm-discuss-outgoing; Mon, 7 Dec 1998 02:47:41 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA22411 for ; Mon, 7 Dec 1998 02:47:38 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA26907; Mon, 7 Dec 98 02:45:13 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id JAA18221; Mon, 7 Dec 1998 09:45:20 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs References: <199812062132.QAA28460@M66-080-3.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 07 Dec 1998 09:45:19 +0200 In-Reply-To: Maciej Stachowiak's message of "Sun, 06 Dec 1998 16:32:34 EST" Message-Id: Lines: 60 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > So I'm planning to remove the automatic desk-switching behavior when > you place a window in another desk. What I'd like to do to replace > that is provide a Scheme module of various placement procs: > > procedure: place-in-desk DESK > > Return a procedure which will place the window it gets passed on DESK. Do I understand this correctly? You want these procedures to return procedures instead of just doing the action? Why is that? Why do ((place-in-desk DESK) WINDOW) instead of (place-in-desk DESK WINDOW) Is it so that you can do things like: (add-hook (place-in-desk DESK) instead of: (add-hook (lambda (w) (place-in-desk DESK w))) It seems to me a minor convenience but a significant complication. Using lambdas for anonymous functions is sometimes convenient, at the expense of being verbose. If someone wants to avoid them, they can just define the procedures that they want to use. It's good that it's a little verbose & thus encourages defining procedures. Defining & using procedures is a better programming style than inserting anonymous fcns everywhere, because reuse is difficult with the latter. Once someone wants something a little complicated they should define a procedure anyway, and now the procedure will look weird: (define* (my-place &optional (window (get-window))) ((place-in-desk 3) window) ((place-in-viewport 30 30) window) ...) (add-hook my-place) You also now have the problem that to the naive user the short version, as in: (add-hook (place-in-desk DESK)) is easily confused with a macro taking code instead of a fcn evaluating it's argument which returns a fcn. This could lead to confusion when compared to: (add-hook my-place-fcn) -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Dec 7 03:09:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA22576 for scwm-discuss-outgoing; Mon, 7 Dec 1998 03:09:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA22573 for ; Mon, 7 Dec 1998 03:09:24 -0500 Received: from M38-370-12.MIT.EDU by MIT.EDU with SMTP id AA28755; Mon, 7 Dec 98 03:07:01 EST Received: by m38-370-12.mit.edu (SMI-8.6/4.7) id DAA17567; Mon, 7 Dec 1998 03:07:15 -0500 Message-Id: <199812070807.DAA17567@m38-370-12.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs In-Reply-To: Your message of "07 Dec 1998 09:45:19 +0200." Date: Mon, 07 Dec 1998 03:07:15 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk hjstein@bfr.co.il writes: > Maciej Stachowiak writes: > > > So I'm planning to remove the automatic desk-switching behavior when > > you place a window in another desk. What I'd like to do to replace > > that is provide a Scheme module of various placement procs: > > > > procedure: place-in-desk DESK > > > > Return a procedure which will place the window it gets passed on DESK. > > Do I understand this correctly? You want these procedures to return > procedures instead of just doing the action? Why is that? Why do > > ((place-in-desk DESK) WINDOW) > > instead of > > (place-in-desk DESK WINDOW) > These procedures are not intended for normal use, but rather for use as placement procedures, so you can do things like: (window-style "*" #:placement-proc (place-in-desk 12)) I don't believe any of these are useful other than as placement procs, in particular because there are ways to set a window's desk and viewport, and move it interactively already. Perhaps there should be a move-to-point but it would be pretty weird in a non-placement context (I suppose it's vaguely possible the ultra-lazy will want to create a window list menu that has moving the window to point as the action, it could spare you some dragging, so I'd consider adding it. > Is it so that you can do things like: > > (add-hook (place-in-desk DESK) > > instead of: > > (add-hook (lambda (w) (place-in-desk DESK w))) > > It seems to me a minor convenience but a significant complication. > Using lambdas for anonymous functions is sometimes convenient, at the > expense of being verbose. If someone wants to avoid them, they can > just define the procedures that they want to use. It's good that it's > a little verbose & thus encourages defining procedures. Defining & > using procedures is a better programming style than inserting > anonymous fcns everywhere, because reuse is difficult with the latter. > > Once someone wants something a little complicated they should define a > procedure anyway, and now the procedure will look weird: > > (define* (my-place &optional (window (get-window))) > ((place-in-desk 3) window) > ((place-in-viewport 30 30) window) > ...) > > (add-hook my-place) > You are right that it looks weird for doing complicated things. In fact, this is the essential point I missed - those procedures are not useful only as placement procs but also as *components* of placement procs. How about if I provide versions named `*-place' that take a window and just do the action, and ones named `*-placement' that return a function of the window for convenience? It's good for users to define their functions, but IMO it's not good for many users to have to define the same function to avoid an anonymous lambda when it could have been done for them. > You also now have the problem that to the naive user the short > version, as in: > > (add-hook (place-in-desk DESK)) > > is easily confused with a macro taking code instead of a fcn > evaluating it's argument which returns a fcn. This could lead to > confusion when compared to: > > (add-hook my-place-fcn) I think because these are meant to be used with window-style rather than add-hook this confusion will probably not arise as much. Also, there's already placement procs that are unparameterized and therefore already used in an obviously un-macro-like style. Thank you for your comments - I do agree that this was a case of going into somewhat excessive gyrations to avoid forcing the user to define procedures, and as a result made it much more annoying to do anything even slightly more complex. I think providing both the -place and -placement versions should satisfy both needs without much extra code. - Maciej From owner-scwm-discuss@mit.edu Mon Dec 7 03:46:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA23826 for scwm-discuss-outgoing; Mon, 7 Dec 1998 03:46:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id DAA23820 for ; Mon, 7 Dec 1998 03:46:00 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA02525; Mon, 7 Dec 98 03:43:35 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id KAA18513; Mon, 7 Dec 1998 10:43:36 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: combining placement procs References: <199812070807.DAA17567@m38-370-12.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 07 Dec 1998 10:43:36 +0200 In-Reply-To: Maciej Stachowiak's message of "Mon, 07 Dec 1998 03:07:15 EST" Message-Id: Lines: 72 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > How about if I provide versions named `*-place' that take a window and > just do the action, and ones named `*-placement' that return a > function of the window for convenience? I guess... But how clear is it that interactive-place does an action & interactive-placement returns a fcn which does the action? > > You also now have the problem that to the naive user the short > > version, as in: > > > > (add-hook (place-in-desk DESK)) > > > > is easily confused with a macro taking code instead of a fcn > > evaluating it's argument which returns a fcn. This could lead to > > confusion when compared to: > > > > (add-hook my-place-fcn) > > I think because these are meant to be used with window-style rather > than add-hook this confusion will probably not arise as much. Also, > there's already placement procs that are unparameterized and therefore > already used in an obviously un-macro-like style. Well, then comparing: (window-style "*" #:placement-proc (place-in-desk 12)) to: (window-style "*" #:placement-proc my-place) I suppose the "-proc" on the keyword arg should give it away, but I think that newbies would still find it confusing. If it's always going to be in a window-style call with a #:placement-proc keyword, then what about putting the complexity into window-style instead of into the fcns passed to it? Possibility 1: Placement-proc is called with window as 1st arg. Additional args can be specified in window-style as, for example: (window-style "*" #:placement-proc place-in-viewport #:placement-extra-args '(30 50)) which would cause (place-in-desk current-window 30 50) to be run when the new window is created. I think this ordering is also a little more consistent with scheme in general. vector-ref, list-ref, vector-set!, set!, etc, all take the object as the 1st argument & the additional stuff as additional arguments. So, it'd be a little more consistent for place-in-desk, place-in-viewport, interactive-place, ... to all take the window as the 1st argument. I guess it's no less verbose than (lambda (w) (place-in-viewport w 30 50)), but it avoids the lambda for the newbies & is consistent & readable. Possibility 2: I really wish I could remember what I was going to write here... :). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Dec 7 09:28:03 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA25134 for scwm-discuss-outgoing; Mon, 7 Dec 1998 09:28:03 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA25131 for ; Mon, 7 Dec 1998 09:28:01 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA12272; Mon, 7 Dec 98 09:25:34 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 07 Dec 1998 09:25:43 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 07 Dec 1998 09:25:43 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id JAA04846; Mon, 7 Dec 1998 09:25:40 -0500 To: scwm-discuss@mit.edu Subject: Re: combining placement procs References: <199812070807.DAA17567@m38-370-12.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: hjstein@bfr.co.il's message of "07 Dec 1998 10:43:36 +0200" Date: 07 Dec 1998 09:25:40 -0500 Message-Id: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: combining placement procs" >>>> Sent on 07 Dec 1998 10:43:36 +0200 >>>> Honorable hjstein@bfr.co.il (Harvey J. Stein) writes: >> Maciej Stachowiak writes: >> >> > How about if I provide versions named `*-place' that take a window and >> > just do the action, and ones named `*-placement' that return a >> > function of the window for convenience? >> >> I guess... But how clear is it that interactive-place does an action >> & interactive-placement returns a fcn which does the action? The only intuitive interface is the nipple. The rest has to be learned. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Between grand theft and a legal fee, there only stands a law degree. From owner-scwm-discuss@mit.edu Mon Dec 7 09:41:46 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA25220 for scwm-discuss-outgoing; Mon, 7 Dec 1998 09:41:46 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA25217 for ; Mon, 7 Dec 1998 09:41:45 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA17125; Mon, 7 Dec 98 09:39:18 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 07 Dec 1998 09:39:33 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 07 Dec 1998 09:39:33 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id JAA04852; Mon, 7 Dec 1998 09:39:30 -0500 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: scwm.elc in prepackaged binaries References: <199812070358.WAA01543@M66-080-3.mit.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Maciej Stachowiak's message of "Sun, 06 Dec 1998 22:58:46 EST" Date: 07 Dec 1998 09:39:30 -0500 Message-Id: Lines: 57 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <199812070358.WAA01543@M66-080-3.mit.edu> >>>> On the subject of "Re: scwm.elc in prepackaged binaries" >>>> Sent on Sun, 06 Dec 1998 22:58:46 EST >>>> Honorable Maciej Stachowiak writes: >> sds@goems.com writes: >> > >> > few people install both emacsen. >> > >> > if you want to cater to the few that do, it should be easy to write code >> > that figures out the directory which is in the XEmacs's load path but >> > not in that of Emacs. >> > >> >> People who run multi-user systems definitely do, for instance. If I >> installed XEmacs on mu box (probably will at some point once it is on >> the net again) I definitely would not remove Emacs. My statement stands: >> > it should be easy to write code that figures out the directory which >> > is in the XEmacs's load path but not in that of Emacs. -------- #!/bin/sh TMP=/tmp/eee$$; emacs --batch -l zz.el ${TMP} xemacs --batch -l xx.el ${TMP} xemacs --batch -l zz.el ${TMP} emacs --batch -l xx.el ${TMP} -------- zz.el: -------- (insert load-path) (save-buffers-kill-emacs t) -------- xx.el: -------- (require 'cl) (setq other-load-path (read (current-buffer))) (let* ((ver (format "%d.%d" emacs-major-version emacs-minor-version)) (dd (find-if (lambda (path) (and (string-match "site-lisp.?$" path) (not (string-match ver path)) (nor (member path other-load-path)))) load-path)) (fl (expand-file-name "scwm.el" dd))) (copy-file "scwm.el" fl t t) (byte-compile-file fl)) -------- -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Really cancel? [OK] [Cancel] From owner-scwm-discuss@mit.edu Tue Dec 8 08:37:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA32460 for scwm-discuss-outgoing; Tue, 8 Dec 1998 08:37:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id IAA32457 for ; Tue, 8 Dec 1998 08:36:57 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA10183; Tue, 8 Dec 98 08:34:14 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Tue, 8 Dec 1998 14:32:06 +0100 Received: from enterprise.osterwald.de (root@h52.ts1.uni-hannover.de [130.75.249.52]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id OAA20796 for ; Tue, 8 Dec 1998 14:31:56 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id LAA14503; Tue, 8 Dec 1998 11:13:03 +0100 Date: Tue, 8 Dec 1998 11:13:03 +0100 Message-Id: <199812081013.LAA14503@enterprise.osterwald.de> From: Heiko Muenkel To: scwm-discuss@mit.edu Subject: Bug in scwm 0.9 beta 1: Missing symbol gh_reverse X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H autoconf --version ------------------ Autoconf version 2.12 automake --version ------------------ automake (GNU automake) 1.2 Copyright (C) 1994, 1995, 1996, 1997 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey libtool --version ------------------ ltmain.sh (GNU libtool) 1.2 scwm -V: ------------------ Scwm Version 0.9beta1 compiled on Dec 8 1998 at 11:05:51 RCS_ID=$Id: scwm.c,v 1.150 1998/11/18 00:04:17 mstachow Exp $ Repository Timestamp: Tue Nov 17 21:33:27 EST 1998 -- $Revision: 1.900 $ changed.c: ------------------ char *szRepoLastChanged = "Tue Nov 17 21:33:27 EST 1998 -- $Revision: 1.900 $"; scwmpaths.h: ------------------ /* generated by Makefile -- do not edit */ #define SCWM_PREFIX "/prog/window-manager" #define SCWM_EXEC_PREFIX "/prog/window-manager" #define SCWMDIR "/prog/window-manager/lib/X11/scwm" #define SCWMRC ".scwmrc" #define SCWM_LOAD_PATH "/prog/window-manager/share/scwm-modules" #define SCWM_BIN_LOAD_PATH "/prog/window-manager/lib/scwm-modules" #define SCWM_IMAGE_LOAD_PATH "(\"/usr/X11R6/include/X11/bitmaps\" \"/usr/X11R6/include/X11/pixmaps\" \"/X11/mini-icons\" \"/prog/window-manager/include/X11/pixmaps\" \"/prog/window-manager/include/X11/bitmaps\" \"/prog/window-manager/lib/X11/mini-icons\")" ldd scwm: ------------------ libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4000c000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40015000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4002a000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40035000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40047000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40055000) libguile.so.4 => /prog/gnu/Global/Linux/lib/libguile.so.4 (0x400f4000) libdl.so.1 => /lib/libdl.so.1 (0x40156000) libm.so.5 => /lib/libm.so.5 (0x40159000) libncurses.so.3.0 => /lib/libncurses.so.3.0 (0x40162000) libstdc++.so.27 => /usr/lib/libstdc++.so.27 (0x401a5000) libc.so.5 => /lib/libc.so.5 (0x401d6000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40290000) relevant env: ------------------ LD_LIBRARY_PATH=/prog/gnu/Global/Linux/lib:/prog/window-manager/lib:/prog/gnu/Global/Linux/lib:/prog/util/lib:/prog/lesstif/Motif-1.2/Linux/lib: PATH=/prog/gcc/bin:/prog/gnu/Global/Linux/bin:.:/home/muenkel/prog/Global/bin:/prog/window-manager/bin:/usr/lib/teTeX/bin/i386-linux:/prog/gnu/Global/Linux/bin:/prog/xemacs/Global/bin/i486-unknown-linux2.0.27:/prog/lesstif/Motif-1.2/Linux/bin:/prog/util/bin:/usr/sbin:/home/muenkel/appl/Global/bin/:/home/muenkel/data/emacs/lemacs-19.10/Global/bin/:/prog/util/bin/:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/openwin/bin:/usr/lib/java/bin:/var/lib/dosemu:/usr/games:/opt/kde/bin:.:/usr/bin/TeX config.h: ------------------ /* include/config.h. Generated automatically by configure. */ /* include/config.h.in. Generated automatically from configure.in by autoheader. */ /* Define if on AIX 3. System headers sometimes define this. We just want to avoid a redefinition error message. */ #ifndef _ALL_SOURCE /* #undef _ALL_SOURCE */ #endif /* Define to empty if the keyword does not work. */ /* #undef const */ /* Define as __inline if that's what the C compiler calls it. */ /* #undef inline */ /* Define if on MINIX. */ /* #undef _MINIX */ /* Define if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define if you need to in order for stat and other things to work. */ /* #undef _POSIX_SOURCE */ /* Define if you have the ANSI C header files. */ #define STDC_HEADERS 1 /* Define if the X Window System is missing or not being used. */ /* #undef X_DISPLAY_MISSING */ /* Package and version macros defined by automake */ #define PACKAGE "scwm" #define VERSION "0.9beta1" /* Define this if your Xext library supports the X extension (wether your server does or not will be determined at runtime */ #define HAVE_SHAPE 1 /* Define this if you have libXpm */ #define HAVE_LIBXPM 1 /* Define this if you have libXmu */ #define HAVE_LIBXMU 1 /* Define this if you have libSM and libIce for session manager support */ #define HAVE_LIBSM_LIBICE 1 /* Define this if you have the readline library */ #define HAVE_READLINE 1 /* Define this if your readline also has add_history() */ #define HAVE_HISTORY 1 /* Define this if your libguile has a scm_eval_string that is safe against re-entry by continuations. This should be true of snapshots newer than 970928. */ #define HAVE_SAFE_SCM_EVAL_STRING 1 /* Define this if your libguile exports scm_puts, meaning that scm_gen_puts should no longer be used. This should be true of snapshots newer than 971014. */ #define HAVE_SCM_PUTS 1 /* Define this if your libguile has gh_vector_ref instead of gh_vref, meaning that gh_vref should no longer be used. This should be true of snapshots newer than 971012. */ #define HAVE_GH_VECTOR_REF 1 /* Define this if your libguile has gh_vector_set_x instead of gh_vset, meaning that gh_vset should no longer be used. This should be true of snapshots newer than 971020. */ #define HAVE_GH_VECTOR_SET_X 1 /* Define this if your libguile has readline support. This should be true of snapshots newer than 971023. */ #define HAVE_SCM_READLINE 1 /* Define this if your libguile has gh_length and not gh_list_length. This should be true of snapshots newer than 970915. */ #define HAVE_GH_LENGTH 1 /* Define this if your libguile has scm_parse_path. */ #define HAVE_SCM_PARSE_PATH 1 /* Define this if your libguile has scm_parse_path. */ /* #undef HAVE_SCM_INTERNAL_SELECT */ /* Define this if your libguile has scm_the_last_stack_fluid instead of scm_the_last_stack_var. */ /* #undef HAVE_SCM_THE_LAST_STACK_FLUID */ /* Define this if your libguile has scm_internal_cwdr. */ #define HAVE_SCM_INTERNAL_CWDR 1 /* Define this if your libguile has scm_internal_stack_catch. */ #define HAVE_SCM_INTERNAL_STACK_CATCH 1 /* Define this if your libguile has scm_internal_parse_path, which should be used instead of scm_parse_path from C. */ #define HAVE_SCM_INTERNAL_PARSE_PATH 1 /* Define this if your libguile has a scm_make_vector, which needs three arguments. This should be true only of older versions. */ /* #undef HAVE_SCM_MAKE_VECTOR_3_ARGS */ /* Define this if your libguile has scm_load_startup_files, which means the hack to get boot-9.scm to be loaded is unnecessary and even dangerous. */ #define HAVE_SCM_LOAD_STARTUP_FILES 1 /* Define this if your system has a header file. */ #define HAVE_GETOPT_H 1 /* Define this if you want multibyte support. */ /* #undef I18N */ /* Define this if you want to compile with X_LOCALE define. */ #define X_LOCALE 1 /* Define this and use C++ compiler if you want to use constraint solver */ /* #undef USE_CASSOWARY */ /* Define tihs if you want to turn debug support off for cassowary */ /* #undef CL_NO_TRACE */ /* Define if you have the gethostname function. */ #define HAVE_GETHOSTNAME 1 /* Define if you have the getopt_long function. */ #define HAVE_GETOPT_LONG 1 /* Define if you have the setlinebuf function. */ #define HAVE_SETLINEBUF 1 /* Define if you have the setvbuf function. */ #define HAVE_SETVBUF 1 /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 /* Define if you have the strerror function. */ #define HAVE_STRERROR 1 /* Define if you have the strncasecmp function. */ #define HAVE_STRNCASECMP 1 /* Define if you have the sysconf function. */ #define HAVE_SYSCONF 1 /* Define if you have the uname function. */ #define HAVE_UNAME 1 /* Define if you have the usleep function. */ #define HAVE_USLEEP 1 /* Define if you have the waitpid function. */ #define HAVE_WAITPID 1 /* Define if you have the header file. */ #define HAVE_X11_SM_SMLIB_H 1 /* Define if you have the header file. */ #define HAVE_GETOPT_H 1 /* Define if you have the m library (-lm). */ #define HAVE_LIBM 1 Please also see ./BUG-REPORTING From owner-scwm-discuss@mit.edu Tue Dec 8 08:37:36 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id IAA32468 for scwm-discuss-outgoing; Tue, 8 Dec 1998 08:37:36 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id IAA32465 for ; Tue, 8 Dec 1998 08:37:36 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA10214; Tue, 8 Dec 98 08:34:24 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Tue, 8 Dec 1998 14:32:12 +0100 Received: from enterprise.osterwald.de (root@h52.ts1.uni-hannover.de [130.75.249.52]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id OAA20802 for ; Tue, 8 Dec 1998 14:32:06 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id LAA13805; Tue, 8 Dec 1998 11:06:16 +0100 Date: Tue, 8 Dec 1998 11:06:16 +0100 Message-Id: <199812081006.LAA13805@enterprise.osterwald.de> From: Heiko Muenkel To: scwm-discuss@mit.edu Subject: Bug and Patch for configure in scwm 0.9 beta 1 X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H autoconf --version ------------------ Autoconf version 2.12 automake --version ------------------ automake (GNU automake) 1.2 Copyright (C) 1994, 1995, 1996, 1997 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Written by Tom Tromey libtool --version ------------------ ltmain.sh (GNU libtool) 1.2 scwm -V: ------------------ ./scwm-bug-report-information: ./scwm/scwm: No such file or directory changed.c: ------------------ char *szRepoLastChanged = "Tue Nov 17 21:33:27 EST 1998 -- $Revision: 1.900 $"; scwmpaths.h: ------------------ /* generated by Makefile -- do not edit */ #define SCWM_PREFIX "/prog/window-manager" #define SCWM_EXEC_PREFIX "/prog/window-manager" #define SCWMDIR "/prog/window-manager/lib/X11/scwm" #define SCWMRC ".scwmrc" #define SCWM_LOAD_PATH "/prog/window-manager/share/scwm-modules" #define SCWM_BIN_LOAD_PATH "/prog/window-manager/lib/scwm-modules" #define SCWM_IMAGE_LOAD_PATH "(\"/usr/X11R6/include/X11/bitmaps\" \"/usr/X11R6/include/X11/pixmaps\" \"/X11/mini-icons\" \"/prog/window-manager/include/X11/pixmaps\" \"/prog/window-manager/include/X11/bitmaps\" \"/prog/window-manager/lib/X11/mini-icons\")" ldd scwm: ------------------ ldd: can't open scwm/scwm (No such file or directory) relevant env: ------------------ LD_LIBRARY_PATH=/prog/window-manager/lib:/prog/gnu/Global/Linux/lib:/prog/window-manager/lib:/prog/gnu/Global/Linux/lib:/prog/util/lib:/prog/lesstif/Motif-1.2/Linux/lib: PATH=/prog/window-manager/bin:/prog/gcc/bin:/prog/gnu/Global/Linux/bin:.:/home/muenkel/prog/Global/bin:/prog/window-manager/bin:/usr/lib/teTeX/bin/i386-linux:/prog/gnu/Global/Linux/bin:/prog/xemacs/Global/bin/i486-unknown-linux2.0.27:/prog/lesstif/Motif-1.2/Linux/bin:/prog/util/bin:/usr/sbin:/home/muenkel/appl/Global/bin/:/home/muenkel/data/emacs/lemacs-19.10/Global/bin/:/prog/util/bin/:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/openwin/bin:/usr/lib/java/bin:/var/lib/dosemu:/usr/games:/opt/kde/bin:.:/usr/bin/TeX config.h: ------------------ /* include/config.h. Generated automatically by configure. */ /* include/config.h.in. Generated automatically from configure.in by autoheader. */ /* Define if on AIX 3. System headers sometimes define this. We just want to avoid a redefinition error message. */ #ifndef _ALL_SOURCE /* #undef _ALL_SOURCE */ #endif /* Define to empty if the keyword does not work. */ /* #undef const */ /* Define as __inline if that's what the C compiler calls it. */ /* #undef inline */ /* Define if on MINIX. */ /* #undef _MINIX */ /* Define if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define if you need to in order for stat and other things to work. */ /* #undef _POSIX_SOURCE */ /* Define if you have the ANSI C header files. */ #define STDC_HEADERS 1 /* Define if the X Window System is missing or not being used. */ /* #undef X_DISPLAY_MISSING */ /* Package and version macros defined by automake */ #define PACKAGE "scwm" #define VERSION "0.9beta1" /* Define this if your Xext library supports the X extension (wether your server does or not will be determined at runtime */ #define HAVE_SHAPE 1 /* Define this if you have libXpm */ #define HAVE_LIBXPM 1 /* Define this if you have libXmu */ #define HAVE_LIBXMU 1 /* Define this if you have libSM and libIce for session manager support */ #define HAVE_LIBSM_LIBICE 1 /* Define this if you have the readline library */ #define HAVE_READLINE 1 /* Define this if your readline also has add_history() */ #define HAVE_HISTORY 1 /* Define this if your libguile has a scm_eval_string that is safe against re-entry by continuations. This should be true of snapshots newer than 970928. */ /* #undef HAVE_SAFE_SCM_EVAL_STRING */ /* Define this if your libguile exports scm_puts, meaning that scm_gen_puts should no longer be used. This should be true of snapshots newer than 971014. */ /* #undef HAVE_SCM_PUTS */ /* Define this if your libguile has gh_vector_ref instead of gh_vref, meaning that gh_vref should no longer be used. This should be true of snapshots newer than 971012. */ /* #undef HAVE_GH_VECTOR_REF */ /* Define this if your libguile has gh_vector_set_x instead of gh_vset, meaning that gh_vset should no longer be used. This should be true of snapshots newer than 971020. */ /* #undef HAVE_GH_VECTOR_SET_X */ /* Define this if your libguile has readline support. This should be true of snapshots newer than 971023. */ /* #undef HAVE_SCM_READLINE */ /* Define this if your libguile has gh_length and not gh_list_length. This should be true of snapshots newer than 970915. */ /* #undef HAVE_GH_LENGTH */ /* Define this if your libguile has scm_parse_path. */ /* #undef HAVE_SCM_PARSE_PATH */ /* Define this if your libguile has scm_parse_path. */ /* #undef HAVE_SCM_INTERNAL_SELECT */ /* Define this if your libguile has scm_the_last_stack_fluid instead of scm_the_last_stack_var. */ /* #undef HAVE_SCM_THE_LAST_STACK_FLUID */ /* Define this if your libguile has scm_internal_cwdr. */ /* #undef HAVE_SCM_INTERNAL_CWDR */ /* Define this if your libguile has scm_internal_stack_catch. */ /* #undef HAVE_SCM_INTERNAL_STACK_CATCH */ /* Define this if your libguile has scm_internal_parse_path, which should be used instead of scm_parse_path from C. */ /* #undef HAVE_SCM_INTERNAL_PARSE_PATH */ /* Define this if your libguile has a scm_make_vector, which needs three arguments. This should be true only of older versions. */ /* #undef HAVE_SCM_MAKE_VECTOR_3_ARGS */ /* Define this if your libguile has scm_load_startup_files, which means the hack to get boot-9.scm to be loaded is unnecessary and even dangerous. */ /* #undef HAVE_SCM_LOAD_STARTUP_FILES */ /* Define this if your system has a header file. */ #define HAVE_GETOPT_H 1 /* Define this if you want multibyte support. */ /* #undef I18N */ /* Define this if you want to compile with X_LOCALE define. */ #define X_LOCALE 1 /* Define this and use C++ compiler if you want to use constraint solver */ /* #undef USE_CASSOWARY */ /* Define tihs if you want to turn debug support off for cassowary */ /* #undef CL_NO_TRACE */ /* Define if you have the gethostname function. */ #define HAVE_GETHOSTNAME 1 /* Define if you have the getopt_long function. */ #define HAVE_GETOPT_LONG 1 /* Define if you have the setlinebuf function. */ #define HAVE_SETLINEBUF 1 /* Define if you have the setvbuf function. */ #define HAVE_SETVBUF 1 /* Define if you have the strcasecmp function. */ #define HAVE_STRCASECMP 1 /* Define if you have the strerror function. */ #define HAVE_STRERROR 1 /* Define if you have the strncasecmp function. */ #define HAVE_STRNCASECMP 1 /* Define if you have the sysconf function. */ #define HAVE_SYSCONF 1 /* Define if you have the uname function. */ #define HAVE_UNAME 1 /* Define if you have the usleep function. */ #define HAVE_USLEEP 1 /* Define if you have the waitpid function. */ #define HAVE_WAITPID 1 /* Define if you have the header file. */ #define HAVE_X11_SM_SMLIB_H 1 /* Define if you have the header file. */ #define HAVE_GETOPT_H 1 /* Define if you have the m library (-lm). */ #define HAVE_LIBM 1 ======================================================================== Bug: The configure checks for scm_done_malloc, scm_puts etc. failed, because there are undefined references to rl_instream etc. The following are some example lines out of configure.log: ======================================================================== configure:4385: checking for scm_done_malloc in -lguile configure:4404: gcc -o conftest -g -O2 conftest.c -lguile -L/prog/window-manager/lib -L/prog/gnu/Global/Linux/lib -lguile -ldl -lm -lm 1>&5 /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_deprep_term_function' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_instream' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_redisplay' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_completion_entry_function' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `readline' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `_rl_kill_kbd_macro' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_getc_function' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_pending_input' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_redisplay_function' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_outstream' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `free_undo_list' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `add_history' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `filename_completion_function' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `current_history' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `rl_clear_message' /prog/gnu/Global/Linux/lib/libguile.so: undefined reference to `_rl_init_argument' configure: failed program was: #line 4393 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char scm_done_malloc(); int main() { scm_done_malloc() ; return 0; } ======================================================================== This can be fixed by adding the readline Library in the AC_CHECK_LIB macros. I had the same problem with the scwm snapshot scwm-19981113. My Linux system is Suse 5.0. The following is a diff -u patch for configure.in: ======================================================================== --- configure.in.orig Tue Dec 8 10:18:37 1998 +++ configure.in Tue Dec 8 10:45:10 1998 @@ -375,35 +375,35 @@ dnl to have a scm_eval_string that is safe against re-entry by continuations. dnl I was to lazy to write a real test macro so I just check for a function dnl that was added soon after. -AC_CHECK_LIB(guile, scm_done_malloc, AC_DEFINE(HAVE_SAFE_SCM_EVAL_STRING), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_done_malloc, AC_DEFINE(HAVE_SAFE_SCM_EVAL_STRING), ,$GUILE_LIBS $READLINE_LIB) dnl This checks if the new printer functions are available, and should dnl be used instead of the old ones. -AC_CHECK_LIB(guile, scm_puts, AC_DEFINE(HAVE_SCM_PUTS), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_puts, AC_DEFINE(HAVE_SCM_PUTS), ,$GUILE_LIBS $READLINE_LIB) dnl This checks if we have gh_vref or gh_vector_ref -AC_CHECK_LIB(guile, gh_vector_ref, AC_DEFINE(HAVE_GH_VECTOR_REF), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, gh_vector_ref, AC_DEFINE(HAVE_GH_VECTOR_REF), ,$GUILE_LIBS $READLINE_LIB) dnl This checks if we have gh_vset or gh_vector_set -AC_CHECK_LIB(guile, gh_vector_set_x, AC_DEFINE(HAVE_GH_VECTOR_SET_X), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, gh_vector_set_x, AC_DEFINE(HAVE_GH_VECTOR_SET_X), ,$GUILE_LIBS $READLINE_LIB) dnl This checks if we have a guile with readline support -AC_CHECK_LIB(guile, scm_readline, AC_DEFINE(HAVE_SCM_READLINE), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_readline, AC_DEFINE(HAVE_SCM_READLINE), ,$GUILE_LIBS $READLINE_LIB) dnl This checks if we have a guile with gh_length, not gh_list_length -AC_CHECK_LIB(guile, gh_length, AC_DEFINE(HAVE_GH_LENGTH), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, gh_length, AC_DEFINE(HAVE_GH_LENGTH), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_parse_path, AC_DEFINE(HAVE_SCM_PARSE_PATH), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_parse_path, AC_DEFINE(HAVE_SCM_PARSE_PATH), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_internal_select, AC_DEFINE(HAVE_SCM_INTERNAL_SELECT), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_internal_select, AC_DEFINE(HAVE_SCM_INTERNAL_SELECT), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_internal_cwdr, AC_DEFINE(HAVE_SCM_INTERNAL_CWDR), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_internal_cwdr, AC_DEFINE(HAVE_SCM_INTERNAL_CWDR), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_internal_stack_catch, AC_DEFINE(HAVE_SCM_INTERNAL_STACK_CATCH), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_internal_stack_catch, AC_DEFINE(HAVE_SCM_INTERNAL_STACK_CATCH), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_internal_parse_path, AC_DEFINE(HAVE_SCM_INTERNAL_PARSE_PATH), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_internal_parse_path, AC_DEFINE(HAVE_SCM_INTERNAL_PARSE_PATH), ,$GUILE_LIBS $READLINE_LIB) -AC_CHECK_LIB(guile, scm_load_startup_files, AC_DEFINE(HAVE_SCM_LOAD_STARTUP_FILES), ,$GUILE_LIBS) +AC_CHECK_LIB(guile, scm_load_startup_files, AC_DEFINE(HAVE_SCM_LOAD_STARTUP_FILES), ,$GUILE_LIBS $READLINE_LIB) dnl check for scm_the_last_fluid in place of scm_the_last_stack_var @@ -429,7 +429,7 @@ dnl FIXJTL: this shouldn't be needed any more; verify and remove saved_LIBS="${LIBS}" -LIBS="${LIBS} ${GUILE_LIBS}" +LIBS="${LIBS} ${GUILE_LIBS} ${READLINE_LIB}" saved_CFLAGS="${CFLAGS}" CFLAGS="${CFLAGS} ${GUILE_INCLUDES}" AC_MSG_CHECKING(whether scm_make_vector in -lguile takes a third argument) ======================================================================== Regards, Heiko From owner-scwm-discuss@mit.edu Tue Dec 8 10:00:24 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA00279 for scwm-discuss-outgoing; Tue, 8 Dec 1998 10:00:24 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA00268; Tue, 8 Dec 1998 10:00:17 -0500 Message-Id: <199812081500.KAA00268@vicarious-existence.mit.edu> To: Heiko Muenkel cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 In-reply-to: Your message of "Tue, 08 Dec 1998 11:06:16 +0100." <199812081006.LAA13805@enterprise.osterwald.de> Date: Tue, 08 Dec 1998 10:00:17 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk muenkel@tnt.uni-hannover.de writes: > ======================================================================== > > Bug: The configure checks for scm_done_malloc, scm_puts etc. failed, > because there are undefined references to rl_instream etc. The > following are some example lines out of configure.log: > Please send all of config.log (to me personally is OK). > ======================================================================== > > This can be fixed by adding the readline Library in the AC_CHECK_LIB > macros. I had the same problem with the scwm snapshot scwm-19981113. > My Linux system is Suse 5.0. The following is a diff -u patch for > configure.in: > The GUILE_LIBS variable should have the proper readline libraries in it if Guile was configured with them, we need to figure out why this is failing. - Maciej From owner-scwm-discuss@mit.edu Tue Dec 8 10:02:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA00314 for scwm-discuss-outgoing; Tue, 8 Dec 1998 10:02:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id KAA00302; Tue, 8 Dec 1998 10:01:49 -0500 Message-Id: <199812081501.KAA00302@vicarious-existence.mit.edu> To: Heiko Muenkel cc: scwm-discuss@mit.edu Subject: Re: Bug in scwm 0.9 beta 1: Missing symbol gh_reverse In-reply-to: Your message of "Tue, 08 Dec 1998 11:13:03 +0100." <199812081013.LAA14503@enterprise.osterwald.de> Date: Tue, 08 Dec 1998 10:01:49 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk muenkel@tnt.uni-hannover.de writes: > I'm missing the symbol gh_reverse. Do I need a newer guile version > than 1.3? > No. gh_reverse should be #define'd to scm_reverse in the guile/gh.h header file in Guile 1.3. Is your compile failing to find this header? What -I flags does it use on a typical compile? - Maciej From owner-scwm-discuss@mit.edu Tue Dec 8 13:47:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA01358 for scwm-discuss-outgoing; Tue, 8 Dec 1998 13:47:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA01352 for ; Tue, 8 Dec 1998 13:46:58 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA25257; Tue, 8 Dec 98 13:44:16 EST Received: (qmail 16679 invoked by uid 501); 8 Dec 1998 18:44:24 -0000 Message-Id: <19981208104423.A14313@molehill.org> Date: Tue, 8 Dec 1998 10:44:23 -0800 From: Todd Larason To: Maciej Stachowiak , Heiko Muenkel Cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 References: <199812081006.LAA13805@enterprise.osterwald.de> <199812081500.KAA00268@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812081500.KAA00268@vicarious-existence.mit.edu>; from Maciej Stachowiak on Tue, Dec 08, 1998 at 10:00:17AM -0500 X-Kibo: Open a mental door Kibology, and eat well! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981208, Maciej Stachowiak wrote: > The GUILE_LIBS variable should have the proper readline libraries in > it if Guile was configured with them, we need to figure out why this > is failing. The Redhat 'rawhide' guile 1.3 package is missing guile-config, and the guile-1.3 RPM I uploaded to the redhat contrib site was removed when they upgraded rawhide to 1.3. Heiko, are you perchance using the rawhide guile-1.3 RPM? or is there a SUSE contrib RPM site I could check? -- ICQ UIN: 99500857 From owner-scwm-discuss@mit.edu Tue Dec 8 14:20:01 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01667 for scwm-discuss-outgoing; Tue, 8 Dec 1998 14:20:01 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01657; Tue, 8 Dec 1998 14:19:55 -0500 Message-Id: <199812081919.OAA01657@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 In-reply-to: Your message of "Tue, 08 Dec 1998 10:44:23 PST." <19981208104423.A14313@molehill.org> Date: Tue, 08 Dec 1998 14:19:55 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981208, Maciej Stachowiak wrote: > > The GUILE_LIBS variable should have the proper readline libraries in > > it if Guile was configured with them, we need to figure out why this > > is failing. > > The Redhat 'rawhide' guile 1.3 package is missing guile-config, and the > guile-1.3 RPM I uploaded to the redhat contrib site was removed when they > upgraded rawhide to 1.3. > Did you file a bug report? Is there a guile-devel package or something that contains guile-config and the headers? If neither of these are true, what would be a good address to direct flames to? > Heiko, are you perchance using the rawhide guile-1.3 RPM? or is there a SUSE > contrib RPM site I could check? - Maciej From owner-scwm-discuss@mit.edu Tue Dec 8 14:58:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA01989 for scwm-discuss-outgoing; Tue, 8 Dec 1998 14:58:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id OAA01986 for ; Tue, 8 Dec 1998 14:58:25 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA22829; Tue, 8 Dec 98 14:55:42 EST Received: (qmail 7353 invoked by uid 501); 8 Dec 1998 19:55:56 -0000 Message-Id: <19981208115555.A1199@molehill.org> Date: Tue, 8 Dec 1998 11:55:55 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 References: <19981208104423.A14313@molehill.org> <199812081919.OAA01657@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812081919.OAA01657@vicarious-existence.mit.edu>; from Maciej Stachowiak on Tue, Dec 08, 1998 at 02:19:55PM -0500 X-Kibo: If fire could shine, would the Universe, U for Ubiquitous, be intense? Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981208, Maciej Stachowiak wrote: > Did you file a bug report? Is there a guile-devel package or something > that contains guile-config and the headers? If neither of these are > true, what would be a good address to direct flames to? *blush* No, I didn't, mainly because I couldn't remember or quickly find an address to, and I keep forgetting to go back and do that. I'll look again. -- ICQ UIN: 43141745 From owner-scwm-discuss@mit.edu Tue Dec 8 15:05:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA02119 for scwm-discuss-outgoing; Tue, 8 Dec 1998 15:05:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA02113; Tue, 8 Dec 1998 15:05:05 -0500 Message-Id: <199812082005.PAA02113@vicarious-existence.mit.edu> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 In-reply-to: Your message of "Tue, 08 Dec 1998 11:55:55 PST." <19981208115555.A1199@molehill.org> Date: Tue, 08 Dec 1998 15:05:04 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > On 981208, Maciej Stachowiak wrote: > > Did you file a bug report? Is there a guile-devel package or something > > that contains guile-config and the headers? If neither of these are > > true, what would be a good address to direct flames to? > > *blush* No, I didn't, mainly because I couldn't remember or quickly find an > address to, and I keep forgetting to go back and do that. I'll look again. No problem, I just didn't want to flie a duplicate. If you want to handle reporting this (if the bug still exists) that is fine by me. Is there an index of the Rawhide packages anywhere? I tried looking on Red Hat's site but it was quite unhelpful. - Maciej From owner-scwm-discuss@mit.edu Tue Dec 8 15:33:48 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA02402 for scwm-discuss-outgoing; Tue, 8 Dec 1998 15:33:48 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA02397; Tue, 8 Dec 1998 15:33:40 -0500 Message-Id: <199812082033.PAA02397@vicarious-existence.mit.edu> To: jtl@molehill.org cc: scwm-discuss@mit.edu cc: guile@cygnus.com Subject: Buggy Rawhide guile-1.3 packages Date: Tue, 08 Dec 1998 15:33:40 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk [ cc'd to guile list so Guile people can confirm the packaging bugs before someone reports them ] Red Hat Rawhide's guile-1.3-1 and guile-devel-1.3-1 RPM packages have the following packaging bugs as far as I can tell from the Rawhide RPM list at http://rufus.w3.org/linux/RPM/rawhide/1.0/i386/RedHat/RPMS/ (for those who may not know, the distinction between a regular and -devel package is that you should need only the non -devel package to run binaries linked against the package, but -devel should provide everything else you need to compile programs from source that link against the package) * guile-devel-1.3-1 does not include guile-config (neither does guile-1.3) * guile-snarf is in guile-1.3-1 instead of in guile-devel-1.3-1 * guile-1.3-1 installs the Guile m4 macros (guile.m4, qthreads.m4), I believe that neither package should install these but if one does it should be guile-devel. * The guile-1.3-1 package depends on the umb-scheme package for no apparent reason. * The guile-devel-1.3-1 package depends on the m4 package, which is wrong since it includes no m4 macros (although guile-1.3 does, and does not depend on m4). * The guile-devel-1.3-1 package does not depend on the guile package, I believe this is wrong on general principle but will be even more wrong when guile-config is added to it since that is a Guile script. I will report these unless Todd wants to, since he discovered the bugs. I think we will need to add a warning to the scwm install docs not to use the guile-1.3 RPMs from rawhide for the time being. - Maciej Stachowiak From owner-scwm-discuss@mit.edu Tue Dec 8 15:38:39 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id PAA02474 for scwm-discuss-outgoing; Tue, 8 Dec 1998 15:38:39 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id PAA02471 for ; Tue, 8 Dec 1998 15:38:38 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA07797; Tue, 8 Dec 98 15:35:54 EST Received: (qmail 18561 invoked by uid 501); 8 Dec 1998 20:36:08 -0000 Message-Id: <19981208123608.C7978@molehill.org> Date: Tue, 8 Dec 1998 12:36:08 -0800 From: Todd Larason To: Maciej Stachowiak Cc: scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Buggy Rawhide guile-1.3 packages References: <199812082033.PAA02397@vicarious-existence.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812082033.PAA02397@vicarious-existence.mit.edu>; from Maciej Stachowiak on Tue, Dec 08, 1998 at 03:33:40PM -0500 X-Kibo: Half of all of the old Chinese food and something like a summit on a high mountain are half-baked. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981208, Maciej Stachowiak wrote: > * The guile-1.3-1 package depends on the umb-scheme package for no > apparent reason. There is a reason, just not a great one. RH's umb-scheme package contains slib, and their guile releases are configured to use that copy of slib. Obviously the Right Thing is to have a separate slib package. > I will report these unless Todd wants to, since he discovered the > bugs. It looks like the right place to report them is redhat-devel-list@redhat.com. -- ICQ UIN: 91797051 From owner-scwm-discuss@mit.edu Tue Dec 8 17:45:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA03471 for scwm-discuss-outgoing; Tue, 8 Dec 1998 17:45:09 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id RAA03465 for ; Tue, 8 Dec 1998 17:44:54 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA14074; Tue, 8 Dec 98 17:39:49 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id RAA27671 for ; Tue, 8 Dec 1998 17:38:35 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id RAA16644 for ; Tue, 8 Dec 1998 17:38:34 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id RAA13961; Tue, 8 Dec 1998 17:38:33 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="4FWgQV6u/C" Content-Transfer-Encoding: 7bit Message-Id: <13933.43624.819069.356827@horus.cs.cornell.edu> Date: Tue, 8 Dec 1998 17:38:32 -0500 (EST) To: scwm-discuss@mit.edu Subject: scwm.el X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk --4FWgQV6u/C Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit Since my last message about scwm.el was silently ignored, I went ahead to modify the file. The version that I have: * Binds the keys properly under FSF. * Compiles on & loads properly on both XEmacs 20.4 and FSF 20.3/19.34 whether compiled with FSF or XEmacs (the only problem is that code that is compiled under XEmacs has an initials expression that signals an error when loading under v.19). The modified code pieces are prefixed with ";;ELI:". --4FWgQV6u/C Content-Type: text/plain Content-Description: scwm.el Content-Disposition: inline; filename="scwm.el" Content-Transfer-Encoding: 7bit ;;; $Id: scwm.el,v 1.54 1998/10/27 20:55:11 sds Exp $ ;;; scwm --- functions for editing and running SCWM code under Emacs ;; Copyright (c) 1998 by Sam Steingold ;; File: ;; Author: Sam Steingold ;; Version: $Revision: 1.54 $ ;; Keywords: language lisp scheme scwm ;; LCD Archive Entry: ;; scwm|Sam Steingold|sds@usa.net| ;; Functions for editing and running SCWM code under Emacs| ;; $Date: 1998/10/27 20:55:11 $|$Revision: 1.54 $|| ;;; History: ;; Completion-support added by Greg J. Badros ;; 03/11/98 gjb ;; ;; Completition, help and apropos are completely re-worked by sds ;; 1998-03-13 Fri 13:58:16 EST sds ;; ;; Fixed scwm-run to restart in the same buffer after a crash. ;; 1998-03-17 Tue 15:50:55 EST sds ;; ;; Made into a major mode. ;; 1998-04-16 Thu 10:38:19 CEST robbe@orcus.priv.at ;; ;; Added font-lock support for the major mode stuff. ;; 1998-04-16 Thu 17:04:43 EDT sds ;; ;; Added font-lock support for XEmacs and Emacs19 compatibility. ;; 1998-06-19 Fri 09:28:19 EDT sds ;; ;; This file is distributed under the GPL. See ;; ;; for further details. ;; This file is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; This file is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with This file; see the file COPYING. If not, write to the ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330, ;; Boston, MA 02111-1307, USA. ;;; Commentary: ;; Put this file somewhare in your load-path and add the following ;; lines to your .emacs file: ;; (autoload 'scwm-mode "scwm" "Major mode for editing scwm code. [...]" t) ;; (setq auto-mode-alist (cons '("scwmrc\\'" . scwm-mode) auto-mode-alist)) ;; Now you do M-x scwm-run (C-c C-s) to get the *scwm* buffer, where you ;; can type commands to be sent to scwm; while you can type C-x C-e in ;; your scheme buffers to send the last SEXP to the interpreter. ;; See C-h v scheme-buffer for details on running several scheme ;; interpreters at once. ;; *Alternatively* (that's OR, not XOR) you can type C-j evaluate the ;; last SEXP and insert the results at point, or type C-x C-j to display ;; them in the minibuffer. This functionality does not require ;; preliminary M-x scwm-run. Note that you can find your recent ;; minibuffer messages in the buffer *Messages*. Help and Apropos are ;; also available: type C-h C-a for apropos and C-h C-s for documentation. ;; Type M-TAB to complete symbol at point. (eval-and-compile ;;ELI: Removed (fboundp 'unless) - its not an excuse to load CL in run-time ;; (it should get autoloaded only in compile-time, and expand to standard ;; CL code - and thatis required below anyway). (or (fboundp 'cadr) (require 'cl)) ;;ELI: The following comment should be fixed (or maybe "dumped" means "exist ;; only with") ;; these three are dumped with e20.3 (unless (fboundp 'quit-window) (defalias 'quit-window 'ignore)) (unless (fboundp 'help-xref-button) (defalias 'help-xref-button 'ignore)) (unless (fboundp 'help-setup-xref) (defalias 'help-setup-xref 'ignore)) ;; why aren't these autoloaded by default? (unless (fboundp 'Info-find-node) (autoload 'Info-find-node "info")) (unless (fboundp 'inferior-scheme-mode) (autoload 'inferior-scheme-mode "cmuscheme")) ;;ELI: Removed ignore-errors, - defined below (unless (fboundp 'compose-mail) (defun compose-mail (to) (mail nil to))) (unless (fboundp 'apropos-mode) (autoload 'apropos-mode "apropos"))) (eval-when-compile (require 'cl) ; for `gensym' (defvar Info-history) ; defined in info.el (defvar Info-current-file) ; defined in info.el (defvar font-lock-defaults-alist) ; defined in font-lock.el (defvar scheme-buffer) ; defined in cmuscheme.el (defvar inferior-scheme-mode-map) ; defined in cmuscheme.el (defvar scwm-mode-map) ; kill warnings (defvar scwm-mode-syntax-table)) ; kill warnings (eval-when-compile ;; cater to the inferior emacs implementations :-) (unless (fboundp 'save-current-buffer) (defmacro save-current-buffer (&rest body) `(save-excursion ,@body))) (unless (fboundp 'with-current-buffer) (defmacro with-current-buffer (buffer &rest body) "Execute the forms in BODY with BUFFER as the current buffer. The value returned is the value of the last form in BODY. See also `with-temp-buffer'." `(save-current-buffer (set-buffer ,buffer) ,@body))) (unless (fboundp 'with-output-to-string) (defmacro with-output-to-string (&rest body) "Execute BODY, return the text it sent to `standard-output', as a string." `(let ((standard-output (get-buffer-create (generate-new-buffer-name " *string-output*")))) ,@body (save-excursion (set-buffer standard-output) (prog1 (buffer-string) (kill-buffer standard-output)))))) ;;ELI: Removed with-temp-buffer and use this instead to overcome the problem ;;of compiling make-symbol (defmacro with-temp-buffer0 (&rest body) "Execute BODY, with current buffer being a temporary one." `(let ((standard-output (get-buffer-create (generate-new-buffer-name " *temp-buffer*")))) (save-excursion (set-buffer standard-output) (unwind-protect (progn ,@body) (kill-buffer standard-output))))) ;;ELI: Moved this out of the unless and made it use interned syms (ugly hack) (defmacro with-face0 (face &rest body) "Execute body, which prints to `standard-output', then highlight the output." (let ((pp (intern (symbol-name (gensym "wf"))))) `(let ((,pp (with-current-buffer standard-output (point)))) ,@body (put-text-property ,pp (with-current-buffer standard-output (point)) 'face ,face standard-output)))) ;;ELI: Redefined - the condition-case var is not used anyway so this is ;; identical to the version in cl-macs.el (fmakunbound 'ignore-errors) (defmacro ignore-errors (&rest body) "Execute FORMS; if an error occurs, return nil. Otherwise, return result of last FORM." (list 'condition-case nil (cons 'progn body) '(error nil)))) ;;; Code: ;; user variables ;; ---- --------- (defvar scwm-repl "scwmrepl" "*The path to scwmrepl.") (defvar scwm-exec "scwmexec" "*The path to scwmexec.") (defvar scwm-source-path "/usr/src/scwm/" "*The path to the SCWM sources.") ;; thing-at-point-file-name-chars ==> (defvar scwm-file-name-chars "~/A-Za-z0-9---_.${}#%,:" "Characters allowable in filenames.") ;; Use scheme major mode (require 'scheme) ;;; XEmacs doesn't have thingatpt. Too bad. ;(eval-and-compile ; (unless (fboundp 'thing-at-point) ; ;; pacify the compiler (XEmacs only) ; (eval-when-compile ; (autoload 'id-select-symbol "id-select")) ; (defun thing-at-point (what) ; "Return the thing at point (crippled: symbols only!)." ; (unless (eq what 'symbol) ; (error "crippled `thing-at-point' - symbols only")) ; (let ((zz (id-select-symbol (point)))) ; (when zz (buffer-substring-no-properties (car zz) (cdr zz))))))) ;(defun scwm-symbol-at-point () ; "Return symbol at point; look back if not found." ; (or (thing-at-point 'symbol) ; (save-excursion (skip-syntax-backward "^w") ; (unless (bobp) (backward-char 1)) ; (thing-at-point 'symbol)) "")) (defun symbol-thing-at-point () (if (fboundp 'thing-at-point) (thing-at-point 'symbol) (progn (require 'id-select) (let ((zz (id-select-symbol (point)))) (when zz (buffer-substring-no-properties (car zz) (cdr zz))))))) (defun scwm-symbol-at-point () "Return symbol at point; look back if not found." (or (symbol-thing-at-point) (save-excursion (skip-syntax-backward "^w") (unless (bobp) (backward-char 1)) (symbol-thing-at-point)) "")) ;; user functions ;; ---- --------- ;;;###autoload (define-derived-mode scwm-mode scheme-mode "Scwm" "Major mode for editing scwm code. Special commands: \\{scwm-mode-map} Turning on Scwm mode calls the value of the variable `scwm-mode-hook', if that value is non-nil. If you are using Emacs 20.2 or earlier and want to use fontifications, you have to (require 'font-lock) first. Sorry.") ;;ELI: used ? for compatibility with FSF (define-key scwm-mode-map [(control ?j)] 'scwm-eval-last) (define-key scwm-mode-map [(control ?c) (control ?s)] 'scwm-run) (define-key scwm-mode-map [(control ?c) (control ?r)] 'scwm-eval-region) (define-key scwm-mode-map [(control ?h) (control ?s)] 'scwm-documentation) (define-key scwm-mode-map [(control ?h) (control ?a)] 'scwm-apropos) (define-key scwm-mode-map [(control ?h) (control ?f)] 'scwm-goto-guile-procedure-node) (define-key scwm-mode-map [(meta tab)] 'scwm-complete-symbol-insert) ;;;###autoload (defun scwm-run () "Run scwm interaction or pop to an existing one. Use \\[scheme-send-last-sexp] to eval the last sexp there." (interactive) (unless (fboundp 'inferior-scheme-mode) (let ((ff (symbol-function 'run-scheme))) (if (and (consp ff) (eq (car ff) 'autoload)) (load (cadr ff)) (error "no `inferior-scheme-mode' and no place to get it from.")))) (pop-to-buffer (setq scheme-buffer (make-comint "scwm" scwm-repl))) (inferior-scheme-mode) (define-key inferior-scheme-mode-map [(control ?h)] (lookup-key scwm-mode-map [(control ?h)]))) ;;; service variables (defvar scwm-obarray nil "The obarray for scwm completion.") (defvar scwm-history nil "The input history of SCWM completions.") (defun scwm-eval (sexp out) "Evaluate the SEXP with scwm-exec and print the results to OUT. All evaluation goes through this procedure." (when (string-match "(\\s *\\(define\\|use-modules\\|load\\)" sexp) (setq scwm-obarray nil)) (call-process scwm-exec nil out nil sexp)) (defun scwm-safe-call (func args out) "Call FUNC with ARGS and output to OUT, checking existence of FUNC first." (scwm-eval (concat "(if (defined? '" func ") (" func " " args ") " "(display \"This Guile version lacks `" func "'.\n\"))") out)) (defvar scwm-eval-to-minibuffer nil "*The default destination of SCWM output. If this is nil, the output from `scwm-eval-sexp' is inserted into the current buffer, otherwise it goes to the minibuffer.") ;;;###autoload (defun scwm-eval-sexp (sexp mb-p) "Eval the SEXP. Output to the current buffer or minibuffer. If the prefix argument (the second argument when called from lisp) is non-nil, the output goes to the minibuffer, otherwise it is inserted in the current buffer. When `scwm-eval-to-minibuffer' is non-nil, the meaning of the second argument is reversed." (interactive "sEval in SCWM: \nP") (cond ((or (and mb-p scwm-eval-to-minibuffer) (not (or mb-p scwm-eval-to-minibuffer))) (newline-and-indent) (scwm-eval sexp t) (newline)) (t (message "%s" (with-output-to-string (scwm-eval sexp standard-output)))))) ;;;###autoload (defun scwm-eval-last (mb-p) "Evaluate the last sexp with `scwm-eval-sexp'." (interactive "P") (scwm-eval-sexp (buffer-substring-no-properties (point) (save-excursion (backward-sexp) (point))) mb-p)) ;;;###autoload (defun scwm-eval-region (beg end mb-p) "Evaluate the region with `scwm-eval-sexp'." (interactive "r\nP") (scwm-eval-sexp (buffer-substring-no-properties beg end) mb-p)) (defalias 'advertised-xscheme-send-previous-expression 'scwm-eval-last) ;; completion ;; ---------- (defun scwm-make-obarray () "Create and return an obarray of SCWM symbols." ;; (setq scwm-obarray (scwm-make-obarray)) ;; Can't use `read' because "? " is read as 32. Another problem is ;; that the symbols will be interned in the standard ELisp obarray ;; `obarray', not in the obarray `scwm-obarray'. (let ((oa (make-vector 131 0)) (pos 2)) ; obarray (with-temp-buffer0 ;; make sure `apropos' is present (scwm-eval "(use-modules (ice-9 session))" nil) (scwm-safe-call "apropos-internal" "\"\"" (current-buffer)) (unless (= (char-after 1) ?\() (error "Not a list: %s" (buffer-string))) (goto-char pos) (while (re-search-forward "[ ()]" nil t) (intern (buffer-substring-no-properties pos (1- (point))) oa) (setq pos (point))) oa))) (defun scwm-obarray () "Ensure `scwm-obarray' is initialized." (setq scwm-obarray (or scwm-obarray (scwm-make-obarray)))) (defun scwm-complete-symbol (&optional sym) "Complete the current symbol or SYM by querying scwm using apropos-internal. Returns a string which is present in the `scwm-obarray'." (when current-prefix-arg (setq scwm-obarray nil)) (let ((oa (scwm-obarray))) ;; require a match only when the obarry is present ;; (in case guile lacks `apropos-internal') ;; to be removed when the situation stabilizes. (completing-read "SCWM symbol: " oa nil oa (or sym (scwm-symbol-at-point)) 'scwm-history))) ;;;###autoload (defun scwm-complete-symbol-insert () (interactive) (let* ((end (point)) (beg (save-excursion (backward-sexp) (point))) (pat (buffer-substring-no-properties beg end)) (comp (try-completion pat (scwm-obarray)))) (cond ((eq comp t) (message "`%s' is complete" pat)) ((null comp) (message "Cannot complete `%s'" pat) (ding)) ((not (string= comp pat)) (delete-region beg end) (insert comp)) (t (message "Making completion list...") (with-output-to-temp-buffer "*Completions*" (display-completion-list (all-completions pat scwm-obarray))) (message "Making completion list...done"))))) ;; help ;; ---- (defvar scwm-bug "scwm-discuss@huis-clos.mit.edu" "The address to send bug reports on SCWM.") ;;;###autoload (defun scwm-bug () "Send a bug report about scwm." (interactive) (compose-mail scwm-bug) (save-excursion (search-forward mail-header-separator nil t) (forward-line 1) (call-process "uname" nil t nil "-a") (scwm-eval "(use-modules (app scwm flux))" nil) (let ((pos (point))) (scwm-eval "(system-info-string)" t) (delete-char -1) (goto-char pos) (delete-char 1)))) ;;;###autoload (defun scwm-documentation (pat) "Query scwm for documentation for the symbol PAT." (interactive (list (scwm-complete-symbol))) (help-setup-xref (list 'scwm-documentation pat) (interactive-p)) (with-output-to-temp-buffer "*Help*" (with-current-buffer "*Help*" (princ "SCWM documentation for `") (with-face0 'highlight (princ pat)) (princ "':\n\n ") (with-face0 'highlight (princ "value")) (princ ":\n\n ") (scwm-eval (concat "(if (defined? '" pat ") " pat " (display \"not defined\"))") standard-output) (princ "\n\n ") (with-face0 'highlight (princ "documentation")) (princ ":\n\n") (scwm-safe-call "documentation" (concat "\"" pat "\"") standard-output) (princ "\n\n ") (with-face0 'highlight (princ "procedure-documentation")) (princ ":\n\n") (scwm-eval (concat "(if (defined? 'procedure-documentation) " "(if (procedure? " pat ") (procedure-documentation " pat ") (begin (display " pat ") (display " "\" is not a procedure\n\")))" " (display \"This Guile version lacks " "`procedure-documentation'.\n\"))") standard-output) ;; add buttons to the help message (let ((st (syntax-table))) (set-syntax-table scwm-mode-syntax-table) (goto-char 1) (forward-line 8) ; skip the header and value (while (looking-at "trying `") (forward-line 1)) (let ((pt (point))) ;; clicking on quoted `symbol' invokes `scwm-documentation'. (while (re-search-forward "`\\(\\(\\sw\\|\\s_\\)+\\)'" nil t) (help-xref-button 1 #'scwm-documentation (match-string 1))) (goto-char pt) ;; calling sequence (quote `?') (when (re-search-forward (concat "^(" (regexp-quote pat) " .*)$") nil t) (put-text-property (match-beginning 0) (match-end 0) 'face 'highlight)) (goto-char pt) ;; function definition in the source (while (re-search-forward (concat "^\\[From \\(\\([" scwm-file-name-chars "\\]+\\):\\([0-9]+\\)\\)]$") nil t) (help-xref-button 1 (lambda (fl pos) (let ((ff (concat scwm-source-path fl))) (unless (file-readable-p ff) (error "File `%s' not found" ff)) (pop-to-buffer (find-file-noselect ff))) (goto-line pos)) (list (match-string 2) (string-to-number (match-string 3)))))) (set-syntax-table st)) (help-mode) (goto-char 1) (print-help-return-message)) )) ;;;###autoload (defun scwm-apropos (pat) "List all scwm symbols matching PAT." (interactive (list (read-string "SCWM Apropos: " (format "%s" (scwm-symbol-at-point))))) (with-output-to-temp-buffer "*Apropos*" (with-current-buffer "*Apropos*" (princ "Click mouse-2 for documentation.\n\nSCWM apropos `") (with-face0 'highlight (princ pat)) (princ "':\n\n") (scwm-safe-call "apropos" (concat "\"" pat "\"") standard-output) (goto-char (point-max)) ; kill `#' (delete-region (point) (progn (beginning-of-line) (point))) (goto-char 1) (forward-line 4) (sort-lines nil (point) (point-max)) ;; make the symbols clickable (let ((props '(action scwm-documentation mouse-face highlight face italic)) p0 p1 p2 str) (while (not (eobp)) (setq p0 (point) p1 (search-forward ": ") p2 (1- (re-search-forward "\\s ")) str (buffer-substring-no-properties p1 p2)) (add-text-properties p0 p2 (cons 'item (cons str props))) (forward-char -1) ; in case the line just ended (forward-line 1))) (apropos-mode) (setq truncate-lines t)))) ;; info interface (defvar scwm-info-file-list '(("r4rs" . "Index") ("guile-ref" . "Procedure Index") ("guile-ref" . "Variable Index") ("scwm" . "Function Index") ("scwm" . "Variable Index")) "AssocList of Info files that describe Guile procedures. An element is of the form (FILE . NODE).") (defun scwm-find-guile-procedure-nodes (procedure) "Return a list of locations documenting PROCEDURE. The variable `scwm-info-file-list' defines heuristics for which Info manual to try. The locations are of the format used in `Info-history', i.e. (FILENAME NODENAME BUFFERPOS)" (let ((where '()) (cmd-desc (concat "^\\* " (regexp-quote procedure) ":\\s *\\(.*\\)\\.$")) (file-list scwm-info-file-list)) (save-window-excursion (save-excursion (while file-list (let ((file (car (car file-list))) (index (cdr (car file-list)))) (setq file-list (cdr file-list)) (ignore-errors (Info-find-node file index) ;; Take the index node off the Info history. (setq Info-history (cdr Info-history)) (goto-char (point-max)) (while (re-search-backward cmd-desc nil t) (setq where (cons (list Info-current-file (buffer-substring (match-beginning 1) (match-end 1)) 0) where)))))))) (let ((ww (get-buffer-window "*info*" t))) (when ww (quit-window nil ww))) where)) ;;;###autoload (defun scwm-goto-guile-procedure-node (procedure) "Go to the Info node in the Guile manual for procedure PROCEDURE. The procedure is found by looking up in the Guile Reference manual's Procedure Index or in another manual found via the variable `scwm-info-file-list'." (interactive (list (scwm-complete-symbol))) (let ((where (scwm-find-guile-procedure-nodes procedure))) (unless where (error "Couldn't find documentation for %s" procedure)) (let ((num-matches (length where))) ;; Get Info running, and pop to it in another window. (save-window-excursion (info)) (pop-to-buffer "*info*") ;; (filename nodename bufferpos) (Info-find-node (car (car where)) (car (cdr (car where)))) (when (> num-matches 1) ;; Info-find-node already pushed (car where) onto ;; Info-history. Put the other nodes that were found on ;; the history. (setq Info-history (nconc (cdr where) Info-history)) (message "Found %d other entr%s. Use %s to see %s." (1- num-matches) (if (> num-matches 2) "ies" "y") (substitute-command-keys "\\[Info-last]") (if (> num-matches 2) "them" "it")))))) ;; fontifications ;; -------------- (cond ((boundp 'running-xemacs) (put 'scwm-mode 'font-lock-defaults (get 'scheme-mode 'font-lock-defaults))) ((and (string-lessp emacs-version "20.3") (boundp 'font-lock-defaults-alist)) (unless (assq 'scwm-mode font-lock-defaults-alist) (setq font-lock-defaults-alist (cons (cons 'scwm-mode (cdr (assq 'scheme-mode font-lock-defaults-alist))) font-lock-defaults-alist))))) (provide 'scwm) ;;; scwm ends here --4FWgQV6u/C Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Eli Barzilay: Maze is Life! --4FWgQV6u/C-- From owner-scwm-discuss@mit.edu Tue Dec 8 17:50:35 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id RAA03508 for scwm-discuss-outgoing; Tue, 8 Dec 1998 17:50:35 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id RAA03504 for ; Tue, 8 Dec 1998 17:50:33 -0500 Received: from mail.eaglets.com by relay7.UU.NET with ESMTP (peer crosschecked as: [208.235.77.228]) id QQfsxv16119; Tue, 8 Dec 1998 17:48:01 -0500 (EST) Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 08 Dec 1998 16:12:25 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 08 Dec 1998 16:12:25 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id QAA14749; Tue, 8 Dec 1998 16:12:04 -0500 To: Maciej Stachowiak Subject: config fails Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 08 Dec 1998 16:12:04 -0500 Message-ID: Lines: 13 Sender: owner-scwm-discuss@mit.edu Precedence: bulk ./configure --enable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/ ==> ltconfig: unrecognized option `--no-reexec' Try `ltconfig --help' for more information. configure: error: libtool configure failed -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. 186,000 Miles per Second. It's not just a good idea. IT'S THE LAW. From owner-scwm-discuss@mit.edu Tue Dec 8 18:49:25 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA03901 for scwm-discuss-outgoing; Tue, 8 Dec 1998 18:49:25 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA03898 for ; Tue, 8 Dec 1998 18:49:18 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA12379; Tue, 8 Dec 98 18:46:48 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Tue, 08 Dec 1998 18:29:11 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Tue, 08 Dec 1998 18:29:10 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id SAA02640; Tue, 8 Dec 1998 18:28:46 -0500 To: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Eli Barzilay's message of "Tue, 8 Dec 1998 17:38:32 -0500 (EST)" Date: 08 Dec 1998 18:28:46 -0500 Message-Id: Lines: 21 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk 1. You are using an old version of scwm.el as your base. 2. I don't understand what you mean when you say "Binds the keys properly under FSF"; scwm.el as is works fine with e20.3 and e19.34. 3. No tweak can guarantee that a file compiled with Emacs will work with XEmacs and vice versa. The elc formats are now officially incompatible, and there is no point whatsoever in trying to ignore that. Moreover, it is wrong to try to do that, as a minor upgrade in either Emacs of XEmacs can (and will!) break the tweak. 4. Please send your changes as 'diff -cbw' next time. 5. I do not understand what you are trying to accomplish with the `thing-at-point' change. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. If brute force does not work, you are not using enough. From owner-scwm-discuss@mit.edu Tue Dec 8 19:47:20 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA04195 for scwm-discuss-outgoing; Tue, 8 Dec 1998 19:47:20 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA04192 for ; Tue, 8 Dec 1998 19:47:17 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA01103; Tue, 8 Dec 98 19:44:48 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id TAA04851; Tue, 8 Dec 1998 19:44:42 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id TAA21302; Tue, 8 Dec 1998 19:44:41 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id TAA18151; Tue, 8 Dec 1998 19:44:39 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13933.51191.494905.717287@horus.cs.cornell.edu> Date: Tue, 8 Dec 1998 19:44:39 -0500 (EST) To: sds@goems.com Cc: scwm-discuss@mit.edu Subject: Re: scwm.el In-Reply-To: References: <13933.43624.819069.356827@horus.cs.cornell.edu> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Dec 8, Sam Steingold wrote: > 1. You are using an old version of scwm.el as your base. Yes, I saw that now, but the changes are minor. > 2. I don't understand what you mean when you say "Binds the keys > properly under FSF"; scwm.el as is works fine with e20.3 and e19.34. Ooops - I just realized that the whole thing with the keys was a result of an extremely stupid mistake I made which is quite unrelated. I promise I'll stand in the corner 10 minutes. > 3. No tweak can guarantee that a file compiled with Emacs will work with > XEmacs and vice versa. The elc formats are now officially > incompatible, and there is no point whatsoever in trying to ignore > that. Moreover, it is wrong to try to do that, as a minor upgrade in > either Emacs of XEmacs can (and will!) break the tweak. The only incompatibility I saw between the compiled files is FSF's usage of the #N=/#N# syntax. By avoiding macros that call make-symbol you don't get this proble - this is far from being an elegant solution, but working on installation scripts that check which Emacs version you have add even more complexity... Using a single compilation is so much simpler If anything will change, I'd expect XEmacs to also implement that syntax. There were other differences like FSF using escape sequences, but both could live with them. If you have a reference to were it is "officially" defined to be incompatible, I'm interested. > 4. Please send your changes as 'diff -cbw' next time. Didn't do that because they were just simple suggestion and also because of laziness. Will do next time. > 5. I do not understand what you are trying to accomplish with the > `thing-at-point' change. Here is were it started: On Dec 6, Todd Larason wrote: > When I accidentally get an FSF-compiled scwm.elc loaded into > XEmacs, I instead get an error about id-select not being defined. the problem is that the old code compiled differently on XEmacs or on FSF -- it uses an eval-when-compile inside an (unless (fboundp 'thing-at-point) ...). Maybe replacing it with eval-and-compile will also work fine. -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Tue Dec 8 20:44:30 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id UAA04572 for scwm-discuss-outgoing; Tue, 8 Dec 1998 20:44:30 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id UAA04569 for ; Tue, 8 Dec 1998 20:44:27 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA05846; Tue, 8 Dec 98 20:41:56 EST Received: (qmail 26755 invoked by uid 501); 9 Dec 1998 01:41:55 -0000 Message-Id: <19981208174154.A19170@molehill.org> Date: Tue, 8 Dec 1998 17:41:54 -0800 From: Todd Larason To: Eli Barzilay Cc: scwm-discuss list Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <13933.43624.819069.356827@horus.cs.cornell.edu>; from Eli Barzilay on Tue, Dec 08, 1998 at 05:38:32PM -0500 X-Kibo: Kibology is deadly serious. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981208, Eli Barzilay wrote: Content-Description: message body text > Since my last message about scwm.el was silently ignored, I went ahead > to modify the file. Sorry about that. I have a bad habit of marking messages which require more thought than I have immediately available as 'read & answer later', and 'later' is sometimes much later. > * Compiles on & loads properly on both XEmacs 20.4 and FSF 20.3/19.34 > whether compiled with FSF or XEmacs (the only problem is that code > that is compiled under XEmacs has an initials expression that > signals an error when loading under v.19). Thanks! If this works reliably, that'd be great. Does anybody use an XEmacs 21.0 beta or a beta of whatever the next FSF release is? It would be nice to verify it works with those, too. -- ICQ UIN: 30857997 From owner-scwm-discuss@mit.edu Tue Dec 8 21:33:26 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA04954 for scwm-discuss-outgoing; Tue, 8 Dec 1998 21:33:26 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA04951 for ; Tue, 8 Dec 1998 21:33:23 -0500 Received: from [207.17.169.8] by MIT.EDU with SMTP id AA17210; Tue, 8 Dec 98 21:30:51 EST Received: (qmail 26980 invoked by uid 501); 9 Dec 1998 02:30:48 -0000 Message-Id: <19981208183048.A26904@molehill.org> Date: Tue, 8 Dec 1998 18:30:48 -0800 From: Todd Larason To: sds@goems.com, Maciej Stachowiak Subject: Re: config fails References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sam Steingold on Tue, Dec 08, 1998 at 04:12:04PM -0500 X-Kibo: I was old. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981208, Sam Steingold wrote: > ./configure --enable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/ > > ==> > > ltconfig: unrecognized option `--no-reexec' > Try `ltconfig --help' for more information. > configure: error: libtool configure failed I started seeing this today on a machine that's recently been reinstalled. It looks like libtool1.2b doesn't get along with the ltconfig/ltmain.sh in the scwm tree. the libtool.m4 automake rule has references to --no-reexec, which the 1.2 libtool doesn't know about. I apparently solved it for me by just removing ltconfig and ltmain.sh. configure complained, but replaced them with working copies (well, symlinks). Maybe they should be removed from the tree, treated as generated source. -- ICQ UIN: 105667186 From owner-scwm-discuss@mit.edu Wed Dec 9 07:14:47 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id HAA08311 for scwm-discuss-outgoing; Wed, 9 Dec 1998 07:14:47 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id HAA08308 for ; Wed, 9 Dec 1998 07:14:34 -0500 Received: from kanga.amtp.cam.ac.uk by MIT.EDU with SMTP id AA08277; Wed, 9 Dec 98 07:11:58 EST Received: from wimp.amtp.cam.ac.uk [131.111.17.101] (ig206) by kanga.amtp.cam.ac.uk with esmtp (Exim 1.73 #1) id 0zniSd-0003zj-00; Wed, 9 Dec 1998 12:11:19 +0000 Received: from localhost by wimp.amtp.cam.ac.uk (8.8.5/DAMTP 2.3-Client (wimp.amtp.cam.ac.uk MX-hub grey.amtp.cam.ac.uk)) id MAA17266; Wed, 9 Dec 1998 12:11:18 GMT Date: Wed, 9 Dec 1998 12:11:18 +0000 (GMT) From: Ian Grant X-Sender: ig206@wimp.amtp.cam.ac.uk To: Maciej Stachowiak Cc: jtl@molehill.org, scwm-discuss@mit.edu, guile@cygnus.com Subject: Re: Buggy Rawhide guile-1.3 packages In-Reply-To: <199812082033.PAA02397@vicarious-existence.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk I think that the guile-devel RPM should install the two .m4 macros (guile and qthreads) because people writing independently distributed guile modules will need aclocal/automake to find references to these macros in configure.in and insert the definitions into aclocal.m4. aclocal finds the definitions in PREFIX/share/aclocal or on its -I path. There shouldn't be a dependency on m4 though because people are not obliged to use aclocal/automake (perhaps they should be though.) Ian On Tue, 8 Dec 1998, Maciej Stachowiak wrote: > > [ cc'd to guile list so Guile people can confirm the packaging bugs > before someone reports them ] > > Red Hat Rawhide's guile-1.3-1 and guile-devel-1.3-1 RPM packages have the > following packaging bugs as far as I can tell from the Rawhide RPM > list at > > http://rufus.w3.org/linux/RPM/rawhide/1.0/i386/RedHat/RPMS/ > > (for those who may not know, the distinction between a regular and > -devel package is that you should need only the non -devel package to > run binaries linked against the package, but -devel should provide > everything else you need to compile programs from source that link > against the package) > > * guile-devel-1.3-1 does not include guile-config (neither does > guile-1.3) > > * guile-snarf is in guile-1.3-1 instead of in guile-devel-1.3-1 > > * guile-1.3-1 installs the Guile m4 macros (guile.m4, qthreads.m4), I > believe that neither package should install these but if one does it > should be guile-devel. > > * The guile-1.3-1 package depends on the umb-scheme package for no > apparent reason. > > * The guile-devel-1.3-1 package depends on the m4 package, which is > wrong since it includes no m4 macros (although guile-1.3 does, and > does not depend on m4). > > * The guile-devel-1.3-1 package does not depend on the guile package, > I believe this is wrong on general principle but will be even more > wrong when guile-config is added to it since that is a Guile script. > > > I will report these unless Todd wants to, since he discovered the > bugs. > > I think we will need to add a warning to the scwm install docs not to > use the guile-1.3 RPMs from rawhide for the time being. > > - Maciej Stachowiak > > From owner-scwm-discuss@mit.edu Wed Dec 9 09:29:53 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA08848 for scwm-discuss-outgoing; Wed, 9 Dec 1998 09:29:53 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA08845 for ; Wed, 9 Dec 1998 09:29:49 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA21298; Wed, 9 Dec 98 09:27:11 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 09 Dec 1998 09:26:30 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 09 Dec 1998 09:26:30 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id JAA07533; Wed, 9 Dec 1998 09:27:11 -0500 To: Maciej Stachowiak Subject: Re: config fails References: <19981208183048.A26904@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Tue, 8 Dec 1998 18:30:48 -0800" Date: 09 Dec 1998 09:27:11 -0500 Message-Id: Lines: 35 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981208183048.A26904@molehill.org> >>>> On the subject of "Re: config fails" >>>> Sent on Tue, 8 Dec 1998 18:30:48 -0800 >>>> Honorable Todd Larason writes: >> On 981208, Sam Steingold wrote: >> > ./configure --enable-maintainer-mode --with-lispdir=/usr/share/emacs/site-lisp/ >> > >> > ==> >> > >> > ltconfig: unrecognized option `--no-reexec' >> > Try `ltconfig --help' for more information. >> > configure: error: libtool configure failed >> >> I started seeing this today on a machine that's recently been reinstalled. >> >> It looks like libtool1.2b doesn't get along with the ltconfig/ltmain.sh in the >> scwm tree. the libtool.m4 automake rule has references to --no-reexec, which >> the 1.2 libtool doesn't know about. >> >> I apparently solved it for me by just removing ltconfig and ltmain.sh. >> configure complained, but replaced them with working copies (well, symlinks). this didn't happen for me: ./ltconfig: ./ltconfig: No such file or directory configure: error: libtool configure failed Also, I just noticed that configure creates empty files /tmp/acout.a$$ and doesn't delete them on failure. Is this a known bug? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A professor is someone who talks in someone else's sleep. From owner-scwm-discuss@mit.edu Wed Dec 9 09:37:43 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA08920 for scwm-discuss-outgoing; Wed, 9 Dec 1998 09:37:43 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA08917 for ; Wed, 9 Dec 1998 09:37:41 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA24011; Wed, 9 Dec 98 09:35:03 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 09 Dec 1998 09:33:46 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 09 Dec 1998 09:33:46 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id JAA07547; Wed, 9 Dec 1998 09:34:26 -0500 To: Todd Larason Cc: Eli Barzilay , scwm-discuss list Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> <19981208174154.A19170@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Tue, 8 Dec 1998 17:41:54 -0800" Date: 09 Dec 1998 09:34:26 -0500 Message-Id: Lines: 36 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981208174154.A19170@molehill.org> >>>> On the subject of "Re: scwm.el" >>>> Sent on Tue, 8 Dec 1998 17:41:54 -0800 >>>> Honorable Todd Larason writes: >> On 981208, Eli Barzilay wrote: >> >> > * Compiles on & loads properly on both XEmacs 20.4 and FSF 20.3/19.34 >> > whether compiled with FSF or XEmacs (the only problem is that code >> > that is compiled under XEmacs has an initials expression that >> > signals an error when loading under v.19). >> >> Thanks! If this works reliably, that'd be great. ***It CANNOT work reliably*** >> Does anybody use an XEmacs 21.0 beta or a beta of whatever the next FSF >> release is? It would be nice to verify it works with those, too. This is a pipe dream. Starting with e20 and x20, the fact that both emacsen call byte compiled files the same - *.elc - is merely an accident. You don't expect that the code compiled with CLISP will work with CMUCL, similarly you cannot expect binary compatibility between XEmacs and Emacs. Sure, *accidentally*, sometimes, that might work, but the maintainers of both versions said that the binary compatibility is out, thus we might as well forget about it. BTW, some of the things Eli was "fixing" were there **intentionally**: I want the file compiled with Emacs to be optimized for Emacs and file compiled with XEmacs to be optimized for XEmacs. I don't want the file to "maybe sometimes work with both if we do these dozen stranges tweaks". -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Modern man is the missing link between apes and human beings. From owner-scwm-discuss@mit.edu Wed Dec 9 09:43:28 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id JAA08992 for scwm-discuss-outgoing; Wed, 9 Dec 1998 09:43:28 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id JAA08989 for ; Wed, 9 Dec 1998 09:43:26 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA25863; Wed, 9 Dec 98 09:40:48 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 09 Dec 1998 09:40:08 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 09 Dec 1998 09:40:08 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id JAA07561; Wed, 9 Dec 1998 09:40:49 -0500 To: Eli Barzilay Cc: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> <13933.51191.494905.717287@horus.cs.cornell.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Eli Barzilay's message of "Tue, 8 Dec 1998 19:44:39 -0500 (EST)" Date: 09 Dec 1998 09:40:49 -0500 Message-Id: Lines: 50 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <13933.51191.494905.717287@horus.cs.cornell.edu> >>>> On the subject of "Re: scwm.el" >>>> Sent on Tue, 8 Dec 1998 19:44:39 -0500 (EST) >>>> Honorable Eli Barzilay writes: >> On Dec 8, Sam Steingold wrote: Please read this again: >> > 3. No tweak can guarantee that a file compiled with Emacs will work with >> > XEmacs and vice versa. The elc formats are now officially >> > incompatible, and there is no point whatsoever in trying to ignore >> > that. Moreover, it is wrong to try to do that, as a minor upgrade in >> > either Emacs of XEmacs can (and will!) break the tweak. I understand that this is a sorry state, but we have to live with it. DTRT: use the code I posted recently to install 2 byte compiled versions in directories accessed by only one emacs. >> If you have a reference to were it is "officially" defined to be >> incompatible, I'm interested. There was a discussion of this on news:comp.emacs.xemacs. the goal of binary compatibility was dropped by the XEmacs' maintainers about a year ago (RMS never cared about this). >> > 5. I do not understand what you are trying to accomplish with the >> > `thing-at-point' change. >> >> Here is were it started: >> >> On Dec 6, Todd Larason wrote: >> > When I accidentally get an FSF-compiled scwm.elc loaded into >> > XEmacs, I instead get an error about id-select not being defined. >> >> the problem is that the old code compiled differently on XEmacs or on >> FSF -- it uses an eval-when-compile inside an (unless (fboundp >> 'thing-at-point) ...). Maybe replacing it with eval-and-compile will >> also work fine. This was intentional: files compiled with Emacs are for Emacs, files compiled for XEmacs are for XEmacs. Binary compatibility is out. Forget it. -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. War doesn't determine who's right, just who's left. From owner-scwm-discuss@mit.edu Wed Dec 9 13:32:13 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id NAA10140 for scwm-discuss-outgoing; Wed, 9 Dec 1998 13:32:13 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id NAA10137 for ; Wed, 9 Dec 1998 13:32:10 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA11228; Wed, 9 Dec 98 13:29:31 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id NAA26552; Wed, 9 Dec 1998 13:29:30 -0500 (EST) Message-Id: <199812091829.NAA26552@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: that unruly netscape In-Reply-To: Your message of "Sat, 05 Dec 1998 20:48:06 EST." <199812060148.UAA04626@M66-080-21.mit.edu> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-18336116570" Date: Wed, 09 Dec 1998 13:19:23 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk This is a multipart MIME message. --==_Exmh_-18336116570 Content-Type: text/plain; charset=us-ascii In message <199812060148.UAA04626@M66-080-21.mit.edu>, Maciej Stachowiak writes : > >arturo@infonautics.com writes: >> Using netscape4.03 under Irix. >> >> Is there any trick to getting it to obey the icon box? >> > >Using system.scwmrc, netscape obeys the icon box just fine on Solaris >for me. I will try it on Irix shortly but I don't expect to see a >difference. Operator error on my part. I had the following in my resource file. netscape*iconX: +70 netscape*iconY: -40 IIRC you said in another thread that scwm doesn't do negative placements the way other window-managers do? > >Regarding your other previously reported problem with icons, when I >iconify a window with sticky icons, move the icon manually, deiconify >the window, and reiconify it, the icon ends up where I moved it >manually. Here's an attached wininfo on the icon both before and after I sticky the window. Note that the icon doesn't change position until after I open and close the file. For example, I iconify then move the icon to my preferred position. Then I de-iconify. When I iconify the app the icon ends up at a different place. Oddly enough, this behavior doesn't happen with xclock or xbiff. The behavior is the same whether I use stick off the window title bar or the root menu using system-scwmrc with the following procedure used instead of the supplied stick procedure. (define (arturo-toggle-stick) (toggle-stick) (toggle-stick-icon)) For some reason the icon moves. Maybe something to do with negative coordinates? > >It seems that you are seeing all sorts of strange icon behavior that I >am not. I wish I could figure out why. > > - Maciej > So do I :-). Anything in particular you'd like me to try? --==_Exmh_-18336116570 Content-Type: text/plain ; name="mving-icon"; charset=us-ascii Content-Description: wininfos of moving icon Content-Disposition: attachment; filename="mving-icon" Script started on Wed Dec 9 13:01:27 1998 $ xwininfo -all xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x1c00114 (has no name) Root window id: 0x25 (the root window) (has no name) Parent window id: 0x25 (the root window) (has no name) 0 children. Absolute upper-left X: 1226 Absolute upper-left Y: 141 Relative upper-left X: 1226 Relative upper-left Y: 141 Width: 52 Height: 52 Depth: 24 Visual id: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +1226+141 -2+141 -2-831 +1226-831 -geometry 52x52-2+141 Bit gravity: ForgetGravity Window gravity: NorthWestGravity Backing-store hint: NotUseful Backing-planes to be preserved: 0xffffffff Backing pixel: 0 Save-unders: No Someone wants these events: KeyPress ButtonPress ButtonRelease EnterWindow Exposure VisibilityChange FocusChange Do not propagate these events: Override redirection?: No No window manager hints defined No normal window size hints defined No zoom window size hints defined No window shape defined No border shape defined $ echo after stickifying after stickifying $ r x xwininfo -all xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x1c00114 (has no name) Root window id: 0x25 (the root window) (has no name) Parent window id: 0x25 (the root window) (has no name) 0 children. Absolute upper-left X: 1226 Absolute upper-left Y: 141 Relative upper-left X: 1226 Relative upper-left Y: 141 Width: 52 Height: 52 Depth: 24 Visual id: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +1226+141 -2+141 -2-831 +1226-831 -geometry 52x52-2+141 Bit gravity: ForgetGravity Window gravity: NorthWestGravity Backing-store hint: NotUseful Backing-planes to be preserved: 0xffffffff Backing pixel: 0 Save-unders: No Someone wants these events: KeyPress ButtonPress ButtonRelease EnterWindow Exposure VisibilityChange FocusChange Do not propagate these events: Override redirection?: No No window manager hints defined No normal window size hints defined No zoom window size hints defined No window shape defined No border shape defined $ echo now I open and close the window "(de-iconify then iconify)" now I open and close the window (de-iconify then iconify) $ echo note how the geometry changes note how the geometry changes $ r xwininfo -all xwininfo: Please select the window about which you would like information by clicking the mouse in that window. xwininfo: Window id: 0x1c00114 (has no name) Root window id: 0x25 (the root window) (has no name) Parent window id: 0x25 (the root window) (has no name) 0 children. Absolute upper-left X: 503 Absolute upper-left Y: 78 Relative upper-left X: 503 Relative upper-left Y: 78 Width: 52 Height: 52 Depth: 24 Visual id: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +503+78 -725+78 -725-894 +503-894 -geometry 52x52+503+78 Bit gravity: ForgetGravity Window gravity: NorthWestGravity Backing-store hint: NotUseful Backing-planes to be preserved: 0xffffffff Backing pixel: 0 Save-unders: No Someone wants these events: KeyPress ButtonPress ButtonRelease EnterWindow Exposure VisibilityChange FocusChange Do not propagate these events: Override redirection?: No No window manager hints defined No normal window size hints defined No zoom window size hints defined No window shape defined No border shape defined script done on Wed Dec 9 13:02:36 1998 --==_Exmh_-18336116570 Content-Type: text/plain; charset=us-ascii ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com --==_Exmh_-18336116570-- From owner-scwm-discuss@mit.edu Wed Dec 9 14:38:22 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA10471 for scwm-discuss-outgoing; Wed, 9 Dec 1998 14:38:22 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id OAA10465; Wed, 9 Dec 1998 14:38:11 -0500 Message-Id: <199812091938.OAA10465@vicarious-existence.mit.edu> To: Arturo Perez cc: scwm-discuss@mit.edu Subject: Re: that unruly netscape In-reply-to: Your message of "Wed, 09 Dec 1998 13:19:23 EST." <199812091829.NAA26552@ns1.infonautics.com> Date: Wed, 09 Dec 1998 14:38:10 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk arturo@infonautics.com writes: > This is a multipart MIME message. > > --==_Exmh_-18336116570 > Content-Type: text/plain; charset=us-ascii > > In message <199812060148.UAA04626@M66-080-21.mit.edu>, Maciej Stachowiak writes > >Using system.scwmrc, netscape obeys the icon box just fine on Solaris > >for me. I will try it on Irix shortly but I don't expect to see a > >difference. > > Operator error on my part. I had the following in my resource file. > netscape*iconX: +70 > netscape*iconY: -40 > > IIRC you said in another thread that scwm doesn't do negative placements > the way other window-managers do? > No, the discussion about negative coordinates was not entirely related. If you use them in a .resource fille they will work properly. > The behavior is the same whether I use stick off the window > title bar or the root menu using system-scwmrc with the following procedure > used instead of the supplied stick procedure. > > (define (arturo-toggle-stick) > (toggle-stick) > (toggle-stick-icon)) > > For some reason the icon moves. Maybe something to do with negative > coordinates? > Ah, I see - it only happens when _window_ is sticky, not the icon. I can reproduce it now. I will try to fix it when I can. Thanks for the information! - Maciej From owner-scwm-discuss@mit.edu Wed Dec 9 18:28:59 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA11801 for scwm-discuss-outgoing; Wed, 9 Dec 1998 18:28:59 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA11797 for ; Wed, 9 Dec 1998 18:28:55 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA09815; Wed, 9 Dec 98 18:26:12 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Thu, 10 Dec 1998 00:25:38 +0100 Received: from enterprise.osterwald.de (root@h51.ts1.uni-hannover.de [130.75.249.51]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id AAA07902; Thu, 10 Dec 1998 00:25:36 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id AAA17244; Thu, 10 Dec 1998 00:21:35 +0100 Date: Thu, 10 Dec 1998 00:21:35 +0100 Message-Id: <199812092321.AAA17244@enterprise.osterwald.de> From: Heiko Muenkel To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Bug in scwm 0.9 beta 1: Missing symbol gh_reverse X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H search starts here: . . ../include /usr/X11R6/include /prog/window-manager/include /prog/window-manager/include /prog/gnu/Global/include /prog/lesstif/Motif-1.2/include . /usr/local/include /usr/i486-linux/include /usr/lib/gcc-lib/i486-linux/2.7.2.1/include /usr/include End of search list. /usr/lib/gcc-lib/i486-linux/2.7.2.1/cc1 /tmp/cca17240.i -fno-strength-reduce -quiet -dumpbase callbacks.c -g -O2 -version -o /tmp/cca17240.s GNU C version 2.7.2.1 (i386 Linux/ELF) compiled by GNU C version 2.7.2.1. callbacks.c: In function `scwm_handle_error': callbacks.c:57: `scm_the_last_stack_var' undeclared (first use this function) callbacks.c:57: (Each undeclared identifier is reported only once callbacks.c:57: for each function it appears in.) From owner-scwm-discuss@mit.edu Wed Dec 9 18:29:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id SAA11805 for scwm-discuss-outgoing; Wed, 9 Dec 1998 18:29:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id SAA11794 for ; Wed, 9 Dec 1998 18:28:55 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA09773; Wed, 9 Dec 98 18:26:01 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Thu, 10 Dec 1998 00:25:36 +0100 Received: from enterprise.osterwald.de (root@h51.ts1.uni-hannover.de [130.75.249.51]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id AAA07899; Thu, 10 Dec 1998 00:25:34 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id AAA17229; Thu, 10 Dec 1998 00:12:30 +0100 Date: Thu, 10 Dec 1998 00:12:30 +0100 Message-Id: <199812092312.AAA17229@enterprise.osterwald.de> From: Heiko Muenkel To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H; Wed, 9 Dec 1998 18:50:58 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA01994; Wed, 9 Dec 98 18:48:17 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id SAA05293; Wed, 9 Dec 1998 18:48:10 -0500 (EST) Received: from horus.cs.cornell.edu (HORUS.CS.CORNELL.EDU [128.84.254.60]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id SAA07341; Wed, 9 Dec 1998 18:48:09 -0500 (EST) Received: (from eli@localhost) by horus.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id SAA19641; Wed, 9 Dec 1998 18:48:08 -0500 (EST) X-Authentication-Warning: horus.cs.cornell.edu: eli set sender to eli@horus.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13935.3128.575364.456980@horus.cs.cornell.edu> Date: Wed, 9 Dec 1998 18:48:08 -0500 (EST) To: sds@goems.com Cc: Eli Barzilay , scwm-discuss@mit.edu Subject: Re: scwm.el In-Reply-To: References: <13933.43624.819069.356827@horus.cs.cornell.edu> <13933.51191.494905.717287@horus.cs.cornell.edu> X-Mailer: VM 6.62 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Dec 9, Sam Steingold wrote: > I understand that this is a sorry state, but we have to live with it. > DTRT: use the code I posted recently to install 2 byte compiled versions > in directories accessed by only one emacs. Yes, it does sound like a *very* sorry state. I guess that you can call my hack attempt something useful only for people that try to keep their environment working with both XEmacs and FSF. I [still] believe that it is useful because I think that scwm.el is probably not going to do a lot more than it does right now (so no danger of adding more & more hacks to keep it working in both), and also that the elc formats will not diverge _too_ much (maybe that's too hopeful, but I sure hope that I'll be able to use my environment conveniently under both). > There was a discussion of this on news:comp.emacs.xemacs. > the goal of binary compatibility was dropped by the XEmacs' maintainers > about a year ago (RMS never cared about this). And nobody else tried to make things work on both? I'm disappointed. > >> the problem is that the old code compiled differently on XEmacs or on > >> FSF -- it uses an eval-when-compile inside an (unless (fboundp > >> 'thing-at-point) ...). Maybe replacing it with eval-and-compile will > >> also work fine. > This was intentional: files compiled with Emacs are for Emacs, files > compiled for XEmacs are for XEmacs. I really fail to see the great optimization here. By doing (eval-and-compile (unless (fboundp 'thing-at-point) ;; pacify the compiler (XEmacs only) (eval-when-compile (autoload 'id-select-symbol "id-select")) ...) all you save (with the eval-when-compile) is including that autoload call in the byte-compiled code (not any runtime since the unless is used anyway). I think that this is minor enough so if someone does have problems with this as Todd did, then it should be fixed (unless you _want_ incompatibility so people will be forced to compile with their own emacs). -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Wed Dec 9 19:19:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA12243 for scwm-discuss-outgoing; Wed, 9 Dec 1998 19:19:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA12240 for ; Wed, 9 Dec 1998 19:19:40 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA21606; Wed, 9 Dec 98 19:16:54 EST Received: (qmail 2217 invoked by uid 501); 10 Dec 1998 00:17:05 -0000 Message-Id: <19981209161705.A2014@molehill.org> Date: Wed, 9 Dec 1998 16:17:05 -0800 From: Todd Larason To: Heiko Muenkel , Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 References: <199812092312.AAA17229@enterprise.osterwald.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812092312.AAA17229@enterprise.osterwald.de>; from Heiko Muenkel on Thu, Dec 10, 1998 at 12:12:30AM +0100 X-Kibo: Does conflict between emotions and radiation fiddle with the Void? True or False? You be the judge! Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981210, Heiko Muenkel wrote: > As you can see, I had some problems with the installation. I'm not > sure, but I think, that -lreadline and -lncurses were not in the > original call of the above linker command. My libreadline has > undefined symbols (eg tputs), which are defined in libncurses. There's > no check for libncurses in the configure of guile. Therefore it fails > finding libreadline. ohh...this would certainly explain it. You probably should update guile-config too, so other guile-using apps can link properly. -- ICQ UIN: 116537383 From owner-scwm-discuss@mit.edu Wed Dec 9 19:21:57 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id TAA12265 for scwm-discuss-outgoing; Wed, 9 Dec 1998 19:21:57 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id TAA12262 for ; Wed, 9 Dec 1998 19:21:56 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA22105; Wed, 9 Dec 98 19:19:13 EST Received: (qmail 2231 invoked by uid 501); 10 Dec 1998 00:19:31 -0000 Message-Id: <19981209161931.B2014@molehill.org> Date: Wed, 9 Dec 1998 16:19:31 -0800 From: Todd Larason To: sds@goems.com, Maciej Stachowiak Subject: Re: config fails References: <19981208183048.A26904@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sam Steingold on Wed, Dec 09, 1998 at 09:27:11AM -0500 X-Kibo: I think you're nonexistant some of the time. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I said: > >> I apparently solved it for me by just removing ltconfig and ltmain.sh. > >> configure complained, but replaced them with working copies (well, symlinks). I'm sorry, I misspoke It was one of the tools in autogen.sh that complained but replaced it, probably autoconf. > Also, I just noticed that configure creates empty files /tmp/acout.a$$ > and doesn't delete them on failure. Is this a known bug? I hadn't heard of it, but I do have one such file...owned by root though, so it's not from scwm. A general autoconf bug it looks? -- ICQ UIN: 41538803 From owner-scwm-discuss@mit.edu Wed Dec 9 21:36:09 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id VAA13068 for scwm-discuss-outgoing; Wed, 9 Dec 1998 21:36:09 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id VAA13065 for ; Wed, 9 Dec 1998 21:36:05 -0500 Received: from M2-032-4.MIT.EDU by MIT.EDU with SMTP id AA19161; Wed, 9 Dec 98 21:33:21 EST Received: by m2-032-4.mit.edu (SMI-8.6/4.7) id VAA23254; Wed, 9 Dec 1998 21:33:22 -0500 Message-Id: <199812100233.VAA23254@m2-032-4.mit.edu> To: scwm-discuss@mit.edu Subject: Re: scwm.el In-Reply-To: Your message of "Wed, 09 Dec 1998 18:48:08 EST." <13935.3128.575364.456980@horus.cs.cornell.edu> Date: Wed, 09 Dec 1998 21:33:22 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk I don't know much about the minutiae of emacs, but as the closest thing scwm has to a dictator, I feel obliged to put in a few words. The facts as I know them are the following: 1) Emacs and XEmacs bytecodes have appeared to be incompatible in various ways in the past. 2) The Emacs and XEmacs maintainers are on record as having no commitment to maintain any degree of bytecode or even source compatability among different emacsen, thus attempts to share bytecode could break unexpectedly at any time. 3) Sam is in charge of scwm.el and he's generally been right before about how to make it work. Thus, I think we should use Sam's posted solution to compiling separately for Emacs and XEmacs for systems that don't provide a solution to this problem. Arguably this should be made part of the regular scwm install process but that is probably harder to do than just doing it for binary packages. I'll also grant that this is a pretty lame solution, but barring a commitment from one side or the other to keep bytecodes compatible, there's not really a better choice. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 10 02:40:37 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA17503 for scwm-discuss-outgoing; Thu, 10 Dec 1998 02:40:37 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA17500 for ; Thu, 10 Dec 1998 02:40:33 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA08114; Thu, 10 Dec 98 02:37:48 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id XAA09615; Wed, 9 Dec 1998 23:37:45 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id XAA00191; Wed, 9 Dec 1998 23:37:42 -0800 To: Todd Larason Cc: Maciej Stachowiak , "Carl R. Witty" , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060409.XAA04827@M66-080-21.mit.edu> <19981205214407.A18442@molehill.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: cwitty@newtonlabs.com (Carl R. Witty) Date: 09 Dec 1998 23:37:39 -0800 In-Reply-To: Todd Larason's message of "Sat, 5 Dec 1998 21:44:07 -0800" Message-Id: Lines: 29 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > On 981205, Maciej Stachowiak wrote: > > As another random thought I think all the various menu style options > > and menu looks should be unified, and all directly appearance-related > > data should be kept in a menu-look object. The menu contructor would > > take only the title, the look, and the items. > > I really like this idea. > > Menu look objects would be augmented with the things that are currently > stylish things, and would keep their 'extra' argument. There would need to be > mutators for the various items, and for whatever else the look supports. If somebody would write up a proposed API for the new menu looks, I might take a shot at implementing it. (No promises though; I'm extremely busy at work for the foreseeable future.) My big question is that it seems like the various "slots" of the look are interrelated in "interesting" ways. For instance, should there be separate mutators to set circle-pie-menu-look vs. xpm-shaped-menu-look (i.e., the menu-drawing-operations vtable) and to set what's currently called the EXTRA field of menu looks? If not, then what mutators should be provided? If so, what happens if you set the vtable to something for which the current value of the EXTRA field is invalid? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 02:51:14 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id CAA17860 for scwm-discuss-outgoing; Thu, 10 Dec 1998 02:51:14 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with SMTP id CAA17857 for ; Thu, 10 Dec 1998 02:51:12 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA24055; Thu, 10 Dec 98 02:48:24 EST Received: (qmail 2164 invoked by uid 501); 10 Dec 1998 07:49:02 -0000 Message-Id: <19981209234902.A2135@molehill.org> Date: Wed, 9 Dec 1998 23:49:02 -0800 From: Todd Larason To: "Carl R. Witty" Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060409.XAA04827@M66-080-21.mit.edu> <19981205214407.A18442@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Carl R. Witty on Wed, Dec 09, 1998 at 11:37:39PM -0800 X-Kibo: Freud is Kibotic. Sender: owner-scwm-discuss@mit.edu Precedence: bulk What I was thinking was something along the lines of: don't allow the vtable to be changed after the menulook is created. This is maybe a wart, but the difficulty in trying to make it safe and even sensible is daunting. add slots to menu-look for: side-image side-image-align (which the more I think about it, may really want to be a scheme function, not a simple symbol) side-bg-color bg-color text-color stipple-color title-color (doesn't currently exist) bg-image title-font (doesn't currently exist) item-font add a mutator for each of these. Does Guile have any reasonable object inheritance system usable from C? Is this the MOP Maciej is pining for? It would be nice to be able to cleanly subclass this and get rid of 'extra'. I'd also want to add per-vtable mutators for whatever's in the extra field for the code. On top of the primitive mutators, an interface similar to the decor/style interface: (define new-menu-style (make-menu-style #:use-menu-style default-menu-style #:bg-image "wh_marble.xpm" #:side-image "linux_98.xpm" #:side-image-align (lambda (picsize menusize) (- menusize picsize)))) yadda yadda yadda create some menus using it decide you want a different background for the already-defined menus (with-menu-style new-menu-style (set-menu-bg-image! (make-image "bk_marble.xpm))) On 981209, Carl R. Witty wrote: > Todd Larason writes: > > > On 981205, Maciej Stachowiak wrote: > > > As another random thought I think all the various menu style options > > > and menu looks should be unified, and all directly appearance-related > > > data should be kept in a menu-look object. The menu contructor would > > > take only the title, the look, and the items. > > > > I really like this idea. > > > > Menu look objects would be augmented with the things that are currently > > stylish things, and would keep their 'extra' argument. There would need to be > > mutators for the various items, and for whatever else the look supports. > > If somebody would write up a proposed API for the new menu looks, I > might take a shot at implementing it. (No promises though; I'm > extremely busy at work for the foreseeable future.) > > My big question is that it seems like the various "slots" of the look > are interrelated in "interesting" ways. For instance, should there be > separate mutators to set circle-pie-menu-look vs. xpm-shaped-menu-look > (i.e., the menu-drawing-operations vtable) and to set what's currently > called the EXTRA field of menu looks? If not, then what mutators > should be provided? If so, what happens if you set the vtable to > something for which the current value of the EXTRA field is invalid? > > Carl Witty > cwitty@newtonlabs.com > -- ICQ UIN: 91631403 From owner-scwm-discuss@mit.edu Thu Dec 10 03:01:49 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA17992 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:01:49 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA17989 for ; Thu, 10 Dec 1998 03:01:46 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id XAA09835 for ; Wed, 9 Dec 1998 23:58:51 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21249; Thu, 10 Dec 1998 00:02:17 -0800 Date: Thu, 10 Dec 1998 00:02:17 -0800 Message-Id: <199812100802.AAA21249@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: patches for modules/*/Makefile.am Sender: owner-scwm-discuss@mit.edu Precedence: bulk I run scwm under Debian (using a slightly modified version of Francesco Tapparo's Debian configuration files and CVS scwm). In order for the process of building a Debian package to work correctly, I had to modify modules/*/Makefile.am as follows. Basically, I changed $(scwm_schemedir) to $(DESTDIR)$(scwm_schemedir). I also modified one instance of $(scwm_moduledir); I assume this was a mistake? Carl Witty cwitty@newtonlabs.com === cd /src/debian/scwm/scwm-cvs/modules/applefile/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/applefile/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- Makefile.am 1998/12/05 03:43:17 1.3 +++ Makefile.am 1998/12/10 07:55:03 @@ -14,9 +14,9 @@ ./make_crc_table > crc.c install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/libapplefile.la - $(LN_S) $(pkglibdir)/libapplefile.la $(scwm_schemedir)/libapplefile.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/libapplefile.la + $(LN_S) $(pkglibdir)/libapplefile.la $(DESTDIR)$(scwm_schemedir)/libapplefile.la uninstall-local: rm -f $(scwm_schemedir)/libapplefile.la === cd /src/debian/scwm/scwm-cvs/modules/background/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/background/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- Makefile.am 1998/12/05 03:43:22 1.4 +++ Makefile.am 1998/12/10 07:55:24 @@ -25,9 +25,9 @@ ETAGS_ARGS = --regex='/[ \t]*SCM_SYMBOL[ \t]*(\([^,]*\)/\1/' --regex='/[ \t]*SCWM_PROC[ \t]*(\([^,]*\),[^,]*/\1/' install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/libbackground.la - $(LN_S) $(pkglibdir)/libbackground.la $(scwm_schemedir)/libbackground.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/libbackground.la + $(LN_S) $(pkglibdir)/libbackground.la $(DESTDIR)$(scwm_schemedir)/libbackground.la uninstall-local: rm -f $(scwm_schemedir)/libbackground.la === cd /src/debian/scwm/scwm-cvs/modules/c-animation/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/c-animation/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- Makefile.am 1998/12/05 03:43:27 1.4 +++ Makefile.am 1998/12/10 07:55:44 @@ -25,9 +25,9 @@ ETAGS_ARGS = --regex='/[ \t]*SCM_SYMBOL[ \t]*(\([^,]*\)/\1/' --regex='/[ \t]*SCWM_PROC[ \t]*(\([^,]*\),[^,]*/\1/' install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/libc-animation.la - $(LN_S) $(pkglibdir)/libc-animation.la $(scwm_schemedir)/libc-animation.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/libc-animation.la + $(LN_S) $(pkglibdir)/libc-animation.la $(DESTDIR)$(scwm_schemedir)/libc-animation.la uninstall-local: rm -f $(scwm_schemedir)/libc-animation.la === cd /src/debian/scwm/scwm-cvs/modules/overlay-plane/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/overlay-plane/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- Makefile.am 1998/12/05 03:43:32 1.3 +++ Makefile.am 1998/12/10 07:55:57 @@ -25,9 +25,9 @@ ETAGS_ARGS = --regex='/[ \t]*SCM_SYMBOL[ \t]*(\([^,]*\)/\1/' --regex='/[ \t]*SCWM_PROC[ \t]*(\([^,]*\),[^,]*/\1/' install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/liboverlay-plane.la - $(LN_S) $(pkglibdir)/liboverlay-plane.la $(scwm_schemedir)/liboverlay-plane.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/liboverlay-plane.la + $(LN_S) $(pkglibdir)/liboverlay-plane.la $(DESTDIR)$(scwm_schemedir)/liboverlay-plane.la uninstall-local: rm -f $(scwm_schemedir)/liboverlay-plane.la === cd /src/debian/scwm/scwm-cvs/modules/pie-menus/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/pie-menus/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- Makefile.am 1998/12/05 03:43:35 1.3 +++ Makefile.am 1998/12/10 07:56:02 @@ -25,9 +25,9 @@ ETAGS_ARGS = --regex='/[ \t]*SCM_SYMBOL[ \t]*(\([^,]*\)/\1/' --regex='/[ \t]*SCWM_PROC[ \t]*(\([^,]*\),[^,]*/\1/' install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/liboverlay-plane.la - $(LN_S) $(pkglibdir)/liboverlay-plane.la $(scwm_schemedir)/liboverlay-plane.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/liboverlay-plane.la + $(LN_S) $(pkglibdir)/liboverlay-plane.la $(DESTDIR)$(scwm_schemedir)/liboverlay-plane.la uninstall-local: rm -f $(scwm_schemedir)/liboverlay-plane.la === cd /src/debian/scwm/scwm-cvs/modules/scwmgtkhelper/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/scwmgtkhelper/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- Makefile.am 1998/12/05 03:43:39 1.3 +++ Makefile.am 1998/12/10 07:56:06 @@ -28,9 +28,9 @@ install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_moduledir)/libscwmgtkhelper.la - $(LN_S) $(pkglibdir)/libscwmgtkhelper.la $(scwm_schemedir)/libscwmgtkhelper.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/libscwmgtkhelper.la + $(LN_S) $(pkglibdir)/libscwmgtkhelper.la $(DESTDIR)$(scwm_schemedir)/libscwmgtkhelper.la uninstall-local: rm -f $(scwm_schemedir)/libscwmgtkhelper.la === cd /src/debian/scwm/scwm-cvs/modules/xpm-menus/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u Makefile.am Index: Makefile.am =================================================================== RCS file: /anoncvs/scwm/modules/xpm-menus/Makefile.am,v retrieving revision 1.4 diff -u -r1.4 Makefile.am --- Makefile.am 1998/12/05 03:43:45 1.4 +++ Makefile.am 1998/12/10 07:56:11 @@ -25,9 +25,9 @@ ETAGS_ARGS = --regex='/[ \t]*SCM_SYMBOL[ \t]*(\([^,]*\)/\1/' --regex='/[ \t]*SCWM_PROC[ \t]*(\([^,]*\),[^,]*/\1/' install-data-hook: - $(mkinstalldirs) $(scwm_schemedir) - rm -f $(scwm_schemedir)/libxpm-menus.la - $(LN_S) $(pkglibdir)/libxpm-menus.la $(scwm_schemedir)/libxpm-menus.la + $(mkinstalldirs) $(DESTDIR)$(scwm_schemedir) + rm -f $(DESTDIR)$(scwm_schemedir)/libxpm-menus.la + $(LN_S) $(pkglibdir)/libxpm-menus.la $(DESTDIR)$(scwm_schemedir)/libxpm-menus.la uninstall-local: rm -f $(scwm_schemedir)/libxpm-menus.la From owner-scwm-discuss@mit.edu Thu Dec 10 03:03:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18026 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:03:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18023 for ; Thu, 10 Dec 1998 03:03:25 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09860 for ; Thu, 10 Dec 1998 00:00:31 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21261; Thu, 10 Dec 1998 00:03:58 -0800 Date: Thu, 10 Dec 1998 00:03:58 -0800 Message-Id: <199812100803.AAA21261@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for background.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/modules/background/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u background.c Index: background.c =================================================================== RCS file: /anoncvs/scwm/modules/background/background.c,v retrieving revision 1.3 diff -u -r1.3 background.c --- background.c 1998/12/03 07:12:04 1.3 +++ background.c 1998/12/10 08:02:03 @@ -81,6 +81,10 @@ SCWM_PROC(make_resized_image, "make-resized-image", 3, 1, 0, (image, width, height, bgcolor)) + /** Makes a new image from IMAGE of the given WIDTH and HEIGHT. +It does not scale IMAGE. If the resized image is smaller than the +original, it is cropped; if larger, the extra space in the new image +is filled with BGCOLOR. */ #define FUNC_NAME s_make_resized_image { int nw; Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 03:04:51 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18059 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:04:51 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18055 for ; Thu, 10 Dec 1998 03:04:49 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09875 for ; Thu, 10 Dec 1998 00:01:55 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21266; Thu, 10 Dec 1998 00:05:22 -0800 Date: Thu, 10 Dec 1998 00:05:22 -0800 Message-Id: <199812100805.AAA21266@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc modification for c-animation.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/modules/c-animation/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u c-animation.c Index: c-animation.c =================================================================== RCS file: /anoncvs/scwm/modules/c-animation/c-animation.c,v retrieving revision 1.3 diff -u -r1.3 c-animation.c --- c-animation.c 1998/12/05 19:22:02 1.3 +++ c-animation.c 1998/12/10 08:03:20 @@ -312,9 +312,8 @@ SCWM_PROC(animated_move_window, "animated-move-window", 2, 2, 0, (SCM x, SCM y, SCM win, SCM move_pointer_too_p)) - /** Move WIN to coordinates virtual coordinates X, Y with -animation. If X is #f, then X defaults to the current X position of -WIN. If Y is #f, then Y defaults to the current Y position of WIN. + /** Move WIN to virtual coordinates X, Y with animation. +If X or Y is #f, then do not change that coordinate during the move. If MOVE-POINTER-TOO? is specified and true, move the mouse pointer by the same amount as the window, animating the motion of the pointer along with the window. WIN defaults to the window context in the usual From owner-scwm-discuss@mit.edu Thu Dec 10 03:06:02 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18098 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:06:02 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18091 for ; Thu, 10 Dec 1998 03:06:00 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09897 for ; Thu, 10 Dec 1998 00:03:01 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21283; Thu, 10 Dec 1998 00:06:27 -0800 Date: Thu, 10 Dec 1998 00:06:27 -0800 Message-Id: <199812100806.AAA21283@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for scwmgtkhelper.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/modules/scwmgtkhelper/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u scwmgtkhelper.c Index: scwmgtkhelper.c =================================================================== RCS file: /anoncvs/scwm/modules/scwmgtkhelper/scwmgtkhelper.c,v retrieving revision 1.2 diff -u -r1.2 scwmgtkhelper.c --- scwmgtkhelper.c 1998/11/23 01:21:22 1.2 +++ scwmgtkhelper.c 1998/12/10 08:04:43 @@ -49,6 +49,7 @@ SCWM_PROC(restore_scwm_handlers, "restore-scwm-handlers", 0, 0, 0, ()) + /** Restore the scwm behavior for signals and for X errors. */ #define FUNC_NAME s_restore_scwm_handlers { newhandler(SIGINT); From owner-scwm-discuss@mit.edu Thu Dec 10 03:07:05 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18136 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:07:05 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18132 for ; Thu, 10 Dec 1998 03:07:03 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09918 for ; Thu, 10 Dec 1998 00:04:14 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21288; Thu, 10 Dec 1998 00:07:36 -0800 Date: Thu, 10 Dec 1998 00:07:36 -0800 Message-Id: <199812100807.AAA21288@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for cached-program-exists.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u cached-program-exists.scm Index: cached-program-exists.scm =================================================================== RCS file: /anoncvs/scwm/scheme/cached-program-exists.scm,v retrieving revision 1.2 diff -u -r1.2 cached-program-exists.scm --- cached-program-exists.scm 1998/10/05 00:30:11 1.2 +++ cached-program-exists.scm 1998/12/10 08:05:49 @@ -31,7 +31,9 @@ (define-public (cached-program-exists? program-name) "Return #t if PROGRAM-NAME is in the cache of programs that exist. Returns #f otherwise. If `debug-program-cache' is true, a message will -print to stdout on hits and misses." +print to stdout on hits and misses. You must call +`initialize-programs-that-exist' before calling this function; otherwise, +it reverts to the (inefficient) implementation of `program-exists?'." (if debug-program-cache (if programs-that-exist (if (member program-name programs-that-exist) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 03:08:27 1998 Received: (from mjrdmo@localhost) by vicarious-existence.mit.edu (8.8.5/8.8.5) id DAA18196 for scwm-discuss-outgoing; Thu, 10 Dec 1998 03:08:27 -0500 X-Authentication-Warning: vicarious-existence.mit.edu: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by vicarious-existence.mit.edu (8.8.5/8.8.5) with ESMTP id DAA18193 for ; Thu, 10 Dec 1998 03:08:25 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09940 for ; Thu, 10 Dec 1998 00:05:35 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21293; Thu, 10 Dec 1998 00:08:57 -0800 Date: Thu, 10 Dec 1998 00:08:57 -0800 Message-Id: <199812100808.AAA21293@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc update for doc.scm Sender: owner-scwm-discuss@mit.edu Precedence: bulk === cd /src/debian/scwm/scwm-cvs/scheme/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u doc.scm Index: doc.scm =================================================================== RCS file: /anoncvs/scwm/scheme/doc.scm,v retrieving revision 1.9 diff -u -r1.9 doc.scm --- doc.scm 1998/12/04 17:48:49 1.9 +++ doc.scm 1998/12/10 08:07:03 @@ -23,7 +23,8 @@ (define*-public (documentation func #&optional (port (current-output-port))) "Print the documentation for the string or symbol. -Return #t if found anything, #f if no documentation." +Works by searching through the files listed in `doc-files'. +Returns #t if any documentation was found, #f otherwise." (let* ((func (if (string? func) func (symbol->string func))) (head (string-append "(" func)) (len (string-length head)) From owner-scwm-discuss@mit.edu Thu Dec 10 12:26:43 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA00601 for scwm-discuss-outgoing; Thu, 10 Dec 1998 12:26:43 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id MAA00598 for ; Thu, 10 Dec 1998 12:26:35 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA09969 for ; Thu, 10 Dec 1998 00:07:14 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21307; Thu, 10 Dec 1998 00:10:36 -0800 Date: Thu, 10 Dec 1998 00:10:36 -0800 Message-Id: <199812100810.AAA21307@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: doc updates for placement.c Sender: owner-scwm-discuss@mit.edu Precedence: bulk Random doc updates on placement procedures. I also added one FIXME comment for Maciej. === cd /src/debian/scwm/scwm-cvs/scwm/ === cvs -d :pserver:anoncvs@huis-clos.mit.edu:/anoncvs diff -u placement.c Index: placement.c =================================================================== RCS file: /anoncvs/scwm/scwm/placement.c,v retrieving revision 1.47 diff -u -r1.47 placement.c --- placement.c 1998/09/25 06:20:45 1.47 +++ placement.c 1998/12/10 08:08:25 @@ -400,7 +400,11 @@ The placement is just as if SmartPlacementIsReallySmart were not in effect. That is, it tries to place the window so that it does not overlap any other. If it fails to do so, it returns #f; otherwise it -returns #t. */ +returns #t. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_smart_place_window { ScwmWindow *psw; @@ -446,7 +450,11 @@ overlap with other windows. Several parameters give different weight to various kinds of windows, but they are not tunable at runtime currently. If it fails to place the window, it -returns #f; otherwise it returns #t. */ +returns #f; otherwise it returns #t. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_clever_place_window { ScwmWindow *psw; @@ -480,7 +488,11 @@ which are incremented for the x and y coordinates, and which wrap around once a window would be forced off the screen. The placement is fairly arbitrary, but always succeeds, and so avoids user -interaction. #t is always returned. */ +interaction. #t is always returned. + +This is called as part of `default-placement-proc'. It could also be +used in user-defined placement procedures (see +`set-window-placement-proc!'). */ #define FUNC_NAME s_random_place_window { ScwmWindow *psw; @@ -515,11 +527,13 @@ This is the default placement procedure for non-transient windows. It tries `smart-place-window', `clever-place-window', `random-place-window', or `interactive-move' (to achieve interactive -placement) on WIN depending on several style flags. However, -if one of the following factors holds, the window will instead be -placed exactly as requested by the program: the position was specified -by the user, the position was specified by the program, and -#:no-PPosition-hint is not set, or the window starts iconic. */ +placement) on WIN depending on several style flags. (See +`set-smart-placement-is-really-smart!', `set-smart-placement!', +and `set-random-placement!'). However, if one of the following +factors holds, the window will instead be placed exactly as +requested by the program: the position was specified by the user, +the position was specified by the program and #:no-PPosition-hint +is not set, or the window starts iconic. */ #define FUNC_NAME s_default_placement_proc { ScwmWindow *psw; @@ -586,6 +600,8 @@ /* * Handles initial placement and sizing of a new window * Returns False in the event of a lost window. + * CRW:FIXME:MS: I'm not sure what a "lost window" is, but as far as I can + * tell, this never returns False. */ Bool PlaceWindow(ScwmWindow *psw, int Desk) Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 12:26:52 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA00609 for scwm-discuss-outgoing; Thu, 10 Dec 1998 12:26:52 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from quasar.newtonlabs.com (kirk.newtonlabs.com [206.125.74.97]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id MAA00595 for ; Thu, 10 Dec 1998 12:26:33 -0500 Received: from nebula.newtonlabs.com (cwitty@nebula.newtonlabs.com [207.55.51.23]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id AAA10073 for ; Thu, 10 Dec 1998 00:17:13 -0800 Received: (from cwitty@localhost) by nebula.newtonlabs.com (8.9.1a/8.9.1/Debian/GNU) id AAA21357; Thu, 10 Dec 1998 00:20:36 -0800 Date: Thu, 10 Dec 1998 00:20:36 -0800 Message-Id: <199812100820.AAA21357@nebula.newtonlabs.com> From: "Carl R. Witty" To: scwm-discuss@mit.edu Subject: (save-settings) from prefs-menu.scm doesn't work Sender: owner-scwm-discuss@mit.edu Precedence: bulk You probably already know about this, but: scwm> (save-settings) Backtrace: 0* [save-settings] 1 (let ((fd #)) (do (#) (# #)) ...) 2* [for-each # ... ERROR: While evaluating arguments to for-each in expression (for-each (lambda # #) settable-object-list): ERROR: Unbound variable: settable-object-list Linux nebula 2.0.35 #1 Thu Nov 19 00:04:16 PST 1998 i686 unknown Guile verion: 1.3 Libguile timestamp: Fri Dec 4 09:06:54 PST 1998 SCWM version: 0.9beta1 >From repository date: Mon Dec 7 03:14:32 EST 1998 -- $Revision: 1.1024 $ Restarted: true Display Size: 1280x1024 Desk Size: 3x3 Viewport Position: 0x0 Pointer: 239x320 Current Desk: 0 X vendor: The XFree86 Project, Inc; version: 11.0; release: 3320 X Display: Resolution: 2956x2951 Color: TrueColor (depth: 16; bits per RGB: 6) image-load-path: /usr/X11R6/include/X11/pixmaps usr/X11R6/include/X11/bitmaps /src/icons/icons /src/icons/mini-icons Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 13:30:51 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA01284 for scwm-discuss-outgoing; Thu, 10 Dec 1998 13:30:51 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA01280 for ; Thu, 10 Dec 1998 13:30:50 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA17818; Thu, 10 Dec 98 11:58:12 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id RAA23159 for scwm-discuss@mit.edu; Thu, 10 Dec 1998 17:45:30 +0100 (MET) Received: (qmail 1370 invoked by uid 115); 9 Dec 1998 12:02:05 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 09 Dec 1998 13:02:02 +0100 In-Reply-To: Sam Steingold's message of "08 Dec 1998 18:28:46 -0500" Message-Id: Lines: 19 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 08 Dec 1998 18:28:46 -0500 >>>>> Sam Steingold said: [...] Sam> The elc formats are now officially incompatible, and there is Sam> no point whatsoever in trying to ignore that. Then they should have different names. Calling them both "elc" or "compiled emacs lisp" confuses software and users. Does anybody know a forum where both Emacs and XEmacs developers are active, so I can bring this up? Or do I have to resort to private e-mail? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Dec 10 13:31:19 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA01299 for scwm-discuss-outgoing; Thu, 10 Dec 1998 13:31:19 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA01296 for ; Thu, 10 Dec 1998 13:31:18 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA18936; Thu, 10 Dec 98 12:01:05 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id RAA23160 for scwm-discuss@mit.edu; Thu, 10 Dec 1998 17:45:32 +0100 (MET) Received: (qmail 1379 invoked by uid 115); 9 Dec 1998 12:06:04 -0000 To: scwm-discuss@mit.edu Subject: Re: config fails References: <19981208183048.A26904@molehill.org> X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 09 Dec 1998 13:06:01 +0100 In-Reply-To: Todd Larason's message of "Tue, 8 Dec 1998 18:30:48 -0800" Message-Id: Lines: 22 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 8 Dec 1998 18:30:48 -0800 >>>>> Todd Larason said: Todd> I apparently solved it for me by just removing ltconfig and Todd> ltmain.sh. configure complained, but replaced them with working Todd> copies (well, symlinks). Todd> Maybe they should be removed from the tree, treated as Todd> generated source. I suspect that this will fail if there are no libtool or auto* scripts installed. Can someone with neither autoconf, automake nor libtool on their machine check this (i.e. remove ltconfig & ltmain.sh and from a nightly scwm-snapshot and try ./configure and making it)? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Dec 10 13:33:13 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA01326 for scwm-discuss-outgoing; Thu, 10 Dec 1998 13:33:13 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA01323 for ; Thu, 10 Dec 1998 13:33:12 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA05476; Thu, 10 Dec 98 13:33:08 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id KAA18052; Thu, 10 Dec 1998 10:33:05 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id KAA02701; Thu, 10 Dec 1998 10:33:05 -0800 To: Todd Larason Cc: "Carl R. Witty" , Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060409.XAA04827@M66-080-21.mit.edu> <19981205214407.A18442@molehill.org> <19981209234902.A2135@molehill.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: cwitty@newtonlabs.com (Carl R. Witty) Date: 10 Dec 1998 10:33:05 -0800 In-Reply-To: Todd Larason's message of "Wed, 9 Dec 1998 23:49:02 -0800" Message-Id: Lines: 59 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: > don't allow the vtable to be changed after the menulook is created. This is > maybe a wart, but the difficulty in trying to make it safe and even sensible > is daunting. If we're going to all this trouble to make things dynamic, it would sure be a pity to make it so the vtable of a menu can't be dynamic (especially since it currently can be). > add slots to menu-look for: > side-image > side-image-align (which the more I think about it, may really want to > be a scheme function, not a simple symbol) > side-bg-color > bg-color > text-color > stipple-color > title-color (doesn't currently exist) > bg-image > title-font (doesn't currently exist) > item-font > > add a mutator for each of these. Are all of these actually used in all the existing menulooks? Maybe (if some sort of inheritance is possible) some of the above should already only be in subclasses. > Does Guile have any reasonable object inheritance system usable from C? Is > this the MOP Maciej is pining for? It would be nice to be able to cleanly > subclass this and get rid of 'extra'. > > I'd also want to add per-vtable mutators for whatever's in the extra field for > the code. > > On top of the primitive mutators, an interface similar to the decor/style > interface: > (define new-menu-style > (make-menu-style #:use-menu-style default-menu-style > #:bg-image "wh_marble.xpm" > #:side-image "linux_98.xpm" > #:side-image-align (lambda (picsize menusize) > (- menusize picsize)))) > yadda yadda yadda > create some menus using it > decide you want a different background for the already-defined menus > > (with-menu-style new-menu-style > (set-menu-bg-image! (make-image "bk_marble.xpm))) Yuck! I really don't like this use of dynamic scope. I would much rather modify decors to have direct acessors and mutators than replicate the decor usage into menu styles. How do other people feel about this use of dynamic scope? Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Thu Dec 10 14:17:05 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA01765 for scwm-discuss-outgoing; Thu, 10 Dec 1998 14:17:05 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA01759 for ; Thu, 10 Dec 1998 14:16:56 -0500 Received: from [209.162.216.44] by MIT.EDU with SMTP id AA19757; Thu, 10 Dec 98 14:14:11 EST Received: (qmail 1682 invoked by uid 501); 10 Dec 1998 19:13:01 -0000 Message-Id: <19981210111301.B1599@molehill.org> Date: Thu, 10 Dec 1998 11:13:01 -0800 From: Todd Larason To: "Carl R. Witty" Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <199812060409.XAA04827@M66-080-21.mit.edu> <19981205214407.A18442@molehill.org> <19981209234902.A2135@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Carl R. Witty on Thu, Dec 10, 1998 at 10:33:05AM -0800 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981210, Carl R. Witty wrote: > If we're going to all this trouble to make things dynamic, it would > sure be a pity to make it so the vtable of a menu can't be dynamic > (especially since it currently can be). Yes, it would. And the case I was thinkingn of last night (changing the vtable on a currently-displayed menu) isn't as bad as I was thinking then - it would be hard to make it meaningful, but it shouldn't crash. > Are all of these actually used in all the existing menulooks? Title font & title color aren't currently used at all, because I haven't done that yet. I think all the others are used except for the side image in circle-pie-menu-look and shaped-pie-menu-look. Well, stipple color isn't actually used now, but only because it's ifdef-ed out until I separate title color. > Maybe > (if some sort of inheritance is possible) some of the above should > already only be in subclasses. I'd have no objection. In fact, I suggested moving some of them to 'extra', and Greg convinced me that the common case shouldn't have to deal with the added time/code cmplexity of extra. but if we can find some clean way to subclass... > Yuck! I really don't like this use of dynamic scope. I would much > rather modify decors to have direct acessors and mutators than > replicate the decor usage into menu styles. I have no strong opinion either way, except that similar things should be done similarly. From owner-scwm-discuss@mit.edu Thu Dec 10 14:19:40 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA01801 for scwm-discuss-outgoing; Thu, 10 Dec 1998 14:19:40 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA01798 for ; Thu, 10 Dec 1998 14:19:39 -0500 Received: from HOME-ON-THE-DOME.MIT.EDU by MIT.EDU with SMTP id AA09895; Thu, 10 Dec 98 14:19:38 EST Received: by home-on-the-dome.mit.edu (8.8.7/4.7) id OAA21704; Thu, 10 Dec 1998 14:17:55 -0500 (EST) Message-Id: <199812101917.OAA21704@home-on-the-dome.mit.edu> To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: config fails In-Reply-To: Your message of "09 Dec 1998 13:06:01 +0100." Date: Thu, 10 Dec 1998 14:17:54 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk robbe@orcus.priv.at writes: > Hi, > > >>>>> On Tue, 8 Dec 1998 18:30:48 -0800 > >>>>> Todd Larason said: > > Todd> I apparently solved it for me by just removing ltconfig and > Todd> ltmain.sh. configure complained, but replaced them with working > Todd> copies (well, symlinks). > > Todd> Maybe they should be removed from the tree, treated as > Todd> generated source. > > I suspect that this will fail if there are no libtool or auto* scripts > installed. Can someone with neither autoconf, automake nor libtool on > their machine check this (i.e. remove ltconfig & ltmain.sh and from a > nightly scwm-snapshot and try ./configure and making it)? > I'm prettu sure this won't work. ltmain.sh and ltconfig are not generated by configure. They _can_ be added by automake --add-missing and/or libtoolize, but I'm not sure if we want to go that way. We'd have to go to making the snapshots with `make dist' if we did that. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 10 14:25:34 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA01923 for scwm-discuss-outgoing; Thu, 10 Dec 1998 14:25:34 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA01920 for ; Thu, 10 Dec 1998 14:25:25 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA23421; Thu, 10 Dec 98 14:24:54 EST Received: (qmail 1763 invoked by uid 501); 10 Dec 1998 19:25:02 -0000 Message-Id: <19981210112502.C1599@molehill.org> Date: Thu, 10 Dec 1998 11:25:02 -0800 From: Todd Larason To: Robert Bihlmeyer , scwm-discuss@mit.edu Subject: Re: config fails References: <19981208183048.A26904@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Robert Bihlmeyer on Wed, Dec 09, 1998 at 01:06:01PM +0100 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981209, Robert Bihlmeyer wrote: > Hi, > > >>>>> On Tue, 8 Dec 1998 18:30:48 -0800 > >>>>> Todd Larason said: > > Todd> I apparently solved it for me by just removing ltconfig and > Todd> ltmain.sh. configure complained, but replaced them with working > Todd> copies (well, symlinks). > > Todd> Maybe they should be removed from the tree, treated as > Todd> generated source. > > I suspect that this will fail if there are no libtool or auto* scripts > installed. Can someone with neither autoconf, automake nor libtool on > their machine check this (i.e. remove ltconfig & ltmain.sh and from a > nightly scwm-snapshot and try ./configure and making it)? I miswrote in my earlier mail; it wasn't configure that replaced the files, it was something in autogen, probably autoconf. So I think the only people who would need to have libtool are ones who already need to have have autoconf and automake. The prepackaged versions, that include configure, would also need to include ltconfig and ltmain.sh. This isn't a problem either, because the problem only manifests itself when the libtool package used to generate configure doesn't match the one that generated ltconfig and ltmain.sh. From owner-scwm-discuss@mit.edu Thu Dec 10 14:32:56 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA02106 for scwm-discuss-outgoing; Thu, 10 Dec 1998 14:32:56 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA02103 for ; Thu, 10 Dec 1998 14:32:55 -0500 Received: from HOME-ON-THE-DOME.MIT.EDU by MIT.EDU with SMTP id AA14791; Thu, 10 Dec 98 14:32:55 EST Received: by home-on-the-dome.mit.edu (8.8.7/4.7) id OAA24169; Thu, 10 Dec 1998 14:32:53 -0500 (EST) Message-Id: <199812101932.OAA24169@home-on-the-dome.mit.edu> To: Mikael Djurfeldt Cc: scwm-discuss@mit.edu Subject: Re: sort In-Reply-To: Your message of "10 Dec 1998 13:00:17 +0100." Date: Thu, 10 Dec 1998 14:32:53 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mdj@nada.kth.se writes: > Maciej Stachowiak writes: > > > My own opinion is that we shouldn't add things to libguile unless > > strictly necessary, since that will just make the factorization more > > painful (guile tends to grow dependencies on even the most random > > weird things in libguile). > > I think your point is good in a general case, but don't think it > applies to this case. > Upon further consideration I withdraw my objection. However: > What I meant about factorization is that it doesn't necessarily belong > in the core module, but could be supplied in another library, also > supplied in the guile-core package. > > The factorization won't be more painful because of `sort' since it is > very clear that it should be moved to the sort module, and it is easy > to add the dependency on the sort module to other modules using sort. > What I was thinking of here was that boot-9.scm and libguile have grown to depend on a lot of things that would otherwise be prime candidates for removal. For instance, I believe for example that none of the following can be safely removed from libguile right now without considerable extra work: posix, extended file operations, uniform arrays, hash tables, first-class variables, `sloppy' versions of the alist primitives, regexps and several of the non-RnRS list operations. Moving `sort' to a separate sort module would be somewhat pointless if it had to be loaded into every Guile invocation, so let's make sure this kind of thing does not happen. > > So, even though it is slightly bad to grow the current libguile by a > few K, I still think it is the best option. > As Jim pointed out, the main issue with size is psychological, not technical. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 10 14:43:27 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA02305 for scwm-discuss-outgoing; Thu, 10 Dec 1998 14:43:27 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA02302 for ; Thu, 10 Dec 1998 14:43:26 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA00619; Thu, 10 Dec 98 14:43:21 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Thu, 10 Dec 1998 14:42:46 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Thu, 10 Dec 1998 14:42:46 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id OAA16742; Thu, 10 Dec 1998 14:43:14 -0500 To: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of "09 Dec 1998 13:02:02 +0100" Date: 10 Dec 1998 14:43:14 -0500 Message-Id: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: scwm.el" >>>> Sent on 09 Dec 1998 13:02:02 +0100 >>>> Honorable Robert Bihlmeyer writes: >> >> >>>>> On 08 Dec 1998 18:28:46 -0500 >> >>>>> Sam Steingold said: >> >> Sam> The elc formats are now officially incompatible, and there is >> Sam> no point whatsoever in trying to ignore that. >> >> Then they should have different names. Calling them both "elc" or >> "compiled emacs lisp" confuses software and users. Does anybody know yep. life isn't fair. OTOH, ACL expects the sources in *.cl, CMUCL - *.lisp and CLISP - *.lsp, while all of them grok the same language - ANSI CL. :-) >> a forum where both Emacs and XEmacs developers are active, so I can >> bring this up? Or do I have to resort to private e-mail? try news:comp.emacs I am subscribed to xemacs-beta - do you want me to ask there? Note that the likely responses we will get (slightly exaggerated, of course :-) are: RMS (Emacs): what? there is some other emacs implementation? why should I care? SL Baur &al (XEmacs): this f*cking bastard, RMS, changes ELC format specifically to spite us! seriously, there is not a chance that Emacs will switch from *.elc to anything else. if you ask nicely and beg patiently, you might manage to convince the XEmacs team to switch to, say *.elx. Unfortunately, this doesn't solve much: many people still use 19.34 and 19.16. OTOH, if we start now, we might be out of the trouble in a couple of years :-) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. War doesn't determine who's right, just who's left. From owner-scwm-discuss@mit.edu Thu Dec 10 15:55:01 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA02797 for scwm-discuss-outgoing; Thu, 10 Dec 1998 15:55:01 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA02791 for ; Thu, 10 Dec 1998 15:55:00 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24031; Thu, 10 Dec 98 15:54:56 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA07421 for scwm-discuss@mit.edu; Thu, 10 Dec 1998 21:51:00 +0100 (MET) Received: (qmail 1383 invoked by uid 115); 10 Dec 1998 18:55:45 -0000 To: scwm-discuss@mit.edu Subject: Re: Buggy Rawhide guile-1.3 packages References: X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 10 Dec 1998 19:55:42 +0100 In-Reply-To: Ian Grant's message of "Wed, 9 Dec 1998 12:11:18 +0000 (GMT)" Message-Id: Lines: 26 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Wed, 9 Dec 1998 12:11:18 +0000 (GMT) >>>>> Ian Grant said: Ian> I think that the guile-devel RPM should install the two .m4 Ian> macros (guile and qthreads) because people writing independently Ian> distributed guile modules will need aclocal/automake to find Ian> references to these macros in configure.in and insert the Ian> definitions into aclocal.m4. aclocal finds the definitions in Ian> PREFIX/share/aclocal or on its -I path. I agree. Ian> There shouldn't be a dependency on m4 though because people are Ian> not obliged to use aclocal/automake (perhaps they should be Ian> though.) It suffices that the automake package depends on m4. People not caring about automake will have no use for the .m4 files anyway. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Dec 10 15:54:48 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA02789 for scwm-discuss-outgoing; Thu, 10 Dec 1998 15:54:48 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA02786 for ; Thu, 10 Dec 1998 15:54:46 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA23933; Thu, 10 Dec 98 15:54:41 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA07420 for scwm-discuss@mit.edu; Thu, 10 Dec 1998 21:50:59 +0100 (MET) Received: (qmail 1328 invoked by uid 115); 10 Dec 1998 18:44:27 -0000 To: scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 References: <199812092312.AAA17229@enterprise.osterwald.de> X-Attribution: Robbe Mime-Version: 1.0 From: Robert Bihlmeyer Date: 10 Dec 1998 19:44:25 +0100 In-Reply-To: Heiko Muenkel's message of "Thu, 10 Dec 1998 00:12:30 +0100" Message-Id: Lines: 25 User-Agent: Gnus/5.070062 (Pterodactyl Gnus v0.62) XEmacs/20.4 (Emerald) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 10 Dec 1998 00:12:30 +0100 >>>>> Heiko Muenkel said: Heiko> /bin/sh ../libtool --mode=link gcc -g -O2 -Wall Heiko> -Wpointer-arith -Wmissing-prototypes -o guile guile.o Heiko> libguile.la -lreadline -lncurses -ldl -lm One possibility would be to put the readline and ncurses depencies into libguile. Using a newer libtool script rather than the old one distributed with guile should do this. You can check this by looking at the "gcc -shared" command that the above invokation produces. It should include "-lreadline -lncurses". >From then on linking with libguile automatically links in libreadline & libncurses, too. Or just fix the guile-config script, like Todd said. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Dec 10 16:47:37 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id QAA03194 for scwm-discuss-outgoing; Thu, 10 Dec 1998 16:47:37 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id QAA03191 for ; Thu, 10 Dec 1998 16:47:34 -0500 Received: from njal.hba.marine.csiro.au by MIT.EDU with SMTP id AA13737; Thu, 10 Dec 98 16:47:26 EST Received: (from gray@localhost) by njal.hba.marine.csiro.au (8.9.0/8.9.0) id VAA17687; Thu, 10 Dec 1998 21:46:22 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 11 Dec 1998 08:46:21 +1100 (EDT) From: Randall.Gray@marine.csiro.au To: scwm-discuss@mit.edu Subject: Re: scwm.el In-Reply-To: References: <13933.43624.819069.356827@horus.cs.cornell.edu> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-Id: <13936.16180.333377.860975@njal.hba.marine.csiro.au> Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > >>>>> Sam Steingold said: > Sam> The elc formats are now officially incompatible, and there is > Sam> no point whatsoever in trying to ignore that. > > Then they should have different names. Calling them both "elc" or > "compiled emacs lisp" confuses software and users. Does anybody know a > forum where both Emacs and XEmacs developers are active, so I can > bring this up? Or do I have to resort to private e-mail? I agree to a point, but we quite happily accept having "libcruft.a" on a system without expecting all our compilers to be able to link to objects in it :-) I guess it is still elisp, and really, I thought a plethora of dialects was mandatory for a credible lisp-like language :-). It is possible (and not *that* hard) to make ".emacs" nothing more than a stub which loads the appropriately partitioned environments. I ran both for a while, but I have dropped FSF emacs (at least for the time being). XEmacs seemed subjectively faster for most of the purposes for which I use it. -- Randall From owner-scwm-discuss@mit.edu Thu Dec 10 16:55:27 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id QAA03271 for scwm-discuss-outgoing; Thu, 10 Dec 1998 16:55:27 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id QAA03268 for ; Thu, 10 Dec 1998 16:55:26 -0500 Received: from mail.citycom.com by MIT.EDU with SMTP id AA16481; Thu, 10 Dec 98 16:54:58 EST Received: from yasmeen (38.28.61.66) by citycom.com with SMTP (Eudora Internet Mail Server 2.2); Thu, 10 Dec 1998 13:54:02 -0800 Message-Id: <013401be2487$3548a210$423d1c26@yasmeen.citycom.com> From: "Jason Nordwick" To: Subject: libPropList from WindowMaker Date: Thu, 10 Dec 1998 13:50:28 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am having problems with scwm and WindowMaker on the same system. WindowMaker installs a separate libPropList. Are these the same thing? Has anybody else seen this? -jay From owner-scwm-discuss@mit.edu Thu Dec 10 19:27:13 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id TAA05047 for scwm-discuss-outgoing; Thu, 10 Dec 1998 19:27:13 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id TAA05044 for ; Thu, 10 Dec 1998 19:27:07 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA15083; Thu, 10 Dec 98 08:54:51 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id IAA19657; Thu, 10 Dec 1998 08:50:49 -0500 (EST) Message-Id: <199812101350.IAA19657@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "Wed, 09 Dec 1998 23:49:02 PST." <19981209234902.A2135@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 10 Dec 1998 08:40:33 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <19981209234902.A2135@molehill.org>, Todd Larason writes: >What I was thinking was something along the lines of: > >don't allow the vtable to be changed after the menulook is created. This is >maybe a wart, but the difficulty in trying to make it safe and even sensible >is daunting. My suggestion: Don't let it be mutable but perhaps add the capability to convert a menu from one style to another. Something like (convert-menu-style menu #from-style 'open-look #to-style 'motif) > >add slots to menu-look for: > side-image > side-image-align (which the more I think about it, may really want to > be a scheme function, not a simple symbol) > side-bg-color > bg-color > text-color > stipple-color > title-color (doesn't currently exist) > bg-image > title-font (doesn't currently exist) > item-font > >add a mutator for each of these. > Should title-image be on this list? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Thu Dec 10 20:20:44 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id UAA05766 for scwm-discuss-outgoing; Thu, 10 Dec 1998 20:20:44 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id UAA05763 for ; Thu, 10 Dec 1998 20:20:42 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA17587; Thu, 10 Dec 98 04:19:09 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Thu, 10 Dec 1998 10:17:58 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id KAA11995; Thu, 10 Dec 1998 10:17:57 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id KAA25708; Thu, 10 Dec 1998 10:17:58 +0100 Date: Thu, 10 Dec 1998 10:17:58 +0100 Message-Id: <199812100917.KAA25708@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jtl@molehill.org Cc: mstachow@mit.edu, scwm-discuss@mit.edu Subject: Re: Bug and Patch for configure in scwm 0.9 beta 1 In-Reply-To: <19981209161705.A2014@molehill.org> References: <199812092312.AAA17229@enterprise.osterwald.de> <19981209161705.A2014@molehill.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Todd" == Todd Larason writes: Todd> On 981210, Heiko Muenkel wrote: >> As you can see, I had some problems with the installation. I'm >> not sure, but I think, that -lreadline and -lncurses were not >> in the original call of the above linker command. My >> libreadline has undefined symbols (eg tputs), which are defined >> in libncurses. There's no check for libncurses in the configure >> of guile. Therefore it fails finding libreadline. Todd> ohh...this would certainly explain it. You probably should Todd> update guile-config too, so other guile-using apps can link Todd> properly. -- ICQ UIN: 116537383 Updating guile-config? Should I change the function `build-link', so that it returns the correct linker options? Thanks, Heiko From owner-scwm-discuss@mit.edu Fri Dec 11 00:06:39 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id AAA10408 for scwm-discuss-outgoing; Fri, 11 Dec 1998 00:06:39 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id AAA10405 for ; Fri, 11 Dec 1998 00:06:33 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA10252; Fri, 11 Dec 98 00:06:32 EST Received: (qmail 5031 invoked by uid 501); 11 Dec 1998 05:07:23 -0000 Message-Id: <19981210210723.B4916@molehill.org> Date: Thu, 10 Dec 1998 21:07:23 -0800 From: Todd Larason To: Arturo Perez Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 References: <19981209234902.A2135@molehill.org> <199812101350.IAA19657@ns1.infonautics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812101350.IAA19657@ns1.infonautics.com>; from Arturo Perez on Thu, Dec 10, 1998 at 08:40:33AM -0500 X-Kibo: If you need no excuse to think about the reward of a game, that's allowed. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981210, Arturo Perez wrote: > In message <19981209234902.A2135@molehill.org>, Todd Larason writes: > >What I was thinking was something along the lines of: > > > >don't allow the vtable to be changed after the menulook is created. This is > >maybe a wart, but the difficulty in trying to make it safe and even sensible > >is daunting. > > My suggestion: Don't let it be mutable but perhaps add the capability to > convert a menu from one style to another. Something like > (convert-menu-style menu > #from-style 'open-look > #to-style 'motif) That would work. I don't see any reason for the from-style though? > >add slots to menu-look for: ... > Should title-image be on this list? Would that be a mini-icon type image, beside or above the title? If so, I'd think it should be part of the title menuitem. Or is it something else? -- ICQ UIN: 2469068 From owner-scwm-discuss@mit.edu Fri Dec 11 08:13:40 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id IAA13379 for scwm-discuss-outgoing; Fri, 11 Dec 1998 08:13:40 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id IAA13376 for ; Fri, 11 Dec 1998 08:13:39 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20010; Fri, 11 Dec 98 08:13:35 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA14179 for scwm-discuss@mit.edu; Fri, 11 Dec 1998 14:08:19 +0100 (MET) Received: (qmail 1152 invoked by uid 115); 11 Dec 1998 12:00:44 -0000 To: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> X-Attribution: Robbe From: Robert Bihlmeyer Date: 11 Dec 1998 13:00:43 +0100 In-Reply-To: Sam Steingold's message of "10 Dec 1998 14:43:14 -0500" Message-Id: Lines: 43 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 10 Dec 1998 14:43:14 -0500 >>>>> Sam Steingold said: Sam> OTOH, ACL expects the sources in *.cl, CMUCL - *.lisp and CLISP Sam> - *.lsp, while all of them grok the same language - ANSI CL. :-) That's better than the other way around. Having one identifier for two slightly different formats is even worse than having one for entirely different langages (prolog ".pl" vs. perl ".pl" come to mind). Sam> I am subscribed to xemacs-beta - do you want me to ask there? That would be nice. Sam> seriously, there is not a chance that Emacs will switch from Sam> *.elc to anything else. *sigh* Yes, I know, I've watched my share of Emacs politics, too. Sam> if you ask nicely and beg patiently, you might manage to Sam> convince the XEmacs team to switch to, say *.elx. I think it would be a very nice feature, if one emacs would simply ignore the other one's byte-compiled files. This could be done easily for both, by changing one suffix. A more complex alternative would be to check a magic number in the file (there is already something like that in XEmacs .elc), and ignore the file if that does not match. But I like the suffix change best. It would allow you to, for example, share your site-lisp between emacsen. Sam> OTOH, if we start now, we might be out of the trouble in a Sam> couple of years :-) Since the problem probably won't go away, it may pay off in time. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 11 08:13:28 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id IAA13374 for scwm-discuss-outgoing; Fri, 11 Dec 1998 08:13:28 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id IAA13371 for ; Fri, 11 Dec 1998 08:13:25 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA19968; Fri, 11 Dec 98 08:13:21 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA14171 for scwm-discuss@mit.edu; Fri, 11 Dec 1998 14:08:18 +0100 (MET) Received: (qmail 1119 invoked by uid 115); 11 Dec 1998 11:45:09 -0000 To: scwm-discuss@mit.edu Subject: Re: config fails References: <19981208183048.A26904@molehill.org> <19981210112502.C1599@molehill.org> X-Attribution: Robbe From: Robert Bihlmeyer Date: 11 Dec 1998 12:45:06 +0100 In-Reply-To: Todd Larason's message of "Thu, 10 Dec 1998 11:25:02 -0800" Message-Id: Lines: 28 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 10 Dec 1998 11:25:02 -0800 >>>>> Todd Larason said: Todd> I miswrote in my earlier mail; it wasn't configure that Todd> replaced the files, it was something in autogen, probably Todd> autoconf. automake is the one, I think. So snapshots should get these files automatically, because the snap-script does autogen.sh before tarring up. People pulling from CVS already need the auto-tools. Todd> The prepackaged versions, that include configure, would also Todd> need to include ltconfig and ltmain.sh. This isn't a problem Todd> either, because the problem only manifests itself when the Todd> libtool package used to generate configure doesn't match the Todd> one that generated ltconfig and ltmain.sh. Yes, this should work. Let's remove "ltconfig" and "ltmain.sh" Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 11 09:30:57 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id JAA13800 for scwm-discuss-outgoing; Fri, 11 Dec 1998 09:30:57 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id JAA13797 for ; Fri, 11 Dec 1998 09:30:55 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA28352; Fri, 11 Dec 98 09:30:55 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id JAA20627; Fri, 11 Dec 1998 09:30:14 -0500 (EST) Message-Id: <199812111430.JAA20627@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Todd Larason Cc: Maciej Stachowiak , scwm-discuss@mit.edu Subject: Re: SCWM CVS checkin Thu Dec 3 21:08:34 EST 1998 In-Reply-To: Your message of "Thu, 10 Dec 1998 21:07:23 PST." <19981210210723.B4916@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Dec 1998 09:20:04 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <19981210210723.B4916@molehill.org>, Todd Larason writes: >On 981210, Arturo Perez wrote: >> In message <19981209234902.A2135@molehill.org>, Todd Larason writes: >> >What I was thinking was something along the lines of: >> > >> >don't allow the vtable to be changed after the menulook is created. This i >s >> >maybe a wart, but the difficulty in trying to make it safe and even sensibl >e >> >is daunting. >> >> My suggestion: Don't let it be mutable but perhaps add the capability to >> convert a menu from one style to another. Something like >> (convert-menu-style menu >> #from-style 'open-look >> #to-style 'motif) > >That would work. I don't see any reason for the from-style though? I guess it's not needed. I was thinking of it as a hint as to how to walk the menu. But really, the menu is-a/would-be a self-descriptive data structure now, wouldn't it? > >> >add slots to menu-look for: >... >> Should title-image be on this list? > >Would that be a mini-icon type image, beside or above the title? If so, I'd >think it should be part of the title menuitem. Or is it something else? I was thinking instead of menu-text or perhaps a different background pixmap for the title. -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Fri Dec 11 09:49:43 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id JAA14171 for scwm-discuss-outgoing; Fri, 11 Dec 1998 09:49:43 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id JAA14165 for ; Fri, 11 Dec 1998 09:49:41 -0500 Received: from seldon.dtek.chalmers.se by MIT.EDU with SMTP id AA04983; Fri, 11 Dec 98 09:49:36 EST Received: from licia.dtek.chalmers.se (d4jonas@licia.dtek.chalmers.se [129.16.30.88]) by seldon.dtek.chalmers.se (8.8.8/8.8.8) with ESMTP id PAA10655 for ; Fri, 11 Dec 1998 15:49:32 +0100 (MET) Received: (from d4jonas@localhost) by licia.dtek.chalmers.se (8.8.8/8.8.8) id PAA14769; Fri, 11 Dec 1998 15:49:31 +0100 (MET) To: scwm-discuss@mit.edu Subject: window-style X-No-Archive: Yes Mail-Copies-To: never Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Jonas Steverud Date: 11 Dec 1998 15:49:31 +0100 Message-Id: Lines: 17 X-Mailer: Gnus v5.6.45/Emacs 20.2 Sender: owner-scwm-discuss@mit.edu Precedence: bulk (window-style "*" #:use-style js-common-window-style) What does the "*" matches on and how? On windowtitle or the X-property "name"? (xterm -name foo) Like the file-matching in sh(1)? (file*, file?s, fil[a-z]*) Regarding the homepage: Could the text about that I collect some links please be removed? I'm quite certain that that section won't expand. (It is ok that I'm mentioned on the page though.) I added the links since the page looked so ... empty and will be removed when I found something better to say. Thank you. /Jonas, who will work in the SCWMDoc during X-mas. -- ( Jonas Steverud @ www.dtek.chalmers.se/~d4jonas/ ! Wei Wu Wei ) ( U2MoL, Roleplaying, LaTeX, Emacs/Gnus, SCWM, etc. ! To Do Without Do ) From owner-scwm-discuss@mit.edu Fri Dec 11 13:23:51 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA15256 for scwm-discuss-outgoing; Fri, 11 Dec 1998 13:23:51 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA15253 for ; Fri, 11 Dec 1998 13:23:49 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA19763; Fri, 11 Dec 98 13:23:47 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id KAA01577; Fri, 11 Dec 1998 10:23:44 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id KAA09067; Fri, 11 Dec 1998 10:23:44 -0800 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: scwm.el References: <13933.43624.819069.356827@horus.cs.cornell.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: cwitty@newtonlabs.com (Carl R. Witty) Date: 11 Dec 1998 10:23:44 -0800 In-Reply-To: Robert Bihlmeyer's message of "11 Dec 1998 13:00:43 +0100" Message-Id: Lines: 23 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > I think it would be a very nice feature, if one emacs would simply > ignore the other one's byte-compiled files. This could be done easily > for both, by changing one suffix. A more complex alternative would be > to check a magic number in the file (there is already something like > that in XEmacs .elc), and ignore the file if that does not match. > > But I like the suffix change best. It would allow you to, for example, > share your site-lisp between emacsen. Well, but this isn't really sufficient. The currently-released version of Debian supports installing emacs19, emacs20, xemacs19, and xemacs20, all on the same machine. I could imagine that in a couple of years it would support emacs21, emacs22, xemacs21, and xemacs22 (plus emacs19, if emacs21 and 22 don't support non-MULE compilation :-). Unless you can get a commitment from FSF or the XEmacs people not to affect forward/backward compatibility of bytecode files (extremely unlikely), you need something like .elc19, .elx20, .elx20.2-beta1, .elx20.2-beta2, etc. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sat Dec 12 17:50:22 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA26365 for scwm-discuss-outgoing; Sat, 12 Dec 1998 17:50:22 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA26362 for ; Sat, 12 Dec 1998 17:50:20 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA19071; Sat, 12 Dec 98 17:50:04 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id OAA16287; Sat, 12 Dec 1998 14:49:59 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id OAA17611; Sat, 12 Dec 1998 14:49:58 -0800 To: Maciej Stachowiak Cc: Craig Struble , scwm-discuss@mit.edu Subject: Re: Typo and binary modules References: <199812062049.PAA28329@M66-080-3.mit.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: cwitty@newtonlabs.com (Carl R. Witty) Date: 12 Dec 1998 14:49:58 -0800 In-Reply-To: Maciej Stachowiak's message of "Sun, 06 Dec 1998 15:49:03 EST" Message-Id: Lines: 32 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > > Finally, on FreeBSD 3.0, just having links to the .la files (and .so > > files) in the module directory doesn't work. I had to put symbolic links > > to the .so.x.x files as well before everything was happy. I don't know > > enough about the particulars of FreeBSD's shared library implementation or > > guile 1.3 port to know why the .so.x.x files need to be there too, but > > I'll be happy to try to figure it out with some direction. > > > > Hmm, I will revert the change if we can't get this working in time for > the release. In the meantime, could you show me what the error message > is? I _think_ Guile should be able to load a shared library from only > the .la file on any platform, but if this is not the case, trying to > link all the files generated for a shared library on any given > platform is likely to be a losing battle. I've just been reading the source code for Guile 1.3. When Guile tries to load a .la file, it opens the file and searches for a line of the form: dlname='...' and takes the "..." to be the library name. It then appends the name of the directory in which the .la file was found and the library name to form a pathname which it passes to the dynamic loading interface (dlopen() or equivalent). So Guile 1.3 has no support for trying to load a dynamic library from a symlink'ed .la file. Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sat Dec 12 18:25:03 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id SAA26571 for scwm-discuss-outgoing; Sat, 12 Dec 1998 18:25:03 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id SAA26568 for ; Sat, 12 Dec 1998 18:25:03 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA21251; Sat, 12 Dec 98 18:24:45 EST Received: (qmail 10870 invoked by uid 501); 12 Dec 1998 23:27:13 -0000 Message-Id: <19981212152713.A6454@molehill.org> Date: Sat, 12 Dec 1998 15:27:13 -0800 From: Todd Larason To: "Carl R. Witty" , Maciej Stachowiak Cc: Craig Struble , scwm-discuss@mit.edu Subject: Re: Typo and binary modules References: <199812062049.PAA28329@M66-080-3.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Carl R. Witty on Sat, Dec 12, 1998 at 02:49:58PM -0800 X-Kibo: I could share Einstein. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981212, Carl R. Witty wrote: > When Guile tries to load a .la file, it opens the file and searches > for a line of the form: > dlname='...' > and takes the "..." to be the library name. It then appends the name > of the directory in which the .la file was found and the library name > to form a pathname which it passes to the dynamic loading interface > (dlopen() or equivalent). I can't tell if this is a bug or not. There IS a line in the .la entry giving the installed-directory name, but the libtool documentation isn't entirely clear whether it should be used: ======= File: libtool.info, Node: Finding the dlname, Next: Dlopen issues, Prev: Dlpreopening, Up: Dlopened modules Finding the correct name to dlopen ================================== After a library has been linked with `-export-dynamic', it can be dlopened. Unfortunately, because of the variation in library names, your package needs to determine the correct file to dlopen. The most straightforward and flexible implementation is to determine the name at runtime, by finding the installed `.la' file, and searching it for the following lines: # The name that we can `dlopen'. dlname='DLNAME' If DLNAME is empty, then the library cannot be dlopened. Otherwise, it gives the dlname of the library. So, if the library was installed as `/usr/local/lib/libhello.la', and the DLNAME was `libhello.so.3', then `/usr/local/lib/libhello.so.3' should be dlopened. If your program uses this approach, then it should search the directories listed in the `LD_LIBRARY_PATH'(1) environment variable, as well as the directory where libraries will eventually be installed. Searching this variable (or equivalent) will guarantee that your program can find its dlopened modules, even before installation, provided you have linked them using libtool. ---------- Footnotes ---------- (1) `LIBPATH' on AIX, and `SHLIB_PATH' on HP-UX. =========== There is a mention of 'directory where libraries will eventually be installed', but no mention of how to find that directory. In any case, bug or not, it's evidentally the way 1.3 is. -- ICQ UIN: 90346284 From owner-scwm-discuss@mit.edu Sat Dec 12 23:03:27 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id XAA27768 for scwm-discuss-outgoing; Sat, 12 Dec 1998 23:03:27 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id XAA27765 for ; Sat, 12 Dec 1998 23:03:26 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA18529; Sat, 12 Dec 98 23:03:06 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sat, 12 Dec 1998 23:02:55 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sat, 12 Dec 1998 23:02:55 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id XAA31768; Sat, 12 Dec 1998 23:02:20 -0500 To: "Carl R. Witty" Cc: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: "Carl R. Witty"'s message of "Thu, 10 Dec 1998 00:20:36 -0800" Date: 12 Dec 1998 23:02:20 -0500 Message-Id: Lines: 42 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I did not know about it, but I am not surprised. This module is rather decorative at the time. before it becomes of much practical use, - someone has to explain to me how to get the value of a symbol (symbol-binding #f symbol) doesn't work, what do I use instead of #f? what is going on in general? I know ELisp and ANSI CL, but I am lost here... - someone has to fix `ask-string': ;;; FIX this is a bit more complex than this, since we don't want all of ;;; scwm to stall waiting for the response -- the hack we could ;;; currently use is use xprompt and have it run the apropriate ;;; scwm-exec command (i.e., pass the continuation [the ;;; set-shadow-factor! e.g.] to the ask-string, and have it run ;;; scwm-exec after getting the value from the user (define-public (ask-string prompt) "Ask for a string with PROMPT." (message prompt "New value: ?!") "") (still, even now it can do some useful things...) >>>> In message <199812100820.AAA21357@nebula.newtonlabs.com> >>>> On the subject of "(save-settings) from prefs-menu.scm doesn't work" >>>> Sent on Thu, 10 Dec 1998 00:20:36 -0800 >>>> Honorable "Carl R. Witty" writes: >> You probably already know about this, but: >> >> scwm> (save-settings) >> >> Backtrace: >> 0* [save-settings] >> 1 (let ((fd #)) (do (#) (# #)) ...) >> 2* [for-each # ... -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. War doesn't determine who's right, just who's left. From owner-scwm-discuss@mit.edu Sat Dec 12 23:23:11 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id XAA27950 for scwm-discuss-outgoing; Sat, 12 Dec 1998 23:23:11 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id XAA27947 for ; Sat, 12 Dec 1998 23:23:10 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sat, 12 Dec 1998 23:22:31 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sat, 12 Dec 1998 23:22:31 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id XAA04745; Sat, 12 Dec 1998 23:21:56 -0500 To: scwm-discuss@mit.edu Subject: make-install Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 12 Dec 1998 23:21:55 -0500 Message-ID: Lines: 18 Sender: owner-scwm-discuss@mit.edu Precedence: bulk make[3]: Entering directory `/usr/src/scwm/modules/scwmgtkhelper' /bin/sh ../../mkinstalldirs /usr/local/share/scwm-modules/app/scwm rm -f /usr/local/lib/scwm-modules/app/scwm/libscwmgtkhelper.la ln -s /usr/local/lib/scwm/libscwmgtkhelper.la /usr/local/share/scwm-modules/app/scwm/libscwmgtkhelper.la ln: /usr/local/share/scwm-modules/app/scwm/libscwmgtkhelper.la: File exists make[3]: *** [install-data-hook] Error 1 make[3]: Leaving directory `/usr/src/scwm/modules/scwmgtkhelper' make[2]: *** [install-data] Error 2 make[2]: Leaving directory `/usr/src/scwm/modules/scwmgtkhelper' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/scwm/modules' make: *** [install-recursive] Error 1 -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. MS: our tomorrow's software will run on your tomorrow's HW at today's speed. From owner-scwm-discuss@mit.edu Sun Dec 13 11:09:50 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA32085 for scwm-discuss-outgoing; Sun, 13 Dec 1998 11:09:50 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id LAA32082 for ; Sun, 13 Dec 1998 11:09:49 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA21562; Sun, 13 Dec 98 11:09:25 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Sun, 13 Dec 1998 17:09:18 +0100 Received: from enterprise.osterwald.de (root@h11.ts1.uni-hannover.de [130.75.249.11]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id RAA14141; Sun, 13 Dec 1998 17:08:54 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id RAA00510; Sun, 13 Dec 1998 17:05:17 +0100 Date: Sun, 13 Dec 1998 17:05:17 +0100 Message-Id: <199812131605.RAA00510@enterprise.osterwald.de> From: Heiko Muenkel To: Doug McNaught Cc: scwm-discuss@mit.edu Subject: Re: Problems with scwm and FvwmButtons X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H writes: > I tried to use the FVWM2 module FvwmButtons together with the scwm > without success. Maciej Stachowiak told me, that he has seen reports > of people successfully doing this (Thank you Maciej). It would be nice > if someone could send me an example configuration. Please reply also > direct to my mail address and not only to this list. I can use the module FvwmButtons now together with scwm 0.9 beta 1. The snapshot from the 13. November wasn't able to use it. Thank you Doug for sending me your configurations. Heiko From owner-scwm-discuss@mit.edu Sun Dec 13 11:09:47 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA32080 for scwm-discuss-outgoing; Sun, 13 Dec 1998 11:09:47 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id LAA32077 for ; Sun, 13 Dec 1998 11:09:44 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA21559; Sun, 13 Dec 98 11:09:23 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Sun, 13 Dec 1998 17:08:53 +0100 Received: from enterprise.osterwald.de (root@h11.ts1.uni-hannover.de [130.75.249.11]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id RAA14136 for ; Sun, 13 Dec 1998 17:08:48 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id RAA00518; Sun, 13 Dec 1998 17:10:50 +0100 From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13939.59146.338611.854084@enterprise.osterwald.de> Date: Sun, 13 Dec 1998 17:10:50 +0100 (MET) To: scwm-discuss@mit.edu Subject: Misnamed function `animated-toggle-window-shade'? X-Mailer: VM 6.62 under 21.0 "Poitou60" XEmacs Lucid (beta60) X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H; Sun, 13 Dec 1998 13:40:19 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24415; Sun, 13 Dec 98 13:39:51 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA23443 for scwm-discuss@mit.edu; Sun, 13 Dec 1998 19:30:54 +0100 (MET) Received: (qmail 1509 invoked by uid 115); 13 Dec 1998 16:18:51 -0000 To: scwm-discuss@mit.edu Cc: guile@cygnus.com Subject: guile's dynamic linking References: <199812062049.PAA28329@M66-080-3.mit.edu> <19981212152713.A6454@molehill.org> X-Attribution: Robbe From: Robert Bihlmeyer Date: 13 Dec 1998 17:18:49 +0100 In-Reply-To: Todd Larason's message of "Sat, 12 Dec 1998 15:27:13 -0800" Message-Id: Lines: 36 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Sat, 12 Dec 1998 15:27:13 -0800 >>>>> Todd Larason said: The libtool manual node "Finding the dlname" says: > If your program uses this approach, then it should search the > directories listed in the `LD_LIBRARY_PATH'(1) environment > variable, as well as the directory where libraries will eventually > be installed. Searching this variable (or equivalent) will > guarantee that your program can find its dlopened modules, even > before installation, provided you have linked them using libtool. Todd> There is a mention of 'directory where libraries will Todd> eventually be installed', but no mention of how to find that Todd> directory. For example, my "libxpm-menus.la" contains the following: # Directory that this library needs to be installed in: libdir='/usr/lib/scwm' That should be it. Guile 1.3 does not take LD_LIBRARY_PATH into account. This is clearly a bug. Second, as it already scans the .la file, it should go all the way, and use the libdir hint as well. This is not required, but would certainly be a good idea. Checking the directory where the .la file resides can be done last. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Dec 13 13:40:18 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA00157 for scwm-discuss-outgoing; Sun, 13 Dec 1998 13:40:18 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA00154 for ; Sun, 13 Dec 1998 13:40:17 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24403; Sun, 13 Dec 98 13:39:50 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA23440 for scwm-discuss@mit.edu; Sun, 13 Dec 1998 19:30:51 +0100 (MET) Received: (qmail 1017 invoked by uid 115); 13 Dec 1998 15:06:03 -0000 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 13 Dec 1998 16:06:01 +0100 In-Reply-To: Sam Steingold's message of "12 Dec 1998 23:02:20 -0500" Message-Id: Lines: 30 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 12 Dec 1998 23:02:20 -0500 >>>>> Sam Steingold said: Sam> - someone has to explain to me how to get the value of a symbol Sam> (symbol-binding #f symbol) doesn't work, what do I use Sam> instead of #f? what is going on in general? I know ELisp and Sam> ANSI CL, but I am lost here... I know much less Lisp, but this should work ... - primitive: symbol-binding OBARRAY STRING Look up in OBARRAY the symbol whose name is STRING, and return the value to which it is bound. If OBARRAY is `#f', use the global symbol table. If STRING is not interned in OBARRAY, an error is signalled. ... and does work in the cases I tried it. E.g.: scwm> (symbol-binding #f 'popup-menu) #> What's the exact problem you're seeing? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Dec 13 13:40:17 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA00152 for scwm-discuss-outgoing; Sun, 13 Dec 1998 13:40:17 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA00148 for ; Sun, 13 Dec 1998 13:40:16 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24399; Sun, 13 Dec 98 13:39:49 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA23441 for scwm-discuss@mit.edu; Sun, 13 Dec 1998 19:30:52 +0100 (MET) Received: (qmail 1076 invoked by uid 115); 13 Dec 1998 15:38:50 -0000 To: SCWM discussion list Subject: Primitive variables, constants, functions X-Attribution: Robbe From: Robert Bihlmeyer Date: 13 Dec 1998 16:38:48 +0100 Message-Id: Lines: 19 Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, while writing some session-management glue, I found out that there are absolutely no "primitive" variables defined in the C part of scwm. Anything that comes from the C side is provided by functions. Is this a deliberate decision - i.e. are primitive variables/constants unhip, wasteful, slow, inconvenient -, or did it just happen? I would have tended to code some things as variables, especially static ones like `display-size', if I were to implement it anew. Of course reimplementing these is not the question, rather how to do things that are newly added. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Dec 13 13:40:16 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA00151 for scwm-discuss-outgoing; Sun, 13 Dec 1998 13:40:16 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA00143 for ; Sun, 13 Dec 1998 13:40:13 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24386; Sun, 13 Dec 98 13:39:46 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA23442 for scwm-discuss@mit.edu; Sun, 13 Dec 1998 19:30:53 +0100 (MET) Received: (qmail 1500 invoked by uid 115); 13 Dec 1998 16:16:31 -0000 To: SCWM discussion list Subject: session-management - the warning has gone X-Attribution: Robbe From: Robert Bihlmeyer Date: 13 Dec 1998 17:16:29 +0100 Message-Id: Lines: 16 Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, the SESSION_MANAGER warning will be finally removed (checkin due to tomorrow). If you normally run under SM and want to be informed of errors, put something like the following in your startup file: (if (not (SM-client-id)) (message (SM-error-message))) Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Dec 13 13:40:25 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA00168 for scwm-discuss-outgoing; Sun, 13 Dec 1998 13:40:25 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA00165 for ; Sun, 13 Dec 1998 13:40:24 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA24426; Sun, 13 Dec 98 13:39:57 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id TAA23445 for scwm-discuss@mit.edu; Sun, 13 Dec 1998 19:30:56 +0100 (MET) Received: (qmail 2110 invoked by uid 115); 13 Dec 1998 17:37:33 -0000 To: scwm-discuss@mit.edu Subject: Re: docking windows References: <199812041542.KAA24143@vicarious-existence.mit.edu> X-Attribution: Robbe From: Robert Bihlmeyer Date: 13 Dec 1998 18:37:32 +0100 In-Reply-To: Maciej Stachowiak's message of "Fri, 04 Dec 1998 10:42:56 EST" Message-Id: Lines: 41 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 04 Dec 1998 10:42:56 EST >>>>> Maciej Stachowiak said: Maciej> I actually realized that there _is_ one missing feature - the Maciej> ability to adjust the rubber-band/window position in the Maciej> middle of an interactive move. Yes, the move loop will get very angry if something move the window away under its nose. Maciej> I think that should be easy to add, though - just add a bit Maciej> to the window structure indicating that an interactive Maciej> operation is in progress, another bit indicating a Maciej> move/resize has taken place in the middle of interaction, Maciej> have move-window/resize-window only update the fields of the Maciej> window struct and that bit during an interactive move, and Maciej> make the interactive loop code check the bit after calling Maciej> the hook. Why not simply check if the position changed? This would be more straight-forward and not much more expensive. Introducing yet another global state variable seems rather messy. Maciej> I also have done some preliminary design work and even wrote Maciej> a bit of semi-pseudo-code for the snap feature itself - would Maciej> you be interested in seeing it? Sure, send it to me. Maciej> You're welcome to implement it the rest of the way if you Maciej> want because I have a billion other things to code :-) Of course. It won't happen before 0.9 though... Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sun Dec 13 14:34:38 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA00645 for scwm-discuss-outgoing; Sun, 13 Dec 1998 14:34:38 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA00641 for ; Sun, 13 Dec 1998 14:34:36 -0500 Received: from kirk.newtonlabs.com by MIT.EDU with SMTP id AA01550; Sun, 13 Dec 98 14:34:08 EST Received: from bogomips.newtonlabs.com (cwitty@bogomips.newtonlabs.com [207.55.51.12]) by quasar.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) with ESMTP id LAA02953; Sun, 13 Dec 1998 11:34:05 -0800 Received: (from cwitty@localhost) by bogomips.newtonlabs.com (8.8.8/8.8.8/Debian/GNU) id LAA32032; Sun, 13 Dec 1998 11:34:04 -0800 To: Robert Bihlmeyer Cc: SCWM discussion list Subject: Re: Primitive variables, constants, functions References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: cwitty@newtonlabs.com (Carl R. Witty) Date: 13 Dec 1998 11:34:03 -0800 In-Reply-To: Robert Bihlmeyer's message of "13 Dec 1998 16:38:48 +0100" Message-Id: Lines: 24 X-Mailer: Gnus v5.4.61/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Robert Bihlmeyer writes: > Hi, > > while writing some session-management glue, I found out that there are > absolutely no "primitive" variables defined in the C part of scwm. > Anything that comes from the C side is provided by functions. There aren't very many variables defined from C, but there are a few: ./scwm/scwm.c: SCWM_VAR_READ_ONLY(NULL,"locale-fullname",gh_str02scm(Lang)); ./scwm/scwm.c: SCWM_VAR_READ_ONLY(NULL,"locale-language-territory",gh_str02scm(territory)); ./scwm/scwm.c: SCWM_VAR(pct_load_path,"%load-path"); ./scwm/image.c: SCWM_VAR_INIT(image_load_path,"image-load-path", gh_eval_str("\'"SCWM_IMAGE_LOAD_PATH)); ./scwm/drawmenu.c: SCWM_VAR_READ_ONLY(NULL,"scwm-menu-look",drawmenu_menu_look); ./modules/xpm-menus/draw-xpm-menu.c: SCWM_VAR_READ_ONLY(NULL,"xpm-shaped-menu-look",xpm_shaped_menu_look); ./modules/xpm-menus/draw-xpm-menu.c: SCWM_VAR(xpm_menu_look,"xpm-menu-look"); ./modules/pie-menus/draw-pie-menu.c: SCWM_VAR_READ_ONLY(NULL,"pie-menu-look",pie_menu_look); ./modules/pie-menus/draw-pie-menu.c: SCWM_VAR_READ_ONLY(NULL,"circle-pie-menu-look",circle_pie_menu_look); ./modules/pie-menus/draw-pie-menu.c: SCWM_VAR_READ_ONLY(NULL,"shaped-pie-menu-look", shaped_pie_menu_look); Carl Witty cwitty@newtonlabs.com From owner-scwm-discuss@mit.edu Sun Dec 13 17:30:24 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA01363 for scwm-discuss-outgoing; Sun, 13 Dec 1998 17:30:24 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA01360 for ; Sun, 13 Dec 1998 17:30:23 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA08445; Sun, 13 Dec 98 17:29:57 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Sun, 13 Dec 1998 17:29:50 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Sun, 13 Dec 1998 17:29:50 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id RAA07302; Sun, 13 Dec 1998 17:29:08 -0500 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of "13 Dec 1998 16:06:01 +0100" Date: 13 Dec 1998 17:29:07 -0500 Message-Id: Lines: 46 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: (save-settings) from prefs-menu.scm doesn't work" >>>> Sent on 13 Dec 1998 16:06:01 +0100 >>>> Honorable Robert Bihlmeyer writes: >> Hi, >> >> >>>>> On 12 Dec 1998 23:02:20 -0500 >> >>>>> Sam Steingold said: >> >> Sam> - someone has to explain to me how to get the value of a symbol >> Sam> (symbol-binding #f symbol) doesn't work, what do I use ^^^^^^^^^^^^^^^^^^^^^^^^^^ I assure you I know about this. >> Sam> instead of #f? what is going on in general? I know ELisp and >> Sam> ANSI CL, but I am lost here... >> >> I know much less Lisp, but this should work ... >> >> - primitive: symbol-binding OBARRAY STRING >> Look up in OBARRAY the symbol whose name is STRING, and return the >> value to which it is bound. If OBARRAY is `#f', use the global >> symbol table. If STRING is not interned in OBARRAY, an error is >> signalled. >> >> ... and does work in the cases I tried it. E.g.: >> >> scwm> (symbol-binding #f 'popup-menu) >> #> >> >> What's the exact problem you're seeing? scwm> (symbol-binding #f 'netscape-new-window) (symbol-binding #f 'netscape-new-window) # scwm> netscape-new-window netscape-new-window #t [I don't know why I see the command twice in the emacs *scwm* window.] -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Bus error -- driver executed. From owner-scwm-discuss@mit.edu Mon Dec 14 07:28:56 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id HAA05781 for scwm-discuss-outgoing; Mon, 14 Dec 1998 07:28:56 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id HAA05778 for ; Mon, 14 Dec 1998 07:28:53 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA24582; Mon, 14 Dec 98 07:28:13 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Mon, 14 Dec 1998 13:22:42 +0100 Received: from enterprise.osterwald.de (root@h41.ts1.uni-hannover.de [130.75.249.41]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id NAA21822 for ; Mon, 14 Dec 1998 13:22:40 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id MAA00747; Mon, 14 Dec 1998 12:27:30 +0100 From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13940.63010.114510.268954@enterprise.osterwald.de> Date: Mon, 14 Dec 1998 12:27:30 +0100 (MET) To: scwm-discuss@mit.edu Subject: Bug: Bad looking titlebar with border-width eq 0 X-Mailer: VM 6.62 under 21.0 "Poitou60" XEmacs Lucid (beta60) X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H; Mon, 14 Dec 1998 08:45:28 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA20010; Mon, 14 Dec 98 08:44:59 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id OAA00023 for scwm-discuss@mit.edu; Mon, 14 Dec 1998 14:11:03 +0100 (MET) Received: (qmail 692 invoked by uid 115); 14 Dec 1998 11:24:20 -0000 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 14 Dec 1998 12:24:19 +0100 In-Reply-To: Sam Steingold's message of "13 Dec 1998 17:29:07 -0500" Message-Id: Lines: 27 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 13 Dec 1998 17:29:07 -0500 >>>>> Sam Steingold said: scwm> (symbol-binding #f 'netscape-new-window) Sam> (symbol-binding #f 'netscape-new-window) Sam> # scwm> netscape-new-window Sam> netscape-new-window Sam> #t After half an hour of diddling, I came up with the following: (let ((var (module-variable the-root-module 'netscape-new-window))) (if (and var (variable-bound? var)) (variable-ref var) (throw 'whatever))) This catches all variables in the-root-module plus any `define-public'. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Dec 14 10:32:02 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA06983 for scwm-discuss-outgoing; Mon, 14 Dec 1998 10:32:02 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id KAA06977 for ; Mon, 14 Dec 1998 10:31:59 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA11075; Mon, 14 Dec 98 10:31:22 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 14 Dec 1998 10:31:30 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 14 Dec 1998 10:31:30 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id KAA08947; Mon, 14 Dec 1998 10:31:18 -0500 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of "14 Dec 1998 12:24:19 +0100" Date: 14 Dec 1998 10:31:18 -0500 Message-Id: Lines: 47 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: (save-settings) from prefs-menu.scm doesn't work" >>>> Sent on 14 Dec 1998 12:24:19 +0100 >>>> Honorable Robert Bihlmeyer writes: >> >> After half an hour of diddling, I came up with the following: >> >> (let ((var (module-variable the-root-module 'netscape-new-window))) >> (if (and var (variable-bound? var)) >> (variable-ref var) >> (throw 'whatever))) >> >> This catches all variables in the-root-module plus any >> `define-public'. Interesting. In CL, a symbol knows which package it belongs to. Not so in scheme? what about `user-options' variable? scwm> user-options user-options Backtrace: 0* user-options ERROR: In expression user-options: ERROR: Unbound variable: user-options scwm> (symbol-binding #f 'user-options) (symbol-binding #f 'user-options) # scwm> (module-variable the-root-module 'user-options) (module-variable the-root-module 'user-options) #f scwm> But I am using prefs-menu and I see the "specific parameters" submenu generated from `user-options'. what is going on? -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. When we break the law, they fine us, when we comply, they tax us. From owner-scwm-discuss@mit.edu Mon Dec 14 12:12:48 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA07518 for scwm-discuss-outgoing; Mon, 14 Dec 1998 12:12:48 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id MAA07515 for ; Mon, 14 Dec 1998 12:12:46 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA22201; Mon, 14 Dec 98 12:12:07 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id MAA01953 for ; Mon, 14 Dec 1998 12:11:58 -0500 (EST) Message-Id: <199812141711.MAA01953@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: scwm-discuss@mit.edu Subject: guild 1.3 not on solaris x86 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Dec 1998 12:01:45 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Although I can build and install libguile1.2 on solaris 2.6 on Intel just fine, libguile1.3 fails to compile. Is this a known problem with a patch? -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Mon Dec 14 17:41:42 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA09225 for scwm-discuss-outgoing; Mon, 14 Dec 1998 17:41:42 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA09222 for ; Mon, 14 Dec 1998 17:41:15 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA17474; Mon, 14 Dec 98 17:40:28 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id XAA23323 for scwm-discuss@mit.edu; Mon, 14 Dec 1998 23:30:43 +0100 (MET) Received: (qmail 443 invoked by uid 115); 14 Dec 1998 19:10:21 -0000 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 14 Dec 1998 20:10:19 +0100 In-Reply-To: Sam Steingold's message of "14 Dec 1998 10:31:18 -0500" Message-Id: Lines: 28 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 14 Dec 1998 10:31:18 -0500 >>>>> Sam Steingold said: Sam> Interesting. In CL, a symbol knows which package it belongs to. Sam> Not so in scheme? As I understand it, variables have no back-reference to their module, but are simply put into current module's obarray by `define'. `define-public' additionally adds the variable to the current module's public interface. You can import all variables in a module's public interface by `use-module'. This makes them visible in the current module, too. Sam> But I am using prefs-menu and I see the "specific parameters" Sam> submenu generated from `user-options'. The ":use-module (app scwm user-options)" clause pulls the `user-options' variable into pref-menu's namespace, but not into the root namespace. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Mon Dec 14 18:48:19 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id SAA09671 for scwm-discuss-outgoing; Mon, 14 Dec 1998 18:48:19 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id SAA09668 for ; Mon, 14 Dec 1998 18:48:10 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA04342; Mon, 14 Dec 98 18:47:26 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 14 Dec 1998 18:46:29 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 14 Dec 1998 18:46:28 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id SAA26417; Mon, 14 Dec 1998 18:45:35 -0500 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of "14 Dec 1998 20:10:19 +0100" Date: 14 Dec 1998 18:45:35 -0500 Message-Id: Lines: 47 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Thanks! So, the upshot is: 1. symbols don't know where they are defined; 2. :use-module is not transitive (if I use A which uses B, I am not using B) what a horror. >>>> In message >>>> On the subject of "Re: (save-settings) from prefs-menu.scm doesn't work" >>>> Sent on 14 Dec 1998 20:10:19 +0100 >>>> Honorable Robert Bihlmeyer writes: >> Hi, >> >> >>>>> On 14 Dec 1998 10:31:18 -0500 >> >>>>> Sam Steingold said: >> >> Sam> Interesting. In CL, a symbol knows which package it belongs to. >> Sam> Not so in scheme? >> >> As I understand it, variables have no back-reference to their module, >> but are simply put into current module's obarray by `define'. >> `define-public' additionally adds the variable to the current module's >> public interface. >> >> You can import all variables in a module's public interface by >> `use-module'. This makes them visible in the current module, too. >> >> Sam> But I am using prefs-menu and I see the "specific parameters" >> Sam> submenu generated from `user-options'. >> >> The ":use-module (app scwm user-options)" clause pulls the >> `user-options' variable into pref-menu's namespace, but not into the >> root namespace. >> >> Robbe >> >> -- >> Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! >> >> -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Type louder, please. From owner-scwm-discuss@mit.edu Tue Dec 15 02:29:51 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id CAA12007 for scwm-discuss-outgoing; Tue, 15 Dec 1998 02:29:51 -0500 Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id CAA12004 for ; Tue, 15 Dec 1998 02:29:49 -0500 Received: from dur.tbit.dk by MIT.EDU with SMTP id AA08133; Tue, 15 Dec 98 02:29:12 EST Received: from chl.tbit.dk (chl.tbit.dk [194.182.135.65]) by dur.tbit.dk (8.8.8/8.8.8) with ESMTP id IAA09493; Tue, 15 Dec 1998 08:29:07 +0100 (MET) Received: (from chl@localhost) by chl.tbit.dk (8.8.8/8.8.8) id IAA17601; Tue, 15 Dec 1998 08:28:48 +0100 (MET) X-Authentication-Warning: chl.tbit.dk: chl set sender to chl@tbit.dk using -f From: Christian Lynbech Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13942.4015.511098.439381@chl> Date: Tue, 15 Dec 1998 08:28:47 +0100 (MET) To: Arturo Perez Cc: scwm-discuss@mit.edu Subject: Re: guild 1.3 not on solaris x86 In-Reply-To: <199812141711.MAA01953@ns1.infonautics.com> References: <199812141711.MAA01953@ns1.infonautics.com> X-Mailer: VM 6.59 under Emacs 20.3.1 Comments: Hyperbole mail buttons accepted, v04.023. Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>>> "Arturo" == Arturo Perez writes: Arturo> Although I can build and install libguile1.2 on solaris 2.6 on Arturo> Intel just fine, libguile1.3 fails to compile. What errors are you getting? It works fine for me (though I am mostly building on (intel) solaris 2.5.1). ---------------------------+-------------------------------------------------- Christian Lynbech | Telebit Communications A/S Fax: +45 8628 8186 | Fabrik 11, DK-8260 Viby J Phone: +45 8628 8177 + 28 | email: chl@tbit.dk --- URL: http://www.telebit.dk ---------------------------+-------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic@hal.com (Michael A. Petonic) From owner-scwm-discuss@mit.edu Wed Dec 16 01:36:03 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id BAA19000 for scwm-discuss-outgoing; Wed, 16 Dec 1998 01:36:03 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id BAA18994 for ; Wed, 16 Dec 1998 01:35:57 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA01229; Wed, 16 Dec 98 01:35:07 EST Received: (qmail 9439 invoked by uid 501); 16 Dec 1998 06:35:02 -0000 Message-Id: <19981215223502.A9323@molehill.org> Date: Tue, 15 Dec 1998 22:35:02 -0800 From: Todd Larason To: scwm-discuss list Subject: imlib module Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Kibo: Can you get in touch with vril? Sender: owner-scwm-discuss@mit.edu Precedence: bulk Yet another in my series of It Works For Me pre-patches. Anyone who wants to run with this is more than welcome to. It works on at least one computer. The current default image loader doesn't handle 24 bit images well, and is rather slow on big images. Imlib isn't blindlingly fast, but is quite a bit faster. the #if 0/#endif stuff at the bottom doesn't work - gh_lookup() doesn't find the symbol, because of the way the guile module system works. Is there a better way to do it? Right now, I'm calling register-image-loader from scheme after I load this module. /* * JTL:FIXME: * This is barely enough to consider a module * Among things that need to be done: * - add a configure test for imlib, only try to compile if it's found * - try to find a better solution than dlopen()ing and dlsym()ing every * symbol we need; a general solution would be nice. Investigate * guile-gtk's solution * - if nothing better is available, at least support all the methods * guile supports * - export WAY more of imlib's functionality * - hook into the scwm image cache and call the imlib free function when * appropriate */ #ifdef HAVE_CONFIG_H #include #endif #include #include #include #include "scwm.h" #include "xmisc.h" #include "image.h" void * imlib_handle; static ImlibData * imlib_data; ImlibData *(*dl_Imlib_init)(Display * disp); int (*dl_Imlib_load_file_to_pixmap)(ImlibData * id, char *filename, Pixmap * pmap, Pixmap * mask); SCWM_PROC(load_imlib, "load-imlib", 1, 0, 0, (SCM full_path)) /** Load an image file identified by the pathname FULL-PATH with imlib. */ #define FUNC_NAME s_load_imlib { ImlibImage *im; SCM result; char * c_path; int ignore, width, height; scwm_image *ci; c_path = gh_scm2newstr(full_path, &ignore); result = make_empty_image(full_path); ci = IMAGE(result); if (dl_Imlib_load_file_to_pixmap(imlib_data, c_path, &ci->image, &ci->mask)) { FXGetWindowSize(ci->image, &width, &height); ci->width = width; ci->height = height; ci->depth = DefaultDepthOfScreen(DefaultScreenOfDisplay(dpy)); ci->foreign = 1; /* JTL:FIXME: this prevents this from being freed out from under imlib, but there's no current way of being notified when it would be freed, and letting imlib do its thing */ } else { /* warn that the image could not be loaded, then drop the result on the floor and let GC clean it up. */ scwm_msg(WARN,FUNC_NAME,"Could not load image `%s'",c_path); result = SCM_BOOL_F; } FREE(c_path); return result; } #undef FUNC_NAME void init_imlib() { SCM val_load_imlib; imlib_handle = dlopen("libImlib.so.1", RTLD_GLOBAL | RTLD_NOW); if (imlib_handle == NULL) { scwm_msg(ERR, "init_imlib", "Couldn't load libImlib.\n"); return; } dl_Imlib_init = dlsym(imlib_handle, "Imlib_init"); if (dl_Imlib_init == NULL) { scwm_msg(ERR, "init_imlib", "Couldn't find Imlib_init"); dlclose(imlib_handle); return; } dl_Imlib_load_file_to_pixmap = dlsym(imlib_handle, "Imlib_load_file_to_pixmap"); if (dl_Imlib_load_file_to_pixmap == NULL) { scwm_msg(ERR, "init_imlib", "Couldn't find Imlib_load_file_to_pixmap"); dlclose(imlib_handle); return; } imlib_data = dl_Imlib_init(dpy); #ifndef SCM_MAGIC_SNARFER #include "imlib.x" #endif #if 0 val_load_imlib = gh_lookup("load-imlib"); if (val_load_imlib == SCM_UNDEFINED ) { scwm_msg(ERR,"init_imlib", "load-imlib not defined -- probable build error\n"); dlclose(imlib_handle); return; } register_image_loader (gh_str02scm(".jpg"), val_load_imlib); register_image_loader (gh_str02scm(".jpeg"), val_load_imlib); register_image_loader (gh_str02scm(".png"), val_load_imlib); register_image_loader (gh_str02scm(".tiff"), val_load_imlib); register_image_loader (gh_str02scm("default"), val_load_imlib); #endif } void scm_init_app_scwm_imlib_module() { scm_register_module_xxx("app scwm imlib", init_imlib); } /* Local Variables: */ /* tab-width: 8 */ /* c-basic-offset: 2 */ /* End: */ -- ICQ UIN: 115349102 From owner-scwm-discuss@mit.edu Wed Dec 16 08:48:44 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id IAA21845 for scwm-discuss-outgoing; Wed, 16 Dec 1998 08:48:44 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id IAA21842 for ; Wed, 16 Dec 1998 08:48:40 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA28171; Wed, 16 Dec 98 08:47:40 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id IAA00965; Wed, 16 Dec 1998 08:47:29 -0500 (EST) Message-Id: <199812161347.IAA00965@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Christian Lynbech Cc: scwm-discuss@mit.edu Subject: Re: guild 1.3 not on solaris x86 In-Reply-To: Your message of "Tue, 15 Dec 1998 08:28:47 +0100." <13942.4015.511098.439381@chl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Dec 1998 08:37:15 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <13942.4015.511098.439381@chl>, Christian Lynbech writes: >>>>>> "Arturo" == Arturo Perez writes: > >Arturo> Although I can build and install libguile1.2 on solaris 2.6 on >Arturo> Intel just fine, libguile1.3 fails to compile. > >What errors are you getting? > >It works fine for me (though I am mostly building on (intel) solaris 2.5.1). Here are the errors. I just did a configure (no options) and a make. $ uname -a; gcc --version SunOS tempest 5.6 Generic_105182-06 i86pc i386 i86pc 2.8.1 gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wpointer-arith -Wmissing-prototypes -c -fPIC -DPIC debug.c debug.x: In function `scm_init_debug': In file included from debug.c:670: debug.x:4: `s_make_gloc' undeclared (first use in this function) debug.x:4: (Each undeclared identifier is reported only once debug.x:4: for each function it appears in.) debug.x:4: `scm_make_gloc' undeclared (first use in this function) debug.x:5: `s_gloc_p' undeclared (first use in this function) debug.x:5: `scm_gloc_p' undeclared (first use in this function) debug.x:6: `s_make_iloc' undeclared (first use in this function) debug.x:6: `scm_make_iloc' undeclared (first use in this function) debug.x:7: `s_iloc_p' undeclared (first use in this function) debug.x:7: `scm_iloc_p' undeclared (first use in this function) debug.x:8: `s_memcons' undeclared (first use in this function) debug.x:8: `scm_memcons' undeclared (first use in this function) debug.x:9: `s_mem_to_proc' undeclared (first use in this function) debug.x:9: `scm_mem_to_proc' undeclared (first use in this function) debug.x:10: `s_proc_to_mem' undeclared (first use in this function) debug.x:10: `scm_proc_to_mem' undeclared (first use in this function) debug.x:18: `s_debug_hang' undeclared (first use in this function) debug.x:18: `scm_debug_hang' undeclared (first use in this function) make[1]: *** [debug.lo] Error 1 make[1]: Leaving directory `/home/arturo/guile-1.3/libguile' make: *** [all-recursive] Error 1 gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wpointer-arith -Wmissing-prototypes -c -fPIC -DPIC dynwind.c dynwind.x: In function `scm_init_dynwind': In file included from dynwind.c:243: dynwind.x:2: `s_wind_chain' undeclared (first use in this function) dynwind.x:2: (Each undeclared identifier is reported only once dynwind.x:2: for each function it appears in.) dynwind.x:2: `scm_wind_chain' undeclared (first use in this function) make[1]: *** [dynwind.lo] Error 1 gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wpointer-arith -Wmissing-prototypes -c -fPIC -DPIC ports.c ports.x: In function `scm_init_ports': In file included from ports.c:952: ports.x:9: `s_pt_size' undeclared (first use in this function) ports.x:9: (Each undeclared identifier is reported only once ports.x:9: for each function it appears in.) ports.x:10: `s_pt_member' undeclared (first use in this function) make[1]: *** [ports.lo] Error 1 gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wpointer-arith -Wmissing-prototypes -c -fPIC -DPIC print.c print.x: In function `scm_init_print': In file included from print.c:1007: print.x:2: `s_current_pstate' undeclared (first use in this function) print.x:2: (Each undeclared identifier is reported only once print.x:2: for each function it appears in.) print.x:2: `scm_current_pstate' undeclared (first use in this function) make[1]: *** [print.lo] Error 1 gcc -DHAVE_CONFIG_H -I. -I. -I. -I.. -I./.. -g -O2 -Wall -Wpointer-arith -Wmissing-prototypes -c -fPIC -DPIC procs.c procs.x: In function `scm_init_procs': In file included from procs.c:205: procs.x:1: `s_make_cclo' undeclared (first use in this function) procs.x:1: (Each undeclared identifier is reported only once procs.x:1: for each function it appears in.) procs.x:1: `scm_make_cclo' undeclared (first use in this function) make[1]: *** [procs.lo] Error 1 -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Wed Dec 16 10:43:16 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA22374 for scwm-discuss-outgoing; Wed, 16 Dec 1998 10:43:16 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id KAA22371 for ; Wed, 16 Dec 1998 10:43:11 -0500 Received: from mdj.nada.kth.se by MIT.EDU with SMTP id AA15567; Wed, 16 Dec 98 10:42:12 EST Received: (from mdj@localhost) by mdj.nada.kth.se (8.8.7/8.8.7) id QAA02642; Wed, 16 Dec 1998 16:42:04 +0100 (MET) Date: Wed, 16 Dec 1998 16:42:04 +0100 (MET) Message-Id: <199812161542.QAA02642@mdj.nada.kth.se> From: Mikael Djurfeldt To: scwm-discuss@mit.edu Cc: mstachow@mit.edu Subject: Newbie question: Remembering window geometry between sessions Reply-To: Mikael Djurfeldt Sender: owner-scwm-discuss@mit.edu Precedence: bulk Is there a simple way to get scwm to remember window geometry between sessions? E.g., if I used Emacs frames F1-F3 during a session and their final geometries (after my pushing around) was G1-G3, could I then get scwm to write G1-G3 down to a file when I quit, so that the first Emacs frame I open next time I start up get geometry G1? /mdj From owner-scwm-discuss@mit.edu Wed Dec 16 11:43:57 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA22967 for scwm-discuss-outgoing; Wed, 16 Dec 1998 11:43:57 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA22960; Wed, 16 Dec 1998 11:43:55 -0500 Message-Id: <199812161643.LAA22960@VICARIOUS-EXISTENCE.MIT.EDU> To: Mikael Djurfeldt cc: scwm-discuss@mit.edu Subject: Re: Newbie question: Remembering window geometry between sessions In-reply-to: Your message of "Wed, 16 Dec 1998 16:42:04 +0100." <199812161542.QAA02642@mdj.nada.kth.se> Date: Wed, 16 Dec 1998 11:43:55 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk mdj@nada.kth.se writes: > Is there a simple way to get scwm to remember window geometry between > sessions? > > E.g., if I used Emacs frames F1-F3 during a session and their final > geometries (after my pushing around) was G1-G3, could I then get scwm > to write G1-G3 down to a file when I quit, so that the first Emacs > frame I open next time I start up get geometry G1? > The right way to do this sort of thing is to use X Session Management and scwm's support for it. If scwm is run under xsm or another X Session Manager, it will save the geometry and other configuration info of windows on shutdown and restore it on restart of the session, and xsm will also ensure that the same applications are restarted, even restoring application state if the application supports session management (I am not sure if Emacs does). However, if you specifically want only the effect you described and not full session management, it is possible to add a shutdown hook that examines the window list and saves the geometry of each window; code that reads this list on startup; and a placement procedure that examines this list and places windows according to it, if they match in some appropriate way, consuming geometries as it goes. However, I think using session management is a better way to get that effect. - Maciej From owner-scwm-discuss@mit.edu Wed Dec 16 12:49:52 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id MAA23419 for scwm-discuss-outgoing; Wed, 16 Dec 1998 12:49:52 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id MAA23416 for ; Wed, 16 Dec 1998 12:49:42 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 16 Dec 1998 12:47:27 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 16 Dec 1998 12:47:27 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id MAA12994; Wed, 16 Dec 1998 12:48:03 -0500 To: scwm-discuss@mit.edu Subject: installation problems Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 16 Dec 1998 12:48:03 -0500 Message-ID: Lines: 44 Sender: owner-scwm-discuss@mit.edu Precedence: bulk $ make install .... make install-data-hook make[3]: Entering directory `/usr/src/scwm/modules/scwmgtkhelper' /bin/sh ../../mkinstalldirs /usr/local/share/scwm-modules/app/scwm rm -f /usr/local/lib/scwm-modules/app/scwm/libscwmgtkhelper.la ln -s /usr/local/lib/scwm/libscwmgtkhelper.la /usr/local/share/scwm-modules/app/scwm/libscwmgtkhelper.la ln: /usr/local/share/scwm-modules/app/scwm/libscwmgtkhelper.la: File exists make[3]: *** [install-data-hook] Error 1 make[3]: Leaving directory `/usr/src/scwm/modules/scwmgtkhelper' make[2]: *** [install-data] Error 2 make[2]: Leaving directory `/usr/src/scwm/modules/scwmgtkhelper' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/src/scwm/modules' make: *** [install-recursive] Error 1 Linux eho.eaglets.com 2.1.131 #4 Wed Dec 16 10:29:50 EST 1998 i686 unknown Guile verion: 1.3 Libguile timestamp: Tue Oct 20 23:18:53 PDT 1998 SCWM version: 0.9beta1 >From repository date: Sat Dec 12 22:57:43 EST 1998 -- $Revision: 1.1031 $ Restarted: false Display Size: 1280x1024 Desk Size: 2x2 Viewport Position: 0x0 Pointer: 919x927 Current Desk: 0 X vendor: The XFree86 Project, Inc; version: 11.0; release: 3320 X Display: Resolution: 2956x2951 Color: TrueColor (depth: 16; bits per RGB: 6) image-load-path: /usr/X11R6/include/X11/bitmaps /usr/X11R6/include/X11/pixmaps /X11/mini-icons /usr/local/include/X11/pixmaps /usr/local/include/X11/bitmaps /usr/local/lib/X11/mini-icons -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Lottery is a tax on statistics ignorants. MS is a tax on computer-idiots. From owner-scwm-discuss@mit.edu Wed Dec 16 15:44:08 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA24348 for scwm-discuss-outgoing; Wed, 16 Dec 1998 15:44:08 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA24342 for ; Wed, 16 Dec 1998 15:44:04 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA03218; Wed, 16 Dec 98 15:43:10 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA08974 for scwm-discuss@mit.edu; Wed, 16 Dec 1998 21:42:52 +0100 (MET) Received: (qmail 835 invoked by uid 115); 16 Dec 1998 20:30:06 -0000 To: scwm-discuss@mit.edu Subject: Re: (save-settings) from prefs-menu.scm doesn't work References: <199812100820.AAA21357@nebula.newtonlabs.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 16 Dec 1998 21:30:03 +0100 In-Reply-To: Sam Steingold's message of "14 Dec 1998 18:45:35 -0500" Message-Id: Lines: 20 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) X-Now-Playing: Jethro Tull - War Child 01 - WarChild Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 14 Dec 1998 18:45:35 -0500 >>>>> Sam Steingold said: Sam> Thanks! So, the upshot is: Sam> 1. symbols don't know where they are defined; Sam> 2. :use-module is not transitive (if I use A which uses B, I am Sam> not using B) Sam> what a horror. Hmm, I'm neutral towards 1, and actually think 2 a feature. YMMV, obviously. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Wed Dec 16 16:44:58 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id QAA24725 for scwm-discuss-outgoing; Wed, 16 Dec 1998 16:44:58 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id QAA24722 for ; Wed, 16 Dec 1998 16:44:53 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 16 Dec 1998 16:43:04 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 16 Dec 1998 16:43:04 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id QAA17937; Wed, 16 Dec 1998 16:43:37 -0500 To: Maciej Stachowiak Subject: user-options Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 16 Dec 1998 16:43:36 -0500 Message-ID: Lines: 26 Sender: owner-scwm-discuss@mit.edu Precedence: bulk an element of the list `user-options' is supposed to be (var comment setter getter) right now it has 23 elements, each a simple variable. The comment is obviously superfluous: (documentation var) should return it. The getter is likely to be the same as var, so it's not needed either. The setter will probably always be (string->symbol (string-append "set-" (symbol->string var) "!")) so why have a list of 4 elements when just one symbol is enough? The obvious problem is when the value of a simple variable is a function. Will it ever happen that a user-variable will take a function as a value? Are there any plans to add stuff to `user-options'? (like, say, `set-animation!' Another question: how do I get back my root module after (use-modules ...)? (after this command no root procedures, like `apropos', is available, I have to restart scwm(!) to get it back!) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Those who can laugh at themselves will never cease to be amused. From owner-scwm-discuss@mit.edu Wed Dec 16 23:11:30 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id XAA02885 for scwm-discuss-outgoing; Wed, 16 Dec 1998 23:11:30 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id XAA02882 for ; Wed, 16 Dec 1998 23:11:27 -0500 Received: from mtiwmhc02.worldnet.att.net by MIT.EDU with SMTP id AA15355; Wed, 16 Dec 98 23:11:30 EST Received: from brownie.esc.net.worldnet.att.net ([153.37.239.242]) by mtiwmhc02.worldnet.att.net (InterMail v03.02.05 118 121 101) with SMTP id <19981217041125.CMAZ17244@brownie.esc.net.worldnet.att.net> for ; Thu, 17 Dec 1998 04:11:25 +0000 To: scwm-discuss@mit.edu Subject: SCWM compilation---beginner's questions X-Face: =zxax\[Gy>RMztF.q3%oOWhwg\venL7mcj)hIi^@p!HA XC:8.(XKL{9e+u8q-C$7vIrC:ri61H'6{xdMQ5<{wxTbM.8#v*7FL>8dy?cJ?Wgi%],n$+mZzGv'%V A|;b%qb2Aw&[3'j*9OM!&JG$ea5af+gFX Date: 16 Dec 1998 23:18:58 -0500 Message-Id: Lines: 16 X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald" Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've been lurking on this list for quite some time and have decided its time to get involved with the bleeding-edge scwm in CVS. I've downloaded, compiled, and installed guile-1.3. I've also gotten all of the scwm sources out of CVS. Now, time to compile. I run ./autogen.sh which seems fine. Then, when I run ./configure --enable-maintainer-mode, I get the following: creating cache ./config.cache ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' I don't know much about automake/autoconf---what's going wrong? Best regards, Eric From owner-scwm-discuss@mit.edu Wed Dec 16 23:49:36 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id XAA03096 for scwm-discuss-outgoing; Wed, 16 Dec 1998 23:49:36 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id XAA03093 for ; Wed, 16 Dec 1998 23:49:35 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA20856; Wed, 16 Dec 98 23:49:38 EST Received: (qmail 24883 invoked by uid 501); 17 Dec 1998 04:49:39 -0000 Message-Id: <19981216204939.A24711@molehill.org> Date: Wed, 16 Dec 1998 20:49:39 -0800 From: Todd Larason To: Eric Crampton , scwm-discuss@mit.edu Subject: Re: SCWM compilation---beginner's questions References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Eric Crampton on Wed, Dec 16, 1998 at 11:18:58PM -0500 X-Kibo: There's one reason for reality, and it's atoms. Sender: owner-scwm-discuss@mit.edu Precedence: bulk > creating cache ./config.cache > ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' > ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' AM_INIT_AUTOMAKE should have been removed by autoconf, and shouldn't be in configure. autoconf should be getting the defintion of AM_INIT_AUTOMAKE indirectly from an init.m4 file installed my automake in autoconf's aclocal directory - /usr/share/aclocal in my case (Redhat Linux 5.2), likely /usr/local/share/aclocal on a system that doesn't ship with autoconf. So...first step is to figure out where autoconf looks for its m4 files. According to aclocal, that's ${prefix}/share/aclocal. You can look in your aclocal script to see what prefix is. The next step is to figure out where automake put its init.m4 file, and why it's not the same place. You can either move the init.m4 file by hand, reinstall automake so it agrees with autoconf, or run aclocal with arguments telling it what directories to look in. Hope this helps! -- ICQ UIN: 75329975 From owner-scwm-discuss@mit.edu Thu Dec 17 09:47:08 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id JAA06575 for scwm-discuss-outgoing; Thu, 17 Dec 1998 09:47:08 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id JAA06572 for ; Thu, 17 Dec 1998 09:47:05 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA27027; Thu, 17 Dec 98 09:47:08 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id JAA01293; Thu, 17 Dec 1998 09:46:48 -0500 (EST) Message-Id: <199812171446.JAA01293@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Christian Lynbech Cc: scwm-discuss@mit.edu Subject: Re: guild 1.3 not on solaris x86 In-Reply-To: Your message of "Thu, 17 Dec 1998 12:05:24 +0100." <13944.58740.80930.184564@chl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Dec 1998 09:36:34 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk In message <13944.58740.80930.184564@chl>, Christian Lynbech writes: >Your primary problem appears to be that debug.x contains garbage (to >some degree). > >Try also to rebuild >the system, and remember to start from a completely fresh >directory. A completely clean directory was the trick. Thanks! Now, on to scwm. -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Thu Dec 17 10:01:36 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA06757 for scwm-discuss-outgoing; Thu, 17 Dec 1998 10:01:36 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id KAA06754 for ; Thu, 17 Dec 1998 10:01:35 -0500 Received: from 205229026070.infonautics.com by MIT.EDU with SMTP id AA13989; Thu, 17 Dec 98 10:01:27 EST Received: from luckycharms.infonautics.com (luckycharms.infonautics.com [207.17.60.151]) by ns1.infonautics.com (8.9.1a/8.9.1/mailhost.m4/1.29) with ESMTP id KAA01637 for ; Thu, 17 Dec 1998 10:01:26 -0500 (EST) Message-Id: <199812171501.KAA01637@ns1.infonautics.com> X-Mailer: exmh version 2.0.2 2/24/98 To: scwm-discuss@mit.edu Subject: missing readline/history.h Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Dec 1998 09:51:13 -0500 From: Arturo Perez Sender: owner-scwm-discuss@mit.edu Precedence: bulk Where is supposed to come from when building scwm? SunOS tempest 5.6 Generic_105182-06 i86pc i386 i86pc gcc --version = 2.8.1 scwm-0.9beta1 gcc -DHAVE_CONFIG_H -I. -I. -I../../include -I/usr/openwin/include -g -O2 -c scwmrepl.c scwmrepl.c:27: readline/history.h: No such file or directory -- ---- Arturo Perez arturo@infonautics.com Too much information, like a bullet through my brain - The Police The way you do research ===> http://www.elibrary.com From owner-scwm-discuss@mit.edu Thu Dec 17 11:15:02 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA07401 for scwm-discuss-outgoing; Thu, 17 Dec 1998 11:15:02 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id LAA07395 for ; Thu, 17 Dec 1998 11:15:00 -0500 Received: from Cantor.suse.de by MIT.EDU with SMTP id AA08642; Thu, 17 Dec 98 11:14:52 EST Received: from Galois.suse.de (Galois.suse.de [194.112.123.130]) by mail.suse.de (Postfix) with ESMTP id E3E4F4FDA; Thu, 17 Dec 1998 17:14:57 +0100 (MET) Received: from Frechet.suse.de (Frechet.suse.de [10.0.0.27]) by Galois.suse.de (Postfix) with ESMTP id D1B171C752; Thu, 17 Dec 1998 17:14:57 +0100 (MET) Received: (from ke@localhost) by Frechet.suse.de (8.8.8/8.8.8) id RAA27556; Thu, 17 Dec 1998 17:14:23 +0100 To: Todd Larason Cc: Eric Crampton , scwm-discuss@mit.edu Subject: Re: SCWM compilation---beginner's questions References: <19981216204939.A24711@molehill.org> X-Emacs: Emacs 20.3, MULE 4.0 (HANANOEN) Mime-Version: 1.0 (generated by SEMI 1.8.5 - "Nishi-Takaoka") Content-Type: text/plain; charset=US-ASCII From: Karl Eichwalder Date: 17 Dec 1998 17:14:23 +0100 In-Reply-To: Todd Larason's message of "Wed, 16 Dec 1998 20:49:39 -0800" Message-Id: Lines: 11 X-Mailer: Semi-gnus 6.8.17 (based on Gnus 5.6.42; for SEMI 1.8, FLIM 1.8/1.9) Sender: owner-scwm-discuss@mit.edu Precedence: bulk Todd Larason writes: | AM_INIT_AUTOMAKE should have been removed by autoconf, and shouldn't | be in configure. Yes, but `configure' coming with ftp://huis-clos.mit.edu/pub/scwm/scwm-19981217.tar.gz is already broken -- but why ? %-) -- Karl Eichwalder From owner-scwm-discuss@mit.edu Fri Dec 18 09:34:50 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id JAA14790 for scwm-discuss-outgoing; Fri, 18 Dec 1998 09:34:50 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id JAA14787 for ; Fri, 18 Dec 1998 09:34:47 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA20930; Fri, 18 Dec 98 09:34:37 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Fri, 18 Dec 1998 15:33:15 +0100 Received: from enterprise.osterwald.de (root@h11.ts1.uni-hannover.de [130.75.249.11]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id PAA11125 for ; Fri, 18 Dec 1998 15:33:14 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id PAA01148; Fri, 18 Dec 1998 15:38:08 +0100 From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13946.26831.980923.538637@enterprise.osterwald.de> Date: Fri, 18 Dec 1998 15:38:07 +0100 (MET) To: scwm-discuss@mit.edu Subject: How to start scwm with xsm? X-Mailer: VM 6.62 under 21.0 "Poitou60" XEmacs Lucid (beta60) X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H; Fri, 18 Dec 1998 12:49:07 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA28866; Fri, 18 Dec 98 11:42:10 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id RAA04463 for scwm-discuss@mit.edu; Fri, 18 Dec 1998 17:14:27 +0100 (MET) Received: (qmail 2293 invoked by uid 115); 18 Dec 1998 12:22:57 -0000 To: scwm-discuss@mit.edu Subject: Re: user-options References: X-Attribution: Robbe From: Robert Bihlmeyer Date: 18 Dec 1998 13:22:54 +0100 In-Reply-To: Sam Steingold's message of "16 Dec 1998 16:43:36 -0500" Message-Id: Lines: 29 User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 16 Dec 1998 16:43:36 -0500 >>>>> Sam Steingold said: Sam> The getter is likely to be the same as var, so it's not needed Sam> either. It can't be in scheme, can it? Sam, could it be that you smoke too much of that unhealthy CL stuff ? So, in my conception, there are two possiblities: * a simple variable FOO, getter: `FOO', setter: `(set! FOO VALUE)', represented in `user-options' by just the symbol FOO. * a complex variable that has a specific getter/setter pair - since we have to disambiguate this case in `user-options' anyway, we can give the getter and setter functions in a cons. Example: (set! user-options '(xterm-command (animation . set-animation!))) (BTW, `animation' does not exist, yet). Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 18 13:54:14 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA16324 for scwm-discuss-outgoing; Fri, 18 Dec 1998 13:54:14 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA16321 for ; Fri, 18 Dec 1998 13:54:12 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA12721; Fri, 18 Dec 98 13:54:10 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Fri, 18 Dec 1998 13:53:51 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Fri, 18 Dec 1998 13:53:50 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id NAA11888; Fri, 18 Dec 1998 13:51:38 -0500 To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: user-options References: Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Robert Bihlmeyer's message of "18 Dec 1998 13:22:54 +0100" Date: 18 Dec 1998 13:51:38 -0500 Message-Id: Lines: 48 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message >>>> On the subject of "Re: user-options" >>>> Sent on 18 Dec 1998 13:22:54 +0100 >>>> Honorable Robert Bihlmeyer writes: >> >> >>>>> On 16 Dec 1998 16:43:36 -0500 >> >>>>> Sam Steingold said: >> >> Sam> The getter is likely to be the same as var, so it's not needed >> Sam> either. >> >> It can't be in scheme, can it? Sam, could it be that you smoke too >> much of that unhealthy CL stuff ? CL rulez. Extremists who disagree will be shot. >> So, in my conception, there are two possiblities: >> * a simple variable FOO, getter: `FOO', setter: `(set! FOO VALUE)', >> represented in `user-options' by just the symbol FOO. >> * a complex variable that has a specific getter/setter pair - since we >> have to disambiguate this case in `user-options' anyway, we can >> give the getter and setter functions in a cons. >> >> Example: >> >> (set! user-options '(xterm-command (animation . set-animation!))) >> >> (BTW, `animation' does not exist, yet). let me repeat my point (it would be nice if you looked at my previous message and told me what was confusing there :) `user-options' is a list of symbols. I take one of them, `FOO', and look at it's value (symbol-binding #f 'FOO) if it's a procedure, I decide that a value of a user option can't be a procedure [this is a weak point, but let me repeat: a user option is something the user will be typing in at a prompt. you don't expect him to type a `lambda', do you? if he can, he is using `scwmrepl' anyway], so this must be what Robbe called "a complex variable", so I assume that the getter is (FOO) and the setter is (SET-FOO! user-input). -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. Between grand theft and a legal fee, there only stands a law degree. From owner-scwm-discuss@mit.edu Fri Dec 18 15:28:43 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA16992 for scwm-discuss-outgoing; Fri, 18 Dec 1998 15:28:43 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA16989 for ; Fri, 18 Dec 1998 15:28:41 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA05340; Fri, 18 Dec 98 15:28:39 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA15667 for scwm-discuss@mit.edu; Fri, 18 Dec 1998 21:20:29 +0100 (MET) Received: (qmail 544 invoked by uid 115); 18 Dec 1998 17:43:09 -0000 To: scwm-discuss@mit.edu Subject: Re: missing readline/history.h References: <199812171501.KAA01637@ns1.infonautics.com> X-Attribution: Robbe From: Robert Bihlmeyer Date: 18 Dec 1998 18:43:06 +0100 In-Reply-To: Arturo Perez's message of "Thu, 17 Dec 1998 09:51:13 -0500" Message-Id: Lines: 16 User-Agent: Gnus/5.070068 (Pterodactyl Gnus v0.68) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Thu, 17 Dec 1998 09:51:13 -0500 >>>>> Arturo Perez said: Arturo> readline/history.h: No such file or directory This should only be included, if configure found a libreadline, and this library contained an add_history() function. Do you have the readline library, where does it store its include files? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 18 15:28:48 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA16997 for scwm-discuss-outgoing; Fri, 18 Dec 1998 15:28:48 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA16994 for ; Fri, 18 Dec 1998 15:28:48 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA05369; Fri, 18 Dec 98 15:28:46 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id VAA15669 for scwm-discuss@mit.edu; Fri, 18 Dec 1998 21:20:30 +0100 (MET) Received: (qmail 565 invoked by uid 115); 18 Dec 1998 17:50:37 -0000 To: scwm-discuss@mit.edu Subject: Re: How to start scwm with xsm? References: <13946.26831.980923.538637@enterprise.osterwald.de> X-Attribution: Robbe From: Robert Bihlmeyer Date: 18 Dec 1998 18:50:35 +0100 In-Reply-To: Heiko Muenkel's message of "Fri, 18 Dec 1998 15:38:07 +0100 (MET)" Message-Id: Lines: 28 User-Agent: Gnus/5.070068 (Pterodactyl Gnus v0.68) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Fri, 18 Dec 1998 15:38:07 +0100 (MET) >>>>> Heiko Muenkel said: Heiko> Hi, I've tried to start the xsm session manager at the end of Heiko> my ~/.xinitrc and have put the scwm start in .xsession. ^^^^^^^^^ That should probably be .xsmstartup Heiko> But xsm fails with the message: Heiko> Could not set authorization Heiko> After that the X server died. Interesting. xsm normally generates a magic cookie and stores it into ~/.ICEauth. Does this file exist? Is it writable/creatable? What does "iceauth list" show you? Heiko> Does anyone know how to start the xsm together with scwm? There are also some instructions on this topic in doc/session-management. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Fri Dec 18 17:23:07 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA17769 for scwm-discuss-outgoing; Fri, 18 Dec 1998 17:23:07 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA17766 for ; Fri, 18 Dec 1998 17:23:05 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA15662; Fri, 18 Dec 98 17:23:03 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA31340; Sat, 19 Dec 1998 00:22:56 +0200 To: scwm-discuss@mit.edu Subject: scwmdoc problem & automatic hell. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Dec 1998 00:22:56 +0200 Message-Id: Lines: 119 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I've finally gotten scwmdoc to run. I even upgraded perl & walked through a sewer (aka CPAN) to find Text::Balanced. The script seems to work, but it spewed lots of errors on its maiden voyage: hjstein@bacall:~/remote-cvs-pkgs/scwm/utilities/dev$ ./scwmdoc ../../scwm/window.c >/dev/null Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line 177. Use of uninitialized value at ./scwmdoc line 931, <> chunk 733. Use of uninitialized value at ./scwmdoc line 931, <> chunk 748. Use of uninitialized value at ./scwmdoc line 931, <> chunk 821. Use of uninitialized value at ./scwmdoc line 931, <> chunk 855. ../../scwm/window.c:871:**** get_window_context: scheme primitive name `window-context' does not match `get_window_context' Use of uninitialized value at ./scwmdoc line 931, <> chunk 876. Use of uninitialized value at ./scwmdoc line 931, <> chunk 889. Use of uninitialized value at ./scwmdoc line 931, <> chunk 899. ../../scwm/window.c:908:**** select_window_interactively: scheme primitive name `select-window-interactively-no-message' does not match `select_window_interactively' ../../scwm/window.c:908:**** select_window_interactively: `#define FUNC_NAME s_select_window_interactively' does not match function name `s_select_window_interactively_no_message' Use of uninitialized value at ./scwmdoc line 931, <> chunk 914. Use of uninitialized value at ./scwmdoc line 931, <> chunk 1575. Use of uninitialized value at ./scwmdoc line 931, <> chunk 1606. Use of uninitialized value at ./scwmdoc line 931, <> chunk 1636. Use of uninitialized value at ./scwmdoc line 931, <> chunk 1652. ... The error msgs goes on for about 300 lines or so. Why all the noise? I'm using perl 5.004_04. Please don't tell me to upgrade. BTW, I still can't build scwm from the CVS anon snap. It had been complaining about GTK+'s version (found 1.0.6, needs 1.0.4, which really bugged me because two steps of minor revisions just *shouldn't* matter), so I started trying to get GTK+ to build from the CVS tree. This required all sorts of upgrades, all of which I did, & *still* failed, the piece of (curse :volume 'hi :length 'long :mood 'foul) software, but I finally managed to get it installed (from source RPMs). In any case, I updated my copy of scwm from the anon CVS tree & it *still* doesn't build! Now I get: checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes ltconfig: unrecognized option `--no-reexec' Try `ltconfig --help' for more information. configure: error: libtool configure failed when it trys to configure itself. Backtracking, I find this in configure: # Actually configure libtool. ac_aux_dir is where install-sh is # found. CC="$CC" CFLAGS="$CFLAGS" CPPFLAGS="$CPPFLAGS" \ LD="$LD" NM="$NM" RANLIB="$RANLIB" LN_S="$LN_S" \ ${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig --no-reexec \ $libtool_flags --no-verify $ac_aux_dir/ltmain.sh $host \ || { echo "configure: error: libtool configure failed" 1>&2; exit 1; } but running some of the ltconfig programs on my system (and *everyone* seems to have one included!) shows that they don't take the --no-reexec flag. So where is this comming from? configure.in seems to just have: AM_PROG_LIBTOOL which generates the above. So, now what? Well, grepping in /usr/share/aclocal for libtool gets me into libtool.m4 which has the offensive use of --no-reexec as an argument to ltconfig. If this was just occurring in the scwm package, I'd just hack it there & continue on. But, when it's occurring in the system installed crap, then it's just too dangerous to hack it like that. How did /usr/share/aclocal/libtool.m4 get out of sync with ltconfig? Well, it looks like it's because I installed libtool-1.2b because it seemed like it might be the reason I couldn't get GTK+ from CVS to configure itself. So, I downgraded to 1.2 & the offensive flag in /usr/share/aclocal/libtool.m4 disapeared. But, I *still* got the same failure! Gues what - this autoauto crap isn't as auto as you'd like - I had an aclocal.m4 in the directory (evidentally built by configuring), and it wasn't rebuilt automatically when it became out of date - the danger of not using make to configure! In any case, the damn thing finally configures, but not cleanly: hjstein@bacall:~/remote-cvs-pkgs/scwm$ ./autogen.sh aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' creating Makefile ... It seems that adding gtk.m4 without checking for it's existence might help those who don't have gtk, but hurts those that do. Actually, I'm getting a little fuzzy at this point. I had a successful configure after removing *.m4, and I don't remember if just removing aclocal.m4 was sufficient. In any case, it seems to be OK now - at least I've finally managed to get to the compilation part of the build. As someone said the guile list, this auto-auto-config stuff is really getting *way* out of hand. Between it and everyone requiring the latest bleeding edge version of everything else it's really making it impossible for people to tag along with the development versions. -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Fri Dec 18 20:08:01 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id UAA18444 for scwm-discuss-outgoing; Fri, 18 Dec 1998 20:08:01 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id UAA18438 for ; Fri, 18 Dec 1998 20:07:54 -0500 Received: from ppp8.ltnb.lu by MIT.EDU with SMTP id AA12347; Fri, 18 Dec 98 20:07:53 EST Received: (from bob@localhost) by iceberg.localnet (8.9.1a/8.9.1) id CAA06615; Sat, 19 Dec 1998 02:07:55 +0100 (CET) From: Bob Pepin Message-Id: <19981219020748.A7380@iceberg.localnet> Date: Sat, 19 Dec 1998 02:07:49 +0100 To: Karl Eichwalder Cc: scwm-discuss@mit.edu Subject: Re: SCWM compilation---beginner's questions References: <19981216204939.A24711@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Karl Eichwalder on Thu, Dec 17, 1998 at 05:14:23PM +0100 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Thu, Dec 17, 1998 at 05:14:23PM +0100, Karl Eichwalder wrote: > Todd Larason writes: > > | AM_INIT_AUTOMAKE should have been removed by autoconf, and shouldn't > | be in configure. > > Yes, but `configure' coming with > ftp://huis-clos.mit.edu/pub/scwm/scwm-19981217.tar.gz is already broken > -- but why ? %-) > works fine if you remove gtk.m4 from scwm directory. (scwm from cvs, OpenBSD 2.4, suse linux 5.3) -- "Grant me the serenity to accept the things I cannot change; the courage to change the things I cannot accept; and the wisdom to hide the bodies of those people I had to kill today because they ticked me off". From owner-scwm-discuss@mit.edu Fri Dec 18 20:45:16 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id UAA18650 for scwm-discuss-outgoing; Fri, 18 Dec 1998 20:45:16 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id UAA18647 for ; Fri, 18 Dec 1998 20:45:15 -0500 Received: from ppp8.ltnb.lu by MIT.EDU with SMTP id AA16607; Fri, 18 Dec 98 20:45:13 EST Received: (from bob@localhost) by iceberg.localnet (8.9.1a/8.9.1) id CAA29134 for scwm-discuss@mit.edu; Sat, 19 Dec 1998 02:45:23 +0100 (CET) From: Bob Pepin Date: Sat, 19 Dec 1998 02:45:21 +0100 To: scwm-discuss@mit.edu Subject: SCWM won't start... Message-Id: <19981219024521.A21736@iceberg.localnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, since about 2 weeks, scwm is aborting at start with the following error message: ERROR: In procedure list: ERROR: end of file in a snippet from kdump output: 16780 scwm NAMI "/usr/local/share/guile/1.3.1/ice-9/version.scm" 16780 scwm RET open 4 16780 scwm CALL fstat(0x4,0xefbfd578) 16780 scwm RET fstat 0 16780 scwm CALL read(0x4,0x98000,0x2000) 16780 scwm GIO fd 4 read 61 bytes "(define (ice-9-config-stamp) "Sat Dec 19 02:19:50 CET 1998") " 16780 scwm RET read 61/0x3d 16780 scwm CALL read(0x4,0x98000,0x2000) 16780 scwm GIO fd 4 read 0 bytes "" 16780 scwm RET read 0 16780 scwm CALL close(0x4) after that, it only calls the functions to print the error message... didn't report this earlier because I thought it had to do something with my box (OpenBSD 2.4), but yesterday I tried to run it on suse linux 5.3 with the same error... I'm using scwm and guile from CVS... -- "Grant me the serenity to accept the things I cannot change; the courage to change the things I cannot accept; and the wisdom to hide the bodies of those people I had to kill today because they ticked me off". From owner-scwm-discuss@mit.edu Fri Dec 18 20:53:44 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id UAA18763 for scwm-discuss-outgoing; Fri, 18 Dec 1998 20:53:44 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id UAA18760 for ; Fri, 18 Dec 1998 20:53:43 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA17427; Fri, 18 Dec 98 20:53:41 EST Received: (qmail 19384 invoked by uid 501); 19 Dec 1998 01:54:24 -0000 Message-Id: <19981218175424.A19296@molehill.org> Date: Fri, 18 Dec 1998 17:54:24 -0800 From: Todd Larason To: "Harvey J. Stein" , scwm-discuss@mit.edu Subject: Re: scwmdoc problem & automatic hell. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Harvey J. Stein on Sat, Dec 19, 1998 at 12:22:56AM +0200 X-Kibo: Love is the luxury of Kibology. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981219, Harvey J. Stein wrote: > Use of uninitialized value at /usr/lib/perl5/File/Basename.pm line > 177. not sure about that one > Use of uninitialized value at ./scwmdoc line 931, <> chunk 733. set the SCWMDIR environment variable to the top of your SCWM source tree. I thought I'd fixed it so that wasn't needed, but either I was wrong or it got broke again. Okay, I've checked in a fix for that. > ../../scwm/window.c:871:**** get_window_context: scheme primitive name > `window-context' does not match `get_window_context' things like this are real errors, or at least things inconsistent with the semi-formal naming guidelines. I can certainly sympathize with your aggravation with trying to get working sets of GTK+ and everything else, but I also understand the other side; the gtk/glib/gnome people are working *fast*, and it's hard enough doing what they're doing without sometimes losing backwards compatibility. Maybe until things calm down some, gtk should only be probed for if configure is given a --with-gtk option? The libtool problem was discussed earlier this week, or last week. Was the consensus to remove ltconfig and ltmain.sh from the CVS tree, but include them in any distribution that also includes 'configure'? -- A whole lot of what makes Linux so good is Linus saying "no". And a whole lot of what makes open software work is development being able to tell marketing to write the code themselves if they are so technically saavy. -- yodaiken@chelm.cs.nmt.edu ICQ UIN: 50294884 From owner-scwm-discuss@mit.edu Sat Dec 19 14:15:51 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id OAA24966 for scwm-discuss-outgoing; Sat, 19 Dec 1998 14:15:51 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id OAA24963 for ; Sat, 19 Dec 1998 14:15:49 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA04627; Sat, 19 Dec 98 14:15:45 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id UAA15080 for scwm-discuss@mit.edu; Sat, 19 Dec 1998 20:00:38 +0100 (MET) Received: (qmail 5857 invoked by uid 115); 19 Dec 1998 16:23:16 -0000 To: scwm-discuss@mit.edu Subject: Re: user-options References: X-Attribution: Robbe From: Robert Bihlmeyer Date: 19 Dec 1998 17:23:14 +0100 In-Reply-To: Sam Steingold's message of "18 Dec 1998 13:51:38 -0500" Message-Id: Lines: 33 User-Agent: Gnus/5.070068 (Pterodactyl Gnus v0.68) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On 18 Dec 1998 13:51:38 -0500 >>>>> Sam Steingold said: Sam> let me repeat my point (it would be nice if you looked at my Sam> previous message and told me what was confusing there :) You didn't mention that you wanted to discern "simple" from "complex" variables by checking if their binding was a function. Or I'm blind. Anyway ... Sam> `user-options' is a list of symbols. I take one of them, `FOO', Sam> and look at it's value Sam> (symbol-binding #f 'FOO) Sam> if it's a procedure, I decide that a value of a user option Sam> can't be a procedure [this is a weak point, but let me repeat: a Sam> user option is something the user will be typing in at a prompt. Sam> you don't expect him to type a `lambda', do you? if he can, he Sam> is using `scwmrepl' anyway], so this must be what Robbe called Sam> "a complex variable", so I assume that the getter is (FOO) and Sam> the setter is (SET-FOO! user-input). Ok, suppose that I'm a power-user, know what scwmrepl &c is for, and want to set a user-option to a lambda? Will prefs-menu fail from then on? What if I like it, but want to set this one variable in a more complicated way? Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Sat Dec 19 16:49:07 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id QAA25627 for scwm-discuss-outgoing; Sat, 19 Dec 1998 16:49:07 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id QAA25624 for ; Sat, 19 Dec 1998 16:49:04 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA03470; Sat, 19 Dec 98 16:48:56 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id XAA05504; Sat, 19 Dec 1998 23:48:51 +0200 To: scwm-discuss@mit.edu Subject: Strange syntax. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 19 Dec 1998 23:48:50 +0200 In-Reply-To: Robert Bihlmeyer's message of "19 Dec 1998 17:23:14 +0100" Message-Id: Lines: 37 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk In scheme/wininfo.scm, I understand: (define*-public (on-desk? n #&optional (win (get-window))) ...) and: (define*-public (on-current-desk? #&optional (win (get-window))) "Return #t if WIN is on the current desk." (on-desk? (current-desk) win)) but what's: (define*-public ((on-desk-n? n) #&optional (win (get-window))) ...) and: (define*-public ((window-overlaps-window? #&optional (win (get-window))) #&optional (win2 (get-window))) ...) Are these bugs or some sort of new bizarre syntax? There's also what appears to be two much depth in scwm/scheme/winops.scm: (define*-public ((make-toggling-winop pred neg pos) #&optional (win (get-window))) ...). -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sat Dec 19 17:17:51 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA25812 for scwm-discuss-outgoing; Sat, 19 Dec 1998 17:17:51 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA25809 for ; Sat, 19 Dec 1998 17:17:50 -0500 Received: from M66-080-1.MIT.EDU by MIT.EDU with SMTP id AA06056; Sat, 19 Dec 98 17:17:42 EST Received: by M66-080-1.mit.edu (SMI-8.6/4.7) id RAA27633; Sat, 19 Dec 1998 17:17:43 -0500 Message-Id: <199812192217.RAA27633@M66-080-1.mit.edu> To: hjstein@bfr.co.il (Harvey J. Stein) Cc: scwm-discuss@mit.edu Subject: Re: Strange syntax. In-Reply-To: Your message of "19 Dec 1998 23:48:50 +0200." Date: Sat, 19 Dec 1998 17:17:43 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk Guile (and several other Scheme dialects) have the convenient syntactic extension that (define ((foo a b ...) x y ...) ...code...) is equivalent to (define foo (lambda (a b ...) (lambda (x y ...) ...code...))) The same applies for any level of nesting. - Maciej From owner-scwm-discuss@mit.edu Sat Dec 19 17:28:11 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA25917 for scwm-discuss-outgoing; Sat, 19 Dec 1998 17:28:11 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA25914 for ; Sat, 19 Dec 1998 17:28:10 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA22638; Sat, 19 Dec 98 17:28:03 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id AAA05739; Sun, 20 Dec 1998 00:28:02 +0200 To: Maciej Stachowiak Cc: scwm-discuss@mit.edu Subject: Re: Strange syntax. References: <199812192217.RAA27633@M66-080-1.mit.edu> Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Dec 1998 00:28:01 +0200 In-Reply-To: Maciej Stachowiak's message of "Sat, 19 Dec 1998 17:17:43 EST" Message-Id: Lines: 24 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Maciej Stachowiak writes: > Guile (and several other Scheme dialects) have the convenient > syntactic extension that > > (define ((foo a b ...) x y ...) > ...code...) > > is equivalent to > > (define foo > (lambda (a b ...) > (lambda (x y ...) > ...code...))) > > > The same applies for any level of nesting. Thanks. I've never seen it before... -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Sun Dec 20 07:06:20 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id HAA30329 for scwm-discuss-outgoing; Sun, 20 Dec 1998 07:06:20 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id HAA30326 for ; Sun, 20 Dec 1998 07:06:16 -0500 Received: from morannon.bfr.co.il by MIT.EDU with SMTP id AA12850; Sun, 20 Dec 98 07:06:04 EST Received: (from hjstein@localhost) by blinky.bfr.co.il (8.8.5/8.6.9) id OAA10483; Sun, 20 Dec 1998 14:06:02 +0200 To: scwm-discuss@mit.edu Subject: Proliferation of text files. Cc: hjstein@bfr.co.il From: hjstein@bfr.co.il (Harvey J. Stein) Date: 20 Dec 1998 14:06:02 +0200 In-Reply-To: hjstein@bfr.co.il's message of "20 Dec 1998 00:28:01 +0200" Message-Id: Lines: 28 X-Mailer: Gnus v5.6.4/Emacs 19.34 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Any reasons in particular to have scwm-concepts.txt, scwm-hooks.txt, and scwm-variables.txt in addition to scwm-procedures.txt? Why not just output everything in text format to scwm.txt? I'd rather output everything to scwm.txt (with a header for each section), because it seems to me that the above implies either a cmd line option for output of each of these files (with a corresponding file name to use for the output), or a cmd line option for outputting all of the above which takes the start of the file name as input (as in --text-output scwm & the program tacks on -concepts.txt, -hooks.txt, ...). I don't like the former because of the proliferation of cmd line options & the fact that the embedded docs include chapter headings already. I don't want to have to add options for each new chapter, or modify the code when if the chapter tag names are changed. I don't like the latter either because of the potential for creating gobs of files & because it seems just generally ugly to input a file name prefix. So, are there any reasons in particular for keeping it this way? -- Harvey J. Stein BFM Financial Research hjstein@bfr.co.il From owner-scwm-discuss@mit.edu Mon Dec 21 15:35:02 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA17426 for scwm-discuss-outgoing; Mon, 21 Dec 1998 15:35:02 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id PAA17417 for ; Mon, 21 Dec 1998 15:34:47 -0500 Received: from dsl-209-162-216-44.easystreet.com by MIT.EDU with SMTP id AA05604; Mon, 21 Dec 98 15:34:15 EST Received: (qmail 12775 invoked by uid 501); 21 Dec 1998 20:34:30 -0000 Message-Id: <19981221123430.A11612@molehill.org> Date: Mon, 21 Dec 1998 12:34:30 -0800 From: Todd Larason To: scwm-discuss list Subject: build issues Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Kibo: I think you are not Xibotic little of the time. Sender: owner-scwm-discuss@mit.edu Precedence: bulk I'm still having to muck with symlinks after every install to get modules to work. Do we have a consensus which way to go to fix this? I assume we still want to work with 1.3 released? I'm getting a new error at link time: /usr/bin/ld: warning: libXt.so.6, needed by /usr/X11R6/lib/libXmu.so, not found (try using --rpath) I put /usr/X11R6/lib in LD_RUN_PATH and that seems to have fixed it. I assume this is caused by something different in how my new X libraries were compiled? Should we be explicitely linking with -lXt? -- ICQ UIN: 129425988 From owner-scwm-discuss@mit.edu Mon Dec 21 15:52:52 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA17601 for scwm-discuss-outgoing; Mon, 21 Dec 1998 15:52:52 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id PAA17593; Mon, 21 Dec 1998 15:52:48 -0500 Message-Id: <199812212052.PAA17593@VICARIOUS-EXISTENCE.MIT.EDU> To: Todd Larason cc: scwm-discuss@mit.edu Subject: Re: build issues In-reply-to: Your message of "Mon, 21 Dec 1998 12:34:30 PST." <19981221123430.A11612@molehill.org> Date: Mon, 21 Dec 1998 15:52:48 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk jtl@molehill.org writes: > I'm still having to muck with symlinks after every install to get modules to > work. Do we have a consensus which way to go to fix this? I assume we still > want to work with 1.3 released? > I want to see it go back to how it was before. This version is clearly breaking for many people. I will do it myself unless someone beats me to it. > I'm getting a new error at link time: > /usr/bin/ld: warning: libXt.so.6, needed by /usr/X11R6/lib/libXmu.so, not found (try using --rpath) > > I put /usr/X11R6/lib in LD_RUN_PATH and that seems to have fixed it. I assume > this is caused by something different in how my new X libraries were compiled? Probably. > Should we be explicitely linking with -lXt? I don't think so, at least I've never heard of a documented dependency between Xmu and Xt before. - Maciej From owner-scwm-discuss@mit.edu Tue Dec 22 09:52:10 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id JAA32237 for scwm-discuss-outgoing; Tue, 22 Dec 1998 09:52:10 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id JAA32234 for ; Tue, 22 Dec 1998 09:52:08 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA27122; Tue, 22 Dec 98 09:52:04 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Tue, 22 Dec 1998 15:41:08 +0100 Received: from ull.tnt.uni-hannover.de (muenkel@ull.tnt.uni-hannover.de [130.75.31.171]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id PAA12645; Tue, 22 Dec 1998 15:41:07 +0100 (MET) Received: (from muenkel@localhost) by ull.tnt.uni-hannover.de (8.8.8/8.8.8) id PAA08457; Tue, 22 Dec 1998 15:41:06 +0100 Date: Tue, 22 Dec 1998 15:41:06 +0100 Message-Id: <199812221441.PAA08457@ull.tnt.uni-hannover.de> From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: robbe@orcus.priv.at Cc: scwm-discuss@mit.edu Subject: Re: How to start scwm with xsm? In-Reply-To: References: <13946.26831.980923.538637@enterprise.osterwald.de> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2> y]f{HzB|Q (\V9+y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{ HS@NEv9c.VII+9PgXHASx}K(jy^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!] 4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_xzuXJJ7W(EGqnzB]`]aq??;+z=) DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Robbe" == Robert Bihlmeyer writes: Robbe> Hi, >>>>> On Fri, 18 Dec 1998 15:38:07 +0100 (MET) >>>>> Heiko Muenkel said: Heiko> Hi, I've tried to start the xsm session manager at the end Heiko> of my ~/.xinitrc and have put the scwm start in .xsession. Robbe> Robbe> ^^^^^^^^^ That should probably be .xsmstartup I've changed that, but it makes no difference. Heiko> But xsm fails with the message: Could not set authorization Heiko> After that the X server died. Robbe> Interesting. xsm normally generates a magic cookie and Robbe> stores it into ~/.ICEauth. Does this file exist? Is it Robbe> writable/creatable? What does "iceauth list" show you? It is readable and writeable for the user. iceauth list shows: ICE "" tcp/enterprise:1052 MIT-MAGIC-COOKIE-1 fc3a12f8f72ef0f7f40582dcbc284a07 XSMP "" tcp/enterprise:1052 MIT-MAGIC-COOKIE-1 fc3a12f8f72ef0f7f40582dcbc284a07 ICE "" local/enterprise:/tmp/.ICE-unix/3774 MIT-MAGIC-COOKIE-1 fc3a12f8f72ef0f7f 40582dcbc284a07 XSMP "" local/enterprise:/tmp/.ICE-unix/3774 MIT-MAGIC-COOKIE-1 fc3a12f8f72ef0f7 f40582dcbc284a07 I don't remember when and why I'd make these entries. Are they looking good? Are there any environment variables for iceauth, like XAUTHORITY for xauth? Are the iceauth and the xauth entries linked in any way? Do you know of any place, where I can get more information about iceauth? The man page is very poor. Heiko> Does anyone know how to start the xsm together with scwm? Robbe> There are also some instructions on this topic in Robbe> doc/session-management. Thanks for the hints, Heiko From owner-scwm-discuss@mit.edu Wed Dec 23 16:42:21 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id QAA07793 for scwm-discuss-outgoing; Wed, 23 Dec 1998 16:42:21 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id QAA07790 for ; Wed, 23 Dec 1998 16:42:18 -0500 Received: from csgrad.cs.vt.edu by MIT.EDU with SMTP id AA18036; Wed, 23 Dec 98 16:42:06 EST Received: from localhost (cstruble@localhost) by csgrad.cs.vt.edu (8.9.1a/8.9.1) with SMTP id QAA06707; Wed, 23 Dec 1998 16:42:00 -0500 (EST) X-Authentication-Warning: csgrad.cs.vt.edu: cstruble owned process doing -bs Date: Wed, 23 Dec 1998 16:42:00 -0500 (EST) From: "Craig A. Struble" X-Sender: cstruble@csgrad.cs.vt.edu To: Todd Larason Cc: scwm-discuss list Subject: Re: build issues In-Reply-To: <19981221123430.A11612@molehill.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Mon, 21 Dec 1998, Todd Larason wrote: > I'm still having to muck with symlinks after every install to get modules to > work. Do we have a consensus which way to go to fix this? I assume we still > want to work with 1.3 released? > > I'm getting a new error at link time: > /usr/bin/ld: warning: libXt.so.6, needed by /usr/X11R6/lib/libXmu.so, not found (try using --rpath) > > I put /usr/X11R6/lib in LD_RUN_PATH and that seems to have fixed it. I assume > this is caused by something different in how my new X libraries were compiled? > Should we be explicitely linking with -lXt? I saw this happen when I switched from FreeBSD 2.2.7 to FreeBSD 3.0. I'm presuming it's a result of the switch to ELF. I noticed that most of the X11 ports for FreeBSD patch the config files to include the --rpath parameter with the compiler. In fact, I had some trouble configuring scwm until I set LD_RUN_PATH (and --rpath for good measure). See ya later, Craig -- Craig Struble (cstruble@vt.edu) Ph.D. Candidate, Virginia Tech http://www.acm.vt.edu/~cstruble/ cstruble@vt.edu From owner-scwm-discuss@mit.edu Wed Dec 23 18:49:29 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id SAA08409 for scwm-discuss-outgoing; Wed, 23 Dec 1998 18:49:29 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id SAA08406 for ; Wed, 23 Dec 1998 18:49:26 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Wed, 23 Dec 1998 18:48:30 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Wed, 23 Dec 1998 18:48:30 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id SAA08460; Wed, 23 Dec 1998 18:47:39 -0500 To: Maciej Stachowiak Subject: crash on startup Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 23 Dec 1998 18:47:39 -0500 Message-ID: Lines: 32 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I get the following crash immediately on startup: $ gdb scwm GNU gdb 981029 with Linux/x86 hardware watchpoint and FPU support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run Starting program: /usr/src/scwm/scwm/scwm Program received signal SIGSEGV, Segmentation fault. 0x402455bd in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) at iosetvbuf.c:92 92 iosetvbuf.c: No such file or directory. (gdb) p *fp $1 = {_flags = -72540024, _IO_read_ptr = 0x0, _IO_read_end = 0x0, _IO_read_base = 0x0, _IO_write_base = 0x0, _IO_write_ptr = 0x0, _IO_write_end = 0x0, _IO_buf_base = 0x0, _IO_buf_end = 0x0, _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 0, _blksize = 0, _old_offset = 0, _cur_column = 0, _vtable_offset = 0 '\000', _shortbuf = "", _lock = 0x401e7ca0, _offset = 1075740480, _unused2 = {0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, -72540028, 0, 0, 0, 0}} -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. All extremists should be taken out and shot. From owner-scwm-discuss@mit.edu Wed Dec 23 19:31:38 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id TAA08777 for scwm-discuss-outgoing; Wed, 23 Dec 1998 19:31:38 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id TAA08774 for ; Wed, 23 Dec 1998 19:31:35 -0500 Received: from molehill.easystreet.com by MIT.EDU with SMTP id AA02826; Wed, 23 Dec 98 19:31:28 EST Received: (qmail 25864 invoked by uid 501); 24 Dec 1998 00:34:21 -0000 Message-Id: <19981223163421.A25837@molehill.org> Date: Wed, 23 Dec 1998 16:34:21 -0800 From: Todd Larason To: "Craig A. Struble" Cc: scwm-discuss list Subject: Re: build issues References: <19981221123430.A11612@molehill.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Craig A. Struble on Wed, Dec 23, 1998 at 04:42:00PM -0500 X-Kibo: There's one reason for the Void, and it's deadly radiation that comes out of TV sets. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981223, Craig A. Struble wrote: > I saw this happen when I switched from FreeBSD 2.2.7 to FreeBSD 3.0. I'm > presuming it's a result of the switch to ELF. I've been on an ELF system for a long time, but recently switched from using the Redhat X binaries to a set I compiled myself; I assume I did something slightly different. Or maybe it's something different in the XFree86 3.3.3 distribution? Is anybody else using it? -- ICQ UIN: 54712952 From owner-scwm-discuss@mit.edu Wed Dec 23 19:36:05 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id TAA08837 for scwm-discuss-outgoing; Wed, 23 Dec 1998 19:36:05 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id TAA08834 for ; Wed, 23 Dec 1998 19:36:03 -0500 Received: from molehill.easystreet.com by MIT.EDU with SMTP id AA10459; Wed, 23 Dec 98 19:35:50 EST Received: (qmail 25883 invoked by uid 501); 24 Dec 1998 00:38:50 -0000 Message-Id: <19981223163850.B25837@molehill.org> Date: Wed, 23 Dec 1998 16:38:50 -0800 From: Todd Larason To: sds@goems.com, Maciej Stachowiak Subject: Re: crash on startup References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sam Steingold on Wed, Dec 23, 1998 at 06:47:39PM -0500 X-Kibo: Being allowed makes sense. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981223, Sam Steingold wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x402455bd in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) > at iosetvbuf.c:92 This looks like it's one of the setlinebuf()s in scwm.c, about line 540. Unless you're building an internationalized version, extremely little has been done at this point - scwm_gh_enter() has done the guile initialiation and called scwm_main(), which has switched to the guile module. If you're using a recent guile snapshot, *suppress-old-style-hook-warning* has been set to #t. And that's it. Can you verify that's where the setvbuf call is being made? There aren't any others in scwm proper, but another library function might be doing it. If that's it, can you verify you aren't building with I18N #defined? What version of guile are you using? -- ICQ UIN: 22992107 From owner-scwm-discuss@mit.edu Thu Dec 24 02:59:14 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id CAA11428 for scwm-discuss-outgoing; Thu, 24 Dec 1998 02:59:14 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id CAA11422; Thu, 24 Dec 1998 02:59:10 -0500 Message-Id: <199812240759.CAA11422@VICARIOUS-EXISTENCE.MIT.EDU> To: "Craig A. Struble" cc: scwm-discuss@mit.edu Subject: Re: build issues In-reply-to: Your message of "Wed, 23 Dec 1998 16:42:00 EST." Date: Thu, 24 Dec 1998 02:59:10 EST From: Maciej Stachowiak Sender: owner-scwm-discuss@mit.edu Precedence: bulk cstruble@vt.edu writes: > On Mon, 21 Dec 1998, Todd Larason wrote: > > > I'm still having to muck with symlinks after every install to get modules t > o > > work. Do we have a consensus which way to go to fix this? I assume we sti > ll > > want to work with 1.3 released? > > > > I'm getting a new error at link time: > > /usr/bin/ld: warning: libXt.so.6, needed by /usr/X11R6/lib/libXmu.so, not f > ound (try using --rpath) > > > > I put /usr/X11R6/lib in LD_RUN_PATH and that seems to have fixed it. I ass > ume > > this is caused by something different in how my new X libraries were compil > ed? > > Should we be explicitely linking with -lXt? > > I saw this happen when I switched from FreeBSD 2.2.7 to FreeBSD 3.0. I'm > presuming it's a result of the switch to ELF. I noticed that most of the > X11 ports for FreeBSD patch the config files to include the --rpath > parameter with the compiler. In fact, I had some trouble configuring scwm > until I set LD_RUN_PATH (and --rpath for good measure). > Hmm, I just did an nm and libXmu has numerous references to symbols from libXmu. Thus, for the sake of toolchains that don't deal with shared library dependencies, we should probably explicitly check for and link against libXt for the sake of systems that don't deal with library dependencies properly. Actually, this got me to wondering what we were using Xmu for exactly. It turns out to be only one call to XmuPrintDefaultErrorMessage() in scwm.c, which according to the docs seems to do the something roughly equivalent to the code in the other branch of the relevant #ifdef. I think it would be better to remove this call and not force the link against libXmu and thus libXt. In a world where more and more apps are based on Gtk or Qt, neither of which require libXmu or libXt, I don't think forcing both of those into user's memory is appropriate. I have really crappy bandwidth until the 26th so I will not personally mess with things until then; others should feel free to resolve this. - Maciej From owner-scwm-discuss@mit.edu Thu Dec 24 04:29:08 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id EAA12779 for scwm-discuss-outgoing; Thu, 24 Dec 1998 04:29:08 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id EAA12776 for ; Thu, 24 Dec 1998 04:29:05 -0500 Received: from molehill.easystreet.com by MIT.EDU with SMTP id AA14468; Thu, 24 Dec 98 04:28:55 EST Received: (qmail 5737 invoked by uid 501); 24 Dec 1998 09:32:18 -0000 Message-Id: <19981224013217.A27807@molehill.org> Date: Thu, 24 Dec 1998 01:32:17 -0800 From: Todd Larason To: scwm-discuss@mit.edu Subject: Re: build issues References: <199812240759.CAA11422@VICARIOUS-EXISTENCE.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199812240759.CAA11422@VICARIOUS-EXISTENCE.MIT.EDU>; from Maciej Stachowiak on Thu, Dec 24, 1998 at 02:59:10AM -0500 X-Kibo: If you can not be the slave of death, allow it to happen. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981224, Maciej Stachowiak wrote: > Hmm, I just did an nm and libXmu has numerous references to symbols > from libXmu. I assume that second libXmu should be libXt? > It turns out to be only one call to > XmuPrintDefaultErrorMessage() in scwm.c, which according to the docs is Xmu documented anywhere except he X source tree? I can't find anything other than passing mention in either the Digital Press or O'Reilly X series. The official documentation isn't very revealing. UTSL...XmuPrintDefaultErrorMessage gives much more informative error messages than the non-Xmu scwm version. I think this change is what removed the need for X-error-describe. Perhaps XmuPrintDefaultErrorMessaage or a C vresion of the X-error-describe lookup could be brought into scwm itself? If it would be helpful for others, I can make a broken-out XFree86 source tree available via http. -- ICQ UIN: 112488505 From owner-scwm-discuss@mit.edu Thu Dec 24 07:14:47 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id HAA13450 for scwm-discuss-outgoing; Thu, 24 Dec 1998 07:14:47 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id HAA13447 for ; Thu, 24 Dec 1998 07:14:44 -0500 Received: from relay8.Austria.EU.net by MIT.EDU with SMTP id AA23666; Thu, 24 Dec 98 07:14:33 EST Received: (from uucp@localhost) by relay8.Austria.EU.net (8.9.1/8.9.1) with UUCP id NAA03692 for scwm-discuss@mit.edu; Thu, 24 Dec 1998 13:00:11 +0100 (MET) Received: (qmail 7969 invoked by uid 115); 23 Dec 1998 16:18:02 -0000 To: scwm-discuss@mit.edu Subject: Re: How to start scwm with xsm? References: <13946.26831.980923.538637@enterprise.osterwald.de> <199812221441.PAA08457@ull.tnt.uni-hannover.de> X-Attribution: Robbe From: Robert Bihlmeyer Date: 23 Dec 1998 17:17:59 +0100 In-Reply-To: Heiko Muenkel's message of "Tue, 22 Dec 1998 15:41:06 +0100" Message-Id: Lines: 59 User-Agent: Gnus/5.070068 (Pterodactyl Gnus v0.68) XEmacs/20.4 (Emerald) Mime-Version: 1.0 Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, >>>>> On Tue, 22 Dec 1998 15:41:06 +0100 >>>>> Heiko Muenkel said: Heiko> It is readable and writeable for the user. iceauth list shows: [...] Heiko> I don't remember when and why I'd make these entries. Are they Heiko> looking good? Are there any environment variables for iceauth, Heiko> like XAUTHORITY for xauth? The entries look perfectly normal. When you start xsm, it takes a port and named-pipe and checks if XSMP entries for these are contained in "~/.ICEauthority" (the filename can be overridden by setting the environment variable ICEAUTHORITY). If cookies were found, xsm uses these, otherwise it creates new ones and writes them back into the file. Programs/users that have access to your "~/.ICEauthority" automatically read the cookies from there as they connect to the session manager. Obviously, something fails while the session manager initializes the authorization. I'd try a syscall tracer (it's called "strace" under linux, don't know about other platforms) on xsm and see where it fails. Or compile a debug-version of xsm, and check this out with gdb. Ah, I just found the xsm sources lying around and checked what xsm does in detail. Any of these steps failing produces the message you were seeing: * if SM_SAVE_DIR is set, place the following files there; else use HOME if this is set; else use the cwd. * create a file ".xsmXXXXXX" * create a file ".xsmYYYYYY" * generate magic cookies and write iceauth-commands setting them into the XXX file. * write iceauth-commands removing the cookies into the YYY file. * execute "iceauth source .xsmXXXXXX". Perhaps playing with SM_SAVE_DIR helps? Heiko> Are the iceauth and the xauth entries linked in any way? Although the scheme used is pretty much the same, these are distinct. The idea is that even non-X-apps can participate in ICE/SM. Heiko> Do you know of any place, where I can get more information Heiko> about iceauth? The man page is very poor. Not really, but understanding xauth helps, as the concepts are very similar. Robbe -- Robert Bihlmeyer reads: Deutsch, English, MIME, Latin-1, NO SPAM! From owner-scwm-discuss@mit.edu Thu Dec 24 10:56:01 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA14268 for scwm-discuss-outgoing; Thu, 24 Dec 1998 10:56:01 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id KAA14262 for ; Thu, 24 Dec 1998 10:55:55 -0500 Received: from [208.235.77.228] by MIT.EDU with SMTP id AA26096; Thu, 24 Dec 98 10:55:30 EST Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Thu, 24 Dec 1998 10:55:04 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Thu, 24 Dec 1998 10:55:04 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id KAA12357; Thu, 24 Dec 1998 10:55:24 -0500 To: Todd Larason Cc: Maciej Stachowiak Subject: Re: crash on startup References: <19981223163850.B25837@molehill.org> Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold In-Reply-To: Todd Larason's message of "Wed, 23 Dec 1998 16:38:50 -0800" Date: 24 Dec 1998 10:55:24 -0500 Message-Id: Lines: 123 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-scwm-discuss@mit.edu Precedence: bulk >>>> In message <19981223163850.B25837@molehill.org> >>>> On the subject of "Re: crash on startup" >>>> Sent on Wed, 23 Dec 1998 16:38:50 -0800 >>>> Honorable Todd Larason writes: >> On 981223, Sam Steingold wrote: >> > Program received signal SIGSEGV, Segmentation fault. >> > 0x402455bd in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) >> > at iosetvbuf.c:92 >> >> This looks like it's one of the setlinebuf()s in scwm.c, about line 540. >> Unless you're building an internationalized version, extremely little has been >> done at this point - scwm_gh_enter() has done the guile initialiation and >> called scwm_main(), which has switched to the guile module. If you're using a >> recent guile snapshot, *suppress-old-style-hook-warning* has been set to #t. >> And that's it. >> >> Can you verify that's where the setvbuf call is being made? There aren't any >> others in scwm proper, but another library function might be doing it. If >> that's it, can you verify you aren't building with I18N #defined? What >> version of guile are you using? I use guile-1.3-2 guile-devel-1.3-2 and the latest CVS scwm. Current directory is /usr/src/scwm/scwm/ GNU gdb 981029 with Linux/x86 hardware watchpoint and FPU support Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run Starting program: /usr/src/scwm/scwm/scwm [Scwm][CatchRedirectError]: <> another WM is running Program received signal SIGSEGV, Segmentation fault. 0x40249016 in _IO_unbuffer_write () at genops.c:718 718 genops.c: No such file or directory. (gdb) stack Undefined command: "stack". Try "help". (gdb) where #0 0x40249016 in _IO_unbuffer_write () at genops.c:718 #1 0x40249049 in _IO_cleanup () at genops.c:733 #2 0x40214ad9 in exit (status=1) at exit.c:62 #3 0x806f5db in CatchRedirectError () at scwm.c:1314 #4 0x4009c25b in _XError () #5 0x4009aab1 in _XReply () #6 0x400963a1 in XSync () #7 0x806ec8d in scwm_main (argc=1, argv=0xbffffc54) at scwm.c:863 #8 0x40135a13 in gh_call3 () #9 0x40137bae in scm_boot_guile () #10 0x4015b135 in scm_internal_lazy_catch () #11 0x40137b5f in scm_boot_guile () #12 0x40137915 in scm_boot_guile () #13 0x40135a41 in gh_enter () #14 0x806e46f in main (argc=1, argv=0xbffffc54) at scwm.c:465 #15 0x4020c877 in __libc_start_main (main=0x806e45c
, argc=1, argv=0xbffffc54, init=0x8053cc0 <_init>, fini=0x8078c3c <_fini>, rtld_fini=0x4000a710 <_dl_fini>, stack_end=0xbffffc4c) at ../sysdeps/generic/libc-start.c:78 (gdb) run Starting program: /usr/src/scwm/scwm/scwm Program received signal SIGSEGV, Segmentation fault. 0x402449c6 in _IO_fwrite (buf=0x80c8dc8, size=25, count=1, fp=0x401e7d40) at iofwrite.c:44 44 iofwrite.c: No such file or directory. (gdb) where #0 0x402449c6 in _IO_fwrite (buf=0x80c8dc8, size=25, count=1, fp=0x401e7d40) at iofwrite.c:44 #1 0x40131f67 in scm_standard_stream_to_port () #2 0x401349cd in scm_lfwrite () #3 0x401472bd in scm_iprin1 () #4 0x401476e7 in scm_prin1 () #5 0x40147c0a in scm_display () #6 0x4012c912 in scm_deval () #7 0x4012a0aa in scm_eval_3 () #8 0x4012a17b in scm_eval_x () #9 0x805af7d in scwm_body_eval_x (body_data=0xbffff32c) at callbacks.c:204 #10 0x4015b135 in scm_internal_lazy_catch () #11 0x4015b205 in scm_internal_lazy_catch () #12 0x4015af9c in scm_internal_catch () #13 0x4015b248 in scm_internal_stack_catch () #14 0x805afcd in scwm_body_load (body_data=0xbffff464) at callbacks.c:210 #15 0x4015af9c in scm_internal_catch () #16 0x401500dc in scm_internal_cwdr () #17 0x805b0b4 in safe_load (fname=1077336680) at callbacks.c:261 #18 0x4012ce86 in scm_deval () #19 0x4012a0aa in scm_eval_3 () #20 0x4012a17b in scm_eval_x () #21 0x805af7d in scwm_body_eval_x (body_data=0xbffff690) at callbacks.c:204 #22 0x4015b135 in scm_internal_lazy_catch () #23 0x4015b205 in scm_internal_lazy_catch () #24 0x4015af9c in scm_internal_catch () #25 0x4015b248 in scm_internal_stack_catch () #26 0x805b04d in scwm_body_eval_str (body_data=0x807f080) at callbacks.c:210 #27 0x4015af9c in scm_internal_catch () #28 0x401500dc in scm_internal_cwdr () #29 0x805b0ed in scwm_safe_eval_str ( string=0x807f080 "(let ((home-scwmrc (string-append (getenv \"HOME\") \"/\" \".scwmrc\")) (system-scwmrc \"/usr/local/lib/X11/scwm/system.scwmrc\")) (if (access? home-scwmrc R_OK) (safe-load home-scwmrc) (if"...) at callbacks.c:275 #30 0x806ed26 in scwm_main (argc=1, argv=0xbffffc54) at scwm.c:932 #31 0x40135a13 in gh_call3 () #32 0x40137bae in scm_boot_guile () #33 0x4015b135 in scm_internal_lazy_catch () #34 0x40137b5f in scm_boot_guile () #35 0x40137915 in scm_boot_guile () #36 0x40135a41 in gh_enter () #37 0x806e46f in main (argc=1, argv=0xbffffc54) at scwm.c:465 #38 0x4020c877 in __libc_start_main (main=0x806e45c
, argc=1, argv=0xbffffc54, init=0x8053cc0 <_init>, fini=0x8078c3c <_fini>, rtld_fini=0x4000a710 <_dl_fini>, stack_end=0xbffffc4c) at ../sysdeps/generic/libc-start.c:78 (gdb) -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. OK, so you're a Ph.D. Just don't touch anything. From owner-scwm-discuss@mit.edu Thu Dec 24 11:09:25 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id LAA14394 for scwm-discuss-outgoing; Thu, 24 Dec 1998 11:09:25 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id LAA14391 for ; Thu, 24 Dec 1998 11:09:23 -0500 Received: from news.mtu.edu by MIT.EDU with SMTP id AA28041; Thu, 24 Dec 98 11:09:03 EST Received: from mtu.edu (root@mtu.edu [141.219.70.1]) by news.mtu.edu (8.8.8/8.8.8) with ESMTP id LAA29677 for ; Thu, 24 Dec 1998 11:09:07 -0500 (EST) Received: from wiley.sas.it.mtu.edu (wiley.sas.it.mtu.edu [141.219.36.70]) by mtu.edu (8.8.8/8.8.8) with ESMTP id LAA24107 for ; Thu, 24 Dec 1998 11:09:06 -0500 (EST) Received: (from adisaacs@localhost) by wiley.sas.it.mtu.edu (8.8.7/8.8.7/mturelay-1.2) id LAA09885 for scwm-discuss@mit.edu; Thu, 24 Dec 1998 11:09:05 -0500 (EST) Date: Thu, 24 Dec 1998 11:09:05 -0500 From: Andrew Isaacson To: scwm-discuss@mit.edu Subject: Syscall tracers (Was Re: How to start scwm with xsm?) Message-Id: <19981224110905.A9791@mtu.edu> References: <13946.26831.980923.538637@enterprise.osterwald.de> <199812221441.PAA08457@ull.tnt.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Robert Bihlmeyer on Wed, Dec 23, 1998 at 05:17:59PM +0100 X-Pgp-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-Pgp-Key-Url: http://www.csl.mtu.edu/~adisaacs/pgp.txt Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Wed, Dec 23, 1998 at 05:17:59PM +0100, Robert Bihlmeyer wrote: > Obviously, something fails while the session manager initializes the > authorization. I'd try a syscall tracer (it's called "strace" under > linux, don't know about other platforms) I think there's an strace on SunOS as well. Solaris has truss, and {Net,Open,Free?}BSD have ktrace. AIX has something you can run from smit (only if you're root?). -andy -- Andy Isaacson adisaacs@mtu.edu adi@acm.org Fight Spam, join CAUCE: http://www.csl.mtu.edu/~adisaacs/ http://www.cauce.org/ From owner-scwm-discuss@mit.edu Fri Dec 25 02:12:56 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id CAA17702 for scwm-discuss-outgoing; Fri, 25 Dec 1998 02:12:56 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id CAA17699 for ; Fri, 25 Dec 1998 02:12:51 -0500 Received: from mothra.ilogic.com.au by MIT.EDU with SMTP id AA27044; Fri, 25 Dec 98 02:12:29 EST Received: from localhost (dmiller@localhost) by mothra.ilogic.com.au (8.8.7/8.8.7) with ESMTP id SAA18647 for ; Fri, 25 Dec 1998 18:12:49 +1100 Date: Fri, 25 Dec 1998 18:12:47 +1100 (EST) From: Damien Miller To: scwm-discuss@mit.edu Subject: GNOME window manager hints Message-Id: X-Paranoia: just because you're paranoid doesn't mean they aren't out to get you Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-scwm-discuss@mit.edu Precedence: bulk Hi, Does SCWM support the GNOME WM hints? I noticed a little discussion on this a while ago, but it was never followed up. I would love to switch to SCWM, but I really like the GNOME pager/winlist applet. Regards, Damien Miller -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.ilogic.com.au/~dmiller From owner-scwm-discuss@mit.edu Sat Dec 26 02:33:19 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id CAA25105 for scwm-discuss-outgoing; Sat, 26 Dec 1998 02:33:19 -0500 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id CAA25102 for ; Sat, 26 Dec 1998 02:33:16 -0500 Received: from SIMON.CS.CORNELL.EDU by MIT.EDU with SMTP id AA29275; Sat, 26 Dec 98 02:32:37 EST Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.8.8/8.8.8/R-1.11) with ESMTP id CAA13988 for ; Sat, 26 Dec 1998 02:32:42 -0500 (EST) Received: from yodel.cs.cornell.edu (YODEL.CS.CORNELL.EDU [128.84.218.84]) by cloyd.cs.cornell.edu (8.8.8/8.8.8/M-1.12) with ESMTP id CAA18696 for ; Sat, 26 Dec 1998 02:32:40 -0500 (EST) Received: (from eli@localhost) by yodel.cs.cornell.edu (8.8.8/8.8.5/C-1.2) id CAA10350; Sat, 26 Dec 1998 02:32:40 -0500 (EST) X-Authentication-Warning: yodel.cs.cornell.edu: eli set sender to eli@yodel.cs.cornell.edu using -f From: Eli Barzilay Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13956.37143.568692.736603@yodel.cs.cornell.edu> Date: Sat, 26 Dec 1998 02:32:39 -0500 (EST) To: scwm-discuss@mit.edu Subject: build problems (?) X-Mailer: VM 6.63 under Emacs 20.3.1 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I don't remember if anything was said about something like this, but I got this from a recent compilation attempt: lambda ~/guile/scwm eli> ./autogen.sh aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' lambda ~/guile/scwm eli> ./configure --enable-maintainer-mode loading cache ./config.cache ./configure: syntax error near unexpected token `AM_INIT_AUTOMAKE(scwm,' ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' Anything I'm missing? -- Eli Barzilay: Maze is Life! From owner-scwm-discuss@mit.edu Sat Dec 26 19:17:40 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id TAA30217 for scwm-discuss-outgoing; Sat, 26 Dec 1998 19:17:40 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id TAA30214 for ; Sat, 26 Dec 1998 19:17:37 -0500 Received: from ppp6.ltnb.lu by MIT.EDU with SMTP id AA14216; Sat, 26 Dec 98 19:16:57 EST Received: (from bob@localhost) by iceberg.localnet (8.9.1a/8.9.1) id BAA03577 for scwm-discuss@mit.edu; Sun, 27 Dec 1998 01:18:24 +0100 (CET) From: Bob Pepin Date: Sun, 27 Dec 1998 01:18:22 +0100 To: scwm-discuss@mit.edu Subject: Re: build problems (?) Message-Id: <19981227011822.A15355@iceberg.localnet> References: <13956.37143.568692.736603@yodel.cs.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <13956.37143.568692.736603@yodel.cs.cornell.edu>; from Eli Barzilay on Sat, Dec 26, 1998 at 02:32:39AM -0500 Sender: owner-scwm-discuss@mit.edu Precedence: bulk On Sat, Dec 26, 1998 at 02:32:39AM -0500, Eli Barzilay wrote: > I don't remember if anything was said about something like this, but I > got this from a recent compilation attempt: > lambda ~/guile/scwm eli> ./autogen.sh > aclocal: ./gtk.m4: 7: duplicated macro `AM_PATH_GTK' > lambda ~/guile/scwm eli> ./configure --enable-maintainer-mode > loading cache ./config.cache > ./configure: syntax error near unexpected token > `AM_INIT_AUTOMAKE(scwm,' > ./configure: ./configure: line 551: `AM_INIT_AUTOMAKE(scwm, 0.9beta1)' > > Anything I'm missing? don't know, works fine here if I delete gtk.m4... (using OpenBSD 2.4, automake 1.3, autoconf 2.12 ) -- sell me shitty software once, shame on you. sell me shitty software twice, shame on me. From owner-scwm-discuss@mit.edu Mon Dec 28 17:04:27 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA16443 for scwm-discuss-outgoing; Mon, 28 Dec 1998 17:04:27 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from mail.eaglets.com ([208.235.77.228]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id RAA16440 for ; Mon, 28 Dec 1998 17:04:25 -0500 Received: by mail.eaglets.com from localhost (router,SLMail V3.1); Mon, 28 Dec 1998 17:01:52 -0500 Received: by mail.eaglets.com from eho.eaglets.com [208.235.77.238] (SLmail 3.1.2948 (Release Build)); Mon, 28 Dec 1998 17:01:52 -0500 Received: (from sds@localhost) by eho.eaglets.com (8.9.1a/8.9.1) id RAA28372; Mon, 28 Dec 1998 17:02:36 -0500 To: Maciej Stachowiak Subject: crash in _IO_setvbuf() Reply-To: sds@goems.com X-Disclaimer: You should not expect anyone to agree with me. X-Attribution: Sam X-No-Archive: Yes Mail-Copies-To: never From: Sam Steingold Date: 28 Dec 1998 17:02:35 -0500 Message-ID: Lines: 30 Sender: owner-scwm-discuss@mit.edu Precedence: bulk I am still getting this crash, no matter what arguments I give scwm. (gdb) run -d 0:0 Starting program: /usr/src/scwm/scwm/scwm -d 0:0 Program received signal SIGSEGV, Segmentation fault. 0x4024556d in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) at iosetvbuf.c:92 92 iosetvbuf.c: No such file or directory. (gdb) where #0 0x4024556d in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) at iosetvbuf.c:92 #1 0x40131584 in scm_setbuf0 () #2 0x40131bb0 in scm_stdio_to_port () #3 0x40131c14 in scm_standard_stream_to_port () #4 0x401377ea in scm_init_hashtab () #5 0x40137ad9 in scm_boot_guile () #6 0x40137915 in scm_boot_guile () #7 0x40135a41 in gh_enter () #8 0x806e76f in main (argc=3, argv=0xbffffc34) at scwm.c:465 #9 0x4020c827 in __libc_start_main (main=0x806e75c
, argc=3, argv=0xbffffc34, init=0x8053d80 <_init>, fini=0x8078f3c <_fini>, rtld_fini=0x4000a710 <_dl_fini>, stack_end=0xbffffc2c) at ../sysdeps/generic/libc-start.c:78 -- Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A professor is someone who talks in someone else's sleep. From owner-scwm-discuss@mit.edu Mon Dec 28 17:27:41 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id RAA26588 for scwm-discuss-outgoing; Mon, 28 Dec 1998 17:27:41 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id RAA26584 for ; Mon, 28 Dec 1998 17:27:38 -0500 Received: from molehill.easystreet.com by MIT.EDU with SMTP id AA22834; Mon, 28 Dec 98 17:26:26 EST Received: (qmail 1662 invoked by uid 501); 28 Dec 1998 22:27:58 -0000 Message-Id: <19981228142758.A1627@molehill.org> Date: Mon, 28 Dec 1998 14:27:58 -0800 From: Todd Larason To: sds@goems.com Cc: scwm-discuss list Subject: Re: crash in _IO_setvbuf() References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Sam Steingold on Mon, Dec 28, 1998 at 05:02:35PM -0500 X-Kibo: Kibology seems confusing to me! Sender: owner-scwm-discuss@mit.edu Precedence: bulk I haven't been able to reproduce this, and it looks from the stack like it's a guile bug. You said you were using guile 1.3-2? Is that a prepackaged RPM or .deb, and if so, where can I find it? Any recent changes to your C library? This is a stock Redhat 5.2 system, like your .sig implies? On 981228, Sam Steingold wrote: > I am still getting this crash, no matter what arguments I give scwm. > > (gdb) run -d 0:0 > Starting program: /usr/src/scwm/scwm/scwm -d 0:0 > > Program received signal SIGSEGV, Segmentation fault. > 0x4024556d in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) > at iosetvbuf.c:92 > 92 iosetvbuf.c: No such file or directory. > (gdb) where > #0 0x4024556d in _IO_setvbuf (fp=0x401e7cc0, buf=0x0, mode=2, size=0) > at iosetvbuf.c:92 > #1 0x40131584 in scm_setbuf0 () > #2 0x40131bb0 in scm_stdio_to_port () > #3 0x40131c14 in scm_standard_stream_to_port () > #4 0x401377ea in scm_init_hashtab () > #5 0x40137ad9 in scm_boot_guile () > #6 0x40137915 in scm_boot_guile () > #7 0x40135a41 in gh_enter () > #8 0x806e76f in main (argc=3, argv=0xbffffc34) at scwm.c:465 > #9 0x4020c827 in __libc_start_main (main=0x806e75c
, argc=3, > argv=0xbffffc34, init=0x8053d80 <_init>, fini=0x8078f3c <_fini>, > rtld_fini=0x4000a710 <_dl_fini>, stack_end=0xbffffc2c) > at ../sysdeps/generic/libc-start.c:78 > > -- > Sam Steingold (http://www.goems.com/~sds) running RedHat5.2 GNU/Linux > Micros**t is not the answer. Micros**t is a question, and the answer is Linux, > (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. > A professor is someone who talks in someone else's sleep. -- ICQ UIN: 121405108 From owner-scwm-discuss@mit.edu Mon Dec 28 18:29:46 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id SAA28965 for scwm-discuss-outgoing; Mon, 28 Dec 1998 18:29:46 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id SAA28962 for ; Tue, 29 Dec 1998 04:45:34 -0500 Received: from mgate2.uni-hannover.de by MIT.EDU with SMTP id AA13035; Tue, 29 Dec 98 04:45:38 EST Received: from helios.tnt.uni-hannover.de by mgate2.uni-hannover.de with LocalSMTP (PP) with ESMTP; Tue, 29 Dec 1998 10:45:09 +0100 Received: from enterprise.osterwald.de (root@h49.ts1.uni-hannover.de [130.75.249.49]) by helios.tnt.uni-hannover.de (8.8.8/8.8.8) with ESMTP id KAA00614; Tue, 29 Dec 1998 10:45:08 +0100 (MET) Received: (from muenkel@localhost) by enterprise.osterwald.de (8.8.8/8.8.8) id XAA00727; Mon, 28 Dec 1998 23:04:41 +0100 From: Heiko Muenkel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <13960.120.882223.884224@enterprise.osterwald.de> Date: Mon, 28 Dec 1998 23:04:40 +0100 (MET) To: Robert Bihlmeyer Cc: scwm-discuss@mit.edu Subject: Re: How to start scwm with xsm? In-Reply-To: References: <13946.26831.980923.538637@enterprise.osterwald.de> <199812221441.PAA08457@ull.tnt.uni-hannover.de> X-Mailer: VM 6.62 under 21.0 "Poitou60" XEmacs Lucid (beta60) X-Face: n}R'l6CHRf>pi&bj7[x0CW3:kmXm@1)7m+l*9[fp;-Ow4Xe~=5E;skf?2>y]f{HzB|Q (\V9 +y$PP~.4G[2n4W7{6Ilm[AMY9B:0kj.K_$-d%p4YIF*bX;=ADp6{HS@NEv9c.VII+9PgXHASx}K(jy ^t=q%qzZ72q1e4E;O!$A$`&wgtLk"1%p.nC_G!]4d1!+J4Q#YD_iXeEy`1x)d\r$1Qn\'23n|[8Y_x zuXJJ7W(EGqnzB]`]aq??;+z=)DW~\'Vq&F'g%QU[Mv2:}nS>SdZFTEC2GsgB=Q,:~H>>>> "Robert" == Robert Bihlmeyer writes: > Perhaps playing with SM_SAVE_DIR helps? Thank you very much for this hint. I don't know why, but this variable was set to /home/muenkel/.xsm, a directory which didn't exist. I'm able to start xsm since I've created the directory. I wish you and the rest of this list a happy new year, Heiko From owner-scwm-discuss@mit.edu Wed Dec 30 21:49:27 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id VAA13090 for scwm-discuss-outgoing; Wed, 30 Dec 1998 21:49:27 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from kodis.jagunet.com (kodis.jaguNET.com [206.156.208.48]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with ESMTP id VAA13087 for ; Wed, 30 Dec 1998 21:49:22 -0500 Received: (from kodis@localhost) by kodis.jagunet.com (8.8.7/8.8.7) id VAA02457 for scwm-discuss@vicarious-existence.mit.edu; Wed, 30 Dec 1998 21:49:20 -0500 Date: Wed, 30 Dec 1998 21:49:19 -0500 From: John Kodis To: scwm-discuss@mit.edu Subject: SCWM Build failure Message-ID: <19981230214919.A2409@kodis.jagunet.com> Reply-To: kodis@jagunet.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-scwm-discuss@mit.edu Precedence: bulk When trying to build scwm-0.8a on a fairly standard Linux box, configure errored out with: checking for scm_handle_by_message_noexit in -lguile... no configure: error: Can not find Guile 1.2 or later on the system However, guile 1.3 is installed: scwm-0.8a$ guile --version Guile 1.3 Copyright (c) 1995, 1996, 1997 Free Software Foundation The config.log reveals that the problem seems to be caused by unresolved readline symbols referenced by libguile. configure:3255: checking for scm_handle_by_message_noexit in -lguile configure:3274: gcc -o conftest -g -O2 conftest.c -lguile -L/usr/local/lib -ldl -lm -lm 1>&5 /usr/local/lib/libguile.so: undefined reference to `rl_deprep_term_function' Before I start hacking up the configure script to work around this, I thought I'd ask: Is there a clean fix available for this problem, or will I just run into trouble later on if I hack around this problem? -- John Kodis. From owner-scwm-discuss@mit.edu Thu Dec 31 10:24:31 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA17188 for scwm-discuss-outgoing; Thu, 31 Dec 1998 10:24:31 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: (from mstachow@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id KAA17181; Thu, 31 Dec 1998 10:24:23 -0500 Message-Id: <199812311524.KAA17181@VICARIOUS-EXISTENCE.MIT.EDU> To: kodis@jagunet.com cc: scwm-discuss@mit.edu SuFrom owner-scwm-discuss@mit.edu Thu Dec 31 13:33:13 1998 Received: (from mjrdmo@localhost) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) id NAA27700 for scwm-discuss-outgoing; Thu, 31 Dec 1998 13:33:13 -0500 X-Authentication-Warning: VICARIOUS-EXISTENCE.MIT.EDU: mjrdmo set sender to owner-scwm-discuss@vicarious-existence.mit.edu using -f Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by VICARIOUS-EXISTENCE.MIT.EDU (8.8.5/8.8.5) with SMTP id NAA27697 for ; Thu, 31 Dec 1998 13:33:08 -0500 Received: from molehill.easystreet.com by MIT.EDU with SMTP id AA22177; Thu, 31 Dec 98 13:32:58 EST Received: (qmail 26668 invoked by uid 501); 31 Dec 1998 18:33:55 -0000 Message-Id: <19981231103355.A26616@molehill.org> Date: Thu, 31 Dec 1998 10:33:55 -0800 From: Todd Larason To: kodis@jagunet.com, scwm-discuss@mit.edu Subject: Re: SCWM Build failure References: <19981230214919.A2409@kodis.jagunet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19981230214919.A2409@kodis.jagunet.com>; from John Kodis on Wed, Dec 30, 1998 at 09:49:19PM -0500 X-Kibo: Let's stay in our world! True or False? You be the judge!. Sender: owner-scwm-discuss@mit.edu Precedence: bulk On 981230, John Kodis wrote: > configure:3255: checking for scm_handle_by_message_noexit in -lguile > configure:3274: gcc -o conftest -g -O2 conftest.c -lguile > -L/usr/local/lib -ldl -lm -lm 1>&5 > /usr/local/lib/libguile.so: undefined reference to `rl_deprep_term_function' That's a libreadline symbol that's missing. If readline is needed by your guile, 'guile-config link' should list -lreadline. If you're missing guile-config or if it doesn't give the proper answers, that's the problem. Are you perhaps using the Redhat RawHide guile-1.3-1 RPM? -- ICQ UIN: 40518852