Revitalizing StumpWM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Revitalizing StumpWM

David Bjergaard
Hi all,

I know there's a handful (fistful?) of people who are happily using
stumpwm, but the git repo has been stagnant for a long time.  Shawn has
added me as a maintainer on github and I'm working through the open pull
requests as I have time.

While my experience hacking a window-manager is relatively limited, I
have some ideas that may add some new life to StumpWM.  

First and foremost, I want to reorganize some of the information on the
wiki so that it matches the state of the repo.  This didn't happen in
the since the wiki was imported from OddMuse two years ago.  

Second, I want to get an idea for which bugs are still out in the wild
and which were fixed but never closed.  To this end, I want the
bug/issue tracking to happen on github.  If you've filed a bug report in
the past and it hasn't been addressed please open a new one on github.
I will be removing the Bugs portion of the wiki and adding instructions
on how to file bug reports when I get time.

Once we get any outstanding bugs squashed, I want to release a 0.98
version, as the best, stable representation of the current head of git.

After that we can start active development again.  I would like to
change the way plugins are organized, as well as some simple
improvements to the build-system (including a bootstrap script to
install quicklisp and stumpwm's prereq's for instance)

Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
modules that various hackers have contributed in the contrib/
directory.  I would like to take a page from emacs' contribution
management and have each plugin author maintain his/her own code and
we'll include a pointer to it from the wiki.  This way there's no issues
with contrib requests not getting pulled in, and the energy barrier for
writing a plugin will be much lower.  I'm not (yet) envisioning
something like package.el, that's too much right now. Eventually it
would be nice to have a script or chunk of code that could iterate over
the contrib repositories and pull in the latest changes.

What do you guys think? Please let me know how this sounds or if you
have any ideas on what the future of StumpWM should be.  Also, please
know that pull requests are *very* welcome. I will do my best to respond
(either with a merge) or questions quickly.

Cheers,

    Dave
Hi all,

I know there's a handful (fistful?) of people who are happily using
stumpwm, but the git repo has been stagnant for a long time.  Shawn has
added me as a maintainer on github and I'm working through the open pull
requests as I have time.

While my experience hacking a window-manager is relatively limited, I
have some ideas that may add some new life to StumpWM.  

First and foremost, I want to reorganize some of the information on the
wiki so that it matches the state of the repo.  This didn't happen in
the since the wiki was imported from OddMuse two years ago.  

Second, I want to get an idea for which bugs are still out in the wild
and which were fixed but never closed.  To this end, I want the
bug/issue tracking to happen on github.  If you've filed a bug report in
the past and it hasn't been addressed please open a new one on github.
I will be removing the Bugs portion of the wiki and adding instructions
on how to file bug reports when I get time.

Once we get any outstanding bugs squashed, I want to release a 0.98
version, as the best, stable representation of the current head of git.

After that we can start active development again.  I would like to
change the way plugins are organized, as well as some simple
improvements to the build-system (including a bootstrap script to
install quicklisp and stumpwm's prereq's for instance)

Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
modules that various hackers have contributed in the contrib/
directory.  I would like to take a page from emacs' contribution
management and have each plugin author maintain his/her own code and
we'll include a pointer to it from the wiki.  This way there's no issues
with contrib requests not getting pulled in, and the energy barrier for
writing a plugin will be much lower.  I'm not (yet) envisioning
something like package.el, that's too much right now. Eventually it
would be nice to have a script or chunk of code that could iterate over
the contrib repositories and pull in the latest changes.

What do you guys think? Please let me know how this sounds or if you
have any ideas on what the future of StumpWM should be.  Also, please
know that pull requests are *very* welcome. I will do my best to respond
(either with a merge) or questions quickly.

Cheers,

    Dave

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

yggdrasil
Hi David,

Thanks for taking the initiative volunteering some TLC to stumpwm! I am
sorry not being able to contribute in a more proactive way than lauding
your initiative, with no bugs filed and no code to pull. As I can't see
myself using another WM all efforts to maintain and improve it is very
much appreciated.

Alex Kost posted some code for floating groups on 2/1 that I am sure
would be useful for floating groups though, although I haven't tested it
myself. Floating groaps in stumpwm could surely use some more tweaks,
but I use it rarely, and understandably this may not be a priority for a
tiling WM. Thinking of it, the resizing behaviour is a bit funny
(0.9.7-80), in that the cursor "jumps" to the corner when resizing. Also
the focus setting of windows would be nice (I think Alex's patch deals
with this), but more of a convenience function.

Feel free to ignore my comments, the main point I want to convey is a
big thanks to you, Shawn, and all other contributors for the efforts!

/Johnny

David Bjergaard <[hidden email]> writes:

> Hi all,
>
> I know there's a handful (fistful?) of people who are happily using
> stumpwm, but the git repo has been stagnant for a long time.  Shawn has
> added me as a maintainer on github and I'm working through the open pull
> requests as I have time.
>
> While my experience hacking a window-manager is relatively limited, I
> have some ideas that may add some new life to StumpWM.  
>
> First and foremost, I want to reorganize some of the information on the
> wiki so that it matches the state of the repo.  This didn't happen in
> the since the wiki was imported from OddMuse two years ago.  
>
> Second, I want to get an idea for which bugs are still out in the wild
> and which were fixed but never closed.  To this end, I want the
> bug/issue tracking to happen on github.  If you've filed a bug report in
> the past and it hasn't been addressed please open a new one on github.
> I will be removing the Bugs portion of the wiki and adding instructions
> on how to file bug reports when I get time.
>
> Once we get any outstanding bugs squashed, I want to release a 0.98
> version, as the best, stable representation of the current head of git.
>
> After that we can start active development again.  I would like to
> change the way plugins are organized, as well as some simple
> improvements to the build-system (including a bootstrap script to
> install quicklisp and stumpwm's prereq's for instance)
>
> Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
> WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
> modules that various hackers have contributed in the contrib/
> directory.  I would like to take a page from emacs' contribution
> management and have each plugin author maintain his/her own code and
> we'll include a pointer to it from the wiki.  This way there's no issues
> with contrib requests not getting pulled in, and the energy barrier for
> writing a plugin will be much lower.  I'm not (yet) envisioning
> something like package.el, that's too much right now. Eventually it
> would be nice to have a script or chunk of code that could iterate over
> the contrib repositories and pull in the latest changes.
>
> What do you guys think? Please let me know how this sounds or if you
> have any ideas on what the future of StumpWM should be.  Also, please
> know that pull requests are *very* welcome. I will do my best to respond
> (either with a merge) or questions quickly.
>
> Cheers,
>
>     Dave
> Hi all,
>
> I know there's a handful (fistful?) of people who are happily using
> stumpwm, but the git repo has been stagnant for a long time.  Shawn has
> added me as a maintainer on github and I'm working through the open pull
> requests as I have time.
>
> While my experience hacking a window-manager is relatively limited, I
> have some ideas that may add some new life to StumpWM.  
>
> First and foremost, I want to reorganize some of the information on the
> wiki so that it matches the state of the repo.  This didn't happen in
> the since the wiki was imported from OddMuse two years ago.  
>
> Second, I want to get an idea for which bugs are still out in the wild
> and which were fixed but never closed.  To this end, I want the
> bug/issue tracking to happen on github.  If you've filed a bug report in
> the past and it hasn't been addressed please open a new one on github.
> I will be removing the Bugs portion of the wiki and adding instructions
> on how to file bug reports when I get time.
>
> Once we get any outstanding bugs squashed, I want to release a 0.98
> version, as the best, stable representation of the current head of git.
>
> After that we can start active development again.  I would like to
> change the way plugins are organized, as well as some simple
> improvements to the build-system (including a bootstrap script to
> install quicklisp and stumpwm's prereq's for instance)
>
> Shawn's philosophy for StumpWM is a "everything-and-the-kitchen-sink
> WM,"  or "the emacs of WMs." There's a lot of (under advertised) contrib
> modules that various hackers have contributed in the contrib/
> directory.  I would like to take a page from emacs' contribution
> management and have each plugin author maintain his/her own code and
> we'll include a pointer to it from the wiki.  This way there's no issues
> with contrib requests not getting pulled in, and the energy barrier for
> writing a plugin will be much lower.  I'm not (yet) envisioning
> something like package.el, that's too much right now. Eventually it
> would be nice to have a script or chunk of code that could iterate over
> the contrib repositories and pull in the latest changes.
>
> What do you guys think? Please let me know how this sounds or if you
> have any ideas on what the future of StumpWM should be.  Also, please
> know that pull requests are *very* welcome. I will do my best to respond
> (either with a merge) or questions quickly.
>
> Cheers,
>
>     Dave
>
> _______________________________________________
> Stumpwm-devel mailing list
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

Eric Abrahamsen-2
In reply to this post by David Bjergaard
David Bjergaard <[hidden email]> writes:

> Hi all,
>
> I know there's a handful (fistful?) of people who are happily using
> stumpwm, but the git repo has been stagnant for a long time.  Shawn has
> added me as a maintainer on github and I'm working through the open pull
> requests as I have time.
>
> While my experience hacking a window-manager is relatively limited, I
> have some ideas that may add some new life to StumpWM.  

Great news, and thanks very much for doing this! More active development
is a good thing (though I have to admit I'm fairly content with it
as-is).

My two cents is to consider merging the truetype-enabled StumpWM fork.
Unless there's a reason why this is a shaky or not widely-compatible
implementation (and I wouldn't know if it was), it seems like a very
reasonable thing to have as a core part of StumpWM.

Thanks again!
Eric


https://github.com/filonenko-mikhail/stumpwm.git


_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

Michael Raskin-3
>David Bjergaard <[hidden email]> writes:
>
>> Hi all,
>>
>> I know there's a handful (fistful?) of people who are happily using
>> stumpwm, but the git repo has been stagnant for a long time.  Shawn has
>> added me as a maintainer on github and I'm working through the open pull
>> requests as I have time.
>>
>> While my experience hacking a window-manager is relatively limited, I
>> have some ideas that may add some new life to StumpWM.  
>
>Great news, and thanks very much for doing this! More active development
>is a good thing (though I have to admit I'm fairly content with it
>as-is).
>
>My two cents is to consider merging the truetype-enabled StumpWM fork.
>Unless there's a reason why this is a shaky or not widely-compatible
>implementation (and I wouldn't know if it was), it seems like a very
>reasonable thing to have as a core part of StumpWM.
>
>Thanks again!
>Eric
>
>https://github.com/filonenko-mikhail/stumpwm.git

As a user of this fork:

1. It would be very nice to have this in core StumpWM
2. This brings some dependencies into StumpWM (right now StumpWM has
just one external dependency: CL-PPCRE).
3. Text drawing is slower with this fork, especially when some character
is drawn after it is purged from cache as too old. As far as
I understand this doesn't affect fixed fonts, but it is something to
document…




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

David Bjergaard
Hi,

Comments inline:
Michael Raskin <[hidden email]> writes:
[snip]

>>My two cents is to consider merging the truetype-enabled StumpWM fork.
>>Unless there's a reason why this is a shaky or not widely-compatible
>>implementation (and I wouldn't know if it was), it seems like a very
>>reasonable thing to have as a core part of StumpWM.
>>
>>Thanks again!
>>Eric
>>
>>https://github.com/filonenko-mikhail/stumpwm.git
>
> As a user of this fork:
>
> 1. It would be very nice to have this in core StumpWM
> 2. This brings some dependencies into StumpWM (right now StumpWM has
> just one external dependency: CL-PPCRE).
> 3. Text drawing is slower with this fork, especially when some character
> is drawn after it is purged from cache as too old. As far as
> I understand this doesn't affect fixed fonts, but it is something to
> document…
Can you explain point 3?  I'm happy to merge this with the core, I just
want to understand exactly what you mean. I'm actually using this
version on one of my computers now.  

Cheers,

    Dave

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

Michael Raskin-3
>> 3. Text drawing is slower with this fork, especially when some character
>> is drawn after it is purged from cache as too old. As far as
>> I understand this doesn't affect fixed fonts, but it is something to
>> document…
>Can you explain point 3?  I'm happy to merge this with the core, I just
>want to understand exactly what you mean. I'm actually using this
>version on one of my computers now.  

I have a custom command (listing all tags of all windows) that produces
a lot of text. If I run it twice, second run is almost always
instantaneous. But sometimes the first run of that command takes a few
seconds. Under adverse conditions it can even take ten seconds to draw
the message.




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

David Bjergaard
Michael Raskin <[hidden email]> writes:

>>> 3. Text drawing is slower with this fork, especially when some character
>>> is drawn after it is purged from cache as too old. As far as
>>> I understand this doesn't affect fixed fonts, but it is something to
>>> document…
>>Can you explain point 3?  I'm happy to merge this with the core, I just
>>want to understand exactly what you mean. I'm actually using this
>>version on one of my computers now.  
>
> I have a custom command (listing all tags of all windows) that produces
> a lot of text. If I run it twice, second run is almost always
> instantaneous. But sometimes the first run of that command takes a few
> seconds. Under adverse conditions it can even take ten seconds to draw
> the message.
If I'm following, users of bitmap fonts won't see a difference, but if
you choose to render truetype (TT) fonts then you may see a delay if stump
tries to dump a lot of text on screen?

The takeaway is:
1. If this is reintegrated, users will get the same old
   performance "out of the box"
2. If you choose to use TT fonts, you may see performance impacts when
   dumping large chunks of text to the screen

Michael, are you aware of why this is the case? Is it an issue that can
be fixed in StumpWM, or is it in the TT rendering library?  It would be
helpful to have an example command that just dumped a grid of characters
so that we could ensure that there isn't something funky going on
elsewhere.

Cheers,

    Dave



_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

Michael Raskin-3
>Michael Raskin <[hidden email]> writes:
>
>>>> 3. Text drawing is slower with this fork, especially when some character
>>>> is drawn after it is purged from cache as too old. As far as
>>>> I understand this doesn't affect fixed fonts, but it is something to
>>>> document…
>>>Can you explain point 3?  I'm happy to merge this with the core, I just
>>>want to understand exactly what you mean. I'm actually using this
>>>version on one of my computers now.  
>>
>> I have a custom command (listing all tags of all windows) that produces
>> a lot of text. If I run it twice, second run is almost always
>> instantaneous. But sometimes the first run of that command takes a few
>> seconds. Under adverse conditions it can even take ten seconds to draw
>> the message.
>If I'm following, users of bitmap fonts won't see a difference, but if
>you choose to render truetype (TT) fonts then you may see a delay if stump
>tries to dump a lot of text on screen?

I didn't test it well, but apparently fixed font works fine.

>The takeaway is:
>1. If this is reintegrated, users will get the same old
>   performance "out of the box"
>2. If you choose to use TT fonts, you may see performance impacts when
>   dumping large chunks of text to the screen
>
>Michael, are you aware of why this is the case? Is it an issue that can
>be fixed in StumpWM, or is it in the TT rendering library?  It would be
>helpful to have an example command that just dumped a grid of characters
>so that we could ensure that there isn't something funky going on
>elsewhere.

I feel it is a problem with clx-truetype, but I am not completely sure.




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Revitalizing StumpWM

Michael Filonenko
Hi all.

clx-truetype performance leaks are bitmap caching at client side, instead of server side and kerning.





On Tue, Jan 28, 2014 at 11:26 PM, Michael Raskin <[hidden email]> wrote:
>Michael Raskin <[hidden email]> writes:
>
>>>> 3. Text drawing is slower with this fork, especially when some character
>>>> is drawn after it is purged from cache as too old. As far as
>>>> I understand this doesn't affect fixed fonts, but it is something to
>>>> document…
>>>Can you explain point 3?  I'm happy to merge this with the core, I just
>>>want to understand exactly what you mean. I'm actually using this
>>>version on one of my computers now.
>>
>> I have a custom command (listing all tags of all windows) that produces
>> a lot of text. If I run it twice, second run is almost always
>> instantaneous. But sometimes the first run of that command takes a few
>> seconds. Under adverse conditions it can even take ten seconds to draw
>> the message.
>If I'm following, users of bitmap fonts won't see a difference, but if
>you choose to render truetype (TT) fonts then you may see a delay if stump
>tries to dump a lot of text on screen?

I didn't test it well, but apparently fixed font works fine.

>The takeaway is:
>1. If this is reintegrated, users will get the same old
>   performance "out of the box"
>2. If you choose to use TT fonts, you may see performance impacts when
>   dumping large chunks of text to the screen
>
>Michael, are you aware of why this is the case? Is it an issue that can
>be fixed in StumpWM, or is it in the TT rendering library?  It would be
>helpful to have an example command that just dumped a grid of characters
>so that we could ensure that there isn't something funky going on
>elsewhere.

I feel it is a problem with clx-truetype, but I am not completely sure.




_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel



--
With best regards, Michael Filonenko

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel