feat! (major-refactor): break gtk into multiple build-targets

[Muqtxdir]

gtk

• build: split gtk2, gtk3, gtk4 build logic into individual meson files for better readability
• build: expose gtk-* targets as build-options (in future if we wanna disable any gtk component)
• gtk-2.0: automate assets generation
• gtk-3.0: move inside gtk/src/gtk-3.0
• gtk-4.0: move inside gtk/src/gtk-3.0
• upstream: use upstream colors for $selected_bg_color will be done post 26.04 release

[Muqtxdir]

@3v1n0 from earlier discussion: do you think we should split gtk package into:

• yaru-theme-gtk2
• yaru-theme-gtk3
• yaru-theme-gtk4

then we move gtksourceview bits into its own thing?

[3v1n0]

Diff is too big for github to handle it, however on:

# Create assets directory and run the render script directly
  gtk2_assets_target = custom_target(
    '@0@-gtk2-assets'.format(theme_name),
    input: [gtk2_svg_to_use, gtk2_assets_txt],
    output: '@0@-gtk2-assets.stamp'.format(theme_name),
    command: [
      'bash', gtk2_render_script_path,
      '@INPUT0@',                    # SVG file
      '@INPUT1@',                    # assets.txt
      '@PRIVATE_DIR@/assets',        # output directory
      '--clean'
    ],
    build_by_default: true,
  )

I think we should do something similar that we do for icons too, so that both SVGs and PNGs are generated only by CI and not by developers unless they don't run a custom target that is only exposed for that reason, but not done while doing the simple meson install.

[3v1n0]

Regarding commit ecd796c I'm unsure if we want to go there, that would imply also quite a bit of synchronization distro-side, and prepare migration scripts.

While this needs design review (/cc @juanruitina) I feel that it would be better to leave it post 26.04, to avoid having to deal with such migration in the LTS cycle (/cc @aleasto).

[3v1n0]

No please, if we need to generate something, let's do it in CI, to avoid having the builders to do all the job

[Muqtxdir]

sure, will remove these

[3v1n0]

Why this?

If we need to re-use stuff for the dark side I'd prefer to have explicit dependencies.

Not great, but we can use also set_variable and get_variable to access to specific variables that are defined programmatically

[Muqtxdir]

I think I'll drop this logic in favour of icons render logic that we use with ci tooling

[Muqtxdir]

Hi @3v1n0 I force-pushed on top of my previous approach and here is the tldr;:

• Dropped the build-time asset rendering; gtk-2.0 now just copies RC files and PNGs directly (havent tried doing your suggestion of ci building the pngs as we wanna start flagging and seperating gtk2 as legacy?)
• Restructured from gtk/src//{gtk-2.0,gtk-3.0,gtk-4.0}/ to gtk/src/{gtk-2.0,gtk-3.0,gtk-4.0}// so each GTK version owns its appropriate files
• Split the monolithic gtk/src/meson.build into per-version build files (gtk-2.0/meson.build, gtk-3.0/meson.build, gtk-4.0/meson.build)
• Replaced the single -Dgtk option with -Dgtk-2, -Dgtk-3, -Dgtk-4
• Used set_variable/get_variable to share accent colour data across subdirs

Questions:

• Do I split the yaru-theme-gtk into multiple versions now with this chnage?