Strict aliasing, yes or no?
Just wondering what the position on this is. I've seen a few conflicting indications: (1) The new meson patches pass -fno-strict-aliasing to GCC and Clang: https://git.gnome.org/browse/gtk+/commit/?h=wip/meson&id=1e3daf3178bb3db56ab12a55195969857f685101 The rationale is "We don't want to build buggy code." Well, technically, code that relies on aliasing is inherently buggy from the outset, because that violates the standard. Assuming that's not something you strive for, the next bit is worse: I can't see an equivalent directive for MSVC. Surely this means, without forcing the compiler to make aliasing well-defined, code that relies on aliasing is free to start wildly bugging out on MSVC at any time? (2) The Autotools build files do not seem to pass this flag, indicating that avoidance of strict aliasing was not a requirement. (3) There's this old bug (and possibly others) to remove aliasing violations: https://bugzilla.gnome.org/show_bug.cgi?id=140722 So, which is true? Do we want to forbid breaking strict aliasing rules, or do we want to require compilers that allow us to override the Standard and rely on aliasing violations? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 156, Issue 11
On 19 April 2017 at 13:00, wrote: > > Message: 4 > Date: Wed, 19 Apr 2017 12:21:06 +0100 > From: Simon McVittie > To: gtk-devel-list@gnome.org > Subject: Re: Strict aliasing, yes or no? > Message-ID: > <20170419112106.rfk2oxs5vfdn4...@archetype.pseudorandom.co.uk> > Content-Type: text/plain; charset=us-ascii > > On Tue, 18 Apr 2017 at 23:05:04 +0100, Daniel Boles wrote: > > Well, technically, code that relies on aliasing is > > inherently buggy from the outset, because that violates the standard. > > Not relying on aliasing forbids casting between dissimilar types, which > rules out "normal" C tricks like casting between GArray and GRealArray > (where GRealArray starts with the same members as GArray) as a way to have > a partially-opaque struct, or an opaque-other-than-size struct on the > stack; > so regardless of whether it might be desirable to be writing Standard > C, I'm not sure that GLib can do that without breaking its API. > Hmm, fair point, I wasn't aware of types like that yet. > It is also not particularly clear from ISO/IEC 9899:201x draft N1570 (which > is essentially the same document as Standard C, but without the > price tag) whether the usual C pseudo-object-orientation idiom[1] (which > is a fairly fundamental part of GObject) is considered to be valid in > Standard C. In general, the aliasing rules are not well-understood, > so it is pragmatic to disable aliasing-driven optimizations in code that > is not CPU-bound. > I think this is well-defined: AFAICT, it is specifically allowed to cast between pointers to SomeStruct and SomeOtherStruct whose first member is a SomeStruct. Put more simply: pointers to structs and pointers to their 1st member are considered to be interchangeable for aliasing purposes - AFAIK. > Most of GNOME is written in pragmatic C (whatever works in gcc and clang > on CPUs that are used in the real world, sometimes with the additional > constraint of also working on MSVC/Windows/x86), not in Standard C. For > instance, standard C doesn't guarantee that 8, 16, 32 and 64-bit types > exist (it only mandates the names like int32_t if such types already > exist!), but GLib requires a type of each of those sizes. Standard C > doesn't > guarantee that a pointer with all bits zero is NULL, but GLib libraries > (and probably GLib itself) commonly require that. There are plenty more > examples, many of them things that a typical C programmer is likely to > assume to be always true even though Standard C does not actually > guarantee it. > Yeah, I figured there would be things like this. I just wasn't sure whether strict aliasing was such a requirement, or whether we could get by without out. I guess not :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 3
On 3 May 2017 at 13:00, wrote: > From: Murray Cumming > To: Timm B?der > Cc: gtk-devel-list > Subject: Re: gtk4: gtk_box_pack_start()/end() porting > Message-ID: <1493810933.18452.1.ca...@murrayc.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, 2017-04-28 at 17:50 +0200, Murray Cumming wrote: > > On Fri, 2017-04-28 at 17:20 +0200, Timm B?der wrote: > > > I've added notes about the fill and expand child properties to the > > > migration guide: > > > https://git.gnome.org/browse/gtk+/commit/?id=bb1deaafa42ccb03929d3c > > > d5 > > > fdab685218bbac29 > > > > Thanks. I guess it's that last part about hexpand/vexpand affecting > > the > > parent widgets too that explains what I've seen so far. So there is > > really no simple mapping from the old API to the new API. Porting is > > going to be rather awkward. > > Have some container widgets changed, or lost, some default > spacing/padding/margins too? For instance, it looks like GtkActionBar > used to have some hard-coded spacing between its child widgets (added > via gtk_action_bar_pack_start()), but not with gtk4. > Based on some commits I remember seeing, I think the new policy is that widgets should not enforce such properties. Which, IMO, is a good thing, though again potentially a pain for porting. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 4
> > Date: Wed, 03 May 2017 15:45:14 +0200 > From: Murray Cumming > To: Timm B?der > Cc: gtk-devel-list > Subject: Re: gtk4: gtk_box_pack_start()/end() porting > Message-ID: <1493819114.24525.3.ca...@murrayc.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2017-05-03 at 15:45 +0200, Timm B?der wrote: > [snip] > > [1]Even though spacing *should* probably be handled by the theme, so > > the > > theme can decide whether UIs are more spacey or more narrow, nobody > > has > > come up with a proper way for applications to specify that. > > Yes, I've never liked how applications have all these magic values > sprinkled through their code. > > Thanks for the explanation. > > -- > Murray In case anyone is interested in my anecdote... I'm using GTK+ 3 (for the forseeable future) but have stopped using widget :margin and :spacing - juuust in case they get removed at some point in the future. There's a general trickle of things like that being removed from the widget side, so better safe than sorry. Doing these in CSS instead - while it involves some horrifying hacks that almost certainly break some cases, which I don't use yet - does mean that I can use relative units like em for spacing out my UI. That said, this also means that (unless I start generating CSS providers on the fly) I have to know in advance which levels of spaciness I want and define them as CSS classes. But, whatever the limitations may be, this is working for me right now, and it's liberating both in the sense of cleaning up my source code and scaling far better with changes to font size, DPI, etc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 4
On 4 May 2017 at 10:44, Daniel Boles wrote: > > I'm using GTK+ 3 (for the forseeable future) but have stopped using widget > :margin and :spacing - juuust in case they get removed at some point in the > future. There's a general trickle of things like that being removed from > the widget side, so better safe than sorry. > Course, I meant removed from GTK+ 4. While I'm still focussing on GTK+ 3, I'm trying to spot obvious changes that 4 will need, which I can do now in 3, to make the task of porting far less painful when it comes around - especially if things look like candidates for being removed. Plus, even if they're retained, usually the newer way is better and worth doing anyway. If I were using GTK+ 4, the new CSS border-spacing property for Box and Grid would avoid the need for the (horrifying but surprisingly functional) way that I hack it into GTK+ 3. It would be really nice to see that being added in 3, but I'm guessing that's unlikely... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 16
I can't speak for any maintainers, but I suspect that constantly pinging like this does not have any significant - or at least significant *positive* - effect on the chance of the tickets being bumped forward in the queue. I believe that pinging is generally discouraged, especially when you do it across channels like this, i.e. not *at least* confining the pinging to Bugzilla. Remember that contributors have many other things they are working on, and those who happen to see these messages may not have specific enough knowledge to make a decision one way or another. Also, all of this is done completely for free, so there's that too. On 25 May 2017 at 13:00, wrote: > Today's Topics: > >1. Re: gdk-pixbuf: Add IANA registered image/emf and image/wmf > (Ingo Br?ckl) >2. Re: Bug 554926 still in 2.24.31 (Ingo Br?ckl) > > > -- > > Message: 1 > Date: Thu, 25 May 2017 10:47:50 +0200 > From: Ingo Br?ckl > To: gtk-devel-list@gnome.org > Subject: Re: gdk-pixbuf: Add IANA registered image/emf and image/wmf > Message-ID: <59269c96.301d883f.bm...@wupperonline.de> > Content-Type: text/plain; charset=ISO-8859-1 > > > Please see > > > https://bugzilla.gnome.org/show_bug.cgi?id=782390 > > Ping? > > These media types are being used by shared-mime-info for over 8 months. > > Ingo > > > -- > > Message: 2 > Date: Thu, 25 May 2017 10:55:40 +0200 > From: Ingo Br?ckl > To: Matthias Clasen > Cc: gtk-devel-list@gnome.org > Subject: Re: Bug 554926 still in 2.24.31 > Message-ID: <59269c96.09c4a12e.bm...@wupperonline.de> > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, 25 Apr 2017 13:38:22 +0200, I wrote: > > > Please apply commit e3bd926c1ef83027c756488ba19f4353930fc6db to current > > GTK+ 2 (2.24.31) where it is missing. > > > The bug has been described in > > > https://bugzilla.gnome.org/show_bug.cgi?id=554926 > > > and has been fixed on Tue, 10 Aug 2010 04:13:22 + (UTC) in 2.90.5. > > Someone please apply and fix it. > > Ingo > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 157, Issue 18
On 28 May 2017 at 13:00, wrote: > > Message: 1 > Date: Sun, 28 May 2017 10:55:21 +0800 > From: Cong Monkey > To: gtk-devel-list > Subject: will gobject-introspection build system migrate to cmake or > meason in the future? > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi, > > I am a fun of python and gtk, I want to port gobject-introspection > to windows, the current manul update VS project make upstream a little > hard. > > Will gobect-introspection migrate to a modern and cross platform > friendly solution like cmake or meason in the near future? > If one considers "cross platform" to include MSYS2, which provides Linux-like build tools but (unlike Cygwin) produces native Win32/64 binaries, then the current system already qualifies. MSVC is not the only game in town. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Fwd: gtk-devel-list Digest, Vol 157, Issue 18
On 30 May 2017 at 05:44, Cong Monkey wrote: > use msys2 in a massive visual studio based product is not a good idea, > Who ever said to do anything like that? My point is MSYS2 is a near-complete Unix-like build environment, under which you can simply build a native executable using the Autotools setup. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 554926 still in 2.24.31
> > Date: Sat, 02 Sep 2017 21:10:56 +0200 > From: Ingo Br?ckl > To: gtk-devel-list@gnome.org > Subject: Re: Bug 554926 still in 2.24.31 > Message-ID: <59ab0245.000ac05b.bm...@wupperonline.de> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > after a few months have passed, a new reminder. > > In the meantime, there is a ready-to-apply git patch: > > https://bugzilla.gnome.org/show_bug.cgi?id=785165 > > Ingo This was just reviewed and pushed. Thanks for the patch! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)
On 5 October 2017 at 10:46, Jean Delvare wrote: > > * While a number of people are advocating the ban of double-click and > the use of single-click for everything to make computers easier to > use by non-tech-savvy people and people with limited abilities, > this change does not even achieve that. > Right. It doesn't help to enable single-clicking inconsistently, only if the item is already selected, thus being confusing and irritating when you open something you didn't want to, or find you can't single-click to open anything except the 1st item in the list. I find it perplexing how this was considered to improve anything. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)
I apologise if there is, if I just blocked most of that thread out of my mind... but is there really a significant number of users out there who had these complaints about double-click and genuinely think what we have now is an unambiguous improvement? rather than just an apparent, superficial fix in one scenario (single-clicking on the pre-selected top item) compensated by regression everywhere else. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)
> > From: "Charles Lindsey" > To: gtk-devel-list@gnome.org > Subject: Re: [PATCH] file chooser: Restore consistent click behavior > (for gtk3.20) > It seems to me that those who are developing GTK are answerable to no-one, > and it they continue to behave in this way, we shall simply all be forced > to switch to QT. It is ridiculous that they are pressing ahead with GTK4 > at a time when several exceeding important applications had not even > switched to GTK3 (and I am beginning to see why). The file changer in > these applications will remain as it is, so that everyone will find > different windows which look the same behaving entirely differently. It is a non sequitur to say that developing a new major version should not be allowed because some users are still on the previous stable version. It is equally irrelevant to completely omit the fact that the current stable version is now LTS and seeing more and more applications, DEs, etc moving across to it. Having a separate bleeding-edge development branch is a precondition for having a really stable one, and now that exists. So, that problem was solved. Yet apparently, somehow there are those who want to construe the solution as a problem in itself... And as always, just complaining about the development means very little when so few of the complainers ever contribute any resources to improve the state of things. If you want to change the focus of "those who are developing GTK", become one. That's all kinda separate from the original topic, which I still think should just be reverted until it's done properly, but anyway. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 162, Issue 7
By my understanding, the explanation is this: - the Entry *is *right-aligned within its cell - but then the Grid is set to align fill and expand, so it expands empty space beyond the Entry and the cell it's in Assuming I understand this guide right, then it does kinda make sense to me. https://developer.gnome.org/gtk3/stable/ch30s02.html I found that hexpanding the Entry too got around this, but it may not be exactly what you want. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkGrid children and GTK_ALIGN_END
On 12 October 2017 at 13:10, Daniel Boles wrote:
> By my understanding, the explanation is this:
>
>- the Entry *is *right-aligned within its cell
>- but then the Grid is set to align fill and expand, so it expands
>empty space beyond the Entry and the cell it's in
>
> Assuming I understand this guide right, then it does kinda make sense to
> me.
>
> https://developer.gnome.org/gtk3/stable/ch30s02.html
>
> I found that hexpanding the Entry too got around this, but it may not be
> exactly what you want.
>
since a test case is always useful...
#include
int
main (intargc,
char **argv)
{
gtk_init (&argc, &argv);
GtkWidget *grid = gtk_grid_new ();
gtk_widget_set_hexpand (grid, TRUE);
gtk_widget_set_halign (grid, GTK_ALIGN_FILL);
gtk_orientable_set_orientation ((GtkOrientable *)grid,
GTK_ORIENTATION_HORIZONTAL);
GtkWidget *entry = gtk_entry_new ();
gtk_widget_set_halign (entry, GTK_ALIGN_END);
gtk_container_add ((GtkContainer *)grid, entry);
GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_container_add ((GtkContainer *)window, grid);
gtk_widget_show_all (window);
gtk_main ();
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkGrid children and GTK_ALIGN_END
The wildcard here, and what makes me confused as to whether my own rationale makes sense, is that you have the grid expanding; I can't immediately think of cases where I've used such a construct, so I don't know what I expect it to do! It's also been a while since I thought about how alignment and expansion interact - I think once you get your program to a point where it works, the brain begins to remove that information ;) - so I don't know if anything I've said makes much sense, and would like an opinion from someone else. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: webassembly
I don't think we can say Broadway is "dead in the water"; there's a current WIP branch for GTK+ 4 with new features and fixes. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why these settings are deprecated?
On 27 December 2017 at 12:00, wrote: > Date: Tue, 26 Dec 2017 21:06:30 +0100 > From: Tomasz G?sior > To: gtk-devel-list@gnome.org > Subject: Why these settings are deprecated? > Message-ID: <6a0eec5c1bd9e4136a033a6c82c38...@tomaszgasior.kao.pl> > Content-Type: text/plain; charset=UTF-8; format=flowed > > I would like to ask question directly to main GTK developers. Why these > Xsettings are deprecated? > Although in this case you got a very detailed answer, I'd like to suggest that it is usually better to check resources like the migration guides, "git blame", etc. to track down the rationale for decisions - instead of expecting that a developer will always see your post and have time or desire to directly explain so many things in precise detail. Sure, that takes a bit longer as a user, but the alternative is that developers have to spend time constantly relitigating past decisions, which at its extreme would mean they'll have no time to develop. :P ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Build Gtk+ by Meson with locally installed Glib
I'd think the simplest option is to put your local GLib in your PATH with higher priority, so that the non-absolute invocation of g-c-r finds your one instead of the system one. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk-devel-list Digest, Vol 166, Issue 9
On 8 February 2018 at 12:01, wrote: > Message: 2 > Date: Wed, 07 Feb 2018 13:45:47 +0100 > From: Christian Schoenebeck > To: gtk-devel-list@gnome.org > Subject: gtk_menu_item_set_accel_path() > Message-ID: <1582692.dYf0dnMCMj@silver> > Content-Type: text/plain; charset="us-ascii" > > Hi! > > I am currently debugging gtk_menu_item_set_accel_path(): when using that > function then keyboard accelerator key(s) are not displayed in the menu > item > at all. Has anybody looked into this bug before? > > What I found out so far is that the the menu item's > > GtkAccelLabel->priv->accel_string > > and > > GtkAccelLabel->priv->accel_string_width > > are correctly updated with the expected textual representation of the > keyboard > accelerator key(s) (i.e. "Ctrl c", "F1", etc.), however the menu item's > GtkAccelLabel would never be displayed on screen. > I think we'd need to see precisely how you're setting up this MenuItem to do anything other than speculate wildly. But note that the doc description indicates you're expected to set the accel shown yourself, rather than that the MenuItem will automatically show one if it's available: https://developer.gnome.org/gtk3/stable/GtkMenuItem.html#GtkMenuItem.description I see no indication in gtkmenuitem.c that it ever manages the displayed accelerator for the user. If you're using some other means of creating MenuItems, we need to know what that is, to say whether or not that method should be doing this for you automatically. > Also the menu item's size is not updated either. By default, when > displaying a > menu item without any action/accelerator, the size (more specific: its > width) > of the menu item is limited to the menu item's main text label. And when an > action with keyboard accelerator is assigned to the menu item, the size of > the > menu item is enlarged to display the acceleration label as well. The latter > never happens when using gtk_menu_item_set_accel_path(). Isn't this a tautology? Why would the size be updated for an accelerator that is not being shown...? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK3 - GtkExpander problem, bug ?
On 6 March 2018 at 18:26, wrote: > Message: 1 > Date: Wed, 13 Dec 2017 03:16:59 +0100 > From: S?bastien Le Roux > To: gtk-app-devel-l...@gnome.org, gtk-devel-list@gnome.org > Subject: GTK3 - GtkExpander problem, bug ? > Message-ID: <7a7f900f-a7e5-8ed3-3fa8-867568087...@ipcms.unistra.fr> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear all thanks in advance for reading this, > > I wrote a piece of code in GTK3, and I might have found an issue with > the GtkExpander widget, > shorter than a long text explanation, I attach to this email a screen > capture from a window from my program. > This window contains a bunch of GtkExpander, inside each a > GtkScrolledWindow that contains a GtkFixed, > each GtkFixed contains a series of GtkToggleButtons. (I can have a lot > of buttons piled up in there). > I tried several container widget other than the ScrolledWindow, but it > is the only one that offers to browse > the entire button list that my program will create. > > The first time, I open/close one of the GtkExpander (1) everything works > fine, the button are working fine, > then if I open/close another GtkExpander (2) and re-open the first one I > lose information regarding the buttons, > some stop to function, for other the pointers for the callback are > damaged and the function will not work properly afterwards. > I noticed that I could even recall buttons located in the other expander > (2), basically at the location they were > appearing on the window before having expander (2) closed, like if the > two sets of buttons from the 2 expanders > ?were overlapping/sharing positions somehow. > > So there is no GTK signal used in all this window excepted for the > buttons, and a simple 'play' with the expanders > is messing everything up ... GDB and VALGRIND are not giving me any > error so ... > I figured that this was out of my skill range, hence this email. > > > I also attach to this message a piece of code to illustrate how I > generate the window from my picture, the part > the generate the button is missing but that it too big to included in > this message. > > Finally I want to add that the almost the exact same code works just > fine with GTK2 ... if that helps. > > Thanks in advance for you help. > > Best regards. > > -- > === > Dr. S?bastien Le Roux > Please always mention your GTK+ exact version when reporting bugs. This sounds like a problem or two that I fixed a few point releases ago, probably 3.22.25 or so. What version is yours? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk on windows 10
On 11 March 2018 at 12:00, wrote: > Date: Sat, 10 Mar 2018 15:19:06 +0100 > From: Luca Bacci > To: gtk-devel-list@gnome.org > Subject: Re: gtk on windows 10 > Message-ID: > yq5f...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Kasper, > > As Allin said, you can get really good results if you stick with Gtk2 and > use MS-Windows theme and libwimp.dll engine. > You can get results that *some* people might think *look* "really good". That aside, I don't think advising sticking with GTK+ 2 makes for good advice. Why not, instead, get someone interested in using a modern version of the toolkit - perhaps even enough that they will look into maintaining a theming engine that will provide what they want? Fwiw, I do use GTK+ on Windows semi-frequently, but (A) I'm probably a minority there and (B) I actually *like* that it has its own theme, so I don't have to make theming changes targeting 2 different look-and-feels. I wonder if these 2 points aren't part of the reason that Windows-style theming has apparently fallen by the wayside a little. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: double_buffered and scrolled_window
On 16 April 2018 at 11:15, wrote: > > Regarding, the gestures, is there a tutorial of how to use them? The > CustomWidgets tutorial mentions them, but then goes on to describe the > button and motion notify events. > https://wiki.gnome.org/HowDoI/Gestures - to which I'll now add a link on the widget one. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug in gobject-introspection
On 6 May 2018 at 12:25, wrote: > I have gobject-introspection-1.50.0-1.el7.x86_64 and gobject- > introspection-devel-1.50.0-1.el7.x86_64. I tried to use a program like > "menulibre" and "devedeng" and the developers say there is a bug in > gobject-instrospecition. Thanks for any help! > I'm baffled by how you think anyone can do anything with such a vague report. What exactly happened when you tried to run those programs? What specific problem did the developers describe? Where is the link to the place where they did so? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Demo/Sample for drag and drop
I found these quite good (even though I wasn't using ListBox; they can be generalised) https://blog.gtk.org/2017/04/23/drag-and-drop-in-lists/ https://blog.gtk.org/2017/06/01/drag-and-drop-in-lists-revisited/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
