DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
The existing Doxyfile script (at the root of the distrib) is the starting
point.
The first increment consists of extracting the current hmtl doc
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
Only 4 work packages? How many files are in each package?
Sounds like each one will be an awful lot of work to take on, and you will
be limited
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
It will not start before we get some ack and strategy confirmation from
Matt, after his utf8 merge anyway. I thought it would be nice already if
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
The smaller the packages, the better. Even one file would be a good
package size. IMHO, we can find more volunteers, if the work for one
package
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2037
Version: 1.3-current
1: I suggest ten to fifteen little blocks, reducing the amount of work per
block. Another block can be started later if there is time.
2: OK,
Author: AlbrechtS
Date: 2008-09-10 00:59:53 -0700 (Wed, 10 Sep 2008)
New Revision: 6204
Log:
updated Doxyfile (doxygen -u) to version 1.5.5, as suggested by Matt.
ToDo: this added DOXYFILE_ENCODING = UTF-8 (among others) and removed
USE_WINDOWS_ENCODING = NO. If that's not correct, it chould be
Author: spitzak
Date: 2008-09-10 09:11:42 -0700 (Wed, 10 Sep 2008)
New Revision: 509
Log:
Fixed date for docs link
Modified:
trunk/documentation.php
Modified: trunk/documentation.php
===
--- trunk/documentation.php
Author: matt
Date: 2008-09-10 15:11:01 -0700 (Wed, 10 Sep 2008)
New Revision: 6209
Log:
Compiler output must have path information.
Modified:
branches/branch-1.3-utf8/makeinclude.in
Modified: branches/branch-1.3-utf8/makeinclude.in
Author: matt
Date: 2008-09-10 16:00:51 -0700 (Wed, 10 Sep 2008)
New Revision: 6210
Log:
utf8 support on VC6 kind of works. We would have to link to imm32.lib at
compile time. However since we use very few functions, and imm32 is not alweays
available, I consider run-time linking.
Added:
Author: matt
Date: 2008-09-10 16:18:08 -0700 (Wed, 10 Sep 2008)
New Revision: 6211
Log:
Added utf8 test code to the VC2005 IDE setup and added support files to
libraries.
Added:
branches/branch-1.3-utf8/vc2005/utf8.vcproj
Modified:
branches/branch-1.3-utf8/vc2005/fltk.lib.vcproj
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
I tested Greg E's scroll window. It does resize only in one direction
(enlarging). Making the window smaller is not possible. Many examples in
the FLTK's ./test folder dont work like help view, fluid and filebrowser.
It is really confusing to read about complicated things like deriving fom
I tested Greg E's scroll window. It does resize only in one direction
(enlarging). Making the window smaller is not possible. Many
examples in
the FLTK's ./test folder dont work like help view, fluid and
filebrowser.
It is really confusing to read about complicated things like
Kai-Uwe Behrmann wrote:
About the system: IA32 Linux, Xorg7.2 + nvidia twinview, fvwm2, resize
After I read your second post I immediately thought of fvwm and now you
confirmed my suspicion. This issue made me switch to icewm (after nearly
10 years of using fvwm).
AFAIR one workaround was
imacarthur wrote:
Gents,
I've never really used Fl_Scroll much, the data I've been rendering
never seemed to lend themselves to it so I've always just created my own
scrolling area using Fl_Scrollbar and some work in the draw method.
However, this evening I thought I had a problem that
imacarthur wrote:
So... what I want is a drawing area that resizes horizontally as I
drag the window (there is no horizontal scrollbar). As the image
reflows horizontally, the vertical dimension will change, so a
vertical scrollbar might appear/disappear at some point, and size/
33 matches
Mail list logo
