Thank for reporting this bug.

I have tried to here but I have been able to open the attached project without issue. Could you give more details?

Is it hanging each time you load this project? You can run anjuta -n to start Anjuta without loading a project and then open the project.

You can try to remove (or rather rename, to keep it) the directory .anjuta inside your project and check if you can load your project without it. It will reset some project preferences.

Strange. Yes, it always hangs when opening the .anjuta file. When it was the last project I was working at, it hangs always after the start.

When I rename the .anjuta folder, it can be successfully opened. So the problem seems to sit somewhere in this folder.

How could I help you? What information could help you?

(In reply to comment #2)
> How could I help you? What information could help you?

I have tried using Anjuta version 2.10 and it's working too here, so I don't know what is the problem.

You can try to delete the file .anjuta/session/dock-layout.xml. This file keeps the layout of the windows inside Anjuta. Perhaps it can lead to an issue.

Else, you can try to remove the line "Geometry=1920x1014+0+27" in the file .anjuta/session/anjuta.session.

No, unfortunately none of them helped.
The only thing which helped was deleting the file "default.profile".

(In reply to comment #4)
> No, unfortunately none of them helped.
> The only thing which helped was deleting the file "default.profile".

It could be better then because this file contains a list of additional plugins which are loaded with your project.

It means that the issues comes probably from one of the plugin here. Could you edit the file to remove each plugin one by one. It's a file in XML format, you can remove everything from <plugin ...> to </plugin> to remove one plugin.

According to your project, you have the help and the terminal plugin loaded. Could you check if you can load your project with only one plugin removed?

Indeed, after having deleted a plug-in, it worked again. The strange thing is, that it did not matter which of the two I deleted.
Then I pressed just enter in gedit at the end of the "default.profile" and saved it and surprise, surprise: it worked …
Maybe Encoding?!

(In reply to comment #6)
> Indeed, after having deleted a plug-in, it worked again. The strange thing is,
> that it did not matter which of the two I deleted.
> Then I pressed just enter in gedit at the end of the "default.profile" and
> saved it and surprise, surprise: it worked …
> Maybe Encoding?!

I have looked at this file and it contains only ASCII character (no character with a code greater than 0x7F). Is the file different after saving it with gedit?

I almost thought I got mad :-) but that are the things I thought I found out:
If I am not mistaken:
It looks like, when I modify the "Default.profile" the files in the folder "session" get modified which leads to a working project again.

The problem is probably connected to the file "dock-layout.xml". When I take the new modified version of this file (working project) and copy it over the corresponding file of a not working project it is working again …

Created attachment 265012 [details]
not working version of dock-layout.xml

Created attachment 265013 [details]
working version of dock-layout.xml

Both versions are working here. Then, I have compare both files and there are a few differences:

* horizontal pane position 593 instead of 677

* AnjutaDevhelpIndex is closed

* AnjutaDevhelpDisplay is closed 

* bottom notebook is closed and selected page is -1

* AnjutaTerminal window is the last one.


Could you try to remove these differences one by one in the non working fine to know which one trigger the bug?

In order to compare and edit both file you can use xmllint that will reformat the xml file on several lines. Here, it is part of libxml2-utils packages and you can run xmllint -format _name_of_xml_file_ to get a xml file on several lines.

It seems that "AnjutaDevhelpDisplay" is the bad one. When I delete this line, the Project can be loaded normally.

I have updated my system and it seems that I can reproduce something similar.

Sometimes, anjuta hangs when loading a project. It seems to be linked to the webkit library which is used by the devhelp plugin.

I have found one bug at least here. There is a warning:
(anjuta:11303): GLib-GObject-WARNING **: cannot register existing type 'GtkOffscreenWindow'(anjuta:11303):


It happens because you have both the devhelp and the glade plugin loaded. Glade registers some dummy types if they are missing. But as Anjuta uses plugins, not all types are defined when Glade check for missing types. Due to that, GtkOffscreenWindow is registered as a dummy type by Glade and libwebkit2 cannot register it anymore when needed.


Inside glade code, in the file gladeui/glade-widget-adaptor.c and the function generate_type, I can fix this issue by always generating a type prefixed by GladeFake without checking if it already exist.

I don't know if it's the right fix though, so I'm moving this bug to Glade project so we can check.

Hi, can you attach the patch in question so we can review it ?

There are some issues about using the "GladeFake" prefix - i.e. off the
top of my head I can foresee this might trigger the dialog to show up
at project open time, incorrectly warning the user that "Glade doesnt
know about this widget type and you are probably missing a catalog".

What we apparently need is to namespace these widgets we register in
the catalog so that:
  a.) They are saved as GtkOffscreenWindow in Glade output, and not
      saved as GladeFakeGtkOffscreenWindow
  b.) They are loaded and recognized, i.e. the adaptor for GtkOffscreenWindow
      is still found for a GtkOffscreenWindow.

Those are the only concerns I can think of, this might require special
handling at load/save time in GladeWidget code.

Created attachment 267996 [details] [review]
proposed simple fix

Here is my fix but it only adds unconditionally the prefix GladeFake.

I have considered that if it works for some widgets, it could work for all of them but I haven't checked anything in glade. I have checked that it fixes the issue in Anjuta though.

Created attachment 268514 [details] [review]
an improved fix

My previous patch leads to several critical warnings because it's not true anymore that a real type exists for all "fake" classes. I have added a check to avoid these warnings and it seems to work here.

It seems that the right name is used in the catalog because the type saved in the glade file doesn't have the GladeFake prefix. I'm able to load and save a glade file with or without this patch.

I have seen the name GladeFake prefix only in the widget tree view but I think it could be acceptable.

Created attachment 271945 [details] [review]
Proposed patch

Hi guys, instead of prefixing everything, I rather go with something more conservative.

Using parent in the catalog was originally intended to easily use custom types without having to actually use them in runtime.

When I added support for GtkOffscreenWindow I took advantage of this feature to cheat the runtime into using a GtkWindow instead of a GtkOffscreenWindow which can be packed into another window for some reason I can not remember now.

This obviously only works if you do not actually try to use a GtkOffscreenWindow. Which was not a problem for Glade but I did not realized back then that it could be for Anjuta. sorry about that!!

So the real problem was that I was using g_type_from_name() in generate_type()
to check if the type existed but that only check if the type is currently registered. Using glade_util_get_type_from_name() fix this problem since it will try dlopen the _get_type() function.

I also had to make sure GladeProject was using GladeWidgetAdaptor name instead of the runtime object class name in the inspector to avoid showing GladeFake* types.

BTw I will push it once you guys give it a try!

Thank you for this patch, it's much better than mine and Anjuta doesn't crash anymore.

Thank you!, You always end up finding these obscure bugs!

pushed to master and 3.16 branch