Fix crashes caused by MateImageMenuItem vs GtkImageMenuItem conflict

[raveit65]

• fix crashing panel with --replace option

This reverts commit 675f72f.

First fix for #1433

[lukefromdc]

This was only half the problem, we also need to revert the earlier PR (rushed now and cannot find it) that first replaced GtkImageMenuItem with MateImageMenuItem.

With this, the "places" and "system" icons disappear from those menu items in the main menu at least w the compact menu

[raveit65]

Are you sure? I asked for that here #1433 (comment)
I think ebb3a79 is independent from GType issue.

[lukefromdc]

Keeping ebb3a79 by itself doesn't actually USE MateImageMenuItem for the offending compact menu items, thus the missing icons on the compact menu. What 675f72f actually did was to redefine these menu items to use our code, without it nothing is used for these two icons.

[raveit65]

My results are different. I only need to revert this commit to fix the crash, which you never couldn't reproduce.
In this post #1433 (comment) @cwendling did only speak about reverting this commit.
Anyway, feel free to close this PR if you think it is wrong.
As is said before, i fixed this already for fedora........so i have no rush and can wait.

[lukefromdc]

The other commit is not the reason for the crash but rather the reason for the missing icons when used by itself. I am not going to close this now, because I think a proper technical fix keeping our replacement function is possible when used w the mate-desktop change. I will have to drill down into that, hopefully tonight.

[lukefromdc]

Pretty sure the mission icons were ONLY in the compact menu BTW

[raveit65]

Which missing icons? I have no idea you're talking about without a report about missing icons.
I don't see any missing icons with using ebb3a79

[lukefromdc]

Places and System menu items in compact menu below

[lukefromdc]

OK, I will work on this and get it fixed right

[lukefromdc]

I just found that 675f72f was incomplete, in panel-menu-items.h we are still using gtk_image_menu_item and not mate_image_menu_item, I am surprised this ever worked, anywhere. Preparing a PR to fix that, will test against my menuitem drag to panel crash in the compact menuy

[lukefromdc]

Reopening for further development. Plan is to pack the icons into those two menuitems within the panel code instead of relying on MateImageMenuItem, as a workaround for the fact that MateImageMenuItem is declared as "final," cannot be subclassed, and thus won't work as a replacement for GtkImageMenuItem in this particular case.

[lukefromdc]

In testing, this shows the "Places" and "System" icons in the compact menu and does not crash on dragging a program icon from the compace menu to the panel. Needs a mate-panel --replace test vs 1.28.0 release on a system where that crashes

[lukefromdc]

I had to copy some code from menu.c to make this work as a strictly static (local to one file) function. This and using deprecated GtkImageMenuItem are a workaround for 1.28 since we should not change library dependencies. When we move on to the 1.29 development branch we can revert this, not declare MateImageMenuItem as final in mate-desktop, and use MateImageMenuItem in these two places where it has to be subclassed but now cannot be.

If others want, I can mark the places in panel-menu-items.c and the two places in panel-menu-items.h where we use GtkImageMenuItem as FIXME, and same for the two functions added to panel-menu-items.c to support this case.

[lukefromdc]

We can close this in favor of mate-desktop/mate-desktop#603 and a panel PR to replace GtkImageMenuItem with MateImageMenuItem and include libmate-desktop/mate-image-menu-item.h in mate-panel/panel-menu-items.h if we decide to allow a breaking change just after the brand-new 1.28 release, or we can keep this fix for 1.28, bump versions, and use those for 1.29 to avoid a breaking change in 1.28.0. Deeming this not my choice to make

[zhuyaliang]

If we accept it mate-desktop/mate-desktop#603 We can continue to use MATE_TYPE_IMAGE_MENU_ITEM.No need to reverts commit

[cwendling]

As said in mate-desktop/mate-desktop#603 (comment), I don't really like how this is growing, and would rather merge mate-desktop/mate-desktop#603 and depend on it (that is, update the dependency and use the right type as the parents in the structure).

[raveit65]

Can be closed or not?

[lukefromdc]

Fine with closing this so long as we are OK with depending on a new mate-desktop version