On 19.04.2010, at 13:22, Michael Surette wrote:
In general, I would prefer *not* to copy the FL directory instead, but
currently we would need the symlinks to stay compatible. OTOH, we're
thinking of removing the links anyway, and this will probably be done
before the 1.3 release (at least we
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2277
Version: 1.3-current
I like the idea of this patch, but I have some reservations about the
actual implementation;
I have not looked in enough detail yet (not at an
On 04/19/2010 08:11 AM, Albrecht Schlosser wrote:
On 19.04.2010, at 13:22, Michael Surette wrote:
In general, I would prefer *not* to copy the FL directory instead, but
currently we would need the symlinks to stay compatible. OTOH, we're
thinking of removing the links anyway, and this will
Author: manolo
Date: 2010-04-19 13:04:47 -0700 (Mon, 19 Apr 2010)
New Revision: 7533
Log:
Device hierarchy functional and documented.
Modified:
branches/branch-1.3-Fl_Printer/FL/Fl_Device.H
branches/branch-1.3-Fl_Printer/FL/Fl_PSfile_Device.H
Author: manolo
Date: 2010-04-19 13:33:18 -0700 (Mon, 19 Apr 2010)
New Revision: 7534
Log:
Doc clarification.
Modified:
branches/branch-1.3-Fl_Printer/FL/Fl_Device.H
Modified: branches/branch-1.3-Fl_Printer/FL/Fl_Device.H
===
---
Author: manolo
Date: 2010-04-19 13:35:25 -0700 (Mon, 19 Apr 2010)
New Revision: 7535
Log:
Updated doc archive
Modified:
branches/branch-1.3-Fl_Printer/doc/html.zip
Modified: branches/branch-1.3-Fl_Printer/doc/html.zip
===
(Binary
Author: engelsman
Date: 2010-04-19 14:15:30 -0700 (Mon, 19 Apr 2010)
New Revision: 7536
Log:
tweaked fl_wcwidth.c and mk_wcwidth.c to remove system wchar_t
commented out, or replaced, wchar_t with unsigned int.
commented out unused functions from mk_wcwidth.c.
Modified:
On 18.04.2010, at 08:06, manolo gouy wrote:
[Matthias wrote]
Fl_Plugin
|
+-- Fl_Device
|
+- Fl_Surface_Device
|| * points to a Window Manager
|| * points to possible Graphics Devices
||
|+- Fl_Screen_Device
|
Ian:
I was going to say that the wchar_t thing was likely to give us
problems on win32, but I see Albrecht already got there.
Yes, I didn't know whether to go for the typedef, or the #define.
As the scope of the latter is usually cited as one of the big
deficiencies of C/C++, I thought the
On 19.04.2010, at 10:19, Duncan Gibson wrote:
Ian:
I was going to say that the wchar_t thing was likely to give us
problems on win32, but I see Albrecht already got there.
Yes, I didn't know whether to go for the typedef, or the #define.
As the scope of the latter is usually cited as one of
Well I was hoping to be able to keep MK's code as vanilla as possible.
If we do need to change it, and it now looks like we do, we should
still make as few changes we can. I shall investigate this evening.
Indeed so - though my change is simply to s/wchar_t/unsigned long/g and
that's the
Me:
2. Although UTF-8 encoding allows for up to 32 bits per character by
using a 6-byte encoding, both the Unicode Consortium and ISO have
decided that they don't need that full range any more. IIRC they
only need 21 bits to represent all characters. So this is probably
the reason
The [text] above is based on some comments in the code, so I assume
that Roman or O'ksi'D or Bill or someone had some insight/analysis to
back this up. I don't have the multi-language / script experience to
be able to judge.
Sure - it just seems to me that if we code for a uint32_t, then we
On 19.04.2010, at 10:48, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Is it safe to assume that all toolchains now know what a uint32_t is?
If so, that would be my favourite option.
I don't know if it would be safe, but I don't see that we use it
anywhere, so this would be new.
I don't believe
Is it safe to assume that all toolchains now know what a
uint32_t is?
If so, that would be my favourite option.
I don't know if it would be safe, but I don't see that we use it
anywhere, so this would be new.
OK, then if not uint32_t, perhaps some other unsigned type that is at least
On Apr 19, 2010, at 1:19 AM, Duncan Gibson wrote:
Ian:
I was going to say that the wchar_t thing was likely to give us
problems on win32, but I see Albrecht already got there.
Yes, I didn't know whether to go for the typedef, or the #define.
As the scope of the latter is usually cited as
On 19.04.2010, at 14:48, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I don't believe that mk_wcwidth.c needs wchar_t at all, nor
should it
include wchar.h either.
Currently it's commented out (#if 0), thus we know that it is not
needed.
Though I think that is only because Duncan has wrapped
Ian:
I don't believe that mk_wcwidth.c needs wchar_t at all, nor
should it include wchar.h either.
Albrecht:
Currently it's commented out (#if 0), thus we know that it is not
needed.
Ian:
Though I think that is only because Duncan has wrapped mk_wcwidth
inside fl_wcwidth which does set a
I have to admit that I'm
always a little unhappy about including .c files because it confuses
anyone looking at how the system is built.
Though as a technique it is widely used in the fltk code base, to handle
cross-platform builds and so forth. I don't see it as a problem here.
As it looks
Hi developers,
I have prepared in development branch-1.3-Fl_Printer a new device hierarchy
according to the idea suggested by Matt. It's as follows, starting from Matt's
own description:
Fl_Device
|
+- Fl_Surface_Device
|| * points to a Window Manager (not
Dear All,
Now, if push on the button widget, the button will in a pushed status, but I do
not want this pushed status. That's means I do not want the button has any
change if I pushed on it. Is there any method to implement it? Thanks.
my fltk is v2.0
Best regards,
Leo Wang
21 matches
Mail list logo
