emelfm2 will not compile on Arch after gtk3 upgrade

[Geoff]

Hello,

I did my usual daily full update of Arch today. I attach as upgrades.txt a
list of all that was done. This includes gtk3 (3.8.4-1 -> 3.10.0-2) which I
assume to be the culprit in what follows.

After the upgrade I had some horrible artifacts in emelfm2 with the "file
selected" bar the wrong colour and with multiple files highlighted when
scrolling. I think that was theme-related, and I have subsequently cured
it by setting "banded background" on. Before finding that fix I decided
to recompile my current version of emelfm2 (downloaded from svn on 2nd
October). It would no longer compile. I downloaded the current svn, and it
will not compile either. I attach compilation.txt.

Geoff

[t***@onepost.net]

On Mon, 7 Oct 2013 19:49:56 +0100
Geoff <***@yahoo.co.uk> wrote:

Thanks, Geoff.

Post by Geoff
I did my usual daily full update of Arch today. I attach as upgrades.txt a
list of all that was done. This includes gtk3 (3.8.4-1 -> 3.10.0-2) which I
assume to be the culprit in what follows.

Yes.

Post by Geoff
After the upgrade I had some horrible artifacts in emelfm2 with the "file
selected" bar the wrong colour and with multiple files highlighted when
scrolling. I think that was theme-related, and I have subsequently cured
it by setting "banded background" on.

Yup, I presume the tradition continues - break all themes with every release.

Before finding that fix I decided

Post by Geoff
to recompile my current version of emelfm2 (downloaded from svn on 2nd
October). It would no longer compile. I downloaded the current svn, and it
will not compile either. I attach compilation.txt.

I haven't yet installed gtk 3.10, so I've only been sporadically investigating what is newly-deprecated in there. The stock-items stuff I've mentioned before, on this list.

You might try a fresh checkout from svn. That will probably fix most, or maybe even all, of the problems you encountered. At a cost, though. Current gtk themes probably won't yet have replacements for gtk's default icons. Having relied on those up to now, you'll see buttons, menus etc without icons, or with missing-icon icons. On the plus side, there will be a squillion other icons available from the default theme, which can be selected for use in the toolbars. Maybe I can find a way to keep the deprecated stock-items in play, without causing so much compiler-verbage.

I don't know why your build wouldn't link. Although you got lots of warnings, I didn't see any errors. It's possible that this gtk actually discarded one or two things by mistake, instead of deprecating.

Regards
Tom

[Geoff]

On Wed, 9 Oct 2013 16:31:25 +1100

Post by t***@onepost.net
You might try a fresh checkout from svn. That will probably fix most, or
maybe even all, of the problems you encountered. At a cost, though. Current
gtk themes probably won't yet have replacements for gtk's default icons.
Having relied on those up to now, you'll see buttons, menus etc without
icons, or with missing-icon icons. On the plus side, there will be a
squillion other icons available from the default theme, which can be selected
for use in the toolbars. Maybe I can find a way to keep the deprecated
stock-items in play, without causing so much compiler-verbage.

Thanks Tom,

The current svn did compile. I lost a couple of icons and was busy learning
how to install them when I came across the following issue, which seems to be
new with gtk-3.10. I cannot be absolutely certain that it is new, because I
don't change my emelfm2 configuration very often, but I have certainly never
seen this behaviour before. The problem affects both the new svn build and
my installed version from last week's svn. Steps to reproduce:

(1) Start emelfm2 and confirm that double click on any directory opens it as
usual.
(2) Open Change Configuration Settings window. Make and accept a change, or
simply discard and close the window.
(3) Double click on a directory to open it. Nothing happens.
(4) Double click again on the same directory (or another). Nothing happens. cpu
utilisation on one core now rises to 100% and stays there. I have to kill the
instance of emelfm2 with killall.

This affects both me, using my usual themed version of emelfm2, and my test
user with no theme set.

Geoff

[t***@onepost.net]

On Wed, 9 Oct 2013 15:04:51 +0100
Geoff <***@yahoo.co.uk> wrote:

Now we have another update, in which relevant stock icons are handled by emelfm2. This is intended as an interim arrangement, until themes catch up and include replacements for all gtk stock icons.

The "cost" is about 50kB of icons, and some code to process them. I've removed the ability to access all current-theme icons, processing them all is too slow during session start-up.

Post by Geoff
The current svn did compile. I lost a couple of icons and was busy learning
how to install them when I came across the following issue, which seems to be
new with gtk-3.10. I cannot be absolutely certain that it is new, because I
don't change my emelfm2 configuration very often, but I have certainly never
seen this behaviour before.

Nor have I, nor heard a report of it, so I assume it's the new gtk.

The problem affects both the new svn build and

Post by Geoff
(1) Start emelfm2 and confirm that double click on any directory opens it as
usual.
(2) Open Change Configuration Settings window. Make and accept a change, or
simply discard and close the window.
(3) Double click on a directory to open it. Nothing happens.
(4) Double click again on the same directory (or another). Nothing happens. cpu
utilisation on one core now rises to 100% and stays there. I have to kill the
instance of emelfm2 with killall.
This affects both me, using my usual themed version of emelfm2, and my test
user with no theme set.

No obvious reason why a config dialog would affect the filelist operation. This will need detailed investigation, after I get brave enough to install gtk 3.10.

Regards
Tom

[Geoff]

On Sat, 12 Oct 2013 12:45:24 +1100

Post by t***@onepost.net
Now we have another update, in which relevant stock icons are handled by
emelfm2. This is intended as an interim arrangement, until themes catch up
and include replacements for all gtk stock icons.

Compiles and works - subject to the problem I reported.

<snip>

Post by t***@onepost.net
No obvious reason why a config dialog would affect the filelist operation.
This will need detailed investigation, after I get brave enough to install
gtk 3.10.

It turns out to be worse than just the filelist. On further testing, even if I
do not try to change directory after closing the configuration window, some
files will not open at all on a double click (eg text files for which I use
leafpad), but others will (jpg's for which I use GQview). For files with no
association, the context menu appears ("Open with" etc), but nothing can be
selected within it.

Incidentally my year-old emelfm2 2-0.8.1 (compiled against gtk3.6.4) throws up a
lot of gtk errors in the xterm, but otherwise continues to work perfectly,
suffering from none of the above issues. I may fall back on that version, or
compile a more recent version against a private copy of an older gtk3, until
you have the opportunity to get to grips with these problems.

Geoff

[t***@onepost.net]

On Sat, 12 Oct 2013 10:02:11 +0100

Post by Geoff
On Sat, 12 Oct 2013 12:45:24 +1100

Post by t***@onepost.net
Now we have another update, in which relevant stock icons are handled by
emelfm2. This is intended as an interim arrangement, until themes catch up
and include replacements for all gtk stock icons.

Compiles and works - subject to the problem I reported.
<snip>

Post by t***@onepost.net
No obvious reason why a config dialog would affect the filelist operation.
This will need detailed investigation, after I get brave enough to install
gtk 3.10.

It turns out to be worse than just the filelist. On further testing, even if I
do not try to change directory after closing the configuration window, some
files will not open at all on a double click (eg text files for which I use
leafpad), but others will (jpg's for which I use GQview). For files with no
association, the context menu appears ("Open with" etc), but nothing can be
selected within it.
Incidentally my year-old emelfm2 2-0.8.1 (compiled against gtk3.6.4) throws up a
lot of gtk errors in the xterm, but otherwise continues to work perfectly,
suffering from none of the above issues. I may fall back on that version, or
compile a more recent version against a private copy of an older gtk3, until
you have the opportunity to get to grips with these problems.

Old story from here - good news and bad ...

First - I installed 3.10.0, rebuilt emelFM2, and so far have found it works better than on 3.8.4. Still no horizontal scrollbars, or menu icons (even when deprecated code which is supposed to add such icons is re-enabled). Not a whole lot of testing, but it does pass the 'steps to reproduce' that you posted recently.

The bad - this makes it much harder to figure out why yours is not working. Almost certainly will need to customise some files with extra debug messages. I'll start by thinking about what's different between 0.8.1 and current svn. Would be good to get as much insight as you can provide about precise circumstances and trains of events, including cases where things still work.

Regards
Tom

[Geoff]

On Sun, 13 Oct 2013 00:21:40 +1100
<***@onepost.net> wrote:

<snip>

Post by t***@onepost.net
Old story from here - good news and bad ...
First - I installed 3.10.0, rebuilt emelFM2, and so far have found it works
better than on 3.8.4. Still no horizontal scrollbars, or menu icons (even
when deprecated code which is supposed to add such icons is re-enabled). Not
a whole lot of testing, but it does pass the 'steps to reproduce' that you
posted recently.
The bad - this makes it much harder to figure out why yours is not working.
Almost certainly will need to customise some files with extra debug messages.
I'll start by thinking about what's different between 0.8.1 and current svn.
Would be good to get as much insight as you can provide about precise
circumstances and trains of events, including cases where things still work.

Is this a clue? The problem does not occur if I set DEBUG?=1 in
Makefile.config. I have tested this as rigorously as I can, several times using
the current (2805) svn and a fresh checkout for each test.

Geoff

[Geoff]

Just an observation - probably irrelevant. I notice that when DEBUG is set,
the closing of the Configuration window produces :

[DEBUG ] e2_action_run () ends
[DEBUG ] attempted BGL re-lock
[DEBUG ] config dialog cancel cb
[DEBUG ] config dialog widget destroy
[DEBUG ] e2_keybinding_disrol, category: ALL, widget: _
[DEBUG ] UNregister keybinding for widget

As you know, that [DEBUG ] attempted BGL re-lock comes from e3_main.c :
#ifdef DEBUG_MESSAGES
if (pthread_mutex_lock (&display_mutex) == EDEADLK)
printd (DEBUG, "attempted BGL re-lock");
#else
pthread_mutex_lock (&display_mutex);
#endif

In 2-0.8.1 that was:
#ifdef DEBUG_MESSAGES
if (pthread_mutex_lock (&gdklock) == EDEADLK)
printd (DEBUG, "attempted BGL re-lock");
#else
pthread_mutex_lock (&gdklock);
#endif

Geoff

[t***@onepost.net]

On Sat, 12 Oct 2013 19:37:14 +0100

Post by Geoff
Just an observation - probably irrelevant.

Quite probably is just what I needed.

The mutex-variable-name change since 0.8.x is irrelevant.

The type of mutex is (has always been) different with DEBUG enabled. From your experience, I guess one is more tolerant than the other.

Anyhow, go see e2_config_dialog.c. Change line 789, from

CLOSEBGL
to
LCLOSEBGL

Or get the same in the latest svn.

That missing "L" is probably causing a lot of grief!

Regards
Tom

[Geoff]

On Sun, 13 Oct 2013 13:02:25 +1100
<***@onepost.net> wrote:
<snip>

Post by t***@onepost.net
The mutex-variable-name change since 0.8.x is irrelevant.
The type of mutex is (has always been) different with DEBUG enabled. From
your experience, I guess one is more tolerant than the other.
Anyhow, go see e2_config_dialog.c. Change line 789, from
CLOSEBGL
to
LCLOSEBGL
Or get the same in the latest svn.
That missing "L" is probably causing a lot of grief!

Thanks Tom. That did the trick. I am now running this as my installed version.

Regards,

Geoff

[t***@onepost.net]

On Sun, 13 Oct 2013 08:28:57 +0100

Post by Geoff
On Sun, 13 Oct 2013 13:02:25 +1100
<snip>

Post by t***@onepost.net
The mutex-variable-name change since 0.8.x is irrelevant.
The type of mutex is (has always been) different with DEBUG enabled. From
your experience, I guess one is more tolerant than the other.
Anyhow, go see e2_config_dialog.c. Change line 789, from
CLOSEBGL
to
LCLOSEBGL
Or get the same in the latest svn.
That missing "L" is probably causing a lot of grief!

Thanks Tom. That did the trick. I am now running this as my installed version.

Good. That was much easier than I'd expected. Well done on your detective work.

The lesson - it's too easy to miss small differences!

All those "L*BGL"s are now "NEED*BGL"s (they're just tags for things needing attention when gtk finally stops handling mutexes in a suitable way).

As opposed to CLOSEBGL and OPENBGL which are function-call aliases.

Menu-item icons now working again on 3.10.

Regards
Tom