[ . . . ]Now I go to the test subdirectory under my fltk-clone. I delete ask.o and the ask executable. I then do fltk-config --compile ask.cxx.
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.
Great questions. [ For this reply, I will only reference test/ask (and not my app code), because it suffices to illustrate the problem. ]
Ian: Yes, I build FLTK as static libs (.a), install those to a local directory, and link with those.
Albrecht: Yes, I always use cmake.
OK, I will tick off the steps I just now took for verification. I did a complete rm -rf * of the contents of my build subdirectory under my fltk-clone (repo) directory. There, I did cmake-gui .. to again configure (e.g., with NO shared libs) and generate.I then did make in that build directory. Looks 100% clean. I then did a rm -rf * in my installation directory, followed by make install back in the build directory, which repopulated the installation directory. Now I go to the test subdirectory under my fltk-clone. I delete ask.o and the ask executable. I then do fltk-config --compile ask.cxx. All good. Attached is a file "ask-ldd.txt" with the ldd output on the ask executable which verifies no FLTK shared libs are being used.
The problem still appears as previously described. When I run the rebuilt ask executable (as root) in its test directory as root, I get the expected display from fl_choice(). However, when I run that same ask executable from my development directory (as me), I get the same problematic display. the attached file "ask-ldd-app.txt" has the output from ldd on the same ask executable done in the latter directory as me.
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.
So what in the world happened in FLTK after that???
#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.
Result of my "git bisect" investigation: the problem shows up for me at version b6de09c "Re-enable nested (aka recursive) common dialogs (STR 3242, #282)" (Albrecht S). The problem does NOT show up at the previous checkin, 2404656.
In the meantime, I am hoping that Albrecht might offer some insights or speculation on what happened in that checkin that may have caused the problem to show up for me.
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 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. ]
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();
}
/**
@@ -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())
Shall I open an issue with this suggested change in github?
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 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.
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.
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". :-)
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).