Glade 3.19.0 Released!
Glade 3.19.0 is the first development release in the series. It comes with support for new widget classes like GtkSidebarWidget, GtkStack, GtkStackSwitcher, GtkHeaderBar, GtkSearchBar, GThemedIcon and GtkLockButton. This version of Glade depends on GTK+ 3.16.0, targets GTK+ >= 3.0 and is parallel installable with Glade 3.8 in case you also need to work with GTK+2 projects. What is Glade? Glade is a RAD tool to enable quick & easy development of user interfaces for the GTK+ 3 toolkit and the GNOME desktop environment. The user interfaces designed in Glade are saved as XML and these can be loaded by applications dynamically as needed by using GtkBuilder or used directly to define a new GtkWidget derived object class using Gtk+ new template feature. By using GtkBuilder, Glade XML files can be used in numerous programming languages including C, C++, C#, Vala, Java, Perl, Python,and others. Glade 3.19.0 - Bug 732328 "New: add python3 support" (Bohuslav "Slavek" Kabrda) - Added new symbolic variant of the app icon (747024 - Jakub Steiner) - Bug #741165 "Previewer crashes when taking PNG screenshot" - Added GtkSidebarWidget support (Matthias Clasen) - Added GtkStack and GtkStackSwitcher support (738480 - Matthias Clasen) - Added GtkHeaderBar support (bug 700914 - Matthias Clasen) - Improved undo/redo command list handling. - Added GtkBox center-widget support (bug 738473 - Matthias Clasen) - Added GtkSearchBar support (bug 738493 - Matthias Clasen) - Support CSD windows (Bug 700914 - Matthias Clasen) - Use current gtk-mac-integration API (bug 738339 - Philip Chimento) - Fixed bug 732575 "Changed the type hint on the "Edit Separately" window to 'utility'" (Tristan) - Fixed bug "Missing plural form for UI string: emited %d time(s)" - Avoid reading freed data in glade_project_read_requires (David Shea) - Added class chooser popover to workspace. (Bug 708146 "Catalog search entry") - Added GThemedIcon support. - GladePreviewer: show handler information in infobar when a signal is emited. - Migrated UI from stock icons to icon names. - Seal needed deprecated API and replaced deprecared API. - GladeWindow: only show found recent files. - Added GtkLockButton support. UI translations: === - bs, courtesy of Samir Ribic - ca, courtesy of Gil Forcada - ca@valencia, courtesy of Gil Forcada - cs, courtesy of Marek Černocký - da, courtesy of Ask Hjorth Larsen - de, courtesy of Christian Kirbach - el, courtesy of Tom Tryfonidis - es, courtesy of Daniel Mustieles - fi, courtesy of Lasse Liehu - fr, courtesy of Alain Lojewski - gl, courtesy of Fran Dieguez - hu, courtesy of Balázs Úr - id, courtesy of Andika Triwidada - it, courtesy of Claudio Arseni - ja, courtesy of Jiro Matsuzawa - kk, courtesy of Baurzhan Muftakhidinov - ko, courtesy of Changwoo Ryu - lt, courtesy of Aurimas Černius - lv, courtesy of Rūdolfs Mazurs - nb, courtesy of Kjartan Maraas - ne, courtesy of Pawan Chitrakar - oc, courtesy of Cédric Valmary (Tot en òc) - pl, courtesy of Piotr Drąg - pt_BR, courtesy of Enrico Nicoletto - pt, courtesy of Pedro Albuquerque - ro, courtesy of Daniel Șerbănescu - ru, courtesy of Yuri Myasoedov - sl, courtesy of Matej Urbančič - sr, courtesy of Мирослав Николић - sr@latin, courtesy of Miroslav Nikolić - sv, courtesy of Daniel Nylander - sv, courtesy of Josef Andersson - tr, courtesy of Muhammet Kara - zh_CN, courtesy of Yunqiang Su - zh_HK, courtesy of Chao-Hsiung Liao - zh_TW, courtesy of Cheng-Chia Tseng Where can I get it ? == http://download.gnome.org/sources/glade/3.19/ Direct Download === https://download.gnome.org/sources/glade/3.19/glade-3.19.0.tar.xz (3.24M) sha256sum: a7a3f6d32fbfcc9b754b48a3410bf025e462bc7898e124f0ad8f64c3d7ad6fa2 For more information on the Glade project see our home page at http://glade.gnome.org/ Enjoy, Glade Team ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
2015-06-11 22:30 GMT+02:00 Bálint Réczey : > 2015-06-11 15:34 GMT+02:00 Emmanuele Bassi : >> Hi; >> >> On 11 June 2015 at 14:28, Bálint Réczey 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. > I'm starting from https://git.gnome.org/browse/gtk3-build-system/ on a > CentOS 6.5 VM. > > I will check all the native/cross build systems posted on the list and > collect the patches if needed. > Thank you everyone for sharing your work. > To help native debugging I plan using cv2pdb, will see how it goes. > https://github.com/rainers/cv2pdb I see there are many patches hanging around in Bugzilla and external repositories. To finish and let others track this work more easily I have set up two repositories on GitHub since I don't have commit access to GTK+: https://github.com/rbalint/gtk https://github.com/rbalint/gtk3-build-system Feel free to send PR-s which would help fixing the Windows builds. New patches should also be sent to GTK+ bugzilla, _this is not a fork of the project_ just a place to collect patches. I will also merge/rebase progress from official gtk+ tree to have the patches merged in the meantime. It would be a great help from GTK+devs if you could check and accept/reject patches related to Windows currently waiting in Bugzilla. Cheers, Balint ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
2015-06-11 15:34 GMT+02:00 Emmanuele Bassi : > Hi; > > On 11 June 2015 at 14:28, Bálint Réczey 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. I'm starting from https://git.gnome.org/browse/gtk3-build-system/ on a CentOS 6.5 VM. I will check all the native/cross build systems posted on the list and collect the patches if needed. Thank you everyone for sharing your work. To help native debugging I plan using cv2pdb, will see how it goes. https://github.com/rainers/cv2pdb > >> 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 It did not help too much. What I would be interested in is the base reference system I should start implementing the missing pieces on. If CentOS 6.5 does not fit, please tell me. Cheers, Balint ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
Hi, On 06/11/2015 05:19 PM, Ignacio Casal Quinteiro wrote: Here you have: https://bugzilla.gnome.org/show_bug.cgi?id=620566 Please consider my patches on that bug report as superseded by the work in this mingw-w64 branch: https://github.com/dieterv/gobject-introspection/tree/mingw-w64 That branch basically makes g-i work reasonably well with MSYS2 (even make check passes on windows, yay). I am blocked on the "scanner: pass arguments through a file" patch though, as it breaks make distcheck on my linux machine with what seems to be a simple VPATH build issue. Haven't found a solution in over a month's free time of hacking though :/ Any insights, pointers, appropriate doses of cluebat (please do avoid the head though) will be most appreciated ;) mvg, Dieter ___ 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 > 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 >> 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 >> wrote: >> >> > Hi; >> >> > >> >> > On 11 June 2015 at 13:44, anatoly techtonik >> wrote: >> >> >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi >> >> >> 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. >> >> >>
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 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 > 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 > wrote: > >> > Hi; > >> > > >> > On 11 June 2015 at 13:44, anatoly techtonik > wrote: > >> >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi > >> >> 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
Re: Outdated win32 bundle
I can take a look at the gobject-introspection work. Bugzilla links? On Thu, Jun 11, 2015 at 10:57 AM, Ignacio Casal Quinteiro wrote: > > > On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre > 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 wrote: >> > Hi; >> > >> > On 11 June 2015 at 13:44, anatoly techtonik wrote: >> >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi >> >> 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/mailm
Re: Outdated win32 bundle
On Thu, Jun 11, 2015 at 4:51 PM, Jasper St. Pierre 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 wrote: > > Hi; > > > > On 11 June 2015 at 13:44, anatoly techtonik wrote: > >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi > 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 _
Re: Outdated win32 bundle
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. On Thu, Jun 11, 2015 at 9:15 AM, Emmanuele Bassi wrote: > Hi; > > On 11 June 2015 at 13:44, anatoly techtonik wrote: >> On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi 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-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
> On Jun 11, 2015, at 6:22 AM, Emmanuele Bassi wrote: > > Hey; > > On 11 June 2015 at 14:19, Ignacio Casal Quinteiro > 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. ;-) If you object to using Qt’s installer there’s Inno-setup, http://www.jrsoftware.org/isinfo.php. GnuCash has been using it for many years. Regards, John Ralls ___ 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 wrote: > Hi; > > On 11 June 2015 at 14:28, Bálint Réczey 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
Hi; On 11 June 2015 at 14:28, Bálint Réczey 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
Re: Outdated win32 bundle
Hi Emmanuele, 2015-06-08 20:22 GMT+02:00 Emmanuele Bassi : > Hi; > > On 8 June 2015 at 19:02, Bálint Réczey wrote: >> Hi Daniel, >> >> 2015-06-07 16:57 GMT+02:00 Daniel Espinosa : >>> Please use at least Gtk+ 3.14.9 because it fixes a bug on GtkFileChooser to >>> access Desktop directory. >> I plan starting with 3.16, but got no response so far regarding my >> request to access the build system. > > Likely because you're using gtk-list@, which nobody in the GTK team > follows (except, I think, me). > > Thanks for your offer of taking over the build on Windows. > > 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. > > 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. > > 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. Great, this was my plan. Having the CI system in place I would like to revive the binary bundles as well. > > 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? Is there any documentation on the GTK+ CI system? Cheers, Balint ___ 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 wrote: > Hey; > > On 11 June 2015 at 14:19, Ignacio Casal Quinteiro > 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 > wrote: > >> > >> Hi; > >> > >> On 11 June 2015 at 13:44, anatoly techtonik > wrote: > >> > On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi > >> > 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
Hey; On 11 June 2015 at 14:19, Ignacio Casal Quinteiro 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. ;-) Ciao, Emmanuele. > On Thu, Jun 11, 2015 at 3:15 PM, Emmanuele Bassi wrote: >> >> Hi; >> >> On 11 June 2015 at 13:44, anatoly techtonik wrote: >> > On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi >> > 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] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Outdated win32 bundle
Hi; On 10 June 2015 at 21:13, Stefan Salewski wrote: > On Mon, 2015-06-08 at 19:22 +0100, Emmanuele Bassi wrote: >> > I plan starting with 3.16, but got no response so far regarding my >> > request to access the build system. >> >> Likely because you're using gtk-list@, which nobody in the GTK team >> follows (except, I think, me). > > Interesting info -- indeed I had that feeling during the last years, and > I think for gtk-app-devel list situation is not really better. So, > whenever I should have a question regarding GTK and need a smart answer, > I will ask my grandma. ;-) Questions regarding the development *of* GTK go to gtk-devel-list. It's been like that for more than 10 years. Questions regarding the development *with* GTK can go to gtk-list or gtk-app-devel-list. Mailing list do suck for timely responses, though; so if you want to ask and get a reply you should probably join IRC — irc.gnome.org, #gtk+ channel. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 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 wrote: > Hi; > > On 11 June 2015 at 13:44, anatoly techtonik wrote: > > On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi > 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
Hi; On 11 June 2015 at 13:44, anatoly techtonik wrote: > On Mon, Jun 8, 2015 at 9:22 PM, Emmanuele Bassi 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
