Re: [XForms] Some requests

[Jens Thoms Toerring]

Hi Lukenshiro,

On Sun, Dec 27, 2009 at 04:52:46PM +0100, LukenShiro wrote:
> I would have some requests that would seem to ease my python porting
> work if it was technically possible, but only if it doesn't cause too
> much hassle to you, Jens, and if it doesn't have any backward
> incompatibility issues.
> 
> 1) FL_OBJECT unique identifier for comparison.
> 
> In XForms a user can use "if obj == exitbutton" to allow comparison
>  between two FL_OBJECTs (where obj is the product of fl_do_forms(), and
>  exitbutton is the product of fl_add_button(...)).
> 
> ctypes (the library I use to wrap XForms in python) uses
> different created instances of FL_OBJECT class (equivalent of C
> FL_OBJECT struct), so a simple comparison using "if _obj_ ==
> _anotherobj_" is not useful (that is: comparison always fails).
> 
> In order to resolve this problem I have used .u_ldata assigning to it a
>  unique value for a particular Object, so I could compare .u_ldata
>  FL_OBJECT element with another one.
> Nonetheless, as .u_ldata element could be maybe used for other purposes
> by users, I'd ask for another (new) element in FL_OBJECT struct (maybe
> something like .u_uid, of 'int' type).

I don't see any big problems with this - and it would seem to
be exactly the right moment to introduce such a change before
publishing a new version with a bumped up SO_NAME. The only
thing I guess I have to take a bit of a closer look is at the
fdesign stuff since, IIRC, there some rather strange copying
of objects goes on and that may get a tiny bit more complicated
when having to maintain a unique ID for objects. But that may
not even be an issue since fdesign won't use the ID...

One question: would the ID variable have to have int type or
would also something else (like a size_t) do as the unique
identifier? I personally would prefer an unsigned type since
otherwise you tend to throw away half the range of possible
values. And since the ID is never to be repeated ever during
running a program I would feel a bit happier if the range
would be as large as possible.

Is there any special name required, or could I create a member
simply called 'id' (the 'u_' prefix stands for 'user data' and
'uid' I would associate with 'user ID')? And do you want an
access function like fl_object_id() for this new member or do
you have to access the member directly anyway?

Another question: would such an ID also be needed for FL_FORM
objects?

> 2) I've noticed in XForms .h headers (i.e. #define macros) and in .c
> demos several references to X11 libraries functions.
> 
> While XForms functions are meant to be only called by ctypes prototypes
> (so I don't have to deal with internal implementation), macros have to
> be trasposed completely in python code, explicitly wrapping X11
> libraries, too.
> 
> As my intention was to wrap XForms libraries only, I'd ask if it was
> possible to transform macros containing X11 functions into
> corresponding functions.
> I'm referring to:
> 
> lib/include/bitmap.h:71
>  #define fl_create_from_bitmapdata( win, data, w, h )  \
>     XCreateBitmapFromData( fl_get_display( ), win, ( char * ) data, w,
>     h )
> 
> lib/include/bitmap.h:138
>  #define fl_free_pixmap( id )                  \
>     do { if ( id != None )                    \
>              XFreePixmap( fl_display, id );   \
>     } while( 0 )
> 
> lib/include/XBasic.h:391
>  #define fl_raise_form( f )                          \
>     do { if ( f->window )                            \
>              XRaiseWindow( fl_display, f->window );  \
>     } while( 0 )
> 
> lib/include/XBasic.h:396
>  #define fl_lower_form( f )                          \
>     do { if ( f->window )                            \
>              XLowerWindow( fl_display, f->window );  \
>     } while( 0 )
> 
> lib/include/XBasic.h:401
>  #define fl_set_foreground( gc, c )   \
>     XSetForeground( fl_display, gc, fl_get_pixel( c ) )
> 
> lib/include/XBasic.h:404
>  #define fl_set_background( gc, c )   \
>     XSetBackground( fl_display, gc, fl_get_pixel( c ) )

I think that's actually a rather good idea since using macros
as if they were functions can lead to trouble in case arguments
are evaluated more than once (probably not happening with the
macros listed here but anyway). And the overhead of calling a
function nowadays should be rather small (if the compiler does
not even inline the stuff anyway).

> From examples in demos, the same happens for:
> 
> demos/minput2.c:63 and 102
>  XFlush( fl_get_display( ) );

There seems to be another one

demos/minput2.c:398
 XFlush( fl_get_display( ) )

In both cases I suspect that the XFlush() shouldn't be needed
(or should be done in the XForms function called directly be-
fore) - I will have a closer look at that. And then having a
fl_XFlush() function (without an argument) that relieves the
user of having to write "XFlush(fl_get_display())" might be
a good idea anyway.

But then keep in mind that these are programs that just use
the XForms library which can use X11  functions directly
(with some limitations, of course). So there will be some
demo programs that use this possibility for demonstration
purposes. Programs that use a canvas are the most likely
candidates (and demos/canvas.c does that) since a canvas is
typically used for direct X11 drawings. Those programs won't
be easily converted by you unless you write a wrappper also
for most of the X11 functions...

If there are no objections to the ideas I would make the
changes proposed by you in the next days.

The next step, of course, would then be to have fdesign
changed so it outputs Python code, wouldn't it?;-)

                             Best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de