A library for writing an X11 tiling window manager
MIT License
Bot releases are visible (Hide)
Bug fixes
Published by sminez over 1 year ago
Full Changelog can be viewed here: https://github.com/sminez/penrose/compare/0.3.2...0.3.3
Published by sminez over 1 year ago
There's a reasonable amount in this one but the main bugs that have been squashed are:
manage_existing_clients
now correctly avoids tiling windows that should be ignoredNew features:
DMenu
helper now supports triggering dmenu-rs
as well as the default suckless versionThis also includes an update of the dependency on x11rb
to 0.11 from @psychon https://github.com/sminez/penrose/pull/250
Published by sminez almost 2 years ago
The kill_client
method on StackSet was only removing the internal state, not shutting down the client on the X side. This is a pretty unfortunate bug so I'm pushing the fix as a new version immediately.
Published by sminez almost 2 years ago
This is a near total rewrite of the previous design to provide a nicer API to work with going forward. An overview of the new design is published to GitHub pages here and the new crate docs are now live on docs.rs.
NOTE: Some (but not all) of the functionality from the old
contrib
module has been ported over to the new API. If something you were using is not there yet please raise an issue and I can take a look at getting it re-implemented. I didn't make use of everything that was available in my day-to-day set up so I'll need some help verifying that the behaviour is as people expect!
Published by sminez almost 2 years ago
rewrite
branch is being merged to the develop
⚠️Users pulling this repo directly from the mainline branch will see this as a breaking change
The original API of penrose was written fairly quickly(!) and has a number of issues that make future development difficult:
dwm
code base lead to a very C like APIA near total rewrite for v0.3
is reaching a usable state which moves over to an API that is more suited for ongoing development and extension by users of the crate. In particular the APIs are now designed with composition in mind as a rich set of primatives and a clear split between "pure" logical operations on the internal state and code that then updates things on the X side based on diffs of that pure state.
🏷️ Please pin your usage of penrose to this tag if you are intending on making use of the original penrose API but be aware that there will be no more development taking place on this version of the code.
The rewrite
branch is being merged to mainline following the creation of this EOL release and is now in a usable state. I've been using it as my daily driver for a few weeks now and it is relatively stable to live in so long as you are only making use of the top level APIs shown in the examples directory.
🐛 That said, there are bugs. There are some issues around tracking mouse based focus changes in a multi-monitor set up and I suspect that it will be easier than it should be to shoot yourself in the foot if you try something clever beyond what is shown in the current examples.
I am planning on writing up the docs and more examples for the API now that it is stablising but for now please be aware that I am making frequent changes to APIs in order to address issues as they crop up. If you are interested in taking things for a spin and providing feedback then please do! Just be aware that I am not yet aiming for stability.
There are a couple of final high profile bugs / behaviours that I want to correct before pushing this live to crates.io. Once those are addressed I'll be publishing a 0.3.0
version to crates which will mark the new stable API.
👋 Happy window managing!
Published by sminez almost 3 years ago
Bug fixes and improved test coverage.
Published by sminez over 3 years ago
The following is a high level overview of the main user facing changes to the
Penrose API when updating your 0.1.X
config to 0.2.0
. For the most part,
the compiler should guide you through the changes but it is worthwhile reading
through the changes that follow in order to guide you through what you need to
do.
There are multiple other internal changes, refactors and additions that can all
be found in the documentation, but these are the main breaking changes that
are likely to leave you scratching your head if you just trying bumping the
minor verison!
Penrose now uses the thiserror crate for defining Error
values instead
of anyhow. This allows for better error handling both inside of Penrose
itself and within user code as well. There is a top level PenroseError type
that is returned by most functions and methods in the crate, but there are also
specific DrawError and XcbError types for those respective modules.
Previously, keybindings were attached to functions matching the FireAndForget
function signature which simply ran your code and expected you to handle all
failures internally. This type has been renamed to KeyEventHandler and now
returns a penrose::Result
. All corresponding public methods on WindowManager
have been updated to match this signature and now propagate errors back to
callers when they occur.
In some cases this has also resulted in modified return types of these methods:
now returning an Error
in cases where previously you would have received a
default value.
In Penrose 0.1
, the WindowManager
struct took a Box<dyn XConn>
which was
used to communicate with the X server. This was then inaccessible to user code
once the manager was created, meaning that there was no way for user code to
interact directly with the X server. In 0.2
, the WindowManager is generic
over the XConn implementation that is provided (non-boxed) and it is now
possible to write specific impl
blocks for a WindowManager
using your
implementation of XConn
should you wish.
NOTE: Interacting with the X server directly without going through the
WindowManager
can (depending on what you do) lead to invalid state in the
WindowManager
. Please be careful with how you make use of this!
One knock on effect of this is that types and traits that take references to a
WindowManager
are now generic as well. This means that you will have to add
generic types to any custom hooks, widgets and keybinding functions you have
written. (It also means that you can customise the behaviour of these depending
on what XConn
is being used, if that is of any interest.)
The Config
struct is now immutable by default and requires that you follow a
builder pattern. This provides more flexability in how you build up your
config while also ensuring that you are not able to inadvertantly create invalid
config which is then only caught at runtime.