Yuri wrote:
Greg Ercolano wrote:
I'm not absolutely sure about it, but I would prefer a different branch for
starting the FLA upgrade. ...
I can also see the problem if this approach takes a longer time to merge the
changes later, but I think that this would be much better because
I just did an update to fltk2, and now it won't build on my
ubuntu8.04 system with the standard x11-dev stuff installed.
Is this something wrong with the default build, or maybe a new
requirement I'm missing?
1.3.x and 1.1.x builds OK, and fltk2.0 used to build OK until now.
=== making src ===
This is one of these widgets that does resizing in draw() like Fl_Scroll
with its scrollbars :-(
Oh heck, that reminds me, I need to check in those Fl_Scroll mods
we worked on for resizing the scrollbars in..!
That wasn't my intention, but ... yes, that would be fine ;-)
Eric Liao wrote:
I just tried as you suggested - adding a leading space before iLiHei
to iLiHei. The result is the same. No difference. I put a screen
capture here:
http://www.mobileread.com/forums/attachment.php?attachmentid=32351d=1247678156
Can you include a hex version of the
I'm thinking the docs for the 'old' multiline text widgets:
Fl_Multiline_Output
Fl_Multiline_Input
..should probably refer people to the newer widgets:
Fl_Text_Display
Fl_Text_Editor
..respectively, and the docs should probably show a simple
example of each
Eric Liao wrote:
The result of running od -tx1 foo.txt: 000 e4 b8 ad e6 96 87 e6 b8 ac
e8 a9 a6
This worked for me.
I don't have iLiHei, but Kochi Gothic worked for me.
I guess change it as you need.
#include fltk/Font.h
#include fltk/Window.h
#include
BTW, here's a screenshot of what I see on my ubuntu8.04 system
with fltk-2.x svn r6829 using Kochi Gothic:
http://seriss.com/people/erco/fltk/tmp/chinese.png
Eric Liao wrote:
Thanx for your help. I installed Kochi Gothic font and used your code
but still not got the
BTW, here's a screenshot of what I see on my ubuntu8.04 system
with fltk-2.x svn r6829 using Kochi Gothic:
http://seriss.com/people/erco/fltk/tmp/chinese.png
Eric Liao wrote:
Thanx for your help. I installed Kochi Gothic font and used your code
but still not got the
MacArthur, Ian (SELEX GALILEO, UK) wrote:
What revision of fltk-2 are you using? Is it linked with XFT for font
support or is it using Xlib?
That's a good point.
In my case I've compiled 2.x with all 'defaults', and XFT is
definitely 'on' in my case; I get nice smooth
Do a 'make distclean' first, and re-run 'configure', then 'make'.
The errors would seem to indicate fltk2 was 'configure'd on a machine
with GL or glut installed, and later this pre-configured code was copied
to another machine without re-running configure.
So run configure again; it should
, use Fl_Text_Display instead.
Fl_Input_Multiline
If you want scrollbars to appear when data exceeds the edges of
the widget, use Fl_Text_Editor instead.
Albrecht Schlosser wrote:
Greg Ercolano wrote:
I'm thinking the docs for the 'old' multiline text widgets
Eric Liao wrote:
2. Did you add error checking to the font calls in the test program I posted?
I just copied your source code. No error checking was added. Besides, I
don't know how to do the error checking. If not bothering, please show
me how it is done.
By this I mean, check
Eric Liao wrote:
What can be the cause?
We don't know -- and since we can't replicate,
to find the answer you'll have to dig deeper I think:
..at that point you'd have to dip into FLTK's source code
for that function, fltk::font() in src/list_fonts.cxx,
copy that
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Are you still building the test program with your Makefile? Or did you
try building it just using fltk2-config...
fltk2-config --compile mycode.cxx
FWIW, I used his exact g++ command and it compiled+ran fine
here on my ubuntu
Eric Liao wrote:
1. I tried fltk2-config --compile mycode.cxx and got the correct
display. So, the problem is solved. What left to answer is how did that
happen. I have some interesting test result. Please read the following.
2. I always built your code using: g++ -o fltkhello1
It seems there might not be an easy way to make a copy of an
Fl_Widget, such that all the colors/fonts/etc are copied from the original.
I'm creating an app that presents objects as FLTK widgets on a 'desk'
that the user can select and copy/paste with ^C/^V, similar in some
respects to what fluid
Matthias Melcher wrote:
it would be a lot harder to have an assignment operator that copies only
attributes that are common among the source and destination widget.
I see, so sounds like the assignment operator idea is bad.
What is is specifically that would make
Isaque Galdino wrote:
If we are thinking about copy, I believe the solution would be to copy
everything. It's the programmer's job to identify what needs to be
linked and what is not.
My 2cents.
Right, though the devil's in the details.
Making copies of eg. pointers
Roman Kantor wrote:
But in that case, would not it be easier - and already possible - to
copy only things you want? Otherwise you would need to fix wrongly
copier members - and there is lot of them - and fix things like
copied_label flags, children (if it is a group-type) and all that jazz.
Greg Ercolano wrote:
Isaque Galdino wrote:
If we are thinking about copy, I believe the solution would be to copy
everything. It's the programmer's job to identify what needs to be
linked and what is not.
My 2cents.
Right, though the devil's in the details.
Making copies
The virtual copy ctors you mentioned sounds like a good idea.
Oops, I misunderstood; apparently you were talking about making a
virtual duplicate() method, not a virtual copy ctor.
(According to my compiler, one can't make copy ctors virtual)
I'm probing around for the
Duncan Gibson wrote:
When I used to follow the comp.lang.c++ newsgroups, one of the big
gotchas was about compiler supplied default and copy constructors
and the assignment operator. Scott Meyers has various references to
these in his Effective C++ series, as does Herb Sutter in his
Albrecht Schlosser wrote:
As Greg mentioned, we can do copy_label(), but we do not (yet ?) have
copy_tooltip() - but this is useful and should be implemented anyway.
Yes, looks like that's needed.
___
fltk-dev mailing list
fltk-dev@easysw.com
Isaque Galdino wrote:
Greg, you were right! The missing hint is _NET_WM_WINDOW_TYPE that must
be set to _NET_WM_WINDOW_TYPE_MENU.
I've just uploaded the new patch to the STR. Please anyone take a look
and see if that's ok.
It sounds like we might be missing a window manager
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1130
Version: 2.0-feature
I'd opened STR#1029 a few months before recommending functions be added to
make this clearer, so these two STRs are related.
There is a way to
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1738
Version: 1.3-feature
I think this STR can be closed as being resolved by FLTK 1.3.x (which is an
official release that supports UTF8, and is in a very active state)
Following up.
Did a little more on this, because I happen to be working
on something similar.
In total, I think all these files are missing from the
CPPFILES section of the src/CMakeList.txt file:
fl_encoding_latin1.cxx
fl_encoding_mac_roman.cxx
imacarthur wrote:
Greg, Did you reply to the wrong thread?
It must have been late where you are...!
Thanks for the heads up; I'll follow that up
to the other thread.
Yeah, was doing too many things at once
back and forth between general and development,
Installing this now, to test FLTK with OSX 10.6 on 64bit Intel.
A few things you should know about Snow Leopard:
1) Available at Apple retail stores now ($29/single, $49/family)
2) *1GB RAM minimum*
3) Comes with XCode compiler (ie. g++/gcc, etc) as per usual.
Regarding
OK, hope you all are ready for this..
This is a fresh checkout of 1.3.x and default FLTK build
on stock Snow Leopard 10.6 + stock Xcode tools
running on an intel mac mini:
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
-- -- -- -- -- -- -- --
Jane wrote:
fltk 1.1.9 builds for me using the gcc-4.0 compiler that comes with SL. :)
i have used:
~/src/fltk-1.1.9$ ./configure CC=/Developer/usr/bin/gcc-4.0
CXX=/Developer/usr/bin/g++-4.0 CFLAGS=-arch i386 -arch ppc
-mmacosx-version-min=10.4 -O3 CXXFLAGS=-arch i386 -arch ppc
Jane wrote:
let me know if you need help to fix fltk for that 64 bit stuff, assuming
there are probably not many SL+fltk devs as of yet.
Yes, that'd be great.
I know zippo about the OSX APIs for Carbon/QuickDraw,
and wanna keep it that way.
My work on
MacArthur, Ian (SELEX GALILEO, UK) wrote:
- Is this for fltk-1.3?
Yes, 1.3.x, svn current.
If so, the --enable-quartz is *probably*
redundant as that is supposed to be the default in 1.3. Ditto
--enable-threads.
Jane used that because in that case it was fltk 1.1.9 being
Best to email the patch to me directly, or post it here as an attachment,
so that folks can access it in case I take a while to get around to
apply/release.
FNFC is still a separate project, but I think there are plans to include it
in a future FLTK release; I leave it to the fltk devs to decide
Gary Hui Zhang wrote:
Thanks for developing the FNFC! It's a great add-on. Per your suggestion,
I've canceled the post to the STR and sent the patch to your email listed on
the FNFC home page.
Received; I'll check it out, and try to make a micro release.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
I'll print the patch out and give it a good look over.
Patch changes the API, so it needs docs. (doxygen)
This looks worrisome:
Fl_Image*
While implementing STR#1739 I noticed the return value for find_line()
does not document what the return value is if the parameter 'line'
is out of range.
I did an empirical test, writing a program that sends find_line()
values between -10 and 10 on a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Thanks for the patch vedran.
I looked this over, seems OK API wise.
Looks like the way it's written, passing an icon=NULL will
do the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Assigning STR#1739 - Greg Ercolano.
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Browser.H
#include
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Fixed in SVN r6850.
Please test, and verify here.
If all is well, I'll close this as resolved.
Link: http://www.fltk.org/str.php?L1739
Fl_File_Browser apparently has its own code to manage icons,
and it derives from Fl_Browser.
As SebHoll points out in STR#1739, now that Fl_Browser supports icons,
possibly Fl_File_Browser's code should be simplified to make use of this
new capability.
This is not critical, and maybe 'if it
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Seb:
Following up regarding Fl_File_Browser's own FL_BLINE
definition.
OK, I echoed the change there as well,
as indeed it
[I'm changing the title of this thread to 'cmake', as that's an
interesting direction to go, but is somewhat separate from the FNFC thread]
Matthias wrote:
Um, yeah, that is one of the biggest problems for pretty much all of us:
adding a new source file requires maintenance in all build
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Albrecht:
Ah, OK -- the vert scrollbar starts 'accumulating'.. I see.
Right as usual ;)
I'll look at the patch you posted and try
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
OK Albrecht, adding this line at the very end of Fl_Browser's
icon(int,Fl_Image*) will solve the horiz scrollbar issues as well:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Albrecht, your patch regarding the vert scrollbar got me to thinking what
happens with the horiz scrollbar.
Interestingly, there is a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Browser.H
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1739
Version: 1.4-feature
To redrawing: IMHO calling the minimal update redraw_line() would be
okay, but we shouldn't call redraw() for a _complete_ redraw of all
I installed cmake on my VS 8 system, and using a recent patch provided
in STR #2244,
was able to get fltk to build with cmake/nmake.
Maybe we should start a README.cmake file, as I have text to put in it:
* * *
Using cmake to build Fltk with VS 8.0 + nmake
Greg Ercolano wrote:
See last posting. Basically what you'd want I think is:
cmake -G Visual Studio 8 2005
I'm just about to crawl away, but I just tried that, and it generated
a hot, steamy little fltk.sln file.
I opened it up in VS express and it loaded
So then potentially we could run those as part of the distro builds
so that up to date IDE files are released in the tar files.
That sounds great!
Roman Kantor wrote:
There is a cmake switch CMAKE_USE_RELATIVE_PATHS (or something like
that, do not remember exactly) which causes to generate
Albrecht Schlosser wrote:
One way to avoid making it public (and I would vote for not making it
public!)
would be to use a common include file, so that we don't need to worry about
later changes.
Sounds good, though I'm not the one to implement that change,
as that would be
maoserr wrote:
For nmake files, you can edit options by doing nmake edit_cache and it'll
bring up a GUI
Sweet. That's good to know.
Hopefully there's a non-gui way, so that it can be automated
into scripts as a build command line flag.. I'll look into that too,
FLTK DOXYGEN: http://docs.google.com/Doc?docid=dgn42tzv_0fsbjmjgphl=en
The old thread on Doxygen FLTK coding standards mods that turned
into a google document (March 2009) is getting old, so I thought
just in case google hiccups or does some accidental house cleaning,
I'd
Albrecht Schlosser wrote:
Anyway, back to CMake ;-)
Yes, from what I've seen and learned about CMake, I really like the idea to
use
CMake to support the IDE project files and _maybe_ drop autoconf (as
Christophe
did for gmsh). BTW: I didn't see XCode in the list of supported IDE's.
zlc53 wrote:
i can't building in vs2005 is use cairo。
1)
fltk-2.0.x-r6844\src\win32\run.cxx(2266) : error C2065: “cc�
2)
fltk2d.lib(run.obj) : struct HPALETTE__ * __cdecl fl_select_palette(struct
HDC__ *)
fltk2d.lib(Font.obj) : error LNK2001: unsigned long fltk::current_xpixel
MacArthur, Ian (SELEX GALILEO, UK) wrote:
i use postion function , but can't auto redraw
Don't understand the question.
You need to tell us enough to helo you...
OP followed up to my email with the question:
But why do not automatically redraw it?
..and I mentioned I'd answer
Albrecht Schlosser wrote:
Matthias Melcher wrote:
Seriously though. If FLTK has stalled completely, I propose that:
This should read: If FLTK *2* has stalled completely ...
Yes, emphasis on that!
FLTK 1.x remains in active development/support.
It's only FLTK2 that
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Want me to apply these patches to 1.3.x + close this?
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Just noticed the useful colorchips in documentation/src/fl_show_colormap.gif
is not being referenced by our docs.
Which led me to realize fl_show_colormap (which pops up the colorchip dialog)
isn't documented either.
OK if I add some docs for that, vis a vis 1.1.9's docs:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Fix Version: 1.3-current
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Fix Version: 1.3-current
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2169
Version: 1.3-feature
Fix Version: 1.3-current (r6893)
Fixed in Subversion repository.
Matt, when you can confirm, I'll close it.
The test/input program and the
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Still an issue with it not forcing the image libs to static if I use
the system image libs, but that's probably not a show stopper...
[..]
if I configure to use the system libs I get:
/d/IanMacarthur/svn/fltk-1.1
$ ../fltk-1.1/fltk-config
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Hey - Greg's got an Irix box that still works!
It makes a great space heater in winter.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Albrecht Schlosser wrote:
This could be done by simply setting the default for our configure
option --with-links to --without-links, so that users still can
configure their installs to have the symlinks. (Did you know that we had
this already ?) ;-)
Sounds good.
The question here
Greg Ercolano wrote:
Albrecht Schlosser wrote:
This could be done by simply setting the default for our configure
option --with-links to --without-links, so that users still can
configure their installs to have the symlinks. (Did you know that we had
this already ?) ;-)
Sounds
Matthias Melcher wrote:
Actually, for 1.3.0, we could remove the symbolic links and instead
create files that include a #warning statment, then later an #error
statement, kind of slowly deprecating the feature.
Right.. for the compilers that support this.
I also thought
On 23.09.2009, at 00:48, Greg Ercolano wrote:
I also thought 'configure' would be a good place to put
warnings (ie. have the 'configure' script sniff around
in /usr/include for links, and if found, warn about them)
Since everyone has to run configure, whether they do
Matthias Melcher wrote:
I am not sure what to do, because WIN32 is casinsenitive
anyways, so they will never see an issue until their source code is
compiled on OS X or Unix. I guess that that problem can never be
solved anyways... .
Yes, seems we may never solve the original
Albrecht Schlosser wrote:
Wrong definition of bit flags in Fl_Widget.H in r6905. I posted another
message, but can't fix it right now. Matt?
Maybe revert 6905 instead of fix for the short term?
___
fltk-dev mailing list
fltk-dev@easysw.com
I understand Dejan's fears, probably many want to avoid
whatever happened with fltk2, once bitten, twice shy.
Seems like the thing to do is to clearly spell out
exactly how fltk3 avoids that same fate. (It seems to,
since I take it Matt made some kind of change that
was very simple.. I've not
imacarthur wrote:
My excuse is that we have been negotiating to buy a house
Hey, that's my excuse! ;)
Yeah, you'll be busy for a while.
Inspections, contractor quotes, negotiations, packing/moving
preparations,
preping new utilities, movers, canceling old
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Are any of these fixes checked in?
I'm trying to test changes to Fl_Tree on OSX and can't compile fltk 1.3.x
svn
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2221
Version: 1.3-feature
Fix Version: 1.3.0 (r6951)
Matt, your latest svn fixed my build problem -- thanks!
Link: http://www.fltk.org/str.php?L2221
Version:
imacarthur wrote:
The sudoku demo does not seem to use the FL_ALT modifier, so I can
not comment on whether the saucepan is upside down or not...
With cocoa 1.3.x sudoku's system menubar item Sudoku - Hide Others
apparently has an ALT modifier, and I can confirm the saucepan
Albrecht Schlosser wrote:
manolo gouy wrote:
Probably from a logical point of view, but it uses dynamic_cast,
and that's not (yet?) allowed according to the current CMP :-(
[...]
I agree, but, please, note that this dynamic_cast is in Fl_cocoa.mm,
a file that does not have to be
Albrecht Schlosser wrote:
Now I'm totally confused. The error message you posted referred to
line #1477, which is the second occurrence of FORCE_POSITION. The
first is in line #1295. What is the error message?
I did a 'Rebuild solution', but who knows what goes on in the GUI.
This all sounds good regarding the POLL stuff.
I didn't know how it was being used.. I just assumed
(rightfully so, I think) that these macros were being used
by the OS system calls (eg. poll(2))
If we're not passing them to the OS and are for local use
only, then yes, we should use our own
OK, I've made STR #2301 for this to ensure it doesn't fall through the cracks.
Regarding the POLL* errors, I'll leave that to you all to apply, as I'm pretty
sure I'm not seeing all the ins and outs of those macro's use.
Regarding the FORCE_POSITION error, it sounds like there's agreement
imacarthur wrote:
On 30 Dec 2009, at 19:24, Greg Ercolano wrote:
Solution on win32 is to change _snprintf() to _snprintf_s()
with the _TRUNCATE macro as the third argument. But there's no
clear way to use a macro shortcut to do this (since this is a
varargs function), so
Then I tried this:
#ifdef _WIN32
extern C int fl_snprintf(char *, size_t, const char *, ...);
#define snprintf fl_snprintf
#endif /*MICROSOFT*/
Hmm, OK, so I guess I'll change my test program to use fl_snprintf.
And if that works normally, is it the case the fix would be
[..] because fl_snprintf() appears to be a complete
standalone implementation of snprintf(), so its behavior should be
consistent on all platforms.
Actually it's fl_vsnprintf() (emphasis on 'v') that's defined in full.
fl_snprintf() is a wrapper function that invokes
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Should we (can we?) post to fltk.announce about the release of 1.1.10,
just for the record as it were?
It hasn't had any posts since 1.1.7 was released. All the posts are by
Mike - maybe he is the only one who can post there?
Maybe Mike can
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
What are the build instructions?
There's no Makefile in the top level dir, and if I do a 'make' in the src
dir, it says there's no
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Oh, nevermind. Didn't catch it was to be installed into FLTK.
So it looks like, eg:
cp FNFC/FL/* /usr/local/fltk-1.3.x-svn/FL
cp
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature//
// $Id: native-filechooser.cxx 6615 2009-01-01 16:35:13Z matt $
//
// Simple
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-featureIndex: Makefile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Good. And we also need to document the FNFC API.
Yes, I'll see about converting the HTML docs to doxygen.
While I'm at it, I guess I can check
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Could you also please apply.. RFE 2221
I'm not the owner of 2221, Matt's handling that one.
So I best leave that to him.
Link:
Albrecht Schlosser wrote:
Greg Ercolano wrote:
The only things I'm not sure of are how to add it to the Microsoft projects.
I don't know. Since we have some older version project files, does
anybody know if these can be written with newer VS software, e.g.
with VS 2008 Express?
BTW
I have a seemingly catch-22 situation with Fl_Native_File_Chooser (FNFC).
It seems to make sense to have this widget be part of libfltk.a
(as opposed to libfltk_images.a)
The Linux version of Fl_Native_File_Chooser calls
Fl_File_Icon::load_system_icons()
as part of it's init, to ensure the FLTK
Albrecht Schlosser wrote:
One of them: require the user program to call it and don't call it
from Fl_Native_File_Chooser. This would give the user the option
to use the images or not and open the possibility to link w/o
libfltk_images. I'm pretty sure that my application doesn't use
OK, I've got FNFC building under linux (Ubuntu8) and OSX,
so I figure it's ready to check in.
Under OSX I tested with both COCOA enabled and disabled
(to test both sections of the FNFC code).
Windows build files haven't been modified, so windows will
not build FNFC or the test program, but that
Greg Ercolano wrote:
OK, I've got FNFC building under linux (Ubuntu8) and OSX,
so I figure it's ready to check in.
[..]
I don't foresee any further technical barriers,
so will be committing RSN, watch this space for details.
Committed as r6997.
I'm now re-checking out FLTK
imacarthur wrote:
On 13 Jan 2010, at 22:56, Greg Ercolano wrote:
OK, I've got FNFC building under linux (Ubuntu8) and OSX,
so I figure it's ready to check in.
Under OSX I tested with both COCOA enabled and disabled
(to test both sections of the FNFC code).
Windows build files haven't
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
OK, I just checked in FNFC into FLTK.
Manolo, I haven't made any the changes you mentioned
on or after 02:05 Jan 13, 2010 in this STR, so I'd
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Fix Version: 1.3-current (r6998)
Link: http://www.fltk.org/str.php?L2298
Version: 1.3-feature
Fix Version: 1.3-current (r6998)
Albrecht Schlosser wrote:
Done:
MinGW and Cygwin/MinGW are okay, no problem.
Good to know.
Cygwin/Cygwin, i.e. configure --enable-cygwin compiles and builds,
but picks the wrong (FLTK) file chooser instead of the Windows
native file chooser. That's due to the wrong usage of _WIN32
Albrecht Schlosser wrote:
Maybe we should document this somewhere, either in the CMP or in
the docs (chapter developer information?)...
Ya, sounds like it.
___
fltk-dev mailing list
fltk-dev@easysw.com
201 - 300 of 938 matches
Mail list logo
