Re: GSoC 2024: gnunet-gtk gtk4 upgrade

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-released/> 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
>