Re: Gtk+4.0
Hi, On 21/06/16 16:26, Peter Weber wrote: > I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to > write about my thoughts, in a careful way. In the first moment, I thought > this is a good idea and just the numbering is misleading. Stability is what > developers want, we need it, we love it. With a few days distance, > numbering is just a small issue, I see this now entirely different and > three major issues: Here are some thoughts I have about all this, from a downstream maintainer POV. My concern with this new scheme is that GTK+ libraries will have to bump the soname every 6 months (if they want to support the latest GTK+). That can be manageable for say vte or gnome-desktop, although it may be bad if some third party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for GTK+ 4.4, as then distros would need to ship an increasing number of versions that are unlikely to get any support upstream. But do you expect WebKitGTK+ to bump the ABI every 6 months? I feel like the X.[024] releases are just snapshots of a development branch, with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly be labelled as that, regardless of what version number is chosen (be it 4.0, 3.99.0, 4.0beta1 or whatever). Cheers, Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: where i find a manual for write a wm in gtk3 ?
On 27/02/14 00:20, Emmanuele Bassi wrote: > hi; > > you really cannot use GTK+ to write a window manager. > > to be absolutely, brutally honest with you, you should not write a > window manager *at* *all* — not even a little one. > > if you want to experiment with window management policies, I suggest > you look at Wayland and Weston, and ignore as much as possible X. you > won't be able to write a window management plugin for Weston with GTK+ > either, but at least your sanity will be saved. You can write the shell client with gtk+, see https://github.com/tiagovignatti/gtk-shell although all the stacking and window logic live in a different place, the shell module. Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkMenu padding - need an alternative for providing an offset
Hi, On 30/10/13 01:10, Michael Webster wrote: > Apologies if this has been brought up already... > > This patch: > > https://git.gnome.org/browse/gtk+/commit/gtk/gtkmenu.c?id=01dc23cdec377c9d9897cc32bf28ec1d241b29fa Is it just me or all these changes we've recently made are not 'deprecations' but ABI breaks? If foo_frobnicate() changes from doing something useful to being a nop, we're breaking our interface, whether we keep the symbol in the DSO or not. GObject properties are no different. Don't get me wrong, I'm not against this kind of changes. But I'd rather see us keep compatibility until GTK+ 4 is out than (rightfully) piss off our users because of changes like this. Regards, Emilio > > deprecated GtkMenu-horizontal-padding and GtkMenu-vertical-padding, > suggesting that CSS padding is used instead. The problem is that these two > values were commonly used to provide a slight 'nudge' to context menus to > prevent the first item in the menu from being automatically highlighted > (and possibly inadvertantly selected) when the context menu appeared under > the pointer. > > With this deprecation, we can no longer do this - and adding more padding > is simply compensated for in the positioning code, so that first menu item > is always selected. > > It would be nice to have some sort of either gtk setting or even hard-code > in 1 or 2 pixels of extra position in X and Y to avoid this situation, > which could be very frustrating to deal with. > > Thanks > > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: non-Linux OSes
Hi, On 23/10/13 18:40, Colin Walters wrote: > When I read this again I realized my previous mail had a bad tone...what > I really wanted to say is: Thanks for your answers. I didn't take them in a bad way at all. > I think InstalledTests is a natural evolution of "make check" that is > far more powerful and flexible, and I'd really love to see Debian and > other projects making use of it. Absolutely. I think your work in CI / installed-tests / OSTree is great, and I'd love to do some of that in Debian. We are starting to package installed tests, which would make it easier to do CI with jenkins or similar. But I haven't had the time to look into this or think about it much. I pointed out the Debian builds with `make check' executions because this thread was specifically about non-Linux OSes and non-standard compilers (and I extended it to not-so-common architectures). Until we have CI running on that variety of platforms, I think the Debian builds may be useful to some extent. > Specifically in helping narrow down which specific individual tests on > which architectures are failing and how often is a lot more efficient > than the all or nothing model of "make check" on an autobuilder once a > month or something when a new version of a GLib tarball is uploaded. Totally agreed. Regards, Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: non-Linux OSes
Hi,
On 21/10/13 10:34, Ryan Lortie wrote:
> hi,
>
> GLib aims to work on a wide range of operating systems, but we have no
> good story for ensuring that this is the case. Mostly we do things for
> Linux and, if they are the sort of thing that may cause problems, we
> also check that they work on Windows. We read manpages and make sure
> that the functions we are using are in the proper POSIX specs, but this
> is not always a fool-proof process.
>
> We want to improve this situation.
>
> Dan recently started by doing some patches to pull out ancient support
> for OSes like OS/2 and BeOS.
>
> We have brainstormed a list of platforms that we think that we want to
> support and it looks like so: Linux, {Free,Net,Open}BSD,
> (Open?)Solaris, HP-UX, AIX, Hurd, Darwin, mingw(32/64), MSVC.
>
> There is also the question of non-standard compilers (icc?).
>
> What we don't have are the resources to setup routine testing of GLib
> against these target operating systems. Some of these operating systems
> are not Free Software.
>
> What would be nice is if we could gain access to some machines (from
> various projects) that we could use for testing GLib and/or if we could
> get a VM farm setup on GNOME infra that various projects would help us
> to setup (and maintain) their OSes on.
>
> I don't have any concrete ideas here, but it seems like there are some
> good options. If anyone has ideas or offers of help, they are greatly
> appreciated.
In Debian we build glib for several architectures (including x86, amd64,
armel/armhf, ppc, sparc...), for GNU/kFreeBSD on amd64 and x86, and for GNU/Hurd
on x86. We currently run the testsuite only on linux (and we make test suite
failures cause the build to fail).
We try to build development snapshots in experimental (though right now 2.38 is
there as we haven't had the time to fix the regressions and upload to
unstable/testing).
Build logs/status can be checked from:
https://buildd.debian.org/status/package.php?p=glib2.0&suite=unstable
https://buildd.debian.org/status/package.php?p=glib2.0&suite=experimental
Even more 'unofficial' architectures are available from
http://buildd.debian-ports.org/status/package.php?p=glib2.0&suite=sid
As you can see 2.36 successfully ran the tests on all those 11 linux
architectures. 2.38 needs a bit of work but I haven't had the time to look at it
yet. Help there is more than welcome! (Note that sometimes test failures are
just race conditions because the tests run on loaded/slow machines).
If a developer needs/wants access to a box for any of those architectures for
the purposes of debugging/fixing some GNOME software I may be able to help on a
case-by-case basis.
Note that we try to do the same thing (run the testsuite, make test failures
fatal) for other GNOME packages, so this doesn't just apply to glib.
Hope this helps.
Regards,
Emilio
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
On 15/06/10 11:01, Tor Lillqvist wrote: > Well, not only GTK+, but presumably then also everything else under it > in the stack, otherwise it would be a rather pointless exercise, > wouldn't it? I am fairly sure it doesn't work out-of-the-box. I have > never tried. We build GTK+, GLib, Pango and Cairo statically in Debian. We have a couple of patches for building GTK+ statically though: http://bugzilla.gnome.org/show_bug.cgi?id=346531 http://bugzilla.gnome.org/show_bug.cgi?id=346559 Cheers, Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: disabling GTK+ features to shrink GTK+
On 15/06/10 09:26, Tor Lillqvist wrote: > Not out-of-the-box currently, but working on that would be a better > idea, and enabling statically building the GTK+ stack would have a > better chance of getting upstream. You can already build GTK+ statically, can't you? Or doesn't it work on Windows? Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the gtk+ team IRC meeting - 2010-06-08
Hi, On 09/06/10 00:49, Emmanuele Bassi wrote: > • how to deal with gtk-requiring libraries, with regards to the API/ABI break > - libraries will have to do an ABI bump to match the ABI bump in gtk > - we need to communicate this on the various venues and remind the maintainers > ACTION: mclasen to draft a mail for gtk-devel-list/desktop-announce Forgive me if I misunderstood it, but isn't this the sort of thing that would be avoided if GTK+ used symbol versioning? If so, using it from 3.0 onwards may be a good idea. Cheers, Emilio ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
