On 19.01.2011 22:33, Domingo Alvarez Duarte wrote:
It seems that the supplied ide/projects aren't updated to include
FL_INTERNAL of FL_LIBRARY, because defining one of then make it works.
Thanks, I thought that they had it already (grep found some hits), but
I didn't verify.
I'm going to
On 19.01.2011 22:33, Domingo Alvarez Duarte wrote:
It seems that the supplied ide/projects aren't updated to include
FL_INTERNAL of FL_LIBRARY, because defining one of then make it works.
This should be solved now in svn r 8293, although there are still
some problems with generation of .cxx and
On 19.01.2011 19:57, Giau P wrote:
I have trouble setting VC++ 6.0.
VC++ 6.0 is really old. We're only partly supporting this for
compatibility. If you can, you should use VC++ 2008 or later.
I followed the compiling programs with microsoft visual c++ to run
hello.cxx sample program, from
On 18.01.2011 06:15, Ish wrote:
undefined reference to `Fl::gl_visual(int, int*)'
I believe that error means its implementation is missing. I haven't checked
the source yet to confirm that. It isn't virtual from what I understand in
the source code.
using Fltk 1.3
Which exakt FLTK
On 14.01.2011, at 18:38, Michael Sweet wrote:
I can certainly make fltk.bugs/fltk-bugs read-only. It'll mean some changes in
the bug system too (emails to fltk-bugs would need to be posted to fltk.bugs
directly, for example) but nothing we can't handle.
Mike, we've got at least three positive
On 18.01.2011, at 15:14, Paul R wrote:
The program only runs from args when a file is double clicked or if the user
know about such things 'dragged and dropped' onto the exe,
both of which things result in argc = 2, any higher and i have fails in
place, argc = 1 is ignored as i am using the
On 14.01.2011 13:19, Albrecht Schlosser wrote:
On 13.01.2011, at 21:05, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2011-01-13 12:05:32 -0800 (Thu, 13 Jan 2011)
New Revision: 8273
Log:
Fixed WIN32 crash when printing with the test/mandelbrot demo.
Modified: branches/branch-1.3/src
On 17.01.2011 11:27, MacArthur, Ian (SELEX GALILEO, UK) wrote:
quote-from-msdn
Alternatively, you can use the following compile options, which also
produces the expected behavior. Make sure that you use either main or
wmain, depending on which character set is used.
cl /clr sample.cpp /link
On 17.01.2011 11:42, Denton Thomas wrote:
Will do. I can't get the weekly (8276) for a test right now, though - looks
like the domain is in transition ... and caught due to MLK day.
It's working (again) for me. There were DNS problems last Saturday,
but they are fixed at least since Sunday
On 17.01.2011 13:32, MacArthur, Ian (SELEX GALILEO, UK) wrote:
So, if the OP shoul djust need to add
/SUBSYSTEM:WINDOWS
To the linker options, then?
That's what I believe, yes.
Albrecht
___
fltk mailing list
fltk@easysw.com
On 14.01.2011 18:38, Michael Sweet wrote:
On Jan 14, 2011, at 1:59 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote:
There seem to have been quite a few posts direct to fltk.bugs recently
by users unfamiliar with our ways... Some of these even seem to have
been of some merit (so it's good that
FYI:
I just noticed that the FLTK news server news.easysw.com is unreachable.
I sent a mail to Mike, and I hope that he can fix this when the night is
over in the US.
Albrecht
___
fltk mailing list
fltk@easysw.com
On 15.01.2011 12:21, Albrecht Schlosser wrote:
FYI:
I just noticed that the FLTK news server news.easysw.com is unreachable.
I sent a mail to Mike, and I hope that he can fix this when the night is
over in the US.
You can fix this temporarily by using the IP address 208.96.52.100
instead
On 15.01.2011 21:09, imm wrote:
Right now, I can't access fltk svn or the fltk.org web-pages, and it
looks as if the easysw.com domain is unreachable too, so I guess that
the DNS is messed up somewhere.
You're right, it was a DNS problem, and I got Mike's confirmation that
it's fixed. News
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2522
Version: 1.3.0
-1 on using FL_LIBRARY for Windows, i.e. we should change FL_LIBRARY to
another name for this purpose, as discussed in fltk.development, and this
Michael Sweet wrote:
Perhaps we could also allow defining FL_UNSTABLE or FL_UNPORTABLE to get the
OS-specific definitions then?
Or FL_OS_SPECIFIC or FL_INTERNALS ?
Yes, something like that maybe.
Albrecht
___
fltk-dev mailing list
MacArthur, Ian (SELEX GALILEO, UK) wrote:
There seem to have been quite a few posts direct to fltk.bugs recently
by users unfamiliar with our ways... Some of these even seem to have
been of some merit (so it's good that Matt reads them!)
However, I still wonder why fltk-bugs is not just made
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Some sort of FL_low_level_feature_here_be_dragons... option sounds
like a good idea, and we separate the Fl_X stuff from the FL_LIBRARY
option, resolving Albrecht's point.
Though if we are doing that, I guess we'd need to do it before 1.3.0
goes
On 13.01.2011, at 21:05, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2011-01-13 12:05:32 -0800 (Thu, 13 Jan 2011)
New Revision: 8273
Log:
Fixed WIN32 crash when printing with the test/mandelbrot demo.
Modified: branches/branch-1.3/src/fl_draw_image_win32.cxx
Paul R wrote:
Well ian you had it right in the first place...i was referring to the
little icon you see in the top left of a windows box, like for
example using internet explorer you see the little 'e' icon in top left.
...
So i think i should look at the sudoku example you mentioned..
There
On 14.01.2011 14:55, Brian Tilley wrote:
Ian wrote
That looks weird - looks like the fltk_jpeg lib somehow incorporates
duplicates of the entire fltk.lib...
Must be a linker misconfig or something, I guess?
Looks like you were right Ian,
I think I've sorted all the problems now.
I've
Paul R wrote:
undefined reference to png_create, read_struct
undefined reference to jpeg std error
undefined reference to jpeg finish decompress
etc
I had been advised to add the fltk library 'before' fltk.a so i did
this, same problems
i added the fltk_z.a library as i thought that was
On 14.01.2011 20:40, Matthias Melcher wrote:
lbfltk_png is just the interface between fltk and png, You still have to link
with libpng. png then again depends on zlib, so you have to link that as
well. And while you are at it, ling libjpeg as well.
libfltk_png *is* libpng, if you use the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2518
Version: 1.3.0
Unfortunately your modification doesn't work well with our doxygen
documentation. We need the argument names for it to work. Sorry, I don't
see a
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2519
Version: 1.3.0
The VisualC2008 project builds well with VC 2008 Express, and since they
use the same source files, I tend to say that it's a bug in the old VC6
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2520
Version: 1.3.0
FLTK 1.3 adds a new Fl_JPEG_Image constructor that loads images from
memory:
Fl_JPEG_Image::Fl_JPEG_Image (const char *name, const unsigned char
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2519
Version: 1.3.0
Fine, thanks. Although my suggestion would be Fl_Text_Display*, but I'm
okay with both. Do what you like more.
Link:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2520
Version: 1.3.0
To Matt: I see... I didn't realize the potential char * vs. unsigned char
*, so it is clear that we need both parameters. Thus, the only thing we
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2520
Version: 1.3.0
Domingo, your proposal is interesting, but please file this as a separate
STR so that it won't get lost and we can close *this* STR. Thanks.
Link:
On 13.01.2011 21:40, Michael Sweet wrote:
Document the workaround (define FL_LIBRARY) and note that such code will
likely not be portable to future versions of FLTK.
That's a good idea, and I believe such a warning is in the docs anyway,
so we can surely go that route. OTOH, FL_LIBRARY is
On 13.01.2011 15:35, Brian Tilley wrote:
I've been having trouble with a Text Editor when attempting to look at files
containing around 330,000 bytes of text (7400 lines).
Basically, when I load the file it appears to load OK, but when displayed, I
don't seem to be able to scroll down to
On 13.01.2011 16:31, Greg Ercolano wrote:
Albrecht Schlosser wrote:
Wouldn't it be better to use (Fl_Widget *) or maybe better yet
(Fl_Text_Display *)?
I decided on void* cause I was torn which of the two to choose,
and being a maverick, I thought: neither! ;)
But yes
On 13.01.2011 16:41, Brian Tilley wrote:
The problem I have with upgrading, in the environment in which I work, is
that the entire application would need to be regression tested if I update
FLTK. (Our QA are not very trusting of this sort of update).
Would this also apply, if you patch only
On 13.01.2011 23:52, Greg Ercolano wrote:
Right. One thing you can do is make your application
/borederless/, and then draw the entire window border and buttons
and behavior yourself.
It will then be up to you to handle making the 'close' and 'iconify'
buttons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2515
Version: 1.3-current
Tested, and it works *somehow* (for some value of somehow ;-) ). Now, with
this version (r8259), I can type dead keys, but they show immediately
On 11.01.2011 10:21, MacArthur, Ian (SELEX GALILEO, UK) wrote:
One for Manolo I guess. Though... There is the bigger question of
whether Fl_X should be exposed or not.
What do folk think?
I'd say don't expose, because it's internal and can be changed.
If we really need to expose some of the
On 11.01.2011, at 18:15, Greg Ercolano wrote:
Albrecht Schlosser wrote:
Thus, we shouldn't bother to provide a main.html file, but rather
add a sample html page for the html viewer test (as Greg volunteered
to do already) and add appropriate browser links where needed.
Mike might have
I'm thinking of making the online docs version-specific, i.e.
instead of having
http://www.fltk.org/doc-1.3/index.html
we should probably have
http://www.fltk.org/doc-1.3.0/index.html
http://www.fltk.org/doc-1.3.1/index.html
...
Reasoning: The doxygen'erated HTML docs change their
On 10.01.2011 19:35, Boris Mayer-St-Onge wrote:
I did some test on Fedora 10 and 14 with current svn(8241). No major
problem.
Thanks.
Here are some suggestions:
1- When compiling fltk, at the end one have
=== making documentation ===
This making ... specifies the directory that is
On 11.01.2011 18:48, Greg Ercolano wrote:
Greg Ercolano wrote:
Michael Sweet wrote:
Would it make sense to provide a separate help file for FLUID, and then use
that as the test file for the help_viewer demo?
That sounds good, as I don't think the FLTK doxygen docs
cover fluid
On 11.01.2011 21:05, Albrecht Schlosser wrote:
On 10.01.2011 19:35, Boris Mayer-St-Onge wrote:
Also, there is 2 copyright in this page
with year 2010. Maybe change it to 2011?
Sigh. We just changed all copyright dates to 2010, but now it's already
2011. Time goes by... I'll see what I can
On 11.01.2011, at 09:48, Rainer Rinke wrote:
1. There is no �fltk.pdf� in the documentation subdir bundled with the
FLTK software, although it is announced in the README (as far as I
understood).
Thanks for the report, this is fixed now (svn r8256).
Your points 2. and 3. have been
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Just thought you should know that the file main.html is
missing from the RC3 documentation tarball.
Yes - this one is a puzzle to me:
- In the fltk-1.1 docs, the entry point was index.html.
- in the 1.3-rc2 tarball docs the entry point was
On 09.01.2011 18:10, nigo wrote:
The fix consists on calling SetProcessDPIAware() as soon as possible during program
initialization. It disables the fake dpi results and the built in
magnification so applications look sharp again and, smaller.
Thanks for the code. I tested this using the
On 09.01.2011 21:30, nigo wrote:
Your code works well on my PC with a 24 monitor at 1920x1080 and DPI
manually adjusted to 144. Here is the output of both codepaths:
D:\home\dpitest
set_show_dpi(81): size=14, scrollbar_size=16
set_show_dpi(95): size=14, scrollbar_size=16
Screen 0 ( 0,
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L1691
Version: 1.3.0
Fix Version: 1.3.0 (r8035)
Fixed in Subversion repository.
This is now a user setting in FLTK 1.3. The NORMAL_INPUT_MOVE macro is now
used as a shortcut for this user setting:
Fl::option(Fl::OPTION_ARROW_FOCUS).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1760
Version: 1.4-feature
Fix Version: 1.3.0 (r7816)
I consider this STR as solved. Please see also STR #2243 and #2199.
Top level menus in Fl_Menu_Bar require the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1760
Version: 1.3.0
Fix Version: 1.3.0 (r7816)
So I guess that we should modify line #345 in src/fl_shortcut.cxx to be
different on OS X?
#ifdef __APPLE__
if
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L1760
Version: 1.3.0
Fix Version: 1.3.0 (r7816)
Matt and Manolo: this STR is assigned to me, but since you are the Mac
experts, please feel free to take it and do the
On 07.01.2011 10:24, Manolo Gouy wrote:
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
Fix Version: 1.3.0 (r8208)
Fixed in Subversion repository.
Not yet... ;-)
We both missed an _important_ point. Currently we're converting
the string almost always
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
Fix Version: 1.3.0 (r8211)
For the record: the above-mentioned commit was in r8208.
Further improvement (removed double string conversion) in svn r 8211.
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
On 07.01.2011 10:24, Manolo Gouy wrote:
[part 2 to this question:]
Could Xft be processed under Cygwin as it is under X11 ?
That is, if one does, in fl_utf.c:
unsigned fl_utf8towc(const char* src, unsigned srclen,
wchar_t* dst, unsigned dstlen)
{
#if defined(WIN32)
On 07.01.2011 10:38, Matthias Melcher wrote:
I don't know much about X11 and much less about Xinerama, but I tried to get
the DPI code running on X yesterday, and all my virtual machines (3 Linux
variants) fell back to X11 (no Xinerama). After investigating a little more,
I found that
On 07.01.2011 14:23, MacArthur, Ian (SELEX GALILEO, UK) wrote:
A few new warnings being seen now on my win32 builds (Msys/mingw based
build...) that were not present a few days ago.
...
The next seems to be a side effect of the recent DPI stuff, I guess...
Compiling screen_xywh.cxx...
On 07.01.2011 13:34, Matthias Melcher wrote:
BTW.: I'm just fixing a bug WRT Xinerama and dpi for Cygwin/X11 or
maybe generally for X11: As it is on my system, configure finds
Xinerama, but it is not active with my X server configuration,
i.e. XineramaIsActive(fl_display) returns false...
I don't think that we currently have a clear documentation of
FLTK's usage of compiler, OS, and FLTK's own #define's.
Should I (we) try to write such docs, and where would be a useful
place? Maybe in the OS-specific documentation chapter ? Or in the
developer section?
Here are some first
On 07.01.2011 18:05, Brad wrote:
I am using Fl_Secret_Input to provide a field where users can type
password sentences. I have a Fl_Button named 'View Sentence' that allows
users to see (but not edit) the sentence they have typed. When they
click 'View Sentence', a fl_message displays the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2510
Version: 1.3-current
FWIW, here are some interesting links:
http://msdn.microsoft.com/en-us/library/ms682528%28v=vs.85%29.aspx
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3.0
Manolo, unfortunately your patch doesn't work on Windows with Cygwin/X11
(configure --enable-x11).
fl_utf8towc() does /not/ convert to an array of
On 06.01.2011 07:58, Michael Sweet wrote:
.PHONY: foo bar is a GNU extension, but fortunately is silently/safely
ignored by make programs that do not support it.
Thanks to you and all the others that replied. I got some
ideas to improve the Makefile. Let's see...
Albrecht
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2506
Version: 1.3-current
Fix Version: 1.3-current
Greg wrote regarding WIN32 vs. _WIN32: Hmm, I'm thinking example code
probably shouldn't assume special FLTK build
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2509
Version: -current
Link: http://www.fltk.org/str.php?L2509
Version: -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?L2509
Version: 1.3-current
This has probably been fixed in subversion rev. 8146 (2010-12-31), please
see STR #2501. If you have subversion, please use a newer version. If
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2510
Version: 1.3-current
I never realized that fluid -c doesn't run serially. Now that you say it,
yes it may be under Windows... I wonder how make works when generating
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2510
Version: 1.3-current
Well, thinking about fluid -c: fluid doesn't background itself when run
from a Cygwin shell and probably not in a MinGW shell (both are usually
I used .phony in documentation/Makefile to force generation
of the doc files manually independent of (not defined)
dependencies.
I couldn't find another example in our Makefiles and wonder
whether this is standard or a GNU make extension. I could
not find it on the web. Does anybody know?
If
On 05.01.2011 18:28, s...@sjssoftware.com wrote:
I used .phony in documentation/Makefile to force generation
of the doc files manually independent of (not defined)
dependencies.
Albrecht, is this what you're looking for?
http://www.gnu.org/software/automake/manual/make/Phony-Targets.html
On 05.01.2011 18:45, Duncan Gibson wrote:
You can probably get what you want by having a dependency on a
file that never exists:
...
Thanks, I partially did this already (see other reply: refman.pdf).
To be sure you can always do 'make clean dist', and this ought to
work as expected.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2506
Version: 1.3-current
Fix Version: 1.3-current
Greg, I saw that this demo uses _WIN32 instead of FLTK's define WIN32.
This should probably be corrected as well.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2504
Version: 1.3-current
The macros in CMake are identical to those used in configure.in etc.. It's
all the same for configuring the CMake build and fltk-config etc. as
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2505
Version: 1.3-current
Yes, I think that's right. The OP wrote: ... by doing a UTF-8 to
UCS-2/UCS-4 conversion, which has the side effect of filtering the
string.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2504
Version: 1.3-current
I vote for just changing the macro names (and all source files that use
them :-( ), and that's enough to close this STR.
Everything else must
On 04.01.2011 20:14, Matthias Melcher wrote:
On 04.01.2011, at 20:06, fltk-dev@easysw.com wrote:
Author: AlbrechtS
Date: 2011-01-04 11:06:02 -0800 (Tue, 04 Jan 2011)
New Revision: 8186
Log:
Fixed a typo and an error. We must not use make html-dist for distribution.
This Makefile tag is
On 04.01.2011 20:06, fltk-dev@easysw.com wrote:
Author: AlbrechtS
Date: 2011-01-04 11:06:02 -0800 (Tue, 04 Jan 2011)
New Revision: 8186
Log:
Fixed a typo and an error. We must not use make html-dist for distribution.
This Makefile tag is misleading and should be corrected.
To elaborate on
On 04.01.2011 20:44, Matthias Melcher wrote:
On 04.01.2011, at 20:32, Albrecht Schlosser wrote:
The correct way to generate the docs with current svn ought to be:
cd documentation
make clean pdf-dist
make clean html
For now: be careful...
Shall I try to clean up this mess?
Yes
On 01.01.2011 23:35, Matthias Melcher wrote:
On 01.01.2011, at 23:28, Kai-Uwe Behrmann wrote:
I get following error with fltk-1.3.0rc2-source.tar.gz :
...
Installing documentation files in /opt/local/share/doc/fltk ...
Installing fltk.pdf in /opt/local/share/doc/fltk ...
/usr/bin/install:
On 01.01.2011 01:21, Michael Sweet wrote:
Any objections to me updating libpng and libjpeg to the current versions for
FLTK 1.3? The current versions are a bit long in the tooth (libpng is
currently 1.4.5 vs. 1.2.40 and libjpeg is currently 8b vs. 6b) and are
missing some functions my
On 01.01.2011 05:42, fltk-dev@easysw.com wrote:
Author: matt
Date: 2010-12-31 20:42:56 -0800 (Fri, 31 Dec 2010)
New Revision: 8151
Log:
A bunch of documentation updates. Not sure if I found everything. The Unicode
section needs some love.
Modified:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2501
Version: 1.3-current
I can't reproduce this here. Neither with nor w/o X11, both compile and run
smoothly (svn r 8145, win 7, Cygwin 1.7.x). I tested Linux as well
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2501
Version: 1.3-current
I saw your latest message only after mine, so here is my Cygwin version for
comparison:
CYGWIN_NT-6.1-WOW64 mypc 1.7.7(0.230/5/3) 2010-08-31
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2500
Version: 1.3.0
I set the priority to 4 - High, because this probably should be fixed
before the final 1.3.0 release. AFAICT fltk.list.in is used by EPM to
create the
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2165
Version: 1.4-feature
I fixed about_panel.fl (only) by enlarging the boxes and the whole window
to accommodate the increased text sizes with XFT fonts. This is not
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2172
Version: 1.4-feature
I believe that this has been fixed for Fl_Input and friends. Greg?
Is Fl_Text_Editor still an issue?
Link: http://www.fltk.org/str.php?L2172
On 29.12.2010 05:00, fltk-dev@easysw.com wrote:
Author: mike
Date: 2010-12-28 20:00:52 -0800 (Tue, 28 Dec 2010)
New Revision: 586
Log:
Fix DOCTYPE ...
Modified: trunk/phplib/html.php
===
--- trunk/phplib/html.php
On 29.12.2010 16:18, Matthias Melcher wrote:
On 29.12.2010, at 13:24, Albrecht Schlosser wrote:
I downloaded and compared the newest fltk-1.3.0rc1-source.tar.gz, and
there seem to be some missing files.
...
RC2 looks okay now, thanks.
I checked again and found only these /expected/ results
On 30.12.2010 16:23, Michael Sweet wrote:
On Dec 30, 2010, at 8:19 AM, Albrecht Schlosser wrote:
print(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.0 Transitional//EN\
According tohttp://www.w3.org/QA/2002/04/valid-dtd-list.html
this should read ... HTML 4.01 Transitional
On 30.12.2010 12:07, Julia Jacobson wrote:
Building FLTK on Windows with Visual C++ worked fine for me.
However, I can only build a FLTK GUI project using CMake if I use absolute
PATHs in my CMakeLists.txt file, which looks like this:
SET(FLTK_DIR C:/Program Files/fltk-1.1.9/)
On 30.12.2010 19:15, Julia Jacobson wrote:
The main point would be to find out how FINDPACKAGE(FLTK ...) works
on Windows.
Once you found out how it works, you could maybe install your
built FLTK libs, dlls, header files so that FINDPACKAGE can find
them...
Yes, that was really the point.
On 28.12.2010 02:14, fltk-dev@easysw.com wrote:
Author: matt
Date: 2010-12-27 17:14:30 -0800 (Mon, 27 Dec 2010)
New Revision: 582
Log:
Slightly new scheme: all is compressed in tar.gz, and html and pdf are
uploaded separatley
+87aa8e940a25e4605d0d8d981f9f1ffd 1.3.0rc1
On 29.12.2010 16:18, Matthias Melcher wrote:
+1 for this packing scheme, as discussed previously in fltk.development.
How it is online now? As above? Or a different one?
As it is online now, or maybe also only one documentation file with
both HTML and PDF included. I personally don't know if
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2328
Version: 1.3.0
Fix Version: 1.3-current (r7830)
Fixed in 1.1.11 as well (r 8119), but fluid.desktop only (no README files).
Link: http://www.fltk.org/str.php?L2328
Version: 1.3.0
Fix Version: 1.3-current (r7830)
On 27.12.2010 16:38, Matthias Melcher wrote:
composing the FLTK 1.3 archive I saw that it doubled in size, because we
include the PDF documentation. Should we keep it that way? It's kind of
bulky, but the docs are right there for the developers... .
;-) First of all, it should be
On 27.12.2010 18:28, Matthias Melcher wrote:
Well, I knew that not everything would be 100% for RC1, so if you'd please
repack and commit it?
I put an updated PDF file in subversion, updated the dependencies,
and I also uploaded the current docs to the web site. I'll leave
packing rc2 to you,
On 27.12.2010 01:01, Greg Ercolano wrote:
Derek Prowse wrote:
I have all installed with Synaptic Package Manager, I didn't do
anything fancy, but I can't launch FLUID from Applications/Programming/ menu.
I get an 'Error' message box with this disheartening information.
I just tried
On 26.12.2010 19:12, Greg Ercolano wrote:
Opinions on automating the creation of the IMAGEFILES
via IMAGEFILES=$(shell find ..) vs. removing the macro completely?
+1 for removing.
I figure if automated it's no longer a maintenance issue, and
retain the dependency
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2479
Version: 1.3-current
Fix Version: 1.3-current (r8067)
Thanks for the correction concerning Mac OS X. I just tested on Windows
with a FLTK program that has a global
On 23.12.2010 15:24, fltk-dev@easysw.com wrote:
Author: manolo
Date: 2010-12-23 06:24:29 -0800 (Thu, 23 Dec 2010)
New Revision: 8113
Log:
Adopted use of FL_LIBRARY #define symbol under Mac OS X. This allows to
compile
client applications without including Mac OS system headers, ...
Fine,
On 23.12.2010 17:24, Manolo Gouy wrote:
I had to stop declaring fl_xid inline under OS X because the class
Fl_X is not part of the public API, whereas fl_xid() is.
This explains why I added fl_xid() to Fl_cocoa.mm.
okay, I see
The Fl::first_window() function is the single instance in all of
On 23.12.2010 16:37, Slick Dealer wrote:
However, if I
./configure --enable-cairo
and then
make
I get a cryptic error message saying -
Linking cairo_test...
/usr/bin/ld: cannot find -lpixman-1
collect2: ld returned 1 exit status
make[1]: *** [cairo_test] Error 1
make:
On 22.12.2010 08:34, Manolo Gouy wrote:
This FL_LIBRARY may be exactly what is needed to solve cleanly this
issue. But what exactly is it used for at this point ?
I see it set ONLY in src/CMakeLists.txt. Does it mean that not any
makefile use it ?
It would be useful for this issue if
801 - 900 of 2485 matches
Mail list logo