xforms-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XForms] Some requests


From: LukenShiro
Subject: Re: [XForms] Some requests
Date: Mon, 28 Dec 2009 15:51:42 +0100

Il giorno Mon, 28 Dec 2009 14:14:32 +0100
Jens Thoms Toerring <address@hidden> ha scritto:
> Mmmm, I supspect that there's something going wrong on a deeper
> level and that your "trick" is leading you into a bad direction,
> i.e. a fight you can't win. E.g. setting the .visible attribute
> of the object alone after a call of fl_show_object may not be
> enough since an object may have child objects that also have
> their visibility changed. And the call may also have changed some
> other attributes beside - having to find out what may change and
> reproduce it in Python is going to be a loet of hard work and there
> are no guaranties that what you found out with a lot of effort and
> then reproduced in Python will still hold in three years (or even
> three months) time...

It's likely you are right; alas for now it is a temporary hack, until I
catch where the problem is deep-seated (I would not be astonished if it
wasn't ctypes fault, but a flaw of mine).

> I am groping a bit in the dark here since I don't understand
> enough about Python/ctypes and the explanations given at
> 
> http://python.net/crew/theller/ctypes/tutorial.html#surprises
> 
> aren't really clear to me. But what I get from it is that in
> some cases copies of objects will be created when you don't
> expect it and in other cases no copies are made when you
> want them to be created;-)

Uhmm, in fact it is not so much clear, it's simply a little mess,
I guess :-//


> My gut feeling is that Python/ctypes better shouldn't be aware
> at all of what an FL_OBJECT consists of, it should be treated
> on that level as an opaque pointer so the contents of an
> FL_OBJECT never get copied - the copy may get out of sync
> with what is stored in the original in hard to trace ways and
> the question is how "deep" the copy is (does the copy e.g. also
> contains pointers to copies of child objects or pointers to the
> child objects of the original, and then what about children's
> child objects etc.?)

Alas AFAIK if I access to a FL_OBJECT struct member, I've necessarily to
transpose FL_OBJECT struct to a FL_OBJECT class (inherited from
ctypes.Structure class), to deal with it.

> Of course, to be able to do that a number
> of new accessor methods for object attributes may have to be
> added, like 'fl_object_is_visible()' or 'fl_object_is_activated()',
> but writing them isn't a big deal (I hope).

Maybe some C getter functions (as you said) would be greatly helpful
for individual struct members that are supposed to be
evaluated/considered (but I didn't mean to burden too much upon your
work ...).

Regards.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]