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