Evan Laforge wrote:
I thought I made a STR for these things, but I don't see it anymore.
Should I add one? Or one STR for each issue?
Just regarding this: I went to http://fltk.org/str.php and searched
for elaforge and found only these items:
Id PriorityStatus
Evan Laforge wrote:
Hm, maybe I didn't add a STR back then after all. Ok, I'm going to
add STRs for slowness, incorrect wrapping, and text wobble, along
with an example program that demonstrates it. I'll add them for 1.3,
since they are after all serious bugs, but if consensus is push them
Moving the request in STR#2521 to modify the fltk*dll projects to
build the .dll file directly into the fltk/lib directory..
OK, so as mentioned in the STR, I tried changing the Output filename
for one of the dll libs:
FROM: Debug/fltk_formsdll/fltk_formsdlld.dll
TO:
I keep bumping my head into '@' symbol parsing in unexpected places.
Is there a global way to disable symbols, like a flag?
If not I'd like to propose an Fl::option() for this, eg.
FL_OPTION_DISABLE_AT_SYMBOLS, which would override the value
of the draw_symbols flags on the text drawing functions
Matthias Melcher wrote:
I would not make it an option, because the idea of options is,
that they can be overridden by the end user.
Ah, the Fl_Preferences tie-in, I see.
You can use this:
void no_symbol_label(const Fl_Label* o, int X, int Y, int W, int H, Fl_Align
align)
{
Ian MacArthur wrote:
- Should we have an example that shows things you can do with Fl::args()
etc.? There have been a few questions about that recently, so it might
come in handy, since the docs are a bit opaque.
Oops! That would be howto-parse-args.cxx then, I guess...
Yep! Duncan
Greg Ercolano wrote:
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Be nice if the Makefile showed use of fltk-config, rather than pulling
in the makeinclude to get things done. [..]
Yes, I agree, that'd be a good thing.
Done -- see r8324, lemme know what you think.
Partially based
I just noticed some API collisions in Fl_Tree vs. Fl_Widget
so I need to change some method names which breaks some of
Fl_Tree's API to date.
Since 1.3.0 hasn't released yet, it should be OK to break this
(even though it's kinda late in the pre-release process).
BTW, when do we start freezing
One question: You've got a $(EXEEXT) for handling the executable
extension on WinXX hosts, but I can't see how you set it.
Yes, it's a place holder until either I, or someone with a
mingw/msys environment can add the needed code to get it to build.
I suppose all that's needed might
MacArthur, Ian (SELEX GALILEO, UK) wrote:
One question: You've got a $(EXEEXT) for handling the executable
extension on WinXX hosts, but I can't see how you set it.
Yes, it's a place holder until either I, or someone with a
mingw/msys environment can add the needed code to get it to
The Fl_Native_File_Chooser class has 4 #include files; the first includes the
other
three depending on the platform being compiled, and is the one that users
should include.
However, because the docs need to be where the methods are implemented, the
doxygen docs
are actually in one of the
Greg Ercolano wrote:
Is there a way to override doxygen's automatic generation of the file to
#include?
Perhaps the solution is to put some of the docs in the correct file, and the
rest in
the others..?
Solved by r8377.
Moved the doxygen /** file header and intro comments
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2560
Version: 1.3-feature
Fix Version: 1.3.0 (r8413)
As long as all fonts on all platforms support it (Helvetica, Courier, etc),
it sounds OK. Has anyone checked this?
Link: http://www.fltk.org/str.php?L2560
Version: 1.3-feature
Alessio Bolognesi wrote:
Hello!
I'm new with FLTK and I have two questions:
1 - Is there any way to fill complex polygons with image patterns? (or, as an
alternative, is there any way to define non rectangular clipping?)
You can use OpenGL to do a lot of that I think..
2 - How can
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2584
Version: 1.3-feature
Would be nice if tooltips by default would automatically disappear after
some period of time (10 secs or so, perhaps reconfigurable).
FLTK apps
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2584
Version: 1.3-feature
Ha, true! (Luckily I said FLTK seems unique.. ;)
Situations where the tooltips go away:
Entire KDE Desktop: Konqueror, Konsole, kdict..
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2586
Version: 1.3-feature
Fluid seems to have a lot of separate settings dialogs now that should
probably be consolidated into a single dialog with tabs, so new users
I still keep seeing new folks jumping on fltk2..
is it perhaps not clear enough on the website that it's still in dev,
not even in alpha, and should only be used by.. other devs?
___
fltk-dev mailing list
fltk-dev@easysw.com
Evan Laforge wrote:
Any other input out there?
I wanna see your handle() code.
If you're overriding handle(), you have to be sure to
(a) call the base class's handle(), and
(b) return correct 0 or 1 values from handle(),
or events won't be delivered
Greg Ercolano wrote:
Evan Laforge wrote:
Any other input out there?
I wanna see your handle() code.
Actually, looks like there might be something up with
OSX + svn current with regards to FL_FOCUS.
I suggest keeping an eye on this bug:
http://www.fltk.org/str.php?L2594
Evan Laforge wrote:
I suggest keeping an eye on this bug:
http://www.fltk.org/str.php?L2594
Indeed.
If we can agree that Fl::focus(window) should set focus to the window,
then I can attach a simple patch to fix that.
I figure you should work with manolo on this one; he's
If we can agree that Fl::focus(window) should set focus to the window,
then I can attach a simple patch to fix that.
I figure you should work with manolo on this one; he's been
handling the Cocoa port, so he'll want to weigh in on patches.
FL::focus() is in Fl.cxx, so it's
Each time I hit Alt-G in fluid (Shell-Execute shortcut, used to save
and rebuild the app), the error window keeps moving around, randomly
blocking parts of the screen.
(I think it's trying to center on wherever the mouse is at the time
the shortcut is hit.)
It seems it would be much better if
Evan Laforge wrote:
#include FL/names.H
BTW, fl_eventnames appears to be undefined. I see it in commented-out
debug prints, but can't find a definition anywhere.
It's in the FL/names.h file. When you include it, that
variable becomes a global.
(in my previous post,
Duncan Gibson wrote:
I described FLTK-2.0 as experimental but dormant in Article #825,
What are the versions of FLTK, but with Ben now plugging away at
the 2.0 STR list, is there a better way to describe it.
Would Experimental, was dormant, but maybe now waking again be OK?
Now I read it
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I am using fltk2.0 for my development.
That may not be wise, as fltk2 is the experimental branch, has never had
a release, and is still considered alpha for most practical purposes.
Can we insert -alpha-' into the 2.0.x tar snapshot
Michael Sweet wrote:
Done!
Nice!
I hope folks don't ask 'where's the old non-alpha version'? lol
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Duncan Gibson wrote:
fl_everything_to_utf8()
Hmm, but isn't that what iconv(3) is for?
I'm not sure, but I think that was the rationale behind FLTK
not providing that. I think the edict was: FLTK would support
ascii and valid utf8 only; everything else would
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2618
Version: 1.3-feature
The add() function in Fl_Tree needs to be able to allow the user to specify
items that contain front slashes, without the slashes being
I was noticing while creating the Fl_Tree API I had some second thoughts
about function naming.
Things like: open() / close() / select() / deselect() all seem obvious enough,
but when testing to see if something is selected, seemed one could go
either present or past tense:
is_open() vs.
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2618
Version: 1.3-feature
Fix Version: 1.3-current (r8632)
Fixed in Subversion repository.
Fl_Tree's add(), item_pathname(), and other 'pathname' oriented methods
now handle escape characters (\) to protect forward and back slashes.
Ian:
I think it's like we are talking about a door; you would say;
The door is open, but The door is opened would be OK too.
You would not say The door is close, you'd want to say the door is closed.
Right, I think that's the right way to think about it.
This is basically a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1981
Version: 1.4-feature
Docs should probably reflect if this code is sensitive to when it can be
executed. (ie. before/after show() is called, before/after the xid is
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1981
Version: 1.4-feature
I get asked for this feature a lot for my nixieclock application.
I don't personally like it either, at least not as a default. (eg. Task
I was noticing yesterday fltk (1.3.x) builds the fltk subproject
in DLL hell mode, ie. with the compiler flag /MD (DLL runtime libs)
instead of /MT (static runtime libs).
Using /MD creates a situation where the resulting exe ends up
requiring MSVCRXXX.DLL
Anyone who's used VS2010 has probably noticed it no longer shows
the compile/link lines. It's as if they're completely gone now.
In it's place are ridiculously terse succeeded/failed messages.
Good luck trying to find the magic damn button to push to turn
that feature on. From the main menubar:
Ian MacArthur wrote:
I'm wondering if:
a) the /MD flag is a good default, given the DLL hell
it seems to incur on unsuspecting programmers;
perhaps /MT instead?
b) Is there an easy way to change this for the entire lib
Matthias Melcher wrote:
I'm wondering if:
a) the /MD flag is a good default, given the DLL hell
it seems to incur on unsuspecting programmers;
perhaps /MT instead?
The static libraries have their own problems [..]
Trust me, I've run into too
Greg Ercolano wrote:
Matthias Melcher wrote:
Oh, and BTW, linking multithread DLL does *not* mean that you have
to link dynamically! It merely means that the C runtime is linked
dynamically, making sure that all modules use the same basic C functions.
Right, and therein lies
Manolo Gouy wrote:
Time for celebration!
..and after we've celebrated and are nursing over our hangovers,
time for some heavy testing!
Seems like we should all take the latest 1.3.x current
(including non-devs), and...
o Make sure fltk-1.3.x
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2635
Version: 1.3-feature
I agree with Albrecht, but I'm going to abstain from voting
because I have nothing to add to that assessment, and am not
familiar enough with
Albrecht Schlosser wrote:
Assuming that works, the only thing that might be wrong with this
(having a small static link stub to access the DLL) would be an
LGPL issue, believe it or not.
LGPL ISSUE
[...]
/LGPL ISSUE
IANAL, but... Our FLTK library allows to link
Albrecht Schlosser wrote:
You don't need a #ifdef if you use my example header file, you must only
#include this _and_ define FL_DLL before the inclusion (usually via the
command line) if you want to build a DLL version of your program.
I see, so in other words, only the main.cxx of
Greg Ercolano wrote:
However; I wonder how compatible our LGPL exception is
with the other libs we include (png, jpeg). I guess those
are optional libs that the user can link against as dlls,
but if one uses them, perhaps our exception becomes disabled.
Answering
Ian MacArthur wrote:
On 24 May 2011, at 21:31, Albrecht Schlosser wrote:
I don't see either of those as blockers - though be nice to get to the bottom
of 2639, as in my testing the behaviour was puzzling... I never use Fl_Pack
though, so not really sure what I'd expect!
#2647 looks
Ian MacArthur wrote:
On 27 May 2011, at 11:55, Albrecht Schlosser wrote:
It's not just me - recent versions of gcc whine on about this too!
Really? I can only remember having seen gcc warnings if you combine
'' and '||' (where '' takes precedence over '||' anyway, and
we fixed all *these*
Evan Laforge wrote:
On Fri, May 27, 2011 at 3:55 AM, Albrecht Schlosser
ajs856s...@go4more.de wrote:
On 27.05.2011 10:43, MacArthur, Ian (SELEX GALILEO, UK) wrote:
As I was reviewing the recent commits, I was looking at this line of
code:
+ if (num_screens 0 n= 0 n num_screens
On 06/06/11 09:24, Manolo Gouy wrote:
On 06.06.2011 10:01, Manolo Gouy wrote:
Reading STR #2657, I discover that Fl_File_Chooser.cxx seems to be
generated from Fl_File_Chooser.fl. I have modified the .cxx file
at r.8282 and r.8286. Should I modify accordingly the .fl file?
yes, please!
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2660
Version: 1.4-feature
Just browsing these patches..
To keep things 'light', the XPMs could perhaps be optimized a bit;
eg the black+white hour glass colormap could
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2662
Version: 1.3-feature
This is a docs-only RFE.
As Li Ding pointed out in this thread:
http://fltk.org/newsgroups.php?gfltk.general+v:33076
..we probably need to go
On 06/10/11 11:54, Evan Laforge wrote:
..we probably need to go into some details in the Drawing Things in FLTK
section about how the coordinate space works for widgets vs. windows.
Speaking of which, why is it that way in the first place?
I think it was mainly a speed issue, to
On 06/14/11 23:49, Evan Laforge wrote:
On Tue, Jun 14, 2011 at 11:34 PM, Bill Spitzak spit...@verizon.net wrote:
It would be a hassle to update every widget whenever the window was
dragged.
If you're just sliding the window around, the widget's positions
do not change. (ie.
Can a 1.3.1 option be added to the STR system's submenus?
I noticed 1.3.0 appears *twice* in the Fix Version: submenu,
so I'm guessing something needs to be tickled for 1.3.1 to show up.
___
fltk-dev mailing list
fltk-dev@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?L2672
Version: 1.3-feature
This sounds really cool.. and the patch is small and the code is small.
Sounds great -- my initial reaction is +1 to add it, but I want to
I ran into this too in 8837 (current) compiling on linux.
In the interest of helping others avoid this error,
I ran 'make depend' in the test directory, and checked in
the resulting 'makedepend' as r8838. Hope that doesn't cause trouble.
On 06/20/11 08:39, Matthias Melcher wrote:
Ahrgh. Go
On 6/23/11 5:55 AM, Matthias Melcher wrote:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2672
Version: 1.3-feature
I am considering making Gleam 3 the default look for FLTK 3. Would that be
OK?
On 07/05/11 13:25, Georg Potthast wrote:
I have observed that apparently FLTK does not use the key characters
but the key scancodes.
FLTK lets you access both.
See the Keyboard Events paragraphs on this page for info:
http://fltk.org/doc-1.3/events.html
Is this
Maybe fltk.announce isn't used anymore (no updates since 1.1.7)
but might be good to post the 1.3.0 release there.
Perhaps (for historical purposes) make back-dated postings
that reflect when 1.1.8, 1.1.9 and 1.1.10 were released..?
Or perhaps delete the group if unused. (Seems fltk.general
is
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2679
Version: 1.3-feature
Yes, good point.
Assigning this to myself to investigate and apply.
I should add Fl_Table to the 'unittest' test program suite
as well,
Ah, crap.
The 1.3.0 opportunity passed for me to add an integer
to the Fl_Table class for _scrollbar_size so that it
would be like the other scrollbar oriented widgets
where the scrollbar size can have a local override
to the global one.
STR#2679 reminded me of this.
Are we planning on being
On 07/16/11 06:15, Dmitrij K wrote:
Albrecht Schlosser albrec...@go4more.de wrote:
-#define SCROLLBAR_SIZE 16
+#define SCROLLBAR_SIZE (Fl::scrollbar_size())
Perhaps it will to have conflicts for names of variables from users
(SCROLLBAR_SIZE),
But maybe and not...
It
On 07/16/11 20:57, Michael Sweet wrote:
Yes, no incompatible ABI changes in patch releases (you could have a method
that refers to the global default, but not add something to the class that
would change the size...)
If someone can supply the new text, I can do the footwork
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2679
Version: 1.3-feature
Fix Version: 1.3.1 (r8863)
Fixed in Subversion repository.
Link: http://www.fltk.org/str.php?L2679
Version: 1.3-feature
Fix Version: 1.3.1 (r8863)
___
fltk-dev
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2681
Version: 1.4-feature
Fl_Table needs a local scrollbar_size() method, similar to Fl_Tree,
Fl_Browser, etc.
Once added, adjust test/unittest_scrollbarsize.cxx to call
On 07/17/11 02:01, Albrecht Schlosser wrote:
On 17.07.2011 08:24, Greg Ercolano wrote:
On 07/16/11 20:57, Michael Sweet wrote:
Yes, no incompatible ABI changes in patch releases (you could have a method
that refers to the global default, but not add something to the class that
would change
On 07/16/11 20:37, Michael Sweet wrote:
We should drop the reference to gnu.org and just refer to it as the FLTK
License...
If someone can supply the new license text that we should use,
I can do the footwork of the mega-diff.
___
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1725
Version: 2.0-feature
Fix Version: 2.0-feature
Amy/cg.amit: the developers are wondering why you attached this very old
(circa 2001) enumerations.H file to this FLTK
Hmm, can someone check the LGPL header src/scandir.c?
While doing the LGPL header mods for STR #2685,
I noticed this file appears to be part of the GNU C
Library, which may not be compat with the FLTK
static LGPL exception.
This code might need to be re-written.
Great, I've made STR#2685 and assigning it to myself.
Big thank you for volunteering for such a big task. One question
though: are we (you) going to do this for 1.3, 3.0, or both? ;-)
I guess both in the longer term, but we do 1.3 first... and it appears
Greg would agree, as he's
On 07/19/11 05:52, Greg Ercolano wrote:
Great, I've made STR#2685 and assigning it to myself.
Big thank you for volunteering for such a big task. One question
though: are we (you) going to do this for 1.3, 3.0, or both? ;-)
I guess both in the longer term, but we do 1.3 first
On 07/19/11 08:14, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds.
Seems like we gotta fix this.
On 07/19/11 07:56, Albrecht Schlosser wrote:
On 19.07.2011 15:29, Greg Ercolano wrote:
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds
Would like to suggest adding a few things to Fl_Input_Choice:
1) Change the existing method:
void add(const char *s) { menu_-add(s); }
to instead:
int add(const char *s) { return(menu_-add(s)); }
This corrects an omission, allowing the user to access
[..]
Made STR #2687 to track this issue.
http://fltk.org/str.php?L2687
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 07/20/11 03:14, Albrecht Schlosser wrote:
On 20.07.2011 10:04, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Agreed, but then we might have to maintain dead code, and given the
complexity of all that #if HAVE_something stuff, i'd like to remove
it for all times...
Suggest we comment out
On 07/20/11 02:11, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Pretty sure the others would have no impact.
I think adding new methods is OK. (But see above!)
Does it change the size of the class though?
No changes in size, just adding code.
Changing the return value
After reading STR #2696 http://www.fltk.org/str.php?L2696
it sounded like we should add some docs for fl_xid()
to mention the need for apps to #define FL_INTERNALS.
I'm not sure what to write or I'd write it.
Looks like documenation/src/osissues.dox is the file
where fl_xid() is documented, and
Any of you FLTK devs at Siggraph this week?
If so, hit me up on email 'n we can haz cheezburgerz
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 8/10/11 10:32 AM, Matthias Melcher wrote:
On 10.08.2011, at 14:36, Greg Ercolano wrote:
Any of you FLTK devs at Siggraph this week?
If so, hit me up on email 'n we can haz cheezburgerz
Aw man! I would love to, but I have not been at Siggraph *forever*.
Sigh. I always loved that show
On 8/11/11 1:37 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Congratulations on the the Academy Award btw.!
Ah, you found out my secret ;)
Sure - but you did put it up on your news page, so not all that much of
a secret...
LOL, I wouldn't have guessed anyone on FLTK keeps
On 08/26/11 09:05, Matthias Melcher wrote:
If anyone has code that can act as a frontend to command line tools,
and that can handle stdin, stdout, stderr, and signals simultaneously,
please send code ;-). I need some kind of simple FLTK text terminal.
This is as close as I'd ever
On 08/26/11 10:27, Greg Ercolano wrote:
On 08/26/11 09:05, Matthias Melcher wrote:
If anyone has code that can act as a frontend to command line tools,
and that can handle stdin, stdout, stderr, and signals simultaneously,
please send code ;-). I need some kind of simple FLTK text terminal
On 08/26/11 13:13, Evan Laforge wrote:
Mmm, it probably could by replacing popen() with pipe()'s
and fork()/exec(), with select() to watch the stdout/err pipe,
and trapping keystrokes yourself and sending them to the stdin
pipe.
Tricky though. I'd do it myself, but this week
On 08/26/11 23:55, Matthias Melcher wrote:
Well, for now the popen solution is somewhat OK.
I want Fluid to launch all kinds of tools, which usually
only requires reading characters from the tools.
It would be nice to have some way to send characters as well,
for example for launching gdb
On 08/29/11 01:26, MacArthur, Ian (SELEX GALILEO, UK) wrote:
The example opens up a tcsh prompt.
See, that's gotta be a bug, right there! ;-)
You're right, it is a bug.. in bash!
During dev, I was getting inconsistent behavior from bash
on an old OSX 10.4.11
On 08/29/11 01:26, MacArthur, Ian (SELEX GALILEO, UK) wrote:
It uses pthreads and bidirectional pipe(2)s. All FLTK operation
is handled by the parent; the threads are just data pumps.
[I chose not to use add_fd() to facilitate a Windows port]
On WIN32, add_fd() will work OK
On 08/06/11 10:07, Greg Ercolano wrote:
After reading STR #2696 http://www.fltk.org/str.php?L2696
it sounded like we should add some docs for fl_xid()
to mention the need for apps to #define FL_INTERNALS.
I'm not sure what to write or I'd write it.
This keeps coming up, so I added
On 09/02/11 07:32, Manolo Gouy wrote:
Greg: I don't think FL_INTERNALS should be defined before
function fl_xid() is called, as implied in your r.9025 doc change.
In files x.H and win32.H, fl_xid() is declared twice according
to whether FL_INTERNALS is defined or not. In mac.H, it is defined
On 09/02/11 10:56, Manolo Gouy wrote:
Also, fl_xid() was part of the API and declared in x.H
already in 1.1, without need for any extra symbol definition.
OK, good. So just confirming:
Should the public docs for fl_xid() indicate
one should #include FL/x.H to make use
On 09/02/11 12:54, Manolo Gouy wrote:
This common header requirement is clearly stated at the top of the
Operating System Issues section of the doc. Isn't that enough ?
LOL, believe it or not, I missed it ;)
Yes, it's certainly clear, right at the top.
Actually, I'd
On 09/03/11 14:47, Manolo Gouy wrote:
All (but especially Greg I guess...)
I have an app that uses the FNFC, and the OSX version crashes quite =
often when I use the BROWSE_SAVE_AS mode - but the regular open file =
case seems to be fine...
Now, the app has been kicking about for a while,
On 09/04/11 12:47, Manolo Gouy wrote:
I see here, that there is a bug on OS X with the BROWSE_SAVE_FILE
mode when the filter() function is used: the filter string needs to
end with a \n; without it the program crashes. Do you see
that as well ?
Sounds like I should add a check for this
If I run that app and do these steps:
1) File - Save As, filter appears
2) File - Open, *filter is missing*
3) File - Save As, *filter is missing*
The filter being missing is the problem.
[..]
Perhaps _filt_total shouldn't be reset to
On 18.09.2011, at 19:46, Jonathan Egstad wrote:
(a big hi to all the old DD guys on this list)
Egg! And old we are..
Someone kindly fetch me my cane and stool softener..
Is anyone touching 2.0 at all or should I look at the
latest 1.3 to figure out the replacements for the
I hope I haven't asked this one before:
Does it create any kind of ABI issue if one moves
a class method's code implementation from the .H file
to the .cxx file? (ie. doesn't change the calling params
or return value, just moves the code from one to the other)
On 09/23/11 09:40, Bill Spitzak wrote:
Functions defined in the body of the code in a .h file end inlined:
Ick, I didn't know 'inline' would be implied if the code was
implemented in the .H file.
So it sounds like if an app /dynamically/ builds against a lib
On 09/25/11 13:09, Bill Spitzak wrote:
Inline is only implied if the method is defined inside the class
definition.
Right, clear on that now.
What's interesting are the implications this has on dynamic libs;
code changes made to lib methods implemented in .h won't be
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2721
Version: 1.3-feature
Regarding this STR (cursor position within a selection), I've can't say
I've ever seen this before anywhere.
When something is selected, the
On 10/03/11 01:26, MacArthur, Ian (SELEX GALILEO, UK) wrote:
There are also some Mac OS bug fixes in the svn version
that would be good to be present in 1.3.1. Is that possible ?
Sure. I will do an svn diff to figure out what is needed. Any
suggestions welcome.
There was a probvlem with
Two questions:
1) Is there a way to get a list of all the tags in fltk 1.3?
ie. something like the following, but that doesn't have to be
run on the easysw server:
http://blog.amnuts.com/2007/08/14/getting-a-list-of-project-tags-from-subversion/
2) is the SVN rev# for releases
601 - 700 of 938 matches
Mail list logo
