[Original comment by anonymous]

Oh please implement this.. its the most wanted feature for me... at least with floating windows this should be rather easy...

[Original comment by Rasmus Steinke <rasi13@…>]

i also vote for this - and i agree floating windows should be relatively easy to implement, it gets tricky when window is in tied mode. But wmii also does it somehow, so its at least possible :)

due to lots of changes in 3.ε already, i don’t want to implement it in this version. will be included in 3.φ probably

[Original comment by Nathan Middleton <nathan.middleton@…>]

I personally think a more useful improvement would be to lift the "tagging" idea from wmii and implement a +all tag for "sticky" behaviour and "+" for individual workspace stickiness, allowing for windows to show up on individual workspaces or all as needed by the user.

This is something I'm keenly interested in and will be looking at the source more indepthly on.

[Original comment by Nathan Middleton <nathan.middleton@…>]

As a side note, wmii gets this behaviour by just simply listing the workspaces a client is attached to in its /client//tags file. IDK how i3 could mimic this behaviour since I'm not as yet familiar with the data structure for clients. It would seem it'd be as simple as keep pointers in the tree back to the client window somewhere else in the tree (I reference how Leo editor does tree-based linking here as an example).

Unsetting version, unlikely to appear in 4.2.

[Original comment by mde@…]

I'll put in a vote for this. My main use case is when I have a long-running interactive installer running (e.g., pacman/packer) that prompts every so many minutes. Otherwise, I'm always having to switch to a workspace to see where how far it's progressed. There are other types of things I'd like to monitor and keep in a corner window (test runners, etc) on all (well, odd or even) workspaces. I suppose a little floating window would be how I'd prefer to use this. I'd also settle for having my scratch window simply be visible/pinned on all (odd or even) workspaces.

[Original comment by fabian@…]

Let's not forget about this one.

I've seen this has been moved forward in each release and I'd say it's a nice to have feature. I don't know how hard it would be to implement, but I started to study the codebase a bit and see if I get some ideas about it.

[Original comment by anonymous]

Why can't a client appear in more than one container?

Is it easy to stick clients in more than one container, but hard to navigate that tree once you've done so?

Might I suggest some sort of --enable-sticky-break-warranty configuration, then? (Maybe even if the breakage is worse that what I guessed.)

I need it for my emacs minibuffer...

Thanks, cheers,

[Original comment by lee@…]

FWIW, I vote for this feature, too. It's useful for too many things for not to have it.

[Original comment by anonymous]

Back in 2010 some code was added to address Sticky Windows.

http://code.stapelberg.de/git/i3/commit/?id=0925e8b7dc76e9a64872b5b25b210ae98ffe3755

anonymous, is this the --enable-sticky-break-warranty configuration you were looking for?

It's clear from the comments that the code is a rough draft; there are known problems.

Anybody know how to connect the code in that commit to a keybinding?

That code is unfinished and might be broken. A UI (keybindings) first needs to be developed.

[Original comment by lkraav <leho@…>]

Oooo, vote vote vote. Need this on QHD display.

[Original comment by TonyC]

What if we made the scratchpad always on top?

It would essentially be the same as one of those "sticky notes" widgets in other window managers but with any window.

Pros

• easy to implement
• no new configuration
• fits every use case listed so far
• people already use the scratchpad like this
  Cons
• can't be tiling
• changes what people expect the scratchpad to do

[Original comment by mistnim@…]

A sticky scratchpad sounds like a good idea to me. I would use it top keep a little mplayer window in a corner.

Replying to comment 19 by TonyC:

What if we made the scratchpad always on top?
It’s in the floating layer, so it already is always on top.

As for the suggestion itself, I don’t want to touch the scratchpad behavior.

This ticket was for tiling sticky windows, not floating changes. Let’s keep it that way.

[Original comment by mistnim@…]

I'm missing this feature a lot now. I'm video recording lectures and I want to constantly monitor the video output to keep sure the camera frame didn't move. Moving the scratchpad and unfocusing it everytime is not fun.

[Original comment by christos.dimitrakakis@…]

Yes, I do find this feature useful sometimes. I work around it by launching multiple emacs windows, but it's a pain when switching buffers. For terminals, I use screen, but again, it's a pain.

[Original comment by TonyC]

My implementation was rejected and I am no longer working on this.

[Original comment by biplane55@…]

I know work on this has been halted, but if anybody would like to continue, it would be great! This is one feature I have been pining for for a while now, and the only flaw I see with i3. I would be grateful if someone managed to put it in!

@stapelberg I'm not convinced we should implement this. It seems like it'd be an insane effort and even then it would probably not be what the user expects. #1856 would at least do this for floating windows. For tiling containers I think the "sticky groups" concept is more feasible.

What do you think?

@acrisci Out of curiosity, do you still have that patch that got rejected? Or at least, how did you deal with container positioning?

@Airblader here: http://cr.i3wm.org/patch/540/

Ah, I see, thanks. So Michael had the same concern I just asked him about. I feel like we should close this issue. EWMH sticky for floating + sticky groups should be all we need. @stapelberg Agreed?

I'm not convinced we should implement this. It seems like it'd be an insane effort and even then it would probably not be what the user expects. #1856 would at least do this for floating windows. For tiling containers I think the "sticky groups" concept is more feasible.

Not sure what you are referring to with “this”. This issue (#11) is about sticky groups for tiling containers, at least that’s how I meant it. I realize in the first post I’m talking about EWMH hints, but I’m not 100% sure if it makes sense to hook up EWMH hints to sticky groups. If that’s what you meant, I agree.

@stapelberg Then #1758 would just be a duplicate of this, right? I'd still close this original issue since #1758 doesn't have the confusing discussion baggage and you described the desired concept there clearly.

Agreed.

I saw there is a prototype about tiling sticky windows. I can't understand why this useful feature is not implemented. Even kwin with kwin-tiling can do this.
I'm not enought comfortable with the languages i3 is made, and i can't make a patch, but really REALLY need this feature for living. If you have only one screen (like a laptop) this is essential.

Sticky tiling windows are now possible by using the swap command. See https://github.com/Airblader/i3-sticky for an example implementation (which can surely be improved upon).

I can't understand why this useful feature is not implemented.

If no one writes the patch, it's not implemented. Pretty simple to understand. I think needing this to »live« is a vast exaggeration.