Notes from day 2

(decisions and concrete tasks marked in bold)

The day starts with an hour of quiet work and patch review

Allison comes by and does a separate glib review session with Philipp

First question to start us off: do we drop since 2/3 annotations from the docs, for 4.0 ? decision: yes, we only keep "since 4.0" around for new api

Another demo idea:

  • Write a vulkan rendering area similar to glarea, and steal some existing vulkan demos
  • A spreadsheet with a million rows

discussing glarea future plans: all taken care of with the texture rendering. May want to look at adding a vulkan area at some point

gtkcalendar: another old, miserable widget thats rarely used. if we want to modernize it, it should be broken into small private widgets and the odd text formatting api should be removed

listbox: Timm has a scalable, model-based version. we should make a branch that adds this as a new widget, to get some exposure. Still problematic: it adds children during size allocate. Can we make that officially ok ?

text view: short term idea: make GtkEntry support multiple lines, that should cover many needs where a text view is used now

gitlab migration:

  • we can migrate the git repo at any time
    • consensus seems to be that we start out with allowing merge commits, and reevaluate how well that works
  • strategy for bug migration:

    • close bugs not touched in >5 years

    • needinfo bugs not touched for >1 year

    • a month later, close the still needinfo ones
    • then we can triage the rest for migration

strategy discussion for 4.x:

  • adding new widgets is ok, reworking css machinery is not
  • start working on 5.0 right away
  • we need to communicate this expectation clearly

Long review session of the 4.0 checklist

Brief discussion of GtkEntry future:

  • Benjamin is not a fan of multiline entry
  • We talked again about splitting off icons and other gizmos

  • We need to make GtkEditable useful for the label breakup to make sense

Brief discussion about textview vs gsk: Emmanuele is concerned about the amount of commands we send if we use the glyph cache for all the text in a view - decision: we will write a big label test case

Lunch break

4.0 Blocker bugs:

  • black shadow when resizing

More detailed GLib discussion: things to get into glib

  • Meson: feature parity for 2.58; think about dropping autotools in 2.60 or 2.62? https://bugzilla.gnome.org/show_bug.cgi?id=790954

    • Target for 2.58: https://bugzilla.gnome.org/show_bug.cgi?id=790954

    • Conclusion:
      • We’d like to target this metabug to be fixed for 2.58
      • We’d then keep the autotools and meson build systems in parallel for at least one release, but push for people to use meson where possible
      • In particular, we’d like to be sure that Windows, OS X, one of the BSDs, and the major Linux distributions all build GLib OK using meson
      • Once we’re satisfied that we have no regressions (and no later), we can drop autotools
  • GRegex migration to PCRE2:
  • Unicode tables updates
    • We’re already at version 10; no need to do anything here
  • GBytes APIs in GIOStreams, write, write_all
    • desrt wants to rewrite this so that there are ~4 vfunc on input/output stream, supporting different data models; abstract input/output stream provides conversions between the data models; each user uses the data model most appropriate to what they’re connecting to, and we aim to minimise the number of copies
    • Non-blocking (don’t return a GError for it; that’s terribly slow)
    • Different data models (POSIX, GBytes, scatter/gather, etc.)
    • Sync vs async
    • EINTR (never expose this to the user)
    • EOF (make handling this case consistent and easy)
    • *_all() variant
    • desrt to take this on
    • desrt won’t commit to a timeline; needs to talk to her new boss
    • desrt needs to talk to Benjamin about it
  • Buffer queues: pull the implementation out of GStreamer; would have been used in the X11 ICCM implementation in GTK+ (2.58?)
  • Thumbnailing:

    • See mailing list (https://mail.gnome.org/archives/gtk-devel-list/2018-January/msg00015.html)

    • TODO: No bugs seem to be open about this?
    • g_file_ensure_thumbnail_async() or similar, which returns a GIcon(?): the existing thumbnail, if it’s valid; otherwise, a newly generated thumbnail
    • GIO extension point which can request thumbnails to be created
    • Crux of the issue is that GTK+ can currently only display thumbnails for directories which you’ve previously visited in Nautilus, since only Nautilus actively thumbnails things
  • think about fd-based GIO replacement
    • This is essentially libglnx
    • Just leave it as libglnx and see who picks this up and how it pans out

  • Finalisation (https://bugzilla.gnome.org/show_bug.cgi?id=681334)

    • vfunc for get_main_context_for_this_object()
    • Potentially target 2.58 with this; Philip to look at how hard it will be

  • CI and GitLab (https://gitlab.gnome.org/Infrastructure/GitLab/issues/123)

  • Maintainership:
    • Philip can’t maintain GLib on his own
    • mclasen and ebassi will continue to be available for patch reviews
    • Reach out to recent OS X and Windows contributors to see if they would like to contribute more
    • Reach out to recent GIO contributors to see if they would like to contribute more

Random hacking

a somewhat meandering discussion of object builder pattern and how to make it bindable. We will use this pattern increasingly in GTK+, so we should do it the same way everywhere:

  • make the builder refcounted
  • make it a boxed object
  • add new and free
  • add a getter for the constructed object
  • add a free_to_... function that returns the constructed object and unrefs

idea for toolbar modernization

  • allow any widget
  • replace the overflow menu with a popover and just reparent the widgets

Hackfests/GTK2018/Day2 (last edited 2018-02-03 08:25:11 by MatthiasClasen)