Re: GSoC 2024: gnunet-gtk gtk4 upgrade

Jacki <[email protected]> Wed, 28 Feb 2024 01:20:16 +0100
Newsgroups gmane.network.gnunet.devel
Message-ID <edad1b98ab349d08166335312b03f6c5737b69fb.camel@thejackimonster.de>
Exactly. In GTK3 you can still use Glade but import the UI files via
GtkBuilder. In GTK4 they adjusted widgets quite a bit. So instead of
Glade you need to use Cambalache because Glade won't be ported over. In
fact Cambalache is developed by one of the core contributors behind
Glade.

Since Camabalache is still in development we could port over to GTK3
using GtkBuilder with designing UI in Glade though. The required
changes from GTK3 to GTK4 shouldn't be huge in most cases. Cambalache
also supports converting the UI files from GTK3 to GTK4.

I think GNOME published a blog post for porting from GTK3 to GTK4 as
well.

But I assume it's also possible to use Cambalache already. Most
important functionality should work.

BR
Jacki

On Tue, 2024-02-27 at 20:58 +0100, Christian Grothoff wrote:
> Let me just say this: using a RAD tool like Glade is just the only 
> logical thing, it is 1000% more productive for UX development then
> doing 
> the building of Gtk objects by hand. So for the sake of sanity,
> please 
> use *some* RAD tool. Besides, AFAIK GtkBuilder isn't deprecated, just
> Glade itself is being rewritten/replaced.  We used Glade for quite a 
> while despite it being WIP/in beta, with GNOME's reluctance to
> declare 
> something stable I'm not sure a WIP RAD tool is inherently a bad
> idea. 
> But I *am* sure that doing gtk_box_add() by hand is the road to 
> insanity.  So I would very strongly recommend using Cambalance ---
> and 
> to use the opportunity to clean up the GUIs ;-).
> 
> On 2/27/24 20:51, Schanzenbach, Martin wrote:
> > I think our use of glade is historical.
> > It just made sense to somebody (not me, my guess is Christian).
> > 
> > I personally have no issue with moving away from glade as RAD tool
> > as I 
> > find it very cumbersome myself.
> > Note, however, that it will also mean writing a lot of code that is
> > currently hidden behind those glade XML files.
> > 
> > OTOH moving to a WIP RAD tool is also not such a smart idea, maybe.
> > But 
> > that depends on the maturity of cambalanche, which I cannot judge
> > myself 
> > right now as I have never tried it.
> > 
> > BR
> > 
> > On 27.02.24 20:19, Gotam Gorabh wrote:
> > > Hello Martin,
> > > 
> > >     Note that migration from gtk3 to gtk4 especially for gnunet-
> > > gtk is 
> > > not
> > >     trivial: We use libglade, which does not exist for gtk4.
> > >     We will need to decide if we want to migrate to something
> > > like
> > >    
> > > https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-released/
> > >     
> > > <
> > > https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-release
> > > d/> or
> > >     something different entirely.
> > > 
> > > 
> > > Why can't we use the proper GObject concept like other gnome 
> > > application does? E.g. GNOME Settings,  Nautilus, etc. which can 
> > > handle the properties, and signals in a structured way.
> > > 
> > > Thanks. Regards
> > > 
> > > Gotam Gorabh
> > 
>
signature.asc (application/pgp-signature, 870 B)
-----BEGIN PGP SIGNATURE-----

iQJNBAABCAA3FiEEP1qkEG8usH2zEXZctAQYR5Y1TF4FAmXefEAZHGphY2tpQHRo
ZWphY2tpbW9uc3Rlci5kZQAKCRC0BBhHljVMXkKhD/0Y7uXBLAJN1t4QxdQ7zIuF
J6krsHXkOgo1fdBjWcVj78m3Gu0RqL0Ik7zt4hjs1ypqL4syaBXU4CA9xeTIAde8
DGcwrw8MTdsdD8U+HdJ5iVessBaiCQBkjnffwmkkdCdOTKU5Nx9knpvKLqNcNFf+
iQKszWOPCAGFAuipypjI17lt5NOYUT+299O1Z5s6rnfe8w+/axTliQMBGQ6UpDL+
ScWZut3OTKXkYCcgNq64kCoE8lUcqjsS7msegLhR76e9v0UEyffYeCXPQ+JXS+Tp
kE3Z3IbpllBxtixa2sv3BIWkzaSL2jraslP0NST7BKZgoh9zjGqKJqJrCy1LI5f1
zPR37CY2DwgwA9suKjxZDpLR693Vnnldm0RCQ0gY88vl8GHszSDRvmxxjyyxxQC7
X9YH9BK6xY2NiUQyszxrrz39SufKDXLkv4RIlJzyEtqPnqHUMgzNHC7J8mYIrgK/
mP5vL58R4kelsW5AU3V/ZEDvz+WfaZ1RpbljqnmHnItVWXQXB5JXn8LkUqvN3i6f
obduPdr2Hl9sfsrOdWfhyB3kOGM6Coa6+vi2UPO5C+EXb7pu6+45BLqK/1lBLfLw
HtDF8RGRHzL+n9L5ibJ5KENJ0nEqDkNJAF4StyZqPyDxw6qIBXsv/claQBgcXAlJ
DFgeDYv6Wc3+uzQ6MVk/Xw==
=KIyo
-----END PGP SIGNATURE-----