Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 20:11 +, Emmanuele Bassi wrote:
> consider using a small
> CSS fragment shipped with your own application, if you want to change
> the appearance of your UI, instead of hardcoding a space.
> 
> Especially now that the CSS system is documented and extremely
> powerful.

are you referring to

https://developer.gnome.org/gtk3/stable/chap-css-properties.html

here? This seems to be just some examples. Looking back through the
widget hierarchy I see sometimes "Style Properties" but this example
from such an entry (for GtkWidget)



GtkWidget:cursor-color has been deprecated since version 3.20 and should not be 
used in newly-written code.
Use the caret-color CSS property


indicates that these "Style Properties" are not the CSS properties that
can be altered for the widget concerned.

So where are they documented, on a widget by widget basis.

Richard Shann






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

Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 20:10 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 31 December 2016 at 16:03, Richard Shann  wrote:
> > On Sat, 2016-12-31 at 15:44 +, Emmanuele Bassi wrote:
> >> Hi;
> >>
> >>
> >> Deprecations will only impact you if you want to update the code base
> >> to the next major API bump.
> >
> > Yes, it is to be ready for GTK4 that I am working on these.
> >
> >>  Since you don't have or want to commit resources to do so,
> >
> > I am committing my meagre resources to this.
> 
> I'm sorry to say this, but then you'll likely need more than just
> replacing deprecated API. In some cases we do expect changes in how
> applications are designed, if they want to keep up with new
> environments and human interface guidelines.

I haven't thought of trying to do either of those - I'm happy if people
with a computer with keyboard, mouse and one (preferably two) large
screens can use the program - I'm not sure if touch screens, virtual
keyboards etc would be feasible for this sort of work.

> 
> That's also why we generally expect mature, low-maintenance
> applications, to bundle a copy of GTK+ if they rely on a specific API.
> On Linux, you can look at using Flatpak to build and distribute your
> application.

Thanks for this pointer - I'm not sure how we create binaries for
GNU/Linux at the moment, but I'll flag this up as a possibility.

> 
> > I have just got to this
> > one:
> >
> > gtk_widget_reparent() is deprecated.
> >
> > Following the suggestion it seems this can be avoided with this:
> >
> > #define gtk_widget_reparent(w,p) 
> > (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)),
> >  w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w)))
> 
> More or less, yes.
> 
> The reparent() call was a call needed to avoid costly
> mapping/unmapping of real X11 resources, back in the day; once we
> stopped using real windowing system resources for each widget,
> reparent() relied on side effects and widget authors always doing the
> right thing, which exposed a bunch of bugs every time somebody wrote a
> new widget. So the idea is to always remove and add a widget, instead
> of reparenting it. This way, all code paths get consolidated.
> 
> > I think it would make developers of applications feel happier if some
> > indication was given as to why something was deprecated so as to guide
> > them in re-working the code.
> 
> Please, feel free to file bugs when a deprecation does not have a
> suggestion. We usually try to be explicit, but sometimes it's either
> complicated or we simply forget.
> 
> > (I'm assuming there's some reason that this
> > macro is not simply put into a header).
> 
> Because macros are not bindable anyway, so we generally don't use them
> as API. The only exceptions are the type system macros, but we are
> kind of replacing them with inlined functions, and those are
> implemented by other means in language bindings anyway.
> 
> We also do not provide a "compatibility layer" because now we'd have
> to deal with the bugs in two separate layers, and the bad interactions
> with applications and toolkit.

Ah, a macro wouldn't be a good thing, I see. Though I'm still not so
clear why the implementation of the function was not just simplified to
the above code when the fancier stuff had become unnecessary. No need to
invoke the deprecation machinery. Perhaps it's in the interest of a
shorter, "cleaner" API, or is there some (conceivable) type of GtkWidget
for which the above code would not work?

Richard


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

Re: gtk_dialog_get_action_area() deprecation

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

 

 Hi Emmanuele,

I see the style property "action-area-border" in the documentation for the 
Dialog. Still learning how to use CSS effectively and am using GTK3.18 
currently which has a different CSS syntax than the newer GTK versions. Figure 
I will still use a few deprecated functions so I don't need two different CSS 
strings for the rest of the GTK3 run and start using more of the CSS 
functionality when GTK4 comes out.

Eric

 



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

Re: gtk_dialog_get_action_area() deprecation

[Emmanuele Bassi]

Hi;

It's part of every widget's API reference page, at:

https://developer.gnome.org/gtk3/stable

Ciao,
 Emmanuele.

On Sat, 31 Dec 2016 at 20:28, Phil Wolff  wrote:

> Perhaps you could provide a link to that documentation?
>
>
>
>
>
> On 12/31/2016 12:11 PM, Emmanuele Bassi wrote:
>
> > Especially now that the CSS system is documented and extremely powerful.
>
> ___
>
> gtk-app-devel-list mailing list
>
> gtk-app-devel-list@gnome.org
>
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk_dialog_get_action_area() deprecation

[Phil Wolff]

Perhaps you could provide a link to that documentation?


On 12/31/2016 12:11 PM, Emmanuele Bassi wrote:

Especially now that the CSS system is documented and extremely powerful.

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

Re: gtk_dialog_get_action_area() deprecation

[Emmanuele Bassi]

Hi;

On 31 December 2016 at 18:31, Eric Cashon via gtk-app-devel-list
 wrote:

>  I like the gtk_dialog_get_action_area() function. It makes it easy to set 
> something like the border width of the container.

Since you're using GTK+ 3, you should really consider using a small
CSS fragment shipped with your own application, if you want to change
the appearance of your UI, instead of hardcoding a space.

Especially now that the CSS system is documented and extremely powerful.

Ciao,
 Emmanuele.

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

Re: gtk_dialog_get_action_area() deprecation

[Emmanuele Bassi]

Hi;

On 31 December 2016 at 16:03, Richard Shann  wrote:
> On Sat, 2016-12-31 at 15:44 +, Emmanuele Bassi wrote:
>> Hi;
>>
>>
>> Deprecations will only impact you if you want to update the code base
>> to the next major API bump.
>
> Yes, it is to be ready for GTK4 that I am working on these.
>
>>  Since you don't have or want to commit resources to do so,
>
> I am committing my meagre resources to this.

I'm sorry to say this, but then you'll likely need more than just
replacing deprecated API. In some cases we do expect changes in how
applications are designed, if they want to keep up with new
environments and human interface guidelines.

That's also why we generally expect mature, low-maintenance
applications, to bundle a copy of GTK+ if they rely on a specific API.
On Linux, you can look at using Flatpak to build and distribute your
application.

> I have just got to this
> one:
>
> gtk_widget_reparent() is deprecated.
>
> Following the suggestion it seems this can be avoided with this:
>
> #define gtk_widget_reparent(w,p) 
> (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)),
>  w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w)))

More or less, yes.

The reparent() call was a call needed to avoid costly
mapping/unmapping of real X11 resources, back in the day; once we
stopped using real windowing system resources for each widget,
reparent() relied on side effects and widget authors always doing the
right thing, which exposed a bunch of bugs every time somebody wrote a
new widget. So the idea is to always remove and add a widget, instead
of reparenting it. This way, all code paths get consolidated.

> I think it would make developers of applications feel happier if some
> indication was given as to why something was deprecated so as to guide
> them in re-working the code.

Please, feel free to file bugs when a deprecation does not have a
suggestion. We usually try to be explicit, but sometimes it's either
complicated or we simply forget.

> (I'm assuming there's some reason that this
> macro is not simply put into a header).

Because macros are not bindable anyway, so we generally don't use them
as API. The only exceptions are the type system macros, but we are
kind of replacing them with inlined functions, and those are
implemented by other means in language bindings anyway.

We also do not provide a "compatibility layer" because now we'd have
to deal with the bugs in two separate layers, and the bad interactions
with applications and toolkit.

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

Re: gtk_dialog_get_action_area() deprecation

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

 

 I like the gtk_dialog_get_action_area() function. It makes it easy to set 
something like the border width of the container. 

action_area=gtk_dialog_get_action_area(GTK_DIALOG(dialog));
gtk_container_set_border_width(GTK_CONTAINER(action_area), 20);

Maybe no big deal and can be done in a different way but it can be handy for 
dialog design.

Eric

 



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

Re: gtk_dialog_get_action_area() deprecation

[Emmanuele Bassi]

Hi;

Deprecations will only impact you if you want to update the code base to
the next major API bump. Since you don't have or want to commit resources
to do so, you can keep using the deprecated API in the same major API
version. If you want to avoid deprecation warnings, you can use the various
approaches GTK provides for that:

 - disable deprecation warnings using GDK_DISABLE_DEPRECATION_WARNINGS
defined before importing gtk.h
 - GDK_VERSION_MIN_REQUIRED and GDK_VERSION_MAX_ALLOWED defined before
importing gtk.h
 - G_GNUC_BEGIN_IGNORE_DEPRECATION and G_GNUC_END_IGNORE_DEPRECATION to
mark sections of the code with calls to deprecated API

Deprecated API is generally guaranteed to work between minor releases of
the same API version, unless it calls into other deprecated functionality.

Walking the widget hierarchy created internally by a widget, on the other
hand, is never guaranteed to work, even between minor or micro releases.

tl;dr - keep using the deprecated API unless you can commit yourself to
rework your code to keep up with different major API versions.

Ciao,
 Emmanuele.

On Sat, 31 Dec 2016 at 14:46, Richard Shann  wrote:

> On Sat, 2016-12-31 at 10:05 +, Gergely Polonkai wrote:
>
> > It would be helpful to see your exact use case. If you put only
>
> > buttons in your GtkBox, you will be fine with gtk_dialog_add_button().
>
> > If you add other, more complex widgets, there might be a design flaw
>
> > in your application. Solutions in between might be OK, but without
>
> > knowing what you want to achieve, it's hard to tell.
>
>
>
> Thank you for you quick reply. I guess the answer to my question was
>
> "no".
>
> There isn't the manpower to investigate the purpose of this bit of code
>
> nor to start re-imagining the design 17 years in to this project,
>
> unfortunately.
>
>
>
> For now, I see that I can get at the action area via
>
>
>
> action_area = gtk_widget_get_parent (cancelbutton);
>
>
>
> which will be ok unless the GtkDialog widget gets some new internal
>
> implementation. Perhaps this will be useful to other developers hitting
>
> this deprecation.
>
>
>
> Richard
>
>
>
> >
>
> > Best,
>
> > Gergely
>
> >
>
> >
>
> > On Sat, Dec 31, 2016, 10:39 Richard Shann 
>
> > wrote:
>
> >
>
> > The documentation for gtk_dialog_get_action_area() suggests
>
> > using
>
> > gtk_dialog_add_button() etc. However, my application is
>
> > storing a GtkBox
>
> > in that area - is there a way to do this, going forward?
>
> >
>
> > Richard
>
> >
>
> >
>
> > ___
>
> > gtk-app-devel-list mailing list
>
> > gtk-app-devel-list@gnome.org
>
> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
>
>
>
> ___
>
> gtk-app-devel-list mailing list
>
> gtk-app-devel-list@gnome.org
>
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 10:05 +, Gergely Polonkai wrote:
> It would be helpful to see your exact use case. If you put only
> buttons in your GtkBox, you will be fine with gtk_dialog_add_button().
> If you add other, more complex widgets, there might be a design flaw
> in your application. Solutions in between might be OK, but without
> knowing what you want to achieve, it's hard to tell.

Thank you for you quick reply. I guess the answer to my question was
"no". 
There isn't the manpower to investigate the purpose of this bit of code
nor to start re-imagining the design 17 years in to this project,
unfortunately.

For now, I see that I can get at the action area via

action_area = gtk_widget_get_parent (cancelbutton); 

which will be ok unless the GtkDialog widget gets some new internal
implementation. Perhaps this will be useful to other developers hitting
this deprecation.

Richard

> 
> Best,
> Gergely
> 
> 
> On Sat, Dec 31, 2016, 10:39 Richard Shann 
> wrote:
> 
> The documentation for gtk_dialog_get_action_area() suggests
> using
> gtk_dialog_add_button() etc. However, my application is
> storing a GtkBox
> in that area - is there a way to do this, going forward?
> 
> Richard
> 
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: gtk_dialog_get_action_area() deprecation

[Gergely Polonkai]

It would be helpful to see your exact use case. If you put only buttons in
your GtkBox, you will be fine with gtk_dialog_add_button(). If you add
other, more complex widgets, there might be a design flaw in your
application. Solutions in between might be OK, but without knowing what you
want to achieve, it's hard to tell.

Best,
Gergely

On Sat, Dec 31, 2016, 10:39 Richard Shann  wrote:

> The documentation for gtk_dialog_get_action_area() suggests using
> gtk_dialog_add_button() etc. However, my application is storing a GtkBox
> in that area - is there a way to do this, going forward?
>
> Richard
>
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list