Created attachment 144754 [details] [review]
Use accessor functions instead direct access

Review of attachment 144754 [details] [review]:

Thanks!

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Hello Johannes,

thank you for apply the patch, but I've reopened this bug because there still are some pending symbols. There is not a replacement API for them (2.19.0 here). Still missing:

GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS);
GTK_WIDGET_UNSET_FLAGS (widget, GTK_HAS_FOCUS);
GTK_WIDGET_REALIZED (widget)
GTK_WIDGET_MAPPED (widget)  See bug #69872

Created attachment 153482 [details] [review]
Use accessor functions instead direct accessv. Second patch

The only remaining function are:

GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS);

but this is really a bug because you should never need to use this

See mith coment here: https://bugzilla.gnome.org/show_bug.cgi?id=593601#c4
and ebassi one here: https://bugzilla.gnome.org/show_bug.cgi?id=69872#c27

(In reply to comment #5)
> GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS);
> but this is really a bug because you should never need to use this
> See mith coment here: https://bugzilla.gnome.org/show_bug.cgi?id=593601#c4
> and ebassi one here: https://bugzilla.gnome.org/show_bug.cgi?id=69872#c27

Well, why not. But what is right solution to replace GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS) ?

(In reply to comment #5)
> 
> The only remaining function are:
> 
> GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS);
> 
> but this is really a bug because you should never need to use this
> 
> See mith coment here: https://bugzilla.gnome.org/show_bug.cgi?id=593601#c4
> and ebassi one here: https://bugzilla.gnome.org/show_bug.cgi?id=69872#c27

Hi Javier, do you have any working solution for this in Anjuta?

The question is, why do you need to use the GtkTreeView hack [1] in your code?

[1] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c#n10264

(In reply to comment #8)
> The question is, why do you need to use the GtkTreeView hack [1] in your code?
> [1] http://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c#n10264

It's used in the debugger view memory windows. You can get it by starting the debugger and then selecting View->Memory.

In the context menu item, you can select Go to Address that will display a small entry box allowing you to enter just an address. To enter the address, I move the focus to this entry box so the user can type directly the new address. But if I don't use the GtkTreeView hack, the cursor doesn't appear which is very confusing.

This address entry box is similar to the entry box that you get in the file selector by example. I'm quite sure that when I have seen this behavior, I have looked how it's done in Gtk+ and find the GtkTreeView hack.

Is there a better way to do it now ?

(In reply to comment #9)
> Is there a better way to do it now ?

not right now, and as I said here:

  https://bugzilla.gnome.org/show_bug.cgi?id=69872#c27

we need public API to allow people to implement this kind of functionality in a consistent and gtk+-like way without using internal details and flags like GTK_HAS_FOCUS.

Apart from GTK_WIDGET_SET_FLAGS (widget, GTK_HAS_FOCUS):
Can the last patch in comment 5 get a review/commit?

Created attachment 159868 [details] [review]
Use accessor functions instead direct accessv. Final patch

All the remaining accessor fixed in this patch.

I'd suggest you to add -GSEAL_ENABLED flag in your configure.ac to not use direct access again.

ping -> It's the latest patch ;)

(In reply to comment #13)
> ping -> It's the latest patch ;)

Yes, I see thanks you very much for all your work.

I have not applied it yet because I don't expect any problem with it and it will not change anything for users or developers so I'm rather working on other parts. Or is there a reason for applying it as soon as possible ?

Cleaning the to-do list for GNOME 3, and being able to compile anjuta with gtk 2.90?

Well, that's no priority for now (as we have a patch anyway that can be easily applied). And in bumping the gtk+ version it makes development for some people much more tricky.

(Yeah, anjuta uses some gtk+ 2.19 specific call somewhere but that's rather easy to patch out for now.)

Give us one or two month and be sure that the patch will be applied in time.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

@Javier: Thanks for pushing the patch correctly. I guess I was too tired yesterday and fucked things up.