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_Scre
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 typ
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
> 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 wh
> That said, this is IMHO a hack that doesn't make the code transparent
> for readers: who would know that mk_wcwidth.c is only included in
> another c file, and that *this* file defines wchar_t to be something
> completely different, if he sees only mk_wcwidth.c ?
>
> Thus, I agree with Ian: sin
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
>>t
> 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
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 believ
> > 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
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 ci
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 Dun
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 d
> 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 lo
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 implement
14 matches
Mail list logo
