> I would suggest to add a declaration of fl_old_shortcut()
> in file FL/fl_draw.H This should make it seen by Doxygen.
>From what I remember of the great doxyfication last year, there
are quite a few functions that are documented in "unexpected"
places. This is especially true for the functions
> I'm trying to strengthen the docs on shortcut specifications,
> and am finding there's contradicting behavior with casing of
> the keyboard codes. (There's already an STR about this)
>
> What is the /intended/ behavior for shortcuts like:
>
> 'a' -- Should only lowercase 'a' trigger s
On Wed, Apr 14, 2010 at 02:40:21AM +0400, Nikita Egorov wrote:
> On Wed, Apr 14, 2010 at 1:41 AM, Kurt Van Dijck wrote:
> > On Wed, Apr 14, 2010 at 12:30:34AM +0400, Nikita Egorov wrote:
>
[...]
> > It's not my intention to start discussing TinyX vs. dfb, I'm just
> > interested and know not that
>
> > I would suggest to add a declaration of fl_old_shortcut()
> > in file FL/fl_draw.H This should make it seen by Doxygen.
>
> From what I remember of the great doxyfication last year, there
> are quite a few functions that are documented in "unexpected"
> places. This is especially true for the
> Interesting.
> Am I right that if one was able to create a dfb graphics driver, he/she
> should be able to create an X11 driver too? It looks to me both do
> similar things (although I've never written either of them).
No, you may have no fb driver at all if the frame buffer is not
necessary for
On 13 Apr 2010, at 22:41, Kurt Van Dijck wrote:
> It's not my intention to start discussing TinyX vs. dfb, I'm just
> interested and know not that much of dfb.
> * Does dfb make use of hardware acceleration in userspace, or kernel
> framebuffer drivers?
My understanding (and this is probably wro
On 13 Apr 2010, at 23:15, Michael Sweet wrote:
> It's been a while, but
Mike, how can you say that - you were *the* GL guy...! :-)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
> The fl_text_extents rectangle is smaller than the fl_measure one.
> But fl_draw() seems to expect a surface the size of fl_measure
> to do its job, and seems unhappy when given a bitmap only the size of
> fl_text_extents.
Ah... yes, fl_draw makes a fair bit of use of fl_height and fl_width, tha
All,
This is in fltk-1.3 r7500.
Inspired by Manlolo's work on rendering utf8 strings under GL on OSX, I was
digging into gl_draw.cxx a bit.
(It's not pretty, and some of the mess is mine...)
However, that aside, I was looking at gl_draw() near line 228 we have:
for (i = 0; i < n; i++) {
On Apr 14, 2010, at 3:24 AM, imacarthur wrote:
> On 13 Apr 2010, at 23:15, Michael Sweet wrote:
>
>> It's been a while, but
>
> Mike, how can you say that - you were *the* GL guy...! :-)
I haven't done any serious OpenGL programming in 15 years - a lot has changed
since then...
_
manolo gouy wrote:
>> So fl_draw.H is one of the catch-all locations for the doxygen
>> comments for these functions. I tried to add a non-doxygen comment
>> explaining why they were documented in an "unexpected" file and
>> not in the real implentation/header file.
>>
>> D.
>
> Greg: I've checked
Albrecht Schlosser wrote:
> I added this point to the TODO.utf8 file:
>
>* Rendering and measuring of non-utf8-conforming text
My preference is to convert invalid UTF-8 byte sequences by turning each
byte into it's equivalent in CP1252 (the Windows "ANSI" "code page").
There is no "mode", i
Fabien Costantini wrote:
> IMHO, I believe that, would we add this action() virtual method,
> the protoype should be :
>
> virtual int action();
>
> And then action() should be called _before_ the potential do_callback()
I would have the default version of action() run do_callback() and
requir
13 matches
Mail list logo
