Skip to content

Releases: sminez/penrose

0.3.6

31 Aug 09:14
c8f04ab
Compare
Choose a tag to compare

What's Changed

  • #297 improving the behaviour of IntervalText to run all updates in a single thread by @sminez in #298
  • Adding meta queries to support combinations of queries as queries. by @favilo in #291
  • fixing #113 and adding proper mouse support by @sminez in #300
  • add battery finder by @bbarker in #303
  • feat: toggle_floating_state and is_floating (#306) by @codybloemhard in #307
  • feat: support customising the behaviour of the workspaces status bar widget by @sminez in #309
  • Only honour removal of fullscreen state if the state is currently present by @sminez in #311

New Contributors

Full Changelog: 0.3.5...0.3.6

0.3.5

04 Jun 18:38
Compare
Choose a tag to compare

What's Changed

New Contributors

Full Changelog: 0.3.4...0.3.5

0.3.4 release

07 Nov 11:05
Compare
Choose a tag to compare

Bug fixes

0.3.3

16 Jul 08:15
Compare
Choose a tag to compare

What's Changed?

  • Issue 272 - removing the dependency on pango and cairo (#274)
  • fixed invalid desktop entry example in the getting started guide
  • added resise request xevent and marking xevent as being non-exhaustive
  • fixing an issue with floating windows continually shrinking as the gain focus
  • added new layouts
  • fixed underflow bug in reflect transformers
  • added quickcheck tests for ensuring layouts don't panic on unexpected inputs
  • adding focus_element and focus_element_by methods to Stack
  • replaced internal usage of linked lists with vecdeque
  • adding helper function for printing and ASCII repr of a layout
  • added a split_at_mid methods to Rect
  • added IntervalText as a base widget type for the status bar
  • #268 clearing destroyed Xids from NSP state (#269)
  • we now remove unknown clients from state when XConn impls return Error::UnknownClient from next_event
  • added a helper macro for composing manage hooks
  • fixed an issue where certain windows (e.g. chromium) render with transparent borders
  • fixed the behaviour of the non_hidden_workspaces method on StackSet
  • added LayoutHooks as a feature in Config
  • allowing pointer warp when a workspace has floating clients
  • added new manage hooks

Full Changelog can be viewed here: 0.3.2...0.3.3

0.3.2: bug fixes & QOL Improvements

11 Jun 15:17
Compare
Choose a tag to compare

There's a reasonable amount in this one but the main bugs that have been squashed are:

  • #129 #223 #231 pop up windows and dialogues no longer make programs unresponsive(!)
  • #244 manage_existing_clients now correctly avoids tiling windows that should be ignored
  • #251 transient windows now render on the same workspace as their parent

New features:

  • #265 @thebashpotato the DMenu helper now supports triggering dmenu-rs as well as the default suckless version
  • #166 keybindings can now be updated while Penrose is running

This also includes an update of the dependency on x11rb to 0.11 from @psychon #250

0.3.1 fixing issue with kill_client

14 Nov 22:06
Compare
Choose a tag to compare

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.

v0.3.0

12 Nov 07:20
Compare
Choose a tag to compare

📦 🦀 V0.3.0 is now live on crates.io 🦀 📦

2022-11-12_1668238509

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!

Highlights

  • A new "diff" based approach to rendering window state that provides a clean split between pure logic and side effect filled X logic
  • Smarter internal data structures that allow for much simpler implementations of extensions to the core behaviour
  • A base layer for extending the UI that is actually usable as opposed to being all kinds of scary! (Currently there is a status bar but a native dmenu replacement is in the works as well)
  • A richer API for layouts that solves a lot of the issues that the pervious release had around implementing more complicated layouts and sharing common functionality (like gaps).

Version 0.2 end of life

29 Oct 15:56
33af1c4
Compare
Choose a tag to compare

⚠️ The 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:

  • Basing the original design on the dwm code base lead to a very C like API
  • State management is overly complicated
  • Hooks are overly complicated
  • Testing core window manager operations is a lot harder than it should be
  • Far too many macros (I wrote penrose originally in part to learn how to write proc-macros...)
  • Default impls used the rust-XCB crate rather than the wonderful x11rb from @psychon

A 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.

What does this mean for me?

I like things the way they are!

🏷️ 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.

How do I start making use of the new APIs?

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.

When will the new APIs be stable?

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!

0.2.1

27 Dec 19:36
Compare
Choose a tag to compare

Bug fixes and improved test coverage.

0.2.0

17 Jan 20:06
Compare
Choose a tag to compare

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!


Errors

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.


Results

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.


WindowManager is now generic over XConn

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.)


Config is now immutable

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.