Paulownia, aka StumpWM 2.0.0

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

Paulownia, aka StumpWM 2.0.0

David Bjergaard-2
Hi All,

I've started a separate repo on the github's stumpwm organization named
paulownia.  This is the code-name I've chosen for StumpWM 2.0.0.  The design
goals etc are listed there.  In short:
1. Use as much of stumpwm as possible
2. Separate out parts of stumpwm into their own packages (distributed via
   quicklisp)
3. Project out clx/xlib parts of the code so that code is less coupled to the
   underlying display server (eye towards wayland, mir, dare I say MacOS/Windows)

The repo has a CI set up to run test with prove and roswell, this already
simplifies the build process for various lisps since roswell provides a uniform
interface for building images.

So what I need input from this list is on:
1. What's broken (in your mind)?
2. What can be moved into its own package (cl-xkeysym has already been made
   external) or can depend on exernal packages?
3. What are the clear conceptual breaks in the stumpwm ecosystem?
4. What should be removed or reworked completely?

Let me answer with my opinions for each one:
1. Internationalized input.  This means handling non-ascii characters in dialog
   boxes and responding to them being bound to keys.
2. Modeline, keysym (in fact all the the code "(kbd ...)" touches),
   debugging/logging can be moved externally, time.lisp, timers in stumpwm.lisp,
   module.lisp, the info manual can be moved to external programs
3. I see this falling into three categories:
   - Backend :: anything that interacts with clx or the xlib package
   - Core :: the parts that define the window model, and primatives, kbd stuff
   - Gui :: the stuff that draws the mode-line, takes user input and echos it
            back, and draws the help window/welcome screen
I would like to restructure it so that you could swap out one gui toolkit for
another.  Specifically, if someone wrote one that used cl-gtk-cffi and another
that used qtools, they should still work with the rest of stumpwm.  The same
goes for the backend parts of the code.  For now and the foreseeable future, the
only backend we'll have to support is clx since wayland and mir have X11 servers
implemented in them.

4. I think the support for floats should be dropped initially and re-worked in a
   different way.  If we're going to have floats, I envision being able to
   toggle windows between being tiled and floating on top of the tiles.  In a
   sense making the float group sit on top of the tiled group and being able to
   move windows between the two as needed.  This would ideally be done
   automagically for dialog boxes that often are placed in awkward positions
   when tiled.
   
I'm sure some of what I plan to do will be controversial or will break someone's
preferred method of interacting with stumpwm.  If that's the case, please
continue to use the 1.0 line.  If something is easy to merge back to 1.0 and
doesn't change the user experience I will.  I will also continue to accept
contrib modules and bug fixes for stumpwm 1.0, so it will continue to be
maintained.

Paulownia is an experiment to see if I can re-write stumpwm they way I want it
while fixing some of it warts along the way.  I don't know how far I'll get or
if it will be a success, but it should be an adventure and I'll be a better
maintainer after auditing the current stumpwm codebase in detail.

Cheers,

    Dave

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

Paulownia, aka StumpWM 2.0.0

Michael Raskin-3
>4. I think the support for floats should be dropped initially and re-worked in a
>   different way.  If we're going to have floats, I envision being able to
>   toggle windows between being tiled and floating on top of the tiles.  In a
>   sense making the float group sit on top of the tiled group and being able to
>   move windows between the two as needed.  This would ideally be done
>   automagically for dialog boxes that often are placed in awkward positions
>   when tiled.

If we discuss changing the grup logic, maybe we will end up
reconsidering the granularity of group choice?

I.e., is it worth supporting per-monitor groups? Is it worth supporting
multiple «pseudo-monitors» inside a single physical display? What _is_
a group, what is tied to it (windows has a single group?) and what are
its immutable characteristics (if we have per-monitor groups, what to do
with frame splits, if there are any)? Is a floating group always
entire-workspace? Is a floating group tied to underlying tiling group?

My setup via frame tagging is most close to 4 no-permanent-splits
«groups» inside a single physical display, and one or four more when
I attach an external display to my notebook.

Should I describe more details about its usage as a use case or is it
too weird to consider at the current stage?




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

Re: Paulownia, aka StumpWM 2.0.0

Mikael Jansson-2


My setup via frame tagging is most close to 4 no-permanent-splits
«groups» inside a single physical display, and one or four more when
I attach an external display to my notebook.

Is this similar to having one "sticky" group that's always on the one same head (= display), and have all other displays have changing groups?
That's one feature I'd really like. IRC/e-mail/etc always open on one monitor, then the other content changes depending on which group I have active.

- Micke 

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

Re: Paulownia, aka StumpWM 2.0.0

David Bjergaard
In reply to this post by Michael Raskin-3

Michael Raskin <[hidden email]> writes:

>>4. I think the support for floats should be dropped initially and re-worked in a
>>   different way.  If we're going to have floats, I envision being able to
>>   toggle windows between being tiled and floating on top of the tiles.  In a
>>   sense making the float group sit on top of the tiled group and being able to
>>   move windows between the two as needed.  This would ideally be done
>>   automagically for dialog boxes that often are placed in awkward positions
>>   when tiled.
>
> If we discuss changing the grup logic, maybe we will end up
> reconsidering the granularity of group choice?
>
> I.e., is it worth supporting per-monitor groups? Is it worth supporting
> multiple «pseudo-monitors» inside a single physical display? What _is_
> a group, what is tied to it (windows has a single group?) and what are
> its immutable characteristics (if we have per-monitor groups, what to do
> with frame splits, if there are any)? Is a floating group always
> entire-workspace? Is a floating group tied to underlying tiling group?
>
> My setup via frame tagging is most close to 4 no-permanent-splits
> «groups» inside a single physical display, and one or four more when
> I attach an external display to my notebook.
>
> Should I describe more details about its usage as a use case or is it
> too weird to consider at the current stage?
>
Hi Michael,

This is a brainstorming thread, so please elaborate an enumerate.  I'm not
promising it'll end up in the final result.

More than one request has been made to make groups per physical screen.  I quite
like the way Stump does it now, so I (personally) would want to make it possible
to achieve what is already there.  For the sake of consistency in our discussion
lets define some terms :
- screen: a virtual space within which frames can be drawn
- head: a physical monitor
- frame: a boundary within which a window is drawn
- group: a list of windows to be drawn in frames

To summarize them a bit, a screen can be drawn across multiple heads.  The frame
is a partition of a screen within which a window can be drawn.  A group is a
collection of windows that will be drawn across the screen within the frames.  

In terms of reasonable vocabulary, the only word that makes sense is frame, ie
the boundary of a window.  Groups are what people typically think of as
workspaces, and I always have to look up how stumpwm treats heads vs screens.

An obvious candidate to lower the barrier for entry (and maintenance) would be
to rename these things, calling a head a monitor, a group a workspace, and
either keeping screen or renaming it a canvas.

    David

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

Re: Paulownia, aka StumpWM 2.0.0

Michael Raskin-3
In reply to this post by Mikael Jansson-2
>> My setup via frame tagging is most close to 4 no-permanent-splits
>> «groups» inside a single physical display, and one or four more when
>> I attach an external display to my notebook.
>>
>
>Is this similar to having one "sticky" group that's always on the one same
>head (= display), and have all other displays have changing groups?
>That's one feature I'd really like. IRC/e-mail/etc always open on one
>monitor, then the other content changes depending on which group I have
>active.

Yes, just a bit more generic (and works on top of current StumpWM).

One of them is for my xterm-based modeline, one for notifications, one
is often IM+email (very like your sticky group).

Sometimes I switch to code+view (LaTeX+PDF or backend+website) usage of
the two large areas.




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

Re: Paulownia, aka StumpWM 2.0.0

Mikael Jansson-2

On Wed, Oct 7, 2015 at 3:16 PM, Michael Raskin <[hidden email]> wrote:
>> My setup via frame tagging is most close to 4 no-permanent-splits
>> «groups» inside a single physical display, and one or four more when
>> I attach an external display to my notebook.
>>
>
>Is this similar to having one "sticky" group that's always on the one same
>head (= display), and have all other displays have changing groups?
>That's one feature I'd really like. IRC/e-mail/etc always open on one
>monitor, then the other content changes depending on which group I have
>active.

Yes, just a bit more generic (and works on top of current StumpWM).

One of them is for my xterm-based modeline, one for notifications, one
is often IM+email (very like your sticky group).

Sometimes I switch to code+view (LaTeX+PDF or backend+website) usage of
the two large areas.


Right. 

I both like the current way, where the group is at top-level, and the other way where I'd have something like nested groups.

To be clear on what I mean, this is hopefully a better explanation:

Given
A, B = monitors
[A], [B] = the frame on an empty head/monitor, i.e. with no splitted frames, on monitors A and B.
{[A] [B]} = group containing said frames
{X}+ = group that's stuck to a head

Then {[A] [B]} is what we have now, and { {[A]}+ {[B]} } is what I'd like to have. Then a command to unstick a group to a head, which causes a merge of {[A]} + {[B]} into {[A] [B]}.

- Micke




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

Re: Paulownia, aka StumpWM 2.0.0

Michael Raskin-3
In reply to this post by David Bjergaard
>
>Michael Raskin <[hidden email]> writes:
>
>>>4. I think the support for floats should be dropped initially and re-worked in a
>>>   different way.  If we're going to have floats, I envision being able to
>>>   toggle windows between being tiled and floating on top of the tiles.  In a
>>>   sense making the float group sit on top of the tiled group and being able to
>>>   move windows between the two as needed.  This would ideally be done
>>>   automagically for dialog boxes that often are placed in awkward positions
>>>   when tiled.
>>
>> If we discuss changing the grup logic, maybe we will end up
>> reconsidering the granularity of group choice?
>>
>> I.e., is it worth supporting per-monitor groups? Is it worth supporting
>> multiple «pseudo-monitors» inside a single physical display? What _is_
>> a group, what is tied to it (windows has a single group?) and what are
>> its immutable characteristics (if we have per-monitor groups, what to do
>> with frame splits, if there are any)? Is a floating group always
>> entire-workspace? Is a floating group tied to underlying tiling group?
>>
>> My setup via frame tagging is most close to 4 no-permanent-splits
>> «groups» inside a single physical display, and one or four more when
>> I attach an external display to my notebook.
>>
>> Should I describe more details about its usage as a use case or is it
>> too weird to consider at the current stage?
>>
>Hi Michael,
>
>This is a brainstorming thread, so please elaborate an enumerate.  I'm not
>promising it'll end up in the final result.
>
>More than one request has been made to make groups per physical screen.  I quite
>like the way Stump does it now, so I (personally) would want to make it possible
>to achieve what is already there.  For the sake of consistency in our discussion
>lets define some terms :
>- screen: a virtual space within which frames can be drawn
>- head: a physical monitor
>- frame: a boundary within which a window is drawn
>- group: a list of windows to be drawn in frames
>
>To summarize them a bit, a screen can be drawn across multiple heads.  The frame
>is a partition of a screen within which a window can be drawn.  A group is a
>collection of windows that will be drawn across the screen within the frames.  
>
>In terms of reasonable vocabulary, the only word that makes sense is frame, ie
>the boundary of a window.  Groups are what people typically think of as
>workspaces, and I always have to look up how stumpwm treats heads vs screens.
>
>An obvious candidate to lower the barrier for entry (and maintenance) would be
>to rename these things, calling a head a monitor, a group a workspace, and
>either keeping screen or renaming it a canvas.

My setup is as follows:

I have a canvas consisting of one laptop monitor and sometimes I add one
more external monitor to this canvas.

I have 4 main frames in the main monitor, and 1 or 4 frames in the
external monitor. Each of the 4 or 5 or 8 frames gets a window set
independently.

When the external monitor is split, it is split in 4 equal parts.

The main monitor has two very narrow frames at the bottom.

The very bottom is a one-line xterm with a pseudo-modeline (there is
a complicated shell script, so not a StumpWM modeline). The next frame
switches between 0 height and one-line urxvt — it displays notifications
like emails from whitelisted senders. The rest of the screen is split
into two full-height frames (the rightmost one has the width of
a 81-symbol xterm window, the leftmost one is all the remaining space).

I often use the rightmost frame for IM or email. Sometimes for some
reference materials.

I also often put code in one half and the result in the other half.
It can be LaTeX+PDF or backend code+website in a browser. On a FullHD
monitor marginal utility of an additional small window is almost always
more than marginal utility of extra horizontal space.

Of course, sometimes there are two terminals or something like that.

My frame tagging setup does allow me to create temporary splits inside
one of the frames without losing the division into «right side» and
«left side» window sets. I mostly use my predefined two big frames,
though.

One more usecase when independent window set switching is very
convenient is driving a (physical) projector/beamer but still having
ability to bring up whatever I need on my laptop monitor.




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

Re: Paulownia, aka StumpWM 2.0.0

sam kleinman
In reply to this post by Michael Raskin-3

On Wednesday, October 07 2015, 09:01:50, Michael Raskin wrote:

>>4. I think the support for floats should be dropped initially and re-worked in a
>>   different way.  If we're going to have floats, I envision being able to
>>   toggle windows between being tiled and floating on top of the tiles.  In a
>>   sense making the float group sit on top of the tiled group and being able to
>>   move windows between the two as needed.  This would ideally be done
>>   automagically for dialog boxes that often are placed in awkward positions
>>   when tiled.
>
> If we discuss changing the grup logic, maybe we will end up
> reconsidering the granularity of group choice?
>
> I.e., is it worth supporting per-monitor groups? Is it worth supporting
> multiple «pseudo-monitors» inside a single physical display? What _is_
> a group, what is tied to it (windows has a single group?) and what are
> its immutable characteristics (if we have per-monitor groups, what to do
> with frame splits, if there are any)? Is a floating group always
> entire-workspace? Is a floating group tied to underlying tiling group?
>
> My setup via frame tagging is most close to 4 no-permanent-splits
> «groups» inside a single physical display, and one or four more when
> I attach an external display to my notebook.
>
> Should I describe more details about its usage as a use case or is it
> too weird to consider at the current stage?

I think the fact that a single group spans *all* heads and it's not
possible to switch between groups on a per-monitor basis is a leading
cause of confusion (based on my experience of lurking/helping out in the
IRC room,) and would defiantly be a great boon to the software.

There are a lot of design questions around interface, and I think the
current functionality might be desirable for some users.

I think that Michael's tag-based approach to window<->frame association
has a bit too much cognitive overhead (at least for me,) and--while this
is more general than this specific feature--I think it'll be important
to continue to use emacs and screen as a guide for interface and user
interaction models, even if we do a lot of clean up and refactoring
around the edges.

Cheers,
sam

--
Sam Kleinman (tychoish):
 - [hidden email]
 - tychoish <http://tychoish.com/>
 "don't get it right, get it written" -- james thurber

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

Re: Paulownia, aka StumpWM 2.0.0

Michael Raskin-3
>> My setup via frame tagging is most close to 4 no-permanent-splits
>> «groups» inside a single physical display, and one or four more when
>> I attach an external display to my notebook.
>>
>> Should I describe more details about its usage as a use case or is it
>> too weird to consider at the current stage?
>
>I think the fact that a single group spans *all* heads and it's not
>possible to switch between groups on a per-monitor basis is a leading
>cause of confusion (based on my experience of lurking/helping out in the
>IRC room,) and would defiantly be a great boon to the software.

And with modern widescreens, even a sub-monitor groups make some sense.

>There are a lot of design questions around interface, and I think the
>current functionality might be desirable for some users.
>
>I think that Michael's tag-based approach to window<->frame association
>has a bit too much cognitive overhead (at least for me,) and--while this

Yes.

Actually, most of the time I use it as an underlying layer for trivial
scripts that reflect my actual intent by auto-tagging and chosing
frequently-used tags.

>is more general than this specific feature--I think it'll be important
>to continue to use emacs and screen as a guide for interface and user
>interaction models, even if we do a lot of clean up and refactoring
>around the edges.

Also, we should remember that screen has some annoying limitations.

Maybe looking to tmux is also a good idea…




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

Re: Paulownia, aka StumpWM 2.0.0

Alberto Otero de la Roza
In reply to this post by David Bjergaard-2
Hi all,

For my part, I'd like to put in a good word for floating groups. I
normally use stumpwm on a single monitor, and most of the time it is
very comfortable to use. However, there are times when along comes a
program that likes spamming a host of tiny dialogs, windows, toolbars
and whatnot. In that case, it is nice having the option of switching
to a non-tiled group to deal with that program, and kill it when I'm
done. Current support for floating windows is a bit rudimentary (for
instance, there is no maximize, minimize, restore, and always-on-top
options) so it would be nice if it were improved or at least existent
in 2.0.

Also, is there any way to provide better support for
very-high-resolution monitors (e.g. 3200x1800)? Other WMs have made
good progress towards providing a way to scale text, icons,
etc. consistently.

Best,

Alberto

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