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...
>>>
>>> 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.
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!
>>>
>>> ;-( 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!
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!)
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);
>> 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.
>>> 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.
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?
Or maybe it really does look bad on your system, I dunno... You could post a
screen grab somewhere?
> 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?
> 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?
> (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.
>>
>> 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?
Well, anyway, same answer in either case I guess.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
