Re: Print dialog hangs for several seconds before activating
On Thu, Jun 10, 2010 at 9:38 AM, Alexander Larsson wrote: > On Wed, 2010-06-09 at 20:20 -0400, David A Benjamin wrote: >> I've run into this issue (and have been poking at it recently). The core >> problem appears to be that, although GTK+ is using CUPS and setting things >> like httpBlocking off, the CUPS "non-blocking" API isn't. See >> conversations with CUPS developers at [1,2,3]. > > Yeah, it seems like threads are the way to go. Dunno if this is related, but there is also bug 614581 that may help as well: https://bugzilla.gnome.org/show_bug.cgi?id=614581 which was committed as http://git.gnome.org/browse/gtk+/commit/?id=33097d65 HTH, Olivier. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk+ 2.10 and compositing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I noticed something really weird which seem to happen with gtk+ applications only. Other Xlib of Qt applications seems unaffected. When using a compositor (xfce's embedded compositor, KDE compositing effects, etc.), once a gtk+ window gets mapped on screen, it shows something that looks like a uninitialized pixmap for a second or so, and then the real contents gets displayed. It did not happen with gtk+-2.8 as fas as I can tell. With gtk+-2.8, there was a lag between the window creation and the content display, but the window was transparent so it was not as noticeable as with gtk+-2.10. It shows more with windows that take longer to fill, like menus with a lot of icons and entries (think panel menu for example) It seems that the contents of the drawable that gets copied (either from XCompositeNameWindowPixmap() or simply by using the drawable id) contents random data until the application actually fill its content and generate damage events. Any idea? Cheers, Olivier. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFKL1LFHBtvh5LRUARAhQdAKCM9pJj/kc8vRipWwJr7K0DTTo8bgCg37hE 1OWOAVmT7fdYstMcT7Kl2Vo= =N3oy -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ 2.10 and compositing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olivier Fourdan wrote: > Hi all, > > I noticed something really weird which seem to happen with gtk+ > applications only. Other Xlib of Qt applications seems unaffected. > > When using a compositor (xfce's embedded compositor, KDE compositing > effects, etc.), once a gtk+ window gets mapped on screen, it shows > something that looks like a uninitialized pixmap for a second or so, and > then the real contents gets displayed. Humm, never mind, gtk is not the problem. The problem is with Xorg 7.1. Sorry for the noise Olivier. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFKSVtFHBtvh5LRUARAvvnAJ98+17MBQc6oycyzFX5nRg29o6kTgCfQnWx jKozJdsmaMTfcntIZRwWO34= =k0BP -END PGP SIGNATURE- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://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: 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 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 wrote: >> Hi; >> >> On 5 March 2015 at 17:51, Olivier Fourdan 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 foun
Re: GTK+, WM, desktops and CSD
Copying the list as well, sorry... On 5 March 2015 at 19:32, Olivier Fourdan wrote: > Hi Florian, > > On 5 March 2015 at 19:17, Florian Müllner 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 Emmanuele, On 5 March 2015 at 20:04, Emmanuele Bassi 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
Hi On 5 March 2015 at 20:09, Emmanuele Bassi wrote: >>> On 5 March 2015 at 19:17, Florian Müllner 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 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
Hi Matthias, On 6 March 2015 at 02:12, Matthias Clasen wrote: > On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan wrote: > 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. I completely agree and this really wasn't my intention in the first place (thus the mention of CSD being a controversial topic at the beginning of the thread). I wouldn't want this thread to be hijacked to pursue some vendetta against CSD, GTK+ or any other particular concept/project. >> >> 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. Yeah, we discussed that in some bugzilla iirc :) > 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... Again, I won't disagree here, driving a cross-desktop spec to a wide consensus can be a daunting task. >> 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...) OK, I'll try to take a look at this, but I am not familiar with that particular code in GTK+, so don't hold your breath... 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, Besides, I don't think we should evaluate CSD in gtk+ based on Chromium implementation. IIRC Chromium moved away from gtk+ in favor of aura [1]. Cheers, Olivier [1] https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/Zpu9801pPRc On 23 March 2015 at 22:50, Jasper St. Pierre wrote: > > > On Mon, Mar 23, 2015 at 2:25 PM, Pavel Machek wrote: >> >> Hi! >> >> > 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. >> >> Consistency already suffers. Chromium pulls this trick, and it means >> you can't move such web browser to other workspace, easily (as right >> click produces useless Chromium's menu, while right click on normal >> windows produces expected WM's menu, including "move to another >> desktop"). >> >> > 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). >> >> If you are modifying protocol between WM and application, would it be >> possible to arrange "right click on title" event to windowmanager, so >> that it can display its full menu? > > > This request already exists. > > http://cgit.freedesktop.org/wayland/weston/tree/protocol/xdg-shell.xml#n187 > >> >> Thanks, >> Pavel >> >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) >> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >> ___ >> 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: [PATCH] Save Windows scancode inside GdkEvent
Hi Frediano, For gtk+, I reckon best is to file a bug in bugzilla.gnome.org (under platform/gtk+ and backend: win32) and attach your patch there for review. HTH, Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Save Windows scancode inside GdkEvent
Hi Frediano, On 19 April 2016 at 16:31, Frediano Ziglio wrote: > > > For gtk+, I reckon best is to file a bug in bugzilla.gnome.org (under > > platform/gtk+ and backend: win32) and attach your patch there for review. > > Opened https://bugzilla.gnome.org/show_bug.cgi?id=765259 > Hope to get some replies earlier than > https://bugzilla.gnome.org/show_bug.cgi?id=761102 You can also go to irc #gtk+ on gimpnet and ask for a review there, mentioning these bugs, if you reckon they've been languishing for too long. Cheers, Olivier ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
