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
Re: Proposal: Recommend meson for glib 2.58.0
On Sat, Jun 9, 2018 at 8:02 AM Nirbheek Chauhan wrote: > On Sun, Jun 3, 2018 at 1:13 AM wrote: > > > > Before making the switch please be aware of > https://github.com/mesonbuild/meson/issues/3077 and > https://github.com/mesonbuild/meson/issues/2121 which make Meson-built > libraries mostly broken on macOS, particularly with regard to g-ir-scanner. > > > > I have a fix for this: https://github.com/mesonbuild/meson/pull/3691 > > I'll wait till Monday or Tuesday for people to comment and then push > it. It will be in the 0.47 release which is scheduled for 24th June. > That's fantastic news, thank you Nirbheek! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Recommend meson for glib 2.58.0
Before making the switch please be aware of https://github.com/mesonbuild/meson/issues/3077 and https://github.com/mesonbuild/meson/issues/2121 which make Meson-built libraries mostly broken on macOS, particularly with regard to g-ir-scanner. Regards, Philip C On Sat, Jun 2, 2018 at 12:08 PM Ignacio Casal Quinteiro < nacho.r...@gmail.com> wrote: > On the gvsbuild side we are already building with meson for a while and > things are ok. I just fear the case where we do not have python 3 on rhel 6 > and sles 11... > > On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi wrote: > >> With Python 2.x getting EOL in less than 2 years, I suspect that >> commercial distros will need to provide Python 3 pretty quickly. >> >> Ciao, >> Emmanuele. >> >> On Fri, 1 Jun 2018 at 21:10, Christian Hergert >> wrote: >> >>> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote: >>> > Disclaimer: I'm not a GLib maintainer so this email is only about >>> > opening the discussion. There is no decision made yet. >>> > >>> > Opinions? >>> >>> I think the risk area is python3 support on some commercially supported >>> distributions. Although, that is probably in better shape now than it >>> was a year ago. >>> >>> Also not a maintainer, but +1 for the switch. >>> >>> -- Christian >>> ___ >>> 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 >> >> > > > -- > Ignacio Casal Quinteiro > ___ > 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: GitLab CI runners for non-Linux systems
On Fri, May 18, 2018 at 10:15 PM wrote: > Thanks for this call for help, it's our chance to finally be serious > about supporting multiple platforms, instead of always fixing a > posteriori. Thanks to gitlab that shouldn't be too hard to setup. > > Le vendredi 18 mai 2018 à 10:52 +0100, Philip Withnall a écrit : > > • macOS (ideally several versions, since we support from OS X 10.7 > > upwards[2]) > > I did a quick test on a macmini (macOS 10.13.4) we have in Collabora > office, and it's almost too easy to setup, not even a challenge! > > Well... except that glib fails to build with meson because libffi > subproject does not support darwin. I'll try to investigate that. > I've been building http://mirrors.kernel.org/sources.redhat.com/libffi/libffi-3.2.1.tar.gz on macOS with no problems since at least 10.9. I think maybe just the meson fork (https://github.com/centricular/libffi/commits/meson) of libffi has this problem. You could try pre-installing libffi from the tarball on the image, then it wouldn't use the wrapped subproject, I think? Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GitLab CI runners for non-Linux systems
On Fri, May 18, 2018 at 5:52 AM Philip Withnall wrote: > Can anybody else provide and maintain CI runners for other platforms? > I’d particularly like to see: > • *BSD (probably OpenBSD and NetBSD) > • macOS (ideally several versions, since we support from OS X 10.7 > upwards[2]) > • Android (probably a cross-build) > • More Windows configurations (currently we have MSYS2 on Windows > Server 2012; ideally we’d have a MinGW-w64 runner too) > I can help write the CI job configurations for macOS, but I don't know how to host or set up a runner. (For a shortcut solution, we could consider farming out the macOS builds to Travis CI, which has macOS runners already available) Regards, Other Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Migration to GitLab, turn your notif off to avoid mail flood
On Wed, May 2, 2018, 11:32 Christoph Reiter, wrote: > On Wed, May 2, 2018 at 7:57 PM, Morten Welinder wrote: > > It is just me, or is the migration mangling bugs? > > > > Compare https://bugzilla.gnome.org/show_bug.cgi?id=765921 > > to https://gitlab.gnome.org/GNOME/gtk/issues/621 > > > > In bugzilla, the cut-and-paste compile commands with output are readable. > > In gitlab, they're a mess. > > If you see a migrated bug that's hard to read please add some markdown > formatting: > > https://docs.gitlab.com/ee/user/markdown.html#code-and-syntax-highlighting Just wanted to add that cut-and-paste is pretty freeform on Bugzilla. It wasn't possible to get all the cases right, and handling some would have messed up others IIRC. So I picked some heuristics that mostly worked on my test migrations of GJS. Even so, I had to edit some bugs and comments to add markdown formatting, so I expect that maintainers will need to do that in some cases for GTK as well. I'd be happy to review any updates to the migration tool that improve its ability to guess whether a particular paragraph should be enclosed in triple-backticks or not. Regards, Philip C > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-introspection Version 1 || GNOME
Hi, As is the standard in open-source software, you can find the license information in the COPYING file in the root directory of the source distribution or Git repository: https://gitlab.gnome.org/GNOME/gobject-introspection/blob/master/COPYING We do not have an ECCN number. Although I don't believe that gobject-introspection uses encryption directly, it can be used to load encryption libraries in client code, and there are no restrictions on the purpose it could be used for. I make no guarantees as to the accuracy of this information. We unfortunately cannot provide any legally binding details, other than what you can find yourself by inspecting the source code. Since many of our contributors are individuals, not connected with any company, we cannot do anything that might expose them to legal liability. Best regards, Philip C On Wed, Mar 7, 2018 at 2:27 AM Chhabra, Komal /CS < komal.chha...@exxonmobil.com> wrote: > Hi Team, > > > > This is Komal Chhabra, a Team Lead from centralized license management > team of ExxonMobil known as Software Asset Management[previously known as > ITAM. The Software Asset Management group at ExxonMobil exists in large > part to steward software license compliance > > > > We are contacting you to get *ECCN *details for product *gobject-introspection > Version 1 *: > > > > Could you please provide us the ECCN number for this software > > > > * If you do not have your software classified with an ECCN, > please kindly answer the following questions* so that we may self-assess > if there may be any prohibition or restriction for export or re-export of > this product. > > > > 1, Does the Software perform any encryption or utilize any > encryption processes? Y/N > > 2. If the answer is YES to question 1, please indicate if the > encryption is coded into the application or separately called (such as > using SSL) > > 3. If the answer is YES to question 1, please indicate what > function(s) the cryptography/encryption serves > > > > A, Copyright protection purposes (Includes using a license > key/code) > > B, User authentication purposes > >C, A core part of the functionality such as to encrypt databases > >D, To encrypt communications between the software and a host > system. > > > > Background information: > > An Export Control Classification Number (ECCN) is a specific > alpha-numeric code that identifies the level of export control for items > e.g. software that are exported from member states of the Wassenaar > Arrangement, including the United States. After obtaining the ECCN, the > exporter must determine whether an export license is required > > > > Waiting for your kind acknowledgment. > > > > Regards, > > > > *Komal Chhabra* > > *New Products & Complex Team* > > *EMIT | IT OPS | Customer Infrastructure | WDS | SAM* > > > > *HCL Technologies Ltd. * > > *(CIN: L74140DL1991PLC046369)* > > *10th Floor, ODC-IV, Software Tower 6, Sector 126* > > *Noida SEZ, Uttar Pradesh – 201301, India* > > *Email : komal.chha...@em-msph.com * > > > > *for* > > > > *ExxonMobil Global Services Company* > > *22777 Springwoods Village Parkway* > > *Spring, TX 77389* > > *United States of America* > > > > > > *From:* Chhabra, Komal /CS > *Sent:* Friday, February 23, 2018 2:46 PM > *To:* 'gtk-devel-list@gnome.org' > *Subject:* RE: gobject-introspection Version 1 || GNOME > *Importance:* High > > > > Hi Team, > > > > This is Komal Chhabra, a Team Lead from centralized license management > team of ExxonMobil known as Software Asset Management[previously known as > ITAM. The Software Asset Management group at ExxonMobil exists in large > part to steward software license compliance > > > > We are contacting you to get *few* details for product * > gobject-introspection Version 1 *: > > > > 1. Under which agreement it falls under: MIT , GPL or LPGL ? > > 2. Could you please provide us the ECCN number for this software > > > > * If you do not have your software classified with an ECCN, > please kindly answer the following questions* so that we may self-assess > if there may be any prohibition or restriction for export or re-export of > this product. > > > > 1, Does the Software perform any encryption or utilize any > encryption processes? Y/N > > 2. If the answer is YES to question 1, please indicate if the > encryption is coded into the application or separately called (such as > using SSL) > > 3. If the answer is YES to question 1, please indicate what > function(s) the cryptography/encryption serves > > > > A, Copyright protection purposes (Includes using a license > key/code) > > B, User authentication purposes > >C, A core part of the functionality such as to encrypt databases > >D, To encrypt communications between the software and a host > system. > > > >
Re: Contribution question
On Thu, Jan 18, 2018 at 2:30 PM Pavlo Solntsev wrote: > Hi, > > To better understand how some glib modules work, I write mini tests. I was > thinking it would be beneficial for a lot of people if more examples will > be included into the documentation to better explain how an object can be > used. Similar to what QT has. I may contribute my examples. When I see > a code on git hub I think about pull request. Do you use this approach? Or > I should generate a patch and attach it to the bug report as described here > https://github.com/GNOME/glib. I saw https://gitlab.gnome.org/ was > created. Is it a common trend for ? Does glib also go there? Sorry for so > many questions, just want to understand how dev process works. > Hi Pavlo, The GNOME GitHub mirror is just a read-only mirror. Pull requests are ignored for most repositories, although some maintainers will monitor them. I'm not sure what's the case for GLib. GNOME is in the process of migrating all their repositories to gitlab.gnome.org, so GLib will go there eventually too, and accept merge requests there. But until the migration is complete, you should follow the old workflow: generate a patch and attach it to a bug report in Bugzilla. Good luck with your contribution! Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk 3 stuck menu bug on Mac
On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: > > What I found out so far is that whenever this problem occurs, both of the > > following two checks in function gtk_menu_motion_notify() (gtkmenu.c) > return > > false and the function is thus aborted at this point: > > > > menu_item = gtk_get_event_widget ((GdkEvent*) event); > > ... > > if (!GTK_IS_MENU_ITEM (menu_item) || > > !GTK_IS_MENU (parent)) > > return false; > > Looking further at this issue, the problem is probably not a timing issue > like > I first considered in my previous email. Fact is that the wrong widget > under > the mouse pointer is resolved forever whenever this issue starts to occur: > > At this code location above, the gtk_menu_motion_notify() function expects > menu_item to be a "GtkMenuItem" gobject class, however when this issue > occurs, > menu_item is pointing at its parent "GtkMenu" gobject instead. > > I would understand if this misbehavior just happens immediately after a new > menu pops up. But whenever this stuck menu issue occurs, I can continue to > move the mouse pointer over all the visible menu items for hours and the > resolved toplevel widget under the mouse pointer (resolved by the Quartz > implementation) is always the GtkMenu widget instead of the respective > GtkMenuItem widget. > > Since this issue only seems to happen on Mac, and since it worked > flawlessly on > Mac before, and since I see the Quartz implementation hasn't really changed > (significantly) in the last couple years, was there some kind of important > change in gtk 3 that still would need to be applied to the Quartz driver? > No-one's really maintaining the Quartz backend at the moment, so if you felt like investigating this it would be really appreciated. You could try a 'git bisect' to see what change in GTK3 might have caused the regression and that would probably make it easy to see what would need to be changed in the Quartz backend. Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stackexchange community for GNOME/GTK+
On Wed, May 10, 2017 at 7:02 AM Tobias Mueller wrote: > Hi. > > On Mi, 2017-05-10 at 08:04 -0500, Michael Catanzaro wrote: > > Looks like if you want to do this, we'd have to host it > Or use Stackoverflow. > Sri's motivation was: > > > We need to have a search engine index-able library of knowledge on > > our platform. Modern programmers today frequently use stackexchange > > and google to ask questions and to look for answers for questions.\ > > I tend to think that Stackoverflow perfectly matches that. > Agreed, I'm a big fan of this but I don't see a reason why it ought to be a separate community from the existing Stack Overflow site. Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib.DIR_SEPARATOR_S problem on raspbian
On Tue, Sep 13, 2016 at 3:36 AM narcisse doudieu siewe < wambenarci...@yahoo.fr> wrote: > Hello just to signal a problem. > > GLib.DIR_SEPARATOR_S on raspbian gives "\\" in place of "//". > and GLib.DIR_SEPARATOR gives 92 number. > Several bugs are reported for this: https://bugzilla.gnome.org/show_bug.cgi?id=696935 https://bugzilla.gnome.org/show_bug.cgi?id=749636 https://bugzilla.gnome.org/show_bug.cgi?id=757284 The short answer is, these constants are broken in introspected language bindings so don't use them. For example, in Python use the os.path module and in Javascript use GLib.build_filenamev() or Gio.File. Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Mon, Sep 12, 2016 at 8:14 AM Davin McCall wrote: > Hi, > > I'm not a regular poster to this list and am not subscribed. I'm posting > here now at the suggestion of Philip Chimento, who read a blog post I wrote > recently [1] about the GTK+ lifecycle plans that have recently been > discussed/announced. This blog post of mine received, for whatever reason, > a lot more attention on anything than my blog normally does (just shy of > 20,000 views in a day, when my average views per day of the whole blog is > around 10) - which puts me in a position such that I feel I should address > the concerns in a more head-on (and level-headed) fashion. I'll freely > admit the tone in the blog posting is that of an indignant rant, though I > hope no-one is personally offended by it since that certainly wasn't my > intention. > > I'm concerned at the outset that this will be dismissed by people who are, > after all, much more involved in GTK+ than I've ever been, so I ask that > you read this with an open mind and with the understanding that I'm writing > this out of genuine concern that's developed from the experience of dealing > with API breakages in various packages over a long time-frame. > > My concern is that the new plan lays a foundation for breaking the API on > a more regular basis, and formalises the notion that this is ok if it > allows innovation in the design and development of GTK. While I am all for > innovation, I am disturbed that casual API breakage in its name is being > legitimised, especially because I do not believe that is necessary. From > the proposal [2], statements such as: > > If new features conflict with existing ones, API might be removed, rather > than being deprecated. > > ... are of particular concern. Further, I don't believe that this is > consistent with the very next point in the same document: > > there will be an effort to limit breakage as much as possible. > > "As much as possible" is a *very* strong statement. If this was really > the aim, there would be hardly any legitimate reason to break API at all, > making the whole plan unnecessary. I'd suggest that the latter point is > somewhat disingenuous (even if unintentionally so); putting it bluntly, > only one of those two points can be correct, and from the tone of the > document, I'm assuming that it's the first one and the second is a case of > overly-strong wording. But on the other hand, removing API instead of > deprecating is most definitely a breaking change that can often be *easily* > avoided, let alone "as much as possible". > > Please do not assume I am basing my entire concern on that point alone. > The general feeling from the proposal and the GTK development blog post > that I initially responded to is that API stability is very much being > pushed to a low priority compared to the need to push development ahead. I > understand that API breakage does sometimes need to occur, but I think this > attitude is not a good one. In particular I think the implied notion that > API stability and good development progress cannot coexist is incorrect. > I would be reassured perhaps if the plan discussed what software > development methods were in place that would help to reduce the amount of > API breakage needed. What is the procedure for API design in GTK - if there > indeed is one? Are APIs reviewed before they are implemented? Are they made > available for public review? Are there any guidelines? The Best Practices > document [3] doesn't even mention API design; why not? Are the APIs even > designed at all? I am left with the worrying impression (hopefully not > correct) that the API simply emerges from the code. This would certainly > explain why API breakage might be needed on a regular basis, but that's a > symptom of an imperfect design practice; if it is being found that the > resulting APIs are not extensible or flexible enough for ongoing > development and future requirements, then I strongly suggest that the > better solution is to improve the API design methodology, rather than > simply to legitimise casual API breakage. > > I understand how open-source development often works in ways that don't > suit more traditional rigourous approaches, but I would recommend > establishing a set of guidelines for API development, and at a minimum have > each commit/check-in that introduces new API be reviewed against those > guidelines by a developer not otherwise involved. Since I can't claim to > know how GTK development proceeds there's the possibility that something > like this (or better) already happens - in which case, perhaps my concerns > can be dismissed; if so, please consider publi
GTK-Next (was: Re: Gtk+4.0)
On Tue, Jul 19, 2016 at 11:08 AM Simon McVittie < simon.mcvit...@collabora.co.uk> wrote: > On 09/07/16 20:42, Jasper St. Pierre wrote: > > In fact, this could be a new plan. If we double down on Flatpak, then we > > could simply not bump soname / major version, leave it at 4, break ABI > > every point release, and have the ".6-multiple" releases be LTS releases > > which are "maintained more than most". > > Speaking as a distribution (Debian) developer: breaking the ABI without > bumping the SONAME is really frustrating to deal with in distributions; > so if there will be anything that uses Gtk and is ever distributed in > ways other than Flatpak and similar things, please manage the Gtk SONAME > correctly. > > gnome-shell, gnome-control-center and gnome-settings-daemon, together > with their forks in GNOME derivatives like Cinnamon, are among prominent > packages that depend on Gtk but should be part of the distribution's > release process, even in a possible future where ordinary apps are > exclusively distributed via Flatpak. (I don't think that future has > arrived yet, in any case.) > Now for the comedy part of the discussion. I'd like to follow through on the double-down-on-Flatpak proposal, even if Jasper didn't mean it seriously. I don't mean it entirely seriously either, since it has some serious flaws detailed below, but it does address some of the concerns I summarized in my email from just now [1]. The stable series would be much as in the original GTK 4 proposal, but it would just be called "GTK". That indicates to outsiders who don't care about release schedules and just want a GUI toolkit, that this is the toolkit to use. GTK would receive bugfixes, and possibly backports of new features if maintainer time and inclination allows. The unstable series would get a different name that isn't "GTK", e.g. "GTK-Next", and become (imagine air quotes around this) "Flatpak-only". Air quotes because it would of course still be released as a source tarball, and if a distro wanted to package it of course no-one could stop them; but we would discourage it from being available through distro package managers. Air quotes also because it wouldn't be limited to Flatpak on Linux; I would for example be able to build GTK-Next and bundle it inside an application bundle on Mac OSX. That use would also be encouraged, as well as its equivalent on Snappy, as well as whatever application sandboxing solution arises on any other platform in the future. But as far as GNOME is concerned, GTK-Next would be released first and foremost as part of the org.gnome.Platform Flatpak runtime. This does cut off system components such as gnome-control-center from using GTK-Next, as Simon pointed out above. This would also leave applications in somewhat of an awkward position if they wanted to use GTK-Next but needed to use a library that depends on GTK, such as GtkSourceView, VTE, or WebKitGTK. I see two possibilities here: 1) if the library maintainer is amenable to doing the work, the library could have a GTK-Next branch with a separate pkg-config name, and this would be released with the same intention and through the same channels as GTK-Next. 2) if the library maintainer is not interested, the application author would have to port the library to GTK-Next themselves and bundle it in their application. The worst part of this proposal is that it makes it very hard for app maintainers to use GTK-Next if they want to keep releasing their app in the traditional manner, not as a Flatpak or other bundle. They could decide to maintain a separate GTK version alongside the GTK-Next version of their app, but that's a really crappy story to sell to developers. Maybe we could include some tooling which would make it easy for GTK-Next to be built as an application's internal library in pkglibdir? It might mean that in practice the only users of GTK-Next would be applications like GNOME Documents and GNOME Music, which would be a shame. It would also feed the perception that GTK is primarily there for the consumption of GNOME and other consumers are an afterthought. The pros of this proposal are that it's crystal clear that GTK-Next is opt-in only, and the bulk of the extra work falls onto the people who opt-in. It removes packagers and distros from the equation entirely and so will not cause them more work. Put bluntly, the idea is to make it harder for app maintainers to opt-in to the unstable series if they aren't serious about keeping up with the porting work, as well as limiting the damage they can do if they leave an app stuck on an old version of GTK-Next. No version numbering schemes were harmed in the making of this email. Happy hacking everyone, Philip C [1] https://mail.gnome.org/archives/gtk-devel-list/2016-August/msg00015.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 9:31 PM wrote: > On Sat, Jul 9, 2016 at 12:06 PM wrote: > >> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort >> wrote: >> >>> >>> Here are some thoughts I have about all this, from a downstream >>> maintainer POV. >>> >> >> Thanks! It's good to get opinions from all over the place. >> > > And, speaking of that, there was a blog post [1] on the GTK 4 subject that > recently got a lot of attention on Hacker News. I reached out to the author > and encouraged them to give their opinion here, but it seems the message is > stalled in the moderator queue. Is there a moderator who can help? > > [1] > https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/ > Could a moderator please help with this? At this point, the blog post is starting to attract comments insinuating that we're suppressing the discussion on purpose [2]. Best, Philip C [2] https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/#comment-1050 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
I realized this thread had been sitting for quite a while. GUADEC is about to start and I'd like to summarize what's been talked about. Some of the concerns I read from this thread are: 1. Developers are concerned about there not being enough indication of which APIs are more likely or less likely to be overhauled in the unstable series. 2. Maintainers of non-core GNOME apps are concerned that they will be sucked into the unstable series; in other words that it's not opt-out enough. 3. App developers are concerned that the stable series will be ignored in favor of the unstable series. 4. Maintainers of libraries that depend on GTK (such as GtkSourceView, VTE, WebKitGTK) are concerned about having to maintain essentially a separate library for each unstable release. 5. Packagers are concerned about apps depending on a library that depends on an unstable version of GTK, then ceasing development, leaving a straggler package in the distro. 6. Users, maintainers, and packagers are concerned that it will be daunting to keep up with stable GTK's 2-year API/ABI break cycle even if not opting-in to the unstable series, and that maintainers will instead choose to remain on GTK 3.x or GTK 2.x. 7. Distro maintainers are concerned about having to recompile the whole world too often because of the unstable series necessitating frequent soname changes. Did I forget anything? Please help me summarize. I suggest phrasing it as "$ROLE is concerned about $THING" as I believe that's conducive to thinking about others' needs rather than a my-opinion-versus-your-opinion discussion. (Not saying those are not good to have, but I think at this particular stage, summarizing and understanding is more useful than hashing it out.) There are also the as-yet unanswered FAQs from the FAQ [1], copy-pasted below, that I think we should try to answer by the end of GUADEC: - Why can't the stable release cadence be longer than 2 years? - Why can't the stable releases stay supported for longer than 2 years? - Why release API-breaking major versions on a cadence? Can't you just do it only when necessary? - How about a GtkPrivate library and #define I_WANT_UNSTABLE_API? - How can I support both the stable and unstable releases? - How will this affect theme developers, since they don't get to choose what version to target like app developers do? By the way, Christian: Peter suggested turning this post of yours [2] into a post on the GTK blog, would you be interested in doing that? Best, Philip C [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ [2] https://mail.gnome.org/archives/gtk-devel-list/2016-June/msg00032.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sun, Jul 10, 2016 at 3:51 PM John Tall wrote: > On Sat, Jul 9, 2016 at 9:06 PM, wrote: > > I'm expecting this will become less and less of a problem as apps move > to Flatpak as a means of distribution. > > As far as I know Flatpak only targets GNU/Linux, and at the moment > only targets a handful of distros. I make software for not only > GNU/Linux but also Windows, FreeBSD and macOS. I use many libraries > including GTK+. I don't know yet if or how these changes will impact > me, all I know is that the way things are right now works just fine > for me. > Let me state categorically: Nothing in this proposal forces anyone to use Flatpak. Though I am excited about Flatpak if that wasn't obvious by now, I myself also make software for other platforms than Linux and contribute quite a lot of my time towards keeping GTK and other libraries buildable on Mac OS X. I really don't want to turn this thread into a discussion of the merits of Flatpak. What I did (more explanation here [1]) was try to answer a question, essentially "What if some app developer does ?" that I would previously, before Flatpak existed, have answered "Well, don't do that then." Instead, I can now say "I hope fewer people will do because of Flatpak." > I'm worried that we're breaking things that already work for lots of > us in order to fix inconveniences that some people have. I don't want > to drastically change the way I make and distribute software just > because one of the many libraries that I use has decided to do things > differently. If things need to change then do whatever is necessary > but please, let the old stuff also continue to work. > If you track the long-term supported releases of GTK with your software, then you shouldn't need to change anything in the way you make and distribute it. Regards, Philip C [1] https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg9.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 1:14 PM Peter Weber wrote: > Hi! > > On Sat, 2016-07-09 at 19:06 +, philip.chime...@gmail.com wrote: > > > I'm expecting this will become less and less of a problem as apps move > > to Flatpak as a means of distribution. > > Uhuuu. I'm sorry, but this is bad. > > This mixes two completely different problems together, packaging and a > toolkit. So enforcing Flatpak on distributions, developers and users > should solve a problem with Gtk+? > No, nothing about any of this proposal forces people to use Flatpak. The problem Emilio mentioned was, > some third party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for GTK+ 4.4, as then distros would need to ship an increasing number of versions that are unlikely to get any support upstream. In my opinion, the expectation is that app developers who sign on to the unstable series will see it through until the next long-term stable release, and not abandon development while still targeting an unstable release, leaving distros to package GTK 4.2, GTK 4.4, VTE-for-GTK-4.2, VTE-for-GTK-4.4, etc. because apps are all stuck at different versions. Of course, nothing is stopping developers from doing that anyway. The same way nothing is stopping me right now from putting this line in my app's configure.ac: PKG_CHECK_MODULES([APP], [gtk+-3.0 >= 3.18 gtk+-3.0 < 3.20]) However, if I did that then any distros trying to package it would quite rightly complain. I'm saying that if an app developer feels the need to do that, then they will be better off targeting a Flatpak runtime. Having said all this, I'm thinking about sketching out a proposal that doubles down on Flatpak like Jasper was suggesting. Paradoxically I think it might seem more palatable to more people... more updates later. Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:13 PM Jasper St. Pierre wrote: > On Sat, Jul 9, 2016 at 12:06 PM, wrote: > >> On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort >> wrote: >> >>> Hi, >>> >>> On 21/06/16 16:26, Peter Weber wrote: >>> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying >>> to >>> > write about my thoughts, in a careful way. In the first moment, I >>> thought >>> > this is a good idea and just the numbering is misleading. Stability is >>> what >>> > developers want, we need it, we love it. With a few days distance, >>> > numbering is just a small issue, I see this now entirely different and >>> > three major issues: >>> >>> Here are some thoughts I have about all this, from a downstream >>> maintainer POV. >>> >> >> Thanks! It's good to get opinions from all over the place. >> >> My concern with this new scheme is that GTK+ libraries will have to bump >>> the >>> soname every 6 months (if they want to support the latest GTK+). That >>> can be >>> manageable for say vte or gnome-desktop, although it may be bad if some >>> third >>> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it >>> for >>> GTK+ 4.4, as then distros would need to ship an increasing number of >>> versions >>> that are unlikely to get any support upstream. >>> >> >> I'm expecting this will become less and less of a problem as apps move to >> Flatpak as a means of distribution. >> > > How does Flatpak solve this problem? > If an app was released as a Flatpak, it would target a Flatpak runtime. There would not be a choice between targeting VTE-for-GTK-4.2 or VTE-for-GTK-4.4, and so distributions would not need to ship a VTE-for-GTK-4.2 straggler that some app was still targeting. But do you expect WebKitGTK+ to bump the ABI every 6 months? >>> >> >> That does seem to point to a problem — if an app uses Library X which >> does follow the unstable GTK series, and Library Y which doesn't, then the >> app developer is forced to stick to the stable series of GTK and an old >> version of Library X in order to accommodate Library Y. >> >> Any thoughts? >> >> I feel like the X.[024] releases are just snapshots of a development >>> branch, >>> with X.6 being the stable release, and I wonder if X.[024] shouldn't >>> clearly be >>> labelled as that, regardless of what version number is chosen (be it 4.0, >>> 3.99.0, 4.0beta1 or whatever). >>> >> >> In my opinion the label "unstable release" communicates exactly that. I'm >> not sure what "development branch" communicates that "unstable release" >> doesn't? >> > > The convention in GNOME up until know has been that even numbers are for > stable releases, and odd ones are for unstable releases. I didn't know GTK+ > 4.0 would be considered an unstable release. > There are several different version numbering schemes proposed on this wiki page [1]. I was referring to the term "unstable release" versus "development branch". [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Sat, Jul 9, 2016 at 12:06 PM wrote: > On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort > wrote: > >> Hi, >> >> On 21/06/16 16:26, Peter Weber wrote: >> > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to >> > write about my thoughts, in a careful way. In the first moment, I >> thought >> > this is a good idea and just the numbering is misleading. Stability is >> what >> > developers want, we need it, we love it. With a few days distance, >> > numbering is just a small issue, I see this now entirely different and >> > three major issues: >> >> Here are some thoughts I have about all this, from a downstream >> maintainer POV. >> > > Thanks! It's good to get opinions from all over the place. > And, speaking of that, there was a blog post [1] on the GTK 4 subject that recently got a lot of attention on Hacker News. I reached out to the author and encouraged them to give their opinion here, but it seems the message is stalled in the moderator queue. Is there a moderator who can help? [1] https://davmac.wordpress.com/2016/07/05/why-do-we-keep-building-rotten-foundations/ Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Thu, Jul 7, 2016 at 11:30 AM Emilio Pozuelo Monfort wrote: > Hi, > > On 21/06/16 16:26, Peter Weber wrote: > > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to > > write about my thoughts, in a careful way. In the first moment, I thought > > this is a good idea and just the numbering is misleading. Stability is > what > > developers want, we need it, we love it. With a few days distance, > > numbering is just a small issue, I see this now entirely different and > > three major issues: > > Here are some thoughts I have about all this, from a downstream maintainer > POV. > Thanks! It's good to get opinions from all over the place. My concern with this new scheme is that GTK+ libraries will have to bump the > soname every 6 months (if they want to support the latest GTK+). That can > be > manageable for say vte or gnome-desktop, although it may be bad if some > third > party apps pick a dependency on the vte for GTK+ 4.2 but don't update it > for > GTK+ 4.4, as then distros would need to ship an increasing number of > versions > that are unlikely to get any support upstream. > I'm expecting this will become less and less of a problem as apps move to Flatpak as a means of distribution. But do you expect WebKitGTK+ to bump the ABI every 6 months? > That does seem to point to a problem — if an app uses Library X which does follow the unstable GTK series, and Library Y which doesn't, then the app developer is forced to stick to the stable series of GTK and an old version of Library X in order to accommodate Library Y. Any thoughts? I feel like the X.[024] releases are just snapshots of a development branch, > with X.6 being the stable release, and I wonder if X.[024] shouldn't > clearly be > labelled as that, regardless of what version number is chosen (be it 4.0, > 3.99.0, 4.0beta1 or whatever). > In my opinion the label "unstable release" communicates exactly that. I'm not sure what "development branch" communicates that "unstable release" doesn't? Regards, Philip C ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Thu, Jun 23, 2016 at 9:29 AM Peter Weber wrote: > On Tue, 21 Jun 2016 17:07:46 +0100, Simon McVittie > wrote: > > Ideally, we'd choose the trade-off such that projects that want to stick > > to a stable-branch version are happy with its stability, while also not > > feeling that they are missing out on too much new stuff by doing so. A > > year is probably too fast? 5 years is probably too slow? I don't know > > what the right middle ground between those two is, but 2 years sounds > > like a good first guess. > > I started to think about it this. I tend to compare Gtk with Qt, but they > are not the same. On the other hand, Gtk and Qt are only major > platform-independent toolkits and largely used on GNU/Linux. The active > phase of Gtk2 lasted from 2001 - 2011 and it is still maintained in 2016, > which is a scary long time. Qt's cycle is much shorter, they moved from > 2.x till 5.x in same time frame. > > The current proposal will split Gtk into stable branch, which will break > in an insupportable* short-period of two years. Even if some major > applications will move immediately to a stable release, they will already > use the out-dated within two years. Furthermore GNOME will not use "Gtk", > GNOME will use it's own Gtk which will likely look and feel different in > several ways(HIG?). I'm afraid support for at least the development Gtk, > the stable Gtk and the old-stable Gtk will be required also. > > * Thank you English language for this word! > > 10 Years are too long and 2 years are too short. Right? Is it better to > break the API/ABI clearly once and keep it stable for some years, maybe a > range between 4 to 6 years? In this area compatible (non-breaking) > features > can be added. I'm feeling far more comfortable with this idea. This sounds > similiar to Qt and maybe it's a good approach: > > + all applications will largely use the same toolkit (good for users) > + reliable planning (application developers) > + necessary API/ABI break (library developers) > + less maintenance burden (library developers) > - not so many freedom through API/ABI break (library developers) > > I would prefer a faster and more firm cycle. > I've tried to capture some of the discussion that we've had so far, on-list and off, in this FAQ [1]. I also added some points for further discussion, such as the longer cycle length you mentioned above. Regards, Philip C [1] https://wiki.gnome.org/Projects/GTK%2B/Lifecycle/FAQ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+4.0
On Tue, Jun 21, 2016 at 7:34 AM Peter Weber wrote: > Hello! > > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to > write about my thoughts, in a careful way. In the first moment, I thought > this is a good idea and just the numbering is misleading. Stability is what > developers want, we need it, we love it. With a few days distance, > numbering is just a small issue, I see this now entirely different and > three major issues: > > 1. Separating official applications from GNOME, away from all other major > applications > 2. Very short stable-release-cycle, every two years an API/ABI-Break is > really bad for all > 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the > most important part for a toolkit > > > > I hope you don't hate me now. Quite the opposite, thanks for starting the discussion. I think many people who were at the hackfest are still recovering from travel and catching up what they missed at work, so no-one started a thread on this. > I'm trying to elaborate this: > 1. Separating official applications from GNOME, away from all other major > applications: > Applications will be splitted in modern and outdated ones. Users will see > modern applications from GNOME and a lot of old stuff, mainly well-known > applications. As time of writing, neither Gimp, Inkscape, Geeqie, Pidgin > nor Geany merged to Gtk3. After five years we see now Firefox and > LibreOffice (?) on Gtk3, and progress on Gimp and Inscape, Gtk3 was > released in 2011. In my opinion, this is what the proposal tries to solve. I think a common message is that outside applications don't want to risk porting to GTK 3 because it's not stable enough. I hope that once GTK 4 is released and declared stable, then applications like Firefox and LibreOffice would be confident enough to start porting right away. Especially if we can have some decent porting guides in place when the new stable release rolls around. I'm not sure about this, but I suspect the jump between GTK 2 and 3 was quite a lot larger than the jump between GTK 4 and the following stable version will be. Since GTK 2 reigned for 10 years, there were a whole lot of breaking changes that had to happen at once when the opportunity arose. > From the developers side, we will forced to choose > between to nasty options, an already outdated stable API/ABI or a shiny new > API/ABI, which will break fast. > Even if the tradeoff is as bad as you describe, it's better than the one that application developers get in the current situation: a 10-years (instead of 1.5 years) outdated stable API/ABI or a shiny new API/ABI which is not expected to break between releases but in practice it does anyway. I'm hoping the tradeoff will not be as bad as you describe though :-) Two years is a much shorter cycle and the stable version will not get as outdated. As for tracking the unstable series, well, it's definitely opt-in for a reason, and you shouldn't do it unless you are OK to deal with the breakage. I expect though that given the option of a two-year stable series, most developers outside of GNOME will use the stable series. I certainly plan for my side projects to track the stable series. If I can finish writing it, I'll add a FAQ page to the wiki today that will try to illustrate better what the benefits and drawbacks are for application developers. 2. Very short stable-release-cycle, every two years an API/ABI-Break is > really bad for all: > If the API/ABI becomes stable every fourth release or two years, this is > to short for the developers to adapt. Constant breaking is bad for > developers! We will see a lot of different stable API/ABIs used within > years (or not, which isn't better). And the Gtk+-Team will have to support > a lot of stable-branches: Gtk2, Gtk+3, Gtk4 (two years later), Gtk5(four > years later) and so on. > This sounds like very much work and is bad for the Gtk+-team. Currently > the Gtk+-Team has to support Gtk2 and Gtk3, only. > I believe the idea is to support one stable and one unstable release at the same time. In my opinion, if GTK 8 is the current stable version and you're still on GTK 3, then that should be equivalent to if you're still using GTK 1 in 2016... Furthermore the alignment to Debian/Ubuntu LTS sounds like a permanent > delayed cycle building on top of each other. I don't expect many developers > to catch up with unstable/upstream or even using "git clone://", in case of > Ubuntu or Debian this could happen: > -> LTS -> Stable API/ABI -> Developers start adapting > -> Subsequent LTS -> Adapted applications available -> But already new > stable API -> Developers start adapting again > This is a good point and it seems like the stable GTK should pick a judicious time to release that fits with distros' release cycles. > 3. No actual reason to break the API/ABI of Gtk3.x, but stability is the > most important part for a toolkit: > Nobody named a reason, why it is really necessary to break the
Re: Does Gtk+ Still Support Application-Provided Widgets?
Hi, To a certain, lesser, extent this has always been the case: for example, I filed [1] a long time ago because you can't write your own GtkContainer subclass with an internal layout manager and have gtk_container_add() and gtk_container_remove() still work on it, although GtkAssistant does this and gets special privileges to allow it. I'm not a core GTK developer so I don't know why things were set up this way, but I assume it's because no-one (yet) wants to guarantee the stability of the API in the private files, and once it's been declared stable it'll be exposed. I hope that particularly the CSS gadget stuff is eventually meant to be public, but if it were public before it was stable, then people's custom widgets would just break on each new release anyway, right? [1] https://bugzilla.gnome.org/show_bug.cgi?id=699756 Regards, Philip C On Sun, May 1, 2016 at 9:20 AM Morten Welinder wrote: > Gtk+ used to support custom widgets. Whenever you were unhappy with > the official > set you would hack up your own. More often than not, this would start > by copying > an official widget's code and do a mass rename of identifiers. > > No more. > > More and more of the api needed to created widgets is migrated into > gtk*private.h > headers rendering it inaccessible for applications. Take GtkButton, > for example. > It includes the following private headers: > > #include "gtkbuttonprivate.h" > Just a structure, but it is included also outside gtkbutton.c. I.e., > widgets like GtkCheckButton > are allowed special privileges that MyButton is not. > > #include "gtkwidgetprivate.h" > Again, there really should not be any API that in-tree widgets are > allowed to use, but > out-of-tree widgets are not. I can see a case for > "gtkwidgetprotected.h" in the C++ sense, > though. > > #include "gtkprivate.h" > No idea. > > #include "gtkapplicationprivate.h" > I don't think this one is actually used. > > #include "gtkcsscustomgadgetprivate.h" > The whole gadget machinery is private. Anyone who wants stateful css > nodes gets to > implement the whole css stack themselves. > > #include "gtkcontainerprivate.h" > This is just silly. Either something is useful for containers in > general and it should be public, or > else it is not useful and it should go into gtkcontainer.c > > Suggestion: Only gtkbutton.c should be allowed to include > gtkbuttonprivate.h and similarly > with other private headers. Create gtkbuttonprotected.h if needed and > install it. Add needed > API for derivation either to gtkbutton.h or gtkbuttonprotected.h. > > Morten > ___ > 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: Ülease get gtk3 css definition to be similar to gtk pixbuf!
On Sat, Jul 25, 2015 at 9:26 AM, Matthias Clasen wrote: > We will be discussing how to document the evolving GTK+ css > capabilities in a clearer way at Guadec in a few weeks. > I wanted to reply to this before GUADEC but it slipped my mind. Here's a documentational Gist of supported CSS properties, as of GTK 3.8, that I put together a couple of years ago by reading the GTK source at the time. It may be useful to your discussion (if that discussion hasn't already happened) as an example. https://gist.github.com/ptomato/0fb634ef4098bb89026f Another thing that I'd find useful in GTK CSS documentation is to document exactly how the properties differ from their web counterparts, and indeed which web properties are not supported. I'm not a web programmer but even for me that would be useful, because the majority of CSS documentation and examples out there are for the web. Regards, Philip -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMemVTable broken
On Fri, Jun 26, 2015 at 8:50 PM, Jasper St. Pierre wrote: > Yeah, we've all been sort of aware of this for some time. I've abused > it to the fact where I know that malloc and g_new / free and g_free > will *always* be the same since a specific glib version. > > I think removing all the code is fine. > > On Fri, Jun 26, 2015 at 8:38 PM, Alexander Larsson > wrote: > > So, I just tried to use the memory profiler in glib, and I crashes > > really early because the gobject constructor (gobject_init_ctor) calls > > g_malloc before main() is reached. > > > > This means g_mem_set_vtable() is impossible to use. I don't necessarily > > think this is all that bad. Honestly we should never have made it a > > vtable (one extra vfunc per malloc...) and instead do memory profiling > > etc the "normal" way, i.e. LD_PRELOAD something with malloc > > interceptors. Maybe we should just remove all this code and keep > > g_mem_set_vtable as a dummy function that prints a deprecation warning? > Would it be possible to write a how-to page on the Gnome wiki that the documentation of the now-deprecated function would point to? I'm afraid that new developers would be the ones hit hardest by this. I certainly used g_mem_set_vtable to my benefit when I was first starting out with the Gnome stack. I could now figure out how to do memory profiling the "normal" way, as you say, on my own, but I certainly wouldn't have been able to 8 years ago. Regards, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GL and libepoxy
On Fri, Mar 6, 2015 at 8:49 PM, Jasper St. Pierre wrote: > Are you sure? This shouldn't be the case since > > > https://github.com/anholt/libepoxy/commit/e3051481cc9f5b7b36b317aff1454ee16ea9cdb9 > > On Fri, Mar 6, 2015 at 7:54 PM, John Ralls wrote: > >> It looks like we've committed to using libepoxy[1] as a shim for GL >> support. It looks quite nice, but there's a catch: In spite of the claim in >> our INSTALL that it's cross-platform, it actually depends on X11. >> >> I think that means that we need to have a separate GL interface >> per-backend. >> > Jasper's correct; I tried this out a while ago [1] and it currently does the right thing in modulesets-unstable [2], although the repository I specified there pointed to the libepoxy commit _before_ it was merged to master. This isn't yet in any release, I suppose we need to wait for libepoxy 1.3. [1] https://mail.gnome.org/archives/gtk-devel-list/2014-November/msg00012.html [2] https://git.gnome.org/browse/gtk-osx/tree/modulesets-unstable/gtk-osx.modules#n85 Best, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Thu, Jan 29, 2015 at 6:58 PM, Paul Davis wrote: > On Thu, Jan 29, 2015 at 7:34 PM, Jasper St. Pierre > wrote: > >> After talking to Owen today, I'm wondering if it makes sense to consider >> GtkPreview a portable widget. These platforms tend to already have their >> own document preview systems, and I'm not sure it makes sense to port all >> our apps (evince preview system, LibreOffice preview system) to use our own >> system instead of simply using the native preview widget. >> > > Its a fine point. But consider the perspective of a GTK developer who > comes across GtkPreview and wants to write a cross-platform application > using it. Embedding non-GTK widgets/views/thingdings inside GTK is still a > bit of black art ... An almost identical argument can be made for the file > browser and yet ... > Would it make sense instead to provide GtkPreviewer on all platforms, but implement it in terms of each platform's native previewer? That's what app developers would end up doing anyway if we considered it non-portable. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Tue, Jan 27, 2015 at 8:49 AM, Jasper St. Pierre wrote: > Gah. I always get those backwards. I actually typed "SCM_RIGHTS" and then > changed it to "SCM_CREDENTIALS". I still don't understand why fd passing is > called "rights". > > On Tue, Jan 27, 2015 at 11:25 AM, Simon McVittie < > simon.mcvit...@collabora.co.uk> wrote: > >> On 27/01/15 15:55, Jasper St. Pierre wrote: >> > Wayland requires two features that would perhaps make it unportable: FD >> > passing (SCM_CREDENTIALS), and shared memory (allocate a temporary >> > files, ftruncate it, mmap it, unlink it and then send the fd across the >> > wire). Everything else is just a simple Unix domain socket. Does OS X >> > support those two features? >> >> I think you mean SCM_RIGHTS? >> >> SCM_RIGHTS is "here's a message with an open fd attached". It's how >> D-Bus does fd-passing, so if D-Bus fd-passing works on your favourite >> platform, Wayland fd-passing should too. >> >> SCM_CREDENTIALS is "here's a message with my uid, gid and pid[1] >> attached, the kernel will check that I haven't lied to you" (also called >> SCM_CREDS on e.g. FreeBSD). Basically every Unix has either this or a >> syscall to query those things or both, but most Unixes also have their >> own unique spelling for the API, because standards are hard.[2] >> >> S >> >> [1] Strictly speaking "the uid, gid and pid I had at the time I opened >> this socket" >> [2] Except that FreeBSD, Dragonfly BSD and Hurd share SCM_CREDS, and >> several platforms (sadly not including Linux) share getpeereid(). For >> the gory details see libdbus source code. > > I put it to the test and tried to build Jasper's proof of concept (and therefore Wayland) on OSX. I didn't get very far. Wayland's configure.ac checks for SFD_CLOEXEC and TFD_CLOEXEC which implies that it uses signalfd() and timerfd(), not available on OSX. I guess the replacement would be something with kqueue though I really haven't the faintest idea what I'm talking about there. Wayland also wants clock_gettime() - not insurmountable to provide on OSX but afaik uses a different API, quick googling showed up this: http://stackoverflow.com/a/6725161/172999 PS. Funny thing that this is one of the top results for googling SFD_CLOEXEC, even without adding "osx" or "wayland": http://stackoverflow.com/questions/27864027/sfd-cloexec-wayland Best, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Deprecated widgets on Stack Overflow [was: a new combo box]
On Tue, Dec 30, 2014 at 2:29 AM, Cosimo Cecchi wrote: > On Tue, Dec 30, 2014 at 2:26 AM, Philip Chimento < > philip.chime...@gmail.com> wrote: > >> Assuming that questions on Stack Overflow are an approximate poll of what >> application authors do - many application authors go to the documentation >> and do exactly that. (And often don't bother to read any further - I've >> often enough seen questions about a deprecated widget such as GtkList which >> was selected purely based on its name.) >> > > We are getting a bit off the topic of the thread, but this is an > interesting observation. > > Can you link to some examples of this? I would be curious why that is the > case - i.e. which medium was used to consult the documentation, because on > the website deprecated classes are quite clearly marked in a separate > section at the bottom of the reference ( > https://developer.gnome.org/gtk3/unstable/). > Sure, I was curious about more substantiated data than just my own memory :-) I did searches on Stack Overflow for some widgets that were deprecated in GTK 2, see some results below. It looks like in at least one case a developer found an outdated GTK 1.x tutorial online and just ran with it. In most other cases the widgets seem to have been picked for their names, although it's hard to tell what the question askers were thinking exactly. In one case someone asked why there were two widgets for the same thing, having missed the deprecation warning completely. - http://stackoverflow.com/questions/16159052/what-is-the-best-widget-with-gtk-for-chat-window-irc - http://stackoverflow.com/questions/6801370/python-clist-widget-not-returning-expected-list-returns-only-the-first-characte - http://stackoverflow.com/questions/27495030/rgtk2-gtkcombo-get-current-selected-text - http://stackoverflow.com/questions/4404610/linux-and-gtk-gtkfileselection-vs-gtkfilechooserdialog - http://stackoverflow.com/questions/5012739/get-text-from-textbox-in-gtk - http://stackoverflow.com/questions/16586635/add-tooltip-to-gtkbutton - http://stackoverflow.com/questions/17390960/how-to-use-gtk-tree-error Here are some more questions where the asker is aware the widget is deprecated but wants to use it anyway or isn't sure what to use instead. Or perhaps isn't sure why 'deprecated' is a bad thing, in the last link: "I know GtkList is deprecated and should be replaced with GtkTreeView + GtkListStore. However, I do want to use GtkList in current situation since GtkListStore is more complex." - http://stackoverflow.com/questions/8162547/gtk-how-to-make-labels-as-buttons-sort-of-list - http://stackoverflow.com/questions/1210602/how-to-make-a-multiple-select-list-box-in-ruby-glade-gtk-maybe-using-treeview - http://stackoverflow.com/questions/18908756/use-what-instead-of-deprecated-gtk-clist - http://stackoverflow.com/questions/2835693/multiple-selection-with-gtkcombo - http://stackoverflow.com/questions/20122232/gtklistc-code-how-to-get-the-selection-of-a-gtklist I would hazard a guess that most people don't load up the docs' index page, but instead land on pages directly by googling - and so don't see the "Deprecated Widgets" section. For example if I google "gtk list widget" a GtkList tutorial page is the fourth result. [1] Although admittedly, that doesn't explain why someone wouldn't click on one of the perfectly fine top three results. [1] http://www.pygtk.org/pygtktutorial/sec-gtklistexample.html -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: a new combo box
On Sun, Dec 28, 2014 at 9:24 PM, Cosimo Cecchi wrote: > On Mon, Dec 29, 2014 at 1:09 AM, Jasper St. Pierre > wrote: > >> Cosimo talks about GtkPopover and GtkMenu, but those just sort of have me >> stunned. Why should I use one instead of the other? >> > > I doubt application authors choose which widget to use by reading type > names in API references; > Assuming that questions on Stack Overflow are an approximate poll of what application authors do - many application authors go to the documentation and do exactly that. (And often don't bother to read any further - I've often enough seen questions about a deprecated widget such as GtkList which was selected purely based on its name.) > if you're following a style guide like the HIG, the recommendation will > come from there. > Other times you will want a widget that looks/works like one you've seen > elsewhere, and the visual/behavioral difference will make it obvious why > there are two different classes. > This also happens, though - people will post a screenshot and say "What is this widget?" We could make the Widget Gallery page more discoverable in the documentation in order to encourage this. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: help wanted for implementing GdkGLContext on Windows and MacOS X
On Thu, Nov 20, 2014 at 3:31 AM, Emmanuele Bassi wrote: > hi; > > I'd like to point out that this is a build-time requirement for > libepoxy only: if the app does not use GLX on the Apple X server, then > the GLX code is never even loaded. > > it'd be nice to have a libepoxy build that does not require X11 on > MacOS, but that would make it harder to have applications linking > against libepoxy run on the X server on that platform. whether or not > that is a long term strategy is a discussion worth having with Eric. > The officially supported way to build the GTK stack on OSX uses jhbuild, and this is also how Gnome applications like Gedit build their app bundles [1]. So building a stripped-down libepoxy shouldn't affect any other applications who would want to use libepoxy's X11 capabilities outside of the jhbuild environment. I guess it's another story for those wanting to build GTK via Homebrew, Macports, or other similar systems, though. On 19 November 2014 08:10, Jasper St. Pierre wrote: > > Yeah, this is an unfortunate bug with libepoxy right now. There's a PR on > > GitHub if you want to see if that fixes it. > > > > https://github.com/anholt/libepoxy/pull/28 > It did, thanks! > > All we can do is pressure Eric Anholt to merge it at this point. > > > > On Wed, Nov 19, 2014 at 12:03 AM, Philip Chimento > > wrote: > >> > >> On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi > wrote: > >>> > >>> hi all; > >>> > >>> I posted this on my blog, which is syndacated on Planet GNOME, but I > >>> thought about trying to reach out to more people by using the GTK+ > >>> mailing list as well. > >>> > >>> GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and > >>> Wayland. > >>> > >>> if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're > >>> using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or > >>> 3.x, then I'm asking you to help out with patches and testing the > >>> OpenGL support in the master branch of GTK+. we'd really like to have > >>> OpenGL support working on all the major backends in GDK by the time we > >>> release GTK+ 3.16.0, next February. > >> > >> > >> I've started trying to build GTK master on OSX; looks like libepoxy is > now > >> a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that > >> dependency? It seems to me that I shouldn't need X11 for the Quartz > backend. > [1] http://blogs.gnome.org/jessevdk/2014/09/02/gedit-3-14-for-os-x-preview/ -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: help wanted for implementing GdkGLContext on Windows and MacOS X
On Sun, Nov 16, 2014 at 6:32 AM, Emmanuele Bassi wrote: > hi all; > > I posted this on my blog, which is syndacated on Planet GNOME, but I > thought about trying to reach out to more people by using the GTK+ > mailing list as well. > > GTK+ 3.16 will have OpenGL support out of the box — at least on X11 and > Wayland. > > if you are using GTK+ 3.x on Windows and/or MacOS X, or if you're > using external libraries like GtkGLExt and GtkGLArea with GTK+ 2.x or > 3.x, then I'm asking you to help out with patches and testing the > OpenGL support in the master branch of GTK+. we'd really like to have > OpenGL support working on all the major backends in GDK by the time we > release GTK+ 3.16.0, next February. > I've started trying to build GTK master on OSX; looks like libepoxy is now a dependency of GDK, and libepoxy in turn needs X11.h. How hard is that dependency? It seems to me that I shouldn't need X11 for the Quartz backend. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Intermediate children [was: Re: flow box]
On Mon, Sep 30, 2013 at 4:16 PM, Matthias Clasen wrote: > On Mon, Sep 30, 2013 at 1:53 PM, Tristan Van Berkom < > trista...@openismus.com> wrote: > >> o gtk_flow_box_insert() or gtk_container_add() add an intermediate >> > child, breaking the logical widget hierarchy. >> >> For most of the history of GTK+, one can rely on the logical >> hierarchy being preserved, i.e. adding a widget to a parent will >> always pass the 'gtk_widget_get_parent (child) == parent' check. >> >> Honestly I would be more comfortable with a policy where only a >> specific child type can be added to the flowbox. The GtkToolBar >> and GtkMenuShell apis are clearer by limiting what types of >> children can be added, without breaking the logical widget >> hierarchy. >> >> In any case, I think this is worth at least a mention in >> the gtk_container_add() documentation. >> > > This is following recent precedents - we are now automatically inserting > viewports between a scrolled window and its child, and GtkListBox is > automatically wrapping its children in GtkListBoxRow intermediaries. > > I agree that we should add some hints about this to the the > gtk_container_add docs. > This may be a bit tangential to the flow box, but especially in light of those recent precedents I think the requirement of 'gtk_widget_get_parent(child) == parent' should be relaxed... we had some discussion about this a while ago in bug 699756 [1] but I never got around to doing anything with it after that. I like Emmanuele's idea of a has_child() vfunc in that bug's discussion though. [1] https://bugzilla.gnome.org/show_bug.cgi?id=699756 Regards, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: win32-fixup.pl
On Sun, Feb 24, 2013 at 10:47 AM, John Emmas wrote:
> On 24/02/2013 08:34, John Emmas wrote:
>>
>>
>> Can anyone tell me what the correct syntax is for running the script? I
>> tried "perl win32-fixup.pl" (without any command-line options) and although
>> it did work, it only processed the first file in the list and then skipped
>> the others.
>>
>
> I realised what the problem was. Here's the list of files to be processed:-
>
>
> process_file ("config.h.win32");
> process_file ("glibconfig.h.win32");
> process_file ("glib/makefile.msc");
> process_file ("glib/glib.rc");
> process_file ("gmodule/makefile.msc");
> process_file ("gmodule/gmodule.rc");
> process_file ("gobject/makefile.msc");
> process_file ("gobject/gobject.rc");
> process_file ("gthread/makefile.msc");
> process_file ("gthread/gthread.rc");
> process_file ("tests/makefile.msc");
>
> The second one is wrong. It should be:-
>
> process_file ("glib/glibconfig.h.win32");
>
> After fixing that, it all works! win32-fixup.pl is a useful little script.
> Congratulations to whoever thought of it.
Looks like it does the necessary substitutions that are usually done
by "configure". I've never built GLib on win32, so the following is
just a wild guess -- but I'd guess this script is long out of date and
needs updating. For one thing, it sets the version number to 1.3.7,
from about 10 years ago -- neither current nor correct. That it is so
long out of date is an indication that you probably don't need to use
it, otherwise it would have been updated in the meantime.
In any case, look at the AC_SUBST and AC_CONFIG_FILES declarations in
"configure.ac" to make sure that the script performs the proper
substitutions with current values.
--
Philip
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
On Thu, Sep 13, 2012 at 11:01 PM, Paul Davis wrote: > > On Thu, Sep 13, 2012 at 4:43 PM, Juan Pablo Ugarte > wrote: >> >> On Thu, 2012-09-13 at 06:22 +, Tristan Van Berkom wrote: >> > From what I see... all one should *need* to do is specify the >> > accelerator keys >> > desired to trigger a given GtkAction and add that action to an action >> > group >> > (either with GtkBuilder constructs or with >> > gtk_action_group_add_action_with_accel()). >> > >> > The fact that a GtkAccelGroup must be added to a GtkWindow... and that >> > it must >> > be referred to by the GtkActionGroup (need to set the >> > property/relation somewhere)... >> > is all a bit sub-par as an API (i.e. it's confusing, not obvious to >> > figure out). >> > >> > So my basic question is... is there anything good about manually >> > setting up these >> > accel groups at all ? GIMP is an example of a multi-windowed application >> > (and >> > many apps can have a 'floating' editor for some purpose)... as it >> > stands whenever >> > you create an extra floating window that is not a temporal dialog, you >> > must set >> > the GtkAccelGroup manually also for those windows for accelerators to >> > work >> > while those windows have focus. >> > >> > GTK+ of course manages an internal list of the app's GtkWindows... I >> > really dont >> > see the reason why GtkAccelGroup couldnt just be completely automated... >> > could we possibly just deprecate/eventually remove that from the >> > (public) api ? >> >> I do not know about deprecating it, but we could definitely have a >> default accelerator group that gets set in every window and action group >> by default. This way actions will simply work and if for some reason you >> need a window with a different accel group you can always set it later. >> I like to keep common cases simple and special cases well special. :) > > > fundamentally, what differs from window are the available actions. the fact > the accels per window *might* be different is just a side-effect of this. > therefore, action groups are the primary entity that needs to be attached to > a window, not accel groups. > > since currently neither action nor accel groups permit sharing of actions or > accels, both concepts are pretty useless in GTK right now. most applications > end up with a single action group (semantically, anyway) and a single accel > group. and if they don't they probably meant to :) For accel groups I agree with you, but action groups are not useless. For example you can have an action group that gets enabled/disabled depending on whether something is on the clipboard (containing all sorts of paste actions) or one that is only enabled when items are selected (containing copy, cut, reformatting actions, etc.) I'm not sure what you mean by semantically a single action group, but I don't think that's it. -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ meetup at Guadec
On Sat, Jul 28, 2012 at 3:30 PM, Matthias Clasen wrote: > - We need to document how one extends GTK+ itself (eg how to create a > new widget class), to make it easier for new people to get involved > (I'll try to get this started) I wrote a tutorial on extending GtkContainer in C (http://ptomato.name/advanced-gtk-techniques/html/custom-container.html). It's even current for 3.0. I wrote it for the advanced developer rather than the new one, but perhaps you can recycle some of it. Best, -- Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Incorporating changes from bindings [was: Add GtkRadioGroup?]
On Wed, Nov 10, 2010 at 17:49, Tristan Van Berkom wrote: > On Wed, 2010-11-10 at 17:16 +0100, Philip Chimento wrote: >> On Sun, Oct 31, 2010 at 11:28, Alexander Larsson wrote: >> > By the way, are there any other places where the java or C++ bindings do >> > "cleanup" changes like this? Some may be interesting to push into the >> > core now that we have the chance. >> >> I'd propose adding gtk_builder_get_widget_derived(), based on a method >> in gtkmm [1]. This would make it much easier to use Glade when >> subclassing widgets. >> >> [1] >> http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en > > I've been cooking up something that might be close to what that API > describes (for some months actually a while back, I just need to dust > off the code and possibly automate the creation of properties which > refer to child widgets etc) > > The general idea is that GtkContainerClass itself allows one to define > content using an assigned GtkBuilder xml at the class level, > implementing classes are composite widgets and a project can be > comprised of several or many composite widgets all defined by > GtkBuilder xml, reusable, practical etc (i.e. the way IMO > GtkBuilder should really be used ideally). > > I brought it up most recently here: > http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00054.html > > And I would really like to land this stuff before 3.0 as well. > > Does that just about cover the use case ? or have I missed the point > somehow ? I think that covers it, although yours takes the concept much farther than just porting that gtkmm function. I'm thinking of the common use case of writing a MyAppMainWindow class that derives from GtkWindow. The way it is now, in my_app_main_window_init() you open the ui file, get the outermost non-toplevel widget from the builder (i.e. whatever widget is contained by the window), gtk_container_add() that widget to the window you're constructing, and then manually set all the properties of the window that you would otherwise have set in Glade. I'm not so fond of the gtkmm derived class having to have a certain constructor either, but maybe this could be circumvented if the derived class was required to implement GtkBuildable? -- Philip Chimento ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Incorporating changes from bindings [was: Add GtkRadioGroup?]
On Sun, Oct 31, 2010 at 11:28, Alexander Larsson wrote: > By the way, are there any other places where the java or C++ bindings do > "cleanup" changes like this? Some may be interesting to push into the > core now that we have the chance. I'd propose adding gtk_builder_get_widget_derived(), based on a method in gtkmm [1]. This would make it much easier to use Glade when subclassing widgets. [1] http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-builder-using-derived-widgets.html.en -- Philip Chimento ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Generic undo stack for GTK+
On Mon, Jun 21, 2010 at 7:40 AM, Holger Berndt wrote: > On Mon, 21 Jun 2010 12:57:44 +0200 ecyrbe wrote: >> [...] >> Anyway, i don't see the value of adding it to GLib, as undo >> frameworks are only an abstraction, and users end-up doing the >> painfull job of implementing undo commands for every type of objects >> or actions they are putting in the stack or the tree. > > Aeh -- it's a container type. Of course no generic container type > gets any application specialized functionality for free. Nobody claimed > that. > > What it does get you is other things, for example > > [...] > - You don't have to write the boring boiler-plate code yourself, which > is likely to motivate application developers to actually offer undo > in their applications. I usually just lurk on this list, but the thought of not getting an undo framework in GLib or GTK because of purity concerns is so unbearable that I simply had to post. Yes, having an undo framework would definitely motivate me to provide proper undo in my application. Right now the undo that I offer is just what GtkSourceView provides, so it only applies to typing text even though there are other actions in the application that should be able to be undone. What's more, I have been actively postponing writing a solution for this because of the noises that I occasionally hear about adding an undo framework. I don't want to implement it myself only to find out later that GTK applications using the standard undo framework will behave subtly differently. Regards, -- Philip Chimento ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkTextBuffer serialization/deserialization into Rich Text Format
Hi developers, I've written a library that includes GtkTextBuffer serialization/deserialization functions for Rich Text Format. I have just released the first public version. I'd be willing to work with somebody on converting the RTF functionality into a patch for GTK if you're interested. You can get the source code here: https://sourceforge.net/projects/osxcart/ Regards, Philip Chimento ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
