Discussion on how best to implement window borders. Two main choices:
I'm really not convinced either way is the obvious solution. Discuss.
Just a few thoughts. Which is the easiest to implement right now and what
would be the performance of each? We might not know that yet though
On 26 Jan 2016 8:19 am, "Drew DeVault" [email protected] wrote:
Discussion on how best to implement window borders. Two main choices:
Draw them with GL in wlc's pre-render hook
Create rgba surfaces for each window that sit behind each window and draw
the border around itI'm really not convinced either way is the obvious solution. Discuss.
—
Reply to this email directly or view it on GitHub.
With rgba surfaces, wouldn't that mean that the user could specify the colors too and hence a colored border? I think that would be good choice in terms of customization...
You can specify color in gl too :)
On 26 Jan 2016 8:36 am, "Seth Barberee" [email protected] wrote:
With rgba surfaces, wouldn't that mean that the user could specify the
colors too and hence a colored border? I think that would be good choice in
terms of customization...—
Reply to this email directly or view it on GitHub
https://github.com/SirCmpwn/sway/issues/477#issuecomment-174674066.
Probably easier to implement with GL. Unsure about the performance.
Text rendering in GL (for window titles) is a pain in the ass, fwiw
We can use Cairo for that can't we
On 26 Jan 2016 8:42 am, "Drew DeVault" [email protected] wrote:
Text rendering in GL (for window titles) is a pain in the ass, fwiw
—
Reply to this email directly or view it on GitHub
https://github.com/SirCmpwn/sway/issues/477#issuecomment-174678419.
Probably, but the GL backend for cairo is experimental. Not sure what that implies.
Hmm most wayland client code/tutorials that I have seen all use egl and cairo and they all run ok
Well, if it works, it works.
Would the surface method be something like
The surface method would be to create a new surface every time a view is created that needs window borders and somehow associate it with that window, then move it during the layout arrangement.
I am leaning towards the pre hook method as we only need to calculate and draw the border instead of dealing with creating/linking/moving/drawing another object
I'm just chiming in with my 2 cents, but I really hope Sway is planning to support window buttons at some point in the future, and that whatever decision is made will allow for that feature down the road!!
I know i3 does not do this and has no plans to do so, but it would be great if Sway did
I have no intention of implementing window buttons.
Aww sad.
How will this interfere with client-side window decoration?
@gpyh they will just be inside the borders drawn by sway.
@ViktorNova if you're sad and have the skills, fork it. For something keyboard-operated like Sway, there's no reason to have them.
I'm not very familiar with the current situation, but isn't it basically just using the wallpaper? With i3, there's no “justification” for having wallpaper, as it's never shown while windows (except the floating kind) are up, but here, the wallpaper could _be_ the borders, providing a practical reason to have one.
Basically, I'm suggesting not implementing custom borders at all, but I don't know if that would entail a loss of functionality.
I don't really understand what you're suggesting.
@ke7ofi borders are very helpful to see what window has focus, in i3 the focused window has a blue border while the others have a grey border (by default).
Also the title of the window is nice to have.
Borders are also very useful in the tiled and stacking layouts.
@mikkeloscar I rarely use the titles except when they're forced (in tabbing mode), but I definitely see why that's important. Focus is also important, so I suppose my suggestion didn't make sense, sorry.
Also worth noting is the hide_edge_borders feature, since its potential implementation might affect the consideration of how to implement window borders.
As for the discussion, I see titlebars and borders as two separate features:
Titlebars are definitely needed for stacking/tabbed layouts.
Borders are only necessary as an indicator of focus, but otherwise they're just a cosmetic feature.
As for the discussion, I see titlebars and borders as two separate features:
They aren't, really.
I'm not sure how separate you're thinking of, but I think i3's semi-optional titlebars are a reasonable implementation. (I guess reasonable design is a large part of why I like i3 so much, actually.)
The reason this makes me sad is because right now there is no such thing as a tiling window manager that is touchscreen-friendly. However, i3 accidentally turned out to be damn near perfect for a touchscreen, but because of the main developers ideals, they 'will never add window decoration buttons'.
I was hoping with Sway's broader goals and a different crew that I might be able to persuade you to at least consider this feature that, if implemented, could possible make Sway a major contender in the rapidly growing touchscreen market that is currently only served by window managers that are floating and/or fullscreen only.
Sadly I am not a coder, or I would absolutely fork it myself!
We're going to be adding multitouch bindings in the future, so you could bind a gesture to do whatever the buttons could do.
@ViktorNova what about CSD? Most clients has it enabled by default in wayland so the buttons are already there.
@SirCmpwn - That is EXCELLENT to hear, I will definitely keep my eye on the project! =)
@mikkeloscar - This is unfortunately true only for GTK3 apps, which only accounts for a portion of Linux desktop software
Most helpful comment
We're going to be adding multitouch bindings in the future, so you could bind a gesture to do whatever the buttons could do.