This seems like a crash in gdl. Try removing the layout.xml in the ~/.config/gtranslator folder.

This was the first thing I did before reporting the bug - no change, it still segfaults when I enable any of the afore mentioned plugins.

FYI, still the same using released gdl 3.5.4 tarball.

I have tried here. I get a crash too but in gtk_ui_manager_get_widget, so it's not sure that it's the same bug.

Could you try with gdl 3.5.3 and gdl 3.4.2?

I have done some changes in this cycle, there are still some bugs inside.

With gdl 3.4.2 it works fine. I'll try gdl 3.5.3 later.

Gdl 3.5.3 works, too. Here you'll need to delete the ~/.config/gtranslator/layout.xml file to get it working, but it works.

(In reply to comment #6)
> Gdl 3.5.3 works, too. Here you'll need to delete the
> ~/.config/gtranslator/layout.xml file to get it working, but it works.

Thanks. It's possible that you get such bug using a development version of gdl. With GDL 3.5.2, I'm surprise that it's not working. Then, we have made some error when numbering GDL version number so perhaps you were still using the development version instead of GDL 3.5.2. Anyway most of the changes have still not arrived, so it's not that useful to check what's happen in these versions.

I have tried here but it doesn't work whatever is the version of GDL but it doesn't look like a GDL bug.

Gtranslator (current git master) keeps segfaulting using current gdl builds (currently gdl 3.5.91). Right before the segfault I get the following warning:

(gtranslator:4278): GLib-GObject-WARNING **: invalid cast from `GdlDockItem' to `GtrWindow'

Maybe this helps tracking down the bug?

I have this here too with the translation-memory plugin, in plugins/translation-memory/gtr-translation-memory-ui.c:

static void
showed_message_cb (GtrTab *tab, GtrMsg *msg, GtrTranslationMemoryUi *tm_ui)
{
 ...

  window = gtk_widget_get_toplevel (GTK_WIDGET (tm_ui));
  manager = gtr_window_get_ui_manager (GTR_WINDOW (window));

I think the issue is that the toplevel widget is not a GTR_WINDOW so the manager get a wrong value and it crashes.

If I understand correctly, the dock item should be attached to the window, and the tm ui is inside the dock item. So doing get_toplevel should give me the gtranslator window as it happened before.
Has something changed in the docking? Maybe now it is attached as a standalone window instead?

(In reply to comment #10)
> If I understand correctly, the dock item should be attached to the window, and
> the tm ui is inside the dock item. So doing get_toplevel should give me the
> gtranslator window as it happened before.
> Has something changed in the docking? Maybe now it is attached as a standalone
> window instead?

I'm just looking at it. It's working fine if I remove the code loading the previous layout. I think the cause it rather something like the dock object is not attached correctly after loading it.

I think one issue is that the format for saving a layout is a bit different and a default layout is included in gtranslator. 

But I'm not sure it's the main issue as I still have a crash if I keep saving the layout. It seems that it saves a invalid layout, or a layout which is strange enough to make unexpected things.

<?xml version="1.0"?>
<dock-layout><layout name="__default__"><dock name="__dock_1" floating="no" width="-1" height="-1" floatx="0" floaty="0" skip-taskbar="yes"><paned orientation="vertical" locked="no" iconified="no" closed="no" position="0"/></dock></layout></dock-layout>

If the layout format changed, I am all for changing the default one.

Although there is something wrong. See that in gtranslator we do not allow to detach the docks, they are always attached, even when they are going to be moved. In this kind of case no matter what gdl should always get them attached, even if the default format is wrong.

(In reply to comment #14)
> Although there is something wrong. See that in gtranslator we do not allow to
> detach the docks, they are always attached, even when they are going to be
> moved. In this kind of case no matter what gdl should always get them attached,
> even if the default format is wrong.

The meaning of detach is a bit different in GDL 3.6.0. In fact the widgets are never detach, they are kept in the widget hierarchy but hidden. That's necessary to keep their position. I don't know if can be an issue for gtranslator.

Created attachment 228306 [details] [review]
Fix proposal

The main issue seems to be that the layout-changed signal is emitted when a new layout is loaded. I imagine it was no the case in older version of GDL. In gtranslator it is an issue because this layout-changed signal triggers a save of the current layout. At the end it saves an empty layout that cause the crash.

I have fixed a few small issues to make it compile without warning on GDL 3.6.0.

Review of attachment 228306 [details] [review]:

Looks good. Thanks a lot.

Review of attachment 228306 [details] [review]:

One minor thing. Why the layout changed signal is triggered when saving the layout? That sounds wrong to me...

(In reply to comment #18)
> One minor thing. Why the layout changed signal is triggered when saving the
> layout? That sounds wrong to me...

I have expected this question a bit :). The layout changed is emitted each time a new window is created or modified. Loading a layout creates new windows and I haven't done anything to block this signal.

I'm agree that it probably makes sense to block it but I'm not sure that there isn't any case where it is annoying.

Well... this case makes it a bit not very discoverable....

Hey Sébastien... what has happened with this issue?

Can I help you with something?

(In reply to comment #21)
> Hey Sébastien... what has happened with this issue?
> Can I help you with something?

Thanks but I think my work is done.I haven't done lots of check but I think the patch that I have proposed fix the issue correctly. At least it is working much better here.

It is marked as committed but it seems that it is not in the master branch, I don't know why but I think it will be done soon. If you recompile gtranslator, you can try it too and check that it's working.

Then for the discussion about emitting the layout-changed signal while a new layout is loaded, I haven't decided yet what should I do. But it is not urgent, I will try to fix it during this cycle. Anyway, I think it's better to block the signal in the application.

It is marked to be committed. I hoped that you would commit it :)

(In reply to comment #23)
> It is marked to be committed. I hoped that you would commit it :)

Ok, it's done.

*** Bug 687680 has been marked as a duplicate of this bug. ***

*** Bug 687614 has been marked as a duplicate of this bug. ***

*** Bug 687432 has been marked as a duplicate of this bug. ***

*** Bug 687322 has been marked as a duplicate of this bug. ***

*** Bug 685845 has been marked as a duplicate of this bug. ***

Created attachment 228963 [details]
Wrong layout disposal

Errr... sorry but it doesn't work for me :(

I've cloned and compiled a fresh copy from Git, and the program opens and works properly, but layout is not saved.

I'm testing it under Ubuntu 12.10 (Quantal) up-to-date and when I open GTR, the layout I previously configured (moved the translation memory field, reduced the messages table, etc) is lost, and I have to reorder it again.

Here are all the messages and warnings I get when running GTR with a PO file as an argument:

$ gtranslator accerciser.gnome-3-6.es.po 

(gtranslator:31461): Gtk-WARNING **: Theme parsing error: gtk-main.css:45:39: Failed to import: Error al abrir el archivo: No existe el archivo o el directorio

(gtranslator:31461): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
** Message: Dispose tab
** Message: Dispose translation memory ui
** Message: Finalize translation memory ui
** Message: Dispose context
** Message: Dispose context
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Dispose view
** Message: Finalize message table
** Message: Dispose tab
** Message: Finalize tab
** Message: window dispose
** Message: Finalize notebook
** Message: window dispose
** Message: Finalize window

(gtranslator:31461): GLib-GObject-WARNING **: invalid unclassed pointer in cast to `GtkWidget'

(gtranslator:31461): Gtk-CRITICAL **: gtk_widget_destroy: assertion `GTK_IS_WIDGET (widget)' failed
** Message: Disposing app

(In reply to comment #30)
> Errr... sorry but it doesn't work for me :(

No, the patch is working fine. The goal was only to fix the crash. It doesn't save the layout here neither.

I will take a look at this. I'm agree that it's probably linked to my changes in GDL but I haven't planned to work on all projects using it. It's a pity that such critical bug takes so much time to be fixed. Anyway, thanks for your work.

Created attachment 229011 [details] [review]
Another fix

Here is another patch fixing the segmentation fault and allowing to save and restore the layout.

It was still the same issue with the layout-changed signal.

GDL 3.6.0 emits the "layout-changed" signal when the layout changes, including when loading a new layout or when new widgets are added at initialization. It seems that older version of GDL were not emitting this signal in such condition.

gtranslator is saving the new layout after each change. At initialization, before loading the previous layout, the current default layout was saved overwriting the one save from the previous run.

This time, I propose a more drastic change. I have don't save the layout after each change anymore. Now the layout is saved only when the windows is destroyed. It means that if gtranslator crashs the layout will not be saved but I hope it's not a big issue.

Issue with latest patch:
main window part(strings, translation, original) not works as it should.
1. as far as i remember part which you could drag was in right, now you can drag left side(it's wrong)
2. in maximized window drag main tab to some position(eg. as far as possible to left border)-> make window windowed-> exit app->launch app->it restores wrong layout, even if you maximize window you won't get same as before exit

for the record: "main tab"/"main window part" i mean http://i.imgur.com/XEpWp.jpg

Review of attachment 229011 [details] [review]:

mmm, I do not get it... how is the layout saved now?

(In reply to comment #33)
> Issue with latest patch:
> main window part(strings, translation, original) not works as it should.
> 1. as far as i remember part which you could drag was in right, now you can
> drag left side(it's wrong)
> 2. in maximized window drag main tab to some position(eg. as far as possible to
> left border)-> make window windowed-> exit app->launch app->it restores wrong
> layout, even if you maximize window you won't get same as before exit

I have the same problem. When GTR is opened, the messages table doesn't fit all the window's area. I can drag it to the left border and it seems to be ok, but if I close the application or if I jus resize the window, reducing it, the table reduces itself.

The only part of the layout being saved are the Translation Memory and the Source code viewer sidepanels: if I resize or move them, the layout is saved and correctly restored the next time, but not the table message.

Also, I'm still getting some warnings when launching it from the command-line:

(gtranslator:17800): Gtk-WARNING **: Theme parsing error: <data>:2:10: Not using units is deprecated. Assuming 'px'.

(gtranslator:17800): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

(In reply to comment #35)
> Review of attachment 229011 [details] [review]:
> mmm, I do not get it... how is the layout saved now?

Now the layout is saved only when the windows is destroyed.

static void
gtr_tab_dispose (GObject * object)
{
  ...
  if (!priv->dispose_has_run)
    {
      save_layout (GTR_TAB (object));

(In reply to comment #33)
> 1. as far as i remember part which you could drag was in right, now you can
> drag left side(it's wrong)

Thanks for the picture but I don't understand the issue. If you want to have the "Message Details" and "Translation Memory" windows on the right, you can just drag and drop these windows on the right.


Or the issue is that you want to have these windows on the right in the default layout?

I have delete the file .config/gtranslator/layout.xml. The default layout is a bit strange, there are some empty spaces. I think it's a issue in GDL.


> 2. in maximized window drag main tab to some position(eg. as far as possible to
> left border)-> make window windowed-> exit app->launch app->it restores wrong
> layout, even if you maximize window you won't get same as before exit

I have some strange behavior of GDL in some condition. I think it's linked to the same issue than above. Empty panes or notebooks should be hidden which is not always the case. I will try to fix in this cycle.


I'm agree that there are issues with GDL and I appreciate to get bug reports. They are the first one on such thing. Anyway this patch is working as expected.

(In reply to comment #36)
> I have the same problem. When GTR is opened, the messages table doesn't fit all
> the window's area. I can drag it to the left border and it seems to be ok, but
> if I close the application or if I jus resize the window, reducing it, the
> table reduces itself.

Yes, this is indeed an issue with GDL.

 
> The only part of the layout being saved are the Translation Memory and the
> Source code viewer sidepanels: if I resize or move them, the layout is saved
> and correctly restored the next time, but not the table message.

The size of the empty space is not saved or not restored. If you put a window in this empty space on the left, everything looks fine to me.


> Also, I'm still getting some warnings when launching it from the command-line:
> (gtranslator:17800): Gtk-WARNING **: Theme parsing error: <data>:2:10: Not
> using units is deprecated. Assuming 'px'.

I get this too, I don't know from where it comes from. I doesn't seem harmful.

 
> (gtranslator:17800): GLib-GObject-CRITICAL **: g_object_unref: assertion
> `G_IS_OBJECT (object)' failed

I don't get this one, just a backtrace to know from where it comes from would be useful.

(In reply to comment #38)
> (In reply to comment #33)
> > 1. as far as i remember part which you could drag was in right, now you can
> > drag left side(it's wrong)
> 
> Thanks for the picture but I don't understand the issue. If you want to have
> the "Message Details" and "Translation Memory" windows on the right, you can
> just drag and drop these windows on the right.
> 
> 
> Or the issue is that you want to have these windows on the right in the default
> layout?
> 
> I have delete the file .config/gtranslator/layout.xml. The default layout is a
> bit strange, there are some empty spaces. I think it's a issue in GDL.
> 
> 
look to another picture, there is two versions side by side. One with your „Another fix“ other without it, both uses gdl 3.6. differences are obviuos. http://i.imgur.com/Ue4gn.jpg

(In reply to comment #40)
> look to another picture, there is two versions side by side. One with your
> „Another fix“ other without it, both uses gdl 3.6. differences are obviuos.
> http://i.imgur.com/Ue4gn.jpg

Ok. With my last patch gtranslator is working as I expect.

Then I think there is a bug in GDL, because the empty space on the left should be hidden. I will try fix it in the next version of GDL. I haven't seen this before on Anjuta.

This empty space is used by two windows named GtrOpenTranPlugin and GtrCharmapPanel. If you don't have them you can edit the layout.xml file with a text editor and remove them with the additional notebook and paned object containing them. It should fix all issues reported here.

I don't know why I don't have these windows (GtrOpenTranPlugin and GtrCharmapPanel). If it's a normal situation, I can remove them in the default layout file.

Removed those lines, that solves all issues. 

By default in gtranslator charmap and opentran plugins are disabled, so either in layout.xml theirs space reservation lines should be removed either they must be enabled by default. Imho by default remove those lines in layout.xml it's better workaround.

Created attachment 229218 [details] [review]
Same than "another fix" with the hidden panes removed in the default layout

My primary goal is to find an acceptable fix in gtranslator which is currently quite unusable due to the changes in GDL. I hope this one is acceptable.

Then, I will try to fix GDL so it can handle correctly the use case of gtranslator but it will take more time.

Thanks for your feedback.


By the way how could I enable charmap and opentrans plugin?

(In reply to comment #43)
> Created an attachment (id=229218) [details] [review]
> Same than "another fix" with the hidden panes removed in the default layout
> 
> My primary goal is to find an acceptable fix in gtranslator which is currently
> quite unusable due to the changes in GDL. I hope this one is acceptable.
> 
> Then, I will try to fix GDL so it can handle correctly the use case of
> gtranslator but it will take more time.
> 
> Thanks for your feedback.
> 
> 
> By the way how could I enable charmap and opentrans plugin?

You can go to the Edit->Preferences menu and select the Plugins tab to enable them.

If I'm not wrong, to enable the Charmap plugin you need to install libgucharmap-dev to compile Gtranslator with support for it (at this momment, I have no access to my laptop, so I can't confirm it).

If not tested the new patch, but it seems to be ok so, if Nacho agrees, you could commit it.

Again, many thanks for your help with this issue (and also thanks to gymka for testing patches and providing feedback) :)

(In reply to comment #44)
> You can go to the Edit->Preferences menu and select the Plugins tab to enable
> them.
> 
i think atleast few versions back, gtranslator preferences menu moved to gtranslator->gtranslator(menu above file menu)->preferences.

>If I'm not wrong, to enable the Charmap plugin you need to install
>libgucharmap-dev to compile Gtranslator with support for it (at this momment, I
>have no access to my laptop, so I can't confirm it)
in archlinux these packages named: 
    gucharmap - for charmap plugin
    json-glib - for open-tran plugin


for the record: current gtranslator version(released, in ftp) not works with gdl 3.6, it simply crashes. people who not reads bugzilla can't use gtranslator already for two weeks(atleast archlinux users, maybe in ubuntu gdl package is still far from 3.6 version). so it would be good if patches would be accepted asap and new version of gtranslator would be released.

tested latest patch, everything works as it should.

(In reply to comment #45)
> i think atleast few versions back, gtranslator preferences menu moved to
> gtranslator->gtranslator(menu above file menu)->preferences.

Thanks, I remember it was possible before but I haven't found the menu. I have enabled the Open Tran plugin and it seems to work fine. At least better than what you have reported.


> for the record: current gtranslator version(released, in ftp) not works with
> gdl 3.6, it simply crashes. people who not reads bugzilla can't use gtranslator
> already for two weeks(atleast archlinux users, maybe in ubuntu gdl package is
> still far from 3.6 version). so it would be good if patches would be accepted
> asap and new version of gtranslator would be released.

I'm fully agree and I'm sorry as I have a major responsibility here.

(In reply to comment #46)
> (In reply to comment #45)
> > i think atleast few versions back, gtranslator preferences menu moved to
> > gtranslator->gtranslator(menu above file menu)->preferences.
> 
> Thanks, I remember it was possible before but I haven't found the menu. I have
> enabled the Open Tran plugin and it seems to work fine. At least better than
> what you have reported.
i reported as is, then you install gtranslator to clean home folder, without any changes. de facto: in my last picture you see what you see then you install gtranslator, there is empty space in left and if you drag notepad part to there after app restart it won't be in same position. ofcourse if you enable additional plugins everything looks ok, but application should work "out of the box", not after tweaking it's settings!

Please start pushing the patches.
As I said before I still have some concerns about them:
 * the layout should be saved always it changes and at the end of the application

Apart from that I prefer to have them already included so distros can apply them downstream.

(In reply to comment #48)
> Please start pushing the patches.

I have pushed it.


> As I said before I still have some concerns about them:
>  * the layout should be saved always it changes and at the end of the
> application

I have already replied to that (comment 32 and 37). With the patch that I have just pushed, the layout is saved only at the end of the application. So I think the only difference is that if the application crashes the layout will not be saved. Is it an issue for you or is there something else?


Then the "layout-changed" signal is emitted when the layout is changed, not during the save as you write in comment 18. But it is emitted during the load and I think several times. So the issue is that after the first change, the half loaded layout is saved erasing the current one. I don't know how to fix it in GDL. I will try to see what can be done but it can be quite difficult.


Please report any issue you can find with this patch or more generally with the new version of GDL.

Created attachment 229509 [details] [review]
A third fix for this bug

I have spent a bit more time to understand what's happen.

The "layout-changed" signal is emitted each time there is a change in the layout. So if you move a pane division but if you add or remove a new dock item too.

* On startup in gtr_tab_init and in gtr_tab_new, you add new widgets in the layout by example (line 738 add_widget_to_dock) and each plugin add its own widgets too. At that time, the "layout-changed" signal is already connected, so you already save the layout while it is not complete. It has not even be loaded because this is done much later in gtr_tab_realize. So finally, you load not the previous layout but the default one that has already been saved a few times on startup.

I could perhaps not emit the layout-changed signal if the widget is not realized but I'm not convince it's right. You really dock new widgets, it can be useful to know about it. What do you think?


* On shutdown, there is a similar issue. You save the layout in the gtr_tab_dispose function which is normally useless because you already save it on each change. But afterward, the plugins are removing their windows which is changing the layout again and which triggers additional saves with a layout where some windows are missing. This is the loading of this corrupted layout that crash GDL.

Again, I'm not sure it's better to not emit the layout-changed signal. The layout manager and the master are still alive. What do you think?



Based on this, here is a patch that is connecting the on_layout_changed signal after loading the layout and disconnect it when destroying the GtrTab widget. I think it's the right fix but tell me if you have another idea.

Review of attachment 229509 [details] [review]:

Sounds good to me. Please push it.

*** Bug 690131 has been marked as a duplicate of this bug. ***

I just stumbled upon this by occasion, as the initial description and the title are not obvious.

There is not even a trace here to match against, adding it below from Trace 231288

crash still happens with latest git master
in gtk_ui_manager_get_widget ()

#1 showed_message_cb 
 at gtr-translation-memory-ui.c line 146 


Deleting ~/.config/gtranslator/layout.xml remedies

+ Trace 231289

hmm ok I got hit again. I changed my distribution from Fedora to Ubuntu. Ubuntu uses 2.91.5 . Opening a PO file there results in no messages being displayed - I have not investigated this, looks like the message display and other widgets do not show up ... rather uninstalled it and compiled gtr from git master. git master I get 

(gtranslator:11732): GLib-GObject-WARNING **: invalid cast from `GdlDockItem' to `GtrWindow'

the offending layout.xml was

<?xml version="1.0"?>
<dock-layout><layout name="__default__"><dock name="__dock_1" floating="no" width="-1" height="-1" floatx="0" floaty="0" skip-taskbar="yes"><paned orientation="vertical" locked="no" iconified="no" closed="no" position="0"/></dock></layout></dock-layout>


=> my primary concern: users might go my upgrade path, and gtranslator will crash, and it will be hard for them to know why. Not every user is capable of finding this report and removing layout.xml
Does it make sense to spend some time on implementing a graceful recovery from this situation?

By the way, the official documentation suggests something like this


--- a/plugins/translation-memory/gtr-translation-memory-ui.c
+++ b/plugins/translation-memory/gtr-translation-memory-ui.c
@@ -142,9 +142,12 @@ showed_message_cb (GtrTab *tab, GtrMsg *msg, GtrTranslationMemoryUi *tm_ui)
   model = GTK_LIST_STORE (gtk_tree_view_get_model (GTK_TREE_VIEW (tm_ui->priv->tree_view)));
 
   window = gtk_widget_get_toplevel (GTK_WIDGET (tm_ui));
-  manager = gtr_window_get_ui_manager (GTR_WINDOW (window));
-  tm_menu = gtk_ui_manager_get_widget (manager, "/MainMenu/EditMenu/EditOps_1/EditTranslationMemory
-
+  if (gtk_widget_is_toplevel (window))
+   {
+       manager = gtr_window_get_ui_manager (GTR_WINDOW (window));
+       tm_menu = gtk_ui_manager_get_widget (manager, "/MainMenu/EditMenu/EditOps_1/EditTranslationM
+   }
+       
   g_signal_connect (tm_ui->priv->tree_view,
                     "size_allocate",
                     G_CALLBACK (tree_view_size_cb), tm_ui->priv->tree_view);

We are mass-closing old gtranslator issues as the latest versions of gtranslator (3.30 or later) should fix most of the reported problems and as there is unfortunately no capacity to retest all of them separately.
https://mail.gnome.org/archives/desktop-devel-list/2019-February/msg00059.html

If the issue described in this report still happens in gtranslator version 3.30 or later, please file a new ticket under https://gitlab.gnome.org/GNOME/gtranslator/issues/ - thanks for your understanding!

We are sorry that your report was not handled / fixed after you reported it - many free and open source software projects receive more bug reports and feature requests than they have developers who have free time to work on them.
If you would like to get involved and contribute on gtranslator code, please check https://wiki.gnome.org/Git/Developers