Re: GTK3 - GtkExpander problem, bug ?

[Eric Cashon via gtk-app-devel-list]

 
Hi Sébastien,

An out of sync reply. I must have accidently deleted your last response after I 
read it. Also I didn't notice there were two mailing lists referenced. Probably 
just need the app dev list.

It looks like it is a bug that has been recently introduced. If I test, test.c 
with three expanders, on GTK3.18 it works fine. No problems. If I test on 
GTK3.22, after I close any expander the buttons can still be clicked even 
though they aren't showing. This is also the case with only 2 expanders in the 
original test code.



It sounds like the treeview work around is the way to go in this case.


Eric



___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Sébastien Wilmet]

On Thu, Dec 14, 2017 at 08:34:51PM +, Emmanuele Bassi wrote:
> On 14 December 2017 at 18:42, Sébastien Wilmet  wrote:
> > A recent example:
> > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> > "gtk: Remove GtkClipboard"
> >
> > The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> > in GTK+ 3.22, and the new API is not available in GDK 3.22.
> 
> The new API just landed; and, yes: it's hard to deprecate the API in
> this case, given that the new API has been moved down one level in the
> hierarchy.

GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard
still worked fine just before the commit that removed it, it would have
been possible to first deprecate GtkClipboard and then removing it in
3.9x+2 (see my comment below).

Of course if GtkClipboard didn't work anymore, then it needed to be
removed. Or maybe it was possible to port GtkClipboard to the new GDK
API, but this would have been more work for the GTK developers. It all
depends if you want to provide a smooth experience to port apps.

> Doing this work in 5 years, for GTK+ 5.0,
> would not have been any easier for anybody.

I don't understand why you say that. Each semi-stable 3.9x version can
be seen as a new major version, since it's possible to break the API. So
an API can be marked as deprecated in 3.92 and then removed in 3.94.
Instead of doing a direct API break. This would make it easier to port
applications.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Emmanuele Bassi]

On 14 December 2017 at 18:42, Sébastien Wilmet  wrote:
> On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote:
>> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.
>
> No, that's not true.
>
> A recent example:
> https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> "gtk: Remove GtkClipboard"
>
> The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> in GTK+ 3.22, and the new API is not available in GDK 3.22.

The new API just landed; and, yes: it's hard to deprecate the API in
this case, given that the new API has been moved down one level in the
hierarchy.

This is also why we could not do this during the 3.x API cycle,
without incurring into a lot of regressions or potential breakage.

> I think Benjamin has done a great work with the new implementation. Just
> a little problem: it's what I call a "direct API break", applications or
> higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
> with a big API delta, so it will result in one huge commit/branch
> untestable until all the code is ported [1].

That's what we said would happen during the 9x development cycle: no
API stability between 9x and 9x+2. We were very much upfront about the
API stability.

> It's of course much worse
> if porting directly from 3.22 to 4.0.

And we understand that. Doing this work in 5 years, for GTK+ 5.0,
would not have been any easier for anybody.

> [1] What I would recommend is to copy custom widgets/containers (if they
> are self-contained) out-of-tree, and port them individually, with a
> small GUI test program for each, so that they can be tested outside the
> whole application.

That would not help at all for the GtkClipboard case, and that would
not help with the new rendering API.

I'm sorry about the pain in porting, but this is what 2.5 years of
development are for.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Sébastien Wilmet]

On Thu, Dec 14, 2017 at 08:02:56PM +0100, Bastien Nocera wrote:
> On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
> > 
> 
> > With "soft API breaks" (i.e. just removing an API that was deprecated
> > in
> > a previous major version), I think this would improve a lot the
> > situation and would avoid to repeat the same problem as GTK+ 2 -> 3.
> 
> It already exists. Look at the "DISABLE_DEPRECATED" macros in the
> current version of libraries, and which usually get removed in the +1
> version.

Yes, it's a nice feature, but it doesn't solve the problem that there
are a lot of direct API breaks during GTK+ 3.9x development.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK3 - GtkExpander problem, bug ?

[Eric Cashon via gtk-devel-list]

 
Hi Sébastien,

If I try some test code... it should work. The code uses a grid instead of a 
fixed container. Is this similar to what you have tried?

Eric

/*
   gcc -Wall buttons1.c -o buttons1 `pkg-config --cflags --libs gtk+-3.0`
   Tested with GTK3.18 on Ubuntu16.04
*/
#include

static void button_clicked1(GtkWidget *button, gpointer user_data)
  {
g_print("1 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
  }
static void button_clicked2(GtkWidget *button, gpointer user_data)
  {
g_print("2 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
  }
int main(int argc, char *argv[])
  {
gtk_init (, );

GtkWidget *window=gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Buttons");
gtk_window_set_default_size(GTK_WINDOW(window), 400, 400);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

gint i=0;
gint j=0;
GtkWidget *buttons1[100];
GtkWidget *buttons2[100];

//First set of buttons.
for(i=0;i<100;i++)
  {
gchar *string=g_strdup_printf("button%i", i);
buttons1[i]=gtk_button_new_with_label(string);
g_free(string);
  }

GtkWidget *grid1=gtk_grid_new();
for(i=0;i<10;i++)
  {
for(j=0;j<10;j++)
  {
gtk_grid_attach(GTK_GRID(grid1), buttons1[i*10+j], j, i, 1, 1);
g_signal_connect(buttons1[i*10+j], "clicked", 
G_CALLBACK(button_clicked1), NULL);
  }
  } 

//Second set of buttons.
for(i=0;i<100;i++)
  {
gchar *string=g_strdup_printf("button%i", i);
buttons2[i]=gtk_button_new_with_label(string);
g_free(string);
  }

GtkWidget *grid2=gtk_grid_new();
for(i=0;i<10;i++)
  {
for(j=0;j<10;j++)
  {
gtk_grid_attach(GTK_GRID(grid2), buttons2[i*10+j], j, i, 1, 1);
g_signal_connect(buttons2[i*10+j], "clicked", 
G_CALLBACK(button_clicked2), NULL);
  }
  }   

GtkWidget *scroll1=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll1, TRUE);
gtk_widget_set_hexpand(scroll1, TRUE);
gtk_container_add(GTK_CONTAINER(scroll1), grid1);

GtkWidget *scroll2=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll2, TRUE);
gtk_widget_set_hexpand(scroll2, TRUE);
gtk_container_add(GTK_CONTAINER(scroll2), grid2);

GtkWidget *expander1=gtk_expander_new("buttons1");
gtk_container_add(GTK_CONTAINER(expander1), scroll1);

GtkWidget *expander2=gtk_expander_new("buttons2");
gtk_container_add(GTK_CONTAINER(expander2), scroll2);

GtkWidget *grid3=gtk_grid_new();
gtk_grid_attach(GTK_GRID(grid3), expander1, 0, 0, 1, 1);
gtk_grid_attach(GTK_GRID(grid3), expander2, 0, 1, 1, 1);

gtk_container_add(GTK_CONTAINER(window), grid3);

gtk_widget_show_all(window);

gtk_main();

return 0;
  }   

 


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK3 - GtkExpander problem, bug ?

[Eric Cashon via gtk-app-devel-list]

 
Hi Sébastien,

If I try some test code... it should work. The code uses a grid instead of a 
fixed container. Is this similar to what you have tried?

Eric

/*
   gcc -Wall buttons1.c -o buttons1 `pkg-config --cflags --libs gtk+-3.0`
   Tested with GTK3.18 on Ubuntu16.04
*/
#include

static void button_clicked1(GtkWidget *button, gpointer user_data)
  {
g_print("1 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
  }
static void button_clicked2(GtkWidget *button, gpointer user_data)
  {
g_print("2 %s\n", gtk_button_get_label(GTK_BUTTON(button)));
  }
int main(int argc, char *argv[])
  {
gtk_init (, );

GtkWidget *window=gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Buttons");
gtk_window_set_default_size(GTK_WINDOW(window), 400, 400);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);

gint i=0;
gint j=0;
GtkWidget *buttons1[100];
GtkWidget *buttons2[100];

//First set of buttons.
for(i=0;i<100;i++)
  {
gchar *string=g_strdup_printf("button%i", i);
buttons1[i]=gtk_button_new_with_label(string);
g_free(string);
  }

GtkWidget *grid1=gtk_grid_new();
for(i=0;i<10;i++)
  {
for(j=0;j<10;j++)
  {
gtk_grid_attach(GTK_GRID(grid1), buttons1[i*10+j], j, i, 1, 1);
g_signal_connect(buttons1[i*10+j], "clicked", 
G_CALLBACK(button_clicked1), NULL);
  }
  } 

//Second set of buttons.
for(i=0;i<100;i++)
  {
gchar *string=g_strdup_printf("button%i", i);
buttons2[i]=gtk_button_new_with_label(string);
g_free(string);
  }

GtkWidget *grid2=gtk_grid_new();
for(i=0;i<10;i++)
  {
for(j=0;j<10;j++)
  {
gtk_grid_attach(GTK_GRID(grid2), buttons2[i*10+j], j, i, 1, 1);
g_signal_connect(buttons2[i*10+j], "clicked", 
G_CALLBACK(button_clicked2), NULL);
  }
  }   

GtkWidget *scroll1=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll1, TRUE);
gtk_widget_set_hexpand(scroll1, TRUE);
gtk_container_add(GTK_CONTAINER(scroll1), grid1);

GtkWidget *scroll2=gtk_scrolled_window_new(NULL, NULL);
gtk_widget_set_vexpand(scroll2, TRUE);
gtk_widget_set_hexpand(scroll2, TRUE);
gtk_container_add(GTK_CONTAINER(scroll2), grid2);

GtkWidget *expander1=gtk_expander_new("buttons1");
gtk_container_add(GTK_CONTAINER(expander1), scroll1);

GtkWidget *expander2=gtk_expander_new("buttons2");
gtk_container_add(GTK_CONTAINER(expander2), scroll2);

GtkWidget *grid3=gtk_grid_new();
gtk_grid_attach(GTK_GRID(grid3), expander1, 0, 0, 1, 1);
gtk_grid_attach(GTK_GRID(grid3), expander2, 0, 1, 1, 1);

gtk_container_add(GTK_CONTAINER(window), grid3);

gtk_widget_show_all(window);

gtk_main();

return 0;
  }   

 


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Bastien Nocera]

On Thu, 2017-12-14 at 19:56 +0100, Sébastien Wilmet wrote:
> 

> With "soft API breaks" (i.e. just removing an API that was deprecated
> in
> a previous major version), I think this would improve a lot the
> situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

It already exists. Look at the "DISABLE_DEPRECATED" macros in the
current version of libraries, and which usually get removed in the +1
version.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Sébastien Wilmet]

On Wed, Dec 13, 2017 at 03:08:46PM -0800, Christian Hergert wrote:
> On 12/13/2017 04:05 AM, Sébastien Wilmet wrote:
> > Can I remind you that most of the biggest GTK+ apps are still using
> > GTK+ 2? MonoDevelop, GIMP, Ardour, …
> 
> MonoDevelop is still Gtk2 because Novell/Xamarin/Unity3d invested, quite
> literally, millions of dollars on consultants to work on the OS X port
> (without much interest in paying additional money to have that work
> upstream'd or ported to Gtk3). Add to that the necessity to write new
> bindings around G-I for Gtk♯ 3 and you can get the idea of how they see
> that as risk from a business standpoint.
> 
> Ardour could never move to Gtk3 because a number of VST plugins use Gtk2
> and you cannot mix both into the same process space. DAW authors will
> often cite the necessity for plugins to be in process to allow for a
> large number of tracks/plugins due to context switching. (This is a
> contributing factor to why many DAWs write their own UI toolkits).

Thanks for that information, I was not aware of those problems.

> As for GIMP, I think the lesson I take away is that we need to recruit
> people to go do the ports for important projects rather than expect them to
> track us. Red Hat has shown that this strategy works in both Firefox and
> LibreOffice (which are arguably the two hardest applications to port).

The question is: why don't they do the port to GTK+ 3 "themselves"?
Because it's hard, you say it yourself in case of Firefox and
LibreOffice. With the GTK+ 2 -> 3 transition, there are a lot of "direct
API breaks". With GTK+ 3 -> 4, the same is happening. Lots of direct API
breaks at once, that's what makes it hard to port an application or a
higher-level library. For 10k lines of code, it's entirely feasible. For
100k lines, it's feasible by a full-time employee. For an application
the size of MonoDevelop, this is just unmanageable IMHO.

With "soft API breaks" (i.e. just removing an API that was deprecated in
a previous major version), I think this would improve a lot the
situation and would avoid to repeat the same problem as GTK+ 2 -> 3.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: First deprecate APIs and then remove them in the next major version

[Sébastien Wilmet]

On Wed, Dec 13, 2017 at 04:55:41PM +, Emmanuele Bassi wrote:
> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

No, that's not true.

A recent example:
https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
"gtk: Remove GtkClipboard"

The clipboard is now implemented in GDK. GtkClipboard is not deprecated
in GTK+ 3.22, and the new API is not available in GDK 3.22.

I think Benjamin has done a great work with the new implementation. Just
a little problem: it's what I call a "direct API break", applications or
higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
with a big API delta, so it will result in one huge commit/branch
untestable until all the code is ported [1]. It's of course much worse
if porting directly from 3.22 to 4.0.

[1] What I would recommend is to copy custom widgets/containers (if they
are self-contained) out-of-tree, and port them individually, with a
small GUI test program for each, so that they can be tested outside the
whole application.

--
Sébastien
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK3 - GtkExpander problem, bug ?

[Tilo Villwock]

Hello Sébastien,

attaching images isn't allowed on here. Have you created a minimal
working example that reproduces the bug? Otherwise it'll be hard to
help you.

Cheers,

Tilo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GTK3 - GtkExpander problem, bug ?

[Sébastien Le Roux]

Dear all thanks in advance for reading this,

I wrote a piece of code in GTK3, and I might have found an issue with 
the GtkExpander widget,
shorter than a long text explanation, I attach to this email a screen 
capture from a window from my program.
This window contains a bunch of GtkExpander, inside each a 
GtkScrolledWindow that contains a GtkFixed,
each GtkFixed contains a series of GtkToggleButtons. (I can have a lot 
of buttons piled up in there).
I tried several container widget other than the ScrolledWindow, but it 
is the only one that offers to browse

the entire button list that my program will create.

The first time, I open/close one of the GtkExpander (1) everything works 
fine, the button are working fine,
then if I open/close another GtkExpander (2) and re-open the first one I 
lose information regarding the buttons,
some stop to function, for other the pointers for the callback are 
damaged and the function will not work properly afterwards.
I noticed that I could even recall buttons located in the other expander 
(2), basically at the location they were
appearing on the window before having expander (2) closed, like if the 
two sets of buttons from the 2 expanders

 were overlapping/sharing positions somehow.

So there is no GTK signal used in all this window excepted for the 
buttons, and a simple 'play' with the expanders
is messing everything up ... GDB and VALGRIND are not giving me any 
error so ...

I figured that this was out of my skill range, hence this email.


I also attach to this message a piece of code to illustrate how I 
generate the window from my picture, the part
the generate the button is missing but that it too big to included in 
this message.


Finally I want to add that the almost the exact same code works just 
fine with GTK2 ... if that helps.


Thanks in advance for you help.

Best regards.

--
===
Dr. Sébastien Le Roux
Ingénieur de Recherche CNRS
Institut de Physique et Chimie des Matériaux de Strasbourg
Département des Matériaux Organiques
23, rue du Loess
BP 43
F-67034 Strasbourg Cedex 2, France
E-mail: sebastien.ler...@ipcms.unistra.fr
Webpage: http://www-ipcms.u-strasbg.fr/spip.php?article1771
RINGS project: http://rings-code.sourceforge.net/
ISAACS project: http://isaacs.sourceforge.net/
Fax:   +33 3 88 10 72 46
Phone: +33 3 88 10 71 62
===

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list