Re: GTK+, WM, desktops and CSD
Ah, I think I see the disagreement. We don't decide between SSD and CSD based on the presence of a compositor and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD fallback. It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD. If you want to help improve CSD fallbacks to behave better when we don't have a compositor, that would be great! But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create, so a hint asking us to prefer to use SSD that we would realistically mostly ignore isn't particularly useful. On Thu, Mar 5, 2015 at 12:29 PM, Olivier Fourdan four...@gmail.com wrote: Hi On 5 March 2015 at 20:09, Emmanuele Bassi eba...@gmail.com wrote: On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote: What about apps that rely on CSD for part of their UI? Will those have the final word as well, or are they just screwed? The same as now without a compositor :) a) X11 without a compositor is a deeply uninteresting case; I'd go as far as saying that if you're running X11 without a compositor you're basically asking for a broken system I am not sure I am following you here, but people do run WM without a compositor, it is a reality. And GTK supports that, at least up until now, and that's fine by me. b) not having a compositor is not at all equivalent to changing a UI from a CSD to a SSD scenario. The UI *changes*, even in drastic ways for the user interaction. The application has to be informed about it, and has to be designed with those two cases in mind. It has to ship with two fairly different sets of UIs. It already happens for menus, but you'll have to convince application developers to ship those two UIs, maintain them, and keep them from going out of sync. Your idea stops at providing a patch for a hint. You're vastly underestimating the effort that such hint entails on the larger ecosystem. But it's already the case, I am not advocating to reinvent the entire ecosystem of UI interactions here, I am merely asking if a setting to help GTK decide to go CSD or SSD instead of just detecting the presence of the compositor alone would be interesting... Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote: It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD. That would work as well, why not. As long as I can set up my DE to pretend not to support CSD, whatever the actual state is. Because this is, at the end, user's preference. But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create... This is sad. Once your mission becomes creating certain types of experience, instead of enabling them, everything else gets destroyed, whether the types of experience it enables are also good or not. And there does not seem anything capable of stopping the destructive mindset at this moment... Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 10:37 AM, Olivier Fourdan four...@gmail.com wrote: +gtk-devel-list Argh sorry, I didn't mean to make that email private, thought my mailer would copy the list as well, my bad :( On 5 March 2015 at 19:29, Olivier Fourdan four...@gmail.com wrote: Emmanuele, Let's face it, I doubt GTK+ will ever dominate the world, so the it's not consistent because we're not using a single toolkit is not going to be solved overnight. And frankly, as much as I like GTK+, I do not wish other toolkits to go away either, so we shall have to deal with heterogeneous toolkits for any foreseeable future. GTK already check for a compositor and detecting the DE to adapt is really not a good approach, it doesn't scale, and worse it ends up being really confusing (I can't remember which famous app was doing that, but I do remember that we ended up pretending to be gnome in the session just so it would work reliably...). Hi, GTK+ should not try to detect the DE it is running under. It should check for the _GTK_FRAME_EXTENTS protocol in _NET_SUPPORTED on the root window. As I wrote, the final word would remain the to apps, just like now, all I'm proposing is to replace the decision made by GTK to use CSD based on a compositor with a hint from the DE instead, nothing more. Cheers, Olivier On 5 March 2015 at 19:18, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com wrote: I am not one of them, but there are a lot of people (including KDE devs apparently) concerned about CSD because it means different decorations depending on the apps/toolkit = Consistency might suffer. I don't strictly buy the consistency argument at all. Right now, on my desktop, I have open two different browsers — Firefox and Chrome — that do not look like anything on my desktop. I also have an office suite using its own toolkit which passes a slight resemblance to GTK, if I squint my eyes and tilt my head a bit. If I were so inclined, I could be probably running some non-GTK applications, and those would look fairly different. There's no consistency because we're not running a platform with a single toolkit. If you're referring to the window controls, you can specify them even for GTK windows using client-side decorations; it's a setting that can be changed to reflect your environment — that's why both server-side and client-side decorated GTK windows have the same buttons. I think it's very little change in GTK+ as it's already able to do both SSD and CSD (currently, decision to use CSD or SSD being made at run time based on the availability of a compositor). That's not entirely correct. The decision to use client-side decorations is up to the application developers, not to the toolkit. An application developer may decide to support both the UIs, and opt for client-side decorations if they detect that the application is running under GNOME, but the toolkit is only tangentially involved. The only place where GTK decides to use an header bar or not is for the dialog windows it creates — file selection dialogs, print dialogs, color selection dialogs, etc. Those are under the control of the toolkit, so the toolkit can make a decision. The UI of an application, on the other hand, is the remit of its developer. The toolkit cannot really move widgets around, because it's missing context to do so. If I use a GtkHeaderBar with a button at the top left, and the environment does not support CSD properly, where should the toolkit put that button? Keep the header bar, but still have decorations on top, thus replicating things like titles? Your proposal for an hint could be simply solved with a check on whether the screen is composited (which is already available) and/or a check on the desktop environment. Sure, we can add a freedesktop.org spec that tells us if the application is running under GNOME, KDE, XFCE, or whatever. Obviously, it all breaks apart as soon as choice is factored in — if somebody is running under KDE with KWin without compositing, what would the environment be? Same with XFCE running with another window manager. Let's ignore that for a minute, though, and figure out the issues of such a hint. • How does that hint get specified? Is it an X11 property on the root window? • How does it get monitored? What happens if the user changes the setting at run time? Do we get a client message? • How are applications supposed to react when that setting is found, or when it changes? Do they ship with two different UIs, one for CSD and one for SSD? • What happens if the application does not have two UIs? Is the setting ignored, and the application stays with client-side decorations even if the window manager does not support the Motif WM hints? At the end of the day, though, if the application developer
Re: GTK+, WM, desktops and CSD
Hi Emmanuele, On 5 March 2015 at 20:04, Emmanuele Bassi eba...@gmail.com wrote: [...] That's not what I was saying. I'm saying that precisely because we don't have an homogeneous environment you cannot use the it's inconsistent argument. It will always be inconsistent, for one reason or for another. Right, so we actually agree :) As I wrote, the final word would remain the to apps, just like now, all I'm proposing is to replace the decision made by GTK to use CSD based on a compositor with a hint from the DE instead, nothing more. You've conveniently ignored all the issues I've raised, so I'll just reiterate them, in the hope you have an answer instead of general handwaving: Sure • How does that hint get specified? Is it an X11 property on the root window? Yes, • How does it get monitored? Yes, it could. What happens if the user changes the setting at run time? The same as of today when someone enables or disables the compositor at run time, i.e. nothing. The apps that have been started with decorations keep it, those without remain without. Just like today. Do we get a client message? Yes. • How are applications supposed to react when that setting is found, or when it changes? When it's found it's an indication, apps may or may not follow it. If not found it remains as of today, GTK checks if there's a compositor running. Do they ship with two different UIs, one for CSD and one for SSD? They could but it's not mandatory. Today, they don't AFAIK. • What happens if the application does not have two UIs? Is the setting ignored, and the application stays with client-side decorations even if the window manager does not support the Motif WM hints? Yes. The use of Motif MWM hints for this is a anachronism IMHO, but that's another story. Ideally, GTK should be able to use CSD even without a compositor. The only reason it requires a compositor is because it uses the shadows as resize handles. Ideally, it should use a larger border width when there is no compositor - But that would another set of patches as not directly related to the hint proposed. Just to clarify, I know this topic is usually controversial, but I really don't mean to be controversial here. I am genuinely trying to come up with something that could possibly please those who don't want CSD - And before anyone asks, xfce 4.12 has pretty good support for CSD windows with GTK, including support for GTK_FRAME_EXTENTS or GTK_SHOW_WINDOW_MENU. Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 1:21 PM, David Nečas y...@physics.muni.cz wrote: On Thu, Mar 05, 2015 at 10:01:44PM +0100, Olivier Fourdan wrote: It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD. That would work as well, why not. As long as I can set up my DE to pretend not to support CSD, whatever the actual state is. Because this is, at the end, user's preference. It's the application developer's decision to build the application and the UI they want to build. GtkHeaderBar, like GtkButton or GtkMenuBar, is simply a widget in their box of tools to construct their UI. These applications might be free software, in which case you have the freedom to change the code and the UI. You are still welcome to do this. GTK+ is an application toolkit and is not in the business of constructing policy about what the application developer can and cannot do. If you do not like CSD, do not use applications that use CSD in their UI, or change the application's code to stop it from using CSD. We wouldn't accept a patch that radically changed GtkButton because it is, at the end, user's preferenece about whether GtkButton should be allowed. The same can be said about other UI elements that application developers use to construct your UI. But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create... This is sad. Once your mission becomes creating certain types of experience, instead of enabling them, everything else gets destroyed, whether the types of experience it enables are also good or not. And there does not seem anything capable of stopping the destructive mindset at this moment... Honest question: What is the everything else that is being destroyed? Are there some issues you have with our CSD implementation? I can try to help fix them. Yeti -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, 5 Mar 2015, Olivier Fourdan wrote: Hi Emmanuele, [plus responses to specific questions] Sorry for the noise, but I just wanted to say, as one who runs X11 without a compositor (I appreciate an elegant desktop but have no use for shadows, animations or transparency, I just want to get the job done efficiently), who greatly appreciates gtk and codes using both gtk2 and gtk3, and occasionally submits patches for both, and who doesn't care for CSD: Go, Olivier! I hope your suggestions have an impact. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
Hi On 5 March 2015 at 20:09, Emmanuele Bassi eba...@gmail.com wrote: On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote: What about apps that rely on CSD for part of their UI? Will those have the final word as well, or are they just screwed? The same as now without a compositor :) a) X11 without a compositor is a deeply uninteresting case; I'd go as far as saying that if you're running X11 without a compositor you're basically asking for a broken system I am not sure I am following you here, but people do run WM without a compositor, it is a reality. And GTK supports that, at least up until now, and that's fine by me. b) not having a compositor is not at all equivalent to changing a UI from a CSD to a SSD scenario. The UI *changes*, even in drastic ways for the user interaction. The application has to be informed about it, and has to be designed with those two cases in mind. It has to ship with two fairly different sets of UIs. It already happens for menus, but you'll have to convince application developers to ship those two UIs, maintain them, and keep them from going out of sync. Your idea stops at providing a patch for a hint. You're vastly underestimating the effort that such hint entails on the larger ecosystem. But it's already the case, I am not advocating to reinvent the entire ecosystem of UI interactions here, I am merely asking if a setting to help GTK decide to go CSD or SSD instead of just detecting the presence of the compositor alone would be interesting... Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
Hi Jasper, On 5 March 2015 at 21:39, Jasper St. Pierre jstpie...@mecheye.net wrote: Ah, I think I see the disagreement. No real disagreement, just discussions :) We don't decide between SSD and CSD based on the presence of a compositor and _GTK_FRAME_EXTENTS, we instead push really hard for CSD with an SSD fallback. I think you hit the nail on the head here :) It's a subtle difference, but it shows our preference: we don't want a hint to say that the DE prefers SSD, we want a hint to say that the DE can support/not support CSD. That would work as well, why not. If you want to help improve CSD fallbacks to behave better when we don't have a compositor, that would be great! But ultimately, SSD does not lead to the types of applications and the types of experiences we want to create, so a hint asking us to prefer to use SSD that we would realistically mostly ignore isn't particularly useful. I have nothing against CSD myself, quite the contrary, but not anyone wants CSD even when the DE supports it. Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 10:33 PM David Nečas y...@physics.muni.cz wrote: As long as I can set up my DE to pretend not to support CSD, whatever the actual state is. Because this is, at the end, user's preference. No, that does not work. All the toolkit can reasonably do is passing the preference on to the application, which can either adjust its UI or not: The worst thing that can happen when running a CSD application in an environment that pretends to not support it are double decorations, missing shadows and problems with window resizing. The worst thing that can happen when the toolkit forcefully rips CSD from applications is that there is no more UI to save, navigate, load or whatever essential UI the applications happens to put into its decorations. So even when such a property is added, there won't be anything magic about it. All it would do is allow applications that bother enough to offer alternative UIs for different environments. For all other applications, your options boil down to modify them yourself (if they are free software) or use something else ... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell cottr...@wfu.edu wrote: On Thu, 5 Mar 2015, Florian Müllner wrote: The worst thing that can happen when the toolkit forcefully rips CSD from applications is that there is no more UI to save, navigate, load or whatever essential UI the applications happens to put into its decorations. Isn't there some dissonance here: essential UI embedded in decorations? How did we come to this? I can sort of see why if metacity is taken as the baseline, since metacity in its default appearance suffered from a severe case of macroencephaly: a huge wasteland of bare forehead holding a bloated boldface window title and little else. But why not fix the WM (not all WMs waste anything like that amount of desktop) rather than conflating UI with decoration? consider a simple dialog. Should it have a close button or not? If the application adds an explicit close button, there are now two areas of the window as displayed by most WMs which will, upon being clicked, cause the window to be hidden. So should the application add its own? Or should it tell the WM that it would like a close button to be added? If it does the latter, is this close button decoration or essential function ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, 5 Mar 2015, Florian Müllner wrote: The worst thing that can happen when the toolkit forcefully rips CSD from applications is that there is no more UI to save, navigate, load or whatever essential UI the applications happens to put into its decorations. Isn't there some dissonance here: essential UI embedded in decorations? How did we come to this? I can sort of see why if metacity is taken as the baseline, since metacity in its default appearance suffered from a severe case of macroencephaly: a huge wasteland of bare forehead holding a bloated boldface window title and little else. But why not fix the WM (not all WMs waste anything like that amount of desktop) rather than conflating UI with decoration? Allin Cottrel___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, 5 Mar 2015, Paul Davis wrote: On Thu, Mar 5, 2015 at 5:44 PM, Allin Cottrell cottr...@wfu.edu wrote: On Thu, 5 Mar 2015, Florian Müllner wrote: The worst thing that can happen when the toolkit forcefully rips CSD from applications is that there is no more UI to save, navigate, load or whatever essential UI the applications happens to put into its decorations. Isn't there some dissonance here: essential UI embedded in decorations? How did we come to this? I can sort of see why if metacity is taken as the baseline, since metacity in its default appearance suffered from a severe case of macroencephaly: a huge wasteland of bare forehead holding a bloated boldface window title and little else. But why not fix the WM (not all WMs waste anything like that amount of desktop) rather than conflating UI with decoration? consider a simple dialog. Should it have a close button or not? If the application adds an explicit close button, there are now two areas of the window as displayed by most WMs which will, upon being clicked, cause the window to be hidden. So should the application add its own? Or should it tell the WM that it would like a close button to be added? If it does the latter, is this close button decoration or essential function ? That's a good, practical question that I'm happy to answer as an app developer. If I'm confident that the WM/OS is going to add a close control at the top right (a pretty good bet in most cases) then I wouldn't choose to add my own close widget in that vicinity. But if I have row of buttons at the foot of the window and Close makes sense as one of the options, I'd be inclined to add that option, to save the user from mousing a few inches to achieve his or her desired effect. -- Allin Cottrell Department of Economics Wake Forest University___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell cottr...@wfu.edu wrote: Isn't there some dissonance here: essential UI embedded in decorations? How did we come to this? [...] why not fix the WM [...] rather than conflating UI with decoration? Because it is not about working around any WM's (or more precisely: theme's) whitespace issues, but about a philosophical difference: Are windows containers that the system provides and applications fill with content, or are they space that is entirely under application control? You know what? It's a matter of taste - it's perfectly fine that you pick a different answer than me. But telling us how bloated and awful and just fucking wrong our preference is is about as helpful to the discussion as yelling at you about your terribly stupid pick of favorite color ... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Fri, 6 Mar 2015, Florian Müllner wrote: On Fri, Mar 6, 2015 at 12:44 AM Allin Cottrell cottr...@wfu.edu wrote: Isn't there some dissonance here: essential UI embedded in decorations? How did we come to this? [...] why not fix the WM [...] rather than conflating UI with decoration? Because it is not about working around any WM's (or more precisely: theme's) whitespace issues, but about a philosophical difference: Are windows containers that the system provides and applications fill with content, or are they space that is entirely under application control? OK, I can see that that's a legitimate difference (I'd say a design rather than a philosophical one, but hey). Fact is that the first alternative has been the status quo for a long time and IMO the second approach -- which is obviously quite disruptive, whatever its merits -- calls for more argument pro than I've seen so far. More than It's the trend, so shut up and live with it, unless you want to fork gtk. You know what? It's a matter of taste - it's perfectly fine that you pick a different answer than me. But telling us how bloated and awful ... I'm not saying that CSD as such is bloated and awful. I did say that metacity had a bloated title-bar by default and I stand by that. If CSD is not motivated by metacity's problems then I stand corrected on that point. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com wrote: Hi, I have little desire to discuss the pros and cons of csd and whether something essential (consistency ?!) was lost when we started using them, but a few points are worth replying to. The use of Motif MWM hints for this is a anachronism IMHO, but that's another story. I agree somewhat. We used them because we thought that they would be almost universally supported. That turned out to be farther from the truth than expected. But consider the alternative: If we had started by suggesting a new cross-desktop spec for CSD, we would still be arguing about protocols for proxying button clicks back and forth today... Ideally, GTK should be able to use CSD even without a compositor. The only reason it requires a compositor is because it uses the shadows as resize handles. Ideally, it should use a larger border width when there is no compositor - But that would another set of patches as not directly related to the hint proposed. Yes, I've been thinking that myself recently: We should fall back to having 'fat borders' instead of 'invisible borders+shadow' if the environment can't support them. A patch to do so would be most welcome (I'm well aware that gtkwindow.c is not the easiest place to add new functionality like this...) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Fri, Mar 6, 2015 at 2:10 AM Allin Cottrell cottr...@wfu.edu wrote: OK, I can see that that's a legitimate difference (I'd say a design rather than a philosophical one, but hey). Sure, let's call it different designs then ... Fact is that the first alternative has been the status quo for a long time and IMO the second approach -- which is obviously quite disruptive, whatever its merits -- calls for more argument pro than I've seen so far. It is not only disruptive, but also optional - applications that don't make use of gtk's custom decorations work as before. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Fri, Mar 6, 2015 at 12:59 AM Paul Davis p...@linuxaudiosystems.com wrote: consider a simple dialog. Should it have a close button or not? If the application adds an explicit close button, there are now two areas of the window as displayed by most WMs which will, upon being clicked, cause the window to be hidden. Yes, in case of server-side decorations. When using client-side decorations, the expectation is that the WM does not add any controls at all and the application can add as many close buttons as it sees fit (read: one). Though to be honest, a simple dialog is not too interesting here - if all you want is a titlebar with a close button, it's perfectly fine to just assume that the WM will give you that. CSD makes more sense(*) for windows with more functions, by for instance allowing you to visually balance the UI by putting an Open button on the left and a Close button on the right. (*) Compared to the simple-dialog case, not SSD in general ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+, WM, desktops and CSD
Hi all, I am not one of them, but there are a lot of people (including KDE devs apparently) concerned about CSD because it means different decorations depending on the apps/toolkit = Consistency might suffer. Currently, it's up to the apps/toolkits to tell the WM they want to remain undecorated (via Motif MWM hints) so that they can manage their decorations themselves. GTK+ can optionally use CSD for its dialogs as well via a specific setting. I would like to evaluate a different approach, the opposite way actually, instead of the apps deciding to go with CSD or SSD, it would be up to the DE to set a hint telling the apps if they /should/ prefer CSD or SSD. The DE /may/ expose that option to the user (or not), up to the DE devs to decide. I think it's very little change in GTK+ as it's already able to do both SSD and CSD (currently, decision to use CSD or SSD being made at run time based on the availability of a compositor). gnome-shell (or any other WM) would just have to set the relevant hint to tell the apps to prefer CSD. Apps that cannot or don't know how to do CSD would still be decorated, just like now = The final word still remains to the applications, just like now. Since GTK+ has different backends for Wayland or Mir, those would remain unaffected (and still prefer CSD, unless someone wants to add a similar mechanism for Wayland - /me looks at KDE). I am willing to work on patches for that on my spare time (I do expect these to be minimal), but before I spend some time on this, I'd like to evaluate the chances of such an idea to be accepted... Was this already discussed in the past maybe? Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk3 MacOS (OSX) context menu issues
2015-03-03 15:01 GMT+06:00 Vest . vest...@gmail.com: Hello Konstantin, I apologize that I probably cannot help you, but I am curious. Do you have this issue, if you run a simple demo, where GtkMenu is used? Because it seems that when you move the mouse outside of the menu's boundaries, something inside the widget is cleared and the menu receives mouse events again. Kind regards, Vest Hello, Vest! Thank you for responding! I have tested the gtk3-demo and (surprise!) the issue seems to be 100%-reproducible there. Here I have recorded a video - http://youtu.be/X_xAHhQN_lY Have tested this with GTK 3.14.8 and 3.14.9. Also tested on 32bit and 64bit. Issue persists. I have tried to build with X11 backend and issue doesn't happen. So, it seems to be Quartz-only. I can provide a bash script that I use to unwrap all environment (creates MacPorts installation from scratch in the custom location and builds our application - Synfig Studio). Any help/advice is appreciated. Best Regards, Konstantin. On Sat, Feb 28, 2015 at 12:59 PM, Konstantin Dmitriev ksee.zelga...@gmail.com wrote: Hello! My name is Konstantin Dmitriev, I am a maintainer of Synfig Studio open-source animation software. Recently we have ported our software from Gtk2 to Gtk3. Unfortunately, after that we have encountered issues with context menus on OSX - the context menus are become insensitive sometimes. This happens randomly, but quite often. I have recorded a video to illustrate the problem - http://www.youtube.com/watch?v=Cscz45WeFEs I am stuck with this issue and don't know how to solve it. Any help, hints, suggestions are highly appreciated. Some information about the build environment: Gtk version 3.14.8, everything built through MacPorts environment. Gtk backend type: XQuartz. I will be happy to provide any additional information. Thank you! Konstantin. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+, WM, desktops and CSD
+gtk-devel-list Argh sorry, I didn't mean to make that email private, thought my mailer would copy the list as well, my bad :( On 5 March 2015 at 19:29, Olivier Fourdan four...@gmail.com wrote: Emmanuele, Let's face it, I doubt GTK+ will ever dominate the world, so the it's not consistent because we're not using a single toolkit is not going to be solved overnight. And frankly, as much as I like GTK+, I do not wish other toolkits to go away either, so we shall have to deal with heterogeneous toolkits for any foreseeable future. GTK already check for a compositor and detecting the DE to adapt is really not a good approach, it doesn't scale, and worse it ends up being really confusing (I can't remember which famous app was doing that, but I do remember that we ended up pretending to be gnome in the session just so it would work reliably...). As I wrote, the final word would remain the to apps, just like now, all I'm proposing is to replace the decision made by GTK to use CSD based on a compositor with a hint from the DE instead, nothing more. Cheers, Olivier On 5 March 2015 at 19:18, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com wrote: I am not one of them, but there are a lot of people (including KDE devs apparently) concerned about CSD because it means different decorations depending on the apps/toolkit = Consistency might suffer. I don't strictly buy the consistency argument at all. Right now, on my desktop, I have open two different browsers — Firefox and Chrome — that do not look like anything on my desktop. I also have an office suite using its own toolkit which passes a slight resemblance to GTK, if I squint my eyes and tilt my head a bit. If I were so inclined, I could be probably running some non-GTK applications, and those would look fairly different. There's no consistency because we're not running a platform with a single toolkit. If you're referring to the window controls, you can specify them even for GTK windows using client-side decorations; it's a setting that can be changed to reflect your environment — that's why both server-side and client-side decorated GTK windows have the same buttons. I think it's very little change in GTK+ as it's already able to do both SSD and CSD (currently, decision to use CSD or SSD being made at run time based on the availability of a compositor). That's not entirely correct. The decision to use client-side decorations is up to the application developers, not to the toolkit. An application developer may decide to support both the UIs, and opt for client-side decorations if they detect that the application is running under GNOME, but the toolkit is only tangentially involved. The only place where GTK decides to use an header bar or not is for the dialog windows it creates — file selection dialogs, print dialogs, color selection dialogs, etc. Those are under the control of the toolkit, so the toolkit can make a decision. The UI of an application, on the other hand, is the remit of its developer. The toolkit cannot really move widgets around, because it's missing context to do so. If I use a GtkHeaderBar with a button at the top left, and the environment does not support CSD properly, where should the toolkit put that button? Keep the header bar, but still have decorations on top, thus replicating things like titles? Your proposal for an hint could be simply solved with a check on whether the screen is composited (which is already available) and/or a check on the desktop environment. Sure, we can add a freedesktop.org spec that tells us if the application is running under GNOME, KDE, XFCE, or whatever. Obviously, it all breaks apart as soon as choice is factored in — if somebody is running under KDE with KWin without compositing, what would the environment be? Same with XFCE running with another window manager. Let's ignore that for a minute, though, and figure out the issues of such a hint. • How does that hint get specified? Is it an X11 property on the root window? • How does it get monitored? What happens if the user changes the setting at run time? Do we get a client message? • How are applications supposed to react when that setting is found, or when it changes? Do they ship with two different UIs, one for CSD and one for SSD? • What happens if the application does not have two UIs? Is the setting ignored, and the application stays with client-side decorations even if the window manager does not support the Motif WM hints? At the end of the day, though, if the application developer decides to use a GtkHeaderBar and client-side decorations, it's the application developer's prerogative to have their wish obeyed. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org
Re: GTK+, WM, desktops and CSD
Hi; On 5 March 2015 at 17:51, Olivier Fourdan four...@gmail.com wrote: I am not one of them, but there are a lot of people (including KDE devs apparently) concerned about CSD because it means different decorations depending on the apps/toolkit = Consistency might suffer. I don't strictly buy the consistency argument at all. Right now, on my desktop, I have open two different browsers — Firefox and Chrome — that do not look like anything on my desktop. I also have an office suite using its own toolkit which passes a slight resemblance to GTK, if I squint my eyes and tilt my head a bit. If I were so inclined, I could be probably running some non-GTK applications, and those would look fairly different. There's no consistency because we're not running a platform with a single toolkit. If you're referring to the window controls, you can specify them even for GTK windows using client-side decorations; it's a setting that can be changed to reflect your environment — that's why both server-side and client-side decorated GTK windows have the same buttons. I think it's very little change in GTK+ as it's already able to do both SSD and CSD (currently, decision to use CSD or SSD being made at run time based on the availability of a compositor). That's not entirely correct. The decision to use client-side decorations is up to the application developers, not to the toolkit. An application developer may decide to support both the UIs, and opt for client-side decorations if they detect that the application is running under GNOME, but the toolkit is only tangentially involved. The only place where GTK decides to use an header bar or not is for the dialog windows it creates — file selection dialogs, print dialogs, color selection dialogs, etc. Those are under the control of the toolkit, so the toolkit can make a decision. The UI of an application, on the other hand, is the remit of its developer. The toolkit cannot really move widgets around, because it's missing context to do so. If I use a GtkHeaderBar with a button at the top left, and the environment does not support CSD properly, where should the toolkit put that button? Keep the header bar, but still have decorations on top, thus replicating things like titles? Your proposal for an hint could be simply solved with a check on whether the screen is composited (which is already available) and/or a check on the desktop environment. Sure, we can add a freedesktop.org spec that tells us if the application is running under GNOME, KDE, XFCE, or whatever. Obviously, it all breaks apart as soon as choice is factored in — if somebody is running under KDE with KWin without compositing, what would the environment be? Same with XFCE running with another window manager. Let's ignore that for a minute, though, and figure out the issues of such a hint. • How does that hint get specified? Is it an X11 property on the root window? • How does it get monitored? What happens if the user changes the setting at run time? Do we get a client message? • How are applications supposed to react when that setting is found, or when it changes? Do they ship with two different UIs, one for CSD and one for SSD? • What happens if the application does not have two UIs? Is the setting ignored, and the application stays with client-side decorations even if the window manager does not support the Motif WM hints? At the end of the day, though, if the application developer decides to use a GtkHeaderBar and client-side decorations, it's the application developer's prerogative to have their wish obeyed. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
On Thu, Mar 5, 2015 at 6:52 PM Olivier Fourdan four...@gmail.com wrote: Apps that cannot or don't know how to do CSD would still be decorated, just like now = The final word still remains to the applications, just like now. What about apps that rely on CSD for part of their UI? Will those have the final word as well, or are they just screwed? I am willing to work on patches for that on my spare time (I do expect these to be minimal) If the DE has the final word on whether apps are allowed to use CSD, then a lot of GNOME applications would need an alternative UI, which is not a minimal change. On the other hand if the app has the final word, then they already have the option to provide a different UI in different environments[0] ... [0] https://wiki.gnome.org/HowDoI/AlternateMenubarLayout ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
Copying the list as well, sorry... On 5 March 2015 at 19:32, Olivier Fourdan four...@gmail.com wrote: Hi Florian, On 5 March 2015 at 19:17, Florian Müllner fmuell...@gnome.org wrote: What about apps that rely on CSD for part of their UI? Will those have the final word as well, or are they just screwed? The same as now without a compositor :) If the DE has the final word on whether apps are allowed to use CSD, then a lot of GNOME applications would need an alternative UI, which is not a minimal change. The DE doesn't have the final word, the DE just sets a hint indicating GTK to prefer CSD or SSD. On the other hand if the app has the final word, then they already have the option to provide a different UI in different environments[0] ... Yeap, that's a god idea, but that's for menubar, I am referring to decorations. [0] https://wiki.gnome.org/HowDoI/AlternateMenubarLayout Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+, WM, desktops and CSD
Hi; On 5 March 2015 at 18:29, Olivier Fourdan four...@gmail.com wrote: Emmanuele, Let's face it, I doubt GTK+ will ever dominate the world, so the it's not consistent because we're not using a single toolkit is not going to be solved overnight. And frankly, as much as I like GTK+, I do not wish other toolkits to go away either, so we shall have to deal with heterogeneous toolkits for any foreseeable future. That's not what I was saying. I'm saying that precisely because we don't have an homogeneous environment you cannot use the it's inconsistent argument. It will always be inconsistent, for one reason or for another. As I wrote, the final word would remain the to apps, just like now, all I'm proposing is to replace the decision made by GTK to use CSD based on a compositor with a hint from the DE instead, nothing more. You've conveniently ignored all the issues I've raised, so I'll just reiterate them, in the hope you have an answer instead of general handwaving: • How does that hint get specified? Is it an X11 property on the root window? • How does it get monitored? What happens if the user changes the setting at run time? Do we get a client message? • How are applications supposed to react when that setting is found, or when it changes? Do they ship with two different UIs, one for CSD and one for SSD? • What happens if the application does not have two UIs? Is the setting ignored, and the application stays with client-side decorations even if the window manager does not support the Motif WM hints? Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to make a GtkButton respond to a key press
On 15-03-05 07:58 PM, Michael Torrie wrote: Maybe I'm just not reading right, but I cannot figure out how to make a GtkButton respond to a single key press. For example, if I made a simple calculator like the one that comes with Gnome, how can I make it so when I press '1' on my keyboard, the 1 button presses. I know how to make shortcuts with a control key by just putting in an in the label. But not just a bare key press. Also is it possible to programmatically depress and then release a GtkButton, simulating a click? I'd like to do this to generate some user feedback when the keyboard is used, while allowing one to still click with a mouse (or finger or whatever) on the GtkButton. Pointing me at the right docs would be appreciated. Gtk3 is fine. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list I presume you have a callback function connected to the button press event. Just create code to intercept the keyboard event and go to a callback function that sees what key was pressed and then calls the same function that would have been called had the button been pressed. The first example I found from Google was http://stackoverflow.com/questions/10134956/in-simple-gtk-key-press-event-example-gdk-shift-mask-seems-to-be-ignored You can see the code you need to intercept the keyboard event. I do exactly this sort of thing in programs with the user being able to hit a select keyboard key or click the button (although I am using gtkmm3). jim... Jim Charlton ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
