Inline window controls

[bertob]

Hi, Tobias from GNOME here.

We started a new initiative to encourage third-party apps to support client-side decorations. I'm reaching out to ask if you are interested in participating.

Our initiative is about making it possible to not have a separate title bar in apps. This allows apps to integrate better with their window decorations, and is more space-efficient. GNOME, elementary, and even newer macOS apps have been moving in this direction for quite some time.

Chromium v63+ on GNU/Linux is a good example: They draw UI elements and window controls in the same toolbar. Importantly, they also handle special cases like which side the buttons are on, which buttons to show, and they have a preference for using a separate title bar.

Here's a quick proof-of-concept mockup of what this could look like for Telegram.

We are interested what you'd need on the toolkit/platform side for this to be implementable, and how we could help. You can find more information in this blog post and this page on our Wiki.

It's worth noting that not all desktops on GNU/Linux use client-side decorations, and some people prefer title bars separate from the rest of the app (like the one Telegram currently has). This could be a preference or something that is set automatically depending on the desktop.

This would also address #1999

[john-preston]

Thanks for such a detailed description.

Perhaps something like Windows version custom titlebar could be used instead of the native one. The proposed screenshots are not fitting with the current design too well when you think about narrow windows, single column layout, three column layout and such other things.

[bertob]

Thanks for the quick answer!

I'm not familiar with how the Windows version behaves exactly, but from screenshots I assume that you mean the thin gray bar at the very top of the window, like on this screenshot?

I'm not sure if that would be a huge improvement over native title bars. One of the main advantages of client-side decorations is that they provide larger click targets for the window buttons and use less screen space. This wouldn't really help with either.

Here's an example of how native GNOME apps use client-side decorations:

I agree that there are a lot of edge cases with moving the decorations to the toolbar, but it doesn't seem impossible. Some small changes to the design might be necessary, but if you're open to it I'd be happy to work with you (or your designers) to find a good solution.

As far as I can see, the main issues would be:

• If the decorations are on the left and the sidebar is very narrow, the search bar gets too narrow
• The emoji panel (in three-column mode) would need to be moved so that it doesn't occupy the top right area
• In single-column mode, we'd need to decide whether the window decorations are on each column or on a separate layer above the rest of the UI (might have implications for the visual design)
• What happens when no chat is selected (and the toolbar not visible) and the decorations are on the right?

If you want, I can work out a concept that addresses these concerns (and any others I might have missed here).

[Aokromes]

IMHO https://github.com/telegramdesktop/tdesktop/issues/2958 can be a generic ticket to address this.

[bertob]

@Aokromes not really, the idea here is to move the window controls inside the app, so we don't need a window frame. #2958 seems to be about different types of window frames...

[Aokromes]

Yes but no, the setting can be a dropdown with: Native windows frame. Current windows frame. Your way with buttons inside the app. :)

[readonly24]

I'd like to see native UI (in my case on windows) as well. Too may programs started theming and forget about the idea of having a uniqe UI all over the desktop.

Please, implement it, or make configurable. Thanks.

[fabiscafe]

Any news on this?

[Feichtmeier]

This qt client is better than anything else. So please no gtk telegram client. Telegram desktop is fine.

CSD option would indeed by very nice and on par with chrome and firefox.

[sergioad]

Agree, I really would love to see CSDs in TDesktop

[Tynach]

@bertob, I have to kindly disagree that this would be a good thing for Telegram to implement. Something I frequently do on Linux, is move Telegram from one display to another, while keeping its relative position within whichever display it's on unchanged. I do this by using KDE and right-clicking the titlebar, and using KWin's titlebar menus - which have a 'move to display' submenu.

One of the number one reasons I refuse to use modern Gnome applications within KDE is because they do not have this option, because they use client-side decorations. There's just simply no possible way to adequately use my window manager of choice's built-in functionality with these applications, because they just have to feel special by combining the use cases of the most standard and fundamental parts of a UI. It breaks the entire Unix design philosophy (do one thing and do it well), and was one of the absolute worst decisions made by Gnome in the entire history of the project.

I've found myself having to use Windows for employment reasons, and the fact that this mentality of recreating fundamental parts of the UI without adequate reason has now crept into Telegram on Windows. To my knowledge, it still uses a native titlebar on Linux, but this bug report suggests that might change. Regarding the Windows version, there are now numerous bug reports about the change, with a majority of users asking for a standard native titlebar to be used instead of a custom one.

The reason it's using a custom implementation? Because Telegram I guess wants to be able to make the title bar whatever color is set by the theme... Except that doesn't actually make sense. If people are customizing the colors, then more likely than not they are changing Telegram's colors to match the colors used by the rest of their system. Having the ability to customize the titlebar color is redundant, because they can already do that, by changing it within their system settings.

This all seems born out of Mac OS X allowing applications to set a custom titlebar color. However, I doubt that a majority of TDesktop users are even using OS X, so making this change just to be able to use that one platform-specific preference doesn't even make sense. And I'm sorry this has turned into a massive angry-sounding rant, but I've been so thankful so far that this nonsense hasn't affected TDesktop on Linux so far, and now it's looking like it's only a matter of time until it will.

I don't even know WHAT I'll do when that happens, because I seriously do swap what monitor an application is on frequently. I understand that implementing a menu item for swapping monitors is far beyond the scope of TDesktop as an application, especially to appease a single user. But that's why TDesktop should not implement its own client-side window decorations to begin with. These things are out-of-scope for TDesktop, but they aren't out-of-scope for KWin.

PLEASE just let KWin, Mutter, and so on do their jobs, and do them well, and give their users the features they want. Don't waste your developer time making Telegram worse by having to re-implement features that don't even relate to Telegram itself.

Yes, this might mean removing support for titlebar themes on Windows, and never implementing them on Linux. This is OK and the majority of actual users won't care. In fact, the absolute worst that can happen is that some users find it mildly disappointing that they can't customize something within Telegram only, instead having to use a system-wide change. But they're probably used to that: the titlebar color is rarely customizable in any application, so they won't think much of it. And if they're on KDE, they can customize it on a per-application basis anyway.

In the end, it will also mean you have more time to work on much more important things, and you won't upset a bunch of current, existing users. That, to me, sounds like the better decision to make.

[Tynach]

In case my ranty post above gets removed for being hostile (I tried to prevent sounding overly aggressive, but it's a topic I'm been increasingly upset over for many years now and I realize I'm not the best person to judge if I sound a particular way or not), I'll make this note of clarification separately.

@bertob, when @john-preston mentioned it not fitting in single-column layout and three-column layout, you never seemed to quite understand what he meant. Basically, try resizing Telegram to be a very small window - like, just the width of the list of users on the left side. It changes the layout of the window to only contain that list, with a search bar on top. When you open up a conversation, it behaves like a mobile application and has that completely replace the users list.

As for three-column mode, make the window bigger (maximized would be easiest), open a conversation, and look in the top-right at the button that's a rectangle that's bisected at an offset that's closer to the right side. Clicking that icon brings up the 'profile' for the conversation (user profile for users, group profile (with user list) if it's a group), but as a side-panel instead of as a floating pop-up.

John's basically saying that a lot of those elements that you place in specific areas of the window decorations, would no longer really fit well (or at all) when using these other modes. I got the impression that they might be more receptive of your proposal if you adjusted it to account for those use cases.

I still personally don't think it'd be a good idea to use CSDs whatsoever, but I understand that my reasons for not liking CSDs are extremely niche. If Telegram decides that using CSDs for its titlebar will make Telegram better for most people, that's up to them, and I'll respect that decision... But in that case, it would indeed be best to fit the design of the decorations in with how the UI currently works with its 1 to 3 panel layouts.

[bugaevc]

Hi @Tynach

I do this by using KDE and right-clicking the titlebar, and using KWin's titlebar menus - which have a 'move to display' submenu.

One of the number one reasons I refuse to use modern Gnome applications within KDE is because they do not have this option, because they use client-side decorations.

I'm not sure about X11, but on Wayland, right-clicking the headerbar opens your window manager's native menu, via xdg_toplevel.show_window_menu() — so you get the best of both worlds.

I don't even know WHAT I'll do when that happens, because I seriously do swap what monitor an application is on frequently. I understand that implementing a menu item for swapping monitors is far beyond the scope of TDesktop as an application, especially to appease a single user. But that's why TDesktop should not implement its own client-side window decorations to begin with. These things are out-of-scope for TDesktop, but they aren't out-of-scope for KWin.

PLEASE just let KWin, Mutter, and so on do their jobs, and do them well, and give their users the features they want. Don't waste your developer time making Telegram worse by having to re-implement features that don't even relate to Telegram itself.

They are indeed out of scope for apps (Telegram in this case), and in scope for window managers. But that's not an argument against CSD support.

On the other hand, there are Wayland protocol extensions that Telegram could implement that let it know if the window manager prefers clients use SSD or CSD — if Telegram adds support for that, then when running under KWin (which uses those protocols to ask clients to use SSD) Telegram would use SSD, and on GNOME (which doesn't), CSD. Again, window menus and window management work properly even without that, but using SSD on desktops that already use SSD for their apps goes towards consistency and aesthetics.

There's no conflict of interest as you're presenting it, we could get the best possible experience for everyone.

[Tynach]

@bugaevc, on X11 all programs implementing CSDs also implement their own right-click menu. At the very least, Firefox, Chrome, Gnome's character map, GEdit, and so on all do.. And in Chrome and Firefox's case, this makes sense because there are extra items that need to be put in there (such as new tab, close tap, select all tabs, and so on).

None of these applications allow me to easily swap which display they display on, which has been a source of annoyance. Thankfully, I can just use KCharMap and Kate instead of Gnome's apps, and I usually have Chrome and Firefox maximized so it just takes a fast flick of the mouse to swap displays.. Though the times where I don't are frustrating, and sometimes I've brought back the standard window decorations instead.

My point, however, is that implementing this properly in a way that makes as many people happy as possible, takes a lot of effort - and yet if they avoided the feature entirely, none of the users would be made unhappy.

Given that the vast majority of code for this project is committed by a group of people no larger than 6 individuals, it doesn't make sense, to me, to even bother trying to implement it. Too little benefit (make Gnome's people happy that another app implements something like one of their little side projects, and make Gnome's users slightly happier that Telegram fits in slightly better) considering the amount of effort.

[fabiscafe]

@Tynach I think kwin supports in whatever-case to press Alt+F3 to show windows controls.

takes a lot of effort

I dont think it's to much. CSD is natively supported by Qt. The part that is missing should mostly be the buttons (correct me if I'm wrong)

and yet if they avoided the feature entirely, none of the users would be made unhappy.

TBH. I'm already very unhappy. That's why I'm here

Too little benefit

Then why support Linux at all? You really should never come up with arguments like this for software that runs on Linux. Thing is, like with the notifications, both options would be a good thing to have. Not only on Linux, but also for Windows and MacOS. I totally do not need a bar with a name and close button in there. It's a waste of space for me, especially if there is already a "top-bar-layout" in this app. But I don't want to start all over again. We would need someone who writes a MR.

[Tynach]

@Tids If it's implemented as an option, I consider that to be the best and ideal case - and if the Telegram devs are willing to go that far, I applaud them and welcome the change. All too commonly, however, I see changes like this being made without it being an option, because it's often considered too much work to support multiple different code paths.

Perhaps I'm just overly worried because the Windows version has implemented a client-side decoration (albeit a very plain one) without an option to revert it, but in reality more substantial changes that affect more platforms would bring in additional options. I'll admit my initial post in here was typed rather late at night and I was pretty tired, and might have made extreme assumptions.

[ilya-fedin]

PLEASE just let KWin, Mutter, and so on do their jobs, and do them well, and give their users the features they want.

+1. Gnome developers make very strange things as deleting of tray icons and removing of support for server-side decorations from their compositor and tries to force apps to follow their guidelines. But Qt apps shouldn't do that. If gnome users want to use Qt apps, they can install an extension for tray and blame developers for not-implementing of the xdg-decorations protocol to make suffering their users. This is more judge, since gnome is one, but other DEs and WMs are just more.

[bugaevc]

This has nothing to do with "xdg-decoration". Wayland clients are required to be able to render their own decorations. If both the compositor and the client support the "xdg-decoration" extension and the compositor indicates it wants the client to use SSD, then and only then the client should stop rendering its own decorations. In other words:

• By default, clients must use CSD
• If the compositor and the client support the xdg-decoration extension, and the compositor tells the client to use CSD (as Mutter would if it was to support xdg-decoration), the client must still use CSD
• Only if the compositor tells the client to use SSD, then it must use SSD

Qt, being a toolkit that supports Wayland, respects this, and renders its own decorations. In fact, Telegram already has client-side decorations when running on Wayland. This issue is not about adding decorations because there's none, it's about enhancing the already existing decorations that Qt draws (on Wayland). In particular, this issue is about combining the title bar (that hosts the title and the close button) and the Telegram toolbar into one bar.

[yushijinhun]

In fact, Telegram already has client-side decorations when running on Wayland.

Yes. And this is what it looks like. The CSD drawn by Qt is extremely ugly, and Telegram really needs its own CSD.

telegram-desktop: 1.9.14+ds-2

[teohhanhui]

The ugly CSD problem is not for Telegram Desktop to solve. That needs to be solved by a theme plugin such as QGnomePlatform: https://github.com/FedoraQt/QGnomePlatform

[bugaevc]

And since you mention it, QGnomePlatform does make Qt decorations look a lot like native Gtk decorations (GtkHeaderBar). Telegram is perfectly usable, but it has two bars when it could have one — hence, this issue.

[fabiscafe]

@teohhanhui They could integrate to controls on "CSD supported platforms" into the main window https://github.com/telegramdesktop/tdesktop/issues/4358#issue-292145949 instead of draw a decoration just for them. I think it kind of is for them to solve. I consider QGnomePlatform to style them as workaround, not a fix. But that's just me.

[ilya-fedin]

Wayland clients are required to be able to render their own decorations.

That's why Wayland API is ugly. The lack of basic things, such as decorations, screenshot API, etc and this even doesn't change.

The CSD drawn by Qt is extremely ugly, and Telegram really needs its own CSD.

Or maybe your compositor needs to draw server-side decorations? :) So basic thing.

it's about enhancing the already existing decorations that Qt draws (on Wayland)

"enhancing". You speak as if they can be edited, but not written again. Not to mention the fact that Qt does not provide any API for CSD and you need to use wayland/xlib directly.

[teohhanhui]

Can we keep the Wayland vs X11 argument out of this issue please? It's irrelevant to the discussion here.

[p3732]

With the inclusion of folders in the sidebar the original mockups are now outdated . So if the folders are staying like they are (I actually think a tabbed version as on the mobile client would give a cleaner interface with less wasted space and fewer horizontal sections), some major rethinking would be necessary, as CSDs can not be placed on the left side with the current design.

[xerz-one]

@p3732 I don't see the conflict, you just have to keep the folders panel along with the chats panel under the main toolbar

[zzag]

and the compositor indicates it wants the client to use SSD, then and only then the client should stop rendering its own decorations

Only if the compositor tells the client to use SSD, then it must use SSD

@bugaevc A small but very important correction: the client indicates the preferred window decoration mode and the compositor decides if it should honor that. In most cases, the compositor will honor the requested decoration mode, but it can also force some other decoration mode. Ideally, telegram needs to indicate that it wants SSD if it runs in KDE Plasma.

[ilya-fedin]

telegram needs to indicate

That happens inside qtwayland, there are no public API

[Tynach]

KDE is still primarily used on X11, and at least on X11, there is only one title bar when Telegram uses a client-side decoration within KDE PLasma.

Also, that upgrade was a slight roller coaster for me! I was getting ready to rant when I first saw it use a client-side decoration here on Linux, and then I read the changelog conversation that popped up. Super glad for the ability to configure it! I'll be changing that option on Windows too next time I'm booted into it, just so I can tell if I have that window up or not x)

I think having it configurable is the right way to go. However, something I found out kinda recently is that at least in KDE, applications can set the color of the titlebar. When I'm in Krita, I can choose a color scheme for Qt to use, and the titlebar of the application changes what colorscheme it's using along with the rest of the program - despite being a server-side decoration.

Personally, I care more about being able to see when I am or am not in a window, so I'd prefer for the server-side decorations to not be touched. However, I wanted to put out there that apparently it is possible, at least in KDE.

[ChALkeR]

This seems to be enabled out of the box on 2.2. How do I disable this and return to SSD, on KWin?

Upd: found it!

[ilya-fedin]

This seems to be enabled out of the box on 2.2.

This issue about gnomish CSD, which requires changing the design

[Feichtmeier]

Not to be too annoying, but CSD is also used by:

• google chrome
• vscode
• firefox & thundebird (if you enable it)
• Many MacOs applications

[ilya-fedin]

Anyway, third-parties have no way to request changing the design, AFAIK, it is handled on a level higher than even core developers and noone relays issues to the right people from here (i.e. if you post some server-side issue or design change request, it would be just ignored). I guess this is due to half-official state of github issues.

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bertob]

Nope, not resolved yet.

The new decorations are technically client-side so they at least have the same color as the app, but it's still a separate bar, which doesn't fit in great on GNOME, where apps have window controls inline in the regular toolbar.

FWIW macOS is doing the same thing now in most apps in Big Sur, so I think there's never been a better time to revisit this ;)

[fabiscafe]

Nope, not resolved yet.

Actually it is.

but it's still a separate bar, which doesn't fit in great on GNOME

Cosmetics... Telegram doesn't have any interest in integrating into one special DE for linux. I'd wish we could toggle this (also on Windows BTW), and i wish we would get shadows on wayland, but thats not this bugreport.

[p3732]

Nope, not resolved yet.

Actually it is.

Technically you are right, but that is not what this issue is about. Maybe the issue should be renamed to clarify this somehow, but I don't have any good suggestions.

Cosmetics...

Sure this is a lot about aesthetics, but the thing is, this aesthetic is more than just cosmetics. Reducing window chrome let's an app provide more actual content, which is what tg is all about.

[sergioad]

I'd wish we could toggle this (also on Windows BTW), and i wish we would get shadows on wayland, but thats not this bugreport.

I agree man, having it as a switch would let anyone to choose if he or she wants inline window controls or not which also would let Telegram fit in any desktop and I am pro choice

[stale[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[bugaevc]

We therefore assume that the user has lost interest or resolved the problem on their own. Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

We have not lost interest :)

[ghost]

Thanks @Aokromes for redirecting me here. It's quite upsetting there hasn't been any progress on this issue. The current client side decoration is nearly unusable on Gnome. It is very tiny, making it impossible to interact with on a touch screen and much more difficult with a track pad. In addition to that, there is no way to enable the standard Gnome title bar on Wayland, so you're stuck with the useless client side title bar. It's not pure cosmetics. The above mentioned problems are ones of usability. Yes, Linux can be and is being used with a touch screen (on MS Surface line of devices, for instance), not to mention on laptops with track pads. Gnome header bars are not there just for pure aesthetics, they fulfill a very functional purpose. I sincerely hope @bertob 's proposal can be revisited. It doesn't seem like it is impossible to achieve without breaking the current telegram-desktop design.

[ilya-fedin]

No change can be done without a permission from Telegram Designers and they don't read github, so any complaints here are useless and won't achieve anything.

[liferooter]

No change can be done without a permission from Telegram Designers and they don't read github, so any complaints here are useless and won't achieve anything.

So is there a way to contact Telegram Designers?

[john-preston]

@liferooter you can always contact t.me/design_bot and suggest high quality design improvements.

Also there is a bugs-and-suggestions platform at https://bugs.telegram.org where you can suggest the design improvements and then other users can vote for them.

[ghost]

@john-preston So do you confirm that the discussion of this issue on GitHub is basically pointless because you can't make this kind of a decision?

[fabiscafe]

@igor-kobzev In the long run Telegrand might be the one that fits in the best. tdesktop is missing a lot when it comes input-types and system integration and I don't see this going to change, given the rather exotic use-case on this sm0l "platform".

[ilya-fedin]

what's 'input-types'?

[fabiscafe]

@ilya-fedin like mouse and keyboard, touchpad, touchscreen, pens, VR-devices, game-controllers, voice, and so on.

[john-preston]

@igor-kobzev Well, I don't really see any good suggestions for the UI changes. If I did maybe I could ask / suggest something to the designer that I'm working with, but for now this suggestion:

https://wiki.gnome.org/Initiatives/CSD/Telegram

doesn't really work. (why the first "GNOME" variant doesn't have minimize and maximize buttons... just curious)

As I said, the proposed mockups cover only tiny amount of use cases and I don't understand, how it'll work in others, for example:

(with controls on the left)

(with controls on the right)

(with controls on the right)

(with controls on the right)

(with controls on the left)

Even if you manage somehow push the controls in all those cases I'm sure it won't look very well. For example, in this case:

It'll be very bad in both cases (with controls on the left or on the right), there is simply not enough space for them. Also on the left they'll be out-of-place, because you are expecting the back button to be in the top-left corner. And so on, and so on.

It simply doesn't fit / work / look good.

[john-preston]

Also, keep in mind, that many users opt in for using native system window frame and all the designs should allow both working with an external, server side decorations as well as with embedded controls. So there is also no way to simply add some critical controls to the non-native title bar, the features should still be accessible in the windows with native title bars as well.

[liferooter]

@john-preston

why the first "GNOME" variant doesn't have minimize and maximize buttons... just curious

Because in GNOME there are no maximize and minimize buttons. Just double-click on headerbar or dragging to the top of the screen.