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
Re: Demo/Sample for drag and drop
I found these quite good (even though I wasn't using ListBox; they can be generalised) https://blog.gtk.org/2017/04/23/drag-and-drop-in-lists/ https://blog.gtk.org/2017/06/01/drag-and-drop-in-lists-revisited/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Demo/Sample for drag and drop
Hi All, I am working with OpenJDK JavaFX dev group and we are facing some problems with drag and drop functionality with gtk3.20 or later. You can have a look at the bug for more information https://bugs.openjdk.java.net/browse/JDK-8211302 I am looking for a sample/demo for drag and drop functionality using gtk3. I can see that there is one demo at [1], but it is not compatible with gtk3 as it is using gtk4 specific structs and functions. I am not able to find any other working demo/sample working with gtk3. It would be great if anyone can point to me to something useful. [1] https://github.com/GNOME/gtk/blob/master/demos/gtk-demo/dnd.c -Pankaj ___ 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: Discourse instance
On 01.03.2019 20:17, Neil McGovern wrote: > On Fri, 2019-03-01 at 19:52 +0300, LRN via gtk-devel-list wrote: >> On 01.03.2019 18:41, Emmanuele Bassi via gtk-devel-list wrote: >>> Feedback is very much appreciated. >>> >> >> Need moar tags! >> > > Tag suggestions welcome :) > Well, what i mean is that i'd like to be able to be notified of topics that are relevant to me, and one way to do that is to allow topics to be tagged and allow people to subscribe to tags. Kind of like issues on gitlab are tagged, which allows me to be notified only of Windows-related issues. Unless the amount of new topics will be modest (kind of like gtk-devel-list right now), in which case i'd probably manage by just sorting out the new topics manually (i'm definitely going to use the email notification thing). Also, related: if i watch a topic, do i get email notifications for each message? If not, i'd have to enable the ML mode. Also, email notifications are issued once per topic, right? So, if the topic subject changes (like how an email thread can split by changing the topic), i won't be notified? signature.asc Description: OpenPGP digital signature _______________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Discourse instance
On 01.03.2019 18:41, Emmanuele Bassi via gtk-devel-list wrote: > Feedback is very much appreciated. > Need moar tags! signature.asc Description: OpenPGP digital signature _______ 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
Re: Discourse instance
Since you forgot the link... https://discourse.gnome.org/ -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Fri, Mar 1, 2019, 9:42 AM Emmanuele Bassi via gtk-devel-list < gtk-devel-list@gnome.org> 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] > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > _______ 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: Project rename to "GTK"
On Wed, Feb 6, 2019 at 10:23 AM Owen Taylor wrote: > > On Wed, Feb 6, 2019 at 5:04 AM Emmanuele Bassi via gtk-devel-list > wrote: > > > > 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. > > Thanks for moving this along! It's good to see the GTK name finally > get less confusing and easier to talk about! > > But to clarify the history, the "+" predates the point when GTK was > moved out of the GIMP tree. Every single version of GTK with publicly > released sources was called GTK+. As I understand it, Peter Mattis > added the + to mark a change from a very early version that was > structured more like Xt/Motif, to a version that had a fuller type > system with inheritance. To add a little more to this - Elijah Lynn pointed me to an answer he obtained from Peter on the subject - see https://unix.stackexchange.com/a/443832/27902 - GTK was the first version of the toolkit used in pre-1.0 versions of the GIMP. At some point, the architectural limitations were revealed and I rewrote and renamed it as GTK+. This too was used in pre-1.0 versions of the GIMP. I don't believe any project outside of the GIMP used GTK-(no-plus). Why a "+" instead of a version number? No reason other than whim. ~ Peter Mattis ___ 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 Pá, úno 8, 2019 at 11:53 PM, Reuben Rissler wrote: Thanks. But it probably isn't possible to open an issue for Gtk by emailing a specific email address on GitLab, or am I wrong? Only in Enterprise Edition Premium: https://gitlab.com/help/user/project/service_desk ___ 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
As has been mentioned, Discourse allows you to receive and via email, you would largely only use the web UI to sign up or change your settings. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Wed, Feb 6, 2019, 11:25 PM Felix Miata via gtk-devel-list < gtk-devel-list@gnome.org> wrote: > Emmanuele Bassi via gtk-devel-list composed on 2019-02-06 12:46 (UTC+0100): > > > Are there any objections? Did somebody already try out Discourse and has > > opinions about it that they want to share with the community? > > As happened when various mozilla dev mailing lists moved to discourse, I > ceased having anything to > do with those subjects. The same will happen if gtk mailing lists move to > discourse. Web sites and > all their CSS and JS interference and bandwidth overhead are no substitute > for plain legible text > email lists. > -- > Evolution as taught in public schools is religion, not science. > > Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! > > Felix Miata *** http://fm.no-ip.com/ > _______ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ 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
Emmanuele Bassi via gtk-devel-list composed on 2019-02-06 12:46 (UTC+0100): > Are there any objections? Did somebody already try out Discourse and has > opinions about it that they want to share with the community? As happened when various mozilla dev mailing lists moved to discourse, I ceased having anything to do with those subjects. The same will happen if gtk mailing lists move to discourse. Web sites and all their CSS and JS interference and bandwidth overhead are no substitute for plain legible text email lists. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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
makep...@firemail.cc composed on 2019-02-07 02:54 (UTC+0200): >> 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? 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. Hyperkitty made Fedora mailing lists a displeasure, like most of the rest of the web, scripts hiding things that previously were obvious and made inaccessible without scripting overhead enabled, overabundant whitespace, tiny gray text, short lists where 5X as many would otherwise fit. I avoid it as much as possible, trying to get answers from bugzilla.redhat.com or IRC or the archlinux wiki whenever possible instead. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.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
Hmm, unfortunately it was over some scattered IRC messages, I can try and find them in the logs if you like. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Wed, Feb 6, 2019, 8:38 PM wrote: > > I know someone who set up HyperKitty, it was a nightmare > > How so? Can you link their blog post? I'm not its user or developer, I > want to better understand the software choice. > _______ 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
I know someone who set up HyperKitty, it was a nightmare and still is a nightmare. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.com/ On Wed, Feb 6, 2019, 6:54 PM 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? 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. > _______________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___________ 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
As a side note, Python has also opened a Discourse instance (in addition to their Zulip experiment), and the results have pretty much been positive. I've also been on Fedora's for quite some time, and it's great. On Wed, Feb 6, 2019 at 5:46 AM Emmanuele Bassi via gtk-devel-list < gtk-devel-list@gnome.org> 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] > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else https://refi64.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 all, I'm very much in favor! Being able to still use e-mail while also having a convenient and pretty-looking interface is something I look *really* forward to. My only question is: what happens to the old archives? Do we keep them online as-is, or is there a plan to also migrate them? The former means of course less effort, but the latter would keep everything unified in one UI for example. I'm fine with whatever you choose :-) Thanks in any case for taking this up, Emmanuele! Cheers, nielsdg On Wed, Feb 6, 2019 at 3:42 PM Emmanuele Bassi via gtk-devel-list wrote: > > 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 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Project rename to "GTK"
On Wed, Feb 6, 2019 at 5:04 AM Emmanuele Bassi via gtk-devel-list wrote: > > 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. Thanks for moving this along! It's good to see the GTK name finally get less confusing and easier to talk about! But to clarify the history, the "+" predates the point when GTK was moved out of the GIMP tree. Every single version of GTK with publicly released sources was called GTK+. As I understand it, Peter Mattis added the + to mark a change from a very early version that was structured more like Xt/Motif, to a version that had a fuller type system with inheritance. Owen ___ 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
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
GTK meeting notes
Minutes of the GTK team meeting of January 7, 2019 Agenda: - Update on the GTK Hackfest after FOSDEM - Current state of GTK4 branches - Revert of A11Y focus changes in stable branches - Releases? Notes 1) Hackfest Venue is booked We have a wiki page Sufficient attendence confirmed Put agenda items on the wiki, please And book your rooms soon! 2) State of GTK4 branches listview branch: still quite in flux, but lots of things possible already. Matthias has started to look at it recently, will create a writeup together with Benjamin on state and remaining work. transformations branch: Emmanuele is reviewing it, will work on an MR wip/layout-manager branch: Current work-in-progress by Emmanuele on separating layout managers from containers. Current issues on master: - window resizing problems with wayland / gl (Matthias) - driver problems with vulkan (Emmanuele) - Adwaita has regressions and is out of sync with 3.24 Some discussion around the way forward for Adwaita. We have a branch with a theme refresh that is targeted for GNOME 3.32, but that might be radical enough that it breaks some apps targeting Adwaita. We could ship a beta-form NewAdwaita with the next 3.24.x release to give people time to try it out. Still need a better theme selection api, ultimatively. Currently we just have the theme name to go off. 3) General agreement that we should revert the a11y changes on 3.24, since they were breaking things too much. Carlos will look into it. 4) Releases were not discussed directly. Matthias will look at doing a 3.24.x release this week. Next meeting time: March 4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
OS X issues
Hey John, since you are one of our OS X contributors: It seems the 2.24.2 release from this week has some issues on OS X: https://gitlab.gnome.org/GNOME/gtk/issues/1517 https://gitlab.gnome.org/GNOME/gtk/issues/1518 We could really use your help here! I'd like to do a follow-up release before X-mas to fix a few other issues, and it would be great to take care of the OS X problems at the same time. Thanks in advance ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Quartz Coordinates
On Tue, Nov 20, 2018 at 8:06 AM John Ralls wrote: > I’m working on GdkQuartz to bring it up to date with the rest of Gdk. I’m > starting with GdkDisplay and GdkMonitor mostly because of > https://gitlab.gnome.org/GNOME/gtk/issues/1312. This question may also > bear upon https://gitlab.gnome.org/GNOME/gtk/issues/1029 as well as other > pointer coordinate issues some users have reported on downstream > applications. > > Under the old GdkScreen regime Gdk had a “root window” with 0,0 in the > upper left corner of the upper-left-most monitor and all point values are > unsigned, increasing down and to the right. Quartz uses a different > coordinate system with the origin at the bottom-left corner of the > “primary” monitor with point values increasing up and to the right. > Monitors placed below or to the left of the “primary” monitor will have > negative coordinates. gdkscreen-quartz and gdkwindow-quartz have conversion > code to create a fake root window and to translate between the two > coordinate systems. > > The new GdkDisplay/GdkMonitor regime does away with the root window and > introduces gdk_display_get_monitor_at_point and > gdk_display_get_monitor_at_window that iterate over the list of active > monitors testing for whether the coordinates of the point or window lie > inside each monitor’s work area. That’s great, it’s similar to the way > Quartz works... but are there any assumptions made about coordinates that > need translation between Gdk and Quartz? > > Yes, we haven't fully resolved this, in particular with respect to hi-dpi. It is still an open issue on the gtk4 roadmap: https://gitlab.gnome.org/GNOME/gtk/issues/1106 _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK meeting notes
At long last, another GTK team meeting! See notes below. Matthias --- Minutes of the GTK team meeting of December 10th, 2018 Agenda - Welcome EmmanueleBassi <https://wiki.gnome.org/EmmanueleBassi> - - GTK Hackfest at FOSDEM (or some other time/place ?) - - Listfest at FOSDEM - - 3.26 for Gnome 3.32 -- theme refresh -- more invasive changes during 3.24: https://gitlab.gnome.org/GNOME/gtk/merge_requests/391 - - Review GTK4 task list - - Revise GTK4 plan - - Website refresh for GTK4 - - Miscellaneous Notes 1) Meeting time and cadence Aiming for monthly meetings, first Monday of the month, 15:00 utc Next date: January 7, 2019 1) GTK Hackfest. Tentative dates: Mon - Wed after FOSDEM Location: Brussels We'll look at getting the same venue as this year Emmanuele volunteered for that, Matthias has contact info Will set up a wiki page to organize 2) Listfest Benjamin is trying to get this organized with various listbox consumers https://wiki.gnome.org/Hackfests/ListFest2018 3) 3.26 release ? Some concern about the scale of theme refresh going into 3.24 And some special-purpose new api needed for a statusicon regression fix Clash between expectations of minor gnome release vs micro gtk release Options: tone down theme changes keep the api private Inconclusive discussion, will revisit at hackfest 4) GTK4 tasks Not a lot of progress recently Matthias has been off doing other things Benjamin has a deep stack of unfinished changes that he is struggling to unwind Timm has an unreviewed transformation branch. Ebassi volunteered to review Big gtk4 blockers: popovers dnd Beyond that, need to identify end user and app developer features, write demos and advertise We have a media demo (puzzle) A blur demo (in tests) A 2.5 million files list box demo (in a branch) 5) Misc Some discussion around improving docs, tutorials, examples _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
compile error in GNOME Builder 3.22.4 https://developer.gnome.org/gtk3/3.24/ch01s02.html
build error in gtk with doc in Builder
it seems that I see the problem of the change I have made below
#include
static void
print_hello (GtkWidget *widget,
gpointer data)
{
g_print ("Hello World\n");
}
static void
activate (GtkApplication *app,
gpointeruser_data)
{
GtkWidget *window;
GtkWidget *grid;
GtkWidget *button;
/* utwórz nowe okno i ustaw jego tytuł */
window = gtk_application_window_new (app);
gtk_window_set_title (GTK_WINDOW (window), "Window");
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
/* Tutaj skonstruujemy kontener, który będzie pakował nasze guziki */
grid = gtk_grid_new ();
/* Zapakuj pojemnik w okno */
gtk_container_add (GTK_CONTAINER (window), grid);
button = gtk_button_new_with_label ("Button 1");
g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);
/* Umieść pierwszy przycisk w komórce siatki (0, 0) i wypełnij go
* tylko 1 komórka poziomo i pionowo (tzn. bez rozpiętości)
*/
gtk_grid_attach (GTK_GRID (grid), button, 0, 0, 1, 1);
button = gtk_button_new_with_label ("Button 2");
g_signal_connect (button, "clicked", G_CALLBACK (print_hello), NULL);
/* Umieść drugi przycisk w komórce siatki (1, 0) i wypełnij go
* tylko 1 komórka poziomo i pionowo (tzn. bez rozpiętości)
*/
gtk_grid_attach (GTK_GRID (grid), button, 1, 0, 2, 1);
button = gtk_button_new_with_label ("Quit");
g_signal_connect_swapped (button, "clicked", G_CALLBACK
(gtk_widget_destroy), window);
/* Umieść przycisk Zakończ w komórce siatki (0, 1) i ustaw go
* rozpiętość 2 kolumn.
*/
gtk_grid_attach (GTK_GRID (grid), button, 0, 1, 3, 1);
/* Teraz, gdy skończyliśmy pakować nasze widżety, pokazujemy je wszystkie
* za jednym zamachem, przez wywołanie gtk_widget_show_all () w oknie.
* To wywołanie rekursywnie wywołuje gtk_widget_show () we wszystkich
widżetach
* które są zawarte w oknie, bezpośrednio lub pośrednio.
*/
gtk_widget_show_all (window);
}
int
main (intargc,
char **argv)
{
GtkApplication *app;
int status;
app = gtk_application_new ("org.gtk.example", G_APPLICATION_FLAGS_NONE);
g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
status = g_application_run (G_APPLICATION (app), argc, argv);
g_object_unref (app);
return status;
}
Krzysztof Sadowski
_______
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
logind + GDbus API
Good day, I planned to write a tiny software for testing purposes that will use GDbus API to interact with logind, in order to detect user idle time. I am still studying GDbus API, and I am also looking for some very good example of GDbus API + logind usage, in order to learn best practices in using both of them. Do you know any? I actually have not found anything yet that fits my needs, but there should be some for sure. I have just found this StackOverflow topic [1] Thank you for your time [1]: https://stackoverflow.com/questions/37185735/sample-program-for-gdbus-signals ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
A pango update
Pango development has been slow in the last few years, while most of the work on the text rendering stack has moved to harfbuzz. But recently, Behdad and I got together for a pango work day, and made some plans, which we want to share. The underlying goal of these changes is to ensure that GTK+ and GNOME continue to have a competitive text rendering stack, and to avoid pango becoming a roadblock for this. To give some background, pango provides these major pieces of functionaliity. Originally, pango has had a backend- and module-based architecture to implement most of these things per platform: - Unicode text analysis (direction, scripts, languages). This is mostly based on Unicode data tables which are for the most part (but not entirely) provided by GLib and firibidi. - Font enumeration. Font enumeration will remain platform-specific, with a Linux implementation based on fontconfig. - Shaping. Shaping is the domain of harfbuzz, and we want to use it on all platforms in the future. The web browsers are ahead of us here, and already use harfbuzz across platforms. The soon-to-be released harfbuzz 2.0 will close one of the last few feature gaps for this by supporting Apple-specific font tables. - Font rendering. For rendering, we nowadays rely on cairo everywhere. In terms of concrete plans, we want to - Move things that need to be updated with Unicode (scripts, character properties) to GLib and/or fribidi - Update the Emoji iterator to be in sync with chrome - Use harfbuzz for shaping everywhere - Provide api to make harfbuzz objects available, so we can get access to harfbuzz features without wrapping everything in pango api There's also a small amount of feature work that we've looked at: - Add some apis to support font variations - Subpixel positioning There is a gitlab milestone to track these: https://gitlab.gnome.org/GNOME/pango/milestones/9 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
About external general purpose modules suppression in GTK+ 4.0
So it seems that GTK external modules support in GTK+ will be deprecated in 4.x branch. I guess it seems feasible because aside from global menubar guys, it seems to me that there aren't so many active external modules. Well, there's at least another useful one, plotinus, a blessing command palettes module that let *all menu item positioning disputes quietly die* while at the same time enhancing usability of all gtk+ applications. https://github.com/p-e-w/plotinus In general, do I understand correctly or what does it go with this removal is the chance to globally modify gtk+ behaviour without forking and continuously patching the toolkit unless you get to import your changes upstream? Emmanuele wrote this in one of this posts in this bug tracker (https://gitlab.gnome.org/GNOME/gtk/issues/1132): >You get to do what everyone else does: engage with the upstream community, >interact with the maintainers and designers, and try to outline your intent. >If you get to convince them, good: the toolkit gets a supported feature, and >applications get to use it, and test it, properly. In practice, doesn't this mean additional work for the app developers that want to integrate features like command palettes in their apps without waiting that upstream takes its time to decide whether the feature deserves to be integrated in the toolkit? Sticking to plotinus, I like a lot what it does and I get to use it *for free* in the applications I've written installing it alongside the app and loading it at runtime, when the user didn't already globally installed by himself: in that case I got support for it out of the box without writing a single extra line. So, when (and now if) I will port my app to gtk4 I will have to explicitly replicate a command palette inside my app; so probably it won't get it because, well, there are more important things when you have deadlines. If I get it right, it seems to me that this external modules suppression will in theory slow down innovation coming from external developers; not that it seriously happened in many cases, but I can say that I wouldn't have lobbied for command palettes if I didn't get to use them in the first place and that *wouldn't have been possible without modules*, apparently. Oscar _______ 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 09/15/18 10:48 AM, John Emmas wrote: On 15/09/2018 12:07, Magnus Bergman wrote: Some mismatch in versions of libtiff could for example be a reason. Otherwise you should probably file a bug report with more information (perhaps to your distribution firstly). Do you happen to know if the tiff library has its own mailing list? I haven't had much success in finding one Yes - see http://www.simplesystems.org/libtiff/ for info on the list. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ 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: An alternative to gdk-pixbuf
On Tue, 11 Sep 2018 at 03:11, Magnus Bergman wrote: > On Tue, 11 Sep 2018 00:07:27 +0200 > Bastien Nocera wrote: > > No, it really isn't: > > https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html > > > > We want to have less CVEs, not more. > > I see what you mean. A few of them (although none of the more serious > ones) were even related to the GIF loader specifically. But the sheer > volume kind of speaks for itself otherwise. :( IM joined Google's OSS-Fuzz programme last year: https://github.com/google/oss-fuzz The huge surge in CVEs was caused by that --- they've been fixing one or two a day ever since. Once they are through this very painful process, IM ought to be rather safe. I do agree though that it's a large and complex thing to use for such a (relatively) simple task. John ___________________ 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 Mon, 10 Sep 2018 at 08:02, Debarshi Ray wrote: > > too with the right plugin (probably using GEGL in that case). But I > > think the problem with large images (say 12000x12000 or so) is giving > > it to the application as a pixmap. From my own tests it seams it's fine > > at least as long as the images are no bigger than the screen. So if the > > drawing (and implicitly also scaling) is handed over to the loading > > library (which in turn might hand it over to the plugin), this problem > > can be avoided. > > Even if one does decode the entire full resolution image into a tiled > data structure (say, GeglBuffer), there's no need to create a Cairo > surface for the entire image at 1:1 zoom. All that's needed is a > surface to represent the visible area at the visible zoom. That's a > lot more manageable. I make a gtk viewer that can display large images efficiently (over 100,000 x 100,000), linked above. I hit a few other issues: 1. You can't use a large ScrolledWindow and only paint the visible area, since you can easily go over the 64k pixel limit on viewports. You have to handle all the scrolling yourself. 2. You need to keep all image processing in a set of background threads and update the display asynchronously, perhaps this is obvious. 3. You have to do the double-buffering yourself as well, since it can take a while to generate a new view and you have to update the screen as new chunks of image are generated. John ___________ 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 Thu, 6 Sep 2018 at 11:40, Emmanuele Bassi via gtk-devel-list wrote: > On Wed, 5 Sep 2018 at 19:25, Magnus Bergman > wrote: >> 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. It doesn't have to be gegl, of course, you could use any image processing library to load and scale down the images. I made a tiny image viewer based on libvips: https://github.com/jcupitt/vipsdisp-tiny It's 300 lines, but does multi-threaded, asynchronous painting of many image formats. It can display gigapixel images on very modest hardware, and it should be quick. There's a more complete image viewer here: https://github.com/jcupitt/vipsdisp That adds most of the usual navigation stuff, though it's not quite done, I must get back to it. The image display part is a widget you could easily cut out and paste into other applications. It's in C, but libvips is a GObject-based library, so it'd be easy to write in any language. Here it is displaying a 18k x 8k 16-bit TIFF: http://www.rollthepotato.net/~john/summer.png That image takes about 8s to load on this laptop. Here it is displaying a 120k x 100k pixel ndpi slide image: http://www.rollthepotato.net/~john/slide.png That image loads instantly, since ndpi supports random access and vipsdisp can just load the parts it needs to paint the screen. John ___________ 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
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 smaller sandboxes inside it. 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
hi, On Tue, Sep 4, 2018, 6:19 PM Magnus Bergman wrote: > Over the years it has been discussed from time to time to replace > gdk-pixbuf with something else[1][2]. [...] > I finally took some time to design an > image loading library on top of cairo [...] > 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. So one thing i think a modern image library needs is sandboxing. the loader should be contained with bubblewrap and it should just give back a chunk of pixels in shared memory as a memfd or similar. then if it crashes it doesnt take down the app. if its exploited the most the attacker can do is make the caller show the wrong image (which could still be bad of course) --Ray ___________ 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
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
Derivable class - Part. 2
Derivable class based on GObject is there. http://psunfun.blogspot.com/2018/08/part-2-deriving-from-gobject-based.html -- - Pavlo Solntsev - Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Sent from Evolution on GNU/Debian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
I can help. But my interests do not got beyond C/C++ scope. I am writing other sections for my blog, where all other concepts will be introduced little-by-little. Anyway, let me know how I can help and we can discuss. On Mon, 2018-08-20 at 09:10 -0600, Sriram Ramkrishna wrote: > > > On Sat, Aug 18, 2018 at 2:03 PM Philip Chimento via gtk-devel-list < > gtk-devel-list@gnome.org> wrote: > > Nice work, Pavlo! I wonder if you can work this into a patch for > > the GObject documentation :-) > > > > You might want to check out > > https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/ > > as well. > > > > > > Pavlo, if you're interested we are working on a developer > documentation portal. We might not hit C first, but I'm sure we > could use your help when it comes to organizing and writing tutorials > when the time comes. It's worth joining up. Let me know! > > sri > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
I needed this. i will try this out. thanks. please include a patreon link as well On Sun, Aug 19, 2018 at 2:27 AM, Pavlo S. via gtk-devel-list < gtk-devel-list@gnome.org> wrote: > Thank you, Philip, > > On Sat, 2018-08-18 at 16:02 -0400, philip.chime...@gmail.com wrote: > > Nice work, Pavlo! I wonder if you can work this into a patch for the > > GObject documentation :-) > > I see no reason why not. I am planning to issue other sections, e.g. > derivable objects, interfaces, properties. I am open for discussion the > best way to incorporate my work to the official manual. What I found, > very often, it is hard to incorporate documentation to the existing > one. Mainly because of the existing structure and logic flow. Also, as > I mentioned in the post, the official manual very technical and very > confused for newcomers. Spending enough time in academia, I always > interested in simplification of the complex concepts. Therefore, I > decided to present my interpretation of very complex concept in a way > that a beginner will be able to understand. > > > You might want to check out > > https://blogs.gnome.org/desrt/2012/02/26/a-gentle- > introduction-to-gobject-construction/ > > as well. > > > > In my personal style I would do three things differently, I don't > > know for sure whether I'm correct about these or how widespread they > > are as best practices: > > > > - It's not necessary to override dispose or finalize if the only > > thing you do is chain up. > > I totally agree with this. The reason I mentioned them is for logic > flow consistency. I mentioned constructor before so I have to mentioned > a destructor and probably copy constructor concept (which I didn't). > > > - I would free self->name in finalize instead of dispose, along with > > any other memory that is fully owned by the MyPoint instance. In > > dispose, I would only drop any references to memory that had been > > passed in through MyPoint's API. > > Hm... This is interesting point. For myself, dispose and finalize are > still very confusing. But it make sense now. I will try to add some > additional explanation to the text. > > > - I think it's confusing to have my_point_free() that calls > > g_clear_object(), since usually g_object_unref() is known as the > > standard way to release a reference to a GObject, and it doesn't > > necessarily free the object if there are other references. > > I would call this as my personal vision. I mentioned that > _free() is just a convenient wrapper around g_object_unref(). I > think this analogy comes from C world, where the free() family > functions are used to free the memory. Again, you probably observe this > situation through a prism of your experience but in my opinion for > beginner it is a little bit confusing to call g_object_unref() > especially in the situation where simple structure can be seen. I will > try to add some additional wording to clarify this a little bit more. > > Best, > > > > Best regards, > > Philip C > > > > On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list < > > gtk-devel-list@gnome.org> wrote: > > > I am putting together a tutorial how to use GObject. It is my > > > interpretation and I was trying to keep is as simple as possible > > > and > > > clear for new users. > > > > > > https://psunfun.blogspot.com/ > > > > > > Thanks. > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
Thank you, Philip, On Sat, 2018-08-18 at 16:02 -0400, philip.chime...@gmail.com wrote: > Nice work, Pavlo! I wonder if you can work this into a patch for the > GObject documentation :-) I see no reason why not. I am planning to issue other sections, e.g. derivable objects, interfaces, properties. I am open for discussion the best way to incorporate my work to the official manual. What I found, very often, it is hard to incorporate documentation to the existing one. Mainly because of the existing structure and logic flow. Also, as I mentioned in the post, the official manual very technical and very confused for newcomers. Spending enough time in academia, I always interested in simplification of the complex concepts. Therefore, I decided to present my interpretation of very complex concept in a way that a beginner will be able to understand. > You might want to check out > https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/ > as well. > > In my personal style I would do three things differently, I don't > know for sure whether I'm correct about these or how widespread they > are as best practices: > > - It's not necessary to override dispose or finalize if the only > thing you do is chain up. I totally agree with this. The reason I mentioned them is for logic flow consistency. I mentioned constructor before so I have to mentioned a destructor and probably copy constructor concept (which I didn't). > - I would free self->name in finalize instead of dispose, along with > any other memory that is fully owned by the MyPoint instance. In > dispose, I would only drop any references to memory that had been > passed in through MyPoint's API. Hm... This is interesting point. For myself, dispose and finalize are still very confusing. But it make sense now. I will try to add some additional explanation to the text. > - I think it's confusing to have my_point_free() that calls > g_clear_object(), since usually g_object_unref() is known as the > standard way to release a reference to a GObject, and it doesn't > necessarily free the object if there are other references. I would call this as my personal vision. I mentioned that _free() is just a convenient wrapper around g_object_unref(). I think this analogy comes from C world, where the free() family functions are used to free the memory. Again, you probably observe this situation through a prism of your experience but in my opinion for beginner it is a little bit confusing to call g_object_unref() especially in the situation where simple structure can be seen. I will try to add some additional wording to clarify this a little bit more. Best, > > Best regards, > Philip C > > On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list < > gtk-devel-list@gnome.org> wrote: > > I am putting together a tutorial how to use GObject. It is my > > interpretation and I was trying to keep is as simple as possible > > and > > clear for new users. > > > > https://psunfun.blogspot.com/ > > > > Thanks. > > _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Development with GObjects
Nice work, Pavlo! I wonder if you can work this into a patch for the GObject documentation :-) You might want to check out https://blogs.gnome.org/desrt/2012/02/26/a-gentle-introduction-to-gobject-construction/ as well. In my personal style I would do three things differently, I don't know for sure whether I'm correct about these or how widespread they are as best practices: - It's not necessary to override dispose or finalize if the only thing you do is chain up. - I would free self->name in finalize instead of dispose, along with any other memory that is fully owned by the MyPoint instance. In dispose, I would only drop any references to memory that had been passed in through MyPoint's API. - I think it's confusing to have my_point_free() that calls g_clear_object(), since usually g_object_unref() is known as the standard way to release a reference to a GObject, and it doesn't necessarily free the object if there are other references. Best regards, Philip C On Fri, Aug 17, 2018 at 3:11 PM Pavlo S. via gtk-devel-list < gtk-devel-list@gnome.org> wrote: > I am putting together a tutorial how to use GObject. It is my > interpretation and I was trying to keep is as simple as possible and > clear for new users. > > https://psunfun.blogspot.com/ > > Thanks. > > -- > - Pavlo Solntsev > - > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > Sent from Evolution on GNU/Debian > > > _______ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Development with GObjects
I am putting together a tutorial how to use GObject. It is my interpretation and I was trying to keep is as simple as possible and clear for new users. https://psunfun.blogspot.com/ Thanks. -- - Pavlo Solntsev - Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Sent from Evolution on GNU/Debian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
compilation error with 3.22.28
Does there exist a patch for : ./.libs/libgtk-3.so: undefined reference to `_gtk_marshal_BOOLEAN__BOXED_BOXED' Has this been otherwise resolved? How should I proceed to correct this error? Terry L. Harris | CompuCom Software Technician direct 480.554.9839 mobil 480.215.9680 terryx.har...@intel.com<mailto:terryx.har...@intel.com> www.Compucom.com<http://www.Compucom.com> _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using "user.mime_type" xattr for MIME guessing
On Thu, Aug 9, 2018 at 2:47 PM Bastien Nocera wrote: > On Thu, 2018-08-09 at 13:09 -0400, Colin Atkinson wrote: > > On Thu, Aug 9, 2018 at 10:47 AM Bastien Nocera > > wrote: > > > On Thu, 2018-08-09 at 10:35 -0400, Colin Atkinson via gtk-devel- > > > list > > > wrote: > > > > Hi everyone, > > > > I'm working on a FUSE file system which makes network requests > > > > whenever a file is read. So obviously, I would like to avoid > > > excess > > > > read requests to files. > > > > > > > > The current implementation [0] of gio's MIME guessing seems to > > > check > > > > the file extension, and then immediately fall back on reading > > > magic > > > > bytes when this is not possible (i.e. files with an ambiguous or > > > no > > > > extension). In my situation, this can potentially lead to many > > > > network requests any time a user opens a directory in Nautilus or > > > a > > > > file selection dialog. > > > > > > > > According to the FreeDesktop specs [1], implementations may query > > > the > > > > user.mime_type xattr for a given file's MIME. But the current > > > version > > > > of glib seems not to make use of this. > > > > > > > > Would there be any interest in a patch to add this functionality? > > > If > > > > so, I would be happy to work on it. > > > > > > > > Please let me know if there's anything I've missed/misunderstood. > > > > > > It's probably something interesting to add to GIO, though checking > > > xattrs also has a cost, especially on local disks. > > > > > > Depending on what your FUSE is, you might want to consider writing > > > a > > > gvfs backend instead, where the backend is responsible for > > > providing > > > the mime-type/content-type (and all the other metadata), so you can > > > use > > > whichever method is the most useful to you, with no added costs > > > because > > > the metadata and the enumeration can be done in one go. > > > > > > Cheers > > > > While there is an overhead for getting the value of an xattr, it also > > potentially prevents the expense of doing glob lookups > > A glob look is essentially free. There's an mmapped cache with those, > and it takes microseconds to do a lookup. > > > and magic guessing. It was added partially to help avoid those very > > operations, as they were deemed expensive. > > magic guessing is only going to be expensive because it needs to do > I/O. So would looking up the xattr. > > > I'm hesitant to commit to writing a full gvfs backend. Correct me if > > I'm wrong, but from reading through some of the backends in the gvfs > > repo, it seems like writing one would require essentially duplicating > > all of that effort. > > Well, yes and no. We've not seen your code, we just know that it's for > a network filesystem. A gvfs backend will integrate better with GNOME > in general, but most of the code should be trivial if you're using a > library to hide all the intricacies of the underlying protocol. > > As for the benefits of writing a gvfs backend, there's an "afc" (Apple > File Conduit, for iOS devices) FUSE backend, but we also wrote a gvfs > backend. The gvfs backend integrates with a separate backend that > watches for plugged in devices, and uses that to mount the filesystems. > There's integration with GNOME because it knows how to tell you about > unlocking your device, it can set thumbnails or icons, and mime-types > on files without doing extra I/O. > > Using a file manager that speaks gvfs on top of a gvfs backend is just > going to be more efficient. A FUSE backend is nice when you're > prototyping, and want people to test out the code, and kick the tires. > It's just not a long-term solution for a lot of use cases. (Though it's > plenty fine if the filesystem is a local one, and the format matches > POSIX expectations, such as local filesystems that are unsupported by > the kernel, you'd then teach udisks how to mount them and integration > would be good enough). > > > And then duplicating it again for KDE. All while maintaining support > > for the FUSE system so that it is usable on Windows/OS X. > > Depends what your target is. I doubt that Windows will read xattrs, but > then again, I don't know anything about FUSE under Windows. > > > This also isn't an isolated situation. There are tons of situations > > where excess reads should b
Re: Using "user.mime_type" xattr for MIME guessing
On Thu, Aug 9, 2018 at 10:47 AM Bastien Nocera wrote: > On Thu, 2018-08-09 at 10:35 -0400, Colin Atkinson via gtk-devel-list > wrote: > > Hi everyone, > > I'm working on a FUSE file system which makes network requests > > whenever a file is read. So obviously, I would like to avoid excess > > read requests to files. > > > > The current implementation [0] of gio's MIME guessing seems to check > > the file extension, and then immediately fall back on reading magic > > bytes when this is not possible (i.e. files with an ambiguous or no > > extension). In my situation, this can potentially lead to many > > network requests any time a user opens a directory in Nautilus or a > > file selection dialog. > > > > According to the FreeDesktop specs [1], implementations may query the > > user.mime_type xattr for a given file's MIME. But the current version > > of glib seems not to make use of this. > > > > Would there be any interest in a patch to add this functionality? If > > so, I would be happy to work on it. > > > > Please let me know if there's anything I've missed/misunderstood. > > It's probably something interesting to add to GIO, though checking > xattrs also has a cost, especially on local disks. > > Depending on what your FUSE is, you might want to consider writing a > gvfs backend instead, where the backend is responsible for providing > the mime-type/content-type (and all the other metadata), so you can use > whichever method is the most useful to you, with no added costs because > the metadata and the enumeration can be done in one go. > > Cheers > While there is an overhead for getting the value of an xattr, it also potentially prevents the expense of doing glob lookups and magic guessing. It was added partially to help avoid those very operations, as they were deemed expensive. I'm hesitant to commit to writing a full gvfs backend. Correct me if I'm wrong, but from reading through some of the backends in the gvfs repo, it seems like writing one would require essentially duplicating all of that effort. And then duplicating it again for KDE. All while maintaining support for the FUSE system so that it is usable on Windows/OS X. This also isn't an isolated situation. There are tons of situations where excess reads should be avoided (e.g. slow disk with lots of files in a directory), or where a FUSE or application has explicitly set the MIME (e.g. curl setting user.mime_type based on the Content-Type header). I may try to whip up a minimal proof-of-concept patch sometime in the next week (unless there's strong opposition to it). From there, it should be feasible to see how checking user.mime_type affects performance. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Using "user.mime_type" xattr for MIME guessing
Hi everyone, I'm working on a FUSE file system which makes network requests whenever a file is read. So obviously, I would like to avoid excess read requests to files. The current implementation [0] of gio's MIME guessing seems to check the file extension, and then immediately fall back on reading magic bytes when this is not possible (i.e. files with an ambiguous or no extension). In my situation, this can potentially lead to many network requests any time a user opens a directory in Nautilus or a file selection dialog. According to the FreeDesktop specs [1], implementations may query the user.mime_type xattr for a given file's MIME. But the current version of glib seems not to make use of this. Would there be any interest in a patch to add this functionality? If so, I would be happy to work on it. Please let me know if there's anything I've missed/misunderstood. Cheers, Colin [0]: https://github.com/GNOME/glib/blob/master/gio/xdgmime/xdgmime.c#L489 [1]: https://specifications.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html#idm140625828614912 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Combined search and combobox?
n arrows within the text entry. > Btw, this happens also if I only replace (without setting up all the > connections), gtk_combo_box_new() with gtk_combo_box_new_with_entry(). I'm > still trying to figure out what went wrong. > > I will hazard a guess that you didn't set the text column with > gtk_combo_box_set_entry_text_column () > > Reuben > > _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Combined search and combobox?
I agree that setting this up is a bit too complex, and it would be nice if there was a standalone widget that this everything for you. Meanwhile I tried converting your widget into C (with the intention of replacing the font selection widget in gucharmap), and something is not working. I get lots of warnings about: (gucharmap:30880): Gtk-CRITICAL **: 17:41:07.804: gtk_entry_set_text: assertion 'text != NULL' failed This happens e.g. when I'm using the up down arrows within the text entry. Btw, this happens also if I only replace (without setting up all the connections), gtk_combo_box_new() with gtk_combo_box_new_with_entry(). I'm still trying to figure out what went wrong. Regards, Dov On Fri, Jul 27, 2018 at 2:25 PM Reuben Rissler wrote: > On 07/27/2018 12:15 AM, Dov Grobgeld wrote: > > Thanks. This is exactly what I was looking for! I didn't realize that a > combobox can be attached to a model, and that a model can be filtered. > > Gtk models are powerful, but with great power comes great complexity ;) > > > Imo multiple partial string match should be default behavior, which it is > unfortunately not. E.g. inkscape only matches in the beginning of the > string. > > Agreed. > > > Is there a GNOME guide line about this? > > Not that I have seen in my travels using Gtk. > > I came up with this tool out of necessity for my accounting/small business > system. I never gave it a thought somebody else would find it useful until > your post to this mailing list. When you posted, I thought you might find > this interesting. So would this be useful to a wider audience? I don't know > if the Gtk devs would consider making a special combo with this feature, as > it seems so easy to setup. After you know how :) > > Glad to be of help, > Reuben > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME GitLab instance slow?
Thank you very much, Tristan. What is d-d-l? In the meantime I have been able to push the Merge Request, but after trying some times over three hours without success Luca 2018-07-27 15:19 GMT+02:00 Tristan Van Berkom < tristan.vanber...@codethink.co.uk>: > This is probably better on another list, maybe d-d-l, since this would > effect everyone. > > I can say that since 2 weeks ago, the gitlab.com instance seems to have > deployed a huge and sluggish JS payload which brings my browser to a crawl, > i dont know if we've opted into that update on the GNOME instance, though. > > Cheers, > -Tristan > > > On Jul 27, 2018, at 8:17 PM, Luca Bacci via gtk-devel-list < > gtk-devel-list@gnome.org> wrote: > > > > Hi, do you experience too general slowness in GNOME's GitLab? > > > > In general the workflow is too sluggish and this gets a bit in the way. > > > > But the real problem is that I'm not able to create a Merge Request. It > waits for about 30 seconds and fails with: "502 Whoops, GitLab is taking > too much time to respond." > > > > Also I get errors in many places like "Error loading viewer", even > though everything seems to work fine! > > > > I don't know if the problem is related to GitLab or the GNOME instance / > installation > > > > Is it me or do you encounter these problems too? > > Just to ask.. > > > > Thank You! > > Luca > > ___________ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME GitLab instance slow?
This is probably better on another list, maybe d-d-l, since this would effect everyone. I can say that since 2 weeks ago, the gitlab.com instance seems to have deployed a huge and sluggish JS payload which brings my browser to a crawl, i dont know if we've opted into that update on the GNOME instance, though. Cheers, -Tristan > On Jul 27, 2018, at 8:17 PM, Luca Bacci via gtk-devel-list > wrote: > > Hi, do you experience too general slowness in GNOME's GitLab? > > In general the workflow is too sluggish and this gets a bit in the way. > > But the real problem is that I'm not able to create a Merge Request. It waits > for about 30 seconds and fails with: "502 Whoops, GitLab is taking too much > time to respond." > > Also I get errors in many places like "Error loading viewer", even though > everything seems to work fine! > > I don't know if the problem is related to GitLab or the GNOME instance / > installation > > Is it me or do you encounter these problems too? > Just to ask.. > > Thank You! > Luca > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GNOME GitLab instance slow?
Hi, do you experience too general slowness in GNOME's GitLab? In general the workflow is too sluggish and this gets a bit in the way. But the real problem is that I'm not able to create a Merge Request. It waits for about 30 seconds and fails with: "502 Whoops, GitLab is taking too much time to respond." Also I get errors in many places like "Error loading viewer", even though everything seems to work fine! I don't know if the problem is related to GitLab or the GNOME instance / installation Is it me or do you encounter these problems too? Just to ask.. Thank You! Luca _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Combined search and combobox?
Thanks. This is exactly what I was looking for! I didn't realize that a
combobox can be attached to a model, and that a model can be filtered.
Imo multiple partial string match should be default behavior, which it is
unfortunately not. E.g. inkscape only matches in the beginning of the
string.
Is there a GNOME guide line about this?
Regards,
Dov
On Thu, Jul 26, 2018 at 8:38 PM Reuben Rissler wrote:
> On 07/26/2018 07:36 AM, Dov Grobgeld via gtk-devel-list wrote:
>
> Is there a widget that combines a searchbox with a combobox?
>
> A use case would be to search for a fontname in a very long font list.
>
> I would like to be able to type a search string, and have the opened
> combobox display only entries that match the typed string. A plus would be
> if it is possible to change how matches take place, e.g. between multiple
> word (like helm-mode in emacs), a regular expression, or an absolute match.
>
> Has someone written anything like that?
>
>
> You didn't specify a language, so here's an example in Python. It uses
> space separated keywords, like in Google search or so. It may not be
> exactly as you requested, but will give you something to start with.
>
> #! /usr/bin/env python3
>
> import gi
> gi.require_version('Gtk', '3.0')
> from gi.repository import Gtk
> import os, sys
>
>
> class GUI (Gtk.Window):
> def __init__(self):
>
> Gtk.Window.__init__(self, title="Combo with search")
> self.model = Gtk.ListStore(str)
> self.populate_model()
> #combobox
> combo = Gtk.ComboBox.new_with_model_and_entry(model = self.model)
> combo.set_entry_text_column(0)
> combo.connect('changed', self.changed)
> #completion
> completion = Gtk.EntryCompletion ()
> completion.set_model(self.model)
> completion.set_text_column(0)
> completion.set_match_func(self.match_func)
> completion.connect ('match-selected', self.match_selected)
> #combobox entry
> entry = combo.get_child()
> entry.set_completion (completion)
> #main window
> self.add (combo)
> self.show_all()
>
> def changed (self, combo):
> _iter = combo.get_active_iter()
> if _iter != None:
> font = self.model[_iter][0]
> print ('You selected combo:', font)
>
> def match_selected (self, completion, model, _iter):
> print ('You selected completion:', model[_iter][0])
>
> def match_func (self, completion, string, _iter):
> for word in string.split():
> if word not in self.model[_iter][0].lower(): #search is always
> lower case
> return False
> return True
>
> def on_window_destroy(self, window):
> Gtk.main_quit()
>
> def populate_model (self):
> for i in range (100):
> self.model.append(["Font %d" % i])
>
> def main():
> app = GUI()
> Gtk.main()
>
> if __name__ == "__main__":
> sys.exit(main())
>
>
> Reuben
>
>
> ___________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Combined search and combobox?
Is there a widget that combines a searchbox with a combobox? A use case would be to search for a fontname in a very long font list. I would like to be able to type a search string, and have the opened combobox display only entries that match the typed string. A plus would be if it is possible to change how matches take place, e.g. between multiple word (like helm-mode in emacs), a regular expression, or an absolute match. Has someone written anything like that? Regards, Dov ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
VeraCrypt support in GNOME
Hi, first a quick status update: the project to add VeraCrypt support to GNOME made good progress in the last months. Our work on Disks, glib, GVfs, and partly GTK+, was merged already: https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues/84 https://gitlab.gnome.org/GNOME/glib/merge_requests/120 https://gitlab.gnome.org/GNOME/gvfs/merge_requests/4/ https://gitlab.gnome.org/GNOME/gtk/merge_requests/260 The remaining important merge requests are: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126 https://gitlab.gnome.org/GNOME/gtk/merge_requests/200 https://gitlab.gnome.org/GNOME/gtk/merge_requests/244 We hope that these can be merged in time for the GTK+ 3.24 / GNOME Shell 3.30 releases. Given the feature freeze will happen soon, time is pressing. Our main concern is the GNOME Shell merge request (https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/126), which seems to be stalled, possibly due to holiday or higher priority work, which is why we're hereby reaching out to the broader GNOME development community, in the hope that someone has time to look into it :) We are also concerned about the merge request for including interesting device mapper devices and loop devices in the GTK places sidebar (https://gitlab.gnome.org/GNOME/gtk/merge_requests/200), which was rejected. The purpose of this merge request is to include encrypted file containers in the sidebar. Based on our user survey, file containers are very common among VeraCrypt users (used by 76% of Tails+VeraCrypt users): https://tails.boum.org/blueprint/veracrypt/#survey We did not get an explanation for the rejection, except that there should be no special-casing of these devices in GTK+. So a couple weeks ago, we asked for a clarification and we explained that we don't think that this would qualify as special-casing, given these volumes are already listed by the GVfs volume monitor: https://gitlab.gnome.org/GNOME/gtk/merge_requests/200#note_261361 The volume monitor documentation explicitly states that it lists devices and volumes interesting for the user, i.e. "what a file selector or file manager would show in a sidebar". In our tests, the only volumes that were added to the sidebar by our patches were encrypted volumes (excluding those on internal drives). We would appreciate to get a comment on this, because we see this as an essential feature for the usability of the VeraCrypt support in GNOME. Thanks a lot in advance! Cheers _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About Gtk4, modules and GlobalMenu approach
OK, so, I need another more hackish way to apply it (I like system-wide menu removal, which not depend on application developers at all (maybe an LD_PRELOAD hack or try to use module with dummy GIO extension implementation)). On Sat, Jun 23, 2018 at 11:19 PM Matthias Clasen wrote: > > > On Tue, Jun 5, 2018 at 6:57 AM, Konstantin P. > wrote: > >> I am a developer of GlobalMenu applets for XFCE, Mate and Budgie. Also I >> maintain appmenu-gtk-module and Jayatana. >> I heard than you removed general purpose loadable modules support, so, I >> cannot alter GtkMenuBar and GtkWindow to acheive support for Global Menu. >> >> Can I develop a patch to GTK which enables support exporting all >> GtkMenuBar instances as GMenuModels (regardless of origin) when >> gtk-shell-shows-menubar is enabled and set to 1? >> >> > No, we don't think that is appropriate, as we already said in > https://gitlab.gnome.org/GNOME/gtk/issues/1132 > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About Gtk4, modules and GlobalMenu approach
On Tue, Jun 5, 2018 at 6:57 AM, Konstantin P. wrote: > I am a developer of GlobalMenu applets for XFCE, Mate and Budgie. Also I > maintain appmenu-gtk-module and Jayatana. > I heard than you removed general purpose loadable modules support, so, I > cannot alter GtkMenuBar and GtkWindow to acheive support for Global Menu. > > Can I develop a patch to GTK which enables support exporting all > GtkMenuBar instances as GMenuModels (regardless of origin) when > gtk-shell-shows-menubar is enabled and set to 1? > > No, we don't think that is appropriate, as we already said in https://gitlab.gnome.org/GNOME/gtk/issues/1132 ___________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_stat() In src/glade3-3.8.5/gladeui/glade-utils.c At Line 1865 Causes SIGSEGV in strlen () from C:\Windows\System32\msvcrt.dll When Saving File
Posted Here Also:
https://stackoverflow.com/questions/50430314/g-stat-in-src-glade3-3-8-5-gladeui-glade-utils-c-at-line-1865-causes-sigsegv-in
This may strictly be an issue on MSYS64 / MinGW64. That is unknown.
The problem has been duplicated:
https://github.com/Alexpux/MINGW-packages/issues/3780
The Runtime Environment Is MSYS64 / MinGW64. (MSYS2 20161025 Upgraded with
pacman -Syu). It worked fine, previous to my most recent set of pacman updates.
When running: /mingw64/bin/glade-3.exe
And I try to save a file, after selecting or entering a filename, and clicking
Save in the File Chooser Dialog, the program crashes, (segfaults), and the file
size is zero.
When I use gdb to troubleshoot the Segmentation Fault, I get the following:
Thread 1 received signal SIGSEGV, Segmentation fault.
0x7ff90f48c981 in strlen () from C:\Windows\System32\msvcrt.dll
Whether I run an executable installed by pacman or built from source.
When I build from source and enable debugging symbols, I get more info as
below, but in the first few lines it identifies the file and line below, and
the problem has been isolated to that line.
(gdb) bt
#0 0x7ff90f48c981 in strlen () from C:\Windows\System32\msvcrt.dll
#1 0x68611286 in ?? () from C:\msys64\mingw64\bin\libglib-2.0-0.dll
#2 0x68611f25 in ?? () from C:\msys64\mingw64\bin\libglib-2.0-0.dll
#3 0x62dbdab4 in glade_util_get_file_mtime (filename=0x0,
error=error@entry=0x0) at ../../glade3-3.8.5/gladeui/glade-utils.c:1865
When I change line 1865 of glade-utils.c from:
retval = g_stat (filename, );
To:
retval = stat (filename, );
I get the following warning:
warning: Invalid parameter passed to C runtime function.
But the program appears to save the file correctly.
If I hardcode it like this:
1865 // retval = g_stat (filename, );
1866 retval = 0;
I get a message about the filename being null, and it does not appear to save
the file correctly, but it does not segfault.
Below is my history of Gtk2 and Glib Installation:
$ grep mingw-w64-x86_64-gtk2 /var/log/pacman.log | grep installed
[2017-11-19 19:29] [ALPM] installed mingw-w64-x86_64-gtk2 (2.24.31-6)
[2018-05-11 02:18] [ALPM] reinstalled mingw-w64-x86_64-gtk2 (2.24.32-1)
$ grep mingw-w64-x86_64-glib2 /var/log/pacman.log | grep installed
[2017-11-19 19:26] [ALPM] installed mingw-w64-x86_64-glib2 (2.54.2-1)
[2018-05-11 01:58] [ALPM] reinstalled mingw-w64-x86_64-glib2 (2.56.1-1)
Glade Version is 3.8.5
Source Info:
pkgver=3.8.5
pkgrel=2
sha256sums=('58a5f6e4df4028230ddecc74c564808b7ec4471b1925058e29304f778b6b2735')
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
fdwalk
Heyho, I discovered you have a fdwalk implementation in glib/gspawn.c which is not exported as a usable symbol. Is there any reason for this? If not, I'd suggest exporting that symbol and maybe even another wrapper that takes a list of FDs to keep open instead of the callback pointer and closes all other ones. Closing all fds except some specific ones is a common pattern before exec()ing. --Markus -- Google Germany GmbH, Erika-Mann-Str. 33, 80636 München, Geschäftsführer: Paul Manicle, Halimah DeLaine Prado, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fdwalk
Heyho, I'm going to unsubscribe from the list now to avoid noise. If someone gets interested in this, please CC me in any response. Thanks! --Markus On Mon, Jan 15, 2018 at 4:46 PM Markus Teich < mteich+gtk-devel-l...@google.com> wrote: > Heyho, > > I discovered you have a fdwalk implementation in glib/gspawn.c which is > not exported as a usable symbol. Is there any reason for this? If not, I'd > suggest exporting that symbol and maybe even another wrapper that takes a > list of FDs to keep open instead of the callback pointer and closes all > other ones. Closing all fds except some specific ones is a common pattern > before exec()ing. > > --Markus > > > -- > Google Germany GmbH, Erika-Mann-Str. 33, 80636 München, Geschäftsführer: > Paul Manicle, Halimah DeLaine Prado, Registergericht und -nummer: Hamburg, > HRB 86891, Sitz der Gesellschaft: Hamburg > This e-mail is confidential. If you received this communication by > mistake, please don't forward it to anyone else, please erase all copies > and attachments, and please let me know that it has gone to the wrong > person. > -- Google Germany GmbH, Erika-Mann-Str. 33, 80636 München, Geschäftsführer: Paul Manicle, Halimah DeLaine Prado, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. ___________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Is a Module Definition File needed when building with MSVC (gtk-2-24)?
Hi John,
Can you try generating gtk/gtkmarshalers.[c|h] using glib-genmarshal? Can you
also test using the Python version of glib-genmarshal and see whether the
linking z works properly? If not, use the former .exe version of the tool,
and perhaps file a bug against the Python version of glib-genmarshal?
(In the gtk\ subdir)
$(glib-genmarshal command) --prefix=_gtk_marshal ./gtkmarshalers.list
--header > gtkmarshalers.h
echo #include "gtkmarshalers.h" > gtkmarshalers.c
echo #include "gtkalias.h" >> gtkmarshalers.c
$(glib-genmarshal command) --prefix=_gtk_marshal ./gtkmarshalers.list --body >>
gtkmarshalers.c
With blessings, thank you!
從 Windows 10 手機傳送
寄件者: John Emmas
傳送時間: 2018年1月22日 00:06
收件者: gtk-devel-list
主旨: Is a Module Definition File needed when building with MSVC (gtk-2-24)?
Perhaps wrongly I've been using a module definition file when building gtk-2-24
with MSVC (I'm saying "perhaps" because it used to be needed at one time but
maybe that eventually got superseded and I didn't notice...)
On 8th Jan, the following symbols got added to 'gtk/gtk.symbols' by commit
#331877fe36 (Fix abicheck):-
gtk_marshal_VOID__BOOLEAN
gtk_marshal_VOID__BOXED
gtk_marshal_VOID__ENUM
gtk_marshal_VOID__INT
gtk_marshal_VOID__OBJECT
gtk_marshal_VOID__POINTER
gtk_marshal_VOID__STRING
gtk_marshal_VOID__UINT
gtk_marshal_VOID__VOID
Like I said, I'd always assumed that 'gtk.symbols' was needed for generating a
module definition file ('gtk.def') as that's generally what a symbols file gets
used for (with MSVC).
If the module definition file isn't needed any more, just ignore this (gtk-2-24
seems to link okay without it). But if it is still used, MSVC now produces the
following linker errors:-
gtk.def : error LNK2001: unresolved external symbol
gtk_marshal_VOID__BOOLEAN
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__BOXED
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__ENUM
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__INT
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__OBJECT
gtk.def : error LNK2001: unresolved external symbol
gtk_marshal_VOID__POINTER
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__STRING
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__UINT
gtk.def : error LNK2001: unresolved external symbol gtk_marshal_VOID__VOID
Taking 'gtk_marshal_VOID__ENUM' as an example, 'gtk/gtkmarshalers.c' contains
some variants - e.g.
gtk_marshal_VOID__ENUM_BOOLEAN
gtk_marshal_VOID__ENUM_ENUM
gtk_marshal_VOID__ENUM_FLOAT
gtk_marshal_VOID__ENUM_FLOAT_BOOLEAN
along with a few others- but I can't find one that's just called
'gtk_marshal_VOID__ENUM' (hence the linker error if it it gets included in
gtk.symbols).
Hope this all makes sense...
John
_______________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
fdwalk
Heyho, I discovered you have a fdwalk implementation in glib/gspawn.c which is not exported as a usable symbol. Is there any reason for this? If not, I'd suggest exporting that symbol and maybe even another wrapper that takes a list of FDs to keep open instead of the callback pointer and closes all other ones. Closing all fds except some specific ones is a common pattern before exec()ing. --Markus -- Google Germany GmbH, Erika-Mann-Str. 33, 80636 München, Geschäftsführer: Paul Manicle, Halimah DeLaine Prado, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 - GtkExpander problem, bug ?
Thanks Matthias. I probably should have checked bugzilla first. Just rebuilt GTK to version 3.22.26 and it works fine. There is no click through after closing the expander. Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 - GtkExpander problem, bug ?
Hi Sébastien,
If I try some test code... it should work. The code uses a grid instead of a
fixed container. Is this similar to what you have tried?
Eric
/*
gcc -Wall buttons1.c -o buttons1 `pkg-config --cflags --libs gtk+-3.0`
Tested with GTK3.18 on Ubuntu16.04
*/
#include
static void button_clicked1(GtkWidget *button, gpointer user_data)
{
g_print("1 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
}
static void button_clicked2(GtkWidget *button, gpointer user_data)
{
g_print("2 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
}
int main(int argc, char *argv[])
{
gtk_init (, );
GtkWidget *window=gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Buttons");
gtk_window_set_default_size(GTK_WINDOW(window), 400, 400);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
gint i=0;
gint j=0;
GtkWidget *buttons1[100];
GtkWidget *buttons2[100];
//First set of buttons.
for(i=0;i<100;i++)
{
gchar *string=g_strdup_printf("button%i", i);
buttons1[i]=gtk_button_new_with_label(string);
g_free(string);
}
GtkWidget *grid1=gtk_grid_new();
for(i=0;i<10;i++)
{
for(j=0;j<10;j++)
{
gtk_grid_attach(GTK_GRID(grid1), buttons1[i*10+j], j, i, 1, 1);
g_signal_connect(buttons1[i*10+j], "clicked",
G_CALLBACK(button_clicked1), NULL);
}
}
//Second set of buttons.
for(i=0;i<100;i++)
{
gchar *string=g_strdup_printf("button%i", i);
buttons2[i]=gtk_button_new_with_label(string);
g_free(string);
}
GtkWidget *grid2=gtk_grid_new();
for(i=0;i<10;i++)
{
for(j=0;j<10;j++)
{
gtk_grid_attach(GTK_GRID(grid2), buttons2[i*10+j], j, i, 1, 1);
g_signal_connect(buttons2[i*10+j], "clicked",
G_CALLBACK(button_clicked2), NULL);
}
}
GtkWidget *scroll1=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll1, TRUE);
gtk_widget_set_hexpand(scroll1, TRUE);
gtk_container_add(GTK_CONTAINER(scroll1), grid1);
GtkWidget *scroll2=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll2, TRUE);
gtk_widget_set_hexpand(scroll2, TRUE);
gtk_container_add(GTK_CONTAINER(scroll2), grid2);
GtkWidget *expander1=gtk_expander_new("buttons1");
gtk_container_add(GTK_CONTAINER(expander1), scroll1);
GtkWidget *expander2=gtk_expander_new("buttons2");
gtk_container_add(GTK_CONTAINER(expander2), scroll2);
GtkWidget *grid3=gtk_grid_new();
gtk_grid_attach(GTK_GRID(grid3), expander1, 0, 0, 1, 1);
gtk_grid_attach(GTK_GRID(grid3), expander2, 0, 1, 1, 1);
gtk_container_add(GTK_CONTAINER(window), grid3);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
___________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: webassembly
Il giorno lun 20 nov 2017 19:23:08 CET, Emmanuele Bassi ha scritto: On 20 November 2017 at 17:34, Andrea Zagli <aza...@libero.it> wrote: Il giorno lun 20 nov 2017 16:02:11 CET, Emmanuele Bassi ha scritto: Hi; On 20 November 2017 at 14:52, Andrea Zagli via gtk-devel-list <gtk-devel-list@gnome.org> wrote: do you plan to port (i don't know if "port" is the right word) glib/gtk to webassembly? There are no plans that I'm aware of, nor use cases that have materialised that would require such a port. for example it could replace broadway Considering that the Broadway backend is mostly a toy, and it hasn't seen much development at all in master, I'm not sure replacing it is going to work. Writing new GDK backends, and ensuring that they keep working, is not a trivial matter. since i hate other languages than c, i wrote a little library with glib to easy develop cgi; and i use other libraries (libgda, libsoup, libxml, etc etc) to make my web apps the base code for that web apps is always a library that i use also for the gui backend of the web app with webassembly i could write backend and frontend in glib/gtk If you are volunteering to write a new GDK backend, and maintain it, then by all means: feel free to work on it and submit your code for review! I strongly advise you work on the master branch, as the rendering model has drastically changed from the gtk-2-24 and gtk-3-22 stable branches. unfortunately my knowledge of glib/gtk structure/architecture is close to zero same thing for webassembly and what it means port to it a library of the level of glib/gtk PS: an other use case could be use latest version of glib/gtk/etc "under" winxp (but maybe the browser version that support webassembly doesn't suport anymore winxp) ___________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: webassembly
Il giorno lun 20 nov 2017 16:02:11 CET, Emmanuele Bassi ha scritto: Hi; On 20 November 2017 at 14:52, Andrea Zagli via gtk-devel-list <gtk-devel-list@gnome.org> wrote: do you plan to port (i don't know if "port" is the right word) glib/gtk to webassembly? There are no plans that I'm aware of, nor use cases that have materialised that would require such a port. for example it could replace broadway since i hate other languages than c, i wrote a little library with glib to easy develop cgi; and i use other libraries (libgda, libsoup, libxml, etc etc) to make my web apps the base code for that web apps is always a library that i use also for the gui backend of the web app with webassembly i could write backend and frontend in glib/gtk today i saw a demo of a qt gui app running inside the browser thanks to webassembly _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
webassembly
do you plan to port (i don't know if "port" is the right word) glib/gtk to webassembly? thanks in advance _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Call not guarded properly
After updating glib from git master today I can no longer build with
MSVC. The build now fails to link because gio makes a call to
'g_openuri_portal_open_uri_finish()' (in function
'g_app_info_launch_default_for_uri_finish()')
Looking around at similar calls, I reckon the function should maybe look
like this:-
gboolean
g_app_info_launch_default_for_uri_finish (GAsyncResult *result,
GError **error)
{
#ifdef G_OS_UNIX // <--- This guard added by me
return g_openuri_portal_open_uri_finish (result, error);
#endif
return FALSE; // <--- and this added by me
}
Should I flag this up in bugzilla or have I misunderstood something?
John
_______
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Licensing
On 28/05/2017 14:41, Sébastien Wilmet wrote: On Wed, Apr 19, 2017 at 09:02:21AM +0100, John Emmas via gtk-devel-list wrote: the following 11 header files stipulate GPL:- gbase64.h gbookmarkfile.h gchecksum.h ghmac.h glib-private.h glib-unix.h gmain.h gmain-internal.h gmessages-private.h goption.h gpoll.h Just thought I'd flag it up in case it's unintentional, I've checked the 3 first files that you list, and they are correctly licensed under the LGPL (up until recently it was the "GNU Library General Public License", it's now the "GNU Lesser General Public License"). Please double check the list. Hi Sebastien, I updated from git master just now and the above files are all okay now. However, in the latest stable branch (glib-2-52 ?) they're still showing the older licenses. John _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Licensing
Hi guys - whilst checking something else this morning I came across an anomaly in the licensing mechanism for glib / gtk+ etc. The vast majority of the header files state that it's LGPL. But occasionally there are GPL headers here and there. For example in glib-2, the following 11 header files stipulate GPL:- gbase64.h gbookmarkfile.h gchecksum.h ghmac.h glib-private.h glib-unix.h gmain.h gmain-internal.h gmessages-private.h goption.h gpoll.h Just thought I'd flag it up in case it's unintentional, John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: What does "(skip)" mean ???
Hi John,
Note that since a few release series ago we stopped using .symbol files to
export symbols but instead use a __declspec(dllexport) approach to export them.
See config.h.win32.in in your checkout in the _GLIB_EXTERN part—if it is not
defined in your build files, define it as it is in config.h.win32.in, and
things should do.
With blessings, and cheers!
從 Windows 10 手機傳送
寄件者: John Emmas via gtk-devel-list
傳送時間: 2017年4月17日 20:47
副本: GTK Devel List
主旨: Re: What does "(skip)" mean ???
On 17/04/2017 12:16, John Emmas via gtk-devel-list wrote:
>
> my VS8 projects seem to use ".symbols" files for determining what gets
> exported from the built DLLs. I can't remember why I needed to do
> that but I probably just need to amend them - or hopefully find a way
> to stop using them now!
>
Yes - that was it.! My ".symbols" file was getting converted into
module definition files (".def" files). The file was very subtly
different for a Debug build compared to a Release build. It looks like
the difference was due to this function:-
g_slice_debug_tree_statistics()
From what I can tell, it's only supposed to be relevant in a Debug
build. But there must have been a time when it was somehow getting
included in a Release build (and presumably causing some kind of
problem). My ".def" file just made sure that it didn't get exported
when it wasn't needed.
Anyway... whatever the problem was, it looks like it eventually got
fixed and I can now get rid of my def/symbols files.. Sorry for the noise.
John
_______
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What does "(skip)" mean ???
On 17/04/2017 12:16, John Emmas via gtk-devel-list wrote:
my VS8 projects seem to use ".symbols" files for determining what gets
exported from the built DLLs. I can't remember why I needed to do
that but I probably just need to amend them - or hopefully find a way
to stop using them now!
Yes - that was it.! My ".symbols" file was getting converted into
module definition files (".def" files). The file was very subtly
different for a Debug build compared to a Release build. It looks like
the difference was due to this function:-
g_slice_debug_tree_statistics()
From what I can tell, it's only supposed to be relevant in a Debug
build. But there must have been a time when it was somehow getting
included in a Release build (and presumably causing some kind of
problem). My ".def" file just made sure that it didn't get exported
when it wasn't needed.
Anyway... whatever the problem was, it looks like it eventually got
fixed and I can now get rid of my def/symbols files.. Sorry for the noise.
John
_______________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What does "(skip)" mean ???
On 17/04/2017 11:25, Emmanuele Bassi wrote: Should I transfer this discussion to bugzilla here:- https://bugzilla.gnome.org/show_bug.cgi?id=780634 Please, do, detailing how you build GLib. Okay - just before I do that though, a bit more investigation might have revealed the problem... I'm building with VS8, using my own vcproj files. Essentially they're the same as the official ones except that as well as building a Debug target and a Release target, I also build a "Debuggable Release" target. Apart from that there are only minor differences - for example when I build the Debug modules I append a letter "D" to the target name (in line with what normally gets done when building with MSVC). Here's where it gets interesting... my VS8 projects seem to use ".symbols" files for determining what gets exported from the built DLLs. I can't remember why I needed to do that but I probably just need to amend them - or hopefully find a way to stop using them now! John ___________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What does "(skip)" mean ???
On 16/04/2017 19:25, Sébastien Wilmet wrote: It's a GObject Introspection annotation !!! https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations Thanks Sébastien, I can't claim to understand it all but it seems like GObject Introspection is a way of compiling modules with one language such that they can be used by some different language. If I use "dumpbin /EXPORTS" on my built DLL, I see these entries:- 755 2F2 2680 g_mkstemp = @ILT+5755(_g_mkstemp) 756 2F3 132A g_mkstemp_full = @ILT+805(_g_mkstemp_full) 757 2F4 1870 g_mkstemp_utf8 = @ILT+2155(_g_mkstemp_utf8) so all three functions are getting exported - BUT - if I examine the corresponding link lib, I can see a reference to g_mkstemp_full(). I can also see a reference to g_mkstemp_utf8(). But there's no reference to g_mkstemp(). In other words, although that function does get exported from the DLL, the accompanying link lib doesn't seem to know about it. I've never seen anything like that before but I'm guessing (maybe wrongly) it wouldn't have anything to do with Introspection?? I've also discovered that if I revert the changes from commit #d1528402,it fixes the problem for g_mkstemp(). So I'm assuming that if I reverted Christoph's other changes from that time, it'd fix the other problems I'm seeing with g_getenv() etc. Should I transfer this discussion to bugzilla here:- https://bugzilla.gnome.org/show_bug.cgi?id=780634 Also - has anyone else managed to build this successfully with MSVC? Maybe there's a new #define somewhere that I need to know about? Thanks, John _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
What does "(skip)" mean ???
All of a sudden I've hit a problem when building glib with MSVC. It seems to be affecting calls to g_mkstemp() / g_getenv() and various others. Let's take g_mkstemp() as an example. It gets called in glib-genmarshal.c Prior to commit #d1528402, git master had some lines looking like this (in 'gfileutils.h'):- #ifndef __GTK_DOC_IGNORE__ #ifdef G_OS_WIN32 #define g_file_test g_file_test_utf8 #define g_file_get_contents g_file_get_contents_utf8 #define g_mkstemp g_mkstemp_utf8 // and a few others #endif /* G_OS_WIN32 */ #endif /* __GTK_DOC_IGNORE__ */ so in the past (when building for WIN32) calls to 'g_mkstemp()' got converted to use 'g_mkstemp_utf8()' instead. But now that the above lines have been removed, 'g_mkstemp()' is coming up as an unresolved symbol when I try to link the glib-genmarshal DLL. I'm a bit baffled about this because it does seem to be getting exported from libglib (so I don't understand why it can't be imported). Maybe there's some confused linkage somewhere?? However... in gfileutils.c, I see a comment, looking like this:- /** * g_mkstemp: (skip) * @tmpl: (type filename): template filename * * Opens a temporary file. See the mkstemp() documentation * * // some other stuff * */ So I'm wondering - what's the significance of the word "skip" here?? I can't see any obvious reason why this isn't linking but maybe that'll give me a clue... John _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkGlArea render fps is different than monitor frame rate
Hi Ferenc, You should be able to take care of what you are after with GTK. The GdkFrameClock works very well for smooth animation. It will get rid of the jitter. Give it a try. You would just need to set up your code a little differently. It you are interested in a simple animation with a frame clock, there is one at https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/cairo_drawings/battery2.c The drawing is with cairo but the idea is the same. You could render your GL widget in a similar way and the result will be smooth animation if your drawing times are fast. Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'
On 05/02/2017 03:59, Yale Zhang wrote: I suggest adding a lrintf() fallback to fallback-c89.c too. Currently, there are 2 rounding functions in the fall backs, round() and rint() Where does fallback-c89.c come from? Some auto-generated file maybe? I can't seem to find it on my system :-( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'
On 4 Feb 2017, at 19:44, Emmanuele Bassi wrote: > > Please, file a bug against gdk-pixbuf: > > https://bugzilla.gnome.org/enter_bug.cgi?product=gdk-pixbuf > > I'd rather have a check at configure-time that looks if we have > lrint() available, and if not, provides a fallback. We used this > approach in GTK+ 3.x, and it makes it easier to remove the code once > we decide to bump the compiler requirements, like we did in GTK+ > master. > Thanks Emmanuele - just filed bug #778181 John _______________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'
On 04/02/2017 16:07, Martin Guy wrote: On 04/02/2017, John Emmas via gtk-devel-list <gtk-devel-list@gnome.org> wrote: I took a quick look through glib, gtk+ (v2) and gdk-pixbuf but I can't see lrint getting used anywhere else. Any chance of a fix? Thanks. The quick fix is to replace them with tmp_width = (int) (src_width * prescale_x + 0.5); tmp_height = (int) (src_height * prescale_y + 0.5); Thanks Martin, Are you able to make those changes upstream? I can change the lines locally but I wouldn't be able to push to git master. Thanks, John _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Use of lrint() in 'gdk-pixbuf/pixops/pixops.c'
Is this the right mailing list for gdk-pixbuf issues? Commit #61e3edeb79 (6th Jan 2017) introduced these 2 calls in 'gdk-pixbuf/pixops/pixops.c' (at lines 1847 and 1848):- tmp_width = lrint (src_width * prescale_x); tmp_height = lrint (src_height * prescale_y); AFAIK Microsoft's MSVC only introduced lrint() in VS2015 - so for those of us building with an earlier version the above code won't link any more. I took a quick look through glib, gtk+ (v2) and gdk-pixbuf but I can't see lrint getting used anywhere else. Any chance of a fix? Thanks, John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_text_iter_forward_search() comparison
I added the above examples to the search. I can find strasse and field but it is not so quick anymore. A good learning experience though. A UTF-8 case insensitive search is difficult. I will definitely stick with the GTK default. https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Csamples/search_textbuffer3.c Thanks again for the ideas and help. Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_text_iter_forward_search() comparison
Thank you Andrew and Chris. I thought there very well could be a language problem with checking characters like that but just didn't know. Thanks again, Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk_text_iter_forward_search() comparison
Hi Sebastien, I assume that you did not even look at the code before commenting. If code is more concise and runs faster... there is no interest? It uses UTF-8 functions but I don't have experience with other languages outside of English. I don't know how to test with other languages. Admittedly, I don't have all things figured out. Maybe there is a bug in the code. If there is no interest, that is OK with me. Not many people even look at search algorithms. I find it interesting. Eric -Original Message- From: Sébastien Wilmet <swil...@gnome.org> To: cecashon <cecas...@aol.com> Cc: gtk-devel-list <gtk-devel-list@gnome.org> Sent: Sun, Jan 29, 2017 1:35 am Subject: Re: gtk_text_iter_forward_search() comparison On Sat, Jan 28, 2017 at 07:16:04PM -0500, Eric Cashon via gtk-devel-list wrote: > I have been working on a little search experimentation. Gave writing a > case in-sensitive gtk_text_iter_forward_search() a try. The code is > shorter than what is in gtktextiter.c and it works a little faster. If > a word is searched that isn't very frequent the time is about the > same. If you just look for single chars or words that are frequent it > looks to be quicker. Is the performance of gtk_text_iter_forward_search() a problem for your application? Or you just wanted to play a little with the code? (Side note: GtkSourceView has a higher-level API for the search and replace, with regex support. If you're working on the search and replace for an application, this is worth a look.) > Not sure if this a suitable method though. I know > little of the textbuffer internals. UTF-8 gives me some trouble also. This doesn't give us confidence in your code. Bug-free code is more important than better performance at the cost of UTF-8-related bugs. -- Sébastien ___________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk_text_iter_forward_search() comparison
I have been working on a little search experimentation. Gave writing a case in-sensitive gtk_text_iter_forward_search() a try. The code is shorter than what is in gtktextiter.c and it works a little faster. If a word is searched that isn't very frequent the time is about the same. If you just look for single chars or words that are frequent it looks to be quicker. Not sure if this a suitable method though. I know little of the textbuffer internals. UTF-8 gives me some trouble also. There is a test progam at https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Csamples/search_textbuffer2.c that does a side by side comparison of the two search methods. If there is an inherent problem with the test forward search please say so. If not, maybe it can be used. I would be glad to work on it a little more if corrections need to be made. Thanks, Eric ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
gdkwin32.h / gdk_win32_drawable_get_handle()
Is it permissiable to #include in client code? Here's the scenario (I discovered this in gtk-2-24 so apologies if it's been fixed in a more recent version...) 'gdk/gdkwin32.h' declares some functions, including gdk_win32_drawable_get_handle(). It isn't declared anywhere else AFAICT and there's an accompanying macro called GDK_WINDOW_HWND. A #ifdef test (called INSIDE_GDK_WIN32) makes the macro call that function if the build is _not_ INSIDE_GDK_WIN32. So it looks like it's allowable to #include from within client code. HOWEVER... gdkwin32.h #includes gdk/gdkprivate.h (which I'd guess is NOT supposed to get #included in client code). Just wanted to check if #including a private header is okay in client code. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
FW: multitouch support for Windows
(Sorry, I forgot to reply to the list) 從 Windows 10 手機傳送 寄件者: fanc...@yahoo.com.tw 傳送時間: 2016年12月29日 13:29 收件者: Yale Zhang 主旨: RE: multitouch support for Windows Hi Yale, This sounds quite nice. Can you go to https://bugzilla.gnome.org and submit a bug there, so that someone here can take a look at your patch, so that things don’t get lost in the mail list. With blessings, thank you, and cheers! 從 Windows 10 手機傳送 寄件者: Yale Zhang 傳送時間: 2016年12月29日 11:58 收件者: gtk-devel-list@gnome.org; vincar...@gmail.com 主旨: multitouch support for Windows Greetings, I have a patch that adds the plumbing for multitouch support on Windows. I've tested it on testinput and the gesture demo, and they behave correctly. I also fixed some problems with pressure pen (Wintab) support. The tablet devices weren't showing up when calling gdk_seat_get_slaves(), probably because it associated the wrong devices. I'm using this for 2 finger gesture recognition in Inkscape for zooming, scrolling, and rotating the canvas. https://www.youtube.com/watch?v=k6qfqcroUcw Vincenzo, you were complaining about this earlier: https://mail.gnome.org/archives/gtk-app-devel-list/2015-July/msg00030.html did you want to try my patch? Anyone else who can review and check in my changes? -Yale ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.x and broadway ( and other remote options )
Il giorno mer 07 dic 2016 04:18:24 CET, Daniel Kasak ha scritto: Hi all. I posting here in response to comments on bug: https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway support likely to be removed from Gtk+4.0 ). [...] it would be great if I could use my gtk apps in browser as i do with html/css/js/etc apps (for example: responsive windows, access to client resources as files and printers, etc.) yes, i'm a fan of broadway backend; i hate programming "traditional" web apps if i can help in any way... i'm here!!! _______ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: Gtk+4.x and broadway ( and other remote options )
Hi Daniel, The main issue with Broadway is that: It is considered an experimental GDK backend, and it is not really kept up to date with the developments in GTK-3.x Specifically what this means is that there isn’t OpenGL support in it (we need OS/platform-level support for OpenGL for creating and switching (making current) OpenGL contexts), which likely needs to be done with WebGL, which most probably needs to be done in the .js file in the broadway subdir in gdk/. GTK+-4.x is going to switch to GL drawing, at least for the majority of the various components, which makes OpenGL support a requirement. AFAIK, the backends that have the needed support are x11, Wayland, mir and Windows. If you know how to do initialize OpenGL in WebGL (ie Javascript), please let the people know here, as this is what I think is mainly what needed for Broadway to stay. With blessings, and cheers! 從 Windows 10 手機傳送 寄件者: Daniel Kasak 傳送時間: 2016年12月7日 11:18 收件者: GTK Devel List 主旨: Gtk+4.x and broadway ( and other remote options ) Hi all. I posting here in response to comments on bug: https://bugzilla.gnome.org/show_bug.cgi?id=775680 ( summary: broadway support likely to be removed from Gtk+4.0 ). I think it would be a massive pity to drop broadway support from gtk. It's been a god-send for me and those I work with - it provides the best remote access to gtk apps and performs way better than vnc. I've actually been working on an authentication + transparent proxy for broadway, so multiple users can access multiple apps all via https on port 443: https://tesla.duckdns.org/transparent-proxy-for-broadway-gtk3-html5-backend/ I've dabbled in C here and there ( mainly patching minor bugs ). It's been quite a long time since I used it at all. However I'm interested in attempting to keep broadway support alive. I currently develop gtk apps ( every day ) using the Perl bindings. So I'm familiar with it from an application-developer perspective. I have no idea how big/complex a task it is I'm talking about. Could someone please comment on the difficulty of keeping broadway support working, given the planned gtk+4.x changes. I guess this would be easier if someone offers to mentor me ( please ) - though I realise we all have busy lives. Another option, if the task is too large or difficult for me, is to either offer a bounty here, or to post a project on something like freelancer. I also realise that work done via freelancer would possibly be of questionable quality, and would quite possibly break with later gtk+ versions again. Any comments on this option? Another option would be another remote-desktop / remote-app capability. I've read a little on wayland / weston and RDP. I think RDP would be a reasonable option, though haven't managed to get it working yet. What does everyone think my best options are, and why? Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
