Re: Proposal: Recommend meson for glib 2.58.0
On the gvsbuild side we are already building with meson for a while and things are ok. I just fear the case where we do not have python 3 on rhel 6 and sles 11... On Fri, Jun 1, 2018 at 10:51 PM, Emmanuele Bassi wrote: > With Python 2.x getting EOL in less than 2 years, I suspect that > commercial distros will need to provide Python 3 pretty quickly. > > Ciao, > Emmanuele. > > On Fri, 1 Jun 2018 at 21:10, Christian Hergert > wrote: > >> On 06/01/2018 08:10 AM, xclae...@gmail.com wrote: >> > Disclaimer: I'm not a GLib maintainer so this email is only about >> > opening the discussion. There is no decision made yet. >> > >> > Opinions? >> >> I think the risk area is python3 support on some commercially supported >> distributions. Although, that is probably in better shape now than it >> was a year ago. >> >> Also not a maintainer, but +1 for the switch. >> >> -- Christian >> ___ >> gtk-devel-list mailing list >> gtk-devel-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > -- > https://www.bassi.io > [@] ebassi [@gmail.com] > > ___________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > > -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building glib on windows
Hi, if you need msvc builds you need to build them with msvc. Mixing runtimes while it could work it might deal to unexpected problems. Regards. On Tue, Nov 3, 2015 at 3:40 PM, <jcup...@gmail.com> wrote: > On 3 November 2015 at 14:34, Ignacio Casal Quinteiro > <nacho.r...@gmail.com> wrote: > > have a look at this: > > https://github.com/nice-software/gtk-win32 > > Hi Ignacio, that looks great, but unfortunately I need to build on > linux and cross-compile :-( > > Does anyone have a link to linux-hosted win64 gtk build system I could > have a look at? > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building glib on windows
Hey, have a look at this: https://github.com/nice-software/gtk-win32 Cheers. On Tue, Nov 3, 2015 at 3:26 PM, <jcup...@gmail.com> wrote: > Hi everyone, > > I'm trying to make my own 64-bit glib DLLs for Windows users. I'm > cross-compiling from linux with jhbuild. It seems to be working, > except that VS users can't link to the libraries I'm making. > > It looks like I need to generate .def and .lib files. Does anyone know > the recommended way to do this? I see the (now too out of date, > unfortunately) official ones have these files, but I can't see a > simple way to make them myself :-( Is there some script to run that > I've not been able to find? > > John > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_strdup_printf fails with VS2015 - snprintf doesn't support %n?
Hi Arnavion,
is this problem just specific to VS 2015? It seems weird that I managed to
build it without this problem with VS 2013.
Cheers.
On Sun, Oct 11, 2015 at 6:22 AM, Arnavion <arnav...@gmail.com> wrote:
> You're right. It does seem to have been fixed in gnulib.
>
>
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/vasnprintf.c;h=5254c8cfcbfc4f9145b1565de305585df8f7dd84;hb=master#l4875
> introduced by
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blobdiff;f=lib/vasnprintf.c;h=968835a1e7d5a704ae5a330ecda091b78851f73c;hp=8377d31eb591687186815e1de5cf973aac465120;hb=ba739e5686c1488280341451c3eb01a8f7b0aaa1;hpb=8c1ff97529b4f5b6462f1be302cc526ccb1960a1
>
> -Arnav
>
> On Sat, Oct 10, 2015 at 9:08 PM, LRN <lrn1...@gmail.com> wrote:
> > On 11.10.2015 7:00, Arnavion wrote:
> >> Hi Fan,
> >>
> >> In your commit 53d487e31bc41cca9bca147e02e81b69e404fe07 to glib you
> >> enabled glib to use VS2015's snprintf. Did you confirm it works?
> >>
> >> I'm updating our gtk-win32 repo to use glib 2.46.0 (from 2.44.1) and
> >> ATK fails to build - it runs glib-genmarshal as part of build when
> >> calling g_strdup_printf. I narrowed it down to
> >> glib/glib/gnulib/vasnprintf.c 's vasnprintf() function at the place
> >> where it effectively calls
> >>
> >> snprintf("%s%n", 12, "atkmarshal.list", );
> >>
> >> This aborts with exit code 0xc417 (invalid parameters to a CRT
> function).
> >>
> >> The Windows printf family of functions has historically not supported
> >> %n (see
> http://blogs.msdn.com/b/michael_howard/archive/2006/09/28/775780.aspx
> >> ) so that is probably the reason.
> >>
> >> I see code below that call that tries to see if snprintf failed to use
> >> %n and recover from it, but this of course doesn't work when the
> >> implementation has already aborted inside snprintf.
> >
> > This is gnulib ...print...() implementation. I would suggest asking
> gnulib
> > developers (maybe this is already fixed upstream, in which case glib
> should
> > pull newer gnulib source).
> >
> > --
> > O< ascii ribbon - stop html email! - www.asciiribbon.org
> >
> > ___________
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
--
Ignacio Casal Quinteiro
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SIGTRAP when sending signal on closing dbus connection
Hi Jean-Pierre, you should not be using the same object from different threads, instead you should probably idle to the main thread and to the signal from there. Cheers. Adding you to the gtk mailing list btw. On Tue, Jun 16, 2015 at 12:14 PM, jean-pierre.bog...@continental-corporation.com wrote: Hi *, in a multi threaded application we are receiving a SIGTRAP, while using gdbus. In short terms, the application is doing the following: Thread 1: g_object_unref(connection); Thread 2: g_dbus_connection_emit_signal(connection); The SIGTRAP is raised when a pthread_mutex_trylock fails, in the callstack of g_dbus_connection_emit_signal, because the mutex already is invalid. I assumed that gdbus is thread safe at this point. Is this assumption wrong or is there really a bug? In case more details are requried, please let me know. I can easily reproduce the issue at my place and already implemented a small test executable. Best regards Jean-Pierre ___ gnome-devel-list mailing list gnome-devel-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Would it be possible for me to fund / help maintain official GNOME Win32 bundles and an SDK? I'd love to improve Windows support of GTK+, but I'm never sure where the status is. Last time I tried jhbuild it failed on something early on -- I believe fontconfig, so that was a bummer. Well the current status is quite good compared with how it was a few years ago. The main problems are still: 1. that we have lots of downstream patches still on msys2, even though I spent quite a lot of time pushing them upstream. 2. building anything out of git is a nightmare, you need a tarball or everything gets in your way 3. gobject-introspection could get quite a bit of love for windows. There are though some patches in bugzilla that are waiting some review. 4. jhbuild would require some serious work. Cheers. On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote: On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote: The current stance of everyone involved in the Windows backend for GLib and GTK+ is to stop advertising binary builds for Windows — as we don't do that for any other platform, and nobody sticks around long enough to keep doing that or to set up a continuous integration build for GTK. Stop advertising == stop supporting? If I wanted to say stop supporting, I would have said that. Not that we *ever* supported binary builds, on any platform. If you want commercial support, you should contract somebody. Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK. This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows. On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software. Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ Like Git? Ship 200Mb of additional value on top? Just for comparison Mercurial installation is 37Mb compared with 267Mb of Git. And that for every GTK application? MSYS2 is for developers, not for end users. You're supposed to set up the development enviroment on *your* development machine(s); once you have built your application, you can take your binary artefacts, including the DLLs you depend on, put them into an installer, and let your users download the installer — which is exactly what you should have done in the past, even with pre-built DLLs. The intended change is for application developers to get pre-built, up to date binaries using MSYS2, instead of downloading zip files from gtk.org that we cannot reliably keep up to date. Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism. This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. Can GTK be cross-compiled for Windows? Yes, it can, and it routinely is. What the GTK team would love, on the other hand, is somebody putting the effort in setting up and maintaining a continuous integration service — similar to https://build.gnome.org — for Windows builds. This way we would be able to catch build regressions after every commit, without relying on the application developers to file bugs. http://www.appveyor.com/ if using closed source service is okay. No, it's really not — especially if it has to run on the gnome.org infrastructure. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Jasper ___ gtk-list mailing list gtk-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
Probably if we want continuous integration what we should do is to put jhbuild up to speed on windows. Last time I tried to build something with it, it failed but it is almost working. Cheers. On Thu, Jun 11, 2015 at 3:34 PM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 14:28, Bálint Réczey bal...@balintreczey.hu wrote: If you want to coordinate this effort, you can use the gtk-devel-list mailing list, and possibly join IRC to talk with the GTK developers and the gnome.org system administrators, in order to get a CI build going on the gnome.org servers. Perfect. Since we are already on the mentioned list who could I send my public SSH key? You should first set up something on your system, and then contact the GNOME system administrators to replicate it on the gnome.org infrastructure. If you don't have a system you can spare, you should probably outline what you're planning to do on the list first. Is there any documentation on the GTK+ CI system? The existing system used by GNOME is of continuous delivery, not just integration; you can read more about it on the wiki: https://wiki.gnome.org/Projects/GnomeContinuous Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
For the record following Emmanuele mail, you can find an example on how to create an installer for your application using msys2 here: https://git.gnome.org/browse/gedit/tree/win32 Cheers. On Thu, Jun 11, 2015 at 3:15 PM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote: On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote: The current stance of everyone involved in the Windows backend for GLib and GTK+ is to stop advertising binary builds for Windows — as we don't do that for any other platform, and nobody sticks around long enough to keep doing that or to set up a continuous integration build for GTK. Stop advertising == stop supporting? If I wanted to say stop supporting, I would have said that. Not that we *ever* supported binary builds, on any platform. If you want commercial support, you should contract somebody. Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK. This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows. On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software. Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ Like Git? Ship 200Mb of additional value on top? Just for comparison Mercurial installation is 37Mb compared with 267Mb of Git. And that for every GTK application? MSYS2 is for developers, not for end users. You're supposed to set up the development enviroment on *your* development machine(s); once you have built your application, you can take your binary artefacts, including the DLLs you depend on, put them into an installer, and let your users download the installer — which is exactly what you should have done in the past, even with pre-built DLLs. The intended change is for application developers to get pre-built, up to date binaries using MSYS2, instead of downloading zip files from gtk.org that we cannot reliably keep up to date. Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism. This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. Can GTK be cross-compiled for Windows? Yes, it can, and it routinely is. What the GTK team would love, on the other hand, is somebody putting the effort in setting up and maintaining a continuous integration service — similar to https://build.gnome.org — for Windows builds. This way we would be able to catch build regressions after every commit, without relying on the application developers to file bugs. http://www.appveyor.com/ if using closed source service is okay. No, it's really not — especially if it has to run on the gnome.org infrastructure. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
On Thu, Jun 11, 2015 at 3:22 PM, Emmanuele Bassi eba...@gmail.com wrote: Hey; On 11 June 2015 at 14:19, Ignacio Casal Quinteiro nacho.r...@gmail.com wrote: For the record following Emmanuele mail, you can find an example on how to create an installer for your application using msys2 here: https://git.gnome.org/browse/gedit/tree/win32 We really need to get a GTK-based installer, so you guys can stop using the Competition. ;-) heh, I definitely agree about that, there is the msitools project but it is not in msys2 and I did not have time yet to put it there. https://git.gnome.org/browse/msitools Cheers. Ciao, Emmanuele. On Thu, Jun 11, 2015 at 3:15 PM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote: On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote: The current stance of everyone involved in the Windows backend for GLib and GTK+ is to stop advertising binary builds for Windows — as we don't do that for any other platform, and nobody sticks around long enough to keep doing that or to set up a continuous integration build for GTK. Stop advertising == stop supporting? If I wanted to say stop supporting, I would have said that. Not that we *ever* supported binary builds, on any platform. If you want commercial support, you should contract somebody. Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK. This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows. On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software. Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ Like Git? Ship 200Mb of additional value on top? Just for comparison Mercurial installation is 37Mb compared with 267Mb of Git. And that for every GTK application? MSYS2 is for developers, not for end users. You're supposed to set up the development enviroment on *your* development machine(s); once you have built your application, you can take your binary artefacts, including the DLLs you depend on, put them into an installer, and let your users download the installer — which is exactly what you should have done in the past, even with pre-built DLLs. The intended change is for application developers to get pre-built, up to date binaries using MSYS2, instead of downloading zip files from gtk.org that we cannot reliably keep up to date. Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism. This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. Can GTK be cross-compiled for Windows? Yes, it can, and it routinely is. What the GTK team would love, on the other hand, is somebody putting the effort in setting up and maintaining a continuous integration service — similar to https://build.gnome.org — for Windows builds. This way we would be able to catch build regressions after every commit, without relying on the application developers to file bugs. http://www.appveyor.com/ if using closed source service is okay. No, it's really not — especially if it has to run on the gnome.org infrastructure. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro -- https://www.bassi.io [@] ebassi [@gmail.com] -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
And this one: https://bugzilla.gnome.org/show_bug.cgi?id=728313 On Thu, Jun 11, 2015 at 5:19 PM, Ignacio Casal Quinteiro nacho.r...@gmail.com wrote: Here you have: https://bugzilla.gnome.org/show_bug.cgi?id=620566 https://bugzilla.gnome.org/show_bug.cgi?id=733535 https://bugzilla.gnome.org/show_bug.cgi?id=693531 And here you have some downstream patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gobject-introspection Cheers. On Thu, Jun 11, 2015 at 5:07 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: I can take a look at the gobject-introspection work. Bugzilla links? On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro nacho.r...@gmail.com wrote: On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Would it be possible for me to fund / help maintain official GNOME Win32 bundles and an SDK? I'd love to improve Windows support of GTK+, but I'm never sure where the status is. Last time I tried jhbuild it failed on something early on -- I believe fontconfig, so that was a bummer. Well the current status is quite good compared with how it was a few years ago. The main problems are still: 1. that we have lots of downstream patches still on msys2, even though I spent quite a lot of time pushing them upstream. 2. building anything out of git is a nightmare, you need a tarball or everything gets in your way 3. gobject-introspection could get quite a bit of love for windows. There are though some patches in bugzilla that are waiting some review. 4. jhbuild would require some serious work. Cheers. On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote: On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote: The current stance of everyone involved in the Windows backend for GLib and GTK+ is to stop advertising binary builds for Windows — as we don't do that for any other platform, and nobody sticks around long enough to keep doing that or to set up a continuous integration build for GTK. Stop advertising == stop supporting? If I wanted to say stop supporting, I would have said that. Not that we *ever* supported binary builds, on any platform. If you want commercial support, you should contract somebody. Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK. This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows. On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software. Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ Like Git? Ship 200Mb of additional value on top? Just for comparison Mercurial installation is 37Mb compared with 267Mb of Git. And that for every GTK application? MSYS2 is for developers, not for end users. You're supposed to set up the development enviroment on *your* development machine(s); once you have built your application, you can take your binary artefacts, including the DLLs you depend on, put them into an installer, and let your users download the installer — which is exactly what you should have done in the past, even with pre-built DLLs. The intended change is for application developers to get pre-built, up to date binaries using MSYS2, instead of downloading zip files from gtk.org that we cannot reliably keep up to date. Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism. This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. Can GTK be cross-compiled for Windows? Yes, it can, and it routinely is. What the GTK team would love, on the other hand, is somebody putting the effort in setting up and maintaining a continuous integration service — similar to https://build.gnome.org — for Windows builds. This way we would be able to catch build regressions after every commit, without relying
Re: Outdated win32 bundle
Here you have: https://bugzilla.gnome.org/show_bug.cgi?id=620566 https://bugzilla.gnome.org/show_bug.cgi?id=733535 https://bugzilla.gnome.org/show_bug.cgi?id=693531 And here you have some downstream patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gobject-introspection Cheers. On Thu, Jun 11, 2015 at 5:07 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: I can take a look at the gobject-introspection work. Bugzilla links? On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro nacho.r...@gmail.com wrote: On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: Would it be possible for me to fund / help maintain official GNOME Win32 bundles and an SDK? I'd love to improve Windows support of GTK+, but I'm never sure where the status is. Last time I tried jhbuild it failed on something early on -- I believe fontconfig, so that was a bummer. Well the current status is quite good compared with how it was a few years ago. The main problems are still: 1. that we have lots of downstream patches still on msys2, even though I spent quite a lot of time pushing them upstream. 2. building anything out of git is a nightmare, you need a tarball or everything gets in your way 3. gobject-introspection could get quite a bit of love for windows. There are though some patches in bugzilla that are waiting some review. 4. jhbuild would require some serious work. Cheers. On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi eba...@gmail.com wrote: Hi; On 11 June 2015 at 13:44, anatoly techtonik techto...@gmail.com wrote: On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi eba...@gmail.com wrote: The current stance of everyone involved in the Windows backend for GLib and GTK+ is to stop advertising binary builds for Windows — as we don't do that for any other platform, and nobody sticks around long enough to keep doing that or to set up a continuous integration build for GTK. Stop advertising == stop supporting? If I wanted to say stop supporting, I would have said that. Not that we *ever* supported binary builds, on any platform. If you want commercial support, you should contract somebody. Currently, we advertise ad hoc Windows builds on gtk.org; those are out of date, and lack many of the bug fixes that went into GTK. This situation is confusing for application developers, and makes the project look bad. It also reflect badly on the great work that developers have been doing in order to make GTK work well on Windows. On top of that, we don't offer binary builds for any other platform, and instead rely on distributors — like Homebrew on Mac; the *BSD ports; or the various Linux distributions — to provide binary builds for them. Windows is an anomaly, mostly because there weren't good/usable software distributions in the past. This has now changed, and it's a good thing to ensure that developers on Windows get reliable, up to date software. Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ Like Git? Ship 200Mb of additional value on top? Just for comparison Mercurial installation is 37Mb compared with 267Mb of Git. And that for every GTK application? MSYS2 is for developers, not for end users. You're supposed to set up the development enviroment on *your* development machine(s); once you have built your application, you can take your binary artefacts, including the DLLs you depend on, put them into an installer, and let your users download the installer — which is exactly what you should have done in the past, even with pre-built DLLs. The intended change is for application developers to get pre-built, up to date binaries using MSYS2, instead of downloading zip files from gtk.org that we cannot reliably keep up to date. Telling your users to download your application; download DLLs from gtk.org; shove them into some directory; and, finally, hope for the best, was never a good software distribution mechanism. This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. Can GTK be cross-compiled for Windows? Yes, it can, and it routinely is. What the GTK team would love, on the other hand, is somebody putting the effort in setting up and maintaining a continuous integration service — similar to https://build.gnome.org — for Windows builds. This way we would be able to catch build regressions after every commit, without relying on the application developers to file bugs. http://www.appveyor.com/ if using closed source service is okay. No, it's really not — especially if it has to run
Re: Outdated win32 bundle
Hey, as pointed several times please read: https://blogs.gnome.org/nacho/2015/02/19/building-gtk-3-with-msvc-2013/ https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/ Cheers. On Wed, Jun 10, 2015 at 8:56 PM, Bill Kelly bi...@cts.com wrote: Hi, Emmanuele Bassi wrote: Developers using the G* core platform libraries on Windows are strongly encouraged to use the MSYS2 distribution: https://msys2.github.io/ This will provide you with pre-built packages that are known to work and maintained. It also allows you to build your own packages on top of it, and create an installer from the result. For whatever it's worth, I wanted to mention the GTK+ bundle provided by the folks at the HexChat project has been incredibly useful to us, specifically because their binaries were compiled with MSVC instead of MSYS/mingw: https://github.com/hexchat/gtk-win32/blob/master/README.md Importantly, the HexChat GTK+ Bundle provides *.pdb files, allowing source level debugging within Microsoft's debugger. The HexChat folks do also provide an automated script for building the full dependency stack under Visual Studio 2013. (I haven't tried the script yet, personally.) Anyway -- just wanted to mention the MSVC bundle was available, as source-level debugging of GTK+ has been very important to our project while doing Windows development. Regards, Bill ___ gtk-list mailing list gtk-l...@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using Python v3.3 while building Glib
Hi John, basically the nice-software one is fork of the hexchat one which also adds vc 2010 projects and gtk 3. When they update the repo we rebase and we also try to keep the gtk3 ones updated. Cheers. On Wed, May 13, 2015 at 10:34 AM, John Emmas john...@tiscali.co.uk wrote: On 13/05/2015 09:02, Ignacio Casal Quinteiro wrote: Hi John, are you using https://github.com/nice-software/gtk-win32/ ? If not, any reason to not use it and improve it for your use case? Thanks Ignacio. That looks like a useful resource and I should maybe consider it. For our purposes we have two slightly unusual requirements:- 1) For historical reasons we need to build with VC8. That's rarely supported now in gtk+ libs. 2) We build 3 targets, namely:- a) Full Debug version b) Full Release version c) Debuggable Release version It might seem like a luxury to have a debuggable Release build - but in fact it can be immensely useful. Are the nice-software libs synced to their official libraries (i.e. if there's a change upstream, does it get imported into the nice-software version?) My repos get updated weekly and are also on github:- https://github.com/johne53?tab=repositories Looks like we're basically doing the same thing !! John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using Python v3.3 while building Glib
Hi John, are you using https://github.com/nice-software/gtk-win32/ ? If not, any reason to not use it and improve it for your use case? Cheers. On Wed, May 13, 2015 at 9:59 AM, John Emmas john...@tiscali.co.uk wrote: I'm building Glib (from Git) using MSVC. FWIW I use my own MSVC projects (rather than the supplied ones) although that isn't relevant here. What's relevant is that, while building libgio, a bunch of python files get converted to binary equivalents. This is all connected with gdbus-codegen AFAICR. For example, there's a python source called codegen_main.py which gets converted to codegen_main.pyc. The build procedure has been working perfectly for many years. For reasons unconnected with Glib I needed to upgrade python yesterday to ver 3.3.5. Since the upgrade, my python binaries now have different names. For example, the above binary now gets called:- codegen_main.cpython-33.pyc I don't know enough about the build process to know whether there might be any ramifications caused by the name changes. Are the .pyc files just used internally by python itself (in other words, the name isn't important)? Or could there be other ramifications for my build? I realise I should be contacting the python team - but I wanted to ask some advice first to find out if anyone can anticipate any potential problems from this change? Thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK_KP_Decimal (on Windows)
Hi John, out of curiosity can you check if this is true for gtk3? Cheers. On Wed, Apr 29, 2015 at 5:01 PM, John Emmas john...@tiscali.co.uk wrote: On 29/04/2015 08:54, John Emmas wrote: The Windows version looks slightly different:- case VK_ADD: *ksymp = GDK_KP_Add; break; case VK_SEPARATOR: *ksymp = GDK_KP_Separator; break; case VK_SUBTRACT: *ksymp = GDK_KP_Subtract; break; // some others However, the list for Windows doesn't seem to include 'GDK_KP_Decimal'. Might this explain why the decimal point key is getting ignored on Windows? Just for the hell of it I decided to add an entry for GDK_KP_Decimal - and sure enough, it seems to have fixed the problem. Does anyone know of a valid reason why that one got left out for the Windows list? Thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should we drop XP?
well one of the reasons is that we are patching downstream in this ways (it can be fixed though) https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-glib2/0027-no_sys_if_nametoindex.patch and afaik fan or lrn had some ideas to improve some parts of the code once xp is dropped On Wed, Apr 1, 2015 at 9:41 AM, Alexander Larsson al...@redhat.com wrote: On tis, 2015-03-31 at 22:41 +0200, Ignacio Casal Quinteiro wrote: Hey folks, so I was wondering if for 3.18/2.46 if we should drop XP. I think it would make our life easier and anyway why do we need to support something that microsoft is also not supporting? My opinion on this is that we should do this as soon as it is any kind of inconvenience to us to support XP. I.E. if we add some non-optional feature that doesn't work on XP. I don't think we necessarily have to drop existing XP code just because, let the existing support stay there until it no longer works. Its possible that this is true already, I've not done any Win32 work recently. If so, just drop it. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an otherworldly neurotic cyborg living undercover at Ringling Bros. Circus. She's an enchanted green-skinned barmaid with an incredible destiny. They fight crime! -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Should we drop XP?
Hey folks, so I was wondering if for 3.18/2.46 if we should drop XP. I think it would make our life easier and anyway why do we need to support something that microsoft is also not supporting? Cheers. -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should We Start Dropping Windows XP Support?
+1 to drop it On Tue, Dec 30, 2014 at 9:26 AM, Fan Chun-wei fanc...@yahoo.com.tw wrote: Hi, Happy Holidays and Happy New Year! I understand that this has been brought up before, but I think probably it's time to gather views on whether we should start to drop XP support, as: -There are some things that required specialized implementations for XP, for example, SRWLock in GLib and networking items in GIO, which may or may not work well. (for example, by using inet_pton() directly in ginetaddress.c for Windows Vista and later enabled many of the network-address.c tests to pass) -We often needed to do GetProcAddress() to check the availability of system-level funtionalities, which would probably need a clean-up. -As people may know, Microsoft ended support for XP this past April, and it is found that maintaining support for XP is becoming a bigger and bigger maintenance burden. -There is likely the need to move forward to use newer system APIs and features, which were only available after XP (such as desktop/window composition) -Other reasons that people might bring up for this. I understand that it might be late in this dev cycle to drop XP support, but I do hope to do it (or at least take part in it) in the next cycle, so I am writing here to see how people think about this before going into this. Any insight into this part would be really appreciated. With blessings, thank you! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building gdk-pixbuf loaders as static libs
Hey John, you can have a look at msys2 to see how gdk-pixbuf is built with static loaders. https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdk-pixbuf2 Cheers. On Tue, Dec 2, 2014 at 10:21 AM, John Emmas john...@tiscali.co.uk wrote: I build the Windows version of our product (Mixbus) which utilises both pango and gdk-pixbuf. Each library contains various 'modules' and for many years I've been building them as externally loadable DLLs (i.e. pango modules and gdk-pixbuf loaders). We use the usual text files to tell Mixbus where to find them. Unfortunately, this can be inconvenient on Windows because it isn't always easy to predict where Windows will install them (for example, lots of Windows users don't even have a C: drive). A few weeks ago I discovered that it's possible to build pango's modules as static libs and link them to pango statically. This was a big step forward for us and it was mostly just a case of reconfiguring my MSVC projects and #defining PANGO_MODULE_PREFIX in a few places. Is it possible to do the same thing with gdk-pixbuf (i.e. link statically to the various pixbuf loaders)? If so, is it similarly easy and/or are there any instructions anywhere that I could refer to? Many thanks, John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Building gdk-pixbuf loaders as static libs
John, in the link you can find out a couple of patches that needed to be applied, also here is the option we pass using mingw: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gdk-pixbuf2/PKGBUILD#L45 Not sure though how you can do that from msvc. Hope it helps. On Tue, Dec 2, 2014 at 12:05 PM, John Emmas john...@tiscali.co.uk wrote: On 02/12/2014 09:58, Ignacio Casal Quinteiro wrote: you can have a look at msys2 to see how gdk-pixbuf is built with static loaders. https://github.com/Alexpux/MINGW-packages/tree/master/ mingw-w64-gdk-pixbuf2 Thanks Ignacio, Forgive me for being dim - but how does that link help me? I just need to know if there are any specific techniques I need to know about (for example, some particular #defines that I'll need to use). And I'm building with MSVC by the way, not MinGW. Thanks again, John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk-pixbuf - more compilation woes with MSVC
Hi John, please yes file those issues in bugzilla, since they will get the proper attention faster. Also providing patches will make it even faster. Cheers. On Thu, Nov 6, 2014 at 5:31 PM, John Emmas john...@tiscali.co.uk wrote: I recently noticed this newly introduced statement at line 616 of 'gdk-pixbuf/io-jpeg.c':- density_str = g_strdup_printf (%d, DPCM_TO_DPI (cinfo.X_density)); There's a similar statement, a few lines further down. In 'gdk-pixbuf/gdk-pixbuf-private.h' we define DPCM_TO_DPI like so:- #define DPCM_TO_DPI(value) ((int) round ((value) * 2.54)) Unfortunately, MSVC doesn't contain 'round()'. Its closest equivalent function is probably 'floor()'. Can this be fixed? Also (while I'm at it) there's an unrelated problem at line 757 of 'gdk-pixbuf/io-tiff.c':- guint16 codec = strtol (compression, NULL, 0); Because we're building as 'C' (rather than C++) the variable 'codec' needs to get declared at the top of the function (along with all the other declarations). I can enter these problems into Bugzilla if that's preferable. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of gdk-pixbuf
Hi Bastien, for what is worth here are the pathes that we need to apply downstream on windows: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdk-pixbuf2 Regards On Thu, Oct 23, 2014 at 4:31 AM, Bastien Nocera had...@hadess.net wrote: Hey, I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling patches, and testing what was testable. The bugs left over basically fall in a few categories: - Bugs or feature requests in the loaders. There's quite a few of them that could probably be handled in minutes, or maybe in a couple of hours if one doesn't know a particular format. It would be great to have an OPW or GSoC project based on those. - API additions. A few of those for animation features which we might or might not want to support, quite a few for async versions of existing functions, or variants of existing functions (stream-based loading). - GDI loader bugs - Pixops bugs (Argh [1]) - Handling of huge images - Cairo interaction support The last 3 are related in that GdkPixbuf is a format that doesn't lend itself to handling big images (especially black and white pictures would balloon in memory usage), and that its coverage for acceleration in manipulation and compositing is small (basically unaccelerated on anything but 32-bit x86 and Solaris). I think we need to start looking at a replacement for pixops, and a replacement for the GdkPixbuf format. I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) Cheers PS: Now is a good time to look at your pet feature, dig in a little, and get your patches reviewed. [1]: https://bugzilla.gnome.org/buglist.cgi?product=gdk-pixbufbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=pixops [2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkOverlay - Move To
Hey, you don't need that, just listen to the signal for positioning the children and change the place. On Sat, Mar 2, 2013 at 11:41 AM, Pierre-Yves Luyten p...@luyten.fr wrote: Hi, I guess GtkOverlay would be a nice place to offer something like gtk_overlay_move_child_to (GtkOverlay *overlay, GtkWidget *child, GdkPoint *where_to_move_child) ? The child could have a slight animation from point A to point B. Unless there is already something like this, or, unless we don't want this since it's not a very common need. (A workaround is : remove from overlay, redefine allocation, re-add to overlay, ...). Seems more a design question than a technical one. Pierre-Yves ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Using gub for Windows / OS X binaries
Hi, you could try with gedit as it is suppose to run in osx and win32 and we already have some old binaries for it. Regards. On Tue, Dec 4, 2012 at 7:55 PM, Behdad Esfahbod beh...@behdad.org wrote: Hi, Has anyone around here considered using gub [1] to create GTK+ binaries / installers for Windows and OS X? Looks like an easy to use tool. It already has specs to build Lilypond and Inkscape. Which means, it already has spec'ed the GTK+ stack. Looks like it's a matter of letting it run for an hour every release. I'm bootstraping it right now. Will report back. [1] https://github.com/gperciva/gub Cheers, -- behdad http://behdad.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: win32 installer?
There is some beta one that you can ask to dieter. Regards. On Fri, Jul 13, 2012 at 9:20 AM, Murray Cumming murr...@murrayc.com wrote: Is anyone any closer to having a Windows installer for GTK+ 3 ready? -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GktTextTag::show-with-bling
Today I was chatting with tbf in the irc, about implementing something like: http://www.cidadedomoble.com/smultron/a.swf for gtksourceview. But finally he said that I should point this here as would be better implement it in gtk+ directly. Here you have the chat: nacho tbf, I think you kind of a cairo guru, any tip to make something like http://www.cidadedomoble.com/smultron/a.swf with cairo for gtksourceview? robtaylor nacho: shiny robtaylor nacho: should be doable with compositing nacho robtaylor, any example on how to make it with compositing? nacho no idea about developing with compositing stuff tbf nacho, robtaylor: this doesn't even need composition tbf nacho, robtaylor: i'd just create a GtkTextTag and use this information to do a regular animation tbf nacho, robtaylor: maybe even could be directly added to gtk+ by introducing some new GtkTextTag property tbf GktTextTag::show-with-bling robtaylor tbf: you're the expert :) nacho would be great amigadave GtkTexTag::pimp-my-tag nacho tbf, don't think is even neccessary create a tag, we have the start and the end iters, what I don't know is how to create the animation tbf nacho: well, but you want to keep that tag highlighted tbf nacho: so you need this anyway nacho the tag is already highlighted by gtk tbf nacho: didn't i just say, this bling probably should be directly added to gtk? nacho I mean when you select some text, that's already highlighted, I wanna add a func in gsv to select with effect tbf nacho: i'd suggest you raise this topic on gtk-devel-list nacho ok tbf nacho: especially as also the theme-engine guys would like to join the discussion murrayc Couldn't you just start a timeout callback that changed the color of the tag? nacho murrayc, that was I was thinking in the first place nacho but if tbf says that should go in gtk+ maybe it is better nacho less work to me tbf nacho, murrayc: first experiments could be done that way tbf nacho, murrayc: and the implementation in gtk would look similar murrayc yeah tbf nacho, murrayc: in the end my point just is, that i would be nice if that code would be done i a generic way ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
