matthiasm wrote:
...
1: go strictly with our patch, remove duplicates, and clean up our
API
2: use the already clean GLib API and hook that up with the guts from
the patch
3: extract the unicode from GLib and replace code from the patch (but
GLib is LGPL, FLTK is modified LGPL, so I am
matthiasm wrote:
I was very excited yesterday to see the first Japanese characters on
my FLTK-for-OSX yesterday and I beleive that we are on a good path.
I'd be happy to test your build with my commercial app in Japanese.
OSX has been the one platform I haven't yet been able
Albrecht Schlosser wrote:
I just wondered, why the two commits -r 6196 and 6199 to branch
fltk-1.3-utf8 didn't appear in fltk.commit.
Is this a bug, or is it, because they are too big ?
Or both ? ;-)
Or do others see them ?
sorry for replying to myself: I just checked the message ids,
OK, so I have no problem with using glib with Pango and X11/Cairo,
however glib isn't fast or light or standard outside Linux/Solaris,
so I wouldn't want to make it a dependency on other platforms. In
particular, glib on Windows still has a lot of issues...
Indeed so, and for simply
Thanks for all the suggestions. I will use a combination of 1 and 2
then. I merge the code base with the patch (done), then make all the
IDEs and Makefiles work that I can test (Linux, OSX, Xcode,
VC6, VC7,
VC8) and merge back into the trunk.
Outstanding! That was really quick...
I'd be happy to test your build with my commercial app
in Japanese.
OSX has been the one platform I haven't yet been able to run in
Japanese mode.
What! My dirty hack wasn't good enough for you then? ;-)
Cheers Greg,
--
Ian
SELEX Sensors and Airborne Systems
Here is an improved version of my patch. This one also handles
keyboard input, as the old version did (at least I could test
Page up/down, pos1, end).
It's still work in progress, however.
Albrecht
Index: FL/Fl_Scroll.H
===
---
Please Matt confirm that it's ok, so that I open an STR and start the job
asap.
After the utf8 work is merged of course.
Thanks,
Fabien
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Fabien Costantini wrote:
fltk.development
Ok, If we agree that we put the the api comments in the sources cxx files
I apologise for butting in here, but I'm not sure if this has been
addressed. If the doxygen comments are in the source files, then a user who
installed FLTK via RPMs (e.g.
Fabien Costantini wrote:
fltk.development
Ok, If we agree that we put the the api comments in the sources cxx files
I apologise for butting in here, but I'm not sure if this has been
addressed. If the doxygen comments are in the source files, then a user who
installed FLTK via RPMs (e.g.
On 10.09.2008, at 09:45, MacArthur, Ian (SELEX GALILEO, UK) wrote:
FWIW, iconv is the usual API on Linux/UNIX systems to do character
set conversions, and Windows has its own multibyte functions - I'd
rather use those than glib, if we are going to pull in another
library...
If I understand
Understanding more and more about languages, script, glyphs, fonts,
and layouts, I realize that we can never produce a perfect UTF8
support. So let's keep it fast and light and allow rendering of all
fonts and simple text input. The existing code base is just fine for
that.
Yup - I
If you have a modification which effects more than one file
should you submit multiple patch files, ie one for each file
modified, or should it be in one big patch file?
I don't think there's a clear policy on this - either way works, as long
as the patch files are clearly indicated in the
If you have a modification which effects more than one file should
you submit multiple patch files, ie one for each file modified, or
should it be in one big patch file?
What I have done in the past for the couple of patches I've made,
and nobody complained about it, was to:
1. checkout the
On 10.09.2008, at 14:52, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Editing complex scripts is *hard*
Trivia:
Reading through various documentation, my own language, German, has
several pitfalls I was not aware of. Converting the word measurments
in German from lower to upper case is a
Alvin wrote:
Fabien Costantini wrote:
fltk.development
Ok, If we agree that we put the the api comments in the sources cxx files
I apologise for butting in here, but I'm not sure if this has been
addressed. If the doxygen comments are in the source files, then a user
who installed FLTK
On 10.09.2008, at 21:20, Yuri wrote:
OK, so I have no problem with using glib with Pango and X11/Cairo,
however glib isn't fast or light or standard outside Linux/Solaris,
so I wouldn't want to make it a dependency on other platforms. In
particular, glib on Windows still has a lot of
Allrighty, I decided to release the utf8 patch into the Wild (in this
case, into the Trunk of the SVN).
This means that the Doxygen developers can go forward now and move the
documentation over.
But this also means that this particular SVN version of FLTK 1.3 is
very buggy! Here are a
18 matches
Mail list logo