scwm-devs — For developer discussions regarding the Scheme Constraints Window Manager

Re: [Scwm-devs] 2nd notification

[Morgan <in...@sh...>]

 I sent you a notification,did you get it?
 Chris Morgan
 
 

[Scwm-devs] Read: Mold LB-0148-0029923 / Tue Aug

[UFDQuNXIiP_Billie <lb3...@16...>]

Unsubscrible from email.Click here.  

[Scwm-devs] !!!! Greetings !!!!

[kong k. <kon...@ou...>]

Hello,
I am Barr Kong Khemara, I humbly ask if you are related to my client who died couple of
years ago in a car accident here in my country Cambodia. I wish to also inquire if
it is possible to have different families with the same last name as yours by coincidence
who do not share the same common roots? Kindly get back to me if your email is still
Valid to enable me give you the details of my message or make headway in my search.
Regards,
Kong Khemara

[Scwm-devs] Patch scwm.texi

[Mark M. <of...@gm...>]

Hi,
I tried to build scwm, but the build fails on my system. Please see the
attached patch.

Regards, Mark

[Scwm-devs] Website Designing and Development

[Narender <and...@re...>]

Hi

Hope you are doing Well

I am a Business Development Manager working with a reputed 
Web Designing and Development Company in INDIA.

Idea + Discussion + Design and Development, YES, It is so easy to
have a website for your professional or personal use, we are the 
experience people into this industry from last so many years and 
we can understand your requirements in few simple questions.

We custom the websites according to the nature of the business, 
we have develop number of websites so far, we offer different 
packages for Small Business, Corporate, Personal, or eCommerce 
websites, please check some basic package to start with a new 
website :

10 Pages website :US $ 300
15 Pages website :US $ 325
20 Pages website :US $ 350
25 Pages website :US $ 375

Let me know if you would like to have more information, 
then we will email you more details or schedule a call with you. 
You can also join us on 

SKYPE : websitedesign6.

We wish to work together, We assure you the best quality and 
attention all the time.

I look forward to your Mail.

Warm Regards

Andy

Business Development Manager
Email :and...@re...
Skype :websitedesign6
Click this link to unsubscribe:
http://123nemail.com/unsubscribe.php?M=24041&C=a1d906eb01120aef032e8061353baf4b&L=5&N=10

Re: [Scwm-devs] panel for scwm

[Dale S. <ds...@us...>]

On Thu, Jan 17, 2013 at 6:41 AM, Jasmin Rahimic <jas...@gm...> wrote:
> I think build it panel in scwm is must have feature. It should be simple
> and something like emacs mode-line.

Not sure if you know, but scwm was supposed to continue to work with
all fvwm "plugins" or "modules" (I forget what they are called).
There might already be a panel like you want.

I'm sure that has bitrotted by now though.

-Dale

[Scwm-devs] panel for scwm

[Jasmin R. <jas...@gm...>]

I think build it panel in scwm is must have feature. It should be simple
and something like emacs mode-line.

[Scwm-devs] [PATCH] Improve tiling in scwm

[Jasmin R. <jas...@gm...>]

Here is my patch. I hope I send it to right address.

Changes from upstream-master to origin-master
	Modified   scheme/tile.scm
diff --git a/scheme/tile.scm b/scheme/tile.scm
index 29b6be8..1a9b2c1 100644
--- a/scheme/tile.scm
+++ b/scheme/tile.scm
@@ -1,23 +1,25 @@
-;;;; $Id$
-;;;; Copyright (C) 1998-1999 Maciej Stachowiak
-;;;; 
-;;;; 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.  If not, write to
-;;;; the Free Software Foundation, Inc., 59 Temple Place, Suite 330,
-;;;; Boston, MA 02111-1307 USA
-;;;; 
-
-
+;;; tile.scm --- 
+;; 
+;; Description: tiling for scwm
+;; Author: 
+;; URL: 
+;; Keywords: 
+;; Commentary: 
+;;  
+;; 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 3, 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 program; see the file COPYING.  If not, write to
+;; the Free Software Foundation, Inc., 51 Franklin Street, Fifth
+;; Floor, Boston, MA 02110-1301, USA.
 
 (define-module (app scwm tile)
   :use-module (app scwm optargs)
@@ -37,7 +39,8 @@
 
 (define*-public (tile-windows
 		 windows #:key (start-pos '(0 0)) 
-		 (end-pos (display-size)) (resize 'always)
+		 (end-pos (display-size))
+		 (resize 'always)
 		 (raise 'restack-only)
 		 (max-windows #f)
 		 (order 'horizontal))
@@ -49,8 +52,9 @@ default, to END-POS, the size of the display by default.
 If MAX-WINDOWS is specified and not #f, at most MAX-WINDOWS elements
 of WINDOWS will be operated on.
 
-If ORDER is 'horizontal, the windows will be tiled in row-major order;
-if it is 'vertical they will be tiled in column-major oder.
+If ORDER is 'horizontal, the windows will be tiled in row order;
+if it is 'vertical they will be tiled in column oder, if ORDER
+is 'mixed it will be tiled as matrix. The default is 'mixed.
 
 RESIZE may be #f, 'shrink-only or 'always, indicating that the windows
 should never be resized, that they should be resized to the max-size
@@ -63,78 +67,82 @@ on top of other windows and placed in the tile order with the upper
 left window lowest in the stacking order; or that they should be
 restacked as for #t but not raised above other windows,
 respectively. The default is 'restack-only."
-    (let* ((num-windows (if max-windows
-			    (min (length windows) max-windows)
-			    (length windows)))
-	   (windows (list-head windows num-windows)))
-      (cond 
-       ((not (null? windows))
-	(cond
-	 (raise (if (not (eq? raise 'restack-only))
-		    (raise-window (car (reverse windows))))
-		(restack-windows (reverse windows))))
-	(let* ((num-major (inexact->exact (ceiling (sqrt num-windows))))
-	       (num-minor (inexact->exact (ceiling (/ num-windows num-major))))
-	       (num-per-row (case order
-			      ((horizontal) num-major)
-			      ((vertical) num-minor)))
-	       (num-per-column (case order
-				 ((horizontal) num-minor)
-				 ((vertical) num-major)))
-	       (start-x (car start-pos))
-	       (start-y (cadr start-pos))
-	       (range-x (- (car end-pos) start-x))
-	       (range-y (- (cadr end-pos) start-y)))
-	  (let loop ((windows (list-head windows num-windows))
-		     (row 0)
-		     (column 0)
-		     (cur-x start-x)
-		     (cur-y start-y)
-		     (next-x (integer-step start-x range-x num-per-row 1))
-		     (next-y (integer-step start-y range-y num-per-column 1)))
-	    (cond
-	     ((not (null? windows))
-	      (let* ((win (car windows))
-		     (fs (window-frame-size win))
-		     (new-size (case resize
-				 ((always) (list (- next-x cur-x) (- next-y cur-y)))
-				 ((shrink-only)
-				  (list (min (car fs) (- next-x cur-x))
-					(min (cadr fs) (- next-y cur-y))))
+  (let* ((num-windows (if max-windows
+			  (min (length windows) max-windows)
+			  (length windows)))
+	 (windows (list-head windows num-windows)))
+    (cond 
+     ((not (null? windows))
+      (cond
+       (raise (if (not (eq? raise 'restack-only))
+		  (raise-window (car (reverse windows))))
+	      (restack-windows (reverse windows))))
+      (let* ((num-major (inexact->exact (ceiling (sqrt num-windows))))
+	     (num-minor (inexact->exact (ceiling (/ num-windows num-major))))
+	     (num-per-row (case order
+			    ((horizontal) (if max-windows max-windows num-windows))
+			    ((vertical) 1)
+			    ((mixed) num-major)))
+	     (num-per-column (case order
+			       ((horizontal) 1)
+			       ((vertical) (if max-windows max-windows num-windows))
+			       ((mixed) num-minor)))
+	     (start-x (car start-pos))
+	     (start-y (cadr start-pos))
+	     (range-x (- (car end-pos) start-x))
+	     (range-y (- (cadr end-pos) start-y)))
+	(let loop ((windows (list-head windows num-windows))
+		   (row 0)
+		   (column 0)
+		   (cur-x start-x)
+		   (cur-y start-y)
+		   (next-x (integer-step start-x range-x num-per-column 1))
+		   (next-y (integer-step start-y range-y num-per-row 1)))
+	  (cond
+	   ((not (null? windows))
+	    (let* ((win (car windows))
+		   (fs (window-frame-size win))
+		   (new-size (case resize
+			       ((always) (list (- next-x cur-x) (- next-y cur-y)))
+			       ((shrink-only)
+				(list (min (car fs) (- next-x cur-x))
+				      (min (cadr fs) (- next-y cur-y))))
 			   ;;; MS:FIXME:: check for bad values
-				 (else fs))))
-		(if (not (equal? new-size fs))
-		    (resize-frame (car new-size) (cadr new-size) win))
-		(move-window cur-x cur-y win))
-	      (cond
-	       ((and (eq? order 'horizontal) (= column (- num-per-row 1)))
-		(loop (cdr windows) (+ row 1) 0 start-x next-y
-		      (integer-step start-x range-x num-per-row 1)
-		      (integer-step start-y range-y num-per-column (+ row 2))))
-	       ((eq? order 'horizontal)
-		(loop (cdr windows) row (+ column 1) next-x cur-y 
-		      (integer-step start-x range-x num-per-row (+ column 2))
-		      next-y))
-	       ((and (eq? order 'vertical) (= row (- num-per-column 1)))
-		(loop (cdr windows) 0 (+ column 1) next-x start-y
-		      (integer-step start-x range-x num-per-row (+ column 2))
-		      (integer-step start-y range-y num-per-column 1)))
-	       ((eq? order 'vertical)
-		(loop (cdr windows) (+ row 1) column cur-x next-y
-		      next-x
-		      (integer-step start-y range-y num-per-column 
-				    (+ row 2)))))))))))))    
-			  
+			       (else fs))))
+	      (if (not (equal? new-size fs))
+		  (resize-frame (car new-size) (cadr new-size) win))
+	      (move-window cur-x cur-y win))
+	    (cond
+	     ((and (eq? order 'mixed) (= column (- num-per-row 1)))
+	      (loop (cdr windows) (+ row 1) 0 start-x next-y
+		    (integer-step start-x range-x num-per-row 1)
+		    (integer-step start-y range-y num-per-column (+ row 2))))
+
+	     ((eq? order 'mixed)
+	      (loop (cdr windows) row (+ column 1) next-x cur-y 
+		    (integer-step start-x range-x num-per-row (+ column 2))
+		    next-y))
+
+	     ((eq? order 'vertical)
+	      (loop (cdr windows) row (+ column 1) next-x cur-y 
+		    (integer-step start-x range-x num-per-column (+ column 2))
+		    next-y))
+
+	     ((eq? order 'horizontal)
+	      (loop (cdr windows) (+ row 1) column cur-x next-y
+		    next-x
+		    (integer-step start-y range-y num-per-row (+ row 2)))))))))))))
+
 (define*-public (tile #:key (only '()) (except '()) 
-			 (by-stacking #f) (by-focus #f)
-			 (reverse #f)
-			 (all-viewports #f) (desk (current-desk))
-			 (ignore-default-exceptions #f)
-			 (start-pos '(0 0)) 
-			 (end-pos (display-size)) (resize 'always)
-			 (raise 'restack-only)
-			 (max-windows #f)
-			 (order 'horizontal))
+		      (by-stacking #f) (by-focus #f)
+		      (reverse #f)
+		      (all-viewports #f) (desk (current-desk))
+		      (ignore-default-exceptions #f)
+		      (start-pos '(0 0)) 
+		      (end-pos (display-size)) (resize 'always)
+		      (raise 'restack-only)
+		      (max-windows #f)
+		      (order 'mixed))
   "Tile the windows on the specified desk.
 The DESK option, defaulting to the current desk, specifies which desk;
 ALL-VIEWPORTS, when true indicates that the windows in all viewports
@@ -165,26 +173,3 @@ control the tiling options as for `tile-windows'."
     #:by-stacking by-stacking #:by-focus by-focus #:reverse reverse)
    #:start-pos start-pos #:end-pos end-pos #:raise raise 
    #:resize resize #:max-windows max-windows #:order order))
-
-
-(define*-public (tile-windows-interactively #:optional (order 'horizontal))
-  "Tile a set of selected windows either vertically or horizontally.
-ORDER can be either 'horizontal or 'vertical.
-The windows used are selected either by `selected-windows-list' or 
-`select-window-group'.
-If `selected-windows-list' is empty, then `select-window-group' is used.
-See also the undo module and `push-undo-global' to save the window 
-configuration before executing this in case the effect is not what you
-expected."
-  (interactive)
-  (let* ((winlist (reverse (selected-windows-list)))
-	 (wins (if (pair? winlist) winlist (select-window-group)))
-	 (r (enclosing-rectangle wins)))
-    (if (pair? winlist)
-	(unselect-all-windows)
-	(for-each unflash-window wins))
-    (push-undo-global)
-    (tile-windows wins
-		  #:start-pos (rect-nw r)
-		  #:end-pos (rect-se r)
-		  #:order order)))
	Modified   scheme/wininfo.scm
diff --git a/scheme/wininfo.scm b/scheme/wininfo.scm
index 6594c3f..301fe41 100644
--- a/scheme/wininfo.scm
+++ b/scheme/wininfo.scm
@@ -27,6 +27,7 @@
   :use-module (app scwm minimal)
   :use-module (ice-9 regex)
   :export (on-desk?
+	   on-desk-n?
            on-current-desk?
            in-viewport-any-desk?
            visible?
@@ -47,7 +48,7 @@
   "Return #t if WIN is on desk N, else #f."
   (if win (= n (window-desk win))))
 
-(define*-public ((on-desk-n? n) #:optional (win (get-window)))
+(define* ((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))
 

Re: [Scwm-devs] Still being developed? Can I help?

[Dale S. <dal...@gm...>]

On 4/20/07, ks...@st...
<ks...@st...> wrote:
> Hello everyone,
> I've just discovered scwm, and I really like how I can use GUILE to customize
> it, because I really like Scheme ;). I see that it's been updated for GUILE 1.8,
> but that was over a year ago, and the latest changes in CVS are from 4 months ago.
>
> Is Scwm still being actively developed? Or better yet, would that stop me from
> using it in any way? Is there anything I could contribute to help?

Yes it is being actively developed, for a certain definition of "actively". ;^)

It's had some severe bitrot, but it's slowing coming alive again.
I've had some hardware issues with my main development machine at
home, so things have stalled somewhat.

How can you help?  Use it.  Find problems and submit bug reports
(hopefully with patches!). Come up with new cool things that are just
impossible with any other window manager.

Check out #guile or #scwm on freenode if you want to chat.

-Dale

[Scwm-devs] Still being developed? Can I help?

[<ks...@st...>]

Hello everyone,
I've just discovered scwm, and I really like how I can use GUILE to customize
it, because I really like Scheme ;). I see that it's been updated for GUILE 1.8,
but that was over a year ago, and the latest changes in CVS are from 4 months ago.

Is Scwm still being actively developed? Or better yet, would that stop me from
using it in any way? Is there anything I could contribute to help?

Thanks!

[Scwm-devs] scwm and Guile 1.8!

[Dale S. <ds...@us...>]

Howdy Scwmers,

Well, at long last it's started to happen.  Last week I did a massive
checkin to cvs that brings scwm mostly up to date with the recently
released Guile 1.8.0.  The code compiles cleanly and runs the
simple.scwmrc file.  There are still some auto* tool issues and I
haven't even begun looking at installation, but I thought give people
some indication that the bitrot is being purged.

Unfortunately, sourceforge is currently having some issues with anon
cvs, and with that the web cvs interface.

-Dale

[Scwm-devs] Fwd: Re: problem becouse scm_tc7_contin is not defined

[P P. <pie...@pl...>]

----------  Forwarded Message  ----------

Subject: Re: problem becouse scm_tc7_contin is not defined
Date: 09 Sep 2002 20:43:12 +0200
From: Marius Vollmer <mv...@za...>
To: P Pareit <pie...@pl...>
Cc: gui...@gn...

P Pareit <pie...@pl...> writes:
> By doing a grep on scm_tc7_contin in the source tree of guile I
> found out that scm_tc7_contin is no longer supported and I have to
> use SMOB continuation for rootcont instead.

Scwm is digging into the innards of Guile, and we don't really support
code like scm_internal_cwdr_no_unwind.  Scm_internal_cwdr_no_unwind is
essentially a copy of Guile's scm_internal_cwdr with some bits
removed.  There is a reason why it is called scm_*internal*_cwdr. ;-)

However, scwm has probably a real need for
scm_internal_cwdr_no_unwind, and we do want to support something like
it officially in the future so that scwm does not need to provide its
own hack.

You might consider fixing scwm's hack like this

  SCM
  scm_internal_cwdr_no_unwind (scm_catch_body_t body, void *body_data,
                               scm_catch_handler_t handler, void
 *handler_data, SCM_STACKITEM *stack_start)
  {
    SCM answer, old_winds;
    old_winds =3D scm_dynwinds;
    scm_dynwinds =3D SCM_EOL;

    answer =3D scm_internal_cwdr (body, body_data, handler, handler_data,
                                stack_stack);

    scm_dynwinds =3D old_winds;
    return answer;
  }

This will _only_ work when HANDLER does not do a non-local exit (via
longjmp, or similar).  If you want to support that (which I
recommend), you need to defer running HANDLER (with the same trick
that scm_internal_cwdr uses) until scm_dynwinds has been restored.

The above code should be more resilient against changes to the
internals of Guile, but it is still a hack.  We have a proposal to fix
this for real.  See workbook/extension/dynamic-roots.text in CVS.

You might also try to just scm_internal_cwdr instead of
scm_internal_cwdr_no_unwind.  That should work as well, but at a
slight performance loss.

Could you bring this up with the scwm developers so that we might find
a solution that makes everyone happy?

--
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405

-------------------------------------------------------

[Scwm-devs] scwm and guile 1.6.*

[P P. <pie...@pl...>]

Hey,

Guile 1.6.0 has been released,
Yesterday I started compiling scwm from cvs with guile-1.6.0 installed on=
 my=20
system (Mandrake 9.0 with gcc 3.2 and gtk 2.0).
The main problem is with the function scm_internal_cwdr_no_unwind in the =
file=20
guile-compat.c. I will forward a discusion I had with the guile developer=
s so=20
you can see there opinion.
With the code changes proposed at guile-dev I was able to compile that co=
de=20
but I get a segment fault at scwm startup with a backtrace to that functi=
on=20
so that still has to be fixed.
Other changes (small) I had to do where in the following files:
scwm/src/callbacks.c
scwm/src/guile-compat.h
scwm/src/guile-compat.c
scwm/modules/esdsound/sound.c
scwm/modules/scwmgtkhelper/scwmgtkhelper.c
Will cvs start to use guile-1.6.0?

I also had to change the Makefiles to not to use guile-doc-snarf but=20
guile-snarf instead.

pieter;

[Scwm-devs] Compiling scwm(cvs) on my laptop

[P P. <pie...@pl...>]

On my laptop I have a RH7.3 system, today I compiled scwm on, here are my=
=20
experices:
All of the things I compiled I used --prefix=3D/usr

Redhat 7.3 still contains the old guile, so I installed guile 1.4.1from=20
sources.
When I started compiling scwm it errored becuze it could not find the com=
mand=20
guile-doc-snarf, looking into /usr/bin there was an guile-snarf. Looking =
into=20
the archive of scwm there were some comment on using guile-snarf instread=
 of=20
guile-doc-snarf. I made a symbolic link for guile-snarf to guile-doc-snar=
f.=20
It might be better to change the Makefile's, but as they are created by=20
autogen.sh, I have no idea what to do best.
During reading of the Makefile's I noticed a problem on line 238 in=20
scwm/src/Makefile.
In file scwm/utilities/scwmrepl/Makefile I removed -DHAVE_CONFIG_H around=
 line=20
152, otherwise I could not compile scwmrepl.c as it confused the header=20
<readline/readline.h> it was including.
After that compilation was ok, and I'm now able to run scwm.
BTW: I do not have the input problem in mozilla on my laptop, but I still=
 have=20
it on my desktop, as my desktop runs an beta mandrake I'll wait till the=20
release is out before giving scwm on my desktop an other try (don't worry=
 I=20
use my laptop more than my desktop).
I hope this information is usable to make some changes so installation wo=
rks=20
better, I will afcourse help when needed.
pieter;

[Scwm-devs] on backward compatibility in Scwm

[P P. <pie...@pl...>]

> How important do you think backward compatibility is in Scwm?  There
> are a lot of changes that should be made to clean up the code base
> to enable easier addition of changes.  A lot of these changes would
> result in backward compatibility issues.  I see roughly three ways
> to handle this:
>
> 1. Don't make the changes
> 2. Make the changes in a way such that the changes are backwards compat=
ible
>    for one(or more) release(s)
> 3. Make the changes and damn the consequences
>=20
> Option 1, leaves us with a difficult to understand, inconsistent, and
> large code base.  I don't think this is tenable in the long term.
> Option 2 requires a bunch of extra work to keep things
> backwards compatible along with extra code to report deprecated feature=
s
> and offer new ways to do things.  Option 3 is the easiest coding wise
> but the hardest from a user perspective.  I think option 2 with backwar=
d
> compatibility maintained for a single release is probably the best opti=
on,
> but option 3 would be more convenient.
>=20

I'll say go for option 3. Documenting the things that where changed and t=
he=20
way things are done now. That way the code can be changed and the wm is s=
till=20
usable.

> The different directions the code can be taken need some high level
> decisions to be make on which way to take the code.  I feel funny
> making these decisions since I haven't put nearly as much effort into
> the code as Greg has.  Nonetheless, some decisions need to be made.
> Do we clean up the code before we release 1.0?  What's our policy on
> version numbers?  What's our policy on backwards compatibility?
> When are acceptable times to put in an event or decoration rewrite?
> Do these need to be post 1.0?  What is expected of a 1.0 release?
> Working code?  Most code working?  No known bugs?  Stable API?  Should
> the poor method names be renamed?  When?  Maintaining backward
> compatibility?  For how long?  How should methods be named?  I think th=
e
> most important issue here is what are the expectations for version 1.0?
> If 1.0 is to be very stable, new features shouldn't go in right before
> it and the code should be changed little before hand.  If 1.0 is meant=20
> to have a very stable API, methods should be renamed and planned featur=
es
> added beforehand.  If 1.0 is just another version, then this stuff does=
n't
> matter so much.  We've sort of built up expectations of 1.0 a bit by
> having all of these 0.99.* releases, but there don't seem to be any
> concrete guidelines of what constitutes 1.0.  I would be inclined to
> make 1.0 more like just another release with the major subsystems teste=
d.
> The window manager is already obviously usable so I think somewhere alo=
ng
> the line it probably already should have been called 1.0.  It almost se=
ems
> like we are reserving 1.0 for when we feel it is "done", whatever that
> means.  If 1.0 is just like another release, this implies:
>=20
> - no special requirements need to be met for the next release to be
>   called 1.0
> - not everything needs to be tested before 1.0
> - not everything needs to be documented before 1.0
> - the documentation for 1.0 doesn't need to be fancy
>=20
> The other major thing I think needs decided is what do we do with all o=
f
> the crap in the scheme directory.  Obviously, most of the stuff is
> valuable, but there is stuff there that does not need to be there and
> just adds a bunch of maintenance cost.  I would like to move some of th=
is
> to some sort of contrib section eventually, which we don't have yet.  B=
ut
> doing so means we have to decide what stays and what goes.  Perhaps, we
> could start marking the useless stuff as deprecated and see if anyone
> complains.
> We need to have deprecated functions print out a warning to make this=20
> effective.
> Some of the modules need to be refactored as well.  There are a lot of
> modules with circular dependencies, largely because utility routines cr=
ept
> into their functionality that somebody else wanted.  I'm not sure how t=
o
> deprecate this stuff effectively.  I think we need to start deprecating
> a fair amount of stuff to allow for refactoring and to keep the project=
 from
> falling under its own weight.
>=20
> What does everyone else think?

There are a lot of questions you ask, and as I am someone who just trying=
 to=20
make scwm it's default window manager, my opinion should not weight heavy=
=2E=20
Please go ahead, make the changes, do what has to be done. Before removin=
g or=20
changing some functionality, it could be documented and discused in the n=
g=20
and put in the the announce list.
As what to do with the 1.0 version, one way to look at it is to say, well=
 all=20
the people who worked on it all those years should have brought out an 1.=
0=20
version (and deserve it). My guess is that they where striving for=20
perfection, and always found one missing feature that needed to get in.

What direction you choose. Just let's get started. And afcource I'm willi=
ng to=20
help in any way.

pieter;

[Scwm-devs] backward compatibility in Scwm

[Scott L. <sl...@cs...>]

How important do you think backward compatibility is in Scwm?  There
are a lot of changes that should be made to clean up the code base
to enable easier addition of changes.  A lot of these changes would
result in backward compatibility issues.  I see roughly three ways
to handle this:

1. Don't make the changes
2. Make the changes in a way such that the changes are backwards compatible
   for one(or more) release(s)
3. Make the changes and damn the consequences

Option 1, leaves us with a difficult to understand, inconsistent, and
large code base.  I don't think this is tenable in the long term.
Option 2 requires a bunch of extra work to keep things
backwards compatible along with extra code to report deprecated features
and offer new ways to do things.  Option 3 is the easiest coding wise
but the hardest from a user perspective.  I think option 2 with backward
compatibility maintained for a single release is probably the best option,
but option 3 would be more convenient.

The different directions the code can be taken need some high level
decisions to be make on which way to take the code.  I feel funny
making these decisions since I haven't put nearly as much effort into
the code as Greg has.  Nonetheless, some decisions need to be made.
Do we clean up the code before we release 1.0?  What's our policy on
version numbers?  What's our policy on backwards compatibility?
When are acceptable times to put in an event or decoration rewrite?
Do these need to be post 1.0?  What is expected of a 1.0 release?
Working code?  Most code working?  No known bugs?  Stable API?  Should
the poor method names be renamed?  When?  Maintaining backward
compatibility?  For how long?  How should methods be named?  I think the
most important issue here is what are the expectations for version 1.0?
If 1.0 is to be very stable, new features shouldn't go in right before
it and the code should be changed little before hand.  If 1.0 is meant 
to have a very stable API, methods should be renamed and planned features
added beforehand.  If 1.0 is just another version, then this stuff doesn't
matter so much.  We've sort of built up expectations of 1.0 a bit by
having all of these 0.99.* releases, but there don't seem to be any
concrete guidelines of what constitutes 1.0.  I would be inclined to
make 1.0 more like just another release with the major subsystems tested.
The window manager is already obviously usable so I think somewhere along
the line it probably already should have been called 1.0.  It almost seems
like we are reserving 1.0 for when we feel it is "done", whatever that
means.  If 1.0 is just like another release, this implies:

- no special requirements need to be met for the next release to be
  called 1.0
- not everything needs to be tested before 1.0
- not everything needs to be documented before 1.0
- the documentation for 1.0 doesn't need to be fancy

The other major thing I think needs decided is what do we do with all of
the crap in the scheme directory.  Obviously, most of the stuff is
valuable, but there is stuff there that does not need to be there and
just adds a bunch of maintenance cost.  I would like to move some of this
to some sort of contrib section eventually, which we don't have yet.  But
doing so means we have to decide what stays and what goes.  Perhaps, we
could start marking the useless stuff as deprecated and see if anyone complains.
We need to have deprecated functions print out a warning to make this effective.
Some of the modules need to be refactored as well.  There are a lot of
modules with circular dependencies, largely because utility routines crept
into their functionality that somebody else wanted.  I'm not sure how to
deprecate this stuff effectively.  I think we need to start deprecating
a fair amount of stuff to allow for refactoring and to keep the project from
falling under its own weight.

What does everyone else think?

- Scott

Re: [Scwm-devs] Re: event question

[Greg B. <gj...@cs...>]

I see your point.  But you can think of the first level event map as
containing bindings for "j" -> literal "j" to be passed to the
application (that's the way Emacs treats them -- X's implementation
makes it a little bit trickier to view things that way, but I think it
can still make sense conceptually).  FWIW, the closest place I came to
multi-key mappings is stuff like my H-p "shove-window" binding that pops
up a little visualization of a keyboard, grabs the keyboard, and lets
you hit another key.  I like this UI a bunch and it does exactly what I
expect and want.

Thanks,
Greg

Scott Lenser <sl...@cs...> writes:

> > I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
> > see it complain "C-c C-@" is undefined.  Scwm could do that using a
> > popup message box for a user configurable amount of time.  Neither of
> > the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
> > send either to the application.)  The upshot of that is that prefix keys
> > should be non-app keys, but that's good sense, anyway.
> > 
> > Thanks,
> > Greg
> > 
> 
> I don't think the situation is entirely analogous since there is no question
> of emacs passing the event on to the app.  In any case, I think that is the
> most reasonable behavior.
> 
> There is an interesting side effect to this behavior.  If we follow the emacs
> model of event maps are a single event deep and prefixes are handled by
> going down to another event map, then the event maps act differently.
> 
> Consider, bindings like so:
> 
> event_map
>   M-F1 => event_map
>             M => maximize window
>             m => minimize window
>             i => iconify window
> 
> Now, if the user types "M-F1 j", a message displays saying this is not bound
> and nothing else happens.  If the user type "j", then this gets sent on to
> the application.  So in the first level event map, unbound events gets passed
> through.  In the second level event map, unbound events cause a message to
> be displayed.  The implementation in X calls is likely to be different too.
> The first level event map will need to install a bunch of passive X grabs to
> get its keys, but the second one will probably be handled with at least the
> keyboard grabbed.  I suppose this distinction could be made when the event map
> gets installed and thus hidden from the user.  It does create some interesting
> problems, though.
> 
> - Scott

Re: [Scwm-devs] Re: event question

[Scott L. <sl...@cs...>]

> I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
> see it complain "C-c C-@" is undefined.  Scwm could do that using a
> popup message box for a user configurable amount of time.  Neither of
> the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
> send either to the application.)  The upshot of that is that prefix keys
> should be non-app keys, but that's good sense, anyway.
> 
> Thanks,
> Greg
> 

I don't think the situation is entirely analogous since there is no question
of emacs passing the event on to the app.  In any case, I think that is the
most reasonable behavior.

There is an interesting side effect to this behavior.  If we follow the emacs
model of event maps are a single event deep and prefixes are handled by
going down to another event map, then the event maps act differently.

Consider, bindings like so:

event_map
  M-F1 => event_map
            M => maximize window
            m => minimize window
            i => iconify window

Now, if the user types "M-F1 j", a message displays saying this is not bound
and nothing else happens.  If the user type "j", then this gets sent on to
the application.  So in the first level event map, unbound events gets passed
through.  In the second level event map, unbound events cause a message to
be displayed.  The implementation in X calls is likely to be different too.
The first level event map will need to install a bunch of passive X grabs to
get its keys, but the second one will probably be handled with at least the
keyboard grabbed.  I suppose this distinction could be made when the event map
gets installed and thus hidden from the user.  It does create some interesting
problems, though.

- Scott

[Scwm-devs] Re: event question

[Greg B. <gj...@cs...>]

I'd use Emacs as a guide.  Try hitting something like C-c C-2 and you'll
see it complain "C-c C-@" is undefined.  Scwm could do that using a
popup message box for a user configurable amount of time.  Neither of
the keystrokes get inserted into the buffer.  (Just as Scwm wouldn't
send either to the application.)  The upshot of that is that prefix keys
should be non-app keys, but that's good sense, anyway.

Thanks,
Greg


Scott Lenser <sl...@cs...> writes:

> I've been thinking about the event rewrite.  I'm trying to write
> up a proposed interface to binding events based on the protocol
> Greg suggested in the doc/dev directory.
> 
> I think we want to support the ability to bind key sequences
> to actions.  I ran into a situation that I don't know what the
> right behavior should be and I'd like opinions.
> 
> Suppose the user has bound a bunch of keys to "F1 <key>" where
> they are basically using F1 as a prefix key for key events to
> send to the window manager.  What do you think should happen
> if they type "F1 b" where this key sequence has not been bound
> to anything?  Should Scwm send "F1 b" to the application, send
> "b" to the application, or drop the event on the floor?
> Or should it do something else entirely?
> 
> - Scott

[Scwm-devs] event question

[Scott L. <sl...@cs...>]

I've been thinking about the event rewrite.  I'm trying to write
up a proposed interface to binding events based on the protocol
Greg suggested in the doc/dev directory.

I think we want to support the ability to bind key sequences
to actions.  I ran into a situation that I don't know what the
right behavior should be and I'd like opinions.

Suppose the user has bound a bunch of keys to "F1 <key>" where
they are basically using F1 as a prefix key for key events to
send to the window manager.  What do you think should happen
if they type "F1 b" where this key sequence has not been bound
to anything?  Should Scwm send "F1 b" to the application, send
"b" to the application, or drop the event on the floor?
Or should it do something else entirely?

- Scott

[Scwm-devs] addendum to random thoughts

[Scott L. <sl...@cs...>]

I forgot to mention a little about the decorations.

There should be a mechanism to associate decorations and the
way they get drawn with the state of the window (focussed, 
highlighted, shaded, iconified, etc.).  Additionally states
should be definable at run time.

- Scott

[Scwm-devs] random thoughts and ideas

[Scott L. <sl...@cs...>]

Hi all.  [Sorry this message isn't formatted for 80 columns]

I've had about all the testing I can take at the moment, so I'm taking
a short break to familarize myself with the C code and start thinking
about plans and enhancements to make.  I should get back to testing
again shortly.  Anyway, here are some random thoughts, ideas, comments,
and questions for feedback.

I just noticed the stuff about window properties that Maciej was adding.  I'm
not sure that this is a good approach.  The way I see it, this basically
replaces a lot of specific functions that do clear things with a general
dispatching function that needs to have lots of magic constants/sysmbols/etc.
defined for it to work.  I don't really see much gain here.  The main gain
I see here is a logical place to attach new properties to windows.  With an
appropriate naming scheme, I think the individual functions capture most
of the information here.  Maybe what we need here is just to have the hooks
for the specific events call a generic property change hook after they run.
This seems to get most of the benefits (although I'm not even convinced this
is necessary) without resorting to processing every kind of hook on every
kind of event.  I think the scwm-options stuff is more like the kind of
interface we want.  What we do need is some way to add information to the
window thats needs to be used by some modules.  Thoughts on this?  I'm
pretty fuzzy on what the problem even is that we are trying to solve here.
I see a need for extensions to the information for each window, but I'm
not sure this gets us anywhere.

Anyway, that was actually just a side note.  The main thing I've been
thinking about is how to do the event/decoration rewrite correctly.  I've
grouped them together here since in my mind they are related and need to
be thought about at the same time (because events can be bound to decoration
elements).  Probably need to implemented in the order event rewrite then
decoration rewrite.  I've looked over the stuff in doc/dev to gather up
the ideas people had been thinking about.  In general, I think the event
proposal in doc/dev/events.gjb is pretty good, although I have a few comments
and thoughts.  First off, I think the idea of making events (make-key-event
and friends) might a good idea IF we can wrap this for the user such
that they can specify things more easily.  It would be pretty irritating to
have to make an event before you can bind a key in a keymap which then needs
to be installed before it has any effect.  I'm not sure this is a clear win
though.  Added this layer allows us to construct a little C structure to
represent that type of event which could allow us to avoid reparsing the
arguments if the event is reused.  However, many events are global and thus
only used once.  It's also not clear this translation is expensive.  I also
think the repesentation of the event map is unlikely to use these structures
since the event map should probably be represented as a hash.  Then having
these lying around in memory is just wasting space.  Also, if we use these
make-*-event routines, they should have a different name.  As is, they sound
like they are making an event that you could send to an app whereas they are
being used to define slots to which event handlers can be bound.

  I like your ideas for event map objects in general.  I agree that they should
be attached to X windows (button, titles, frames, client windows, etc.).
I'm not sure I agree with your commentary in make-event-map about relying on the
geometry-based chaining of X11.  Currently, we use the XShape extension to handle
our squashed title bars.  Fluxbox has a similar display element for their tabbed
windows which looks similar on screen.  However, instead of the shape extension
they use a seperate window which has the root window as parent.  This avoids the
shape extension but means that they have to explicitly remember to move both
windows whenever they move one.  Which is better depends on the efficiency of the
xshape extension and presumably on the area to which the shape extension is
applied.  I don't know enough to say whether this is a better way to do things,
but relying on X to propagate the events precludes doing things this way.  I'm not
sure if X even gives the option of not propagating the event upwards though.
I think allowing multiple parent event maps is confusing, error prone and doesn't
buy us much.  Hmm... just thought how that could be used to provide a nice keymap
mixin ability though.  I think we can get this same mixin type ability just
through the normal parent mechanism if we seperate the concept of event maps
and installed event maps (I think we might need this anyway to do the grabs
properly).  Then the installed event map could have the parent pointer and the
event map itself has no parent.  Oh, btw, the add-event-binding! primitive should
be able to take a keymap as the way to process a key-binding so that we can get
prefix key capability.  There should be some mechanism for having the sub event
map time out back to the normal key map for people who want it.  Anyway, back
to the parenting thing.  A mixin would just correspond to inserting another keymap
as the child of the current keymap.  Not sure what the primitives would look like
for all of this.  Just spouting ideas to get feedback right now.  For the event
callbacks, I don't see why different kinds of events couldn't have different
callback types.  Makes things less orthogonal but saves the callbacks accessing
some mysterious global variable.  I don't understand the comment you made about
the Common Lisp Object System method combination.  I don't understand how CLOS
is applicable, but maybe I'm just being dense.  I also think we want to have
some semantic classes to which event maps can be attached so you could say
things like (attach-event-map 'maximize-button max-button-event-map).  Semantic
classes would also be useful for supporting the various wm hints.

Some thoughts on decorations.  I think we need to think general here.  This means
almost abritrary drawing primitives for drawing various effects (like pixmaps,
gradients, colors, text, you name it) that should eventually live in modules that
get dynamically loaded.  This should allow for things like using a very simple
style for small footprint machines (although, I don't think we are going to do
to well on these anyway due to requiring guile) and using a native widget set
like gtk to blend with the apps better.  This could even allow gtk widgets on
GNOME apps and qt widgets on KDE apps.  I've been trying to keep two constraints
in mind when thinking about this: 1) it should be possible to emulate any other
window manager's look, 2) simple stuff should be simple to specify.  These two
are sort of at odds since 1 implies more features which implies more options
while 2 implies fewer options to have to specify.  I think this problem can be
handled with utility routines to use common styles and reasonable defaults as
appropriate.  Another major issue is how to specify the layout to use.  This
is actually even more complex than it initially appears because of new features
that are starting to appear in other window managers (assuming we stick to
constraint 1).  There are 3 features that I have seen that require special
thought.  The first is tabbed windows ala PWM, Fluxbox, and others.  The basic
idea is to group windows together into one frame and make a bunch of tab buttons
to select which one to display.  This looks cool and I'd like to support it.
The second, which is even more tricky, is subdivided displays and frames.  The
basic idea here is to stick multiple windows in one frame and provide a bar
inbetween them to control the relative size of the windows.  This is usually
a recursive binary partition but other grids are also possible.  See the Ion
window manager for a pretty example of this (http://www.students.tut.fi/~tuomov/ion/)
[what is it with those wacky Fins, they come up with the most strange and
interesting stuff, must be the winter].  I really want to support this as it
leads to a very nice interface for driving the window manager mostly from the
keyboard (the way I tend to do things).  The third feature is a bit more
exotic and not as useful but I'd like to support it if possible anyway.  This
feature is the workspace concept of amiwm (http://www.plig.org/xwinman/amiwm.html,
see the second screen shot).  The basic idea is several desktops that can be
manipulating somewhat like windows.  Sort of a nested window sort of thing.
This is probably more difficult to support and since I don't think it is as
useful, probably the right thing to do is not support at first in the rewrite
but try to leave room for it.  The common thread to these features is that they
remove the 1:1 mapping between client windows and frames/decorations.  I think
the decoration rewrite should reflect this.

Here's basically what I'm thinking at the moment.

Main concepts:

Container - an element in the window manager in which decorations can be arranged
  and client windows can be displayed (roughly equivalent to a frame [although may
  contain several client windows and the a client window can jump from container
  to container {although no 2 at the same time}]).  There would be a n:m mapping
  from client windows to associated containers.  Each client window would have a
  current container of NULL if not currently being displayed in any container.
  Containers can also hold other containers.  Event maps can be attached to containers.
  Each window will have at least a small container always associated with it which
  corresponds to the parent frame currently used.  [Not sure about this part:
  This can also have another frame to support decorations that jump with the window
  from container to container.  For Fvwm style decorations, this would be the only
  container needed.]
Layout - a layout specifies the layout of components within a container and enforces
  any constraints that need to be maintained.  Basically, the layout is reponsible
  for figuring out the location and size of all the widgets in a container.  Examples
  would be a grid layout, horizontal box, vertical box, etc. similar to tables, hboxs,
  vboxs, and the like in gtk.  Layouts can be nested.
Decoration - A primitive section of the screen to which an event map can be attached.
  Basically, these will be X windows.  This will be the smallest thing to which an event
  map can be attached.  Each decoration will have a list of drawing primitives to use
  to draw it.  Decorations would have some sort of shaped flag.
Drawing primitive - The basic primitives which can be used to draw stuff on the
  decorations.  This would include things like relief button, text, pixmap, relief
  pattern, gradient, solid color, line, use gtk button, and so on.  These need to
  be extensible by modules to allow for using widget libraries and such without making
  everyone suffer.  Probably need an object to hold lists of these.

Decorations, layout, and containers without client windows can share their
specification across multiple instantiations.  Probably sort of like the
menu item/menu item in menu distinction.

All of these settings should be changeable on the fly.  There will be styling
routines to help make specification for common styles.  There will be styling
routines for specifying things like fvwm style, wm2 style, etc.

So here's how I see the different cases above being implemented.

fvwm style - one container for each window, each button becomes a decoration, the
  border parts and corners become decorations, the title bar becomes a container
  holding the title, buttons.  The button faces, title faces, and border faces become
  drawing primitive lists.  Icons/menus are containers that don't have a client area.
pwm style [tabbed windows] - one container for each group of windows.  container is
  similar to fvwm stuff except has additional tab section.  Tab buttons bound to
  switching the client window associated with the container's client area.  Other
  bindings split/join groups of windows by creating/destroying containers dynamically.
  Note: this happens even when no client windows are being created.
ion style [subdivided screen] - one container for entire screen.  Container has several
  client areas within it along with decorations for the grab bars to resize the subparts.
  Windows get put into this container when captured and get a new client area created
  for them along with new decoration for the grab bar to resize them.  Note: this means
  need to be able to add decorations to a container on the fly.  Mixed ion/pwm/fvwm style
  can also be supported through similar means.

Other interesting things you could do with this: make a mode that when you bump one window
into another they become part of the same frame and move/iconify/etc together.  This gets
many of the same benefits as the constraint stuff.

Implementation notes:

The drawing primitives are mostly already there in the form of faces.
Many more things need to be dynamic because less info is known up front.  This means more
  dynamic data structures.
Need to be careful in specification of all this to make easy things easy.  This
  means common layout things need to be easy.

Well, those are my thoughts so far.  Let me know what you think, where there are holes,
unimplementable stuff, overly general stuff, etc.  I'm sure there are still major problems
with this and it is still pretty wishy-washy right now but I thought some early feedback
would be helpful.  I see this as probably an immediately post-1.0 thing.  This is going
to shake up the interface a fair amount so this might require a rather major bump of
version number.

Which reminds me, we need to think about a convention for version numbers.  Specifically,
I think something in the version number needs to correspond to changes in the API.  We
need to figure out a correspondence between API changes and revision number bumps so
people can tell what they are in for when upgrading (of course, we should try to keep
backwards compatibility too).  We also need a policy on backwards compatibility since
it'll be too unwieldy to support everything forever.  A lot of the current functions in
the API have pretty arbitrary names.  We should pick a naming scheme and try to stick
to it and change all the old names to new names.  There is the question of whether we
should do this pre-1.0 or not.  The argument against is things work as is and have been
tested this way.  The argument for is that the API should be somewhat stabilized with the
1.0 release and therefore this should happen before the 1.0 release.

Well I better get some sleep now.  Let me know what you'll think.

- Scott

Re: [Scwm-devs] Re: done testing key-mover-xtest.scm

[Greg B. <ba...@cs...>]

I agree with you that an interface to the "preferred" functionality is
in order, and that we need an interface to the primitive functionality,
as well.  I dislike global state side-effects, though, so I still prefer
an extra level of indirection that folks can use.  There may be other
reasons why folks want to send synthetic events (I can't think of
anything esp. compelling right now, but it's been a while for me).

Thanks,
Greg

Scott Lenser <sl...@cs...> writes:

> There are other ways to test this without exposing a dual interface though.
> For instance, you could expose a function that sets debugging flags that
> disallow the use of certain features of the X server.  Seems bad to make
> the client decide which one they want when we can easily determine it
> for them (perhaps on the scheme side, perhaps on the C side).
> 
> - Scott
> 
> > To test it, for one. :-)
> > 
> > Greg
> > 
> > Scott Lenser <sl...@cs...> writes:
> > 
> > > > Scott Lenser <sl...@cs...> writes:
> > > > 
> > > > > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > > > > actually look to see how they were implemented much.  Couldn't this
> > > > > be folded into the move-pointer primitive so that you always get the
> > > > > best one that your version of X supports?  In any case, the function
> > > > > to move the virtual viewports is identical between the two versions.
> > > > 
> > > > It's possible, but sometimes you specifically want one or the other, so
> > > > the "smart" one would have to be another layer of abstraction.  The
> > > > stuff that's truly duplicated definitely should be factored out into
> > > > something separate.
> > > > 
> > > > Thanks,
> > > > Greg
> > > > 
> > > 
> > > When would you want the non-xtest one if it the xtest one is available?
> > > 
> > > - Scott

Re: [Scwm-devs] Re: done testing key-mover-xtest.scm

[Scott L. <sl...@cs...>]

There are other ways to test this without exposing a dual interface though.
For instance, you could expose a function that sets debugging flags that
disallow the use of certain features of the X server.  Seems bad to make
the client decide which one they want when we can easily determine it
for them (perhaps on the scheme side, perhaps on the C side).

- Scott

> To test it, for one. :-)
> 
> Greg
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > > Scott Lenser <sl...@cs...> writes:
> > > 
> > > > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > > > actually look to see how they were implemented much.  Couldn't this
> > > > be folded into the move-pointer primitive so that you always get the
> > > > best one that your version of X supports?  In any case, the function
> > > > to move the virtual viewports is identical between the two versions.
> > > 
> > > It's possible, but sometimes you specifically want one or the other, so
> > > the "smart" one would have to be another layer of abstraction.  The
> > > stuff that's truly duplicated definitely should be factored out into
> > > something separate.
> > > 
> > > Thanks,
> > > Greg
> > > 
> > 
> > When would you want the non-xtest one if it the xtest one is available?
> > 
> > - Scott

[Scwm-devs] done testing property-respond.scm

[Scott L. <sl...@cs...>]

Summary:

works fine except for minor fix to 'handle-flash-property'

Changelog:

	* property-respond.scm:
	Made 'handle-flash-property' work when the color is not specified.
	Added comment to property-responses.
	Added 'property-changed-debug' to hooks inserted by
	  'start-property-respond' to be consistent with 'stop-property-respond'.
	Improved docs for 'start-property-respond' and 'stop-property-respond'.
	Improved code formatting.