> Christian writes:
>> I imagine that you wouldn't want to change anything in 1.1.x and
>> 1.3.x, because you don't want to break programs that #include the .H
>> or .h files on case-sensitive systems. But for FLTK 2.x? I'd say
>> there's a strong case for just going with ".h".
Yes, in 2.x they already made that change.
Everything's like this in 2.x:
#include <fltk/run.h>
#include <fltk/Window.h>
#include <fltk/Slider.h>
#include <fltk/draw.h>
#include <fltk/CheckButton.h>
2.0 is a whole different animal.
Torsten writes:
> Even with 1.3 people should be forced
> to either use this or that way.
Maybe schedule the actual change to docs + progs for 1.4.x?
I'd just hate to see 'too much' change in 1.3.x.
I agree with Matt that 1.3.x should really get released RSN,
as soon as all the bugs against it are fixed, so we can all
have an official utf8 release, along with all the other cool
features we've all been waiting for from 1.3.x.
I believe not only all the docs, but also all the example
programs and src/*.cxx and FL/*.H files would have to change
their #include<>'s to all be 'consistent', as well as the
Makefile dependencies.. a large diff for the code base.
Not sure if this affects the windows project files.
I would at least consider the time issue and potential for
complications before making this large a change to 1.3.x
so close to a release. It really yields little net effect,
and I don't think anyone's really waiting for this change.
> Even if a source file uses the wrong way,
> it is not hard to change it. Searching for a string
> and changing it can be automated with commandline tools.
It's true it won't affect existing programs, but I am
concerned about too many changes to the code potentially
delaying a release.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
