Thanks again, Ian, ...
In message <[email protected]>, Ian MacArthur <[email protected]> writes > >On 11 Feb 2013, at 20:14, Alec Ross wrote: > >> Thanks Ian, > >No worries... > >FWIW, I have built the PPP demo code on Ubuntu-12.10 and OSX now, for a >look, linked against 1.3.2... Some comments appended below... > for making this effort ... > > >>>> >>>> 2) A few simple, compilation problems in the example code that >>>> were >>>> easy to fix. >>> >>> Though perhaps unexpected? >>> I'd imagine those examples are well-tried, so if errors are being >>> encountered that might hint at some underlying problem? >> >> Indeed. > > >Well, that was interesting... > >The dialect of C++ the examples are in seems quite dated; all the >compilers I have access to whined about the code in places. >Several places needed actual interventions; > >- Several occurrences of Font had to be Graph_lib::Font to disambiguate >the meaning. > >- Several occurrences of Window had to be Graph_lib::Window to >disambiguate the meaning. > Yes, that seems to agree w/ my memory on my changes. I think that I had to #include <cstring> in one file, and perhaps one or two other things seem to have been needed. >The binaries, once built, did run, but... (more on that later...) > > >>>> >>>> Problem 1) above was encountered with or without an (1.3) version of >>>> FLTK separately installed on the machine. >>> >>> By "installed" do you really mean "installed" or just >>> "on the same machine"? >>> >> >> Wrt 1.3, I mean installed. Wrt the 1.1, I built and linked with this, >> but did not install it. This was intended to leave open the possibility >> of its not interfering with the use of the installed 1.3; and more >> importantly, I'd hoped to get a working version of the PPP examples, >> insulated from any changes coming w/ updates to the (FLTK) library. > > >Ah... word of caution though - *if* the fltk-1.3 headers were actually >installed, then when you tried to build a local fltk-1.1, there is a >really nasty chance that the compiler might pick up the (system, >installed) fltk-1.3 headers when you want the fltk-1.1 headers. > >Now, that *nearly* works, sort of, and I have even managed to compile >and link code in a messed up setup like that. >Wouldn't run though! > Well in my case, there was, as I said, failure to build using the fltk-1.1 whether or no 1.3 were installed. > > >>>> >>>> ;-( But there were no huge issues seen with the results, apart from >>>> those covered below, which might be unrelated to this change. >>>> >>>> In running the built example code, there was a problem related to >>>> closing the example window. Several of the samples have a "Next" >>>> button >>>> which worked - at least reasonably - reliably to effect closing. But >>>> the window's 'x' or close on its menu seemed to result in the app's >>>> looping. Is this to be expected? I've seen references saying that >>>> windows under FLTK, Fl::run() does not return until all of the windows >>>> under user control are hidden or closed. Is this related? > > >No, this appears to be a design choice in the PPP Simple_window class; >though I would have done it differently! > Sorry, I'd not looked into the source. I feared something like this; but perhaps even more that there was something odd due to corruption at the source or build levels. >If you look at the file GUI/Simple_window.cpp, in the method >Simple_window::wait_for_button(); there is a deliberate attempt to >ignore the window close button. >(Though implemented in a rather odd way, in fltk the better thing to do >would be to attach a null callback to the default window callback >handler, but I suspect Dr Stroustroup didn't want to take his students >down that particular rabbit hole at this stage in their studies!) > I'd guess so. >Also, at line 30 of that file he is spinning in a loop: > > while (!button_pushed) Fl::wait(); > >I think it would behave better with a slight delay set here, viz: > > while (!button_pushed) Fl::wait(0.1); > Agreed. Tho' his way might also impose less - irrelevant at this stage - cognitive load on the students, as you mentioned above. > > >>> Grab a tarball of fltk-1.3.2 from here, and then do the: >>> >>> ./configure ; make >>> >>> dance. >> >> I may do. But my "proper" installations were done from the package >> systems of Ubuntu (via GUI), and RPi (via apt-get at the command line). > > >Meh. IIRC the debian packagers (hence Raspbian and Ubuntu) mess about >with our packages, so I don't use them. The raw tarballs are preferred. > Noted. Thanks. I might well try this. (Tho' _if_ I were to adopt the code for teaching purposes, I might well want to "simplify" the install route by using pre-built packages.) > > >>>> Finally, on the Raspberry Pi's display, the lines are over-thin, and >>>> the >>>> colours (colors ;-)) are somewhat poor. > >Hmm, the colours look OK in my tests. The lines are a bit thin, but >about what I'd expect for a single-pixel not-anti-aliased line on X11. > Yes, the thickness ("thinness") is as expected; but results in shapes that are not very clearly outlined, or pleasing, when shown on a biggish screen with a higher res than an old-fashioned monitor. >Fltk does not anti-alias lines (well, except on host systems like OSX >where you get it whether you want it or not) so that may be making >things look worse than you expected? Perhaps this contributed to what I saw - but it seemed that the "thinness" lead towards invisibility. And this was my main issue with the visual effect. > >Or maybe it really does look bad on your system, I dunno... You could >post a screen grab somewhere? > I could perhaps do this; but I doubt if its worth it. (Especially as, ISTM, the capture and subsequent re-rendering on different monitor(s) would add further distortions of colour and image.) > > >> Tks. I've done that before, and may do so again. But I suspect that >> the line thickness issue is > >> a) 'cos the samples date from a lower res age, and > >I don't think fltk has changed its line defaults though. Since... ever? > To be clearer on this: what I meant was that a line of say, 1 px, on an old low-res screen might be satisfactory; but on a higher res screen - especially when viewed at a greater distance - it would be over-thin. > > >> b) thickening would be easy to achieve by slight tweaking of >> the implementation of the PPP graphics shapes classes. > >A 2-pixel line width might work better generally anyway in these examples? > Very possibly. > >> (Which begs the >> question: is/are there functions in FLTK that can determine at runtime >> the screen or window dimensions (in pixels) for width and height? If >> so, the code could self-adjust the line thickness.) > >Sure, you can use the Fl::screen_*() methods to determine the display >size, resolution, etc... Check the docs for details. > Thanks. Will do, if/when I pursue this. > >>> >>> I'd try the fltk /test folder items first, if they are OK then >>> it suggests that the PPP examples have not built right. >>> >> >> Thanks. That's now on the agenda. BTW, are all these samples expected >> to work unchanged w/ 1.1 and 1.3? > >They appear to work - oh, wait, are you asking about the PPP examples >or fltk's own examples? I meant fltk's ones, that you mentioned above. >Well, anyway, same answer in either case I guess. > ... Thanks again for your great reply. BR, Alec -- Alec Ross, A-Train http://www.a-train.co.uk +44 (0)1689 829163 +44 (0)7710 656955 (m) A Ross Computing Services (Arcs) Ltd. 30 Cathcart Drive, Orpington, KENT, BR6 8BX UK _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
