fl_choice() dialog apprearance discrepancy problem in 1.4

    If we're suspecting that kind of thing, be sure to rename away /usr/include/FL (if it exists) to 'something else',
    so it doesn't get picked up by accident.

Why do you need to rebuild ask at all, I still don't get what your doing and what you want to achieve.

I'm seeing differences in the two ldd text files. Seems your build (or your runtime environment) includes different shared libs. Where does this come from? I noticed your post about vnc and non-vnc runs but I don't know how much that can influence the issue. Are you connecting to the system via vnc from another host or are you running it on the same host?

--- ask-ldd.txt    2021-12-09 17:44:24.528492511 +0100
+++ ask-ldd-app.txt    2021-12-09 17:44:24.496492416 +0100
@@ -1,5 +1,5 @@
-[root@athabasca test]# ldd ask
-    linux-vdso.so.1 =>  (0x00007ffecbde8000)
+[pdhahn@athabasca fltkapi]$ ldd /vol1/athabasca/apps/fltk/fltk-clone/test/ask
+    linux-vdso.so.1 =>  (0x00007ffef9551000)

The above diff might not cause any issues but ...

-    libstdc++.so.6 => /vol1/athabasca/apps/usr/local/latest/lib64/libstdc++.so.6 (0x00007f93f4d65000)
-    libgcc_s.so.1 => /vol1/athabasca/apps/usr/local/latest/lib64/libgcc_s.so.1 (0x00007f93f4b4f000)
+    libstdc++.so.6 => /vol1/athabasca/apps/usr/local/gcc-5.1/lib64/libstdc++.so.6 (0x00007fc2c2aeb000)
+    libgcc_s.so.1 => /vol1/athabasca/apps/usr/local/gcc-5.1/lib64/libgcc_s.so.1 (0x00007fc2c28d5000)

This looks suspicious. Two different libgcc and libstdc++ versions?

-    /lib64/ld-linux-x86-64.so.2 (0x00007f93f50f2000)
+    /lib64/ld-linux-x86-64.so.2 (0x00007fc2c2e78000)

Again, probably irrelevant.

OKAY, here's another test. Please check out an older git version to rule out the recent changes to fl_choice():

$ git checkout 7b9ddd97c

Rebuild (just running make in a CMake build dir should suffice) and test again. As others said, remove "other" FLTK dirs and make sure to pick the correct fltk-config script if you build another executable.

It would also be interesting to see if this problem is *only* related to fl_choice() or if there are other issues. Please test a few other FLTK test programs as well.

 

OKAY, here's another test. Please check out an older git version to rule out the recent changes to fl_choice():

$ git checkout 7b9ddd97c

Rebuild (just running make in a CMake build dir should suffice) and test again. As others said, remove "other" FLTK dirs and make sure to pick the correct fltk-config script if you build another executable.

It would also be interesting to see if this problem is *only* related to fl_choice() or if there are other issues. Please test a few other FLTK test programs as well.

Sounds good.  I will try that right away.

#1) 240465626 2021-12-04 13:40:29 +0100 Albrecht Schlosser - Add minimal version of class Fl_String
#2) b6de09cff 2021-12-04 14:49:27 +0100 Albrecht Schlosser - Re-enable nested (aka recursive) common dialogs (STR 3242, #282)
#3) 7a7e50df6 2021-12-04 15:34:41 +0100 Albrecht Schlosser - Rename FL/Fl_String.H to FL/Fl_String_class.H
#4) 130f864d1 2021-12-04 15:50:10 +0100 Albrecht Schlosser - Rename src/Fl_String.cxx to src/Fl_String_class.cxx
#5) a0724ab7c 2021-12-04 20:36:11 +0100 Albrecht Schlosser - Add fl_message_icon_label() function (STR #2762)

What shell do you build from? Is it the “local” one or the “VNC" one?

I wonder because the different ldd outputs for the two contexts imply, to me at least, they are seeing different runtime environments, so I wonder if there is something in one environment that is not in the other, and that is throwing the build out in some way?


In particular, if the build is done from within the VNC context, and is setting some different env setting, that might go some way to explain why that context then runs OK later, and not the other.

That all said, I won't be able to reply further tonight, but I'm looking forward to see your replies tomorrow.

That all said, I won't be able to reply further tonight, but I'm looking forward to see your replies tomorrow.

OK sounds good. I will reply later with the information. Thanks, Albrecht.

On 12/10/21 12:42 AM Paul Hahn wrote:

On Thursday, December 9, 2021 at 3:57:46 PM UTC-6 Paul Hahn wrote:

That all said, I won't be able to reply further tonight, but I'm looking forward to see your replies tomorrow.

OK sounds good. I will reply later with the information. Thanks, Albrecht.

Looks like I have a fix that solves my problem.

1. I added a call to window_->init_sizes() at the end of Fl_Message::resizeform() in Fl_Message.cxx.

2. I also modified Fl_Message::innards() to call Fl_Group::current(0) before the call to window_->show().  [ Not sure this one is necessary but it looks to me like it is missing. ]

The good news: both your proposed changes are correct. Great findings!

The bad news: if you compare src/Fl_Message.cxx with an older src/fl_ask.cxx (I used branch-1.3 for comparison) you'll notice that these code sequences have not been changed at all.

That's weird. Although these changes are not wrong they should not have much influence on the overall behavior of the program, particularly not test/fl_ask.cxx. I always like to fix bugs when you have a clear test case that shows a but in the old code and works well with the new code.

Here I must admit that I can't believe that these code changes are the root causes for the behavior you see, particular because this has "always been this way". But there may be a connection, hence I believe we should apply them. However there's still some doubt...

I'll discuss this further below.

Here is the git diff on src/Fl_Message.cxx.

> git diff src/Fl_Message.cxx
diff --git a/src/Fl_Message.cxx b/src/Fl_Message.cxx
index 4332416..cfe4c5c 100644
--- a/src/Fl_Message.cxx
+++ b/src/Fl_Message.cxx
@@ -274,6 +274,7 @@ void Fl_Message::resizeform() {
       button_[i]->resize(x, h - 10 - max_h, button_w[i] - 10, max_h);
     }
   }
+  window_->init_sizes();
 }

OK, this is correct. Although it's not been in 1.3 and not in the old commit you tested (before this change).

The only explanation I have is that some internal window size changes (aka resize()) that depend on a particular window manager (or VNC?) trigger a resize of the main window that eventually makes the buttons appear in the wrong places. 'window_->init_sizes();' should fix this. It's better to have it than not.

Patch "accepted".

 /**
@@ -376,6 +377,8 @@ int Fl_Message::innards(const char *fmt, va_list ap, const char *b0, const char
   if (g)
     Fl::grab(0);
   Fl_Group *current_group = Fl_Group::current(); // make sure the dialog does not interfere with any active group
+  if (current_group)
+    Fl_Group::current(0);  
   window_->show();
   Fl_Group::current(current_group);
   while (window_->shown())

Same as above, this has not been in the old code (hence it should not trigger a regression) but I agree that it is also correct to add it here. The comment makes clear that this is (was) the intended behavior, particularly because the reset ('Fl_Group::current(current_group);') *is* done after show().

Off the top of my head I can say that ISTR that at least one of the overloaded show() methods always did set Fl_Group::current(0); but I'm not sure.

Anyway, the patch is good. Accepted. How did you find this?

However I would prefer not to use the line 'if (current_group)' because it's unnecessary and instead just add the line Fl_Group::current(0);

(just in case you send a patch or make a PR, otherwise I can apply it tomorrow).

Shall I open an issue with this suggested change in github?

It's not necessary, I can apply the patch tomorrow. However, if you like to see a commit with your name, then please

Thank you very much for finding this. I'm still surprised that this fixes the issue for you but it's IMHO really good to apply your patch. I must admit that I didn't look at the code in the first place given your description of the issue.

On 12/10/21 4:24 AM Paul Hahn wrote:

On Thursday, December 9, 2021 at 8:37:43 PM UTC-6 Albrecht Schlosser wrote:

The only explanation I have is that some internal window size changes (aka resize()) that depend on a particular window manager (or VNC?) trigger a resize of the main window that eventually makes the buttons appear in the wrong places. 'window_->init_sizes();' should fix this. It's better to have it than not.

I think your speculation on causality is on the right track. The effect was real. Yes, you never know about this kind of thing -- it may have eventually shown up as a mystery for someone else down the road, under the right circumstances, not only now for me on my old CentOS 6 + gcc 5.1 platform.

I've seen some strange resizing sequences on application startup when working on another topic (an STR about "tiny windows"). You may find a commit with reference to this STR. The sequences I saw included resizing the window to width/height (1, 1) before it was resized to its final size. This made me think of a similar "feature" of the WM you are using.

But let's finish this now, the problem is solved. And I learned that you can never know what a WM does with your windows. ;-)

It's not necessary, I can apply the patch tomorrow. However, if you like to see a commit with your name, then please

No, I do not need to have my name on the commit, so please just do the changes on your side.

Done. Commit a8cc34032.

Might I also add tongue-in-cheek, that maybe CentOS 6 w/ gcc 5.1 should become a reference test-bed for FLTK, since as Ian reported, he could not see the problem on the more modern linux platforms at his disposal. Not that this particular platform is used by anyone other than me, but it could serve as a good "sieve". :-)

Might I also add tongue-in-cheek, that you are friendly invited to do these checks for the FLTK community?  ;-)

Seriously: your findings are very much appreciated and every system we can test FLTK on is an advantage. Unfortunately we don't have a build and test farm (except what GitHub Actions and GitLab CI provide). Your issue would hardly have been found by testing unless by accident. It's clear that nobody can test all applications on all platforms. Unit tests that include graphic output would be fine but hard to achieve, impossible for our team. All the different configure/CMake options multiply to a giant set of different configurations, notwithstanding all the different platforms.

That said, I started a while ago using docker containers for build tests. I could for instance install a Sci Linux 7 (not sure about the exact version) docker instance for a problem Greg was facing and I could replicate and solve it. That's cool!

I may also look for a CentOS 6 docker container if time permits which is currently very unlikely. That would also be a nice enhancement. But these containers don't use their own WM's, they use the display of the host system - hence I wouldn't have been able to find your issue because it was very likely caused by WM interactions.

The only way out of this dilemma (is it?) is to install a VM with that particular OS and to use the Window Manager in question. Which leads me to the hopefully last three questions in this thread, just in case I can find an old distro image (see below) which I can install in a VM: which WM did you use, and do you have a link to (official) CentOS 6 installation images (see also below)?

FTR: Docker images of CentOS (CentOS 6 to 8): https://registry.hub.docker.com/_/centos/

ISO images for CentOS 6.6: https://vault.centos.org/6.6/isos/x86_64/ (picked an arbitrary version 6.6)

There are also other 6.x versions, so here is the third and last question: which Centos 6 version are you using? The range is from 6.0 to 6.10.

On 12/10/21 9:55 PM Paul Hahn wrote:

OK, thank you. With this information (particularly that of updating the repo URL's) I'll find my way when (if!) I can find the time to install yet another VM. But I'm curious how this may work out, hence it's possible that I'll do it (soon'ish).