pywm-talk — Discussion about development and propably everything else

[PyWM-talk] Maintainers update

[<el...@ji...>]

I haven't forgotten pywm, but I have been busy with school. Now that the
summer holidays are on, I would like to get something done. If you have
problems of any kind with pywm or want to improve it, I'm ready to help,
but if not, I probably won't post anything in the immediate future since
I have some other projects needing my attention.

Elmo

[Fwd: Re: [PyWM-talk] pywm debian installation]

[<el...@ji...>]

Jonathan North Washington wrote:

> I'm having the exact same problem on my debian box atm too.
>
> --  Jonathan
>
> On 16 Apr 2006, at 20:40, George Harris wrote:
>
>> I've been trying to install pywm on debian unstable and I haven't 
>> quite been able to get it working. Upon running setup.py install, 
>> I'm getting a compile error about what looks like fltk fonts. I've 
>> followed the posted directions and installed all of the necessary 
>> libraries, but I might have missed something. Below is the output; 
>> I've got a hankering for some tinkering and any help would be 
>> appreciated.
>>
>> Thanks,
>> George
>>
>> # python setup.py install
>> running install
>> running build
>> running build_py
>> running build_ext
>> building 'pywm.flwm_' extension
>> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-
>> prototypes -fPIC -DFLTK_1_0_COMPAT -I/usr/include/python2.3 -c src-
>> c/Rotated.cpp -o build/temp.linux- i686-2.3/src-c/Rotated.o
>> cc1plus: warning: command line option "-Wstrict-prototypes" is  valid
>> for Ada/C/ObjC but not for C++
>> In file included from /usr/include/python2.3/Python.h:8,
>>                  from src-c/pycallbacks.h:10,
>>                  from src-c/Rotated.cpp:43:
>> /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE" 
>> redefined
>> In file included from /usr/include/stdlib.h:25,
>>                  from src-c/Rotated.cpp:35:
>> /usr/include/features.h:150:1: warning: this is the location of the 
>> previous definition
>> src-c/Rotated.cpp: In function 'void draw_rotated(const char*, int, 
>> int, int, int)':
>> src-c/Rotated.cpp:396: error: 'fl_xxfont' was not declared in this 
>> scope
>> error: command 'gcc' failed with exit status 1
>
Sorry, I forgot to do a testbuild. Attached is a file that compiles.

Re: [PyWM-talk] pywm debian installation

[Jonathan N. W. <li...@fi...>]

I'm having the exact same problem on my debian box atm too.

--  
Jonathan

On 16 Apr 2006, at 20:40, George Harris wrote:

> I've been trying to install pywm on debian unstable and I haven't  
> quite been able to get it working. Upon running setup.py install,  
> I'm getting a compile error about what looks like fltk fonts. I've  
> followed the posted directions and installed all of the necessary  
> libraries, but I might have missed something. Below is the output;  
> I've got a hankering for some tinkering and any help would be  
> appreciated.
>
> Thanks,
> George
>
> # python setup.py install
> running install
> running build
> running build_py
> running build_ext
> building 'pywm.flwm_' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict- 
> prototypes -fPIC -DFLTK_1_0_COMPAT -I/usr/include/python2.3 -c src- 
> c/Rotated.cpp -o build/temp.linux- i686-2.3/src-c/Rotated.o
> cc1plus: warning: command line option "-Wstrict-prototypes" is  
> valid for Ada/C/ObjC but not for C++
> In file included from /usr/include/python2.3/Python.h:8,
>                  from src-c/pycallbacks.h:10,
>                  from src-c/Rotated.cpp:43:
> /usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE"  
> redefined
> In file included from /usr/include/stdlib.h:25,
>                  from src-c/Rotated.cpp:35:
> /usr/include/features.h:150:1: warning: this is the location of the  
> previous definition
> src-c/Rotated.cpp: In function 'void draw_rotated(const char*, int,  
> int, int, int)':
> src-c/Rotated.cpp:396: error: 'fl_xxfont' was not declared in this  
> scope
> error: command 'gcc' failed with exit status 1

[PyWM-talk] pywm debian installation

[George H. <ash...@gm...>]

I've been trying to install pywm on debian unstable and I haven't quite bee=
n
able to get it working. Upon running setup.py install, I'm getting a compil=
e
error about what looks like fltk fonts. I've followed the posted directions
and installed all of the necessary libraries, but I might have missed
something. Below is the output; I've got a hankering for some tinkering and
any help would be appreciated.

Thanks,
George

# python setup.py install
running install
running build
running build_py
running build_ext
building 'pywm.flwm_' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes
-fPIC -DFLTK_1_0_COMPAT -I/usr/include/python2.3 -c src-c/Rotated.cpp -o
build/temp.linux-i686-2.3/src-c/Rotated.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for
Ada/C/ObjC but not for C++
In file included from /usr/include/python2.3/Python.h:8,
                 from src-c/pycallbacks.h:10,
                 from src-c/Rotated.cpp:43:
/usr/include/python2.3/pyconfig.h:853:1: warning: "_POSIX_C_SOURCE"
redefined
In file included from /usr/include/stdlib.h:25,
                 from src-c/Rotated.cpp:35:
/usr/include/features.h:150:1: warning: this is the location of the previou=
s
definition
src-c/Rotated.cpp: In function 'void draw_rotated(const char*, int, int,
int, int)':
src-c/Rotated.cpp:396: error: 'fl_xxfont' was not declared in this scope
error: command 'gcc' failed with exit status 1

Re: [PyWM-talk] feature possible?

[<el...@ji...>]

Jonathan North Washington wrote:

>
> On 13 Apr 2006, at 08:14, Elmo Mäntynen wrote:
>
>> Jonathan North Washington wrote:
>>
>>> I'd like to hear people's thoughts on this.  I also wonder how easy
>>> Elmo thinks this would be to implement, and whether it's an
>>> appropriate feature for PyWM.
>>
>>
>> This is definitely suited for pywm. If you have the time (shouldn't 
>> take
>> long), you can try to implement this in a wm-script and tell if
>> something in pywm should adjusted to accomodate this kind of behavior
>> better. Alternatively you can just wait till someone, like me,
>> implements this, which should happen soon. Anyway, you should post any
>> specific details you might have in mind so we can come up with a 
>> kind of
>> spec.
>
>
> I'm not sure about writing a wm script (I imagine that's best done 
> running PyWM, and I'm currently running OS X as my primary OS, so it 
> would take a little effort to figure out even what's entailed..), but 
> here's the basic logic for what it should do:
> - if window is being dragged and cursor hits a screen edge:
>   - maximise window horizontally if top or bottom edge
>   - maximise window vertically if left or right edge
>   - reset area where windows can be maximised to the remaining  screen
> area
> - if maximised window is dragged, unmaximise
>
> I suppose there's a little bit more to it than that, but that should 
> provide the basics.  Seems pretty simple, and so useful it's a wonder 
> all WMs don't do it..  There should probably be a way (in a config 
> file or menu somewhere) to enable and disable this feature.
>
> And btw, my friend who came up with the demo calls the feature 
> "Window Locking".  I suppose that's a good name for it.
>
If no one beats me to it, I will try to do this. Hopefully soon, though
not guaranteed =).

Elmo

Re: [PyWM-talk] feature possible?

[Jonathan N. W. <li...@fi...>]

On 13 Apr 2006, at 08:14, Elmo M=E4ntynen wrote:

> Jonathan North Washington wrote:
>
>> I'd like to hear people's thoughts on this.  I also wonder how easy
>> Elmo thinks this would be to implement, and whether it's an
>> appropriate feature for PyWM.
>
> This is definitely suited for pywm. If you have the time (shouldn't =20=

> take
> long), you can try to implement this in a wm-script and tell if
> something in pywm should adjusted to accomodate this kind of behavior
> better. Alternatively you can just wait till someone, like me,
> implements this, which should happen soon. Anyway, you should post any
> specific details you might have in mind so we can come up with a =20
> kind of
> spec.

I'm not sure about writing a wm script (I imagine that's best done =20
running PyWM, and I'm currently running OS X as my primary OS, so it =20
would take a little effort to figure out even what's entailed..), but =20=

here's the basic logic for what it should do:
- if window is being dragged and cursor hits a screen edge:
   - maximise window horizontally if top or bottom edge
   - maximise window vertically if left or right edge
   - reset area where windows can be maximised to the remaining =20
screen area
- if maximised window is dragged, unmaximise

I suppose there's a little bit more to it than that, but that should =20
provide the basics.  Seems pretty simple, and so useful it's a wonder =20=

all WMs don't do it..  There should probably be a way (in a config =20
file or menu somewhere) to enable and disable this feature.

And btw, my friend who came up with the demo calls the feature =20
"Window Locking".  I suppose that's a good name for it.

--=20
Jonathan=

Re: [PyWM-talk] feature possible?

[<el...@ji...>]

Jonathan North Washington wrote:

> There's a feature I'd love to see implemented in a window manager, 
> and I think PyWM is the right windowmanager for it.
>
> The attached file is a demo a friend wrote up for a class on Human-
> Computer Interaction.  You can run the demo by running python 
> windowlockdemo.py, and you'll need pygame.  If you drag a window to 
> the right edge of the screen, the window fills the edge, and the new 
> edge of the screen is the left edge of the window--you can see this 
> if you maximize the remaining window.
>
> Ideally this feature would work for any edge of the screen, and the 
> window management otherwise would work as expected.  This sort of 
> "docking" would give a window manager RatPoison-like functionality 
> without taking away the functionality of a normal wm.  I expect a 
> number of uses of this feature come to mind.

Very interesting indeed.

>
> I'd like to hear people's thoughts on this.  I also wonder how easy 
> Elmo thinks this would be to implement, and whether it's an 
> appropriate feature for PyWM.

This is definitely suited for pywm. If you have the time (shouldn't take
long), you can try to implement this in a wm-script and tell if
something in pywm should adjusted to accomodate this kind of behavior
better. Alternatively you can just wait till someone, like me,
implements this, which should happen soon. Anyway, you should post any
specific details you might have in mind so we can come up with a kind of
spec.

Elmo

[PyWM-talk] feature possible?

[Jonathan N. W. <li...@fi...>]

There's a feature I'd love to see implemented in a window manager,  
and I think PyWM is the right windowmanager for it.

The attached file is a demo a friend wrote up for a class on Human- 
Computer Interaction.  You can run the demo by running python  
windowlockdemo.py, and you'll need pygame.  If you drag a window to  
the right edge of the screen, the window fills the edge, and the new  
edge of the screen is the left edge of the window--you can see this  
if you maximize the remaining window.

Ideally this feature would work for any edge of the screen, and the  
window management otherwise would work as expected.  This sort of  
"docking" would give a window manager RatPoison-like functionality  
without taking away the functionality of a normal wm.  I expect a  
number of uses of this feature come to mind.

I'd like to hear people's thoughts on this.  I also wonder how easy  
Elmo thinks this would be to implement, and whether it's an  
appropriate feature for PyWM.

-- 
Jonathan

[PyWM-talk] Supporting other that debian based distros, help welcome

[<el...@ji...>]

I'm working on debian packaging, but if there's someone on this list
that wants to do other types of packages, they are welcomed. Especially
sitewide menu support for other than debian based distributions.
Attached is a script that was used to create menus for flwm (compatible
with pywm) for redhat, which is a bit old. If it doesn't work, it should
at least help get started.

Elmo

Re: [PyWM-talk] Scheme for key binding

[<el...@ji...>]

Maeda Yasuyuki wrote:

>I want the two-stroke key-binding like emacs. And somebody else 
>may prefer the binding like vi. 
>So I want the class to manage the key-bindings and to provide the easy 
>interfaces to bind both emacs-like and vi-like. It's best if it also provides 
>the way to give the difference binding for the difference window.
>
>Maeda
>
I'm not sure about emacs- or vi-style key binding (have never even used
them anywhere), but different bindings for different apps/windows should
work, I think. Later when I look in to  that portion of pywm closer I
might give you some pointers. Meanwhile you're on your own=)

Elmo

[PyWM-talk] Scheme for key binding

[Maeda Y. <ma...@th...>]

I want the two-stroke key-binding like emacs. And somebody else 
may prefer the binding like vi. 
So I want the class to manage the key-bindings and to provide the easy 
interfaces to bind both emacs-like and vi-like. It's best if it also provides 
the way to give the difference binding for the difference window.

Maeda

Re: [PyWM-talk] segmentation fault occurs when the applications launch

[<el...@ji...>]

Elmo Mäntynen wrote:

>Maeda Yasuyuki wrote:
>
>  
>
>>I've got a point!
>>As was expected, the segfaults seems to be of a font problem.
>>
>>I found where the segfaults occurred: line 116 in Rotated.cpp  
>>116:    XSetFont(dpy, font_gc, fontstruct->fid); 
>>
>>'fontstruct' was null when segfaults occurred. I couldn't follow how it should be set. 
>>
>>Would you give me a suggestion to resolve the problem?
>>
>>Maeda
>> 
>>
>>    
>>
>Now that's great. I thought this particular bug shouldn't appear with
>fltk 1.1.4=<, but I happen to have two alternative fixes. As you seem to
>know c better than I do, you could look into them and propose a final
>fix. The fixes are in comments in Rotated.cpp (use the one attached),
>and you should first look around line 450. There's also something around
>180, but that wouldn't work out of the box, since the fix happens after
>line 116 (they are at the same level). Hope this works, I should've
>thought about this sooner.
>
>Elmo
>
>  
>
The file =)

Re: [PyWM-talk] segmentation fault occurs when the applications launch

[<el...@ji...>]

Maeda Yasuyuki wrote:

>I've got a point!
>As was expected, the segfaults seems to be of a font problem.
>
>I found where the segfaults occurred: line 116 in Rotated.cpp  
>116:    XSetFont(dpy, font_gc, fontstruct->fid); 
>
>'fontstruct' was null when segfaults occurred. I couldn't follow how it should be set. 
>
>Would you give me a suggestion to resolve the problem?
>
>Maeda
>  
>
Now that's great. I thought this particular bug shouldn't appear with
fltk 1.1.4=<, but I happen to have two alternative fixes. As you seem to
know c better than I do, you could look into them and propose a final
fix. The fixes are in comments in Rotated.cpp (use the one attached),
and you should first look around line 450. There's also something around
180, but that wouldn't work out of the box, since the fix happens after
line 116 (they are at the same level). Hope this works, I should've
thought about this sooner.

Elmo

Re: [PyWM-talk] segmentation fault occurs when the applications launch

[<el...@ji...>]

Maeda Yasuyuki wrote:

>Elmo Mäntynen wrote:
>  
>
>>Something realy weird happens with the pyrex code. I don't understand it
>>yet, but attached is a version of flwm_.pyx that shouldn't fail (can you
>>confirm this?)
>>    
>>
>Indeed, no exceptions were thrown with the new flwm_.pyx. 
>However, segfaults still occured.
>
>I tried Fedora Core 3, which contains:
>glibc 2.3.6
>gcc 3.4.4
>fltk 1.1.4
>python 2.3.4
>Pyrex 0.9.2
>
>I suspected that multibyte for Japanese character caused the segfaults, so that I also installed English version Fedora Core 3.It also failed. 
>
>Maeda
>  
>
Thanks a lot for your effort. As it segfaults only with certain apps,
what would be the lowest common denominator, as in, what is in those
apps that causes the segfaulting that isn't in the two terminal
programs. Could it be sheer size, time that takes for them to start, or
what? Could you maybe test other terminal progs, very small to very
large www-browsers, and anything else of significance you might come up
with.

Thanks again.

Elmo

Re: [PyWM-talk] segmentation fault occurs when the applications launch

[<el...@ji...>]

Elmo Mäntynen wrote:

>Maeda Yasuyuki wrote:
>
>  
>
>>I found that the exception was thrown even when xterm is launching.
>> 
>>
>>    
>>
>The exception gets thrown from time to time when doing something with
>windows, like creating them. Will have to look in this more deeply,
>concerning the apparently non-deterneministic nature of exception throwing.
>  
>
Something realy weird happens with the pyrex code. I don't understand it
yet, but attached is a version of flwm_.pyx that shouldn't fail (can you
confirm this?), but around line 680, there's very rude hack. If you want
to investigate, go ahead, I have to sleep now.

Elmo

[Fwd: Re: [PyWM-talk] segmentation fault occurs when the applications launch]

[<el...@ji...>]

A correction...

Maeda Yasuyuki wrote:

>I found that the exception was thrown even when xterm is launching.
>  
>
The exception gets thrown from time to time when doing something with
windows, like creating them. Will have to look in this more deeply,
concerning the apparently non-deterneministic nature of exception throwing.

>This exception may not be concerned with segfaults directly 
>because PyWM kept running in this case.
>  
>
To me it seems that they are related, but as I don't get segfaults, it
should be possible for you to get rid of the segfaults somehow.

>---beginning---
>myWindowClass.__init__: window xterm created
>flwm_.py_on_create: chained handler ok
>flwm_.py_on_create: a chained handler failed
>Traceback (most recent call last):
>  File "flwm_.pyx", line 681, in flwm_.py_on_create
>  File "/usr/lib/python2.4/site-packages/pywm/applets.py", line 66, in taskbarRefresh
>    if win:
>  File "flwm_.pyx", line 731, in flwm_.py_on_activate
>  File "/usr/lib/python2.4/site-packages/pywm/__init__.py", line 1107, in window    return self.windows[hWin]
>KeyError: 143635344L
>myWindowManager: created window xterm
><window hWin:0x88fb390 'xterm'>
>Fl_Hold_Browser.clear: entered
>Fl_Hold_Browser_clear: entered
>flwm_.py_on_deactivate: chained handler ok
>WM.on_deactivate: deactivated 'xterm'
>---end---
>
>Moreover, when I use example1 to example4, xterm caused PyWM down,
>just example5 were OK.
>
>---beginning---
>*********** LAUNCHING FLWM *******************
>WM.on_create: created window 'xterm'
>zsh: segmentation fault  python /usr/lib/python2.4/site-packages/pywm/examples/example1.py
>---end---
>
>My envrioment is:
>Pyrex : 0.9.3.1
>gcc : 4.1.0
>glibc : 2.4
>python : 2.4.2
>fltk : 1.1.7
>  
>
I tested with a setup that differs only with glibc being v. 2.3.6 (I'm
using debian testing). Still, pywm just keeps going, only complaining
from time to time. What do you think is causing the segfaulting? Could
you maybe test with differrent setups (different distros especially)

Anyway, I'll try to fix the bug soon.

>>Expect (don't depend on me though=) a solution around the weekend.
>>    
>>
>Thank you for your favor. I will try to figure it out, too.
>
>Maeda
>  
>
No problem, after all, I'm supposed to maintain this software =)...

Elmo

Re: [PyWM-talk] segmentation fault occurs when the applications launch

[<el...@ji...>]

Maeda Yasuyuki wrote:

>I found that the exception was thrown even when xterm is launching.
>  
>
The exception gets thrown from time to time when doing something with
windows, like creating them. Will have to look in this more deeply,
concerning the apparently non-deterneministic nature of exception throwing.

>This exception may not be concerned with segfaults directly 
>because PyWM kept running in this case.
>  
>
To me it seems that they are related, but as I don't get segfaults, It
should be possible for also.

>---beginning---
>myWindowClass.__init__: window xterm created
>flwm_.py_on_create: chained handler ok
>flwm_.py_on_create: a chained handler failed
>Traceback (most recent call last):
>  File "flwm_.pyx", line 681, in flwm_.py_on_create
>  File "/usr/lib/python2.4/site-packages/pywm/applets.py", line 66, in taskbarRefresh
>    if win:
>  File "flwm_.pyx", line 731, in flwm_.py_on_activate
>  File "/usr/lib/python2.4/site-packages/pywm/__init__.py", line 1107, in window    return self.windows[hWin]
>KeyError: 143635344L
>myWindowManager: created window xterm
><window hWin:0x88fb390 'xterm'>
>Fl_Hold_Browser.clear: entered
>Fl_Hold_Browser_clear: entered
>flwm_.py_on_deactivate: chained handler ok
>WM.on_deactivate: deactivated 'xterm'
>---end---
>
>Moreover, when I use example1 to example4, xterm caused PyWM down,
>just example5 were OK.
>
>---beginning---
>*********** LAUNCHING FLWM *******************
>WM.on_create: created window 'xterm'
>zsh: segmentation fault  python /usr/lib/python2.4/site-packages/pywm/examples/example1.py
>---end---
>
>My envrioment is:
>Pyrex : 0.9.3.1
>gcc : 4.1.0
>glibc : 2.4
>python : 2.4.2
>fltk : 1.1.7
>  
>
I tested with a setup that differs only with glibc being v. 2.3.6 (I'm
using debian testing). Still, pywm just keeps going, only complaining
from time to time. What do you think is causing the segfaulting? Could
you maybe test with differrent setups (different distros especially)

Anyway, I'll try to fix the bug soon.

>>Expect (don't depend on me though=) a solution around the weekend.
>>    
>>
>Thank you for your favor. I will try to figure it out, too.
>
>Maeda
>  
>
No problem, after all, I'm supposed to maintain this software =)...

Elmo

[PyWM-talk] segmentation fault occurs when the applications launch

[Maeda Y. <ma...@th...>]

I have succeeded to start up PyWM. But segmentaion fault occured 
when applications launched. I tried Emacs, Firefox, sylpheed, xev, xeyes... Only xterm and gnome-terminal were OK.

I am using Fedora Core 5 and the following is the log when sylpheed launched:

--- beginning of log ---
myWindowClass.__init__: creating a window
myWindowClass.__init__: window Sylpheed version 2.0.4 created
flwm_.py_on_create: chained handler ok
flwm_.py_on_create: a chained handler failed
Traceback (most recent call last):
  File "flwm_.pyx", line 681, in flwm_.py_on_create
  File "/usr/lib/python2.4/site-packages/pywm/applets.py", line 66, in taskbarRefresh
    if win:
  File "flwm_.pyx", line 731, in flwm_.py_on_activate
  File "/usr/lib/python2.4/site-packages/pywm/__init__.py", line 1107, in window    return self.windows[hWin]
KeyError: 159533600L
myWindowManager: created window Sylpheed version 2.0.4
zsh: segmentation fault  python .pywm/example5.pyc
--- end ---

Can you realize what was happening?
If you need the additional informations, please let me know.

Best regards,
Maeda

[PyWM-talk] Improvement suggestions wanted...

[<el...@ji...>]

As you can see, there isn't much traffic on this list, and since you
have joined, why not generate some=). Specifically, apart from any
questions you might have, suggestions are welcomed. Especially feedback
about the docs. Small suggestions are preferable if you'd like them
implemented by me in the near future, but day dreaming is always fun=),
especially so if you're into coding python (or c, ofcourse) youself.

Elmo

[PyWM-talk] New release

[<el...@ji...>]

Release named 0.1-1-a3 appears on sf.net in a moment.

Highligths:

Improved documentation and smart window placement (somewhat experimental).

Try out and give feedback about the docs.

Elmo

Re: [PyWM-talk] Stuck with the install

[<el...@ji...>]

cga wrote:

> Elmo Mäntynen wrote:
>
>> cga wrote:
>>  
>>
>>>   
>>
> [...]
>
>>> Please advise.
>>>
>>>   
>>
>> Well, I don't know wether you looked in the README and or the INSTALL
>> files (wich you should), but here are the parts that are applicable:
>>
>> "
>> *** INSTALLING BINARY PACKAGE
>>
>>  
>>
> [...]
>
> misread the instructions.. :-[
>
> here's what I have:
>
> * There is no binary offered in this package, and there's
>   a version mismatch with python 2.3.5 and later, so building
>   from source is encouraged. I'll gladly help, or might even
>   send a binary if asked nicely=). If you'd like to try
>   the old binary, it's in the original 0.1 release (caution: the
> instructions below
>   might not be correct).

The "caution" is there for good reason=). I think they are reminiscent
of some previous shape of pywm.

>
> * If you feel impatient, or you just hate building
>   stuff from source, you could try the binary module
>   included in this package.
>
> found this a little confusing.. at first glance (2) ..
>
> "try the binary module included in 'this' package.." appears to
> contradict (1) "There is no binary offered in 'this' package.."

I have made only the most necessary changes to the docs so it's possible
to get started without going through everything I did the first time.
Now that someone has shown interest I will definitely rework the docs.

>
> But I was not so much being 'impatient' & trying to comlete the
> install so as to have a working pywm.. main objective was playing with
> the install to clarify my understanding of pywm in relation to my
> working environment.. the implications.. how it would fit into my
> current setup - I obviously need  to keep separate.. figuring whether
> it would be preferable to run pywm under a test user.. the environment
> variables I might need to set.. clarify the role of pyrex.. stuff like
> that..
>
>> So you do need libfltk1.1-dev and python-pyrex
>>
> python-pyrex is not installed but there is a debian package:
>
> $ apt-cache search pyrex
> pyrex-mode - Emacs-lisp pyrex-mode for Pyrex
> python-pyrex - Compile native-code modules for Python from python-like
> syntax
> python-tables - hierarchical database for Python based on HDF5
> python2.2-pyrex - Compile native-code modules for Python from
> python-like syntax
> python2.2-tables - hierarchical database for Python based on HDF5
> python2.3-pyrex - Compile native-code modules for Python from
> python-like syntax
> python2.3-tables - hierarchical database for Python based on HDF5
> python2.4-tables - hierarchical database for Python based on HDF5

I should've been clearer. I mean't, debian packages libfltk1.1-dev and
python-pyrex, needed for compiling

>
> I do have a libfltk:
>
> $ dkg -l '*libfltk*'
> ..
> ii  libfltk1.1c102                                   
> 1.1.6-5                                           Fast Light Toolkit
> shared libraries
>
> presumably installed when I 'apt-got' flwm.
>
>> (this might not be enough,
>> we'll see), but you have no use for flwm
>>
> isn't flwm a requirement..?

PyWM is an pythonisation of flwm, which you couldn't achieve by making a
driver for the flwm binary. So, flwm isn't required, it's included
(think of pywm as a fork of flwm).

>
>> (if you wan't a prebuilt binary,
>> that's not the place where to look for it).
>>
>>  
>>
> I try not to install too much stuff that's not managed by the debian
> packaging system.. but for something like pywm that is not finalized
> at this point - and not available in .deb

-----------------------------------------------------------------------------------------------^^^^^^^^^^^^^^^^^^^^^
To be changed in the foreseeable future...

> format - my instincts tell me that sooner or later I will have to
> build from source. So I will have to keep track of what I install
> manually - no big deal since there is not really much - but also.. and
> that's my main concern.. make sure that components (libraries.. python
> modules..) that are installed together with pywm do not clash with
> anything that comes with the sarge distro.. That's why I would prefer
> to use whatever components are already available on my system and *if
> possible* get those that are not yet installed from debian
> repositories. I do realize that you may not be able to advise me
> regarding debian aspects and that I will have to figure this out myself.

You just described my attitude towards non-debianized software, though I
happen to use some devel versions of certain packages, which can be a
bit of a pain with debian sometimes. So, I do use "the greatest distro
of them all" (testing), and can help accordingly.

Just installing pywm is very unlikely to clash with anything (no
packages that I know of install anything having pywm somewhere in the path)

> just hope I won't end up having to set up some form of chroot environment
>
> :-)

About setting up a chroot: I currently run pywm inside a chroot, mainly
because of ease of testing (I can use the same user without messing with
my homedir) with some confidence that if X doesn't take the kernel with
it if it happened to crash, my main instance of X isn't bothered. You
can read the warning text at pywm.sf.net/#status, which is written by
the  original author. PyWM seems quite stable, but at least while
developing your own scripts (am going to develop something generally
useful, but in the meantime this is a necessary step for pywm to be of
any real use), you should be vary about having open anything critical
apps. Doing a "New login" and logging in as a different user would
propably work without much fear of crashing your working environment,
but you never know...

>> "
>> ...
>> If you have successfully [built and] installed FLTK, you
>> can log in as root and type:
>>      make install (or 'python setup.py build', and link to
>>    it by means of a site.py, etc)
>>
>> If the make completes successfully, you will have:
>>
>>  * The PYWM launcher utility, installed as
>>    /usr/bin/pywm-run.py
>>    This program pops up a window of available window
>>    manager scripts, as well as an xterm fallback
>>    * The directory 'pywm' installed in your Python
>>    site-packages directory. Note that within this pywm
>>    directory is a copy of the examples directory.
>> ...
>> "
>>
>> This should work, but tell me if the instructions aren't clear
>> enough(they aren't complete nor completely right, I have to work on
>> that).
>>
>>
>>  
>>
> I need to send some time reading and understanding the instructions
> regarding the source install and I will get back to you with any
> questions I may have. Hopefully, this will provide a log of the
> problems - if any - encountered by an average user with some
> superficial knowledge of window managers.. little python and even less
> oop.. and may help improve the INSTALL document.

All this is hopefully going to improve, but you can always learn by
figuring things out yourself. At least that has happened to me while
working on pywm, since I didn't (and still don't) really know much about
stuff like the build process of c/c++/pyrex, wm's and the debian way of
generating menus and starting a particular wm through gdm...

> Thank you very much for you fast, detailed response.
>
> Chris.

Thanks for your interest, it's good to have someone else testing the
install process, and better yet when I get to releasing .debs...

Elmo

Re: [PyWM-talk] Stuck with the install

[<el...@ji...>]

cga wrote:

> I'm trying to install pywm on debian sarge. I did an 'apt-get install
> flwm'.. created the /usr/local/lib/python.2.3.5/site-packages/flwm
> directory.. copied the flwm executable and the
> ~/pywm.0.1.1/src-python/* files to this directory.. set my .xinitrc
> file to exec pywm-run.. cd'd to the ~/pywm directory.. started X via
> startx from a console and I do get to the chooser alright but there's
> nothing to choose from. I'm probably missing something - regarding
> this 'pyrex' thing I would imagine.. but I don't know what. I've taken
> a  look at the launcher - pywm.py.. but since I am totally unfamiliar
> with Tk I haven't been able to figure out what the chooser should be
> displaying. I noticed that it did create the ~/.pywm directory but
> failed to populate it - iow .. it is empty..
>
> Please advise.
>
Well, I don't know wether you looked in the README and or the INSTALL
files (wich you should), but here are the parts that are applicable:

"
*** INSTALLING BINARY PACKAGE

 * There is no binary offered in this package (with the formerly
distributed binary,
   there's a version mismatch with current python, f.ex.), so building
   from source is encouraged. I'll gladly help, or might even
   send a binary if asked nicely=). If you'd like to try
   the old binary, it's in the original 0.1 release (caution: the
instructions below
   might not be correct).
...
"

So you do need libfltk1.1-dev and python-pyrex(this might not be enough,
we'll see), but you have no use for flwm(if you wan't a prebuilt binary,
that's not the place where to look for it).

"
...
If you have successfully [built and] installed FLTK, you
can log in as root and type:
   
    make install (or 'python setup.py build', and link to
    it by means of a site.py, etc)

If the make completes successfully, you will have:
 
  * The PYWM launcher utility, installed as
    /usr/bin/pywm-run.py
    This program pops up a window of available window
    manager scripts, as well as an xterm fallback
   
  * The directory 'pywm' installed in your Python
    site-packages directory. Note that within this pywm
    directory is a copy of the examples directory.
...
"

This should work, but tell me if the instructions aren't clear
enough(they aren't complete nor completely right, I have to work on that).

[PyWM-talk] Stuck with the install

[cga <cg...@gm...>]

I'm trying to install pywm on debian sarge. I did an 'apt-get install 
flwm'.. created the /usr/local/lib/python.2.3.5/site-packages/flwm 
directory.. copied the flwm executable and the ~/pywm.0.1.1/src-python/* 
files to this directory.. set my .xinitrc file to exec pywm-run.. cd'd 
to the ~/pywm directory.. started X via startx from a console and I do 
get to the chooser alright but there's nothing to choose from. I'm 
probably missing something - regarding this 'pyrex' thing I would 
imagine.. but I don't know what. I've taken a  look at the launcher - 
pywm.py.. but since I am totally unfamiliar with Tk I haven't been able 
to figure out what the chooser should be displaying. I noticed that it 
did create the ~/.pywm directory but failed to populate it - iow .. it 
is empty..

Please advise.

[PyWM-talk] test

[<el...@ji...>]

test