Fabien: one question about implementing this.
I take it you want the color() to be the default for
newly created items.
Correct, this is the way fluid expect the background color to be set for most
widgets, color2() being generically for the selection color use.
But
What I'm not sure about is what should happen if the app
then changes color(); should new items use the color(),
or should they stick to using the item_labelbgcolor()?
The answer to the question in the example would be cyan because color() and
item_labelbgcolor() would affect
On 05/08/12 19:47, Fabien Costantini wrote:
Now, at initialization the item label color is an 'undefined' value
(let say 0x ?). Note that value would be stored in the prefs
as well if user did not specify a custom color.
Ah, OK, I was going to use a bitflag to keep track
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2828
Version: 1.3-current
Hi Greg godd job for the recent enhancements you made on Fl_Tree,
something really mice to do to do would be to sync the item default bkgnd
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2797
Version: 1.3-current
Agreed that we should return NULL and document it;
as thinking about the consequences of being permisse as windows is, I
would say that if I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9368)
Thanks Chris, yes I am aware of that but as you probably already noticed
the probability for that to happen
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2802
Version: 1.3-current
, as we now have a test for excluding tooltip and menu windows in
canBecomeKeyWindow() ; it might explain why this does not seem to make any
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9368)
Potential false positives problem fixed in r9390.
Link: http://www.fltk.org/str.php?L2771
Version:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9403)
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9403)
___
fltk-bugs mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2828
Version: 1.3-current
for Point D) more prcisely we still can select multiple items but with
click and keyboard combination.
It is only the drag operations that are
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2783
Version: 1.3-current
Fix Version: 1.3-current (r9366)
Fixed in Subversion repository.
Made sure internal cleanup still happens as suggested.
Updated documentation mod adequately.
Link: http://www.fltk.org/str.php?L2783
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2796
Version: 1.3-current
Could you elaborate how to reproduce that bug with the demo tree app ?
Link: http://www.fltk.org/str.php?L2796
Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9368)
Fixed in Subversion repository.
Introduced a new fl_ascii_strcasecmp that does not rely on locale
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Fix Version: 1.3-current (r9368)
Added the use of the new fl_ascii_strcasecmp() in shceme(const char* ) as
well in r9369.
Ian, tell me what
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2802
Version: 1.3-current
If I add the following on OS X:
- (BOOL)canBecomeKeyWindow
{
if (Fl::modal_ (Fl::modal_ != w))
return NO; // prevent the caption to be
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current
So can we close that STR or is there any more work on that one ?
Link: http://www.fltk.org/str.php?L2819
Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2761
Version: 1.3-current
If possible, that would be great _not_ have a new option for a bug fix.
Is there any downside of of fixing that problem in terms of backward
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2803
Version: 1.3-current
Fix Version: 1.3-current (r9374)
Fixed in Subversion repository.
Tested on my ubuntu amd64 vm with gcc 4.6.1, as well as regression tested
on mac os x 10.6 and windows 7 64
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2709
Version: 1.3.0
Fix Version: 1.3.1 (r9211)
Tested r9375 today in my Win7/64 VM and with vs2010 - works fine.
Maybe we can close that STR now ?
Link:
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2799
Version: 1.3.0
Agreed as not a bug, work as designed: On OS X , if I click and drag even a
little (even one pixel): it will close the main menu just like fltk does.
BTW I like very much that feature as it is.
Now closing, as
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
___
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
Fix Version: 1.3-current (r9362)
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
Fix Version: 1.3-current (r9362)
___
fltk-bugs mailing list
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
Fix Version: 1.3-current (r9362)
Link: http://www.fltk.org/str.php?L2731
Version: 1.3-current
Fix Version: 1.3-current (r9362)
___
fltk-bugs mailing list
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2726
Version: 1.3-current
Fix Version: 1.3-current (r9363)
Fixed in Subversion repository.
Used int instead of unsigned char as specified in isspace documentation.
Link: http://www.fltk.org/str.php?L2726
Version: 1.3-current
Fix
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2799
Version: 1.3.0
I would say no as fltk is supposed to work the same way all platforms in
that regard.
Now one could advocate it should work the same way on all platform with a
tolerance, which I would not really like but would
The indirection lookup in the selection data structure could actually
eat a lot of cpu if you use a non suitable abstract data type..
Right, but no matter how you optimize 'the lookup' (hash, bsp, etc),
it's still a lookup, vs. a simple if (selected) test on a bit flag.
Simple -
Sounds like Fabien is willing to do the footwork
to port it to FLTK:
Yes, I would but ...
I imagine it should be put to vote among the devs
to add it to the main branch, as it's a significant
bit of code.
.. then indeed it would should be discussed what exactly
If it's just the tree widget that's needed, I guess I have
to ask, before we embark on having two tree widgets in the
FLTK api.. perhaps I'm missing something obvious, but:
What exactly are the benefits of Flu's tree
over Fl_Tree?
From the top of
Of course read below : *NOT* to be ashamed of in any ways.
Yet, I am open to keep only one tree class if more conservative opinions are
emitted,as Fl_Tree is definitly a class to be ashamed of in any ways.
We could improve it continually instead ...
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2826
Version: Current
When opening fluid via the arguments parameters with a file path, and when
a previous (same) file was opened, it tries per default to reload the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2826
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2826
Version: 1.3-current
___
fltk-bugs mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2795
Version: 1.3-current
Fix Version: 1.4-feature (r9232)
Also, when looking for selected nodes and checking if node is already
selected it seems, that we traverse
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2826
Version: 1.3-current
Fixed in Subversion repository.
Tested with most recent (9346) version and it's working now.
Link: http://www.fltk.org/str.php?L2826
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2826
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2826
Version: 1.3-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
___
fltk-bugs mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2771
Version: 1.3-current
An interesting work around might be to compare only the consonants after we
transformed the scheme in uppercase ...
i.e. we would only compare
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2787
Version: 1.3-current
There is no 'restrict' keyword anymore in the latest png.h file.
Does it build now ?
If yes maybe we can close that one ?
Link:
FYI,
I just ported the full FLU 2.14 set of widgets from Jason to fltk 1.3 after
reading that thread ...
IMO, The FLU Tree browser is still *amazing* today compared to what we've ever
had in FLTK (1.x + 2.x)
I would be volunteer to integrate a Fl_Tree2 to 1.3 3.0 from the Jason's
version
Sorry for the html garbage; I didn't know that we still had this reply problem
when posting html reply from an email client,
So I just ported the full FLU 2.14 set of widgets from Jason to fltk 1.3 after
reading that thread ...
IMO, The FLU Tree browser is still *amazing* today compared to
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
Further discussion on fltk.org if necessary, as suggested by Albrecht.
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
___
fltk-bugs mailing list
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2332
Version: 1.3-current
Fix Version: 1.3-current (r7317)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2332
Version: 1.3-current
Fix Version: 1.3-current (r7317)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2332
Version: 1.3-current
Fix Version: 1.3-current
I fixed the visualC, vs 2005/2008 compilation errors.
I added missing projects in vs2005/2008 ide projects
Please
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2004
Version: 1.3-current
Fix Version: 1.3-current (r6744)
I think I made it crash after the original patch, so I excluded it from osx
as the fix did not seem to
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L890
Version: 1.3.0
Fix Version: 1.3-current
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L890
Version: 1.3.0
Fix Version: 1.3-current
___
fltk-bugs mailing list
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2120
Version: 1.3-current
Fix Version: Will Not Fix
You'll find many articles in the forum section, and cheat pages from fltk
users to help in setting up a proper mingw / fltk configuration.
Fabien
Link:
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2125
Version: 1.3-current
Fix Version: Will Not Fix
We are unable to resolve this problem with the information provided. If you
discover new information, please file a new STR referencing this one.
As demonstrated, the exit()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2122
Version: 1.3-current
I believe this happen to all fonts, just comment in your code the font spec
(to get the default one) and set the size of this font to 9 .
Then
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2123
Version: 1.3-feature
Fix Version: Will Not Fix
We are unable to resolve this problem with the information provided. If you
discover new information, please file a new STR referencing this one.
Closed as asked by the OP.
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2104
Version: 1.3-current
Fix Version: 1.3-current (r6624)
Fixed in Subversion repository.
Applied patch from sadysta, modified it to harmonize with existing win32
code, like global alloc code, wchar_t type use. Added a wchar.h
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2121
Version: 1.3-current
i dont understand that one:
I tested with latest 6624 release, copying japanese text from the
STRâ2080 greg example, then pasting it to a
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2121
Version: 1.3-current
Fix Version: 1.3-current (r6625)
Fixed in Subversion repository.
Thanks manolo,
should work fine now.
Link: http://www.fltk.org/str.php?L2121
Version: 1.3-current
Fix Version: 1.3-current (r6625)
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2068
Version: 1.3-current
Fix Version: 1.3-current (r6624)
Should be solved now since r6624, please feel free to open a new str if it
is not the case.
Link: http://www.fltk.org/str.php?L2068
Version: 1.3-current
Fix Version:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L400
Version: 1.3-current
Fix Version: 1.3-current
Fixed in Subversion repository.
Checked that it is not the case anymore in 1.3, with do have uuid and
ole32 libs in LDLIBS, GLDLIBS.
Link: http://www.fltk.org/str.php?L400
Version:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L50
Version: 1.3-feature
Fix Version: 1.3-current (r6621)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L50
Version: 1.3-feature
Fix Version: 1.3-current (r6621)
___
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2036
Version: 1.3-current
Fix Version: 1.3-current (r6626)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2036
Version: 1.3-current
Fix Version: 1.3-current (r6626)
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2103
Version: 1.3-current
Fix Version: 1.3-current
Fixed in Subversion repository.
Site updated with latest FLTK 1.3 documentation content.
Link: http://www.fltk.org/str.php?L2103
Version: 1.3-current
Fix Version: 1.3-current
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L1105
Version: 1.3.0
Fix Version: Will Not Fix
Semantics of enter prevent generating an enter message, if you are already
in ...
Special 3rd party code (i.e: that keeps track of the mouse movements)
should address such custom
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2104
Version: 1.3-current
I'm not opposed to a temporary fix if it is commented as so in the code and
if it explains its limits.
But still, I would really appreciate
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2106
Version: 1.3-current
In previous read toggle type instead of radio type, buty this problem also
happens with radio buttons (callback called with mouse click but not
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2106
Version: 1.3-current
After more inspection, this happens when only FL_WHEN_RELEASE was set (by
default) for radio or toggle buttons.
But the documentation clearly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2006
Version: 1.3-current
Um, this looks odd:
First the real modification is the bounding test which is sadly not
commented as a change, I guess that's why diff file are
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L2006
Version: 1.3-current
Fix Version: 1.3-current
Obsolete, a different fix was achieved in STR#2021.
Link: http://www.fltk.org/str.php?L2006
Version: 1.3-current
Fix Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2094
Version: 1.3-current
This is just a reminder for who will have some time to finish 2026 (which
btw hides quite some anomalies more serious than the bug report on the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1938
Version: Web Site
It's true that recently some people raised the problem that fltk newbies
can use 1.3, thinking it's the most recent stable version instead of
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2093
Version: 1.3-current
Fix Version: 1.3-current (r6532)
Fixed in Subversion repository.
Just confirming this have been fixed by Ian in 6532.
Please feel free to open new str for other related problem if any.
(Please team, check
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2103
Version: 1.3-current
Fix Version: 1.3-current
Should update asap the fltk1.3 documentation pdf and html files.
For html files, it may destroy related revision 8
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
Thanks Al,
I'll check your updated diff file which indeed seems to correct the
indentation problem.
Now for the pertinence of this STR,
I
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-currentIndex: Fl_Button.cxx
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
This looks very interesting, thanks.
I updated the radio test program tio be a more complete test case.
I updated your patch to current version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2026
Version: 1.3-current
No problem Al, I did a diff -Bbw for ignoring whitespaces to just to check
before I started to investigate, jp added one else if test block and
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1942
Version: 1.3-current
We have a placeholder in the new doxygen documentation, accessible from the
index called Migrating Code from FLTK 1.1 to 1.3 .
We may improve
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2089
Version: 1.1.3
did check the configure messages in the pthread section ?
What does it say, any warning ?
Link: http://www.fltk.org/str.php?L2089
Version: 1.1.3
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1949
Version: 1.3-current
I believe this one could close w/resolution now, Ian ?
Link: http://www.fltk.org/str.php?L1949
Version: 1.3-current
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2080
Version: 1.3-current
Fix Version: 1.3-current
Fixed in Subversion repository.
Ok thanks Ian,
this is making me a bit nervous and worried though, to see how the way we
seem to treat labels and especially their expansion differs
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2085
Version: 1.3-feature
Ok, Jean Marc sent to Mike and I a confirmation that there is no problem to
change the headers, he also points out we should check some others
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2085
Version: 1.3-feature
Who's Jean Marc ?
How to contact him and what exactly did we use from it's utf8 stuff please
?
Link: http://www.fltk.org/str.php?L2085
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2085
Version: 1.3-feature
Ok, I sent a message to Jean Marc, for once that it is useful to speak
french ; I took this in charge :-)
Link:
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L1414
Version: 1.3-current
Fix Version: None
This STR has not been updated by the submitter for two or more weeks and
has been closed as required by the FLTK Configuration Management Plan. If
the issue still requires resolution,
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2071
Version: 1.3-current
Thanks for the feedback Alvin,
most compilation aspects have been fixed in r6485.
However, there is still one problem I didn't fix yet:
in
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2058
Version: 1.3-current
Fix Version: 1.3-current (r6388)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2058
Version: 1.3-current
Fix Version: 1.3-current (r6388)
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2052
Version: 1.3-current
Fix Version: 1.3-current (r6386)
Fixed in Subversion repository.
Also added related doxygen documentation and application note.
Link: http://www.fltk.org/str.php?L2052
Version: 1.3-current
Fix Version:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2005
Version: 1.3-current
Fix Version: 1.3-current (r6387)
Fixed in Subversion repository.
I added a check before the free() call because if one day the 'temporary
fix' is removed, we won't crash here.
But it will make no difference
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2056
Version: 1.3-current
I fixed the problem you mentionned, but still lot of UTF8 code won't
compile.
In particular, the wide char API (like wcsdup, wcslen, ...) won't
Fabien, you did a very good job, too. With your work and my entry pages,
it's impressing, what doxygen can achieve. You can now navigate through
the widget tree from Fl_Window down to Fl_Widget :-)
Thanks Albrecht, there's now WP2 do in the svn !
Let's keep on the good work !
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
OK, we can start now, there is 11 WP to work on for the classes doc. and 2
WP for other docs.
It has been decided that:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
Well, thanks but it is unlikely that we get this doc. next week as you can
guess :-) , and this timeline will highly depend on the numbers of
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
The existing Doxyfile script (at the root of the distrib) is the starting
point.
The first increment consists of extracting the current hmtl doc
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
It will not start before we get some ack and strategy confirmation from
Matt, after his utf8 merge anyway. I thought it would be nice already if
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2031
Version: 1.3-current
Fix Version: 1.3-current (r6188)
fixed in current repository as discussed and successfully regression
tested.
Link: http://www.fltk.org/str.php?L2031
Version: 1.3-current
Fix Version: 1.3-current (r6188)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2005
Version: 1.3-current
no doubt that the pointer should be checked here,
but what intringues me is : do we address correctly the problem only with
this, why and when a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2029
Version: 1.3-current
Thanks Albrecht, here's my comment:
On point 1)
Agreed that the wsock should not affect the 3rd party application socket
behavior so
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2030
Version: 1.3-current
Fix Version: 1.3-current
This is a reminder of a discussion I had recently with matt.
What is unambiguously admitted is the need to move
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L1906
Version: 1.3-current
Fix Version: 1.3-current (r6165)
Link: http://www.fltk.org/str.php?L1906
Version: 1.3-current
Fix Version: 1.3-current (r6165)
___
fltk-bugs mailing list
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L96
Version: 1.3-current
Verified with the provided example, compiled with -W on gcc 3.4.4 and
gcc4.0.1 : produces no Warnings.
Closing this STR.
Link: http://www.fltk.org/str.php?L96
Version: 1.3-current
[STR Closed w/o Resolution]
Link: http://www.fltk.org/str.php?L1811
Version: 1.2-current
Fix Version: 1.3.0
Does not apply to 1.3 branch
Link: http://www.fltk.org/str.php?L1811
Version: 1.2-current
Fix Version: 1.3.0
___
fltk-bugs mailing list
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1414
Version: 1.3-current
Any report with current 1.3 svn branch on aix ?
should work here.
Does not close yet for duplicate of #1155 because this STR deals with the
AIX
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2030
Version: 1.3-current
Fix Version: 1.3-current
Considering to the poll results, even 2 or 3 percent of use means more
than one hundred people still uses
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2030
Version: 1.3-current
Fix Version: 1.3-current
I had a quick to the watcom build files, noticed it proposed several target
platforms.
I used latest 1.7a openwatcom
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1942
Version: 1.3-current
Adding a CHANGES.API file or whatever to maintain the API changes would be
also error prone because we could easily forget to update it, while
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1894
Version: 1.3-current
Wouldn't it be better to solve such problems to add in the the Widget
destructor a parent remove() call so that the widget smoothly detach from
1 - 100 of 125 matches
Mail list logo
