GTK meeting notes

Minutes of the GTK team meeting of January 7, 2019 Agenda: - Update on the GTK Hackfest after FOSDEM - Current state of GTK4 branches - Revert of A11Y focus changes in stable branches - Releases? Notes 1) Hackfest Venue is booked We have a wiki page Sufficient attendence confirmed

OS X issues

Hey John, since you are one of our OS X contributors: It seems the 2.24.2 release from this week has some issues on OS X: https://gitlab.gnome.org/GNOME/gtk/issues/1517 https://gitlab.gnome.org/GNOME/gtk/issues/1518 We could really use your help here! I'd like to do a follow-up release before

Re: Quartz Coordinates

On Tue, Nov 20, 2018 at 8:06 AM John Ralls wrote: > I’m working on GdkQuartz to bring it up to date with the rest of Gdk. I’m > starting with GdkDisplay and GdkMonitor mostly because of > https://gitlab.gnome.org/GNOME/gtk/issues/1312. This question may also > bear upon

GTK meeting notes

At long last, another GTK team meeting! See notes below. Matthias --- Minutes of the GTK team meeting of December 10th, 2018 Agenda - Welcome EmmanueleBassi - - GTK Hackfest at FOSDEM (or some other time/place ?) - - Listfest at FOSDEM - - 3.26 for

A pango update

Pango development has been slow in the last few years, while most of the work on the text rendering stack has moved to harfbuzz. But recently, Behdad and I got together for a pango work day, and made some plans, which we want to share. The underlying goal of these changes is to ensure that GTK+

Re: About Gtk4, modules and GlobalMenu approach

On Tue, Jun 5, 2018 at 6:57 AM, Konstantin P. wrote: > I am a developer of GlobalMenu applets for XFCE, Mate and Budgie. Also I > maintain appmenu-gtk-module and Jayatana. > I heard than you removed general purpose loadable modules support, so, I > cannot alter GtkMenuBar and GtkWindow to

Re: widget accessibility roles: being able to override it

On Mon, Mar 19, 2018 at 10:19 AM, Samuel Thibault wrote: > Hello, > > Samuel Thibault, on lun. 05 mars 2018 16:17:24 +0100, wrote: > > Some dialog boxes use labels for static information, e.g. printer > > status, replace result, etc. For the screen reader to properly > >

Re: GTK_MODULES removal and the future of existing modules

On Sun, Feb 25, 2018 at 4:11 AM, Philipp Emanuel Weidmann < p...@worldwidemann.com> wrote: > Greetings, > > I am the author of Plotinus[1], a GTK+ module that provides a > searchable command palette to GTK+ applications. Recently, it was > brought to my attention[2] that module loading has been

Re: No module anymore & perfect zoom feature

On Mon, Feb 26, 2018 at 5:49 AM, Samuel Thibault < samuel.thiba...@ens-lyon.org> wrote: > Hello, > > So, I also saw the removal of generic modules. > > Unfortunately we currently need it for implementing perfect zoom feature > :) > > The context is that visual-impaired users need magnification of

Re: migrating gtk

I will ignore the childish name-calling here and just state that as far as I am concerned, the bugs you file are donations to the project. What we do with them is up to us. If we decide to fix them, good for you. If not, that's tough and annoying, but lets face it: there is an infinite number of

Re: Question about popovers

On Mon, Jan 29, 2018 at 3:31 PM, Tomasz Gąsior wrote: > I want to ask question about GtkPopover. GTK3 documentation says > "GtkPopover is a bubble-like context window [...]" but popover is not a > real window but it is a floating widget inside other window. From >

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

On Thu, Jan 25, 2018 at 2:15 PM, segfault wrote: > (I resend this email because the first one awaits moderator approval > since a few days, because I was not subscribed to the list when I sent it) > > Hi, > > we at Tails (tails.boum.org) are currently working on adding

migrating gtk

Hey Carlos, we discussed gitlab migration for gtk here at the hackfest. Our conclusions were as follows: * We want to migrate the git repository as soon as possible * For bugs: * Do a sweep now, close all >5 year old bugs, needinfo all >1 old ones * Wait a few weeks, then close the

Re: First deprecate APIs and then remove them in the next major version

On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck < schoeneb...@linuxsampler.org> wrote: > > > With cooperation and compatibility layers in GTK, GTK would move forward > > less quickly, but it would maybe yield a better outcome globally when > > taking into account higher-level libraries and

Re: First deprecate APIs and then remove them in the next major version

On Thu, Dec 14, 2017 at 4:41 PM, Sébastien Wilmet wrote: > > > GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard > still worked fine just before the commit that removed it, it would have > been possible to first deprecate GtkClipboard and then removing it

Re: GTK3 - GtkExpander problem, bug ?

On Thu, Dec 14, 2017 at 7:58 PM, Sébastien Le Roux < sebastien.ler...@ipcms.unistra.fr> wrote: > Dear Eric, > thanks for your answer, and yes it is pretty much the same, the > differences in my case, > are: I use toggle buttons and I do not use a grid. > > Thanks you for providing me with this

Re: GTK3 - GtkExpander problem, bug ?

On Thu, Dec 14, 2017 at 7:58 PM, Sébastien Le Roux < sebastien.ler...@ipcms.unistra.fr> wrote: > Dear Eric, > thanks for your answer, and yes it is pretty much the same, the > differences in my case, > are: I use toggle buttons and I do not use a grid. > > Thanks you for providing me with this

Re: gtk 3 stuck menu bug on Mac

On Sat, Nov 18, 2017 at 3:34 PM, wrote: > On Sat, Nov 18, 2017 at 6:45 AM Christian Schoenebeck < > schoeneb...@linuxsampler.org> wrote: > >> On Freitag, 17. November 2017 00:51:25 CET Christian Schoenebeck wrote: >> > What I found out so far is that whenever this

Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)

On Fri, 2017-10-06 at 09:52 +0200, Tomasz Gąsior wrote: > W dniu 2017-10-05 19:02, Matthias Clasen napisał(a): > > On Thu, 2017-10-05 at 11:46 +0200, Jean Delvare wrote: > > > The change in single-click vs double-click in the GTK 3 file > > > chooser > > > fro

Re: [PATCH] file chooser: Restore consistent click behavior (for gtk 3.20)

On Thu, 2017-10-05 at 11:46 +0200, Jean Delvare wrote: > The change in single-click vs double-click in the GTK 3 file chooser > from commit fb0a13b7f070 ("file chooser: Allow activating without > double-click") causes more problems than it resolves. There have been > a lot of complaints about it:

Re: [cairo] color fonts and CAIRO_OPERATOR_SOURCE

On Mon, Sep 11, 2017 at 4:44 AM, Uli Schlachter wrote: > > > So apparently this behaviour is by design, meaning that glyphs can only > really be used with operator OVER any more (well, and some others). So > let me ask this another why: Is this really a good behaviour? > I think

Re: [cairo] Color fonts

On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in> wrote: > On 07.07.2017 15:23, Matthias Clasen wrote: > > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psyc...@znc.in> wrote: > >> On 30.06.2017 17:29, Behdad Esfahbod wrote: > >>> On Jun

Re: [cairo] Color fonts

It would be great to know if this approach, following Behdad's recommendation, will be acceptable. Review of the changes in https://github.com/matthiasclasen/cairo/tree/emoji-again would appreciated as well. I admit that I haven't thought about necessary documentation updates yet.

Re: Color fonts

On Thu, Jun 29, 2017 at 11:18 PM, Matthias Clasen <matthias.cla...@gmail.com > wrote: > I had another go at this here: https://github.com/ > matthiasclasen/cairo/tree/emoji-again > I've spent some more time on this branch. It now uses paint only for clusters that consists purely

Re: [cairo] Color fonts

On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote: > Hi, > > On 28.06.2017 14:23, Behdad Esfahbod wrote: > > All of you have asked me about the status of color fonts in > > cairo. There's > > some discussion here: > > what was the solution to make this fit into cairo's drawing model? >

Re: Color fonts

I had another go at this here: https://github.com/matthiasclasen/cairo/tree/emoji-again ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Color fonts

On Wed, Jun 28, 2017 at 8:23 AM, Behdad Esfahbod wrote: > Hello, > > All of you have asked me about the status of color fonts in cairo. > There's some discussion here: > > https://github.com/googlei18n/noto-emoji/issues/36 > > The remaining part is indeed the cairo patchset.

Re: Widget, drawing and event coordinates

Trying to summarize an irc discussion on this topic: We generally agreed that the content area should be what all vfuncs (measure, size_allocate, snapshot), events and signal handlers operate in. The other size that is relevant for widgets is the 'outer' size including the content size, css

Re: Widget, drawing and event coordinates

On Mon, Jun 5, 2017 at 2:38 PM, Timm Bäder wrote: > The goal here is to unify the coordinate systems we use for events, > drawing and size allocation. > > Widget coordinates definitely should be relative to the parent > allocation in some sense, so we can move subtrees around

Re: Call not guarded properly

Thanks for pointing thus out, I'll have a look On Jun 2, 2017 07:03, "John Emmas via gtk-devel-list" < gtk-devel-list@gnome.org> wrote: After updating glib from git master today I can no longer build with MSVC. The build now fails to link because gio makes a call to

Re: wip/baedert/drawing branch

On Thu, May 18, 2017 at 3:19 PM, Timm Bäder wrote: > > > How _are_ they done now ? > > gtk_widget_snapshot just draws it around the widget if > gtk_widget_has_visible_focus returns TRUE for it: > https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h= >

Re: wip/baedert/drawing branch

On Thu, May 18, 2017 at 11:52 AM, Timm Bäder wrote: > Hi, > > I've collected a whole bunch of changes in th wip/baedert/drawing branch. > Here's a little overview of how things work in there, so we can decide > if it's the right way forward. > Hey Tim, thanks for writing this

Re: Review of wip/carlosg/event-delivery

On Tue, May 16, 2017 at 1:25 PM, Carlos Garnacho wrote: > > > - interactive overlay: buttons over entry get prelights and clicks > > instead of the entry stealing them > > Hmm, the demo however sets the overlay as passthrough? >

Re: Functional programming with GLib

On Tue, May 9, 2017 at 4:59 AM, Tristan Van Berkom < tristan.vanber...@codethink.co.uk> wrote: > > Some things that I'm finding important for CLI apps: > > A.) Automatic generation of man pages and similar documentation, > especially generating separate man pages for each separate sub >

Re: GTK+ 3.24?

On Wed, May 3, 2017 at 2:55 PM, Murray Cumming wrote: > Will there absolutely positively never be any GTK+ 3.23/24 releases? > > After all these years of not adding API, or deprecating API, in micro > releases, I feel very uneasy about doing that in gtkmm 3.22.* just >

Re: Functional programming with GLib

On Thu, Apr 27, 2017 at 10:29 AM, Emmanuele Bassi wrote: > For command line parsing I'd actually favour a slightly bolder > approach of deprecating GOptionContext, and having something slightly > more modern — in terms of being bindable in other languages, and > well-integrated

Re: GSK review and ideas

On Thu, Dec 15, 2016 at 10:26 AM, Alexander Larsson wrote: > > Also related to clipping, we're currently not doing any culling at > all. I think we need to make gtk_container_snapshot_child() take the > current clip into consideration when recursing. Right now we're > creating

GTK+ hackfest 2017

Hey, we had a very producive meeting this year in Toronto. Lets build on that that and do another one, in early 2017. I've started to organize it here: https://wiki.gnome.org/Hackfests/GTK2017 In short: March 20-23, in London If you are interested in attending, please put your name on the

Re: gtk changes in the jhbuild moduleset

On Fri, Oct 7, 2016 at 11:47 AM, Simon McVittie <simon.mcvit...@collabora.co.uk> wrote: > On Fri, 2016-10-07 at 11:14 -0400, Matthias Clasen wrote: >> On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera <had...@hadess.net> >> wrote: >> > Which would mean nothing

gtk changes in the jhbuild moduleset

Hi, we are getting ready to start development of gtk 3.90 in master. To avoid causing lots of breakage and irritation, here is the plan: 1) Switch the modulesets to use the gtk-3-22 branch for the gtk module 2) Rename the gtk module to gtk3 3) Add a gtk4 module that follows master 4) Switch

Re: gtkdoc-scan make interfaces public

On Wed, Jun 1, 2016 at 3:40 AM, Joël Krähemann wrote: > Hi > > I want to generate an API reference of my libraries. How to tell > gtkdoc-scan to make interfaces public? Currently interfaces don't have > cross references. I figured out how I can modify gtkdoc-scan to do >

GTK+ 3.22 released

project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 21, 2016 Matthias Clasen ___ gtk-list mailing list gtk-list@gnome.org https

GTK+ 3.22 released

project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 21, 2016 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

GTK+ 3.22 released

project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 21, 2016 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list

Re: Lack of documentation for custom GTK3 widgets in C

On Thu, Mar 10, 2016 at 7:53 AM, Drew DeVault wrote: > I've found a reasonable amount of resources online for making custom > GTK2 widgets in C. Unfortunately, I can't say the same about GTK3. Can > anyone point me to some resources for this, and can we do something > about the

GTK+ 3.20

to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 21, 2016 Matthias

GTK+ 3.20

to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 21, 2016 Matthias

GTK+ 3.20

to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 21, 2016 Matthias

Re: G_UTF8String: Boxed Type Proposal

On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer wrote: > 2) If the former is true - which it is - then the developer will need to > call g_utf8_strlen() to determine if there are multi-byte sequences to > navigate - and if there are - g_utf8_offset_to_pointer() to

Re: G_UTF8String: Boxed Type Proposal

Sure, code point works too. Anyway, enough with the ontology, we're not a standards body I still don't think that we need a utf8-string datatype. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

Re: G_UTF8String: Boxed Type Proposal

On Thu, Mar 17, 2016 at 4:09 PM, Jasper St. Pierre wrote: > The major issue is that "Unicode character" doesn't have a good > definition. The most likely definition is a "Unicode code point", > however, Windows uses "Unicode character" to mean a UTF-16 byte > sequence,

Re: G_UTF8String: Boxed Type Proposal

On Wed, Mar 16, 2016 at 6:58 PM, Randall Sawyer wrote: > I have a question at the end of this! Please answer if you think it will > help. Hi Randall, thanks for contributing! > > I propose the development of a new boxed type for the Glib API named > "G_UTF8String".

Re: G_UTF8String: Boxed Type Proposal

On Thu, Mar 17, 2016 at 2:26 PM, Jasper St. Pierre wrote: > I'll also ask what "character" means in this case, even though I know > glib also has the same confusion. Are you talking about the number of > Unicode code points in the string, or the number of grapheme

Re: GTK+ hackfest 2016

After considering the scheduling and the topics for a bit, I prefer to keep the June date. But don't worry, Sri - I'll be happy to come to Portland too. Considering some scheduling constraints that came up, I've moved the date for the hackfest to June 13-16, and reserved a meeting room at the Red

Re: GTK+ hackfest 2016

> We are hosting a GNOME conference in Portland in September. Would you like > to do it then? Thats an interesting alternative, worth considering. My initial thoughts are: - It does push us late in the 3.22 cycle, which is a bit of a minus for the 'planning next steps after 3.20' - Can you

GTK+ hackfest 2016

Hi, we've discussed the idea of doing a GTK+ hackfest this year. I've started a wiki page with the current plan: https://wiki.gnome.org/Hackfests/GTK2016 If you are interested in attending, please add your name to the list. If you want to see topics added to the agenda, please suggest them on

Re: API/ABI reports

On Fri, Feb 5, 2016 at 7:21 AM, Ponomarenko Andrey wrote: > Hello, > > I've started to maintain API/ABI changes reports for the Gtk+ and Glib > libraries here: > > http://abi-laboratory.pro/tracker/timeline/gtk+/ > http://abi-laboratory.pro/tracker/timeline/glib/ > >

Re: elementary would like to participate :)

On Sun, Nov 8, 2015 at 8:41 PM, Daniel Foré wrote: > Hey Matthias, > > I remember speaking to you about it and you had mentioned you would prefer > it to be implemented as a stack switcher and note a GTK.notebook. Does that > still hold true? I imagine that we could

Re: elementary would like to participate :)

Here is what I did to see granite-demo running: 1) download and untar https://launchpad.net/granite/0.3/0.3.1/+download/granite-0.3.1.tar.xz 2) cd granite-0.3.1/ 3) cmake . 4) run ./demo/granite-demo ___ gtk-devel-list mailing list

Re: elementary would like to participate :)

On Thu, Nov 5, 2015 at 4:32 PM, Daniel Foré wrote: > Hey folks, > > Sri and Matthias pointed us here. Basically the idea is we want to start a > discussion about how elementary can be more involved in Gtk+ development > and Sri thought a good place to start would be to

Re: [Discuss] Make a thinner Glib/GTK+ to fit tiny device better

On Wed, Oct 14, 2015 at 11:40 AM, Nicolas Dufresne < nicolas.dufre...@collabora.com> wrote: > Le lundi 12 octobre 2015 à 23:24 +0800, cee1 a écrit : > > > > > 2. I notice EFL use some "COW" logic[1], but we already have a much > > clean implementation in GStreamer, that's > >

Re: Interface analyzer for GTK+

On Mon, Sep 28, 2015 at 1:58 PM, Daniel Milewski < danmil...@student.pg.gda.pl> wrote: > As a part of my engineer's thesis I'm developing a interface analysis > tool for GTK+. The tool's purpose is to let one judge how good the > interface design is based on task execution and learning time.

Re: Dropping 'fringe' pixbuf loaders

Thanks for the feedback. So far, I've dropped wbmp, ras and pcx. I've left tga because Benjamin has a branch with a rewritten loader (hopefully more trustwrothy). I've left qtif because I wasn't sure if this format is important on OS X.. I've left ani because it is an example of adding animation

Re: Dropping 'fringe' pixbuf loaders

On Mon, Sep 21, 2015 at 7:20 PM, Bastien Nocera wrote: > > > I would argue that at least I have taken care of some of that work at > the end of 2014. I didn't get to see coverity scans or cppchecks, but > this isn't the most complicated code to fix up and review. > > Yes, that

Re: Dropping 'fringe' pixbuf loaders

On Mon, Sep 21, 2015 at 5:10 PM, Cosimo Cecchi wrote: > > On Mon, Sep 21, 2015 at 1:01 PM, Owen Taylor wrote: > >> Do we trust this code or not? If not, we should either a) sandbox it or >> b) delete it. >> >> Moving less-trusted loaders into a separate

Re: Ülease get gtk3 css definition to be similar to gtk pixbuf!

On Wed, Aug 12, 2015 at 12:32 AM, Philip Chimento philip.chime...@gmail.com wrote: On Sat, Jul 25, 2015 at 9:26 AM, Matthias Clasen matthias.cla...@gmail.com wrote: We will be discussing how to document the evolving GTK+ css capabilities in a clearer way at Guadec in a few weeks. I wanted

Re: Ülease get gtk3 css definition to be similar to gtk pixbuf!

On Wed, Aug 12, 2015 at 12:32 AM, Philip Chimento philip.chime...@gmail.com wrote: On Sat, Jul 25, 2015 at 9:26 AM, Matthias Clasen matthias.cla...@gmail.com wrote: We will be discussing how to document the evolving GTK+ css capabilities in a clearer way at Guadec in a few weeks. I wanted

Re: Ülease get gtk3 css definition to be similar to gtk pixbuf!

We will be discussing how to document the evolving GTK+ css capabilities in a clearer way at Guadec in a few weeks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Ülease get gtk3 css definition to be similar to gtk pixbuf!

We will be discussing how to document the evolving GTK+ css capabilities in a clearer way at Guadec in a few weeks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDK_KP_Decimal (on Windows)

On Thu, Apr 30, 2015 at 2:37 AM, John Emmas john...@tiscali.co.uk wrote: Thanks. Here's a patch produced by one of my colleagues:- --- a/gdk/win32/gdkkeys-win32.c 2015-04-29 16:33:41.545406159 +0200 +++ b/gdk/win32/gdkkeys-win32.c 2015-04-29 16:35:16.821576820 +0200 @@ -145,6 +145,8 @@

Re: Module-less pango vs pangox-compat

On Fri, 2015-04-24 at 14:31 -0700, Behdad Esfahbod wrote: Hi Matthias, Just a quick note that with the module-less pango, the pangox-compat lib won't work anymore. Not that *anyone* cares... Thanks for the update. I do have customers who care about pangox -compat, but it'll be a while

Re: hint for vertical writing mode to input method

On Tue, Mar 31, 2015 at 3:30 AM, Makoto Kato m_k...@ga2.so-net.ne.jp wrote: Hi, GTK team. Mozilla is implementing vertical-writing spec [*1] to Gecko rendering engine. But GTK has no API to add hint of vertical writing mode to input method. Other OS already has the following method /

GTK+ 3.16.0 released

to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 22, 2014 Matthias Clasen

GTK+ 3.16.0 released

to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 22, 2014 Matthias Clasen

GTK+ 3.16.0 released

to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GTK+/Roadmap Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. March 22, 2014 Matthias Clasen

Re: I'm done with O_CLOEXEC

On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie de...@desrt.ca wrote: The first one, which we have been pursuing during the past several years, is to try to mark every file descriptor that we create as O_CLOEXEC. This is particularly fun in multi-threaded programs because it means that we have

Re: I'm done with O_CLOEXEC

On Sat, Mar 21, 2015 at 1:10 AM, Ryan Lortie de...@desrt.ca wrote: On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote: So, you found that dup3 doesn't do what you want, and now you want to throw out the baby with the bathwater and just say I don't care anymore if we leak fds ? dup3

Re: I'm done with O_CLOEXEC

So, you found that dup3 doesn't do what you want, and now you want to throw out the baby with the bathwater and just say I don't care anymore if we leak fds ? On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie de...@desrt.ca wrote: karaj, For those unfamiliar with the issue: when a process is

GTK+ is branched too

I've followed Ryans example, and branched GTK+ early too. The gtk-3-16 branch will lead to 3.16.0, and master is open for new stuff, such as Benjamins css node work. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org

Re: GTK+, WM, desktops and CSD

On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan four...@gmail.com wrote: Hi, I have little desire to discuss the pros and cons of csd and whether something essential (consistency ?!) was lost when we started using them, but a few points are worth replying to. The use of Motif MWM hints for

Re: recently-used.xbel

On Thu, Jan 22, 2015 at 8:52 AM, John Emmas john...@tiscali.co.uk wrote: Yesterday I mistakenly posted this to gtk-list when it should probably have come here... sorry. Anyway... I'm working on an app which uses a GtkFileChooser dialog. Let's say I use it to open a file. Next time I

Re: RFC: GtkPreview library

On Mon, Jan 19, 2015 at 9:24 PM, Cosimo Cecchi cosi...@gnome.org wrote: I moved this to the wiki: https://wiki.gnome.org/Projects/GTK%2B/Preview Hey, thanks for starting this discussion! I think the document would benefit from a section listing some expected use cases: where do we expect this

Re: [PATCH] Fix check for 'y' padding in gtk_cell_renderer_set_padding()

On Mon, Jan 12, 2015 at 1:30 PM, Philip Withnall phi...@tecnocode.co.uk wrote: On Sun, 2015-01-11 at 16:43 +, Emmanuele Bassi wrote: hi; thanks for your patches. GTK+ does not use the mailing list to track bugs and patches; could you please open bugs on Bugzilla, instead? just use:

Re: a new combo box

On Sun, Dec 28, 2014 at 7:42 PM, Emmanuele Bassi eba...@gmail.com wrote: just a bunch of comments going through the commits. Thanks for this! [...] as for the overall naming: I think combo box does not entirely apply, given that the entry is not only optional, but also part of the drop

Re: a new combo box

On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz ar...@gnome.org wrote: My main concern with the design is that users can't make a difference between a normal button and this widget (usually related to an action, perhaps with the exception of iconized menus like the ones we're using in headerbars

Re: a new combo box

I am a bit disappointed by the turn this discussion has taken - I was hoping people would try the code I pointed to and let me know what they think and point out problems (thanks to Tim for doing just that). Instead, I get arguments about how much my time is worth compared to Mortens, complaints

a new combo box

Hi, over Christmas, I had some for a little side project, a new combo box. It is based on these mockups: https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/master/theming/widgets/combobox-replacements.png One question I need some feedback on is naming: We currently have

Re: a new combo box

On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom tris...@upstairslabs.com wrote: It's really not that bad, combobox is currently 6k lines of code which is really not much for all that it does, sure we could afford to do a bit less (like dropping the crazy tabular menus). Tbh, thats only

Re: help wanted for implementing GdkGLContext on Windows and MacOS X

On Wed, Nov 19, 2014 at 3:10 AM, Jasper St. Pierre jstpie...@mecheye.net wrote: Yeah, this is an unfortunate bug with libepoxy right now. There's a PR on GitHub if you want to see if that fixes it. https://github.com/anholt/libepoxy/pull/28 All we can do is pressure Eric Anholt to merge it

Re: Use the user's gtk theme in gtk-inspector

On Fri, Oct 24, 2014 at 8:19 AM, Simon simonz...@gmail.com wrote: Would it be a good idea to use the user's gtk theme by default in gtk-inspector? The current default theme is hardcoded to Adwaita, see this change. Thats a misunderstanding of what that change does. It simply ensures that

Re: State of gdk-pixbuf

On Wed, Oct 22, 2014 at 10:31 PM, Bastien Nocera had...@hadess.net wrote: Hey, I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling patches, and testing what was testable. Thanks for doing that! The last 3 are related in that GdkPixbuf is a format that doesn't lend

Re: gnome in the future?

It is hard to know what to reply to this. GTK+ is not going away. A large part of what we've been doing over the last few years is about enabling animations, and adding animations to core widgets. Bindings are available and work well for the most part.

Re: Improve word boundaries for text widgets

On Sat, Oct 4, 2014 at 8:24 AM, Sébastien Wilmet swil...@gnome.org wrote: On Fri, Oct 03, 2014 at 10:25:36PM -0400, Matthias Clasen wrote: I think I want the default in GtkTextView/Pango to stay basically Unicode. So the vfunc may be needed sooner if you want to have vim-like behaviour

Re: Improve word boundaries for text widgets

On Sat, Oct 4, 2014 at 1:52 PM, Paul Davis p...@linuxaudiosystems.com wrote: But the Vim word boundaries improve the behavior also for normal text, not just code. Vim can be used to write mails and documents. this is none of my business, but it seems fairly clear to me what matthias wants:

Re: Improve word boundaries for text widgets

On Sat, Sep 27, 2014 at 7:39 AM, Sébastien Wilmet swil...@gnome.org wrote: On Sat, Sep 27, 2014 at 12:47:31AM -0400, Matthias Clasen wrote: I agree that we probably need a vfunc - there's different use cases that need different variants: natural language, code, xml, etc. For best results, we

GTK+ 3.14.0 released

Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 22, 2014 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk

Re: GTK+ 3.14.0 released

Small correction: the correct link to the roadmap page is this: https://wiki.gnome.org/Projects/GTK+/Roadmap ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK+ 3.14.0 released

Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 22, 2014 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel

Re: GTK+ 3.14.0 released

Small correction: the correct link to the roadmap page is this: https://wiki.gnome.org/Projects/GTK+/Roadmap ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.14.0 released

Thanks to the many people who contributed to this release in the form of bug reports, patches and translations. September 22, 2014 Matthias Clasen ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list

  1   2   3   4   5   6   7   8   9   10   >