GTK meeting notes

[Matthias Clasen via gtk-devel-list]

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
Put agenda items on the wiki, please
And book your rooms soon!

2) State of GTK4 branches

listview branch: still quite in flux, but lots of things possible already.
Matthias has started to look at it recently, will create a writeup together
with Benjamin on state and remaining work.

transformations branch: Emmanuele is reviewing it, will work on an MR

wip/layout-manager branch: Current work-in-progress by Emmanuele on
separating layout managers from containers.

Current issues on master:
- window resizing problems with wayland / gl (Matthias)
- driver problems with vulkan (Emmanuele)
- Adwaita has regressions and is out of sync with 3.24

Some discussion around the way forward for Adwaita. We have a branch
with a theme refresh that is targeted for GNOME 3.32, but that might be
radical enough that it breaks some apps targeting Adwaita. We could
ship a beta-form NewAdwaita with the next 3.24.x release to give people
time to try it out. Still need a better theme selection api, ultimatively.
Currently
we just have the theme name to go off.

3) General agreement that we should revert the a11y changes on 3.24, since
they were breaking things too much. Carlos will look into it.

4) Releases were not discussed directly. Matthias will look at doing a
3.24.x release
this week.

Next meeting time: March 4
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

OS X issues

[Matthias Clasen via gtk-devel-list]

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-mas to fix
a few other issues, and it would be great to take care of the OS X problems
at the
same time.

Thanks in advance
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Quartz Coordinates

[Matthias Clasen via gtk-devel-list]

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/GNOME/gtk/issues/1029 as well as other
> pointer coordinate issues some users have reported on downstream
> applications.
>
> Under the old GdkScreen regime Gdk had a “root window” with 0,0 in the
> upper left corner of the upper-left-most monitor and all point values are
> unsigned, increasing down and to the right. Quartz uses a different
> coordinate system with the origin at the bottom-left corner of the
> “primary” monitor with point values increasing up and to the right.
> Monitors placed below or to the left of the “primary” monitor will have
> negative coordinates. gdkscreen-quartz and gdkwindow-quartz have conversion
> code to create a fake root window and to translate between the two
> coordinate systems.
>
> The new GdkDisplay/GdkMonitor regime does away with the root window and
> introduces gdk_display_get_monitor_at_point and
> gdk_display_get_monitor_at_window that iterate over the list of active
> monitors testing for whether the coordinates of the point or window lie
> inside each monitor’s work area. That’s great, it’s similar to the way
> Quartz works... but are there any assumptions made about coordinates that
> need translation between Gdk and Quartz?
>
>
Yes, we haven't fully resolved this, in particular with respect to hi-dpi.
It is still an open issue on the gtk4 roadmap:
https://gitlab.gnome.org/GNOME/gtk/issues/1106
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK meeting notes

[Matthias Clasen via gtk-devel-list]

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 Gnome 3.32
-- theme refresh
-- more invasive changes during 3.24:
https://gitlab.gnome.org/GNOME/gtk/merge_requests/391
-  - Review GTK4 task list
-  - Revise GTK4 plan
-  - Website refresh for GTK4
-  - Miscellaneous

Notes

1) Meeting time and cadence

  Aiming for monthly meetings, first Monday of the month, 15:00 utc
  Next date: January 7, 2019

1) GTK Hackfest.

  Tentative dates: Mon - Wed after FOSDEM
  Location: Brussels
  We'll look at getting the same venue as this year
  Emmanuele volunteered for that, Matthias has contact info
  Will set up a wiki page to organize

2) Listfest

  Benjamin is trying to get this organized with various listbox consumers
  https://wiki.gnome.org/Hackfests/ListFest2018

3) 3.26 release ?

  Some concern about the scale of theme refresh going into 3.24
  And some special-purpose new api needed for a statusicon regression fix
  Clash between expectations of minor gnome release vs micro gtk release
  Options:
tone down theme changes
keep the api private

  Inconclusive discussion, will revisit at hackfest

4) GTK4 tasks

  Not a lot of progress recently
  Matthias has been off doing other things
  Benjamin has a deep stack of unfinished changes that he is
struggling to unwind
  Timm has an unreviewed transformation branch. Ebassi volunteered to review

  Big gtk4 blockers:
popovers
dnd
  Beyond that, need to identify end user and app developer features,
write demos and advertise

  We have a media demo (puzzle)

  A blur demo (in tests)

  A 2.5 million files list box demo (in a branch)

5) Misc

  Some discussion around improving docs, tutorials, examples
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

A pango update

[Matthias Clasen via gtk-devel-list]

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 GNOME continue to have a competitive text
rendering stack,
and to avoid pango becoming a roadblock for this.

To give some background, pango provides these major pieces of
functionaliity. Originally,
pango has had a backend- and module-based architecture to implement most of
these things per platform:

- Unicode text analysis (direction, scripts, languages).

This is mostly based on Unicode data tables which are for the most part
(but not entirely)
provided by GLib and firibidi.

- Font enumeration.

Font enumeration will remain platform-specific, with a Linux implementation
based
on fontconfig.

- Shaping.

Shaping is the domain of harfbuzz, and we want to use it on all platforms
in the
future. The web browsers are ahead of us here, and already use harfbuzz
across
platforms. The soon-to-be released harfbuzz 2.0 will close one of the last
few feature
gaps for this by supporting Apple-specific font tables.

- Font rendering.

For rendering, we nowadays rely on cairo everywhere.

In terms of concrete plans, we want to

- Move things that need to be updated with Unicode (scripts, character
properties)
  to GLib and/or fribidi

- Update the Emoji iterator to be in sync with chrome

- Use harfbuzz for shaping everywhere

- Provide api to make harfbuzz objects available, so we can get access to
harfbuzz
  features without wrapping everything in pango api

There's also a small amount of feature work that we've looked at:

- Add some apis to support font variations

- Subpixel positioning

There is a gitlab milestone to track these:
https://gitlab.gnome.org/GNOME/pango/milestones/9
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About Gtk4, modules and GlobalMenu approach

[Matthias Clasen via gtk-devel-list]

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 support for Global Menu.
>
> Can I develop a patch to GTK which enables support exporting all
> GtkMenuBar instances as GMenuModels (regardless of origin) when
> gtk-shell-shows-menubar is enabled and set to 1?
>
>
No, we don't think that is appropriate, as we already said in
https://gitlab.gnome.org/GNOME/gtk/issues/1132
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: widget accessibility roles: being able to override it

[Matthias Clasen]

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 should have role ATK_ROLE_STATIC.  I have not found
> > any way in glade's .ui format to specify this, actually ROLE_STATIC does
> > not appear in gtk+3.0 source code, so I guess it's just not there.
> >
> > I'm thinking we could have something like
> >
> > 
> >   
> > 
> >
> > to be able to specify e.g. labels' role?
>
> FI, I have posted a patch implementing this in gtk on
>
> https://gitlab.gnome.org/GNOME/gtk/issues/109
>
> Along the way, I found that there is
>
> 
> 
> ATK_ROLE_STATIC
> 
> 
>
> which is supposed to do the same, but that doesn't work:
> "accessible-role" is supposed to be an int, not a string, and thus one
> would have to put 117 there instead of ATK_ROLE_STATIC, which is really
> going to work :)
>
>
This is a bug in atk, I would say. The role property should really be
defined as enum, not as int.
If that is fixed, then your ui file snipplet will start to work.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK_MODULES removal and the future of existing modules

[Matthias Clasen]

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 removed[3] on
> GTK+ master.
>
> It appears that this change could mean the end for Plotinus and other
> modules like it. I would be interested to learn:
>
> 1. What is the rationale behind the removal of module loading?
>
> 2. What will be the first stable release of GTK+ that does not support
>modules anymore? Is this GTK+ 4.0+ only, or will support also be
>dropped in a 3.0 series release?
>
> 3. What, if any, alternatives are available/planned for software
>like Plotinus that needs to inspect the widget hierarchy of running
>applications in order to work?
>
> Any insight is appreciated!
>
>
This may not be a popular opinion, but my view is that it is harmful to the
eco system
overall if useful features are hidden away in 3rd party modules instead of
being properly
integrated in the toolkit.

Has the example you mention ever been suggested as a feature addition to
GTK+ ?
Was it rejected ? Or why was it implemented as a 3rd party module ?

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: No module anymore & perfect zoom feature

[Matthias Clasen]

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 the
> desktop. Changing font sizes / dpi etc. have their limit, at some point
> we need to just have a zoomed view of a piece of the screen. Currently
> compiz' ezoom takes the piece of the screen, and magnify it to show it
> on the screen, with obviously awful pixelization effects.
>
> Our idea was very similar to gtk-vector-screenshot : instead of taking
> the output as it is displayed on the screen, get a module loaded within
> the application, with which ezoom can discuss to make the application
> produce a magnified rendering of its window, which ezoom can then show
> in the magnification glass, thus getting perfect zoom.
>
> Without module loading, I don't know how to implement it :) Or perhaps
> this could be added as an AT-SPI interface?
>
>
If it is a toolkit-level feature that is needed desktop-wide, it needs to
be implemented in the toolkit proper, not added through the backdoor via a
module. I know that this will require some rearchitecting and may not be
super-easy, but I still believe that this is the right way forward.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: migrating gtk

[Matthias Clasen]

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 bug reporters out there, and only a handful of people who spend
their free time trying
to keep up with it, so some bugs will always go unfixed, that is just
reality.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Question about popovers

[Matthias Clasen]

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 and compositors popovers don't exist.
>
> Appearance of popover is similar to window but it is not window — this
> causes inconsistences in animations. Window animation is defined by WM and
> compositor, popover animation — in GTK theme.
>
> There are also problems with big popovers in small windows. See example:
> Mousepad GTK3, "Find and replace" dialog.
> First: http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-
> 01-2915-15-00.php
> and then:  http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-0
> 1-2915-15-22.php
>
> Why did you — my question is directed to GNOME devs — chosen this way of
> implementation of this feature? Why popovers are not normal windows (with
> disabled server side decoration and with client side shadow)? I don't want
> to criticize your decision, probably you are more experienced, just I want
> to understand.
>
> Firefox uses in some parts of its UI widgets with appearance similar to
> GTK popovers. Fx devs implemented it as real window. See
> http://en.zimagez.com/zimage/przechwycenieobrazuekranu2018-0
> 1-2915-27-18.php
>

It was hard to do this in GTK+ 3. We are looking at doing this for GTK+ 4.


>
> I have also second question. Why GNOME uses popovers instead normal menus
> for menus purposes?
>
>
Because it provides a different user experience, somewhere between menus
and dialogs.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Extending GtkMountOperation to support TrueCrypt/VeraCrypt

[Matthias Clasen]

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 VeraCrypt volumes in udisks and GNOME Disks (see also the
> corresponding thread on devkit-devel [1]). A team mate will also send an
> email regarding this to GNOME UX people in the next days, so you won't
> see any code from us implementing a GUI design that they have not
> accepted. I'm stating this so you can ignore the GUI design implications
> for now.
>
> Beside other things, we also want to support unlocking via the GVfs
> udisks volume monitor, which automatically prompts the user to unlock
> encrypted volumes once they are plugged in. In order to fully support
> TC/VC volumes, the unlock dialog shown to the user must allow specifying
> several other options than only the password, namely: keyfiles required
> to unlock the file, a PIM value [2], and whether the volume is a hidden
> volume, a system volume, or neither.
>

Doesn't sound like the greatest user experience, having to specify
a ton of arcane details like that...


> The work on this part turned out more complicated than we anticipated.
> The unlock dialog is not created by the GVfs monitor directly, but by
> GtkMountOperation, which in turn calls
> org.gtk.MountOperationHandler.AskPassword, which is part of GNOME Shell,
> and which then finally creates the ShellMountPasswordDialog (please
> correct me if I got anything wrong).
>
> This means that we will have to patch a lot more, and more low-level
> GNOME components than we anticipated, and we would like to ask for
> advice on what the best way to solve this would be.
>
> The only way I see is to extend GtkMountOperation (and GMountOperation)
> by fields for the additional options, and create new flags in
> GAskPasswordFlags, which can be passed down from GVfs to
> ShellMountPasswordDialog. This could be a single "VeraCrypt-mode" flag,
> or a separate flag for each of the required options I listed above.
>
> Do you see a better way?
>
>
If you could describe the required data a bit more, it might be possible to
figure out
if we can describe this in a somewhat concise way - it sounds like you need
to add
a file chooser button, an entry and a combobox ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

migrating gtk

[Matthias Clasen]

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 bugs that didn't get a
response
  * Triage the rest
  * Migrate what's left at the end

Does this sound plausible to you ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 applications.
>
> This is always the common argument "retaining old APIs means more work".
> But
> if you look at what APIs had been removed in gtk (and glib and co) in the
> past, most of them could have been preserved with no or little effort on
> library level.
>
> I mean to me it looks like nobody even considered in the past to keep old
> APIs
> at all. Currently it is just a common rule "ok, we are now on the next
> major
> version branch, we are now safe to do whatever we want to do, so let's
> start
> removing everything we don't like anymore".
>

Maybe give a concrete example of an api that we could have 'preserved with
no effort"
and yet removed out of folly ? I would be interested.


> Addressing major library changes on application level often means *much*
> more
> effort, because as application you don't necessarily have access to library
> internal things nor can you make certain presumptions. Plus not only one
> gtk
> app project has to do that gtk version compatibility work, all gtk app
> projects need to do them.  If you calculate how many man hours are wasted
> on
> all these applications, just for retaining compatiblity with the latest
> major
> gtk version, then you probably might see that the trash can decisions are
> currently made far too easily on library level.
>

To me this reads like a misunderstanding.

Moving an application from GTK3 to GTK4 means porting work. But you do it
only once,
and you don't retain GTK3 compatibility. At least, that is not what the
GTK+ team
recommends you should do.

If you want to stick with GTK3, you are more than welcome to do so for
years to come.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 comment below).
>
> Of course if GtkClipboard didn't work anymore, then it needed to be
> removed. Or maybe it was possible to port GtkClipboard to the new GDK
> API, but this would have been more work for the GTK developers. It all
> depends if you want to provide a smooth experience to port apps.
>
>
I know this may sound harsh, but: If you want things to work differently,
send patches.
Patches to the migration guide are welcome too.

The bulk of the work done on GTK4 so far has been done by 3 or 4 people,
only one of
which gets payed to work fulltime on GTK+.

Maintaining compatibility layers costs and constantly gets in the way of
large-scale
refactorings like the ones that are happening in gtk 3.9x now.

Note that we haven't really asked application developers to port to the
current 3.9x releases
yet, because they are still in flux.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK3 - GtkExpander problem, bug ?

[Matthias Clasen]

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 nice working example, I played with
> it to illustrate the
> bug because it happens with your code too, check the new 'test.c' file
> attached !
>
> I simply added a third expander and a third set of buttons, I invite you
> to compile the code attached,
> and play with it you will see, that at same point even it stops to
> function properly.
>
> To start to have errors you can follow the following sequence:
> 1) open the first expander
> 2) open the second
> 3) open the third
> 4) close the second
> 5) starting clicking on the second expander location (without buttons
> visible) and it starts.
>
> I can only guess that the more expander you use the more messy it will get
> ... hence the problems
> with my program that uses 10.
>
>
I can't be too sure since you don't say which version of gtk this is with,
exactly, and it doesn't reproduce on my
system (and the example only has 2 expandes, not 3...), but it sounds like
you might be seeing a symptom of
https://bugzilla.gnome.org/show_bug.cgi?id=774134
which is fixed in current releases of gtk 3.22.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK3 - GtkExpander problem, bug ?

[Matthias Clasen]

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 nice working example, I played with
> it to illustrate the
> bug because it happens with your code too, check the new 'test.c' file
> attached !
>
> I simply added a third expander and a third set of buttons, I invite you
> to compile the code attached,
> and play with it you will see, that at same point even it stops to
> function properly.
>
> To start to have errors you can follow the following sequence:
> 1) open the first expander
> 2) open the second
> 3) open the third
> 4) close the second
> 5) starting clicking on the second expander location (without buttons
> visible) and it starts.
>
> I can only guess that the more expander you use the more messy it will get
> ... hence the problems
> with my program that uses 10.
>
>
I can't be too sure since you don't say which version of gtk this is with,
exactly, and it doesn't reproduce on my
system (and the example only has 2 expandes, not 3...), but it sounds like
you might be seeing a symptom of
https://bugzilla.gnome.org/show_bug.cgi?id=774134
which is fixed in current releases of gtk 3.22.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk 3 stuck menu bug on Mac

[Matthias Clasen]

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
>> > following two checks in function gtk_menu_motion_notify() (gtkmenu.c)
>> return
>> > false and the function is thus aborted at this point:
>> >
>> >   menu_item = gtk_get_event_widget ((GdkEvent*) event);
>> >   ...
>> >   if (!GTK_IS_MENU_ITEM (menu_item) ||
>> >   !GTK_IS_MENU (parent))
>> >   return false;
>>
>> Looking further at this issue, the problem is probably not a timing issue
>> like
>> I first considered in my previous email. Fact is that the wrong widget
>> under
>> the mouse pointer is resolved forever whenever this issue starts to occur:
>>
>> At this code location above, the gtk_menu_motion_notify() function expects
>> menu_item to be a "GtkMenuItem" gobject class, however when this issue
>> occurs,
>> menu_item is pointing at its parent "GtkMenu" gobject instead.
>>
>> I would understand if this misbehavior just happens immediately after a
>> new
>> menu pops up. But whenever this stuck menu issue occurs, I can continue to
>> move the mouse pointer over all the visible menu items for hours and the
>> resolved toplevel widget under the mouse pointer (resolved by the Quartz
>> implementation) is always the GtkMenu widget instead of the respective
>> GtkMenuItem widget.
>>
>> Since this issue only seems to happen on Mac, and since it worked
>> flawlessly on
>> Mac before, and since I see the Quartz implementation hasn't really
>> changed
>> (significantly) in the last couple years, was there some kind of important
>> change in gtk 3 that still would need to be applied to the Quartz driver?
>>
>
> No-one's really maintaining the Quartz backend at the moment, so if you
> felt like investigating this it would be really appreciated. You could try
> a 'git bisect' to see what change in GTK3 might have caused the regression
> and that would probably make it easy to see what would need to be changed
> in the Quartz backend.
>
>
As Philip, a git bisect might be helpful. But keep in mind that OS X builds
of GTK+ tend to include quite a few non-upstream patches, so keep any eye
out for those.
___
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)

[Matthias Clasen]

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
> > > 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:
> > > 
> > > * The first item in a directory is selected by default, so a
> > >   double-click on it misbehaves. Specifically, if that item is a
> > >   directory, the first click enters the directory, and the second
> > >   click will apply to whatever is listed first in that directory
> > >   (which is also selected by default, so effect is immediate.)
> > > This
> > >   is unexpected and quite confusing.
> > > * The ability to activate a selected file or directory with a
> > > single
> > >   click interacts badly with selection of multiple files. If you
> > >   start the selection with a file which was already selected,
> > > then
> > >   that file is immediately opened, before you have a chance to
> > >   complete your selection.
> > > * This new behavior is inconsistent with Nautilus, GTK 2
> > > applications
> > >   (which are sill many) or basically any other existing GUI
> > > toolkit.
> > >   Having incompatible behavior between applications is confusing
> > > for
> > >   the user.
> > > * 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.
> > > 
> > > If the problem that this change was supposed to address is that
> > > double-clicking fast is a challenge for some people, this issue
> > > should be addressed at the desktop environment level, by
> > > accessibility tools and/or mouse configuration. The GTK 3 file
> > > chooser is way too high level and specialized to handle this.
> > > 
> > > So the best thing to do is to revert this change. Ubuntu has
> > > already
> > > done so, and SUSE is in the process of doing the same.
> > > 
> > > https://bugzilla.gnome.org/show_bug.cgi?id=758065
> > > 
> > 
> > You are just bringing back the complaints about double-click.
> > 
> > There is no winning here, and I will not support any simple
> > reversal
> > unless it comes along with a person who is willing to maintain the
> > filechooser long-term, and field all the complaints from the 'its
> > still
> > not the same as nautilus' crowd.
> > 
> > IMO the way forward for the file chooser in GTK+ is
> > GtkFileChooserNative, making this entire mess somebody elses
> > problem.
> 
> Can't you just add ability to change single- or double-click behavior
> in 
> dconf?
> 
> For example you can create setting 
> "/org/gtk/settings/file-chooser/click-mode" with two possible values 
> "double" or "single".
> If "click-mode" is set to "double", do nothing because this is
> default 
> behavior of GtkTreeView. If "click-mode" is set to "single", set 
> "activate-on-single-click" property of GtkTreeView class to "true".
> 
> It's all. It seems to me it would be simple to maintain in the
> future. 
> And this way is more consistent — you always have to double-click or 
> single-click. Also you don't have to write a lot of code — all it's 
> needed is in GtkTreeView now.

Adding an option is not a solution at all, thats just a way to avoid
finding a solution.
___
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)

[Matthias Clasen]

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:
> 
> * The first item in a directory is selected by default, so a
>   double-click on it misbehaves. Specifically, if that item is a
>   directory, the first click enters the directory, and the second
>   click will apply to whatever is listed first in that directory
>   (which is also selected by default, so effect is immediate.) This
>   is unexpected and quite confusing.
> * The ability to activate a selected file or directory with a single
>   click interacts badly with selection of multiple files. If you
>   start the selection with a file which was already selected, then
>   that file is immediately opened, before you have a chance to
>   complete your selection.
> * This new behavior is inconsistent with Nautilus, GTK 2 applications
>   (which are sill many) or basically any other existing GUI toolkit.
>   Having incompatible behavior between applications is confusing for
>   the user.
> * 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.
> 
> If the problem that this change was supposed to address is that
> double-clicking fast is a challenge for some people, this issue
> should be addressed at the desktop environment level, by
> accessibility tools and/or mouse configuration. The GTK 3 file
> chooser is way too high level and specialized to handle this.
> 
> So the best thing to do is to revert this change. Ubuntu has already
> done so, and SUSE is in the process of doing the same.
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=758065
> 

You are just bringing back the complaints about double-click.

There is no winning here, and I will not support any simple reversal
unless it comes along with a person who is willing to maintain the
filechooser long-term, and field all the complaints from the 'its still
not the same as nautilus' crowd.

IMO the way forward for the file chooser in GTK+ is
GtkFileChooserNative, making this entire mess somebody elses problem.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] color fonts and CAIRO_OPERATOR_SOURCE

[Matthias Clasen]

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 to conclusions here. The only glyphs for which this
is a problem
with the current code are color glyphs. Most glyphs are still fine with
other operators. One
answer I gave on irc is: if you want to do fancy stuff with text, you
better control which
fonts are involved, so use a custom context (which can avoid loading color
glyphs for the
emoji family). But that is not a great answer. Some ideas for a better one:

- Add an api to find out if a fond has color glpyhs
- Add an api to control loading of color glyphs
- Clip when painting color glyphs to not affect the target outside the
extent of the glyph


> Oh and one more thing: Who updates cairo's docs and all the explanations
> on the web page? ("glyphs work like this, except when they do not").
>

 I can take a look at docs. No idea about the web page.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Matthias Clasen]

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 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com> wrote:
> >>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> >>>> 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?
> >>>> Text
> >>>> / glyphs are used as a mask and a mask does not have colors.
> >>>>
> >>>
> >>> There is no solution to that. The assumption in cairo's drawing model
> >>> about glyphs/fonts has simply been invalidated by reality.
> >>>
> >>>
> >>> Correct.
> >>
> >> Okay... so what is the new model? What happens when I draw a color glyph
> >> with operator XOR and a red source?
> >
> >
> > The red source is ignored for color glyphs because they are used as the
> > source.
>
> Hi again,
>
> I just came up with another question: How are overlapping glyphs handled?
>
> Let's say I have a red glyph and a blue glyph and I draw them in such a
> way that they overlap. Let's say this additionally overlaps with a
> non-colored glyph in the same position and I use a green source with 50%
> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)).
>
> What's the visible result?
>
>
Here is what my implementation does: It renders the color glyphs, in order,
followed by the non-color glyphs.

In practice, I don't think the case of mixed color and non-color glyphs in
the same call will be all that common.
Most apps will explicitly set a color font just for the emoji and they
won't render regular text with an emoji font,
with the result that runs of color glyphs and non-color glyphs will
typically be in separate calls.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Matthias Clasen]

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.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Color fonts

[Matthias Clasen]

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 of color glyphs, rewriting the inputs to remove handled clusters,
and then falls through
the show_glyphs code paths.

It seems to work ok, at least as far as gedit / pango let me test easily.
I'm less confident that
the CAIRO_TEXT_CLUSTER_FLAG_BACKWARD case is entirely correct, that is hard
for me
to judge.

An unrelated observation: pango treats the gap between an emoji modifier
base and a variant selector
as a cursor position. That looks like a bug.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Matthias Clasen]

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?
> Text
> / glyphs are used as a mask and a mask does not have colors.
> 

There is no solution to that. The assumption in cairo's drawing model
about glyphs/fonts has simply been invalidated by reality.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Color fonts

[Matthias Clasen]

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

[Matthias Clasen]

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 reworked
> version, which Chris Wilson objected to.  I agree with parts of his
> objection.  In particular, I don't think we should need to touch every
> compositor.
>
> IMO, this is how it should work:
>
>   - Extend glyph cache to also hold a color-glyph object possibly,
>
>   - Early on, perhals in _cairo_surface_show_text_glyphs(), ask
> scaled_font to see if it has color.  If it does, call a special function
> that iterates over the glyphs, for each, load it and see if it has color.
> Show the color ones using image ops, show the rest using text ops. Or just
> show all as image ops, that's feasible too.
>
> With the above, we wouldn't need to touch any compositor whatsoever.
>
> Unfortunately I'm too busy / lazy to do this any time soon.  However, I
> just bought my ticket to GUADEC, so working on it together there definitely
> is an option.
>
>
Thanks for the guidance on fixing up the cairo patchset. And yay for coming
to GUADEC!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Widget, drawing and event coordinates

[Matthias Clasen]

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 padding, border and margin, and any extra space that the widget might
be allocated.

Widgets need the content size of themeselves, and the outer size of their
children.

We should introduce new getters for content size and outer size, and phase
out
get_allocation, which is defined in terms of the parent window - not very
useful
anymore.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Widget, drawing and event coordinates

[Matthias Clasen]

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-allocating every single widget in it.
>
> In master, all event coordinates are relative to the widget allocation,
> which excludes widget margins, but includes css margin/border/padding.
>
> In wip/baedert/drawing[1], currently widget allocations are relative to
> the parent content allocation, which means the size_allocate
> implementations get an allocation of
> {0, 0, content_allocation_width, content_allocation_height} passed.
>

Not sure i follow here. If it is relative to the parent, why would x/y by 0?


> When drawing a widget, we first offset to the widget's content
> allocation and then call its snapshot implementation.


Can we define a few terms here ? I would like to make sure we all have
the same understanding of 'content', for example.

Do we use this https://www.w3.org/TR/CSS2/box.html as reference ?

As for input, the
> events get routed to a widget if the (toplevel relative) coordinates
> are inside the widget's margin allocation (widget allocation excluding
> the css margins as well). The coordinates the gestures (or
> gdk_event_get_coords) report however, are relative to that widget's
> content allocation, i.e. the values will be negative inside the widget's
> padding and border[1].
>

I don't think there is any problem with negative coordinates, apart from
not being used this happening ?


>
> So using the content allocation in size_allocate and snapshot
> implementations makes IMO perfect sense. One problem now is that
> gtk_widget_get_allocation (and the still private get_margin_allocation,
> get_content_allocation and get_border_allocation) are not relative to
> the widget's content allocation but to the parent's (since that's the
> coordinate space passed to gtk_widget_size_allocate_with_baseline).
> Changing this would however mean that gtk_widget_get_allocation can
> also return negative x/y coordinates.
>

How so ? Doesn't it return the content allocation, which you said earlier is
(0, 0, allocated-width, allocated-height) ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Call not guarded properly

[Matthias Clasen]

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_finish()' (in function
'g_app_info_launch_default_for_uri_finish()')

Looking around at similar calls, I reckon the function should maybe look
like this:-

gboolean
g_app_info_launch_default_for_uri_finish (GAsyncResult  *result,

GError   **error)
{
#ifdef G_OS_UNIX  // <--- This guard added by me 
  return g_openuri_portal_open_uri_finish (result, error);
#endif
  return FALSE;  // <--- and this added by me 
}

Should I flag this up in bugzilla or have I misunderstood something?

John

___
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: wip/baedert/drawing branch

[Matthias Clasen]

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. dragging on a scale slider means the entire scale gets a focus
> rectangle drawn, and entries get a focus rectangle drawn on top of their
> normal focus indication (the blue border). Dunno if we can just set
> can-focus to FALSE for appropriate (child) widgets and it works itself
> out.
>

I think that is not going to work.

What we need here is a way to decouple the actual focus location (ie where
key events get sent)
from the focus indication (what to draw the focus rectangle around). With
gadgets, this was
separated by having focus location always be the widget, while the
rectangle could be drawing
around one of the gadgets inside.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: wip/baedert/drawing branch

[Matthias Clasen]

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 few questions that are unclear to me, before we discuss the
individual things:

- What are the overall goals here ? That would be good to know. My guess
would be:
  1) Get rid of gadgets
  2) Full css drawing for all widgets
  anything else ?


>   - gtk_widget_real_snapshot calls gtk_widget_snapshot_child on all the
>child widgets of the given GtkWidget instance. This makes sense to me
>but it's already been problematic when porting GtkScale and GtkRange
>away from gadgets because GtkRange didn't override ::snapshot so
>GtkScale couldn't just subclass it and chain up, since it would cause
>all child widgets to be drawn twice.
>

Iirc, we've had this kind of issue with containers in the past. You can't
chain up without knowing
details about the parents implementation, and ordering becomes really
tricky to get right.

Remaining problems/open questions:
>  - Both GtkWindow and GtkPopover are special-cased in
>gtk_widget_snapshot to not draw the CSS background and border for
>them, since they are just too special. Getting rid of that special
>case would require porting them away from manual background drawing.
>  - There are lots of CSS problems now of course, e.g. GtkRevealer does
>not hide its padding anymore so GtkSearchBar always leaves a few
>pixels of space around, or the 4px margin around GtkMenu which is not
>applied inside the toplevel instead of outside. Also GtkCheckButton
>obviously.
>

So this is a case where we deviate from gtk3 theming and introduce
Adwaigtk-4.0


>  - Focus outlines work out pretty badly the way they are currently done
>in the branch. Wit gadgets, widgets had pretty fine-grained control
>over which gadget draws the focus outline.
>

How _are_ they done now ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of wip/carlosg/event-delivery

[Matthias Clasen]

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.c#n60
>

There's two overlay. One is passthrough, the other isn't: the "Numbers" are
supposed to be passthrough, while the entry is supposed to get input.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

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
> command.
>
> I'm not even sure, do we have this already ?
>

I fail to see the value of a man page that just repeats what --help already
tells me.  Why is this useful ?


> B.) Built-in support for bash completions, allowing optional overrides
> for the application to implement custom completion suggestions
> for selected options/arguments.
>

This on the other hand, is very useful. But hard to do in a way that is
generic enough for all possible styles of
commandline interface that people have built with GOption. Do you have a
suggestion for this ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 3.24?

[Matthias Clasen]

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 doing it.
>

No plans for a 3.24, no. I don't think there is much of a problem with
adding deprecations - they are really a tool to help people prepare for the
jump to the next version. If you want to stick with 3.22.x, there is no
reason to chase deprecations.

As for new API, we have been pretty careful so far, and only allowed some
very minor additions in 3.22.x. Any examples you are thinking of ?


>
> But if there will never be a GTK+ 3.24, we could have a gtkmm 3.24 that
> adds and deprecates API without causing too much confusion in the
> future.


I'm afraid that a gtkmm 3.24 that is based on gtk+ 3.22 would cause quite a
bit of confusion.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Functional programming with GLib

[Matthias Clasen]

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 GApplication.
>
>
What is lacking in the current incarnation of commandline option support in
GApplication?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSK review and ideas

[Matthias Clasen]

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 that are not visible.
>
> Of course, such culling relies on the fact that the children don't
> draw outside their allocation. Culling seems quite important to be
> able to handle 1s of rows in a listbox. So maybe we need to
> actually clip every widget.
>
> The above kinda contradicts each other, so we need to decide what to
> do here. My hunch is that the natural approach is a bit of both, where
> we always repaint the entire window (ignoring the damage region), but
> clip each widget to the allocation. That means clipping becomes a
> simple int-rect intersection (not a full region_t) which can be done
> fast (and maybe on the GPU) while still allowing highlevel culling on
> the widget allocation level. Does that seem right?
>

Note that we do have a clip rect for widgets that can be larger than
the allocation. So we can have the best of both worlds: widgets can
opt in to drawing outside their alllocation by setting a clip, and we
can still cull everything whose clip rect doesn't intersect the (gsk)
clip.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ hackfest 2017

[Matthias Clasen]

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.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk changes in the jhbuild moduleset

[Matthias Clasen]

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 called "gtk+" in the modulesets? Why not
>> > keep
>> > either gtk 3.x or gtk 4.x with that name?
>> >
>> > I'd expect the "gtk+" module to build GTK+ 4.x ("the latest").
>>
>> I have no strong opinion on this. Not having gtk+ in the moduleset
>> doesn't seem like a big deal to me. The + in the name is a bit
>> awkward, tbh.
>
> Losing the gtk+ module would mean third-party modulesets are forced to
> make a decision on whether they want gtk3 or gtk4, which seems like it
> might be desirable?

I ended up naming the modules gtk+-3 and gtk+, and I switched all
existing dependencies in the moduleset to gtk+-3 for now. 3rd party
modules will still have to make a decision. We can change the name to
gtk+-4 if that is preferred.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtk changes in the jhbuild moduleset

[Matthias Clasen]

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 applications over to  use gtk4 as they are found to work

If you see a problem with that, please let me know.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtkdoc-scan make interfaces public

[Matthias Clasen]

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
> include it but isn't a satisfiable solution.

What do you mean by cross references ?

What is missing from e.g.
https://developer.gnome.org/gtk3/stable/GtkAppChooser.html ?
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK+ 3.22 released

[Matthias Clasen]

GTK+ 3.22.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.22/

sha256 sum:

88d0bb584be7ecec965b82ba88a9cf0aafd6f03eff7447653295ab2341c74134
gtk+-3.22.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.22
==

The 3.22 release is the last development release in the GTK+ 3. series.
GTK+ 3.22 will be maintained as the long-term stable version of GTK+ 3,
and new development will move to the GTK+ 3.90.x releases. To learn more
about the GTK+ roadmap, read:

 
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk

Major new features include:

* The Wayland backend has support for drawing tablets

* The Wayland backend requires xdg-shell v6

* We have a gesture API for tablet support, GtkPadController

* GdkMonitor offers an API for richer information about connected outputs

* GdkGLContext supports GLES

* GtkScrolledWindow has new max-content-width/height properties that can
  affect the sizing behavior

* GtkShortcutLabel is a new widget that can display keyboard shortcuts
  in the same way that GtkShortcutWindow does

* A number of GTK+ APIs will now transparently use portals when used
  in a Flatpak sandbox, including GtkFileChooserNative, GtkPrintOperation,
  gtk_show_uri.

For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.22.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/README.in?id=3.22.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 21, 2016
Matthias Clasen
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GTK+ 3.22 released

[Matthias Clasen]

GTK+ 3.22.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.22/

sha256 sum:

88d0bb584be7ecec965b82ba88a9cf0aafd6f03eff7447653295ab2341c74134
gtk+-3.22.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.22
==

The 3.22 release is the last development release in the GTK+ 3. series.
GTK+ 3.22 will be maintained as the long-term stable version of GTK+ 3,
and new development will move to the GTK+ 3.90.x releases. To learn more
about the GTK+ roadmap, read:

 
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk

Major new features include:

* The Wayland backend has support for drawing tablets

* The Wayland backend requires xdg-shell v6

* We have a gesture API for tablet support, GtkPadController

* GdkMonitor offers an API for richer information about connected outputs

* GdkGLContext supports GLES

* GtkScrolledWindow has new max-content-width/height properties that can
  affect the sizing behavior

* GtkShortcutLabel is a new widget that can display keyboard shortcuts
  in the same way that GtkShortcutWindow does

* A number of GTK+ APIs will now transparently use portals when used
  in a Flatpak sandbox, including GtkFileChooserNative, GtkPrintOperation,
  gtk_show_uri.

For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.22.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/README.in?id=3.22.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 21, 2016
Matthias Clasen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.22 released

[Matthias Clasen]

GTK+ 3.22.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.22/

sha256 sum:

88d0bb584be7ecec965b82ba88a9cf0aafd6f03eff7447653295ab2341c74134
gtk+-3.22.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.22
==

The 3.22 release is the last development release in the GTK+ 3. series.
GTK+ 3.22 will be maintained as the long-term stable version of GTK+ 3,
and new development will move to the GTK+ 3.90.x releases. To learn more
about the GTK+ roadmap, read:

 
https://blog.gtk.org/2016/09/01/versioning-and-long-term-stability-promise-in-gtk

Major new features include:

* The Wayland backend has support for drawing tablets

* The Wayland backend requires xdg-shell v6

* We have a gesture API for tablet support, GtkPadController

* GdkMonitor offers an API for richer information about connected outputs

* GdkGLContext supports GLES

* GtkScrolledWindow has new max-content-width/height properties that can
  affect the sizing behavior

* GtkShortcutLabel is a new widget that can display keyboard shortcuts
  in the same way that GtkShortcutWindow does

* A number of GTK+ APIs will now transparently use portals when used
  in a Flatpak sandbox, including GtkFileChooserNative, GtkPrintOperation,
  gtk_show_uri.

For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.22.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/README.in?id=3.22.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 21, 2016
Matthias Clasen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Lack of documentation for custom GTK3 widgets in C

[Matthias Clasen]

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 documentation?
>
> Note: gtk-devel in the CC because the mailing list page indicates that
> documentation improvements should be discussed on it. Apologies if this
> is in error.

https://wiki.gnome.org/HowDoI/CustomWidgets

is my attempt at closing that gap from a few years ago.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.20

[Matthias Clasen]

GTK+ 3.20.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.20/

sha256 sum:

1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803
gtk+-3.20.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.20
==

Major new features include:

* The CSS machinery now uses element names for widgets and their components

* CSS margins, borders, padding and min-width and min-height are now much more
  consistently supported

* CSS features that have been added: radial gradients, recoloring symbolic
  icons, image(), calc(), rem

* Help overlays to document keyboard shortcuts and gestures

* GTK+ now reads .XCompose files

* GTK+ can use native file choosers on Windows

* A HighContrastInverse theme has been added

* The Wayland backend has full support for DND, kinetic scrolling, startup
  notification, primary selection, presenting windows, bell.

* Deprecations and removals: Style properties, testing infrastructure,
  geometry support in window sizing, GdkDeviceManager,
  gtk_text_iter_begins_tag, gdk_display_get_screen


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 Clasen
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GTK+ 3.20

[Matthias Clasen]

GTK+ 3.20.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.20/

sha256 sum:

1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803
gtk+-3.20.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.20
==

Major new features include:

* The CSS machinery now uses element names for widgets and their components

* CSS margins, borders, padding and min-width and min-height are now much more
  consistently supported

* CSS features that have been added: radial gradients, recoloring symbolic
  icons, image(), calc(), rem

* Help overlays to document keyboard shortcuts and gestures

* GTK+ now reads .XCompose files

* GTK+ can use native file choosers on Windows

* A HighContrastInverse theme has been added

* The Wayland backend has full support for DND, kinetic scrolling, startup
  notification, primary selection, presenting windows, bell.

* Deprecations and removals: Style properties, testing infrastructure,
  geometry support in window sizing, GdkDeviceManager,
  gtk_text_iter_begins_tag, gdk_display_get_screen


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 Clasen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.20

[Matthias Clasen]

GTK+ 3.20.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.20/

sha256 sum:

1c3d3a4a6e959ec8636ccb074bcdb8fa25c81ec56fbc70de6a3f5ef83ba6d803
gtk+-3.20.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.20
==

Major new features include:

* The CSS machinery now uses element names for widgets and their components

* CSS margins, borders, padding and min-width and min-height are now much more
  consistently supported

* CSS features that have been added: radial gradients, recoloring symbolic
  icons, image(), calc(), rem

* Help overlays to document keyboard shortcuts and gestures

* GTK+ now reads .XCompose files

* GTK+ can use native file choosers on Windows

* A HighContrastInverse theme has been added

* The Wayland backend has full support for DND, kinetic scrolling, startup
  notification, primary selection, presenting windows, bell.

* Deprecations and removals: Style properties, testing infrastructure,
  geometry support in window sizing, GdkDeviceManager,
  gtk_text_iter_begins_tag, gdk_display_get_screen


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.20.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.20.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 Clasen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: G_UTF8String: Boxed Type Proposal

[Matthias Clasen]

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't this increase processing demand?

It does. But whether that is a problem (in general, or for your
particular use case) can only be answered by  profiling. My theory is
that you won't be able to notice this on the profile at all, unless
all your application does is constantly operating on large amounts of
text. In which case, you really shouldn't be using GString to begin
with...

> 3) Wouldn't it be helpful to keep track of how many code points
> ("characters")are stored in the GString - a number which may be less than
> the value of GString.len - without needing to call g_utf8_strlen() each time
> to find out?
> 4) Would my efforts be better spent editing patches of "gstring.h" and
> "gstring.c" - or - to proceed as I am to introduce a parallel alternative?

I think we haven't gotten past the 'what is the problem you are trying
to solve - and is it a problem in the first place ?' part yet.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: G_UTF8String: Boxed Type Proposal

[Matthias Clasen]

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

Re: G_UTF8String: Boxed Type Proposal

[Matthias Clasen]

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 point above the Basic Multilingual
> Plane is really composed of two "Unicode characters", which are, of
> course, surrogate pairs.

Terminology can certainly be confusing at times, but I think that a
Unicode character is a perfectly well-defined entity, non-withstanding
the fact that it can be represented in various encodings (a utf8
sequence, a ucs4 word, a utf-16 surrogate pair, etc).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: G_UTF8String: Boxed Type Proposal

[Matthias Clasen]

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 mailing list's archives to see
> if anyone else has proposed anything similar. I have not found any.

I believe that you haven't found such a proposal because most people
don't see much use in a separate boxed type for utf8 strings. Every
string we pass around in GLib and GTK+, and every char * in their APIs
is expected to be in utf8. The few exceptions to this rule are
explicitly documented.

The main reason you mention for wanting such a type is to do away with
the need for repeatedly calculating the character count. I think this
falls into the same category as the length of the string in bytes - C
doesn't have counted strings either, and expects you to just call
strlen() over and over again. In practice, most strings we're handling
are short enough for this to not be much of an issue.

GLib already provides a number of utilities for dealing with utf8
strings in terms of characters, such as g_utf8_strlen,
g_utf8_substring, g_utf8_find_next/prev_char. We can certainly discuss
adding to that list, if there are glaring omissions.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: G_UTF8String: Boxed Type Proposal

[Matthias Clasen]

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 Unicode TR29 [0]? The number of code points isn't useful
> for editing in all cases, even after NFC normalization. Some grapheme
> clusters just don't have a single code-point representation.

I don't think there is any confusion in glib about this, really.
There is no mention of graphemes in GLib at all, its all just
characters. If you want graphemes, you need pango.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ hackfest 2016

[Matthias Clasen]

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 Hat office for these days.

Please add your name to the wiki if you plan to attend.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ hackfest 2016

[Matthias Clasen]

> 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 us a venue ?

What do others think ? Too late ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ hackfest 2016

[Matthias Clasen]

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
this page, too.

Hope to see some of you in Toronto!

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: API/ABI reports

[Matthias Clasen]

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 and I'd like to share my results with the 
> community. Hope this report will help Linux maintainers of these libraries to 
> be aware of ABI changes and added/removed binary symbols.
>
> Please let me know if some information in the report is incorrect.

As a tangential note: these sorts of trackers have somewhat limited
usefulness; many relevant changes are not directly reflected in the
C-level ABI/API. As an example, we are just discussing the
compatibility impact of adding a parameter to a signal in
https://bugzilla.gnome.org/show_bug.cgi?id=754743
The change will clearly cause problems for applications connecting to
this signal, but it will not show up in your ABI report at all.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: elementary would like to participate :)

[Matthias Clasen]

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 to
> implement something that uses for example revealer to animate tabs and the
> like. Can you make any technical recommendations before I get someone on
> the task?
>
>
GtkNotebook ... already has tabs, so it doesn't really need a freestanding
tabbar implementation. GtkStack does, though. So, I would at least see a
tabbar that can easily be used as a stack switcher. Note that we may need
some GtkStack extensions to make this work fully - e.g. we will need to
have a way to mark stack children as reorderable, closable, or draggable.

>From a technical perspective, I think I would like to see this being
implemented as a composite widget, using subwidgets for the tabs (similar
to GtkStackSwitcher). It may be a bit more challenging to achieve the
desired visuals and behavior with a composite, but I think the current
notebook tab look is more amenable to it than traditional tabs.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: elementary would like to participate :)

[Matthias Clasen]

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

Re: elementary would like to participate :)

[Matthias Clasen]

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
> Granite widgets into Gtk+. I think I know someone who would be interested
> in porting widgets and getting them into upstream. I guess the big question
> is what you all find most interesting.
>
>
Hey, thanks for coming in here. The tab bar widget is one that has been on
the GNOME designer wishlist for a long time too.
It is certainly the most complex widget on your list, but also the most
interesting one from my perspective.
I think there were some people (Carlos ?) who said they would take this on,
but so far nothing has materialized.
Using your implementation as a starting point would be great.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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_writable[2]. Then we may merge GstMiniObject
> > back
> > to glib?
>
> We (taking my GStreamer hat) havent heard of any interest from the GLib
> group for lightweight objects. Note that some library ended up also
> having these lightweight kind of object, hence may be interesting to
> eventually consolidate.
>

I think it is fair to say that there is more interest in fixing performance
of GObject than there is in introducing a miniobject type. Not sure if that
qualifies as 'interest in lightweight objects' or not.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Interface analyzer for GTK+

[Matthias Clasen]

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
> employ a theoretical framework known as the GOMS method[1]. As I hope
> to get my code accepted into GTK+, I have a few questions.
>
> I need to make GTK+ create an event log in runtime. I skimmed through
> documentation and the source code and I've found the --gtk-debug
> option. My idea was to add a one more debug flag named "goms" to make
> analysis conditional. Is it ok?
> It'd also be nice to have a way to specify a filename of the event log.
> Since it's not possible to squeeze the filename into the debug string,
> is it ok to introduce a second command line for this?
>
> I also wonder if there is a preferred format for dumps of this kind in
> GNOME. I think of going with XML since a lot of other things in GNOME
> like interface descriptions also make use of XML. Do you have better
> ideas or suggestions on this?
>
> If XML is ok, then what is the recommended way to generate XML output
> in GNOME? I saw that some parts of GTK+ are generating XML from inline
> strings and using convenience functions provided by GMarkup, which is
> rather not clean. Is it fine to generate dumps this way? I wonder if
> introducing a dependency on e.g. libxml would be better.
>
> [1] https://en.wikipedia.org/wiki/GOMS
>

I don't think putting such specialized logging directly into GTK+ is going
to be acceptable. I would suggest to either investigate if you can get what
you need through the accessibility framework, or look at creating a
loadable module that connects signal handlers to catch the necessary events
(you can eg look at libcanberra for how that works in practice).
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

[Matthias Clasen]

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

I'll look at following your recommendation for the others.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

[Matthias Clasen]

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 helped with maintainenance, and I should have
mentioned it. Thanks!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Dropping 'fringe' pixbuf loaders

[Matthias Clasen]

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-os-vendor move, depending on who installs them onto the system.
>>
>
> The only way to prevent the blame game you mention in a typical
> distribution where everything is installed through packages would be to
> stop supporting out of tree modules entirely, if I interpret your concern
> correctly.
>
> My point is that as long as that's the case, at least maintaining them in
> a central location gives people an aggregation point for fixes.
>

But they are not being maintained by anybody, and the fixes have not been
aggregating... every few years some security researchers decide to have a
look at image loaders, and then we get a bunch of overflows and corruptions
reported, and either me of Benjamin grudgingly fix them. And both of us are
tired of doing that.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 to reply to this before GUADEC but it slipped my mind. Here's a
 documentational Gist of supported CSS properties, as of GTK 3.8, that I put
 together a couple of years ago by reading the GTK source at the time. It may
 be useful to your discussion (if that discussion hasn't already happened) as
 an example.

 https://gist.github.com/ptomato/0fb634ef4098bb89026f

Thanks, this looks very useful, and is a nice complement to the list
of style classes that I've begun to put together here:
https://wiki.gnome.org/Projects/GTK%2B/StyleClasses
___
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!

[Matthias Clasen]

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 to reply to this before GUADEC but it slipped my mind. Here's a
 documentational Gist of supported CSS properties, as of GTK 3.8, that I put
 together a couple of years ago by reading the GTK source at the time. It may
 be useful to your discussion (if that discussion hasn't already happened) as
 an example.

 https://gist.github.com/ptomato/0fb634ef4098bb89026f

Thanks, this looks very useful, and is a nice complement to the list
of style classes that I've begun to put together here:
https://wiki.gnome.org/Projects/GTK%2B/StyleClasses
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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!

[Matthias Clasen]

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)

[Matthias Clasen]

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 @@
*ksymp = GDK_Meta_R; break;
  case VK_APPS:
*ksymp = GDK_Menu; break;
 +case VK_DECIMAL:
 +  *ksymp = GDK_KP_Decimal; break;
  case VK_MULTIPLY:
*ksymp = GDK_KP_Multiply; break;
  case VK_ADD:


Thanks, applied.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Module-less pango vs pangox-compat

[Matthias Clasen]

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 before module-less pango hits RHEL.
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: hint for vertical writing mode to input method

[Matthias Clasen]

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 / attribute for this case.

 OSX / Cocoa
 drawsVerticallyForCharacterAtIndex method
 https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSTextInputClient_Protocol/index.html#//apple_ref/occ/intfm/NSTextInputClient/drawsVerticallyForCharacterAtIndex:

 Windows / TSF
 TSATTRID_Text_VerticalWriting attirubte
 https://msdn.microsoft.com/en-us/library/windows/desktop/ms629018%28v=vs.85%29.aspx


 Do you have a plan to add an attribute or API of vertical writing hint
 to GTK?   If nothing, could you add this to any property such as adding
 GTK_INPUT_HINT_VERTICAL_WRITING to GtkInputHints?


There's no 'plan' for this. Adding such a hint to the enum would be
pretty easy, of course. Note that these hints are currently not used
for anything in practice. No application (that I know of) sets them,
and no input method (that I know of) looks at them. How would your new
vertical writing hint be set or used ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.16.0 released

[Matthias Clasen]

GTK+ 3.16.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.16/

sha256 sum:

ce617318fe18092383cf6ed5d8c688a95a97f2d4c68481317a6a531e288c26ea
gtk+-3.16.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.16
==

Major new features include:

* GDK supports rendering windows using OpenGL; currently
  this is implemented for X11 and Wayland using libepoxy

* GtkGLArea is a new widget for rendering with OpenGL

* GtkStackSidebar is a new controller for GtkStack that looks
  like a sidebar

* GtkModelButton is a button that can be used with a GAction as 'model'

* GtkPopoverMenu is a GtkPopover subclass that makes it easy to
  create menu-like popovers

* Scrolling has been overhauled
 - Scrollbars can be overlayed
 - There is a 'scrolled off' indication
 - Signals ::edge-reached and ::edge-overshot have been added
 - The new GTK_POLICY_EXTERNAL policy allows scrolling without
   a visible scrollbar

* An experimental Mir backend has been added

* Deprecations and removals:
  gdk_window_set_static_gravities, gdk_window_set_composited,
  gtk_style_context_get_background_color, gtk_style_context_get_border_color,
  gtk_settings_set_string/long/double_property, gtk_settings_install_property,
  GtkStyleProperties, gdk_cursor_new, gdk_*_libgtk_only,
  GtkCellRendererPixbuf::follow-state


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.16.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.16.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 22, 2014
Matthias Clasen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK+ 3.16.0 released

[Matthias Clasen]

GTK+ 3.16.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.16/

sha256 sum:

ce617318fe18092383cf6ed5d8c688a95a97f2d4c68481317a6a531e288c26ea
gtk+-3.16.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.16
==

Major new features include:

* GDK supports rendering windows using OpenGL; currently
  this is implemented for X11 and Wayland using libepoxy

* GtkGLArea is a new widget for rendering with OpenGL

* GtkStackSidebar is a new controller for GtkStack that looks
  like a sidebar

* GtkModelButton is a button that can be used with a GAction as 'model'

* GtkPopoverMenu is a GtkPopover subclass that makes it easy to
  create menu-like popovers

* Scrolling has been overhauled
 - Scrollbars can be overlayed
 - There is a 'scrolled off' indication
 - Signals ::edge-reached and ::edge-overshot have been added
 - The new GTK_POLICY_EXTERNAL policy allows scrolling without
   a visible scrollbar

* An experimental Mir backend has been added

* Deprecations and removals:
  gdk_window_set_static_gravities, gdk_window_set_composited,
  gtk_style_context_get_background_color, gtk_style_context_get_border_color,
  gtk_settings_set_string/long/double_property, gtk_settings_install_property,
  GtkStyleProperties, gdk_cursor_new, gdk_*_libgtk_only,
  GtkCellRendererPixbuf::follow-state


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.16.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.16.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 22, 2014
Matthias Clasen
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

GTK+ 3.16.0 released

[Matthias Clasen]

GTK+ 3.16.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.16/

sha256 sum:

ce617318fe18092383cf6ed5d8c688a95a97f2d4c68481317a6a531e288c26ea
gtk+-3.16.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.16
==

Major new features include:

* GDK supports rendering windows using OpenGL; currently
  this is implemented for X11 and Wayland using libepoxy

* GtkGLArea is a new widget for rendering with OpenGL

* GtkStackSidebar is a new controller for GtkStack that looks
  like a sidebar

* GtkModelButton is a button that can be used with a GAction as 'model'

* GtkPopoverMenu is a GtkPopover subclass that makes it easy to
  create menu-like popovers

* Scrolling has been overhauled
 - Scrollbars can be overlayed
 - There is a 'scrolled off' indication
 - Signals ::edge-reached and ::edge-overshot have been added
 - The new GTK_POLICY_EXTERNAL policy allows scrolling without
   a visible scrollbar

* An experimental Mir backend has been added

* Deprecations and removals:
  gdk_window_set_static_gravities, gdk_window_set_composited,
  gtk_style_context_get_background_color, gtk_style_context_get_border_color,
  gtk_settings_set_string/long/double_property, gtk_settings_install_property,
  GtkStyleProperties, gdk_cursor_new, gdk_*_libgtk_only,
  GtkCellRendererPixbuf::follow-state


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.16.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.16.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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 22, 2014
Matthias Clasen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I'm done with O_CLOEXEC

[Matthias Clasen]

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 a race between the creation of a file descriptor
 and marking it O_CLOEXEC vs. a fork() that may be happening in another
 thread.  This has led to the creation of a whole bunch of new syscalls
 to allow creation of file descriptors that already have O_CLOEXEC set
 from the start, thus avoiding the race.  We have tried to use these
 syscalls where possible, but they usually are not part of POSIX.
 Somethings they are completely unavailable, even in Linux, or when they
 are available, they have other annoying limitations.

'Not part of POSIX' has never stopped us from using something in glib:
atomics, futexes, inotify, pipe2, libelf, to name just a few...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I'm done with O_CLOEXEC

[Matthias Clasen]

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() was a bit of a straw that broke the camel's back case.  I could
 point at the existence of g_unix_open_pipe() as a similarly ridiculous
 case, or many others.

 I'm also not impressed by the inaccurate categorisation.  I thought I
 explained fairly clearly why I believe that leaked fds will _not_ be the
 case, even without O_CLOEXEC.

 I was looking for some slightly more constructive arguments...

Before we can have constructive arguments, we first need to understand
what you are actually proposing. Most of your mail was an extended
whine about inadequacies of posix in general, and fd inheritance in
particular. Jasper asked the right question:

Will you accept patches that add cloexec-correctness where it is
missing, in the future ?

Are you actually suggesting that we rip out all code that is currently
doing the right thing, cloexec-wise ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: I'm done with O_CLOEXEC

[Matthias Clasen]

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 created on UNIX
 via naive fork() and exec(), the default is that the process will
 inherit all of the file descriptors of the parent.  This makes a lot of
 sense for stdin, stdout and stderr, but almost nothing else.

 This has been the cause of a lot of strange problems over the years.
 The typical example: a process will open a listener socket at some point
 and sometime later will call a library function that does a naive
 fork()/exec() of a helper process that hangs around past the lifetime of
 the original program.  When you try to restart the first program, the
 socket is still being held open by the helper and the new instance can't
 bind it again.

 There are two fixes to this problem.

 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 between the creation of a file descriptor
 and marking it O_CLOEXEC vs. a fork() that may be happening in another
 thread.  This has led to the creation of a whole bunch of new syscalls
 to allow creation of file descriptors that already have O_CLOEXEC set
 from the start, thus avoiding the race.  We have tried to use these
 syscalls where possible, but they usually are not part of POSIX.
 Somethings they are completely unavailable, even in Linux, or when they
 are available, they have other annoying limitations.

 The other fix to the problem is one that we have had in place for a long
 time in the g_spawn_*() family of APIs, and also in the new GSubprocess
 API.  The trick involves close()ing all fds (except stdin/out/err) each
 time we do a fork()/exec() pair.

 Assuming it is practised universally, only one of these fixes is
 necessary.

 Today I am suggesting that we completely abandon our attempts to follow
 the first approach.  I'm done with O_CLOEXEC.

 What led me to this was the dup3() system call.  This is a variant of
 dup2() that was added (as part of the efforts mentioned above) to avoid
 the O_CLOEXEC race:

   int dup3(int oldfd, int newfd, int flags);

 unfortunately:

   dup3(0, -1, 0)  = -1 EBADF (Bad file
   descriptor)

 which means that using this as a stand-in for dup() is a no-go.  I could
 probably work around that by creating a new eventfd() or unbound UNIX
 socket in order to get a new fd number (while being careful to mark it
 as O_CLOEXEC as well) before using dup3().  We could probably also get
 this fixed in Linux, but dup3() has already been widely copied and we
 would then have to go about detecting which implementations are working
 and which aren't, and include a fallback (which would have to be
 implemented using the same dirty hacks mentioned above).  I've had
 enough with these games, and this isn't really about dup3() anyway.

 O_CLOEXEC is useless.

 Okay.  O_CLOEXEC is useful for one thing: when spawning a new process
 using fork()/exec(), you may want to know if exec() worked.  An old
 trick for this is to create a pipe and mark the writer end O_CLOEXEC.
 The reader end will read EOF (due to the close of the writer) once
 exec() has succeeded.  Otherwise, you can indicate the error by sending
 some other data through the pipe and calling exit().

 Aside from that, O_CLOEXEC is useless.

 So: starting today I'm going to stop worrying about O_CLOEXEC being set
 on every file descriptor that GLib creates.  I'm not going to go and
 retroactively tear things out where they are already working, unless it
 would provide a substantial cleanup or fixes an actual bug.  I'm not
 just going to go around looking for #ifdefs to remove.

 I believe this is justified for a few reasons:

  - during the GSubprocess discussion, I originally held the opposite
  opinion, but eventually became convinced (by Colin) to see the
  inherit-by-default behaviour of exec() as nothing more than a
  questionable implementation detail of the underlying OS.  Consequently,
  at the high level, GSubprocess provides an API that gives the caller
  direct control over what is inherited and what is not, and that's just
  the way that it should be.

  - this behaviour is not limited to GSubprocess.  Closing all fds before
  calling exec() is a common practice in modern libraries and runtimes,
  and for good reason.

  - fixing the few places that we spawn other programs is massively
  preferable to fixing the hundreds or thousands of places that we create
  new file descriptors

  - in the world of D-Bus activation, direct spawning of long-lived
  helper processes is just not something that we do anymore anyway.  fds
  are not the only thing we have to worry about here. 

GTK+ is branched too

[Matthias Clasen]

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/listinfo/gtk-devel-list

Re: GTK+, WM, desktops and CSD

[Matthias Clasen]

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 this is a anachronism IMHO, but that's
 another story.

I agree somewhat. We used them because we thought that they would be
almost universally supported. That turned out to be farther from the
truth than expected. But consider the alternative: If we had started
by suggesting a new cross-desktop spec for CSD, we would still be
arguing about protocols for proxying button clicks back and forth
today...

 Ideally, GTK should be able to use CSD even without a compositor. The
 only reason it requires a compositor is because it uses the shadows as
 resize handles. Ideally, it should use a larger border width when
 there is no compositor - But that would another set of patches as not
 directly related to the hint proposed.

Yes, I've been thinking that myself recently: We should fall back to
having 'fat borders' instead of 'invisible borders+shadow' if the
environment can't support them. A patch to do so would be most welcome
(I'm well aware that gtkwindow.c is not the easiest place to add new
functionality like this...)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: recently-used.xbel

[Matthias Clasen]

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 launch the GtkFileChooser I'll see 
 an entry called Recently Used which lists the file I opened last time.  As 
 the number of entries increases, they get saved in a persistent file called 
 recently-used.xbel.  This all seems to be a feature of gtk+.  There's 
 nothing in the actual app that handles any of this.

 Currently we're using gtk+2 (as opposed to gtk+3).  Is there any way I can 
 modify what gets saved in 'recently-used.xbel'?  For example, if I DIDN'T 
 want it to include files with a particular extension, does the existing code 
 provide any mechanism for achieving that?  In other words, I want the user to 
 be able to select files of that type - but I DON'T want them to get listed in 
 'recently-used.xbel'.

 Or alternatively...  if I ONLY wanted it to include files with certain 
 extension(s) can I specify that somehow in my application? Thanks.

There's no direct api to achieve this. You can probably get it done in
a few lines of code with GtkRecentManager::changed and
gtk_recent_manager_remove_item().
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: RFC: GtkPreview library

[Matthias Clasen]

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 preview to be used ?
nautilus, filechooser - anything else ? Having that list will make it
easier to judge whether the embedding api is suitable for all those
cases.

Also, it would be good to list some of the things that you expect to
preview: documents, videos, music, images - anything else ? Having
that list will help to get a sense for the interactivity that will be
required from the preview.

One thing we should keep in mind while designing this is that we hope
to make application more isolated from the host system (and from each
other) with https://wiki.gnome.org/Projects/SandboxedApps - what we
come up here should have a chance of working in such an environment.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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: https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

 this will make it easier for us to track the issue, review the code,
 and commit the change.

 This looks similar to (but not the same as) the patches I posted from
 analysing GTK+ with Clang static analyser in November, which are still
 awaiting review.

 I really hope we aren't going to end up with duplicate bug reports and
 duplicate patches because things are not getting reviewed. :'-(

 https://bugzilla.gnome.org/show_bug.cgi?id=712760


I can't say that I agree with them being very similar. Most of Maks'
patches were small, to the point, obvious oversight fixes that could
be reviewed in a minute, each. The static analysis 'fixes' are an
endless stream of mind-numbing can-never-happen corner cases of
dubious value. Just IMO, of course :-)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Matthias Clasen]

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 down, instead of being an entry *with* a drop down. maybe
 something like GtkDropdown? or GtkDropList?

I've spent some more time on the branch and ended up reworking things
a bit more. I've incorporated most of your suggestions. Wrt names,
I've renamed things to GtkOptionList (for the list widget) and
GtkOptionButton for the button with the popover. Still not great. The
test app is now called testoptionlist, and shows a more stuff:
multi-selection, and various alternative uses of the list widget
without a button.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Matthias Clasen]

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 these days).

 Is there any design rationale to remove the usual arrow?

You should try the actual thing... I had the same question, and added
the arrow back
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Matthias Clasen]

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 about 10 year old bugs getting wontfixed, or
philosophical questions about whether a toolkit should ever provide
more than one tool for a given job...

Please, it was fun to write this code, I was hoping you would have
some fun trying it out.

Anyway, really off now until the new year. Enjoy your new years party,
everybody!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

a new combo box

[Matthias Clasen]

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
GtkComboBox and
GtkComboBoxText. I've gone with GtkCombo for now, which has the
downside that there is a widget by that name in gtk2. Alternatives
might be GtkChoice or GtkComboButton (with a possible avenue for
making the list-of-choices available for direct embeeding as
GtkComboWidget later).

There are some lose ends in the code, like the interaction of grouping
and search, but it is complete enough to give it a try and evaluate
the design. If you want to try it, the code is in the wip/combo
branch, and there is a testnewcombo test app with some examples.

I'm off for a few days now - would be great to hear some feedback when
I come back.

Matthias
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: a new combo box

[Matthias Clasen]

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 true after your shoved off 2000+ lines to gtktreemenu.c.

 Honestly I would have rather proposed to just switch the whole internals
 of combobox to do the more modern looking thing using cell areas, which
 strikes me as the obvious way forward, bringing a new look to the combo
 without dropping any of the value of combobox, and every app using
 combobox automatically benefits - only that it would probably result in
 breaking API.

 Frankly I don't appreciate this let's rewrite everything from scratch
 attitude, it doesnt show a whole lot of respect to the users of our API,
 who would, I think have a justifiable expectation that their usage of
 combobox would not be labeled as obsolete at least until GTK+ 4.

 Sure, exceptions can be made within reason for dropping huge important
 parts of GTK+, but let's stick within reason right ? Has this been
 discussed ? Has it been concluded that there is no way forward with
 the existing API ? Where is that discussion ? What is the rationale ?

Thats one of the hardest questions, isn't it ?

Deciding when a codebase that you've invested a lot of time and effort
into has grown too old and complex, and it is better to start from
scratch ? I'm often struggling with this, and stick to fixing things
up to 'preserve existing investment' far too long. Of course, starting
over is not a panacea: you may end up repeating old mistakes, and do a
lot of work just to end up in the same place you started from. On the
flip side, its a chance to revisit old assumptions that are deeply
embedded in the old code, add modern features without having to
force-retrofit them into ancient code (and cause collateral damage in
the process).

That being said, I think the case for GtkComboBox is pretty clear-cut.
It was doomed from the beginning by the mistake to force two pretty
distinct user experiences (option menus and combo boxes) into a single
widget. You've made a valiant attempt to clean this up with the
introduction of GtkTreeMenu, but it is still a mess. Another mistake
was to expose a data-driven API (with models and cell renderers) for a
widget that most of the time is used in non-data-driven scenarios.
We've later tried to patch up that mistake by adding the simplified
GtkComboBoxText. But since it is a subclass, it inherits all of the
api problems of GtkComboBox. Lastly, there's a number of ill-advised
APIs in GtkComboBox that make it very hard to do any new
implementation of the same api: tabular menus, spanning columns, etc.
Almost as if to prove the last point, your last major refactoring of
GtkComboBox already broke a bunch of those APIs (e.g. col-span-column
is not working anymore).

You'll be happy to learn that the buildable API of GtkCombo is
pretty close to compatible with GtkComboBoxText (I should probably
rename the active property to active-id to get even closer), so for
most users, switching from GtkComboBoxText to GtkCombo should be as
simple as s/GtkComboBoxText/GtkCombo/ in their ui files.

Since you are asking about discussions and conclusion, I'll state that
in my opinion, combo boxes should not use (even less expose in the
api) cell renderers and tree models. I believe that is pretty much
agreed upon between most people who regularly touch GTK+ code (with
the exception of you, possibly).  Speak up if you disagree.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 at this point.


We can also add the patch to continuous and jhbuild if that helps.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

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

[Matthias Clasen]

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 Adwaita is always present in the list.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: State of gdk-pixbuf

[Matthias Clasen]

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
 itself to handling big images (especially black and white pictures would
 balloon in memory usage), and that its coverage for acceleration in
 manipulation and compositing is small (basically unaccelerated on
 anything but 32-bit x86 and Solaris).

 I think we need to start looking at a replacement for pixops, and a
 replacement for the GdkPixbuf format.

 I'm particularly interested to know what cairo, pixman and other image
 manipulation libraries can do for us. Benjamin surely has comments[2] :)

When I last talked to Soeren about it (several years ago), pixman
didn't support the pixel format that gdk-pixbuf is using.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gnome in the future?

[Matthias Clasen]

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.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve word boundaries for text widgets

[Matthias Clasen]

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 in GtkSourceView.

 What do you mean by basically Unicode?

I mean that it is the right default behavior to follow Unicode TR 29.

 The problems in GTK+:
 - the behavior is not consistent between GtkEntry and GtkTextView (and
   possibly GtkLabel too for word selection).
 - the current behaviors don't work well, since it uses only
   natural-language word boundaries.

 So I want to fix both points.

Fixing internal inconsistencies is a good idea, of course. Patches for
that would be most welcome.

For tayloring the text segmentation behavior for special situations,
such as code instead of natural language, a vfunc is the right
approach.

Does that make clear what I would like to see ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve word boundaries for text widgets

[Matthias Clasen]

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:

 step 1: create a vfunc for this
 step 2: implement a version of the vfunc that implements whatever behaviour
 you want

 what i think matthias doesn't want:

 step 1: implement the behaviour you want
 step 2: think about adding a vfunc

 i'm sure he'll correct me if i got this wrong.


My main motiviation is that 'we follow TR29' is much better in terms
of documenting it, testing it and diagnosing bugs in than 'do what vim
does'.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Improve word boundaries for text widgets

[Matthias Clasen]

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 may even want a way to use different word breaking
 rules in different regions of the buffer. As an example, you might
 have comments embedded in code.

 So having better defaults in GTK+ would be a first step, I think it's
 more important. The vfunc can be added later.

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 in GtkSourceView.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GTK+ 3.14.0 released

[Matthias Clasen]

GTK+ 3.14.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.14/
 ftp://ftp.gtk.org/pub/gtk/3.14/

sha256 sum:

68d6b57d15c16808d0045e96b303f3dd439cc22a9c06fdffb07025cd713a82bc
gtk+-3.14.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.14
==

Major new features include:

* Wayland:
 - We support Wayland 1.6 now
 - Touch is supported
 - Drag-and-Drop works
 - Support GNOME classic mode

* Theme:
 - Adwaita and its dark variant are now included and used as the
   default theme on all platforms
 - New states for links and for checked check- and radiobuttons
 - Icon theme support in CSS

* Multitouch support
 - Gesture framework
 - Widgets converted to use gestures internally

* Interactive debugging support

* An icon browser utility

* GtkListBox
 - multi-selection support

* OS X:
 - Better menu integration for GtkApplication

* Deprecations and removals:
 GdkColor, GtkMisc, GtkArrow, GtkStatusIcon, GtkNumerableIcon,
 GtkThemingEngine, many style properties, style regions, resize grips,
 .icon files, built-in icons, gdk_window_flush, drawing outside begin/end
 paint, gtk_widget_reparent, gtk_widget_region_intersect,
 gtk_container_reallocate_redraws


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.14.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.14.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 22, 2014
Matthias Clasen
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK+ 3.14.0 released

[Matthias Clasen]

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

[Matthias Clasen]

GTK+ 3.14.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.14/
 ftp://ftp.gtk.org/pub/gtk/3.14/

sha256 sum:

68d6b57d15c16808d0045e96b303f3dd439cc22a9c06fdffb07025cd713a82bc
gtk+-3.14.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.14
==

Major new features include:

* Wayland:
 - We support Wayland 1.6 now
 - Touch is supported
 - Drag-and-Drop works
 - Support GNOME classic mode

* Theme:
 - Adwaita and its dark variant are now included and used as the
   default theme on all platforms
 - New states for links and for checked check- and radiobuttons
 - Icon theme support in CSS

* Multitouch support
 - Gesture framework
 - Widgets converted to use gestures internally

* Interactive debugging support

* An icon browser utility

* GtkListBox
 - multi-selection support

* OS X:
 - Better menu integration for GtkApplication

* Deprecations and removals:
 GdkColor, GtkMisc, GtkArrow, GtkStatusIcon, GtkNumerableIcon,
 GtkThemingEngine, many style properties, style regions, resize grips,
 .icon files, built-in icons, gdk_window_flush, drawing outside begin/end
 paint, gtk_widget_reparent, gtk_widget_region_intersect,
 gtk_container_reallocate_redraws


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.14.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.14.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 22, 2014
Matthias Clasen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 3.14.0 released

[Matthias Clasen]

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

[Matthias Clasen]

GTK+ 3.14.0 is now available for download at:

 http://download.gnome.org/sources/gtk+/3.14/
 ftp://ftp.gtk.org/pub/gtk/3.14/

sha256 sum:

68d6b57d15c16808d0045e96b303f3dd439cc22a9c06fdffb07025cd713a82bc
gtk+-3.14.0.tar.xz


What is GTK+


GTK+ is a multi-platform toolkit for creating graphical user interfaces.
Offering a comprehensive set of widgets as well as facilities for creating
your own widgets, GTK+ is suitable for projects ranging from small one-off
tools to complete application suites.

GTK+ has been designed from the ground up to support a range of languages,
not only C/C++. Using GTK+ from languages such as Python, Vala and JavaScript
(especially in combination with gobject-introspection and the Glade GUI builder)
provides an effective method of rapid application development.

GTK+ is free software and part of the GNU Project. However, the licensing terms
for GTK+, the GNU LGPL, allow it to be used by all developers, including those
developing proprietary software, without any license fees or royalties.

Since its origins as the toolkit for the GNU Image Manipulation Program (GIMP),
GTK+ has been used in a wide range of software. Notably, GTK+ is the foundation
of the GNOME desktop.


What's new in 3.14
==

Major new features include:

* Wayland:
 - We support Wayland 1.6 now
 - Touch is supported
 - Drag-and-Drop works
 - Support GNOME classic mode

* Theme:
 - Adwaita and its dark variant are now included and used as the
   default theme on all platforms
 - New states for links and for checked check- and radiobuttons
 - Icon theme support in CSS

* Multitouch support
 - Gesture framework
 - Widgets converted to use gestures internally

* Interactive debugging support

* An icon browser utility

* GtkListBox
 - multi-selection support

* OS X:
 - Better menu integration for GtkApplication

* Deprecations and removals:
 GdkColor, GtkMisc, GtkArrow, GtkStatusIcon, GtkNumerableIcon,
 GtkThemingEngine, many style properties, style regions, resize grips,
 .icon files, built-in icons, gdk_window_flush, drawing outside begin/end
 paint, gtk_widget_reparent, gtk_widget_region_intersect,
 gtk_container_reallocate_redraws


For more details and lists of fixed bugs, see the NEWS file that is
included in the tarball, or see:

 http://git.gnome.org/browse/gtk+/plain/NEWS?id=3.14.0

For concerns about porting from older GTK+ releases, see the README file
that is included in the tarball, or see:

http://git.gnome.org/browse/gtk+/plain/README.in?id=3.14.0


Where to get more information about GTK+


Information about GTK+ including links to documentation can be found at:

 http://www.gtk.org/

An installation guide for GTK+ is found at:

 http://library.gnome.org/devel/gtk3/stable/gtk-building.html

Common questions:

 http://library.gnome.org/devel/gtk3/stable/gtk-question-index.html


Contributing


GTK+ is a large project and relies on voluntary contributions. We are actively
searching for new contributors in various areas and invite everyone to help
project development. If you are willing 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.


September 22, 2014
Matthias Clasen
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list