Re: [XForms] Some requests

[LukenShiro]

Il giorno Sun, 27 Dec 2009 17:54:07 +0100
Jens Thoms Toerring <address@hidden> ha scritto:
[..]

> > 1) FL_OBJECT unique identifier for comparison.
> 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.

Sorry, you are right, indeed an unsigned int is way better.

> 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')?

No particular name required, I believe 'uid' name maybe will be fine
(as "id" can be confusing as it's a python standard function, too).

> 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?

It depends on ctypes class instance problem I pointed out in my
email; nonetheless an alternative method to direct access it's welcome
(two choices are better than one, for now I don't know if it is viable
or not for me, but I will test it with pleasure).

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

For the time being I have not had to test comparison between two forms;
but feel free to consider it, too.

> > [X11 libraries functions wrapping]
> 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).

Thank you.

> 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...

Thank you, I believe example demos are an excellent way to test and
document XForms library usage (I've already ported about 58 demos, with
minimal changes, all things considered, and they let me to find some
flaws in my implementation).
 Anyway in next days/months I'm planning to do a global review, function
 by function, to verify explicitly its working state (in the meantime I
 will have a deeper look to C sources, too). BTW there are some XForms
 functions I don't need, as their functionality is provided implicitly
 by python interpreter (e.g. low-level memory functions: fl_malloc,
 fl_calloc, etc..), but I've yet to figure out if there are any other.

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

Thank you, very much.

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

Sure :-P
I don't want to overload you; as soon as I can achieve a reasonable
degree of stabilization of the library, I plan to work on it, too (it
would be an interesting testing battle camp ;-).

I am undecided if it's better to write a python parser for .fd files
created with fdesign (then creating a skeleton .py file with
ready-to-use classes/functions for UI only), or to re-write in python
the whole fdesign program.


> A different approch could be to have a function that compares
> two objects for equality, so that the pointer comparison happens
> in the C code, i.e. 

> int fl_is_same_object( FL_OBJECT * obj1, FL_OBJECT * obj2 );

> That might be a bit simpler than adding an extra ID just for that
> purpose. What do you think?

OK, it seems to be simpler, if it is viable it may be even better
(anyway I'm willing to test it).


Regards.

-- 
GNU/Linux * Slackware64 current
Slackware 13.0-32bit VM
LU #210970 SU #12583 LM #98222/#412913