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 X-

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 https://gitlab.gnome.org/G

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 Gn

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+ and

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 acheive

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 > > understand that, it shou

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

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 bu

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 > perspective of window managers

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 support for > TrueCrypt and

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 needinfoed

Re: Why these settings are deprecated?

On Tue, Dec 26, 2017 at 3:06 PM, Tomasz Gąsior wrote: > I would like to ask question directly to main GTK developers. Why these > Xsettings are deprecated? > > * gtk-button-images > * gtk-enable-mnemonics > * gtk-icon-sizes > * gtk-menu-bar-accel > * gtk-menu-bar-popup-delay > * gtk-menu-images >

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 in > 3.9x+2 (see my

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 ni

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 problem occurs, both of >> the >

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 you are jumping

Re: [cairo] Color fonts

On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter wrote: > On 07.07.2017 15:23, Matthias Clasen wrote: > > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter wrote: > >> On 30.06.2017 17:29, Behdad Esfahbod wrote: > >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen"

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: [cairo] Color fonts

On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter wrote: > On 30.06.2017 17:29, Behdad Esfahbod wrote: > > On Jun 30, 2017 7:51 PM, "Matthias Clasen" wrote: > > > > On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote: > >> Hi, > >> > >>

Re: Color fonts

On Thu, Jun 29, 2017 at 11:18 PM, Matthias Clasen 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 of color glyphs, rewriting

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? > Tex

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. Matthias had a rewor

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 paddi

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 without > re-allocat

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 'g_openuri_portal_open_uri_fin

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= > wip/baedert/drawing#n15693 > > So e.g. dr

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 up. Let me ask a f

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? > https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/overlay.

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 > co

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 > because GTK+ seems to be do

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 with API like GApp

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 nodes for children t

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 list.

Re: gtk changes in the jhbuild moduleset

On Fri, Oct 7, 2016 at 11:47 AM, Simon McVittie wrote: > On Fri, 2016-10-07 at 11:14 -0400, Matthias Clasen wrote: >> On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera >> wrote: >> > Which would mean nothing called "gtk+" in the modulesets? Why not >> > ke

Re: gtk changes in the jhbuild moduleset

On Fri, Oct 7, 2016 at 6:36 AM, Bastien Nocera wrote: > On Fri, 2016-10-07 at 06:33 -0400, Matthias Clasen wrote: >> 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: >&g

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 appli

GTK+ 3.22 released

acant 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@gnom

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 gap in documentatio

GTK+ 3.20

ng 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 Mat

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 locate the array > index. Doesn

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 https://mail.gnome.org/mailman/listinfo/gtk-dev

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, which means that any code po

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". I have searched through this

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 clusters, > as defined by Unicod

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 get

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 th

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/ > > The project is just a hobby a

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 probably take the opportunity

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 gtk-devel-list@gnome.o

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 try getting some of our > G

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 > > gst_mini_object_make_

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. It'll

Re: Dropping 'fringe' pixbuf loaders

On Thu, Sep 24, 2015 at 5:57 PM, Petr Tomasek wrote: > On Mon, Sep 21, 2015 at 11:28:17AM -0400, Matthias Clasen wrote: > > After several rounds of fixing overflow and allocation failure issues in > > various loaders this cycle, I'm reconsidering following the sug

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 is true. You have h

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 repo is a blame-the-user or >> blame-the-o

Dropping 'fringe' pixbuf loaders

After several rounds of fixing overflow and allocation failure issues in various loaders this cycle, I'm reconsidering following the suggestion in https://bugzilla.gnome.org/show_bug.cgi?id=721372 wbmp, tga, ras, qtif, pcx, ani... these are probably prime candidates for being removed. Before do

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

On Wed, Aug 12, 2015 at 12:32 AM, Philip Chimento wrote: > On Sat, Jul 25, 2015 at 9:26 AM, Matthias Clasen > 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 to r

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 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 @@ >*ksymp = GDK

Re: hint for vertical writing mode to input method

On Tue, Mar 31, 2015 at 3:30 AM, Makoto Kato 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 / attribute for this cas

GTK+ 3.16.0 released

, 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

Re: I'm done with O_CLOEXEC

On Sat, Mar 21, 2015 at 1:10 AM, Ryan Lortie 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 >> anymor

Re: I'm done with O_CLOEXEC

On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie 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 a race betw

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 wrote: > karaj, > > For those unfamiliar with the issue: when a process is created on UNIX

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 https://mail.gnome.org/mailman/l

Re: GTK+, WM, desktops and CSD

On Thu, Mar 5, 2015 at 3:23 PM, Olivier Fourdan 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 this is a anachron

Re: recently-used.xbel

On Thu, Jan 22, 2015 at 8:52 AM, John Emmas 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 launch the GtkFileCh

Re: RFC: GtkPreview library

On Mon, Jan 19, 2015 at 9:24 PM, Cosimo Cecchi 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 preview to be

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

On Mon, Jan 12, 2015 at 1:30 PM, Philip Withnall 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: https://bugzil

Re: a new combo box

On Sun, Dec 28, 2014 at 7:42 PM, Emmanuele Bassi 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 down, instead

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 ab

Re: a new combo box

On Sun, Dec 28, 2014 at 1:27 AM, Alberto Ruiz 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 these days)

Re: a new combo box

On Sat, Dec 27, 2014 at 12:59 PM, Tristan Van Berkom 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 true after your sho

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 GtkComboBo

Re: hooking spinner to GtkSidebar page transition

On Thu, Dec 18, 2014 at 4:31 AM, Daiki Ueno wrote: > Hello, > > I'm trying to replace my application's own sidebar implementation (based > on GtkListBox/GtkStack) with GtkSidebar, to take advantage of the > standard CSS theme[1]. Currently I have a small obstacle to this > migration. > > To reduc

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

On Wed, Nov 19, 2014 at 3:10 AM, Jasper St. Pierre 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 at this point. >

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

On Fri, Oct 24, 2014 at 8:19 AM, Simon 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 Adwaita is always pr

Re: State of gdk-pixbuf

On Wed, Oct 22, 2014 at 10:31 PM, Bastien Nocera 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 > itself to handl

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 1:52 PM, Paul Davis 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: > > step 1: create

Re: Improve word boundaries for text widgets

On Sat, Oct 4, 2014 at 8:24 AM, Sébastien Wilmet 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 behav

Re: Improve word boundaries for text widgets

On Sat, Sep 27, 2014 at 7:39 AM, Sébastien Wilmet 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 >>

Re: Improve word boundaries for text widgets

On Fri, Sep 26, 2014 at 7:37 PM, Christian Hergert wrote: >> Another idea for GtkTextView is to add a vfunc to let GtkSourceView >> define custom word boundaries for word movements and selection. But >> all what GtkSourceView would do is to define the "Vim" word boundaries, >> which are generic.

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

admap 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-

Re: Why aren't gtk color variables used in the Adwaita scss?

On Mon, Sep 8, 2014 at 7:10 PM, Wayne Rowcliffe wrote: > I was looking to extend the Adwaita theme to use some different colors. > > This would be very straight-forward if Adwaita used @define-color > variables throughout the theme since I could just redefine those > values. However it looks like

Re: A Gtk's build system ?

On Thu, Aug 7, 2014 at 10:16 AM, Alberto Ruiz wrote: > However, building Gtk+ is not trivial and I am sure waf is going to require > some fixing before it can support a full build, if people want to take on > the task of setting up a branch and checking what it would look like, I > would be happy

GTK+ team meeting at guadec

Hey, I've put an initial page together for our traditional GTK+ team meeting at guadec: https://wiki.gnome.org/GUADEC/2014/BOFs/GTK+ It would be great if those who are around and interested in participating would put their names and availability (mainly departure dates are relevant, I'd say) on

Icon theme changes in GTK+

GTK+ 3.13.3 will include a number of changes to the icon theme handling code. The overarching goal is to simplify the icon handling, and make it possible to use it for theme assets like checkboxes, expander arrows, etc. The main changes that may affect applications are: 1) Icons will be automatica

Re: Volunteer

Hey Lieven, great that you are interested in helping out ! I'm sure you'll find something interesting to work on. Here's a few ideas: - pick any widget that is currently still using a button press event handler, and convert it to using event controllers instead - add support for switching pages

A GTK+ roadmap update

Its been on my todo list for a while to write an update for the GTK+ roadmap. While I couldn't make it to the Developer experience hackfest in Berlin myself, the GTK+ team was present there and had a pretty extensive roadmap discussion. Thankfully, they took great notes [1]. I encourage everybody

Re: A little style issue

The common way to achieve the look you want here (raised, linked buttons) in a toolbar is to but the buttons in a box with the "linked" style class, and then put that box in a toolitem. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mai

  1   2   3   4   5   6   7   8   9   10   >