Re: Discourse instance
On Fri, 2019-03-01 at 19:34 +, Neil McGovern wrote: > On Fri, 2019-03-01 at 20:37 +0300, LRN via gtk-devel-list wrote: > > 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. > > Ah, yes. You can do that! > > https://discourse.gnome.org/tags/ > Click on a tag, and you can update your watching status. The number > of > tags are limited at the moment, so if you have any ideas for other > tags > you want to add, let me know and I'll add them. Well, I suspect LRN would probably appreciate a ‘windows’ tag. Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Translating enum values in schema
On Sat, 2018-09-15 at 16:25 +0200, rastersoft wrote: > Hi all: > I'm doing an schema for gsettings. This is part of it: > > > > > > > > id="org.gnome.shell.extensions.desktop-icons" gettext- > domain="desktop-icons"> > > "large" > Icon size > Set the size for the desktop > icons. > > After passing xgettext, it adds to the .po file all the "summary" > and "description" contents, but it doesn't add the nicks in the > enum (this is, the strings "small", "standard", "large" and > "huge" > aren't added to the .pot file). But I want to show in my > program > the values translated. > Of course, I now that in the settings itself I must use the > original strings, not the translated ones, but I don't want > gsettings_schema_key to return those values already translated; > I > only want to ensure that xgettext adds those strings to the > .pot > file. > > > > I tried adding l10n="messages" to each value, but the compiler > doesn't like it. I tried using "alias" inside the key part, but > they aren't added, and adding l10n to the aliases is also not > allowed. > > > So the question is: how can I do that? > tl;dr: You can’t do that from a GSettings schema file. GLib doesn’t support translations of enum/flag value names or nicknames, because they can end up being used as identifiers for the enum/flag values (for example, when calling g_enum_get_value_by_nick()). Probably the right way to do it is to keep an array of the translatable enum names in your code, and have xgettext extract the strings from that. Presumably you’ll need the enum names in your code somewhere anyway to put them in the UI. If you really want to make everything dynamic, you could write some custom ITS rules for extracting the enum nicks from the GSettings XML file, and use them with xgettext’s `--its` argument. Philip signature.asc Description: This is a digitally signed message part ___ 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
On Thu, 2018-09-06 at 15:30 +0100, John Emmas wrote: > On 06/09/2018 14:11, Bastien Nocera wrote: > > > > It's gitlab.gnome.org, not git.gnome.org anymore. > > > > Thanks Bastien - but that doesn't seem to help... :-( > > I see exactly the same error except that whereas it previously said > "fatal: unable to connect to git.gnome.org" it now tells me:- > "fatal: > unable to connect to gitlab.gnome.org" > > Is the remote at 'git://gitlab.gnome.org' or somewhere else (https:// > > maybe) ? You can find the new git URI for each project by going to the project’s page on GitLab: https://gitlab.gnome.org/GNOME/pango The clone URI is in the middle at the top, just below the project logo and name. You get the choice of HTTPS or (if you’re logged in) SSH. Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib gitlab tag
On Mon, 2018-09-03 at 10:09 +0100, Patrick Welche wrote: > I just pointed my local glib repository from git.gnome.org to > gitlab.gnome.org. I did the usual pull --rebase. I see > > Author: Philip Withnall > Date: Thu Aug 30 14:40:04 2018 +0100 > > 2.58.0 > > Signed-off-by: Philip Withnall > > > but I don't see the 2.58.0 tag! > > ... > 2.55.0 > 2.55.1 > 2.56.0 > 2.56.1 > 2.56.2 > 2.57.1 > 2.57.2 > 2.57.3 > EAZEL-NAUTILUS-MS-AUG07 > FOR_GNOME_0_99_1 > GLIB_1_1_0 > GLIB_1_1_1 > GLIB_1_1_10 > GLIB_1_1_11 > ... > > It is listed at https://gitlab.gnome.org/GNOME/glib/tags > > What am I missing? I pushed the wrong tag, sorry. Trying to fix it now, but it will need sysadmin involvement because the git server (rightfully) doesn’t allow tags to be deleted or changed. The release commit you should build is c138b98e363df8b95c2ee3eac214649b2908ad68; or just build from the glib- 2-58 branch. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib BoF session at GUADEC
There will be a GLib BoF session all day on the 9th of July in room 2 of GUADEC, subverting part of the GTK+ BoF: https://wiki.gnome.org/GUADEC/2018/Hacking%20days/GtkBOF Come along if you’re interested in GLib, GIO, GObject. We’ll be assessing the status of the 2.58 release, and starting to plan for 2.60. Ta, Philip signature.asc Description: This is a digitally signed message part ___ 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 Fri, 2018-06-08 at 14:59 -0400, xclae...@gmail.com wrote: > Le vendredi 08 juin 2018 à 18:59 +0100, Philip Withnall a écrit : > > How about: > > 1) Starting from 2.57.2, create release tarballs with `ninja dist`, > > but > > recommend that distributions still build with autotools (unless > > they > > want to dogfood with Meson early). > > 2) From 2.57.3, switch to recommending that distributions build > > with > > Meson. > > Yeah, why not, let's start it slow. What I like with that step is we > can easily roll new tarballs with "make distcheck" if packagers have > any issues. Yup. > Btw, when is 2.58.0 due? And how many dev release do we plan in > between? Due after GUADEC; as many dev releases as we want. https://wiki.gnome.org/Schedule Philip signature.asc Description: This is a digitally signed message part ___ 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
Hey, On Fri, 2018-06-01 at 11:10 -0400, xclae...@gmail.com wrote: > Things are looking pretty well with meson in GLib master. We have CI > working for pretty much all interesting platforms (more to come) and > there are only a few remaining issues with "Meson" tag in gitlab[1]. > > I think the longer we keep 2 build systems, the more time we waste on > useless tasks. So I would like to discuss a roadmap that would lead > to > dropping autotools. Yes, it would be good to clarify the roadmap. A roadmap was planned at the GTK+ hackfest at FOSDEM earlier this year, and I blogged about it, but it looks like my blog had dropped off planet.gnome.org at the time, so I doubt anyone saw the post. ☹ https://tecnocode.co.uk/2018/02/06/gtk-hackfest-and-fosdem-outcomes/ tl;dr: The plan from FOSDEM was to support autotools and Meson in parallel for 2.58 (with feature parity between the two), then keep both systems in parallel for a ‘release or two’, before dropping autotools as soon as we can be satisfied there are no regressions for our features or supported platforms. As a reminder, here’s the set of supported platforms for GLib: https://wiki.gnome.org/Projects/GLib/SupportedPlatforms > My proposal would be: > 1) Starting from 2.57.2 (next dev release), create release tarballs > using "ninja dist" and recommend disto to build with Meson 0.46.1. > This > would mean that './configure' in a release tarball won't work, people > still wanting to use autotools will have to update their scripts to > use > "./autogen.sh" instead and adjust their build deps. IMHO, forcing a > small change is a good incentive to have most of our users switch to > meson. This would give us good feedback while still keeping the door > open to rollback if any blocker bug appears. > 2) Starting from 2.59.1 (next dev cycle), drop autotools completely > from our git repository. How about: 1) Starting from 2.57.2, create release tarballs with `ninja dist`, but recommend that distributions still build with autotools (unless they want to dogfood with Meson early). 2) From 2.57.3, switch to recommending that distributions build with Meson. 3) Starting from 2.59.0 (the actual start of next dev cycle), drop autotools completely; assuming that steps 1 and 2 have gone OK. I want to make sure that distributions only start building GLib using Meson for their unstable/development releases, rather than for stable releases. There have only recently been bugs about code which was compiled with autotools not being built with Meson (the FAM file monitor comes to mind), which doesn’t give me enough confidence to jump to recommending building with Meson right yet. Note that on some platforms, we may drop support for autotools early. Notably the maintainers of the GLib builds on Windows have already fully switched to Meson, and there is a merge request open about making configure error out on Windows. I could imagine the same happening for other platforms where we’re in direct contact with the small set of packagers for those platforms (for example, MacPorts and the *BSDs). BTW, why are you recommending 0.46.1? The dependency in our top-level meson.build is currently 0.46.0. Philip signature.asc Description: This is a digitally signed message part ___ 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 Wed, 2018-05-30 at 00:59 +0800, 藍挺瑋 wrote: > 於 星期一，2018-05-28 於 12:09 -0400，xclae...@gmail.com 提到： > > Hi, > > > > We now have 6 arch tested for glib, all with Meson. > > > > - macosx-10.13-meson-x86_64 > > * Native macosx 10.13 build > > * Fails to build with --werror, if anyone wants to take a look. > > * Some unit tests fails and are ignored, if anyone wants to take > > a > > look. > > * Machine currently hosted at Collabora Montreal office, will > > setup > > another runner on another machine we have in a proper data center. > > It looks like this one was temporarily removed. > > > Missing, if someone wants to contribute: > > - Some autotools runners? IMHO (I'm not maintainer) we should > > recommend meson for 2.58 and drop autotools for 2.60. > > - Some 32 bits archs? > > - More macosx/android/windows/distros versions? > > - *BSD > > After spending a few days on fixing GLib tests, I finally get all > tests pass on > FreeBSD: https://gitlab.gnome.org/lantw/glib/-/jobs/38840 > > The test ran in a jail with FreeBSD 11.1-RELEASE-p10 userland on > FreeBSD 11.2- > BETA3 amd64 kernel. > > In fact, 'collate' test fails but it is marked as 'SKIP' because of > lacking > en_US locale, 'testfilemonitor' is modified to allow some missing > events because > kqueue isn't as good as inotify on file monitoring. Even if not all > tests work > perfectly, running these tests already let me find a few bugs and fix > problems > in GKqueueFileMonitor. The code and commits in my GLib fork are just > for quick > testing and I will make them look better before submitting a merge > request. > > However, the runner I use in my GLib fork runs in a VM whose host is > very > unreliable and not suitable for use as an official CI runner. This > host crashes > often and its uptime is usually less than 2 weeks. It also gives me > random > segfault and corrupted files sometimes. I can document steps required > to run > GitLab CI runner on FreeBSD, so people who are able to provide > machines can > setup a runner quickly. It is easy and can be done in about 5 > commands. What are those 5 commands? I think it should be possible to use a separate Docker image for the FreeBSD CI, but run it on the same Docker hosts as the Fedora image which we use for the Linux CI and crossbuilds. See https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#defin e-image-and-services-from-gitlab-ci-yml. Philip signature.asc Description: This is a digitally signed message part ___ 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 Wed, 2018-05-23 at 10:03 -0700, Alan Coopersmith wrote: > On 05/23/18 09:40 AM, Philip Withnall wrote: > > On Wed, 2018-05-23 at 16:19 +0200, Christoph Reiter wrote: > > > On Mon, May 21, 2018 at 5:54 PM, Alan Coopersmith > > > wrote: > > > > On 05/18/18 02:52 AM, Philip Withnall wrote: > > > > > Can anybody else provide and maintain CI runners for other > > > > > platforms? > > > > > > > > Are there instructions somewhere on what's needed to do this? > > > > > > 1) Install the gitlab runner on a server: > > > https://docs.gitlab.com/runner/#install-gitlab-runner > > > > I’m not sure of the latest status of this, but it looks like gitab- > > runner might need some porting work to Solaris to be done before it > > can > > be used. There’s some information about it here: > > > > https://gitlab.com/gitlab-org/gitlab-runner/issues/1764 > > > > > 2) Fork glib on gitlab and register your runner in the forked > > > repo > > > settings > > > 3) Adjust the .gitlab-ci.yml file to add a job using your runner. > > > See > > > Xavier's recent patch for > > > macos for what's roughly needed there: > > > https://bugzilla.gnome.org/show_bug.cgi?id=796343 > > > > Additionally, once all that is working, file an ‘infrastructure’ > > issue > > (like https://gitlab.gnome.org/Infrastructure/GitLab/issues/141) to > > get > > a CI token for the runner to be used by GitLab. > > Thanks - I'm not going to have time until after we get Solaris 11.4 > shipped, but hopefully later this year I'll have some time to see if > we can get a Solaris runner set up in the Oracle cloud. Sure. Whenever you get time, it would be appreciated (and I hope it would reduce your porting workload, in the long run). Let me know when you pick this up, or if you have any questions then. Thanks, Philip signature.asc Description: This is a digitally signed message part ___ 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 Wed, 2018-05-23 at 16:19 +0200, Christoph Reiter wrote: > On Mon, May 21, 2018 at 5:54 PM, Alan Coopersmith > wrote: > > On 05/18/18 02:52 AM, Philip Withnall wrote: > > > Can anybody else provide and maintain CI runners for other > > > platforms? > > > > Are there instructions somewhere on what's needed to do this? > > 1) Install the gitlab runner on a server: > https://docs.gitlab.com/runner/#install-gitlab-runner I’m not sure of the latest status of this, but it looks like gitab- runner might need some porting work to Solaris to be done before it can be used. There’s some information about it here: https://gitlab.com/gitlab-org/gitlab-runner/issues/1764 > 2) Fork glib on gitlab and register your runner in the forked repo > settings > 3) Adjust the .gitlab-ci.yml file to add a job using your runner. See > Xavier's recent patch for > macos for what's roughly needed there: > https://bugzilla.gnome.org/show_bug.cgi?id=796343 Additionally, once all that is working, file an ‘infrastructure’ issue (like https://gitlab.gnome.org/Infrastructure/GitLab/issues/141) to get a CI token for the runner to be used by GitLab. Thanks, and please keep me in the loop! Philip signature.asc Description: This is a digitally signed message part ___ 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 Sat, 2018-05-19 at 20:41 +1000, Jonathan Matthew wrote: > On Fri, May 18, 2018 at 10:52:18AM +0100, 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 do OpenBSD and SmartOS, assuming I can get the gitlab CI runner > to > work on either of them. That would be great, thanks. Here are the instructions Christoph provided elsewhere in the thread about how to set things up, in case you haven’t tried this before: 1) Install the gitlab runner on a server: https://docs.gitlab.com/runner/#install-gitlab-runner 2) Fork glib on gitlab and register your runner in the forked repo settings 3) Adjust the .gitlab-ci.yml file to add a job using your runner. See Xavier's recent patch for macos for what's roughly needed there: https://bugzilla.gnome.org/show_bug.cgi?id=796343 Once all that is working, file an ‘infrastructure’ issue (like https:// gitlab.gnome.org/Infrastructure/GitLab/issues/141) to get a CI token for the runner to be used by GitLab. Thanks, Philip signature.asc Description: This is a digitally signed message part ___ 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, 2018-05-18 at 09:21 -0400, philip.chime...@gmail.com wrote: > On Fri, May 18, 2018 at 5:52 AM Philip Withnall uk> 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) Xavier has now provided a configuration here: https://bugzilla.gnome.org/show_bug.cgi?id=796343 It looks like work is needed to get all the unit tests passing. I know there are some unreviewed patches in Bugzilla for fixing various things on OS X (they’re on my radar). Help with those, and with fixing other failures from bug #796343, would be appreciated! --- Copying the instructions Christoph provided for configuring a runner from elsewhere in the thread, for anyone who’s interested: 1) Install the gitlab runner on a server: https://docs.gitlab.com/runner/#install-gitlab-runner 2) Fork glib on gitlab and register your runner in the forked repo settings 3) Adjust the .gitlab-ci.yml file to add a job using your runner. See Xavier's recent patch for macos for what's roughly needed there: https://bugzilla.gnome.org/show_bug.cgi?id=796343 Philip signature.asc Description: This is a digitally signed message part ___ 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 Sun, 2018-05-20 at 00:34 -0400, xclae...@gmail.com wrote: > Ok, spent way too much time on this, but finally got it working to > cross build glib on our fedora docker image. > > https://bugzilla.gnome.org/show_bug.cgi?id=796264 Fantastic, thanks. I will review this (and your other CI submissions) as soon as I can. > Similar setup could be done to cross build for windows using mingw. > Tests could maybe run with exe_wrapper=wine, that would be fun :P That would indeed be cool to try, if anyone is interested in bootstrapping and supporting that as a supported platform. I honestly don’t know whether that would be a little, or a lot, of work. Philip > Le vendredi 18 mai 2018 à 19:16 +0530, Arun Raghavan a écrit : > > On 18 May 2018 at 18:51, wrote: > > > On Fri, May 18, 2018 at 5:52 AM Philip Withnall > > .c > > > o.uk> > > > 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) > > > > If anyone can point me to how to set up an Android runner I could > > try > > to pitch in there. > > > > Cheers, > > Arun > > ___ > > desktop-devel-list mailing list > > desktop-devel-l...@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > > ___ > desktop-devel-list mailing list > desktop-devel-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GitLab CI runners for non-Linux systems
Hi all, tl;dr: Want to provide us with a GitLab CI runner for a non-Linux platform? There’s been a surge of interest recently, from various directions, in getting GLib better tested on non-Linux architectures. This is great, and we’ve got various people to thank for doing the thankless work of porting and testing. Particularly: • macOS: Ryan Schmidt, Patrick Griffis, Michael Lauer, John Ralls • Windows/MinGW/MSYS2: LRN, Christoph Reiter, Xavier Claessens, Chun- wei Fan • Android: Xavier Claessens • *BSD: Ting-Wei Lan There’s a real risk of this all bitrotting, though, since the main GLib developers only have regular access to Linux machines (and don’t have the bandwidth or expertise to regularly test on other architectures). The solution here is CI. Christoph Reiter has already got a Windows MSYS2 CI runner set up on GitLab[1], which is producing helpful results for GLib. 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) After the initial setup and porting work, I hope these wouldn’t require much effort to maintain. The fast turnaround on testing GLib on non- Linux platforms would help us ensure cross-platform compatibility during development. Thanks, Philip [1]: https://gitlab.gnome.org/creiter/gitlab-ci-win32-runner [2]: https://wiki.gnome.org/Projects/GLib/SupportedPlatforms signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with gio_drive and gio_volume
On Sun, 2018-05-06 at 12:22 +0200, rastersoft wrote: > Hi all: > > I've been using GIO's Drive and Volume to detect the available > external > disks in an app (cronopete) and it worked fine for me; but some > people > referred troubles: some of them says their USB disks aren't > detected. > Also, I found that you can't retrieve information about the SATA > hard > disks, no matter if they are connected through eSATA. > > Is there a way of detecting ALL hard disks in the system and ALL > their > volumes inside with Drive.get_volumes(), no matter if they are > external, > internal, removable or fixed? Or I must rely on udisks2 for that? File a bug: https://bugzilla.gnome.org/enter_bug.cgi?product=glib and include a pointer to the specific GDrive/GVolume calls you’re making, and as much information as you can from the people whose drives aren’t showing up, including the output of `gio mount -li`. Thanks, Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: F_SETPIPE_SZ error
It’s already been reported as https://bugzilla.gnome.org/show_bug.cgi?i d=795133, and has been fixed as the following commits in master and glib-2-56: • master: https://gitlab.gnome.org/GNOME/glib/commit/0beb62f 56 • glib-2-56: https://gitlab.gnome.org/GNOME/glib/commit/1d2e685d9 Either apply the glib-2-56 patch from above, or wait until the next 2.56.x release. Philip On Mon, 2018-04-23 at 16:40 +, Harris, TerryX wrote: > Including #define _GNU_SOURCE does not solve the following glib- > 2.56.0 compile problem. > Has anyone else seen this error? > > > gmake[4]: Entering directory > `/nfs/pdx/disks/comp.ct.9/build/ib/em64t_SLES11/ibbuilds/glib- > 2.56.0tt/tmp/glib-2.56.0/gio' > CC libgio_2_0_la-gfile.lo > In file included from ../gobject/gbinding.h:29:0, > from ../glib/glib-object.h:23, > from ../gio/gioenums.h:28, > from ../gio/giotypes.h:28, > from gfile.h:28, > from gfile.c:43: > ../gobject/gobject.h: In function 'g_set_object': > ../gobject/gobject.h:725:5: warning: value computed is not used [- > Wunused-value] > gfile.c: In function 'splice_stream_with_progress': > gfile.c:3017:35: error: 'F_SETPIPE_SZ' undeclared (first use in this > function) > gfile.c:3017:35: note: each undeclared identifier is reported only > once for each function it appears in > gfile.c:3021:39: error: 'F_GETPIPE_SZ' undeclared (first use in this > function) > gmake[4]: *** [libgio_2_0_la-gfile.lo] Error 1 > > > Terry L. Harris | > eXcell, > a division of CompuCom > Software Technician > direct 480.554.9839 > mobil 480.215.9680 > terryx.har...@intel.com > > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fdwalk
On Fri, 2018-01-12 at 13:15 +, Markus Teich via gtk-devel-list 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. GLib provides higher-level subprocess handling functionality with GSubprocess; the g_subprocess_launcher_take_fd() and g_subprocess_launcher_set_child_setup() functions are relevant here. I’m not sure there’s enough demand to expose an fdwalk() implementation to everyone. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A macro to add
On Thu, 2018-02-08 at 23:06 -0600, Pavlo Solntsev wrote: > Hi, > > I found that I need to convert a bool variable to its string > representation, e.g. "FALSE" or "TRUE". I "invented" a macro: > > #define G_BOOL_TO_STRING(x) (x ? "TRUE" : "FALSE") > > I put this macro to ./glib/gmacros.h file and added a brief > description ./glib/docs.c > > Everything looks good but gtk-doc ignores it. Do I need to explicitly > mention this macro in some file? If so, what file? BTW, do we need > this macro in glib? You’d need to add it to docs/reference/glib/glib-sections.txt so that gtk-doc knows where to include it in the index. However, this isn’t something I’d be interested in including in GLib: it’s just as easy to open-code this in your application, and prescribing the string formats for people to use would mean half of all applications would find the format inappropriate. If you find the macro useful, keep it in a header in your own application. Do not prefix it with ‘G_’ as that’s the GLib namespace; use your own namespace. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gdbus-codegen] handle property set on the service-side
On Tue, 2018-02-06 at 13:35 +, Simon McVittie wrote: > On Mon, 05 Feb 2018 at 15:22:00 +0100, Gabriel LUCAS wrote: > > I think I might have reached some limitation with this method while > > trying > > to handle a property set from the service side. The generated code > > provides > > a vtable for the interface with the property_get and property_set > > handlers > > set. When a property set is received, the GObject property is > > automatically > > changed without having to be handled by the developer. > > > > My opinion is that the service should be able to refuse a property > > set in > > some cases. > > One option is to set properties via method calls: this makes it > easier to > document which errors they can raise, makes it possible to have > several > properties change atomically as a batch, and makes it (I suspect) > more likely that all D-Bus clients will be able to make those changes > asynchronously and cope with failure (or cope with the property being > set to a differing value, e.g. undergoing some sort of > normalization). > > > For example, a property GNSSEnabled can be set true to activate > > the GNSS output only if the modem is powered on. Then, I'll need to > > return > > an error and prevent the property set if the modem is off. > > For example, you could have a read-only GNSSEnabled property paired > with > an EnableGNSS() method; or maybe a read-only GNSSEnabled property > paired with an EnableFeatures() method that takes an array of strings > or integers representing features as its argument. > > The underlying GDBusInterfaceVTable makes it possible to handle > setting > properties asynchronously (and the documentation doesn't explicitly > say > so, but this is also failable) but I don't think gdbus-codegen > currently > has a way to generate code that makes use of that feature. Indeed, afaik you have to forego gdbus-codegen entirely and manually write your vtables in order to do failable property setters. A common cause for this is the need to do a polkit check before allowing a property to be set. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: fdwalk
Hey, The general answer to this kind of question is ’because nobody has needed it’. If you can demonstrate a need for a public fdwalk() implementation, which would be used by multiple apps, for a purpose which can’t just be served by GSubprocess or g_spawn_*(), then please file a bug about it on https://bugzilla.gnome.org/enter_bug.cgi?product =glib. Philip On Mon, 2018-01-29 at 14:40 +, Markus Teich via gtk-devel-list wrote: > 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 oogle.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 > > > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GnomeDesktopThumbnail API replacement
On Wed, 2018-01-17 at 18:15 +0100, Bastien Nocera wrote:
> On Wed, 2018-01-17 at 13:15 +0100, Bastien Nocera wrote:
> > Hey,
> >
> > I wanted to start a discussion about replacing
> > GnomeDesktopThumbnail
> > with an API that would live in the GLib/GTK+ stack.
>
>
From the GLib side of things, my thoughts are that this shouldn’t live
in GLib, since it deals with pixbufs. As long as it integrates with
GIO’s thumbnail attribute support, GLib will be happy.
What about https://wiki.gnome.org/DraftSpecs/ThumbnailerSpec? I don’t
know if the API is entirely relevant (or whether explicitly exposing
the cache over D-Bus makes sense), but there may be some useful ideas
there even if the API as a whole is not a good fit.
What did you have to say about making things free-Unix-specific (or
more Linux specific)?
> > To sum up, here are the questions:
> > - Do we want the API in GTK+ and depending on gdk-pixbuf, even if
> > it's
> > only really meant to be used on "freedesktop" platforms?
> > - Are there specific API entry points that people need besides the
> > current API (including [1]) with async support?
>
> This is the API that I came up with, which could live in either gdk-
> pixbuf, or GTK+, dependency-wise. It might also be small enough to
> copy/paste although I count 15 users of just the C API in Debian
> Codesearch[1], so it might be worth having in a shared library
> anyway.
>
> typedef enum {
> GNOME_DESKTOP_THUMBNAIL_FLAGS_NONE = 0,
> GNOME_DESKTOP_THUMBNAIL_FLAGS_SAVE, // Whether to save the
> created (successful or failed) thumbnail to the cache
> } GnomeDesktopThumbnailFlag;
>
> #define GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES \
> G_FILE_ATTRIBUTE_THUMBNAIL_PATH "," \
> G_FILE_ATTRIBUTE_THUMBNAILING_FAILED ","\
> G_FILE_ATTRIBUTE_THUMBNAIL_IS_VALID "," \
> G_FILE_ATTRIBUTE_PREVIEW_ICON "," \
> G_FILE_ATTRIBUTE_TIME_MODIFIED "," \
> G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE
>
> // About @info:
> // NULL means we'll look it up if necessary, otherwise must include
> // GNOME_DESKTOP_THUMBNAIL_FILE_ATTRIBUTES,
> // G_FILE_ATTRIBUTE_STANDARD_CONTENT_TYPE will however be used rather
> // than G_FILE_ATTRIBUTE_STANDARD_FAST_CONTENT_TYPE if present
>
> GdkPixbuf *
> gnome_desktop_thumbnail_generate_thumbnail_sync
> (GnomeDesktopThumbnailFactory *factory,
> GFile
> *file, // instead of a URI?
> GFileInfo
> *info,
> GnomeDesktopThumbnai
> lFlags flag,
> char
> **ret_thumbnail_path,
> GError
> **error);
Seems reasonable, though I assume people will typically use the
*_async() version? The *_sync() version should still have a
GCancellable argument. I agree with using a GFile rather than a raw
URI. If this is done as a shared library then you can implement it
using bwrap or D-Bus as you see fit, and change the implementation
later on without problems.
Philip
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Python error when building gdbus-codegen stuff (in glib / gio)
On Wed, 2018-01-17 at 16:07 +, John Emmas wrote: > On 17/01/2018 11:04, John Emmas wrote: > > > > I'll look a bit further into this and see if I can figure out > > what's > > gone wrong. > > > > This turned out to be a problem with TortoiseGit. Some of glib's > python > files contain lines looking like this:- > >from .whatever import something > > For some reason, I always need to edit them to remove the period - > i.e. > >from whatever import something > > So typically, I can have 4 or 5 such conflicts in any given python > script. TortoiseGit has an option which effectively means "resolve > all > conflicted lines using my version". But I've just realised that it > doesn't confine itself to overwriting the conflicted lines - it > actually > substitutes my whole file (and therefore loses any non-conflicted > changes!!) Good to hear you’ve resolved that problem. > Now I'm past that point I've encountered a new problem (when > compiling > the recently added 'gnetworkmonitorwindows.c'). On my system (MSVC) > it > seems to be #including the wrong version of "iphlpapi.h" and is > consequently failing to pick up one of the symbols > (IP_ADDRESS_PREFIX) > which is needed by function 'win_network_monitor_get_ip_info()'. When you get a chance to investigate it, can you add your findings to https://bugzilla.gnome.org/show_bug.cgi?id=685442 please? That’s where we’re working on the Windows network monitor. Thanks, Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Python error when building gdbus-codegen stuff (in glib / gio)
On Wed, 2018-01-17 at 10:26 +, John Emmas wrote: > On 17/01/2018 09:51, Philip Withnall wrote: > > Exactly what commit are you building? > > > > > [...] > > > > > > > That’s not what the code currently looks like: > > > > Thanks for the quick response Philip. The latest commit here is > #5fba62ade by Benjamin Berg on 15 Jan 2018 (gmessages: Flush output > stream after logging messages). > > My last 'pull' did flag up some conflicts though - so maybe I didn't > fix > one of them correctly? (or did that change come after the above > commit?) Perhaps. What’s the output of `git status`? Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Python error when building gdbus-codegen stuff (in glib / gio)
On Wed, 2018-01-17 at 09:44 +, John Emmas wrote: > I'm not yet building with meson so forgive me if this is just down to > my > build system being out-of-date !! > > The problem happens when I try to build glib/gio from yesterday's > git > master. Exactly what commit are you building? > But in the file 'gdbus-2.0/codegen/codegen_main.py' it seems to be > getting called like this, at line 186:- > >docbook_gen = > codegen_docbook.DocbookCodeGenerator(all_ifaces, docbook, outdir); That’s not what the code currently looks like: https://git.gnome.org/browse/glib/tree/gio/gdbus-2.0/codegen/codegen_ma in.py#n226 Is your git checkout completely up to date? Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_object_ref() now propagates types
On Sat, 2017-12-09 at 10:54 +0100, Sébastien Wilmet wrote: > On Fri, Dec 08, 2017 at 11:26:31AM +0000, Philip Withnall wrote: > > Note that the new behaviour requires GCC, and is only enabled if > > you > > have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56. > > If GLIB_VERSION_MAX_ALLOWED is not defined, does it take by default > the > value of the last GLib version? That’s a good point. If left undefined, GLIB_VERSION_MAX_ALLOWED is defined to the current stable release (GLIB_VERSION_CUR_STABLE). Once 2.56 is released, that means anyone who has not defined GLIB_VERSION_MAX_ALLOWED will get the new g_object_ref() behaviour by default. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
g_object_ref() now propagates types
Hi all, We just landed a patch in GLib which propagates the type from the argument of g_object_ref() to its return type: https://git.gnome.org/browse/glib/commit/?id=3fae39a5d https://bugzilla.gnome.org/show_bug.cgi?id=790697 The idea here is that it will catch invalid implicit casts which the compiler otherwise wouldn’t have noticed because g_object_ref() previously operated entirely on gpointers. This will eliminate a whole class of bugs: bugs which are unlikely to exist, but are a complete pain to track down if they do. The downside of this is that some legitimate implicit casts may now cause compiler warnings with -Wincompatible-pointer-types. For example, in the situation below, a warning will be introduced since parent_type isn’t guaranteed to be an instance of child_type: ParentType *parent_type; ChildType *child_type; child_type = g_object_ref (parent_type); To fix this warning, first double-check that parent_type is actually guaranteed to always be an instance of child_type at runtime, and then change the ref to: child_type = CHILD_TYPE (g_object_ref (parent_type)); That will add a compile-time explicit cast, and a runtime type check. (As always, the runtime type check is disabled if GLib is built without debugging enabled (or with G_DISABLE_CAST_CHECKS defined.) Note that the new behaviour requires GCC, and is only enabled if you have defined GLIB_VERSION_MAX_ALLOWED >= GLIB_VERSION_2_56. If anybody encounters any problems with this, please comment on the bug report: https://bugzilla.gnome.org/show_bug.cgi?id=790697 Thanks, Philip on behalf of the GLib maintainership cabal signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib compilation problems when building from git master with MSVC
On Fri, 2017-11-03 at 14:54 +, John Emmas wrote: > When trying to build glib (git master) I've hit a few compilation > snags > arising from commit #53bd6a359f (29th Sept 2017) Thanks for reporting these problems. I’ve reopened the bug (#788180) which added this code; let’s discuss things there. I’ve subscribed you to it. Philip > 1) Firstly (in gstdio.c) the function:- > '_g_win32_readlink_utf16_raw()' > uses a value called "IO_REPARSE_TAG_SYMLINK". This doesn't seem to > be > defined for MSVC - at least not in my version (VC8). > > 2) gstdio.c uses some other identifiers too - notably, > 'FILE_STANDARD_INFO' and 'FILE_NAME_NORMALIZED'. These seem to be > declared in winbase.h which should (in theory) be getting #included > by > windows.h. However, MSVC reports them both as undeclared > identifiers > (even if I specifically #include winbase.h !!) > > Is there some new #define needed which I maybe don''t know about ?? > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How to compile gobject-introspection ?
On Tue, 2017-08-08 at 16:19 +0200, Andy wrote: > I call ./autogen.sh > I have error: > configure: error: Package requirements (glib-2.0 >= 2.53.5) were not > met: > > No package 'glib-2.0' found > > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > > Alternatively, you may set the environment variables GLIB_CFLAGS > and GLIB_LIBS to avoid the need to call pkg-config. > See the pkg-config man page for more details. > --- > I try sudo apt-get install glib-2.0 > and is the same You want sudo apt-get install libglib2.0-dev In almost all distributions, the development files for libraries (pkg- config files, headers, debugging symbols) are packaged separately from the libraries themselves (.so files) because almost all users don’t need them. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Functional programming with GLib
I was thinking about that, but then fell into the trap of worrying about suggesting it because someone might expect me to implement it. I agree though; a reworking of GOptionContext which integrates better with GApplication, supports sub-commands and supports custom argument formats more easily would be lovely. Drawing inspiration from python- argparse would also be good. Philip On Thu, 2017-04-27 at 15:29 +0100, Emmanuele Bassi wrote: > For command line parsing I'd actually favour a slightly bolder > approach of deprecating GOptionContext, and having something slightly > more modern — in terms of being bindable in other languages, and > well-integrated with API like GApplication. > > For instance, something similar to [clap.rs][0]. > > Ciao, > Emmanuele. > > [0]: https://clap.rs/ > > On 27 April 2017 at 15:15, Philip Withnall > wrote: > > Hey, > > > > The general policy for GLib is that utility functions which are > > useful > > (and used in) several projects are considered for being added to > > GLib. > > > > To me, a functional programming approach using GLists is not > > something > > which every project is going to use. Is there any harm in keeping > > it as > > a separate library? There’s nothing stopping projects from linking > > to > > GLib *and* GXLib. :-) > > > > The command line parsing stuff you have looks a bit more widely > > applicable. Were you considering merging those into GLib? > > > > http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.ht > > ml > > > > Anyway, nice work on GXLib. It looks well documented. > > > > Philip > > > > On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote: > > > Hi All, > > > > > > A while back, I wrote some functions for functional-flavored > > > programming > > > with GLib. It's fully documented[1], has tests, etc. > > > > > > It would (for me at least) be useful to have some of these > > > functions > > > in > > > GLib-proper, but I suspect the GLib-maintainers are not /too/ > > > eager > > > to > > > accept contributions to GList... anyway, perhaps its useful for > > > others. > > > > > > As a simple example, suppose we want to calculate the sum of > > > primes > > > up > > > to 100 (a common task after all): > > > > > > , > > > > intsum; > > > > GList *nums, *primes; > > > > > > > > nums = gx_list_iota (100, 1, 1); > > > > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL); > > > > sum= gx_list_sum (primes); /* => 1060 */ > > > > > > > > g_list_free (nums); > > > > g_list_free (primes); > > > > > > ` > > > > > > There's also folding, mapping etc. See a short article about > > > this: > > > http://www.djcbsoftware.nl/2015/10/04/functional-glists/ > > > (2015?! time does fly). Am still developing it though. > > > > > > Repo: https://github.com/djcb/gxlib > > > Docs: http://www.djcbsoftware.nl/code/gxlib/ > > > > > > Best wishes, > > > Dirk. > > > > > > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Functional programming with GLib
Hey, The general policy for GLib is that utility functions which are useful (and used in) several projects are considered for being added to GLib. To me, a functional programming approach using GLists is not something which every project is going to use. Is there any harm in keeping it as a separate library? There’s nothing stopping projects from linking to GLib *and* GXLib. :-) The command line parsing stuff you have looks a bit more widely applicable. Were you considering merging those into GLib? http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html Anyway, nice work on GXLib. It looks well documented. Philip On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote: > Hi All, > > A while back, I wrote some functions for functional-flavored > programming > with GLib. It's fully documented[1], has tests, etc. > > It would (for me at least) be useful to have some of these functions > in > GLib-proper, but I suspect the GLib-maintainers are not /too/ eager > to > accept contributions to GList... anyway, perhaps its useful for > others. > > As a simple example, suppose we want to calculate the sum of primes > up > to 100 (a common task after all): > > , > > intsum; > > GList *nums, *primes; > > > > nums = gx_list_iota (100, 1, 1); > > primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL); > > sum= gx_list_sum (primes); /* => 1060 */ > > > > g_list_free (nums); > > g_list_free (primes); > > ` > > There's also folding, mapping etc. See a short article about this: > http://www.djcbsoftware.nl/2015/10/04/functional-glists/ > (2015?! time does fly). Am still developing it though. > > Repo: https://github.com/djcb/gxlib > Docs: http://www.djcbsoftware.nl/code/gxlib/ > > Best wishes, > Dirk. > signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gio enhancement.
Hi, On Thu, 2017-04-13 at 10:14 +0200, Bruggemann Eddie wrote: > Hi to everybody, > > Some ideas for enhance GIO. > > --- > > Why not include encrypting into GIO per example a function: > > ```C > > GFile *g_file_encrypt(GFile *file, GEnryptAlgo algorithm) ; > > ``` > > --- > > Or For multimedia files (Video, Music, Image) providing a way to > access > the meta-data: > > in a type like this: > > GMediaFileInfo > > --- > > Else because Gtk has a library for the font (pango) for drawing > (cairo) > for images (gdk_pixbuf), and so on... > > Why not get a library for playing sounds ? GStreamer exists for playing sounds. Putting functionality for encryption or playing sounds into GIO itself would pull in a lot of code which would not be used by most projects which depend on GIO. Instead, you should be looking at adding functions to those libraries which take a GFile as a parameter. Are you looking to fill a specific gap in functionality for a project you’re working on? Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?
Hey, On Mon, 2016-08-01 at 20:10 +0200, Sébastien Wilmet wrote: > GLib/GTK+ don't seem to provide a Valgrind suppression file upstream. > At > the following wiki page: > https://wiki.gnome.org/Valgrind That page is fairly outdated. I’ll give it a bit of a spruce up. > So, is there an up-to-date Valgrind suppression file somewhere? Or is > GNOME.supp the most up-to-date? The one I’ve been using is here: https://github.com/pwithnall/walbottle/blob/master/libwalbottle/tests/w albottle.supp It covers most of the GLib and GIO functionality which I’ve been using recently. Enough to get the Walbottle tests Valgrind-clean, at least. I do not claim it’s anything like perfect though. > I'm aware of: > "Make GLib valgrind friendly" > https://bugzilla.gnome.org/show_bug.cgi?id=627423 > But in that bug, there is no significant activity since 2013, so if > there is an up-to-date suppression file, it might make sense to > include > it upstream, and install it. This has been discussed before, and I failed to do anything about it: https://bugzilla.gnome.org/show_bug.cgi?id=666114#c28 Installing a suppression file with GLib won’t fix everything, because Valgrind only has one default suppression file, which we can’t modify or add to. So even if GLib installed a suppression file, you’d have to pass it as a --suppressions argument to Valgrind manually. However, that is better than having to write your own suppressions file //and// pass it in. See here for information about default.supp: https://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto#Valgrind_and _suppression_files Valgrind has a couple of bugs open about improving its support for default suppressions. None of them have seen activity recently: https://bugs.kde.org/show_bug.cgi?id=93376 https://bugs.kde.org/show_bug.cgi?id=160905 (basically a duplicate) Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Submitting changes for gobject-introspection
Hi, On Tue, 2016-04-05 at 19:09 +0530, Krishnamoney Elayath wrote: > I am new to open source community and I would like to push the > following changes to the gobject introspection. What would be the > steps to do this > > girepository/gitypelib.c > > #define MAX_NAME_LEN 255 <-- this is currently 200 which is not > sufficient while using > introspection along with generated symbols from tools like yang tool > chain. Please file a new bug report against gobject-introspection here: https://bugzilla.gnome.org/enter_bug.cgi?product=gobject-introspection and attach a git formatted patch with your changes (and a suitable commit message explaining them). You might find git-bz is useful for this: http://git.fishsoup.net/cgit/git-bz/ Thanks! Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Interface analyzer for GTK+
On Wed, 2015-09-30 at 10:40 +0200, Daniel Milewski wrote: > > What kind of events are you wanting to log? > > I need to log events caused by user interacting with the program. > More > specifically, I have to log GDK events of these types: > > * GDK_MOTION_NOTIFY > * GDK_BUTTON_PRESS > * GDK_2BUTTON_PRESS > * GDK_BUTTON_RELEASE > * GDK_KEY_PRESS > * GDK_KEY_RELEASE > > I also need to store along some data about widgets (like their name > and > size), to make distinction between events received by different > widgets. Sounds like SystemTap would be appropriate for this. > > I suggest the events be agnostic to your GOMS software. > > What do you mean by that? Output a general event trace, usable by all sorts of software. Not an event trace which is only useful for GOMS. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Interface analyzer for GTK+
Hey, On Mon, 2015-09-28 at 19:58 +0200, Daniel Milewski wrote: > As a part of my engineer's thesis I'm developing a interface analysis > tool for GTK+. The tool's purpose is to let one judge how good the > interface design is based on task execution and learning time. It'll > employ a theoretical framework known as the GOMS method[1]. As I hope > to get my code accepted into GTK+, I have a few questions. > > I need to make GTK+ create an event log in runtime. I skimmed through > documentation and the source code and I've found the --gtk-debug > option. My idea was to add a one more debug flag named "goms" to make > analysis conditional. Is it ok? > It'd also be nice to have a way to specify a filename of the event > log. > Since it's not possible to squeeze the filename into the debug > string, > is it ok to introduce a second command line for this? Note firstly that I’m not a GTK+ maintainer, so these are just my suggestions rather than concrete answers. What kind of events are you wanting to log? Similar-ish stuff has been done for GLib by making it emit SystemTap events if compiled with --enable-systemtap. https://sourceware.org/systemtap/SystemTap_Beginners_Guide/userspace-pr obing.html#uevents I suggest the events be agnostic to your GOMS software. Your software would have a SystemTap script which post-processes these into the format you want, which is specific to your software. > I also wonder if there is a preferred format for dumps of this kind > in > GNOME. I think of going with XML since a lot of other things in GNOME > like interface descriptions also make use of XML. Do you have better > ideas or suggestions on this? > > If XML is ok, then what is the recommended way to generate XML output > in GNOME? I saw that some parts of GTK+ are generating XML from > inline > strings and using convenience functions provided by GMarkup, which is > rather not clean. Is it fine to generate dumps this way? I wonder if > introducing a dependency on e.g. libxml would be better. I doubt that anyone would want to add a dependency on libxml2 to GTK+ simply to output XML. I believe one of the reasons for writing GMarkup in the first place was to avoid a dependency on libxml2, because a lot of its functionality (XSLT transforms!) is unnecessary for most of the use cases GLib and GTK+ have for XML (parsing UI files, mostly). Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: HELP: fixing nullable annotations for return values
Hey, On Fri, 2015-08-14 at 17:13 +0100, Alberto Ruiz wrote: > During GUADEC I decided to revive a small effort I took a while ago. > I wrote a script using the private GObject Introspection AST API to > check if %NULL was mentioned in the documentation string of any > return value in any way that indicated that such function/method was > likely to miss the (nullable) introspection annotation. Sorry to have missed this at GUADEC. :-( I have a couple of bug reports open about incorrect annotations already: • https://bugzilla.gnome.org/show_bug.cgi?id=742903 • https://bugzilla.gnome.org/show_bug.cgi?id=719966 #719966 is a big one and is worth looking at because it depends on https://bugzilla.gnome.org/show_bug.cgi?id=729660 which suggests fixing things by changing some of the GIR default assumptions about what’s nullable and what’s not (regarding closures). > I came up with a list of 143 functions that I'm trying to fix on a > branch (wip/aruiz/nullable-annotations), the plan is to collect and > review all the fixes there and then rebase/sqash into master > eventually. I'm tracking the effort on bgo#753520 [0] and using this > Google Spreadsheet[1]. > > Anyone interested in helping fixing any of the listed functions, just > add your IRC nickname in the owner list in the spreadsheet[1] and > push into that branch. I only ask of a few things before pushing: > - Check if (transfer none/full) applies > - Rename NULL or #NULL as %NULL if you have the chance. > - Check if the function is actually nullable, my script may be > mislead by whatever is in the document. > > If we have any clang hacker, it'll be great if we could tool this > into the compiler to check at compile time if a given function can > return NULL at some point. To have something like this integrated in > Builder and gobject introspection would certainly prevent new APIs to > suffer from this problem. https://people.collabora.com/~pwith/tartan/ If I ever get time to finish it. It can already do a lot of this — that’s how I found all the problems in bug #719966. Help very much welcome. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMemVTable broken
On Sat, 2015-06-27 at 05:38 +0200, 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? https://bugzilla.gnome.org/show_bug.cgi?id=701694 I think. signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Sun, 2015-01-25 at 07:22 -0500, Cosimo Cecchi wrote: > On Sat, Jan 24, 2015 at 4:33 AM, Carlos Garcia Campos > wrote: > I'm assuming the providers will render the contents into > surfaces that > > the previewer will compose, not providers directly drawing > into the > previewer. We can share the bitmaps between processes without > using > anything like CORBA, simply using shared memory and sending > the file > descriptor with dbus. Note that providers might not be > asynchronous, or > thread safe. > > > I can see a few problems with this approach: > - data is not always a static bitmap. You can preview arbitrary > complex things like webpages, videos, presentations, etc. In the > future even possibly complex CAD drawings or whatnot, if a module gets > written for them. > - the problem with doing this generically is that there needs a system > that notifies what has been invalidated in order to redraw, something > that forwards input events, etc. > - ideally we don't want to copy every frame while doing that > > > Bastien's suggestion to use (wayland) sub-surfaces sounds like a much > better fit, as they're designed specifically to address some of these > problems. My understanding is that it requires writing a small wayland > compositor in the widget itself; not sure yet what'd be involved with > this. There's also a question about what to do on backends (like X11) > that don't really support such a thing. I guess we could use XEmbed on > X11, but I can see it turning messy pretty quickly. > > > That's why my proposal doesn't enforce this specific design; I'm > definitely open to think more about how a multi-process design looks > like, but I wouldn't want to block until that is figured out. To me, the security and rendering architecture of this seems pretty core in the design, so I _would_ block on figuring it out. It doesn’t feel like the kind of thing which can easily be bolted on or fixed afterwards. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cl-cffi-gtk: A Common Lisp binding for GTK+ 3
Hi, On Wed, 2015-01-21 at 14:27 +, Sian Mountbatten wrote: > I'd like to bring to your attention the Common Lisp binding for GTK+ 3 > written by Dr Dieter Kaiser . The binding is > thorough and well documented. I don’t know much about Lisp, especially not about writing bindings for it, but it appears that cl-cffi-gtk doesn’t use gobject-introspection data. Is there a reason for this? Using it might allow you to automatically bind a lot more GObject-using API. If there are features or information missing from GIR files, please drop an e-mail to gir-devel-l...@gnome.org to discuss it. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Wed, 2015-01-21 at 10:25 -0800, Christian Hergert wrote: > On 01/21/2015 08:50 AM, Philip Withnall wrote: > > Or perhaps > > GtkWidget *gtk_preview_widget_new_from_stream (GInputStream *); > > which would more generally cover this via GMemoryInputStream? > > One potential downside to this is that applications will need to > implement their own async open/priority queue. (Imagine updating a > FileChooser preview while a users spuriously holds down arrow). > > That specific case, is not something I'd want every application to have > to implement. Certainly, and in that case I suppose they would use the GFile-based API, which would take care of that for them, I think? The GInputStream API would be for memory input or other exceptional situations. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: GtkPreview library
On Wed, 2015-01-21 at 10:16 -0500, Erick Pérez Castellanos wrote: > > Theoretically, previewing would be interesting whenever an app wants > > to provide a view of a content item - that could be useful for chat, > > social messaging, mail, or download/transfer applications. However, I > > haven't done any detailed work into how this would look. One question > > in this area is whether applications would > > Thinking on this I would add to the API: > > + `GtkWidget * gtk_preview_widget_new_from_data (gpointer)` > > in order to provide preview for not file-backed data. Or perhaps GtkWidget *gtk_preview_widget_new_from_stream (GInputStream *); which would more generally cover this via GMemoryInputStream? Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Fix check for 'y' padding in gtk_cell_renderer_set_padding()
On Tue, 2015-01-13 at 08:10 -0500, Matthias Clasen wrote: > On Mon, Jan 12, 2015 at 1:30 PM, Philip Withnall > wrote: > > On Sun, 2015-01-11 at 16:43 +, Emmanuele Bassi wrote: > >> hi; > >> > >> thanks for your patches. GTK+ does not use the mailing list to track > >> bugs and patches; could you please open bugs on Bugzilla, instead? > >> > >> just use: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B > >> > >> this will make it easier for us to track the issue, review the code, > >> and commit the change. > > > > This looks similar to (but not the same as) the patches I posted from > > analysing GTK+ with Clang static analyser in November, which are still > > awaiting review. > > > > I really hope we aren't going to end up with duplicate bug reports and > > duplicate patches because things are not getting reviewed. :'-( > > > > https://bugzilla.gnome.org/show_bug.cgi?id=712760 > > > > I can't say that I agree with them being very similar. Most of Maks' > patches were small, to the point, obvious oversight fixes that could > be reviewed in a minute, each. The static analysis 'fixes' are an > endless stream of mind-numbing can-never-happen corner cases of > dubious value. Just IMO, of course :-) He’s doing great work, for sure. Initially I posted a lot of static analysis ‘fixes’, purely because I didn’t know how (entirely reasonably) picky you wanted to be about what to consider relevant. There has not been an endless stream of them: I’ve stalled on this Coverity work (on GTK+ at least) since the end of 2013. Since the first round of patches, I have tried to be more selective about which issues I patch, and have marked a lot more as false positives in Coverity. I believe the patches currently on bug #712770 (and a couple of GLib bugs) are all now mostly relevant bugs which can be triggered in the real world. For example, this one’s quite similar to one of the problems Maks fixed: https://bugzilla.gnome.org/show_bug.cgi?id=712760#c103 This one is triggerable (IIRC) by calling gtk_widget_set_visual(widget, NULL): https://bugzilla.gnome.org/show_bug.cgi?id=712760#c106 This one fixes handling NULL page setup objects when printing: https://bugzilla.gnome.org/show_bug.cgi?id=712760#c107 If you still think the balance is wrong, let me know, and we can try and sort out some rules for what kinds of issues to consider patching. I believe that fixing static analysis errors (or marking them as ignored) is like fixing compiler warnings: a lot of fiddling around in the beginning to get the code clean, and then the value comes from seeing new errors come in with new changes. Please, either review the patches; or reject them all with a big notice somewhere saying that GLib is not expected to be Coverity-clean and I’ll stop wasting my time trying to make static analysis useful. Either outcome would be fine. Just don’t leave the patches unreviewed indefinitely. That’s the worst of all worlds. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] Fix check for 'y' padding in gtk_cell_renderer_set_padding()
On Sun, 2015-01-11 at 16:43 +, Emmanuele Bassi wrote: > hi; > > thanks for your patches. GTK+ does not use the mailing list to track > bugs and patches; could you please open bugs on Bugzilla, instead? > > just use: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B > > this will make it easier for us to track the issue, review the code, > and commit the change. This looks similar to (but not the same as) the patches I posted from analysing GTK+ with Clang static analyser in November, which are still awaiting review. I really hope we aren't going to end up with duplicate bug reports and duplicate patches because things are not getting reviewed. :'-( https://bugzilla.gnome.org/show_bug.cgi?id=712760 Philip > thanks again! > > ciao, > Emmanuele. > > > On 11 January 2015 at 15:06, Maks Naumov wrote: > > gtkcellrenderer.c 1096 > > > > g_return_if_fail (xpad >= 0 && xpad >= 0); > > ___ > > gtk-devel-list mailing list > > gtk-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > > > > signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
Hi, On Tue, 2014-12-23 at 06:40 -0500, sduclos wrote: > Hi, > > Thanks for the info .. I didn't thought checking the repo. > There is one entree in Bugzilla about g_ptr_array_set_size () from 2007. You mean this? https://bugzilla.gnome.org/show_bug.cgi?id=422939 Not really relevant. > On 12/23/14, Philip Withnall wrote: > > Hi, > > > > On Mon, 2014-12-22 at 14:42 -0500, sduclos wrote: > >> Hi, > >> > >> I'm looking for the rational of using 'gint' instead of 'guint' in the > >> call: > >> > >> g_ptr_array_set_size (GPtrArray *array, gint length); > > > > > I imagine that the use of a signed integer was an oversight at the time > > which can now not be corrected without breaking API. It's not worth > > that. > > Well, looking at the code, length is used against len a couple of time in all > code path. This force the compiler to typecast gint into guint, say: > > http://stackoverflow.com/questions/50605/signed-to-unsigned-conversion-in-c-is-it-always-safe > > On the other hand, if guint is used instead of gint, only the caller > that use gint would need to typecast. > > But what happen to legacy code that use pass a gint/guint to a > g_ptr_array_set_size(..., guint lenght) is a bit foggy for me. That's where the problem lies. We can't change gint to guint without breaking API. The change would introduce new compiler warnings (converting signed to unsigned integer) in modules which previously didn't have any, which GLib guarantees to avoid. I'm not entirely sure whether it would be an ABI break (don't have time to trawl through the C specification at the moment). I guess it wouldn't be, since the only valid uses of that API are where (0 ≤ len ≤ G_MAXINT), which is binary compatible regardless of whether the function is expecting a signed or unsigned integer. > >> I assume that this has been debated to death .. but I can't find where! > > > > I can't find anything either. It probably hasn't; it's fairly > > unimportant. If you've got an array with more than 2^31 elements, you > > should probably be using something other than an array. > > Well we get rid of useless friction and also it normalize the interface. > Agree that 2^31 is plenty but for my use case, g_ptr_array it is the fastest. > Rather then returning to the user a pointer to an internal object in my lib > I return an index to a g_ptr_array of internal pointer .. it's safer - no > risk of dangling pointer for instance. I agree that it would make the API more pleasing, but I don't think we can justify the API break. Sorry! Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
Hi, On Mon, 2014-12-22 at 14:42 -0500, sduclos wrote: > Hi, > > I'm looking for the rational of using 'gint' instead of 'guint' in the call: > > g_ptr_array_set_size (GPtrArray *array, gint length); g_ptr_array_set_size() was introduced in 1998 (commit df9a49ec), and has not been modified since. The commit message introducing it doesn't mention anything about choosing gint as the type, other than that GPtrArray itself is similar to java.lang.Vector. I imagine that the use of a signed integer was an oversight at the time which can now not be corrected without breaking API. It's not worth that. > I assume that this has been debated to death .. but I can't find where! I can't find anything either. It probably hasn't; it's fairly unimportant. If you've got an array with more than 2^31 elements, you should probably be using something other than an array. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some shortcomings in gtestutils
On Wed, 2013-02-20 at 20:46 -0600, Federico Mena Quintero wrote: > * It's hard to get a debugger up in the middle of "make check". I can't > think of a way to do it other than manually inserting code to sleep in > the middle of the faulty test, and then attaching with a debugger > manually. Maybe having an environment variable or something, so that I > could run Add the following in your Makefile.am: TESTS_ENVIRONMENT = libtool --mode=execute gdb Then run `make check` as normal, and magically all of your tests will be run under gdb. If you just want to run a specific test binary under gdb, use `make check TESTS=my-test-binary` Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Mainloop debugging tool idea
On Mon, 2012-11-19 at 00:55 +0100, Bastien Nocera wrote: > Came the idea of using of watchdog thread, based on the mainloop, which > would check for how long the mainloop was running a particular > iteration, and have to dump a backtrace if the main loop was blocking on > a particular task for more than X amount of time. I had a similar idea for debugging folks, since there’s something blocking the main loop there too. My approach is to add some extra SystemTap probes to GLib to output information about the main loop and its events. These can be dropped into a log file and analysed later, or piped to a program running at the same time as the shell and analysed in real time. > Does anyone have code like that available? If not, where would one plug > that code into the main loop code in gmain.c? I started writing a ‘Main Loop Visualiser’ to do this. I didn’t get very far before I ran out of time, but the foundations are there if you think it’s worth pursuing. It takes in a log file generated by a SystemTap script and visualises it. The visualisation is only partially complete, but the log file stuff is mostly there. The main downside is that this would require gnome-shell to be run under SystemTap. https://www.gitorious.org/main-loop-visualiser/main-loop-visualiser The necessary SystemTap additions to GLib are languishing in a branch which I’ve just pushed here: https://www.gitorious.org/~pwithnall/gnome/pwithnalls-glib/commits/stap-probes I’m interested in working on this further, but I don’t have any time for it at the moment. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Improve handling of bug reports for GTK+?
On Sun, 2012-08-12 at 05:23 -0400, Tristan Van Berkom wrote: > When I was working on height-for-width support, we created the "EL" > (extended layout) whiteboard keyword for triaging... this is awkward > because one needs to perform explicit searches to get the EL bugs. > > So, while I was working on the geometry management, I did lookup > those bugs on a regular basis... however since then I do not receive > any notifications regarding GTK+ geometry management issues. Pipe dream: Bugzilla should scrap components and keywords and combine them both into ‘tags’ (or something like that). Each bug would have zero or more tags. A tag could be a component name, or a cross-component thing such as extended layout. This would get rid of the limitation that bugs have to be in one component (since it's often the case that two components are applicable; e.g. ‘documentation’ and ‘GtkBuilder’ for bugs about the GtkBuilder documentation), remove the pointless ‘General’ (or similar) components from products, and by allowing subscription to individual tags it would let people subscribe to cross-component things such as extended layout. Of course, this would be a massive change to Bugzilla, so I expect it won't happen for a while. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Crash in g_slice_alloc
It's almost certainly a memory corruption problem. Run your program under valgrind with G_SLICE=always-malloc and it should tell you where the problem is. e.g. G_SLICE=always-malloc valgrind --tool=memcheck ./my_program Philip On Wed, 2012-01-11 at 14:54 +0700, Hieu Trung Le wrote: > Hi, > > I'm currently using GLib for my application and sometime I get crash at > g_slice_alloc or g_slice_free_chain_with_offset. Do you know what might > cause of this crash? > > Thanks, > -Hieu > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: pango @ introspection.m4
On Mon, 2010-01-04 at 06:09 -0500, Paul Davis wrote: > any comments? It's explained in the bug report[1]: Pango is now dependent on gobject-introspection, and while Behdad will probably include introspection.m4 in the next release, in the long term the dependency will hold. In short, you need to install gobject-introspection >= 0.6.7. Regards, Philip [1]: https://bugzilla.gnome.org/show_bug.cgi?id=604770 > > -- Forwarded message -- > From: Paul Davis > Date: Sat, Jan 2, 2010 at 3:51 PM > Subject: pango @ introspection.m4 > To: gtk-devel-list > > > what is this? > > http://git.gnome.org/browse/pango/commit/?id=fd15a3a04c69af0f5c04cde8c659269d0b139c28 > > as far as i can tell, pango doesn't use introspection, and this was > added without including introspection.m4 to the pango tree, thus > rendering it unbuildable on a system that doesn't happen to have > introspection.m4 lying around in another convenient location. > > what is going on? > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
On Tue, 2009-01-27 at 00:19 +0100, Martin (OPENGeoMap) wrote: > hummm. > Example: > If we have for example a DWG binary file we have for example 15000 utf16 > strings. If i use glib i need make 15000 translations utf16/utf8 to use > the utf8 glib api. When i need save the file i need make other 15000 > translations. There are thounsand of formats using utf16. I don´t love > utf16, but I "MUST" use utf16 in the real world. I am not the guilty of > existence of utf16 :'( . If you find that really is a bottleneck, there's nothing stopping you from writing functions _in your app_ which would deal with the strings as UTF-16 throughout the process of loading and saving. Philip > Regards. > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: reference count not freed in dispose?
Yes, and priv->adjustment should be set to NULL afterwards to stop it
getting unreffed more than once. Please file a bug.
Philip
On Fri, 2008-12-12 at 00:41 -0500, Yu Feng wrote:
> Hi,
>
> I was reading gtkcellrendererspin.c
> and saw:
>
> static void
> gtk_cell_renderer_spin_finalize (GObject *object)
> {
> GtkCellRendererSpinPrivate *priv;
>
> priv = GTK_CELL_RENDERER_SPIN_GET_PRIVATE (object);
>
> if (priv && priv->adjustment)
> g_object_unref (priv->adjustment);
>
> G_OBJECT_CLASS (gtk_cell_renderer_spin_parent_class)->finalize (object);
> }
>
> Isn't it suggested that the reference counts should be freed in dispose
> method in GObject's document?
>
> Yu
>
>
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Patch] Re: Howto retrieve selected font size from GtkFontButton
On Wed, 2008-12-03 at 14:34 +0100, Nelson Benítez León wrote: > I think nowadays, thanks to library.gnome.org, most people use online > documentation, it's way more practical because you don't have to > install any package, it's always up-to-date, it has a good google > search and you can open the information in several tabs with your > browser. > > But I don't think this is an online vs offline documentation question, > I'm talking about adding a feature to the online docs, if people want > later to add that feature to the offline docs they can, just save the > html output of the online docs to disk in some browseable format. I strongly disagree with this, and while I can't speak for everyone, I'll join Ross in saying that I always use Devhelp over library.gnome.org. You can use tabs in Devhelp, and its search has never failed me. One of the main advantages of Devhelp, as Ross says, is that the documentation you have installed is tied to the library versions against which you're developing, so you don't get into muddles over changed/added/removed API. > I don't like this approach, it requires manpower, and what is worse, > someone who decides what is useful and whatnot, that is subjective, I > prefer there's an official documentation with no comments, and the > online documentation with the possibility to add comments. Just like > in www.php.net/docs.php where you have the online documentation with > comments, and if you choose to download the documentation (eg. to > consult it offline) then you get the official version with no > comments. Developers moderating submitted improvements to the documentation is no more subjective than them moderating patches. They know the code and its behaviour the best, and it's only really a matter of making sure that they set a consistent baseline for how simple the documentation is (in terms of what it assumes the reader knows already). I don't see that as being a problem. I've used the online PHP documentation, and the comments on it are more often than not quite helpful, and very suitable for inclusion into the offline documentation. However, there are also many cases where the comments are incorrect or contradictory, and that's why periodic moderation (and merging into the source code) is required. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder
I don't know about any other programs, but Totem transitioned a while ago (such that it uses GtkBuilder in 2.20), and it's been OK. The only big problem I can think of is the lack of accessibility support[1]. Philip [1]: http://bugzilla.gnome.org/show_bug.cgi?id=454653 On Sat, 2007-11-24 at 17:54 +0100, Mikael Hermansson wrote: > Hello! > > Just wondering when will libglade will be deprecated in favor of > GtkBuilder API? I dont see any news about this on live.gnome.org > > atm. I am writing an application using GTKBuilder API and the convert > scripts and it seems to work okey :-) I wonder if other developers has > plans to replace libglade in next Gnome release? > > > Not even GUIBuilder like gazpacho/Glade seems to support it right now? > > Greets > > M.H. > > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Website Review - draft 2
Hi, It might be an idea to link the list items in the "Interfaces" and "Foundations" section of the features page to the relevant parts of the API documentation on library.gnome.org. That is, unless the features page isn't meant for programmers. You might also want to insert some more whitespace into the area at the top; it looks a little crowded to me. Perhaps a line underneath the page title would help stop it merging in with section headings. :-) Philip On Sun, 2007-09-16 at 13:51 +0100, Martyn Russell wrote: > Hi, > > I finally got round to finishing these pages for a second review. > You can test the latest version here: > > http://imendio.com/~martyn/gtk/draft2b/about.html > > I have changed a few things compared to draft 1 which I initially did: > > - Fixed the pages so they work on devices like the N800. > - Fixed all the typos/comments that I received from the first review. > - Keep the menu on the left all times for quick navigation. > - Add a sub-menu for each page for quick "jump-to" links. > > I have tested these pages with: > > - Windows Internet Explorer 7 > - Safari (Windows beta) > - Firefox (Windows/Linux) > - Epiphany > - N800. > > It has to be said, that the pages do vary slightly from browser to > browser. Initially I went for a much smaller text but Tim convinced me > it was a bad idea and that we should use content text at 100% size not > 60% which I had tried. This does mean that in Firefox (especially on > Windows) the text does look a bit bloated. > > Of the pages the current issues left outstanding are: > > - We should have a better way of sharing future ideas (dev page) > - Is linking to a directory for old irc logs good enough? > - Should we change the logo (I don't mind either way)? > - Rework the FAQ (I will do this after so ignore that for now). > - Redirections for links like http://www.gtk.org/api/xxx/ are needed. > - Update the news page (will do this before committing). > > What are peoples thoughts on those? > Have I missed anything? > Does anyone have any other general comments? > signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: elastic tabstops implemented for GTK
Wow, that's such a good idea; the implementation seems to solve the problems I've always had with tabs/spaces/alignment. Is the patch for GtkSourceView, or just gedit? If you want to get it into "GTK", then it should probably be aimed at GtkSourceView. (Which is used by both gedit and Anjuta.) Well anyway, it's certainly got my vote. Philip On Thu, 2007-07-12 at 23:39 +0200, Nick Gravgaard wrote: > Hi everyone, > > I thought some of you might be interested in some work I did recently. > I came up with an idea I call elastic tabstops which I think goes some > way towards solving the problems we programmers have with indenting > and aligning code, and I've implemented this in GTK. At the moment > this exists in the form of a patch for gedit, but at some point I plan > to make a proper GTK class for it. > > For more information, please see http://nickgravgaard.com/elastictabstops/ > > I'd love to hear any feedback, and really love to see this > functionality appear in other projects. > > Tell me what you think, > Nick > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Warning! Spelling nazism follows...
Is the misspelling of GTK_BUILDER_ERROR_MISSING_ATTRIBUTE in
GtkBuilderError below a transcription error?
There're also spelling errors in the documentation for:
GtkBuilderConnectFunc: s/intented/intended/ and s/non NULL/non-%NULL/
gtk_builder_connect_signals_full: s/interpeted/interpreted/
gtk_buildable_set_property: s/neeeded/needed/
gtk_buildable_construct_child: s/outsideof/outside of/
I can't comment on the API though.
Philip
On Tue, 2007-06-12 at 18:26 -0300, Johan Dahlin wrote:
> Hi,
>
> During the Gtk+ developer meeting today it was decided that there will be a
> final GtkBuilder discussion before it gets committed to trunk.
> The current plan is that there will be a new developer release in the end of
> the week, most likely on friday and that GtkBuilder is going to be included
> in that release.
>
> I'd like this discussion to be focus on the Public API. I've included the
> two new public headers (gtkbuilder.h and gtkbuildable.h) with the API
> documentation embedded.
> Suggestions and questions about the documentation are also welcome, but
> remember that the documentation is still very much open for changes during
> the next couple of weeks, before the final release of 2.12.
>
> I've also attached a .glade file which demonstrates some of the new
> capabilities.
>
> gtkbuilder.h
>
>
> GtkBuilder is a replacement for the GladeXML found in the libglade library.
> It is responsible for parsing a GtkBuilder UI definition and constructing
> the object tree from that definition, usually a user interface.
>
> This is the API which applications are going to use.
>
> typedef enum
> {
> GTK_BUILDER_ERROR_INVALID_TYPE_FUNCTION,
> GTK_BUILDER_ERROR_UNHANDLED_TAG,
> GTK_BUILDER_ERROR_MISSING_ATTRIUTE,
> GTK_BUILDER_ERROR_INVALID_ATTRIBUTE,
> GTK_BUILDER_ERROR_INVALID_TAG
> } GtkBuilderError;
>
> struct _GtkBuilder
> {
> GObject parent;
>
> GtkBuilderPrivate *priv;
> };
>
> struct _GtkBuilderClass
> {
> GObjectClass parent_class;
>
> GType (* get_type_from_name) (GtkBuilder *builder,
> const char *typename);
>
> /* Padding for future expansion */
> void (*_gtk_reserved1) (void);
> void (*_gtk_reserved2) (void);
> void (*_gtk_reserved3) (void);
> void (*_gtk_reserved4) (void);
> };
>
> GTypegtk_builder_get_type(void) G_GNUC_CONST;
>
> /**
> * gtk_builder_new:
> *
> * Creates a new builder object.
> *
> * Return value: a new builder object.
> *
> * Since: 2.12
> **/
> GtkBuilder* gtk_builder_new (void);
>
> /**
> * gtk_builder_add_from_file:
> * @buildable: a #GtkBuilder
> * @filename: the name of the file to parse
> * @error: return location for an error
> *
> * Parses a string containing a GtkBuilder UI
> definition and
> * merges it with the current contents of @builder.
> *
> * Returns: A positive value on success, 0 if an error occurred
> *
> * Since: 2.12
> **/
> guintgtk_builder_add_from_file (GtkBuilder *builder,
> const gchar *filename,
> GError **error);
> /**
> * gtk_builder_add_from_string:
> * @builder: a #GtkBuilder
> * @buffer: the string to parse
> * @length: the length of @buffer (may be -1 if @buffer is nul-terminated)
> * @error: return location for an error
> *
> * Parses a file containing a GtkBuilder UI
> definition and
> * merges it with the current contents of @builder.
> *
> * Returns: A positive value on success, 0 if an error occurred
> *
> * Since: 2.12
> **/
> guintgtk_builder_add_from_string (GtkBuilder *builder,
> const gchar *buffer,
> gsize length,
> GError **error);
> /**
> * gtk_builder_get_object:
> * @builder: a #GtkBuilder
> * @name: name of object to get
> *
> * Return value: GObject or %NULL if it could not be found in the object tree.
> *
> * Since: 2.12
> **/
> GObject* gtk_builder_get_object (GtkBuilder *builder,
> const gchar *name);
> /**
> * gtk_builder_get_objects:
> * @builder: a #GtkBuilder
> *
> * Return value: a newly-allocated #GSList containing all the objects
> * constructed by GtkBuilder instance.
> *
> * Since: 2.12
> **/
> GSList* gtk_builder_get_objects (GtkBuilder *builder);
>
> /**
> * gtk_builder_set_translation_domain:
> * @builder: a #GtkBuilder
> * @domain: the translation domain or %NULL
> *
> * Sets the translation domain and uses dgettext() for translating the
> * property values marked as translatable from an interface description.
> * You can also pass in %NULL to this method to use gettext() instead of
> * dgettext().
> *
Re: Common OSD widget?
On Fri, 2007-06-01 at 16:35 +0100, Bastien Nocera wrote: > On Fri, 2007-06-01 at 15:43 +0100, Philip Withnall wrote: > > Hi, > > > > I'm looking at the possibility of adding an OSD to Totem > > (http://bugzilla.gnome.org/show_bug.cgi?id=442925), similar to the one > > now in gnome-control-center/gnome-settings-daemon for display when the > > mixer volume's changed > > (http://bugzilla.gnome.org/show_bug.cgi?id=383066). There's also a bug > > for getting one in gnome-power-manager > > (http://bugzilla.gnome.org/show_bug.cgi?id=400844), which makes me > > wonder if it might just be better to write a common widget and put it > > somewhere like libegg (and eventually GTK?). There's already a > > GtkWindow-derived object for it in gnome-settings-daemon > > (http://svn.gnome.org/viewcvs/gnome-control-center/trunk/gnome-settings-daemon/gsd-media-keys-window.c?view=markup), > > so that could probably be used as a base. However, it would be better to > > use themed icons, rather than drawing a picture on screen manually using > > Cairo, as the code does at the moment. > > > > I just want to know what people's thoughts are on this, and if they're > > positive, what I should do to go about getting it working. > > It would probably be a good idea to make this easier to achieve, but I > don't think we'd get that many applications actually sharing that code. > Only gnome-power-manager and gnome-settings-daemon would use similar > middle of the screen popups. > > Most media/movie players would have different needs as far as those sort > of popups are concerned, eg. you can expect Totem to show keys pressed, > as a visual feedback, whereas Rhythmbox would only show visual effects > and fade artist information in and out in fullscreen mode. > > Trying to share too much here is probably an optimisation too early. There's all the media programs, plus g-p-m and g-s-d, which is quite a lot --- certainly enough to put that volume control widget in GTK+. I propose that the code written is basically just for drawing the fancy transparent "window", with some convenience functions for putting an icon and text in it --- the underlying container widget could be exposed to allow applications to put whatever they want there, if they feel it's necessary. Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Common OSD widget?
Hi, I'm looking at the possibility of adding an OSD to Totem (http://bugzilla.gnome.org/show_bug.cgi?id=442925), similar to the one now in gnome-control-center/gnome-settings-daemon for display when the mixer volume's changed (http://bugzilla.gnome.org/show_bug.cgi?id=383066). There's also a bug for getting one in gnome-power-manager (http://bugzilla.gnome.org/show_bug.cgi?id=400844), which makes me wonder if it might just be better to write a common widget and put it somewhere like libegg (and eventually GTK?). There's already a GtkWindow-derived object for it in gnome-settings-daemon (http://svn.gnome.org/viewcvs/gnome-control-center/trunk/gnome-settings-daemon/gsd-media-keys-window.c?view=markup), so that could probably be used as a base. However, it would be better to use themed icons, rather than drawing a picture on screen manually using Cairo, as the code does at the moment. I just want to know what people's thoughts are on this, and if they're positive, what I should do to go about getting it working. Cheers, Philip signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
Yeah, that was me. I've since stopped, and I'm talking with Tor Lindqvist about how I could be more useful. He's suggesting I go through the list of unloved patches and review them, which sounds fair enough. Philip On Sun, 2007-05-27 at 12:39 -0400, Matthias Clasen wrote: > On 3/15/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > > Your mission, should you decide to accept it, is to do this: > > > > - Get the latest GTK+ from svn trunk. > > > > - Go through each of the unreviewed patches and classify them > > informally: > > > > - obsolete patch which does not apply "as-is" to the sources > > (you can use "patch --dry-run" to test this easily without > > screwing up your source tree) > > - big patch which needs detailed testing/review > > - small patch which could be tested/reviewed in a few minutes > > > > I see that somebody took up this task now. While I appreciate the effort, > I don't think that a mere applies/doesn't apply small/big classification of > patches helps _that_ much with the patch review. > > I have started a small patch review checklist in > http://live.gnome.org/GtkTasks#P1 > that should help people who want to bring patches in good shape. > > Matthias > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Default DND action when multiple actions defined
For people's information, this is bug #372220 (http://bugzilla.gnome.org/show_bug.cgi?id=372220) in Totem. On Fri, 2007-05-11 at 01:10 +0100, Bastien Nocera wrote: > Heya, > > It doesn't seem possible to achieve the following in GTK+: > - widget accepts GDK_ACTION_COPY and GDK_ACTION_MOVE, but widget has a > *default* action of GDK_ACTION_MOVE (not copy) > > I'm trying to get to the following behaviour in Totem: > - dnd on the video canvas defaults to "link" which would clear the > playlist, and add the dropped items to the list. Pressing Ctrl at the > same time would add the items to the playlist. > - dnd on the playlist which would "copy" by default, and only add the > items to the list. Pressing Shift at the same time would replace the > items in the playlist. > > Is it possible to do this in GTK+ right now? (in which case, pointers > appreciated, and I'd update the docs to show that) > If not, is it an XDND protocol limitation, or a GTK+ one? > > Cheers > signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Turning off screens in a multiscreen setup
Oh crud, looks like I _did_ post it to the wrong list. Excuse me... On Sun, 2007-05-06 at 21:31 +0100, Philip Withnall wrote: > Hi all, > > I suppose I should start by asking "does g-p-m already turn off single > idle screens in a multiscreen setup?". Since I don't have such a setup > myself, I don't know, but if g-p-m does, then you don't have to bother > reading the rest of this e-mail. :-P > > This is following up on bug #347737 filed against Totem > (http://bugzilla.gnome.org/show_bug.cgi?id=347737), which asks that > other screens be turned off when one goes fullscreen in Totem. I was > wondering if it might be a better idea to make this desktop-wide, and > have idle screens turned off if they had no applications running on > them. They could then be turned on one-by-one again when the mouse moves > on them (as with a normal setup). As I said already, I don't have a > multiscreen setup, so I've got no idea what I'm talking about really, > but I thought it would be interesting to bring up anyway. > > Additionally, I apologise if I've posted this in the wrong place --- it > was a juggle between g-p-m, g-s, and GTK/GDK. I hope I chose the right > one. :) > > Cheers, > Philip Withnall > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Turning off screens in a multiscreen setup
Hi all, I suppose I should start by asking "does g-p-m already turn off single idle screens in a multiscreen setup?". Since I don't have such a setup myself, I don't know, but if g-p-m does, then you don't have to bother reading the rest of this e-mail. :-P This is following up on bug #347737 filed against Totem (http://bugzilla.gnome.org/show_bug.cgi?id=347737), which asks that other screens be turned off when one goes fullscreen in Totem. I was wondering if it might be a better idea to make this desktop-wide, and have idle screens turned off if they had no applications running on them. They could then be turned on one-by-one again when the mouse moves on them (as with a normal setup). As I said already, I don't have a multiscreen setup, so I've got no idea what I'm talking about really, but I thought it would be interesting to bring up anyway. Additionally, I apologise if I've posted this in the wrong place --- it was a juggle between g-p-m, g-s, and GTK/GDK. I hope I chose the right one. :) Cheers, Philip Withnall signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
