Until recently geany was built with gtk2
In the latest commit it has been changed to gtk3
Backinfo
Geany is effectively a GUI around a text box, the GUI toolkit is very important. Geany supports both the gtk2 and gtk3 guis. The GTK3 variant has some disadvantages (size, file-picker dialogs, etc).
From a user perspective: gtk2 and gtk3 are completely unrelated products with little in common functionally or graphically. Having the package silently change is a bit jarring, like a change between qt and gtk3.
IMHO this big of a change (when it's optional) should be associated with a package name change (eg geany-gtk3).
I'll see if I can pullreq some pkgbuilds, but I'm not sure how the -dev packages will behave. The two builds of geany conflict with each other (both file layout and at runtime due to IPC).
it's easy enough to add a build option for (mostly copied from deadbeef):
--- srcpkgs/geany/template
+++ srcpkgs/geany/template
@@ -3,10 +3,13 @@
version=1.34
revision=1
build_style=gnu-configure
-configure_args="--enable-vte --enable-gtk3"
+build_options="gtk3"
+build_options_default="gtk3"
+configure_args="--enable-vte
+ $(vopt_if gtk3 '--enable-gtk3 --disable-gtk2'
'--enable-gtk2 --disable-gtk3')"
hostmakedepends="automake gettext-devel glib-devel libtool pkg-config intltool
python"
-makedepends="gtk+3-devel"
+makedepends="$(vopt_if gtk3 gtk+3-devel gtk+-devel)"
depends="hicolor-icon-theme desktop-file-utils"
short_desc="Fast and lightweight IDE"
maintainer="Juan RP <[email protected]>"
some of this was needed for geany-plugins (based on the diff for 1.33 -> 1.34):
--- srcpkgs/geany-plugins/template
+++ srcpkgs/geany-plugins/template
@@ -3,13 +3,19 @@
version=1.34.0
revision=1
build_style=gnu-configure
+build_options="gtk3"
+build_options_default="gtk3"
configure_args="PYTHON=/usr/bin/python2 --enable-all-plugins --disable-devhelp
- --disable-webhelper --disable-debugger --disable-geanypy --disable-multiterm"
+ --disable-webhelper
+ $(vopt_if gtk3 '--disable-debugger --disable-geanypy --disable-multiterm'
+ '--disable-markdown --disable-peg-markdown')"
hostmakedepends="automake gettext-devel intltool libtool pkg-config vala
glib-devel python-devel"
makedepends="geany-devel lua51-devel ctpl-devel libwnck2-devel GConf-devel
zlib-devel gpgme-devel enchant2-devel pygtk-devel libgit2-devel libsoup-devel
- gtkspell-devel webkit2gtk-devel vte3-devel"
+ gtkspell-devel
+ $(vopt_if gtk3 'webkit2gtk-devel vte3-devel'
+ 'vte-devel')
short_desc="Geany IDE plugins"
maintainer="Steve Prybylski <[email protected]>"
license="GPL-2.0-or-later"
@@ -36,7 +42,7 @@
geany-plugins-extra_package() {
short_desc+=" - extra plugins"
pkg_install() {
- for p in geanygendoc geanylua geanypg geniuspaste \
+ for p in geanygendoc geanylua geanypg $(vopt_if gtk3 '' 'geanypy') geniuspaste \
git-changebar pretty-printer spellcheck updatechecker; do
if [ -x ${DESTDIR}/usr/lib/geany/${p}.so ]; then
vmove usr/lib/geany/${p}.so
@@ -50,6 +56,8 @@
done
vmove usr/lib/geany-plugins/geanylua
+ if [ "$(vopt_if gtk3 'yes' 'no')" = 'no' ]; then
+ vmove usr/lib/geany/geanypy
+ fi
}
}
not tested:
These are my thoughts on this, for whatever its worth.
GTK2 is unmaintained. Most applications that use it are either unmaintained or have a plan to migrate to GTK+3. Most users of e.g. Inkscape, GIMP, XFCE apps, etc. expect to have the latest stable version of these apps when they are released, with the build options as close to those preferred by upstream as possible. In the future, this will mean GTK3. Keeping users on GTK2 even after upstream has migrated is not the behavior used by any other distro, so there is no precedent. The two issues you listed for disadvantages of GTK3 (size, file-picker dialogs) are controllable by themes and/or modules.
Rather than trying to maintain the GTK2 APIs, your efforts may be better spent in modifying GTK3 to meet your aesthetic and functional priorities.
The GTK3 variant has some disadvantages
Hum, these seem very much like your own opinion. GTK+3 still provides a functional file picker and has many advantages, like proper scaling for HiDPI devices, Wayland support, better theming, better performance and actual support by upstream.
like a change between qt and gtk3
Uhh... more like a change from Qt4 to Qt5...which only makes sense.
Sure, such a change means... change which one has to adopt for (and one may prefer the old behaviour), yet we can't stay with old stuff forever.
@huglovefan : Thanks for the idea, I have not come across the vopt_if functionality before.
My best understanding of the docs: this would not create a separate package on the mirrors, but would instead provide an option if you compile the template yourself. I'm not sure of the advantage of this.
I have a separate geany-gtk2 template I'm working on at the moment, however I'm hitting some strange corner cases with how xbps manages package conflicts re packages sharing a prefix in their name. Still investigating.
@CameronNemo
Indeed gtk3 has some advantages over gtk2.
As far as I can tell GTK2 is supported by (gtk)upstream. I can't find anything saying otherwise (is my search-foo-off?). It's getting occasional bug fixes, just no new features, eg:
https://mail.gnome.org/archives/ftp-release-list/2018-January/msg00030.html
[...] your efforts may be better spent in modifying GTK3 to meet your aesthetic and functional priorities.
I'm also having a look at that (gtk-mushrooms, if I can get it working), but it's a much harder/bigger task.
For the time being: I want to provide a soft landing option for voidlinux users that have found geany's compile time options to have drastically changed.
@Cogitri
Uhh... more like a change from Qt4 to Qt5...which only makes sense.
Developer perspective: I'm unsure, I've never developed GTK2 and GTK3 apps (or Qt4/5)
User perspective: GTK2 and GTK3 are completely different beasts. Different configuration methods, different features, different appearance. If they did not share a name then they could be projects by different groups. One similarity they notably share is the bookmarks list in the file-chooser.
Sure, such a change means... change which one has to adopt for (and one may prefer the old behaviour), yet we can't stay with old stuff forever.
Yes and no.
Many of the tools I use on Void day to day are projects that have been around for more than a decade. Many of them have not had features added in years. There are newer options, but they are not necessarily better.
Geany supports both the GTK2 and GTK3 interfaces. Whilst there is the support I think it's useful for users to provide both versions of the program. I don't think its wise to base packaging decisions off fear; when and if (geany) upstream drops GTK2 is when change should be considered.
My best understanding of the docs: this would not create a separate package on the mirrors, but would instead provide an option if you compile the template yourself. I'm not sure of the advantage of this.
i had used deadbeef which has a gtk3 build option so i thought that was the way we were supposed to do gtk2 variants of packages but it looks like there are some existing *-gtk2 packages too
# packages with gtk[23] build option in the x86_64-musl repo
CPU-X gtk3
abiword ~goffice ~gtk3
abiword-devel ~goffice ~gtk3
deadbeef gtk3
deadbeef-devel gtk3
firefox-esr alsa dbus gtk3 pulseaudio rust startup_notification xscreensaver
gst-plugins-good1 gtk3
icecat alsa dbus gtk3 pulseaudio startup_notification xscreensaver
instead sdl2 ~gtk3
libabiword ~goffice ~gtk3
lxappearance dbus ~gtk3
plymouth gtk3 pango
plymouth-data gtk3 pango
plymouth-devel gtk3 pango
qemu gtk3 opengl sdl2 smartcard spice virgl ~sdl
qemu-ga gtk3 opengl sdl2 smartcard spice virgl ~sdl
spacefm ~gtk3
spacefm-ng ~gtk3
vice gtk3 ~sdl2
# packages with -gtk[23] variants in the x86_64-musl repo
avahi-ui-libs Avahi UI shared libraries
avahi-ui-libs-gtk3 Avahi UI GTK+3 shared libraries
cbatticon-gtk2 Lightweight and fast battery icon that sits in your systray - GTK2
cbatticon-gtk3 Lightweight and fast battery icon that sits in your systray - GTK3
emacs GNU Emacs editor
emacs-gtk2 GNU Emacs editor - GTK+2 version
emacs-gtk3 GNU Emacs editor - GTK+3 version
freeciv Free and Open Source empire-building strategy game - server/data
freeciv-gtk2 Free and Open Source empire-building strategy game - GTK+ client
freeciv-gtk3 Free and Open Source empire-building strategy game - GTK+3 client
galculator-gtk2 GTK+ based scientific calculator (GTK+2)
galculator-gtk3 GTK+ based scientific calculator (GTK+3)
gsimplecal-gtk2 Simple and lightweight GTK calendar
gsimplecal-gtk3 Simple and lightweight GTK calendar
gwenhywfar OS abstraction functions for various projects
gwenhywfar-gtk3 OS abstraction functions for various projects - gtk+3 bindings
libcanberra XDG Sound Theme and Name Specification library implementation
libcanberra-gtk3 XDG Sound Theme and Name Specification library implementation - GTK+ (3.x) support
libdbusmenu-gtk3 Library for passing menus over DBus (GTK+3)
libfcitx Flexible Context-aware Input Tool with eXtension - shared libraries
libfcitx-gtk3 Flexible Context-aware Input Tool with eXtension - GTK3 IM module
pcmanx-gtk2 Easy-to-use telnet client mainly for BBS users
uim Multilingual input method library and environment
uim-gtk2 Multilingual input method library and environment - GTK2 IM module
uim-gtk3 Multilingual input method library and environment - GTK3 IM module
wxWidgets The wxWidgets GUI toolkit library (version 3)
wxWidgets-gtk3 The wxWidgets GUI toolkit library compiled with gtk3 support
I have a separate geany-gtk2 template I'm working on at the moment, however I'm hitting some strange corner cases with how xbps manages package conflicts re packages sharing a prefix in their name. Still investigating.
did you add geany-gtk2 to common/shlibs? it might be for the libgeany.so.0 geany installs
any progress ?
Most helpful comment
These are my thoughts on this, for whatever its worth.
GTK2 is unmaintained. Most applications that use it are either unmaintained or have a plan to migrate to GTK+3. Most users of e.g. Inkscape, GIMP, XFCE apps, etc. expect to have the latest stable version of these apps when they are released, with the build options as close to those preferred by upstream as possible. In the future, this will mean GTK3. Keeping users on GTK2 even after upstream has migrated is not the behavior used by any other distro, so there is no precedent. The two issues you listed for disadvantages of GTK3 (size, file-picker dialogs) are controllable by themes and/or modules.
Rather than trying to maintain the GTK2 APIs, your efforts may be better spent in modifying GTK3 to meet your aesthetic and functional priorities.