maybe someone else can remember why we did it this way...
Oh buy, this code is over 10 years old. I can barely remember
what I had for lunch yesterday ;-)
If a window is fully off screen, we should probably loop
through all available screens and find the one that is
closest to the
Hah, I got it!
Oh yes - good stuff: and that ties in with Consul the OP's observation
in
http://www.fltk.org/newsgroups.php?gfltk.development+v:12583
that setting num_screens to zero fixes the issue, too...
So I guess we are in the right area. Do we need a work_xywh() function
for this one,
However, I won't have much time until next week or even later :-(
Any help would be appreciated. If you'd like to continue my
investigations, feel free to do so, but please drop a note here
(or file an STR please) so that we don't do it in parallel. I don't
think that I can find the time
Hah, I got it!
Oh yes - good stuff: and that ties in with Consul the
OP's observation
in
http://www.fltk.org/newsgroups.php?gfltk.development+v:12583
that setting num_screens to zero fixes the issue, too...
Yes, maybe, as a side effect, but you knew that since you wrote
Well, it is the same now in 1.3 and 3.0. I had at first set
it to 0, but fixed it to -1 when I saw it was set to -1 in 1.3.
But you are right, this could very well be the bug! I have no
MSWindows machine near ATM. Could somebody please test this?
I played with this some more (after
1. When you create a window, the properties window will
appear on the top left corner of the desktop without the title bar,
making the window unmovable.
Yes, I saw that when I finally tested on MS Windows. I was
very surprised and I wonder if 1.3 does that, too. Or if it
is specific
Though once fltk-1.3 is broken, it stays broken until I
quit and restart it, whereas once I shows a good properties
window it tends to stay fixed.
I hazard that there's an initialization issue - something is
not setting a root or parent correctly or something, and once
it is set it
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...
(The page maybe needs updated a bit, BTW? Copyright says 2009, and the
download button references 102.42a9c event though
Ah, thanks. I was using exception to verify my code. Now
should I enable them for fltk3, or should I remove the
try-catch-throw?
I see Ben's already answered in favour of exceptions, but I have to say
that (at least for the core library) I'm not in favour. (Though, like
the STL, I have no
What are you implying? FLTK 3 has bugs? How very dare you :-P
No comment. ;-)
I can't tell if it has bugs or not - I can't get it to build! ;-)
(Sorry, just joking...)
I see Ben says They're portable (except perhaps to some
really obscure
Yup - though that's not one of my targets, the decision not to
support
exceptions is one that many embedded systems make. I'd hazard
that the
choice represented best practice and was probably correct at
the time.
Whether we agree with it, or consider it the
I suggest to use the print support capability of 1.3 in fluid
(and also to use Fl_Native_File_Chooser). I enclose here the
patch file for that. This renders file fluid/print_panel.cxx useless.
Is this OK ?
Hi Manolo,
I think this is a great idea.
This will presumably also enable print
I'll be happy to support FLTK3 on Android NDK as well as I
can. It brings us to the next modernization issue though.
Many of our widgets are not touch-screen friendly at all... .
UI element designers! To your arms!
We've been using fltk with touch screens for years here.
It works OK.
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.
Yes, I think so...
I'm not sure what to write or I'd write it.
Hmm, nor do I.
Looks like documenation/src/osissues.dox is
Matt,
Here's a new one: this is winxx/mingw, though I think I saw this on OSX
too (I was not paying attention as the script ran...)
=== making fluid ===
Compiling CodeEditor.cxx...
In file included from CodeEditor.h:41,
from CodeEditor.cxx:36:
../fltk3/TextEditor.h:46:
So, I want to draw some text rotated 90 degrees. There's fl_rotate,
but the documentation also says whether fl_draw is affected is
implementation defined. And sure enough, on OS X, it's not.
Evan, are you using fltk-1.3?
If so (I think you are?) then it may not be that hard.
The fltk-1.3
Matt,
Are you interested in build logs of fltk3 on various platforms?
Or would that just be more unnecessary noise at this stage?
I have logs of building on winXP with mingw, for example, that show a
fair few warnings about trivia that we'd need to fix *at some point*,
but which probably do not
All,
Can anybody see the web page for the Developer Roadmap properly?
I was updating a few STR's, and now the page is trashed (don't think it
is a cache issue between me and the server, but you never know.)
Or maybe I broke something? (If so, sorry...)
--
Ian
SELEX Galileo Ltd
Registered
Or maybe I broke something? (If so, sorry...)
2686 and 2689 have produced empty output in the log and can
not be viewed anymore. What did you change? Maybe we can un-change it?
It's maybe some sort of circular reference?
They are the same bug AFAICT,and I was trying to set the
2-to-3: This compatibility layer has not been touched. I have
created a few prerequisites and test2/hell.cxx does compile,
hell.cxx - is that a typo, or an expectation that it will be hard?
but nothing beynd that yet.
Oh, I see, the 'o' on your keyboard is suspect... ;-)
SELEX
Oh, I remember another (maybe related?) issue when I tried to *reset*
the duplicate field recently. The update failed with the message
Unable to save STR!
See my post on Jul 20, 2011 to STR #2490
http://www.fltk.org/str.php?L2490
Yes I remember you having trouble with that.
But I
Okay then, on Linux we have a real error. Here's the full error
message:
Oh - I built this just a few days ago on a 32-bit ubuntu VM hosted on my
mac and it went fine (I think!) so that must be fairly recent...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road,
All,
I've added a #warning to the scandir.c sources, in the hope of identify
which, if any, hosts actually use this code (see STR 2687) that *might*
not be compatible with the fltk license.
I haven't found any users, but...
NOTE: The warning will only trigger if the host compiler is gcc, so
I do not know whether there are other serious fltk2 users.
Ben is doing work on fltk2 now, so you need to liaise with him...
So, I am trying to apply developer status for fltk2 here
again. Yes, I applied multiple times before, but I had never
gotten feedback.
Bit of a catch-22
Could you please test with svn releases pre-8866 (STR #2680) and
if that doesn't solve it with pre-8639 (STR #2613)? I'm short of
time, otherwise I'd do it. Thanks.
Testing:
r8860 - broken
r8630 - OK
Thanks.
So I guess that means it broke somewhere between 8630 and
Ian, I saw you commit in svn r 8911, which is effectively a one-liner,
but obviously something in your editor setup (or a habit of yours) is
removing trailing white space from source files, and this is not the
only (first) commit affected by this.
Argh, bother. Sorry. Looks like I'm having a
I'm running it on Win7 here, and thanks to Win7's semi-transparent
task bar I can see that the menu is *drawn* behind the task bar in
both cases (1.1 and 1.3), so I would say that it is clipped at the
screen border.
However, srolling starts near the task bar in fltk 1.1, and the
Albrechts,
I've raised STR #2695 for this one...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
This email and
Matt,
I've been following along at home your work on fltk3 - is it possible
for you to #include stdint.h in workspace_panel.cxx please?
It chokes for me on win32 hosts with:
Compiling workspace_panel.cxx...
workspace_panel.cxx: In member function `void
Thanks for following this and trying to compile it! I just
checked in the change. Sorry it got swallowed (I wonder why,
but with the amount of code changes ATM, I guess that can happen).
Doh! I know why...
I had not noticed that workspace_panel is fluid generated, so I changed
the C++
All,
I have some code with an unreasonably long menu item in it (i.e. too big
for the screen).
Compiled under fltk-1.1 the menu scrolls as the mouse reaches the
top/bottom edge, allowing the full menu to be accessed.
Under fltk-1.3 the same code does not scroll.
Setting aside the UX failure
Could you please test with svn releases pre-8866 (STR #2680) and
if that doesn't solve it with pre-8639 (STR #2613)? I'm short of
time, otherwise I'd do it. Thanks.
Testing:
r8860 - broken
r8630 - OK
So I guess that means it broke somewhere between 8630 and 8860, and that
perhaps the fix
Have you seen this post over in fltk.opengl?
http://www.fltk.org/newsgroups.php?gfltk.opengl+v:1461
This looks like something you might understand better than I do!
Unfortunately, I know nothing about OpenGL, so I can't debug that.
Could anyone who knows OpenGL help? The issue
My concern (as a commercial developer that releases
static builds) is not whether the code is used,
but that it's in the lib at all.
True: if the code is not called, it shouldn't
appear in the linked executables by optimization.
And legally I imagine
These sound like useful additions to me...
A few questions:
a) Does (1) break the ABI (by changing the return value
from void to int)?
I think it does, but I am usually wrong about ABI stuff..
Pretty sure the others would have no impact.
I think adding new methods is OK. (But
Suggest we comment out the file and see what happens.
To prevent having to modify all the Makefile/VS files,
I'd recommend we just change the file to be a one line comment
that says '// Removed due to non-LGPL/static license. See
STR# . Original in svn r.'
and
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 taken
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.
Hmm, that's odd, I'd
AFAICT that would be the only case where this code came
into play, i.e.
on non-WinXX host for which configure could not locate a scandir
implementation at build time...
Yep, I believe this is true. There is an exception for SunOS that
disables the system scandir function explicitly,
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.
Bother.
Did it choke because we *need* the file, or just
Why the fltk app appears correct on OSX I am not sure - it
may be that the Apple text renderer under Quartz is fixing
things for us, which I find unexpected.
Ah, this is a right-to-left script?!
Um, no, I do not think it is, though I do not know for sure. I think the
Indic scripts
Little addendum:
I just tested nitin's example code on a WinXP box (albeit one with complex text
handling enabled, which is *not* the default for LGC Windows systems, though it
is enabled by default for Asian systems I think) and it seems to be displaying
the text correctly. IIRC the CTL was
Mike said:
FWIW, I would actually prefer that FLTK handles the conversion to
display
order (as needed) since otherwise you end up with every Unicode app
re-implementing the same damn code, and all of the other
(mainstream/popular) GUI toolkits handle this for the developer as
well.
This is
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
Attached file enumerations.h...
Link: http://www.fltk.org/str.php?L1725
Version: 2.0-feature
Fix
Wouldn't it be better to have a direct (complete) link?
// http://www.fltk.org/COPYING.php;.
...snipped...
Oh yes, if that's allowed, then that seems like it would be better.
And while I remember, do we want to update COPYING.php to remove the
reference to fltk-b...@fltk.org and instead
As we all know, FLTK has its own static link exception
in our license file included with the toolkit (COPYING).
However, of *possible* confusion:
The headers in all our source files refer to the raw LGPL
from gnu.org, which *might* be a point of confusion,
since IIRC
is there anyway to port fltk2 for wince??
I motify some code but it still have much errors
Anyone have a source code that finished port to fltk2?
Why are you using fltk2? It is unstable, alpha and currently deprecated
for new users. I would strongly urge you not to use fltk2 for any
critical
Fl::set_font(FL_SYMBOL, Lohit Hindi); but it now show well
The Symbol font does normally not contain text characters,
but only graphics characters.
Nah, he's just pulling a trick I often use myself in my code - he's
effectively over writing the FL_SYMBOL font entry (which I never use
Random thought:
Here's a thing - Canonical's new Unity desktop for ubuntu places the app
menu bar at the top of the screen, a la OSX, for those apps that support
it.
Two questions;
1) Do we want to tweak Fl_Sys_Menu_Bar to support that behaviour, as it
does for OSX?
2) If so, then does anyone
On winXP with Msys/mingw the fluid1 build fails (the build of the fltk3
fluid is fine however.)
This problem seems to be WinXX related, so not specifically a mingw
feature I think.
Here's the failure:
=== making fluid1 ===
:
Compiling fluid.cxx...
fluid.cxx: In function `void
All,
The fltk3 test/makedepend file appears to be humped in svn again, with a
recurrence of the references to Preferences.h rather than to
../fltk3/Preferences.h problem that we saw before.
Or maybe that's just for me? It certainly looks wrong - but are others
finding it works OK?
(NOTE: just
On Jul 9, 2011, at 5:43 PM, Ian MacArthur wrote:
...
I may be going off at a slight tangent here, but it
occurs to me that there are two sides to to making the examples folder
build under fltk3;
a) tweak the examples to be
Link: http://www.fltk.org/str.php?L2666
Version: 1.4-feature
Fix Version: 1.3-current (r8852)
Fixed in Subversion repository.
The NSHumanReadableCopyright key of Info.plist will be used
if present.
This sounds quite handy to me, but I seldom use Xcode, so I have a tool
to generate
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?
Fine by me - I quite like the look of it - though the later versions
were maybe a bit too curved for my taste... V3 was OK I guess.
We do need to
Hmm, I thought you referred to your edit in r 8835 in
test1/makedepend:
-unittests.o: ../fltk3/Plugin.h Preferences.h ../FL/Fl_Preferences.H
+unittests.o: ../fltk3/Plugin.h ../FL/Fl_Preferences.H
*This* removed Preferences.h dependency was on test1/Preferences.h,
Not quite - the
BTW: I included preferences.cxx/.h because FLTK3 Fluid at the
moment would write a mishmashed FLTK3 cxx/h pair. In an
effort to generate the FLTK3 FileChooser UI from the .fl
file, I forgot that an FLTK1 .fl file should still generate
FLTK1 code, and an F3 .fl file should generate F3
Here there is the modified version of fl_gleam. I think it
looks better
with the gradients on the top and the bottom, so the the
middle area of
the widgets it is no strongly affected. Here an screen shot:
https://sites.google.com/site/eetorres/fl_gleam
The new gleam can be found
Just refreshed my fltk3 snapshot - fails with the following errors.
(NOTE: I don't think I've ever seen one of those errors before, now we
have several!)
Compiling Fl_File_Chooser2.cxx...
Fl_File_Chooser2.cxx: In member function `void
fltk3::FileChooser::fileNameCB()':
Fl_File_Chooser2.cxx:870:
What I'd suggest doing is simply explicitly casting the first
parameter
to a char*; this _should_ fix your issue (at least it doesn't
create any
on gcc under Ubuntu 10.10).
I suspect the only person who could confirm such a fix would be Ian,
though
Yes, that does work, e.g:
// fltk3::alert(%s,existing_file_label); // error
fltk3::alert((char*)%s,existing_file_label); // ok
Though I have concerns about casting a fixed string like
that just to
trick the compiler into doing the obvious conversion.
From what I understand of the mechanics
No need to fiddle something. The va_list version is only
there to support the sealers and would be rarely used by an
app developer. Somewhat like fprint vs vfprint. All we need
to do is rename the second fltk3::alert to fltk3::va_alert
and the ambiguity is gone. It's interesting that
Ahrgh. Go into the fltk directory and run make depend. I
keep forgetting to do that before I run svn commit and
after make clean.
The makedepend file appears to be configured - so I just hand edited it
to fix the one typo and commited that, it then seems to work just fine
right up until
The header file Fl_Font.H has always been in the src/ folder, rather
than in FL/ since it provides private low-level stuff about the
platform specific font handling.
But, on the other hand, when I am manipulating fonts, it's very handy to
get access to that stuff, so I generally just include it
svn r8758 compiled with a few warnings on Windows with MinGW,
except test/threads.cxx.
Wow, well done !
Indeed so. Very neat indeed.
Also, the failure to compile threads.cxx looks like it might be
interesting too... I wonder if this is a mingw issue, or general
win32 issue?
Looks to be
Also, the failure to compile threads.cxx looks like it might
be interesting too... I wonder if this is a mingw issue, or
general win32 issue?
Looks to be some sort of typedef clash, but I can't
immediately see exactly what...
Note that explicitly including windows.h before we include
Looking in my copy of wtypes.h, at line 141 I actually have:
typedef double DOUBLE;
This appears to be getting expanded at compile time as:
typedef double fltk3::DOUBLE;
Which then clashes with the definition fltk3::Mode
fltk3::DOUBLE in our enumerations.h.
So - I
Moving those #include out of the namespace{} and all seems
to compile just fine...
Yep, that works.
Yes - not the tidiest looking change, but does the Right Thing.
Congratulation, you're now a fltk3 developer! ;-)
Well, *technically*, I think I was anyway, as I changed a few minor
Matt,
Your work on fltk3 - which hosts are you looking at with your current
work, i.e. is it expected to work on won32 right now?
(Loaded question, since I just tried a build and it choked.)
=== making src ===
Compiling Fl.cxx...
In file included from ../fltk3/x.h:50,
from
One solution would be to link additionally with fltk.lib, so
that the same
applies as with our FLTK project test programs: they pull
WinMain() from
the static lib. I don't know whether this is good style,
however, since it
could come to ambiguities...
I can't vouch for the MS linker,
I have never had problems with the DLL and mingw (Though I
do not use it
all that much now.)
Have I just been lucky, or is it actually different in this respect?
I *believe* yes. I think that the MinGW runtime doesn't call WinMain()
at program initialization, but calls main()
All,
One of my trees builds fltk-1.3 from svn, with the --enable-cairo option
selected.
It is currently failing to build on win32/mingw with the following
errors:
$ make
=== making src ===
Compiling Fl.cxx...
Fl.cxx:41:1: warning: WINVER redefined
In file included from
Please try this patch instead:
No, that does not work. I just get:
=== making src ===
Compiling Fl.cxx...
In file included from Fl.cxx:1709:
Fl_win32.cxx:754: error: `VK_BROWSER_BACK' was not declared in this
scope
Fl_win32.cxx:755: error: `VK_BROWSER_FORWARD' was not declared in this
scope
I'd appreciate if you could just do both of it, including the
_WIN32_WINNT definition (and maybe fixing the other occurrences, too)?
I have two more STR's (2632 and 2637) that I want to
fix/finish tonight before Matt can do RC6.
OK, I've pushed a mod to Fl.cxx and fl_font.cxx that I think
... the intent is that the programmer explicitly provide a
button to dismiss the widget; it's a usability guidelines
sort of a thing.
Though note that, unless you over-ride the default window
callback, you can always dismiss any fltk window by hitting
ESC anyway...
It seems to me
Matt,
Just FYI.
My scheduled svn update says that you (presumably accidentaly) have
checked in some auto-generated files into the fltk3 repo., specifically
configure, makeinclude, config.log, etc...
--
Ian
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon,
Just FYI.
My scheduled svn update says that you (presumably accidentaly) have
checked in some auto-generated files into the fltk3 repo.,
specifically
configure, makeinclude, config.log, etc...
Thanks, yes, weird! I saw that yesterday and I assume I had a
typo when adding another
Ok, the exact thing on what to do is yet unclear ...
Agree!
Please be aware that until now, the application
just 'hangs' waiting on events for windows that don't exist anymore.
I do believe such situation would be reported when it happens. Since
no reports exist, I conclude that most
almost. You should read: 'noone is using applications that do
XDestroyWindow'
Um, my problem is that I'm not sure *other* apps are even permitted to
call XDestroyWindow() on your app's window, and from a fltk app, if we
choose to close the window internally it all works OK.
So my concern is
Manolo has added:
r8653 | manolo | 2011-05-11 19:09:43 +0100 (Wed, 11 May 2011) | 3 lines
On Mac OS, FL_HIDE is now sent when a window is minimized or the
application is hidden.
The context removal on Fl_Gl_Window::handle()
Well, it was empty, for about 30 seconds...
Currently standing at 3 bugs and an RFE, though 1 of the bugs is maybe
fixed already, two may be cannot reproduce and the RFE I don't think
we need at this stage...
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon,
OK - think I have this fixed now. Try the svn r8644 and see
how that goes.
Yep, this fixes it. I'm glad that you could find it. This was such a
subtle bug that happened only under certain circumstances...
Great work, thanks!
I was just tidying up the mess I left behind...
SELEX
So if you want to make a simple little .exe that can be dropped
on a file server and invoked by numerous workstations without
running 'an installer' on each machine, is it possible?
Yes, use MinGW. Seriously. At least for FLTK programs this is a
good alternative, but
Hi everyone, I have have a little problem.I want to show a
vtk console window resulting from interactor-start(); in a
Fl_Window. Plese can you tell me how i can do it. Tell me the
problem in following Program.
You'll need to show us something simpler that manifests your error - I
don't
Question to all developers: would it be okay to update the online
docs NOW (means: in the short term, when I can find the needed time),
or is anybody planning doc updates before the next release?
(I don't want to update the online docs too often because of
the included doxygen version
OT here in fltk.general
To Ian: it's your code, and it compiles well with the /broken/ MinGW
wingdi.h, but not with Visual C++ (STR #2623) and the
corrected mingw64
header files. If you have a better idea than an autoconf
feature test,
please give a comment on STR #2622. Thanks.
/OT
It now *appears* that we can set that to NULL if we are not
using it,
and that might appease all the different compiler versions.
Yes, I noticed that it wasn't used at all, but I didn't know whether
it could be set to NULL or not. I looked at my (VS 2008/2010)
docs, and
I didn't find
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. is_opened()
is_close() vs. is_closed()
is_select() vs. is_selected()
is_open()
- But does not address the equivalent problem in:
void Fl_GDI_Graphics_Driver::draw(int angle, const char*
str); that uses a similar but different approach.
Actually, the easy fix for that method might be to *not*
use fl_utf8decode() at all but only to use fl_utf8toUtf16()
and
On Mac OS, with the editor demo and the character palette, one
can enter and display musical characters correctly.
The ::width() code expressly handles surrogate pairs with its
surrogate_width() function, so I believe it should measure
surrogate-containing text correctly, and that's what
In r. 8569, Fl_Quartz_Graphics_Driver::width(unsigned int wc)
is modified to handle properly wc 0x.
Yes - see that.
Do we need to think about adding a one gyph UCS-UTF16 function?
I mean, rather than calling fl_utf8encode() then fl_utf8toUtf16() to do
the job.
It would probably make
Hmm, well, my test code (including the simple version I just
posted) *is* now working on this Vista box, with my proposed
changes applied.
Argh!
Well, back at work, with a WinXP box, and the changes that worked so
well on my Vista laptop at home Do Not Work on XP.
- It only fixes the
Hmm, well, my test code (including the simple version I just
posted) *is* now working on this Vista box, with my proposed
changes applied.
And so it is on Win7, with and w/o the latest svn commit (r8570).
Thanks Albrecht - that confirms what I saw on Vista. Good to have the
feedback.
I believe Fl_Quartz_Graphics_Driver::width(unsigned int wc)
is very seldom used because in most situations, one has to measure
a string and not a single character. In FLTK, it's used only in
Fl_Help_View to measure the space character.
If conversion from a single UTF32 character to UTF16
It very much looks as if the rendering of Unicode values from the
bigger numbers is broken on win32.
The code in fl_font_win32.cxx for handling the ::draw() mechanisms seems
to be assuming that any UTF8 encoded char can be represented by 1 win32
WCHAR, but of course this is not true, since the
If you could provide a short example program including some of
the glyphs (maybe U+1D160 - U+1D164) I could patch my FLTK lib
and give it a try on Win7. Other than that, the patch looks
plausible, and I don't know what else to do.
BTW: I'm looking at
Thanks Albrecht,
This ought to show U+1D160 - U+1D164 and U+D160 - U+D164 for
comparison
in the 2nd row. I did NOT load any fonts for this test, since Win7
seems to do a good job w/o it anyway. The 2nd row shows what is to be
expected with the old code, and indeed, I can see two identical
Gah! Something really obvious just struck me, that I should have noticed
ages ago...
It's not handling the surrogate pairs, even though they look right to
me.
So, if I have (say) 5 glyphs, all surrogate pairs, it is rendering 10
unknown glyph boxes rather than just 5, so it must be trying to
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.
Fltk-1.3 is the active branch and is more up-to-date and certainly less
buggy than fltk2 in most cases.
Fltk-1.1
But the main reason is that Xcode 4 compiles for 10.6 only
(at least out of the box), whereas Xcode 3 comes with the
10.5 SDK as well. So if one targets SOX 10.5 or even lower,
additional downloads of SDKs would be required.
What do you think?
Also, Xc4 will not build PPC binaries for
I'd say center the first time it is shown, then leave it
along afterwards...
On Mar 23, 2011, at 4:36 PM, Greg Ercolano wrote:
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
101 - 200 of 668 matches
Mail list logo
