On 24.04.2012, at 02:59, Greg Ercolano wrote:
Very VERY enlightening! I always had a bad feeling about STL in the API, =
but this surpasses my fears. The only usable STL container is =
std::string then, since it does not have a template?=
Most std::string are based on template too like :
Their GUI reporter is cute, which apparently parses gcc's error
output and gives a condensed report and lots of cute bar graphs.
Looks like r9390 gave these non-fatal warnings:
Fl_x.cxx: In function �int fl_handle(const XEvent)�:
Fl_x.cxx:1292:9: warning: variable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2799
Version: 1.3-feature
+1 for proportional instead of fixed detection, totally makes sense.
I re-open this one a request for enhancement ...
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2676
Version: 1.3-feature
A request for enhancement has been raised that we should preferably raise
an error dialog when an Xft install is broken instead of a crash.
A
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current (r9358)
Tested with r9359 on mac os x 10.6, confirmed working fine.
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current (r9358)
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current (r9350)
Fixed in Subversion repository.
Now closing as suggested.
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current (r9350)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current
Thanks Greg, I re-indexed some sections and homogenized new enum scope with
other fl_tree previous scope.
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Add an 'a la mac os x' reselect feature when user
clicks 2 times on an item, that was therefore already selected in Fl_Tree.
First, it would
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
will implement that one for 1.3 3.0 ...
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2827
Version: 1.3-feature
Fix Version: 1.3-current
Fixed in Subversion repository.
Only activable if ABI version 10302
Link: http://www.fltk.org/str.php?L2827
On 19.02.2012, at 00:35, Bill Spitzak wrote:
I like fl as well.
And many others like me like longer, less ambiguous naming :)
I do think worrying about fltk2 compatibility is a mistake. It is=20
obvious that fltk1 compatiblity is wanted instead.
I also think fltk3 should not care about
Thanks Manolo!
+1
I believe that a few changes were not propagated to FLTK 3, unfortunately.
Including mine (msvc win64 build fix 200+ warnings removal),
sorry btw;
was willing to sync it too but manolo was the fastest to apply the change back
to 3.0.
I'm not using 3.0 yet but will
I'd like to add an 'a la mac os x' reselect feature when user clicks 2 times on
an item, that was therefore already selected in Fl_Tree.
IMHO, the benefits are:
First, it would permit like in os x to implement optionally an item label edit
the 2nd time user selects it by just implementing
I just looked into the code: the widget is initialized with
default_callback() as its callback_ function; do_callback() calls
callback_ unconditionally and decides whether to call clear_changed()
or not after the callback, depending on callback_ != default_callback.
Thus, we could do
BTW, Great work has been done since I had look, great new widgets and
functionalities !
Cheers,
Fabien
Fabien: did you notice the Print front window item of the
application menu in Mac-based FLTK applications ?
It's simply amazing !
I also had a quick look to the underlying
I suspected that, but that was fast to do anyway.
More important was r7312 that fixes broken compilation on msvc6.
I reinstalled few WXP, Linux VMs on my mac and I'm currently looking for my
vs2005 disk ...
Folks, do we need to regenerate the web docs ?
BTW, Great work has been done since I
I suspected that, but that was fast to do anyway.
More important was r7312 that fixes broken compilation on msvc6.
I reinstalled few WXP, Linux VMs on my mac and I'm currently looking for my
vs2005 disk ...
Folks, do we need to regenerate the web docs ?
BTW, Great work has been done since I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
This looks truly interesting manolo,
unfortunately I have no 64bit OS X platform for testing that yet and I'm
really too busy with my business
Albrecht wrote:
./..
Another possibility would be to use standard named entities such as
iexcl; (note trailing semicolon), which exist for all the characters
you need; you can find a list at
http://www.w3.org/MarkUp/html-spec/html-spec_14.html .
Yes, another good idea, and thanks for the
Bill Spitzak wrote:
If you *EVER* think you need the number of characters in a UTF-8
string, you are doing something wrong.
This might be.. or well, maybe we do it more than we should,
as I know we might be more apt to retrofit utf8 in, instead
of checking to make sure a
Duncan Gibson wrote:
Specifically, this is for a test program to investigate STR #2158
In Fl_Text_Display, word wrapping do not work when mixing with unicode
http://www.fltk.org/str.php?L2158
FLTK has some internal functions that will return the number
of Unicode characters
Fabien Costantini wrote:
Bill Spitzak wrote:
If you *EVER* think you need the number of characters in a UTF-8
string, you are doing something wrong.
greg wrote:
..but I just can't see how that's possible in contexts like
this, where eg. wordwrap values implies working
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2148
Version: 1.3-feature
On on hand, I'm not keen on adding a new lib dependency to fltk, this could
be a problem for those who use fltk as a shared lib, because the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2175
Version: 1.4-feature
DirectFB as other graphical layers support within an adequate decoupled
architecture is planned for 1.4
Link:
but, am I right in thinking that the code above would say that
the string z is less than aa because it is shorter?
=20
If so, something doesn't make sense, or am I missing something?
It does seem this would return -1 in this case, so that z is less
than aa.
Whether that is right or
Greg Ercolano wrote:
./..
Should we document Fl_Browser_::scrollbar_width() as being deprecated,
and make a new Fl_Browser_::scrollbar_size() instead, to be consistent
with the global's existing naming?
Hmm, and if we do that, there's the added benefit where the old
Duncan Gibson wrote:
I'm as guilty of this as anybody else, but can we start renaming threads?
I'm finding it increasingly difficult to track back through the relevant
sub-threads, especially using the web interface from home. Maybe this is
less of a problem for those participants who
Fabien Costantini wrote:
That said, yes we should IMHO stop fancy modifications/improvements and
focus exclusively on bug fixes asap.
I agree in general (priority on fltk 1.3 release), but I still want
to get some ABI breaking things done before the release of 1.3.
IMHO there are four
On 25.03.2009, at 16:34, Fabien Costantini wrote:
(1) Get utf-8 support ready.
Ok, let's specifiy the _minimum_ features to realize before an RC
can be released then.
- First, the TODO.utf8 file is just a list a files (to be treated?),
should be rename TODO_FILES.utf8 if it is still
matthiasm wrote:
The current documentation is great, and Erco's improvements make it
beatiful and consistent. Now if we solve the PDF numbering issue and the
above mentioned missing utf8 API, we are fine. Fantastic work!
I'll start the PDF numbering issue ASAP, if nobody else wants to
Fabien Costantini wrote:
Greg recently used a shared document approach so that a discussion can be
hopefully land on a single durable document.
I feel we would highly need to write such a document for UTF8.
As many of us were not involved at the origin of the UTF8 intiative,
I think
Fabien Costantini wrote:
...
Also, it really shocks me to see overloaded copy() methods in derived
classes of Fl_Image, a fast inspection shows that it only calls the
copy(w(),h()) virtual method.
So we should also _remove_ all overloaded copy() methods because they
duplicate
Fabien Costantini wrote:
...
Also, it really shocks me to see overloaded copy() methods in derived
classes of Fl_Image, a fast inspection shows that it only calls the
copy(w(),h()) virtual method.
So we should also _remove_ all overloaded copy() methods because they
duplicate
In fact, it will also work because any message sent to an object is resolved
into a call deducted dyna,ically from its virtual method table (VMT) which
contains a ref to itself and the correct pointers to methods (this in c++,
self in java).
erratum: self is for ObjectiveC, in java it is
Albrecht Schlosser wrote:
...
What happens? Note that img points to an Fl_Shared_Image object.
The compiler can't detect this, can it? Will the Fl_Shared_Image
be destroyed?
Yes, it will, since the destructor of a class is always virtual.
Always virtual ?
Isn't it only if base class
Albrecht Schlosser wrote:
./..
Currently the Fl_Shared_Image would be removed from the image
list only if release() would be called, but we'd have a problem
anyway, since there might be other pointers to the shared image.
Yup, and we'll just have to educate users about this - don't use
Michael Sweet wrote:
Albrecht Schlosser wrote:
...
What happens? Note that img points to an Fl_Shared_Image object.
The compiler can't detect this, can it? Will the Fl_Shared_Image
be destroyed?
Yes, it will, since the destructor of a class is always virtual.
Will
Fabien Costantini wrote:
./..
This is exactly why mike suggested to implement release() in the Fl_Image
class I think.
He wrote refcounting, but I don't want to be nitpicking, maybe
that's what he meant.
This way, we could avoid completely the need of deleting images.
No, objects
Fabien Costantini wrote:
Dear Developers,
many files are going to be updated today according to the new doxygen
parameter tag standard agreed recently (\a becomes \p).
Please report if you have any branch to merge soon before this update,
if no heavy merge is pending, I'll update
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2180
Version: 1.3-feature
Because pkg-config is not available/compatible in all platforms it makes it
difficult to handle it in multiplatform development.
So I having we
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2179
Version: 1.3-feature
It indeed makes sense to me than for every platform, one should be able to
intercept any event _before_ fltk does.
I thought that
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2180
Version: 1.3-feature
Why not?
Please read my previous answer.
it is simle to add.
And apparently a hell to maintain if we want FLTK to be still used
correctly on
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2180
Version: 1.3-feature
Sure, and just before this line I (also) added :
dnl FIXME This part should be fixed so configure do not depend on dnl
we do not rely
Fabien Costantini wrote:
I'd suggest to always favorize the content than the form though I also
understand that a proper form will make more easy the documentation reading.
Yes, I know what you mean.
Though to a new user, a lot of things are important, such as getting
Fabien Costantini wrote:
Albrecht Schlosser wrote:
...
What happens? Note that img points to an Fl_Shared_Image object.
The compiler can't detect this, can it? Will the Fl_Shared_Image
be destroyed?
Yes, it will, since the destructor of a class is always virtual.
Always virtual
Duncan wrote:
./..
I know for 1.3.x to go out, we mainly want to get the code stable,
so I figure that's what you guys are all on top of.
One STR burger at a time, but there are some T-bone steaks
involving UTF-8 and Mac/Windows that are too big for me :-(
Cheers
D
There's no problem
Dear Developers,
many files are going to be updated today according to the new doxygen parameter
tag standard agreed recently (\a becomes \p).
Please report if you have any branch to merge soon before this update,
if no heavy merge is pending, I'll update the branch this evening (MDT).
Fabien
Short form:
Fl_Shared_Image::copy() should return the proper
type (Fl_Shared_Image* instead of Fl_Image*), and
Fl_Shared_Image::refcount() should be private or
protected.
IMHO No, It should _NOT_ return anything else than an Fl_Image.
This is also the base of polymorphic behavior, this
Short form:
Fl_Shared_Image::copy() should return the proper
type (Fl_Shared_Image* instead of Fl_Image*), and
Fl_Shared_Image::refcount() should be private or
protected.
Long form:
Problem #1:
There are two copy methods:
virtual Fl_Image *copy(int W, int H);
Fl_Image *copy()
Moved the stripping of date comments (strip_tags) to its own target
html-dist, just like it has been done for pdf-dist.
Good, thanks.
This new stripping procedure I created is saving lot of (useless) diffs,
but it was just a (working) first attempt of the kind,
so feel to improve it as much as you
PDF doc 2 garbage pages before frontpage added since r6704.
Revrted the modifications until r6703 where no garbage pages were present
before the frontpage of the pdf.
it seems that the navigation reworked makes doxygen bug ...
For those who do not have a working pdf gen env., here's the bad pdf
Greg Ercolano wrote:
I noticed there's a mix of using \a vs \p for parameters.
./..
Thanks for that info. I didn't know \p until I saw what you did. I
always used \a, but I don't remember that we discussed this before
(I may have missed or forgotten that though).
I remember that I was using
I would simply make the names match between the prototype and the impl.,
so 1)
Fabien
Trying to fix up those discrepancies in Fl_Browser's docs
where we have discrepancies like this in the method index:
no variable names in the prototype
Well, testing WIN32 is too permissive because it would include also mingw as an
example.
On the other hand, _MSC_VER would only exclude msvc compilers which is better
think, but may include borland and watcom compilers.
I don't think borland compilers support the warning pragma as an example.
Fabien Costantini wrote:
Well, testing WIN32 is too permissive because it would include also mingw
as an example.
On the other hand, _MSC_VER would only exclude msvc compilers which is
better think, but may include borland and watcom compilers.
I don't think borland compilers support
.
Also, it is always preferable to filter more platforms thus preventing the
warning but still compiling, than filtering not enough platforms and
potentially break compile on some platform.
Fabien
Fabien Costantini wrote:
Well, testing WIN32 is too permissive because it would include also mingw
a) should be fine and is probably the only choice that will never have to be
changed again, even if it may filter too much for non gnu compilers that would
have a warning directive now or in future, it should at least always compile.
Fabien
Vote?
a) #if defined(__GNUC__)
b) #if
Figure this got lost in the flurry of posts..
The source code in the utf8 dir is all nutty with
very wide indenting.
Needs to be brought around to 2 space indents
and KR style bracing.
Thought I'd bring the files into compliance..
have most of them
Albrecht Schlosser wrote:
Personally I don't have problems with comments in the sources. Sometimes
I'd like much more comments in the code (not only doxygen, but also
some hints what the code is good for).
Yes, I agree.
Though I sure do like being able to turn off the end
Well, I did update the html and pdf version on the website recently,
that said ; I did not update the pdf file on the source repos,
because some complained about the size of the pdf when they update their svn
local copy, as Al already mentioned.
Concerning the documentation 'with comments' link,
Well, I did update the html and pdf version on the website recently,
that said ; I did not update the pdf file on the source repos,
because some complained about the size of the pdf when they update
their svn local copy, as Al already mentioned.
I've just checked, and now have links
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
Fix Version: 1.3-current (r6648)
Fixed in Subversion repository.
Tested successfully on Mac OS X 10.5.5, Linux ubuntu 8.10 and Windows XP
SP3.
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2118
Version: 1.4-feature
Link: http://www.fltk.org/str.php?L2118
Version: 1.4-feature
___
fltk-dev mailing list
Thanks, this should be fixed now in r6643.
Fabien
Seems the test/help program segfaults under linux (fedora3)
with the current clean checkout of 1.3.x (r6642) and default build.
(Works fine on the mac, though)
Also, the test/help program no longer shows an example
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
I talked about a similar functionality recently, i.e: the ability to embark
url's in dialog boxes which could reuse the fl_open_uri() function
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
mmm, I'm experimenting strange side effects with the patch:
the current impl. blocks while it does not return from callee and handle
errors on
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2127
Version: 1.3-feature
Under Mac OS X 10.5.5, it is even worse than I thought, in fact even a
valid remote web page link would prevent the caller fltk app to handle
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2121
Version: 1.3-feature
Fix Version: 1.3-current (r6636)
Fixed in Subversion repository.
Fixed a potential memory leak on flavorType.
Made all local stack variables declaration zero initialized when
necessary, those not zero
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L569
Version: 1.3-feature
Fix Version: 1.3-feature
We are unable to resolve this problem with the information provided. If you
discover new information, please file a new STR referencing this one.
The faq referred to is obsolete
Great initiative, the roadmap issue is no big deal,
Thanks,
Fabien.
Dear Users,
you may have noticed that FLTK 1.4 popped up on the roadmap. No
worries please, I am not jumping ahead. I am merely trying to get a
1.3.0 roadmap down to a manageable size.
Once we have a 1.3.0 with full utf8
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1923
Version: 1.3-feature
I totally agree, still, it would be quite some work for 1.3 IMHO.
Maybe we could first implement a toolbox window for 1.3, which seems to be
the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2040
Version: 1.3-feature
Overriding the handle() method and treating the FL_WHEN_RELEASE event isn't
enough?
Why the need of overriding another method here ?
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2040
Version: 1.3-feature
FLTK, like many other toolkits and GUI's , is an event driven interface.
In the GUI SoA, events are dispatched and treated by what we called
I was not sure that STR bug fix should appear or not in the CHANGES,
anyway I added this one in CHANGES to both branches; as it won't hurt.
Fabien
IMHO this should also be worth a note in CHANGES for
1.1 and 1.3. Just for the
record, if someone complains...
Thanks in advance for adding this.
I would like to do the update before this week's (Friday morning) snapshot. I
think that waiting longer (if that's what you wanted to say ?) doesn't help
much.
After all it's a low risk operation (local to the png dir.), and we can always
revert it. Any reasonable objections? (If I don't
It seems to bring more good than bad and you took the time to test,
so I would suggest to do this update asap, after the conventional 2 weeks
period because, if we happen to find eventually a problem, the sooner the
better, and if possible before an RC will appear (I know it's not for tomorrow
Interesting.. if I gather the gist of the patch correctly,
it looks like the change is to avoid having the void function
return() a function that returns a void.
=20
Which seems to compile OK with 'g++ -Wall' on my linux
systems, eg. no compile errors for this:
=20
I'm sort of wondering which compiler variants do/don't=20
allow that style
of usage...
=20
Me too. Which compiler did _not_ like it?
This one complained:
$ gcc -v
Reading specs from d:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
VC6 is not happy too, and has another problem compiling
Ian wrote:
And very nice it is too - but is it intended that my two favourite
chapters (Appendix A and Appendix B) are missing?
I confess I'm not all that clear on how the whole doxygen/pdf/etc
mechanism works or what I would realistically expect to have included in
the PDF output.
Thanks for
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1937
Version: Web Site
Shouldn't it be of an RFE level ?
That, I love purple :-)
Link: http://www.fltk.org/str.php?L1937
Version: Web Site
Ian wrote:
Is it intended that the fltk.pdf file be included in the svn repo?
At least, this is what is done for doc-1.0 and doc-1.1 www svn repository,
so I did exactly the same.
I wondered, only because it is quite large and that might be a
problem for some users on slow links?
The current
Gents,
Is it intended that the fltk.pdf file be included in the svn repo?
I wondered, only because it is quite large and that might be a
problem for some users on slow links?
No, the PDF should not be part of the svn because it is auto-generated
and can also be downloaded
Not sure if a temporary pdf is interesting to someone who could not
generate an improved one?
Anyway, fine with me either way.
Ahem, I don't understand what you mean by _temporary_ pdf ?
This is the look-at-me-im-beautiful-i-shine-latest-generation-doc-the-one.pdf
file that we put in the
Dear developers,
We have now an up-to-date fltk 1.3 pdf file manual on the website in the
documentation section, with other fltk versions reference manuals.
I did not update the html files yet because I'm not sure of how to do it
properly:
- So should we put all the html doxygen files (rather
Hey folks,we discussed about this and integrated it quite some time ago :-)
Did you noticed only today that the fltk.pdf file was in the distrib 1.3 ?
FYI, I only added the pdf to the website today.
I thought my svn update was freezing up, and was about to hit
^C when I realized it
OK Al,
Doxybook change broke my toolchain,
except from that ; your makefile change is good so thanks.
I generated again a fltk.pdf file in r656,
hope it will work for you,
please check that one as I had to rebuild a new mac config as my previous intel
imac is dead.
(The true (and funny) story is
imacarthur wrote:
...
I guess we should try and gather opinions about a min version. I'm happy
to drop Win9x, but am less sure about dropping NT4 at this stage. Anyone?
+1 for dropping Win9x/WinMe/WinNT.
I'd happily second that, so +1 too for this 3 oldies.
What is the normal use of a FL_NORMAL_BUTTON from a user's view?
./..
Typing the shortcut is like clicking the button (pressing
_and_ releasing the mouse button). The keyup events should be ignored
(as they are for almost all other widgets in FLTK).
Agree in the' case of a normal button with a
On 5 Dec 2008, at 23:09, Fabien Costantini wrote:
possibly manifest the same bug, e.g. my recent fl_text_extents()
mod ?
To reply this specific question ; I would say YES it can happen in
./..
OK.
Best way forward, for the short term? Do I just duplicate your
defensive code to try
Fabien Costantini wrote:
What is the normal use of a FL_NORMAL_BUTTON from a user's view?
But here's where my opinion still _really_ differs from yours:
IMHO, it is really important to handle both events (key push and released)
exactly as for the mouse when user specify to use
Al wrote:
That's what I wrote about before. You need specialized state variables
to track all changes. This is beyond the scope of a toolkit like FLTK.
Many examples (see my previous posts) will not need any state variables
Regarding FL_WHEN_CHANGED. I was attempting to mimic the way the mouse
This really tricky bug should be fixed now.
Please check if it works for you !
Thanks Fabien, that seems to have got it.
I wonder if there might be related issues elsewhere that could
possibly manifest the same bug, e.g. my recent fl_text_extents() mod,
etc.?
What do you think - is it
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1927
Version: 1.3-feature
Fix Version: 1.3-feature
Link: http://www.fltk.org/str.php?L1927
Version: 1.3-feature
Fix Version: 1.3-feature
FWIW, I had a quick look and it compiled ok on vc2005, too.
Fabien
One question; did the previous version compile OK for you?
I'm sort of wondering which compiler variants do/don't allow that style
of usage...
Cheers,
--=20
Ian
___
fltk-dev
Also, can someone tell me... For a fast and light toolkit, is there
a performance impact with the overloading and virtual functions?
Yes,there is a performance impact as virtual methods adress ptr need to be
resolved dynamically using Virtual Method Tables (hope this spells like this in
MacArthur, Ian (SELEX GALILEO, UK) wrote:
(Note: is jpeg.h what we should look for? Lib jpeg-6b seems to use
jpeglib.h?)
yes it should, corrected in svn
ac_cv_lib_jpeg_jpeg_CreateCompress=no # fc: is it still necessary ?
No, it is not. Should be removed.
Ok, Commented out.
So,
r6519 is now generalizing latest png configure.in code to jpeg and z libs.
Also, it now warns the user if he asked for a system (jpeg,z,png) lib that was
not available.
Very unfortunately, it still doesn't make coffee.
Please, review the changes.
Fabien
Ok here's a temporary fix in r6509 that solves the last problem while keeping
the new Ian flag settings.
The png header test is not activated yet because it did not work under cygwin
(?) but this version should work better than before as we should have now the
rgb32 square pb solved as new
I do not have cygwin, but do have mingw. I seem to be getting the same
result as you report (that is, the auto mode is not selecting the
correct lib.)
Further, in another test, although it is *finding* the system PNG lib,
it is not setting up the config.h to actually use that either.
This
Close, but...
On mingw, trying to use the system png lib, I configure with:
../configure --enable-threads --enable-cairo
CPPFLAGS=3D-I/usr/local/include LDFLAGS=3D-L/usr/local/lib
BUT, config.h is not correct, it has:
/* #undef HAVE_PNG_H */
/* #undef HAVE_LIBPNG_PNG_H */
I think
1 - 100 of 218 matches
Mail list logo
