REMINDER: List moved to Discourse; archival in 1 week
Hi all; next week, on May 1st, this list will be archived[0]. This means no new subscriptions, and no new email. If you have questions about GTK, GLib, and the rest of the core GNOME development platform, you can use the Discourse[1] instance hosted on GNOME infrastructure; we have a Platform/Core category, and we can use appropriate tags that you can watch[2] and filter on. You can use existing single-sign on systems, like Google and Github, to authenticate yourself; if you have a GNOME LDAP account already, you're strongly encouraged to use that method of authentication. You can still use email to interact with Discourse, and a guide is available[3] to configure your account. If you have any questions or feedback on Discourse, please use the appropriate category[4]. Ciao, Emmanuele. [0]: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg00024.html [1]: https://discourse.gnome.org [2]: https://discourse.gnome.org/t/tags-and-watching/94 [3]: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 [4]: https://discourse.gnome.org/c/site-feedback -- 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
ANNOUNCE: Phasing out GTK mailing lists and move to Discord
Hi all; as announced in: https://mail.gnome.org/archives/gtk-devel-list/2019-March/msg0.html we have created a Discourse instance available at: https://discourse.gnome.org After testing it for the past couple of weeks, we're very satisfied with how the platform behaves, so we are going to officially migrate all GTK-related discussion lists over to Discourse. This means the following mailing lists: - gtk-devel-list - gtk-app-devel-list - gtk-list Will be closed and archived on May 1st, 2019. The archives will remain public, but you won't be able to subscribe or send emails to the list. If you're subscribed to any of those lists you will receive a link to Discourse where you'll be able to create an account on that platform; you can also use other single sign-on systems, like Google or GitHub; and if you have an LDAP account on gnome.org, you're strongly encouraged to use that account. For further information on Discourse, please see the following topics: - https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 - https://discourse.gnome.org/t/tags-and-watching/94 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::Widget::is_mapped ()
No, it's not. The issue is not GTK: it's the windowing system. With the advent of compositing, all windows are "visible" all the time, from a toolkit perspective. The compositor is responsible for building what's presented to the user. For example: are windows fully visible when doing an "exposé"-like view? Are they not? If the compositor is ultimately responsible of creating the final result of what's on the screen, it could put each window on separate planets as far as the toolkit is concerned (assuming latency and coordinate space size aren't a problem). On Wayland is even "worse", because each window surface is completely separate from every other window surface by design; each window has its own coordinate system, that has an origin in the top-left corner of the window. A window *cannot* be obscured by another window, as far as the toolkit is concerned. If you're targeting an X11 system from the late '90s/early '00s, then visibility notifications *may* be emitted (though they are never guaranteed). On anything more modern than that, or on Wayland/Windows/macOS, visibility notification events are either non-sensical, not emitted, or not possible by design. This is why I said: "there is no way to know". Ciao, Emmanuele. On Sun, 3 Mar 2019 at 16:10, Paul Davis wrote: > > > > On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list < > gtk-devel-list@gnome.org> wrote: > >> On Sun, 3 Mar 2019 at 12:58, John Emmas wrote: >> >>> >> For example... let's say the widget is a top-level window. If it's >>> currently displayed on screen but there's some other window hiding it >>> (maybe from a totally different app) would 'is_visible()' return true or >>> false? >>> >> >> That's entirely different, and you should have said so at the very >> beginning of the thread. Yes, both "visible" and "mapped" would be set to >> true because you called show() on the window, and a window has no parents, >> so once it's visible and realized, it'll be mapped as well; there is no way >> to know, from a toolkit perspective, if a top level is being partially, or >> totally, covered by some other window, either in the same process or from a >> different process. That information is only available to the window manager. >> > > John should really know that there's code to do this (to the best extent > possible) within the Ardour source code at > libs/gtkmm2ext/visibility_tracker.cc :))) > > It works (to whatever extent it does work) by handling GtkEventVisibility > notifications. Hopefully this is still possible in GTK3 ? > > -- 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::Widget::is_mapped ()
On Sun, 3 Mar 2019 at 12:58, John Emmas wrote: > On 03/03/2019 11:22, Emmanuele Bassi wrote: > > On Sun, 3 Mar 2019 at 11:09, John Emmas wrote: > >> Sorry to ask a dumb question... >> >> What does it mean if a widget is "mapped" ? >> > > It means that: > > - the widget is visible > - the widget is realized > - all its ancestors up to the top level window are mapped > > Thanks Emmanuele - can I just check 'is_visible()'? Does it mean > 'literally visible' or 'capable of being visible'? > If it were enough, why would we have two flags? :-) The "visible" property means "you, or something else, called gtk_widget_show()" on the widget. A widget can be visible and not have any parent, for instance. If you want to know that a widget is going to be drawn, and respond to events, then you have to check the "mapped" state. For example... let's say the widget is a top-level window. If it's > currently displayed on screen but there's some other window hiding it > (maybe from a totally different app) would 'is_visible()' return true or > false? > That's entirely different, and you should have said so at the very beginning of the thread. Yes, both "visible" and "mapped" would be set to true because you called show() on the window, and a window has no parents, so once it's visible and realized, it'll be mapped as well; there is no way to know, from a toolkit perspective, if a top level is being partially, or totally, covered by some other window, either in the same process or from a different process. That information is only available to the window manager. 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::Widget::is_mapped ()
On Sun, 3 Mar 2019 at 11:09, John Emmas wrote: > Sorry to ask a dumb question... > > What does it mean if a widget is "mapped" ? > It means that: - the widget is visible - the widget is realized - all its ancestors up to the top level window are mapped Only mapped widgets are drawn and can receive events. 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: Discourse instance
Note: for those who prefer email, we've written down a handy guide on how to use email with Discourse: https://discourse.gnome.org/t/interacting-with-discourse-via-email/46 Ciao, Emmanuele. On Fri, 1 Mar 2019 at 15:50, Emmanuele Bassi wrote: > And, of course, I forgot the link: https://discourse.gnome.org > > Embarrassing. > > Ciao, > Emmanuele. > > On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi wrote: > >> Hi all; >> >> after the discussion[1] last month, and the feedback received (both on >> list and off), we decided to trial a Discourse instance on the GNOME >> infrastructure. >> >> The Platform/Core sub-category is meant to be used for all discussions >> about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME >> stack. >> >> Email is still allowed for both posting and replying, though I strongly >> encourage people to give the web UI a try; it's really nice. >> >> Feedback is very much appreciated. >> >> Ciao, >> Emmanuele. >> >> [1]: >> https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html >> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] >> > > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- 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: Discourse instance
And, of course, I forgot the link: https://discourse.gnome.org Embarrassing. Ciao, Emmanuele. On Fri, 1 Mar 2019 at 15:41, Emmanuele Bassi wrote: > Hi all; > > after the discussion[1] last month, and the feedback received (both on > list and off), we decided to trial a Discourse instance on the GNOME > infrastructure. > > The Platform/Core sub-category is meant to be used for all discussions > about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME > stack. > > Email is still allowed for both posting and replying, though I strongly > encourage people to give the web UI a try; it's really nice. > > Feedback is very much appreciated. > > Ciao, > Emmanuele. > > [1]: > https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html > > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- 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
Discourse instance
Hi all; after the discussion[1] last month, and the feedback received (both on list and off), we decided to trial a Discourse instance on the GNOME infrastructure. The Platform/Core sub-category is meant to be used for all discussions about GTK, GLib, GdkPixbuf, Pango, and other core libraries of the GNOME stack. Email is still allowed for both posting and replying, though I strongly encourage people to give the web UI a try; it's really nice. Feedback is very much appreciated. Ciao, Emmanuele. [1]: https://mail.gnome.org/archives/gtk-devel-list/2019-February/msg1.html -- 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: Moving from mailing lists to Discourse
On Wed, 6 Feb 2019 at 12:19, Emmanuele Bassi wrote: > > The main differences are that you’d need a different subscription account > than the existing one, and that you wouldn’t have the weekly digests, as > far as I can see. > It turns out I was wrong: Discourse has "weekly summaries" as well. As for the subscription: Discourse supports multiple identity providers—Google, Facebook, Instagram, Twitter, Yahoo, and GitHub are all supported, and there's a plugin available for GitLab authentication as well, so we might be able to automatically authenticate existing GTK contributors with an account on gitlab.gnome.org. 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: Moving from mailing lists to Discourse
On Thu, 7 Feb 2019 at 00:54, wrote: > > We already looked at Hyperkitty, and found it fairly limited in > > functionality. Avoiding Hyperkitty is what led us to Discourse in the > > first place. > Can you link that discussion please? It was on IRC and in person discussions, and private emails between various people. > I'm interested what newcomers want > to do such that Hyperkitty doesn't let. Negatives of Discourse: loads > slower, broken without evergreen CSS and JS, huge blank margins. Fedora > uses Hyperkitty on its other, non-Silverblue lists. > We asked Fedora developers for their experiences, and they weren't overly impressed with it. Off the top of my head (and after using Hyperkitty to browse Fedora desktop and devel mailing lists for the last couple of years): - Hyperkitty's UX is confusing, cluttered to the point of being unhelpful - navigating through recent discussions never makes it clear which emails are newer, and the fake threading makes it visually harder to scan - searching is a disaster, with results returned without any sense of what's relevant or not - mobile access is pretty much not supported - it's all just a front to a mailman, instead of being a whole packaged software; this means: - harder to set up and upgrade - no moderation tools - no categories, sub-categories, or tagging to organise email - no integration with services or additional plugins In general, mailman3 + hyperkitty is a somewhat good upgrade on mailman2 (even though I still prefer the old archive pages compared to hyperkitty; I've been going through those *a lot* for my "History of GNOME" project), but it does not compare to other platforms like Discourse. 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: Moving from mailing lists to Discourse
More information on Discourse: - About: https://www.discourse.org/about - Features: https://www.discourse.org/features Discourse is a forum software that has multiple ways to access it: web, native apps, and email. It's not a mailing list software with a web frontend. The interesting (to me) parts are: - 2FA instead of Mailman's plaintext password - real moderation tools, that can scale with the community and encourage civility and code of conduct compliant behaviour - anti-spam measures - open source software (kind of a pre-requisite) - good UI for reading and replying to topics The Fedora (Silverblue) and Ubuntu communities already use Discourse, for instance; the SDL community also does. Ciao, Emmanuele. On Wed, 6 Feb 2019 at 12:46, Emmanuele Bassi wrote: > [Cross-posted to various relevant mailing lists; please, reply to > gtk-devel-list] > > As part of an attempt at making GTK more friendly to newcomers, I and > other core developers were thinking of moving the mailing lists from the > current mailman installation to Discourse: > > https://discourse.org/ > > Possibly still hosted on GNOME infrastructure, depending on the > requirements for our sysadmins. > > The GTK project would have various sub-topics, mostly around development > with and of GTK. Having a better archive search, a better moderation > system, and a decent web UI are the major selling points for switching to > Discourse. The fact that the project is also open source is neatly aligned > with our values. > > Are there any objections? Did somebody already try out Discourse and has > opinions about it that they want to share with the community? > > Ciao, > Emmanuele. > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > -- 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: Moving from mailing lists to Discourse
On Wed, 6 Feb 2019 at 15:11, Charles Lindsey wrote: > > > On 06/02/2019 11:46, Emmanuele Bassi via gtk-devel-list wrote: > > [Cross-posted to various relevant mailing lists; please, reply to > > gtk-devel-list] > > > > As part of an attempt at making GTK more friendly to newcomers, I and > other > > core developers were thinking of moving the mailing lists from the > current > > mailman installation to Discourse: > > > >https://discourse.org/ > > > > Possibly still hosted on GNOME infrastructure, depending on the > > requirements for our sysadmins. > > > Are there any objections? Did somebody already try out Discourse and has > > opinions about it that they want to share with the community? > > Does that mean I have to log in to Discourse every day just to check > whether > some new message has arrived? If so, then no thank you. No, you could still get email notifications for messages, and you could still send email replies; that's supported on Discourse, as you could easily check on their website. > This is a low volume > list, often with two or more weeks between messages. > Yes, the *gtk-devel-list* mailing list is low volume, compared to gtk-app-devel-list and gtk-list. Did you ever wonder why it is? Mostly because mailing lists are kind of terrible. The idea behind switching to Discourse is to improve the communication channels available to GTK developers and users to something more useful than email. 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: Moving from mailing lists to Discourse
Hi; On Wed, 6 Feb 2019 at 13:10, Reuben Rissler wrote: > > To introduce myself, I only am using Gtk for 3 years, but really like > the infrastructure / people / open source surrounding Gtk. I am > sometimes seen as 'theGtknerd'. > > > On 02/06/2019 06:46 AM, Emmanuele Bassi via gtk-devel-list wrote: > > > > The GTK project would have various sub-topics, mostly around > > development with and of GTK. Having a better archive search, a better > > moderation system, and a decent web UI are the major selling points > > for switching to Discourse. The fact that the project is also open > > source is neatly aligned with our values. > Let me ask a poignant question, was moderation ever a problem with > mailing lists? As the person that moderates two out of the three GTK mailing lists, yes: it’s somewhat annoying the amount of spam going on every day. Not terrible, but it’d be nice not to have to deal with it. Additionally, Discourse would allow us to deal with code of conduct violations in a much better way than mailman currently lets us. > > > > Are there any objections? Did somebody already try out Discourse and > > has opinions about it that they want to share with the community? > I have a computer that is email only for work (no web browser for > several personal reasons). I could no longer be a part of the Gtk > responders as far as I can see. That’s not accurate: Discourse also works with email, so you’d receive email messages and you’d be able to reply to email messages. The main differences are that you’d need a different subscription account than the existing one, and that you wouldn’t have the weekly digests, as far as I can see. 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
Moving from mailing lists to Discourse
[Cross-posted to various relevant mailing lists; please, reply to gtk-devel-list] As part of an attempt at making GTK more friendly to newcomers, I and other core developers were thinking of moving the mailing lists from the current mailman installation to Discourse: https://discourse.org/ Possibly still hosted on GNOME infrastructure, depending on the requirements for our sysadmins. The GTK project would have various sub-topics, mostly around development with and of GTK. Having a better archive search, a better moderation system, and a decent web UI are the major selling points for switching to Discourse. The fact that the project is also open source is neatly aligned with our values. Are there any objections? Did somebody already try out Discourse and has opinions about it that they want to share with the community? 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
Project rename to "GTK"
Hi all; tl;dr: GTK is GTK, not GTK+. The documentation has been updated, and the pkg-config file for the future 4.0 major release is now called "gtk4" over the years, we had discussions about removing the "+" from the project name. The "plus" was added to "GTK" once it was moved out of the GIMP sources tree and the project gained utilities like GLib and the GTK type system, in order to distinguish it from the previous, in-tree version. Very few people are aware of this history, and it's kind of confusing from the perspective of both newcomers and even expert users; people join the wrong IRC channel, the URLs on wikis are fairly ugly, etc. With the move to Git, years ago, we had to add a couple of hacks to allow for the "plus" to stay in the repository browsing UI; those hacks were dropped once we moved to GitLab. We discussed again during IRC meetings and hackfests whether to drop the "plus", and we finally decided to do so. With the work in the master branch towards the 4.0 release, it's finally time to say goodbye to the "plus" in "GTK+". The documentation is updated so that the project in named consistently. The removal of the plus has a side effect on the name of the pkg-config file for GTK 4; additionally, since we don't break API across the same major version, having a fully qualified major.minor version in the pkg-config file is redundant. This means that the pkg-config file for GTK 4 is going to be called "gtk4". Incidentally, the IRC channel on irc.gnome.org is now called "#gtk"; there's a re-direct in place, so if you join "#gtk+" you'll end up in the right place. 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: An alternative to gdk-pixbuf
On Sun, 16 Sep 2018 at 10:47, John Emmas wrote: > On 15/09/2018 18:48, John Emmas wrote: > > > > Do you happen to know if the tiff library has its own mailing list? I > > haven't had much success in finding one > > > > In fact I'll need the mailing list for gdk-pixbuf now - except that I > can't find that one either!! (or is this the correct place for reporting > gdk-pixbuf issues?) > > The correct way to report issues for gdk-pixbuf: 1. use the issue tracker: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/new 2. do not attach to an existing, unrelated thread on a mailing list; create a new topic instead For discussions, you can use this mailing list—but issues should strictly be reported on the issue tracker. 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: Problems with git.gnome.org
Are you trying to access a repository using a `git://` URL? That has been deprecated a long time ago, for security reasons, and with GitLab it was removed altogether. Ciao, Emmanuele. On Thu, 6 Sep 2018 at 14:09, John Emmas wrote: > Hi guys - sorry for posting this here but I've tried gnome's > 'gitlab-issues' mailing list and couldn't get any response. Maybe > someone here can help..? > > For the past few weeks I've been seeing errors if I try to update (i.e. > pull) certain libraries from git (e.g. pango / pangomm / gtkmm etc). > Here's what I see... > > Looking up git.gnome.org ... done. > Connecting to git.gnome.org (port 9418) ... fatal: unable to > connect to git.gnome.org > git.gnome.org[0: 209.132.180.168]: errno=No error > git.gnome.org[1: 209.132.180.180]: errno=No error > > At first I assumed the repos were down temporarily but it's not getting > any better so I'm guessing the libraries have been moved somewhere > else? So do I maybe need to change something at my end? > > It doesn't seem to be affecting all my gtk support libs BTW - just some > of them... Thanks, > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- 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: An alternative to gdk-pixbuf
On Wed, 5 Sep 2018 at 19:25, Magnus Bergman wrote: > On Wed, 5 Sep 2018 17:28:22 +0100 > Emmanuele Bassi wrote: > > > We're phasing out Cairo in favour of the CSS rendering model, > > implemented on top of OpenGL and Vulkan, as it's the API that most > > closely matches the requirements of GTK. > > I'm not sure I quite understand what you are saying. What does this > mean for image loading if terms of actual implementation? What would > ideally happen then GTK+ needs to load an image (because the > application called gtk_image_new_from_file() for example)? > > We're still using GdkPixbuf, and for the 4.0 API series we still have GdkPixbuf types exposed in the GTK API. For future API series (5.x, 6.x, …) we may revisit this, with the option of moving icon loading into GTK itself. > > Cairo is still used as a fallback mechanism — both when running on > > platforms without support for OpenGL or Vulkan, and in the interim > > period while the GL/Vulkan rendering pipelines inside GTK don't > > support a CSS feature. Additionally, you may still use Cairo for 2D > > high quality rendering, for printing and for custom drawing. > > But then it comes to printing and custom drawing I'm on my own then it > comes to loading the images? Which is okey of course since gdk-pixbuf > is kind of a separate library already. But isn't it a good thing to > share common image loading code? > Not really; icons—especially ones that are identified via icon theme names—are a very narrow subset of "all the possible images and formats in human history". Gegl is great for image editing. But not as much for simple viewing. This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi display I'm already pushing gdk-pixbuf and cairo to their limits because of the scaling factor applied to the window — not only the buffer gets loaded uncompressed to allow for zooming, but the image viewer needs to render a CPU-scaled down copy of the image. Sure, for viewing a 500x400px image macro for a meme we're fine; but we're fine with gdk-pixbuf as well, so there's really no need to change to a different image loading library. > It doesn't do animation Animated formats are a dying breed, and they have all but killed by VP9 and new, web-friendly video formats. Social platforms will take a GIF and turn it into a video transparently. Additionally, GTK 4.x already has new API to render videos and other frame-based media sources through GStreamer. > From the perspective of a consumer of GdkPixbuf, the only thing that > > an image loading library should do is, pretty literally, load images. > > No scaling, no compositing, no rendering. Saving to a file may be > > interesting — but that opens the whole transcoding can of worms, so > > maybe it should just be a debugging feature. Ideally, I/O operations > > should happen in a separate thread, and possible use multi-threading > > to chunk out the work on multiple cores; it definitely needs to > > integrate with GIO, as it's a modern API that well maps to GUIs. > > Yes, I very much agree with this. Except I think it has to do rendering > of some sort. If an image contains a triangle, it has to be converted to > a function call that renders it (using OpenGL/Vulcan/cairo) somehow. > That's up to the toolkit, as it's going to be the one deciding how to render the rest of the UI. There's no way for you to know, from the outside, how to efficiently render anything. That's why it's much, much better to get a memory buffer with the contents of the image, and let the toolkit pass it to the GPU. Vector formats are different, but that's why we have API like Cairo or Skia; I'm also waiting for web browsers to implement SVG rendering on the GPU where possible, with the help of new primitives from the GL/Vulkan implementation. > In the near future, I'll very likely deprecate most of GdkPixbuf's > > API, except for the I/O operations; I'd also be happy to seal off > > most of its internals, within the ABI stability promise, to avoid > > leakage of internal state. > > Will the loader plugin API go away, you think? > No API will ever go away: there are no plans for a gdk-pixbuf-3.0. The deprecations would mostly apply to API that is either long since been replaced by Cairo (scale/composite), or that is weirdly ad hoc, like saturate_and_pixelate(). Ideally, I'd like to deprecate the option to build gdk-pixbuf without depending on GIO to do MIME type sniffing, as GIO has been fixed to work on Windows and macOS, and it is a required dependency anyway. The animation API is pretty much a garbage fire, so it may go on the chopping block as well. Of course, deprecated API will keep working as well—or as badly—as it works today, so people can still use it. Moving pixbuf loaders to separate processes, and wrap them in sandboxes, would be a fairly good thing to do; it need to be decided at run time, though, because there are many users of GdkPixbuf that already run in a sandbox, which prevents creating smalle
Re: An alternative to gdk-pixbuf
Hi; On Tue, 4 Sep 2018 at 23:19, Magnus Bergman wrote: > Over the years it has been discussed from time to time to replace > gdk-pixbuf with something else[1][2]. Something was even in the making > (I guess over ten years ago) but it never replaced gdk-pixbuf > apparently. Now I don't even remember what it was called. And something > else called pig was proposed more recently. > > One major reason to replace gdk-pixbuf has been the long term goal to > phase out GDK in favour of cairo. And some people (including me) has > been displeased with the gdk-pixbuf API for more subtle reasons. It has > also been brough up that it lacks some features (which I guess are hard > to implement as an afterthought). I finally took some time to design an > image loading library on top of cairo called abydos, which at least > suits my needs. And also some needs mentioned in this list over the > years. First I thought it could suit the needs of GTK+ as well. But I > just learned that even cairo is now considered "legacy technology" by > the GTK+ developers[3], so I guess cairo is also being phased out now. > But in favour of what? We're phasing out Cairo in favour of the CSS rendering model, implemented on top of OpenGL and Vulkan, as it's the API that most closely matches the requirements of GTK. Cairo is still used as a fallback mechanism — both when running on platforms without support for OpenGL or Vulkan, and in the interim period while the GL/Vulkan rendering pipelines inside GTK don't support a CSS feature. Additionally, you may still use Cairo for 2D high quality rendering, for printing and for custom drawing. Internally, GTK only cares about GdkPixbuf in as much as it provides us with a way to load graphic assets like icons, which are typically in a very limited amount of formats. As far as we're concerned, image data coming from GdkPixbuf and Cairo gets loaded into memory buffers that get submitted to the GPU almost immediately, and all transformations and rendering happen using shaders, on the GPU. Anything bigger than an icon should probably be loaded and displayed through Gegl, the same library used by the GIMP; this is especially true if you're planning to process the image using filters. Images, these days, are pretty big buffers — and so are displays; using a simple linear buffer like GdkPixbuf's does not scale. >From the perspective of a consumer of GdkPixbuf, the only thing that an image loading library should do is, pretty literally, load images. No scaling, no compositing, no rendering. Saving to a file may be interesting — but that opens the whole transcoding can of worms, so maybe it should just be a debugging feature. Ideally, I/O operations should happen in a separate thread, and possible use multi-threading to chunk out the work on multiple cores; it definitely needs to integrate with GIO, as it's a modern API that well maps to GUIs. In the near future, I'll very likely deprecate most of GdkPixbuf's API, except for the I/O operations; I'd also be happy to seal off most of its internals, within the ABI stability promise, to avoid leakage of internal state. 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
