Hi Carlos,
Carlos Nieves Ónega writes:
> [...]
> I would not want to change the behaviour of the hooks (they don't get
> w_current and o_current as parameters), so I wonder if w_current and
> o_current pointers could be passed to scheme as two variables, with
> names __wcurrent, and __ocurrent (using scm_c_define).
What would be even better is:
1 - define a new smob for OBJECT on the model of the one for ATTRIB
in libgeda;
2 - modify the hook to be passed a smob OBJECT instead of a list of
ATTRIB smobs;
3 - write a function get-object-attributes in C that is given an
OBJECT smob and actually returns the list of ATTRIB smobs
Example:
(define (print-all-attributes attribute-list)
(for-each display attribute-list))
(add-hook! add-pin-hook (lambda (pin)
(print-all-attributes (get-object-attributes pin))))
4 - modify your g_add_attrib function so that scm_vis is expected to
be boolean and scm_show a symbol (or list of symbols). Also split
newtext into name and value.
Example:
(add-attrib object "name1" "value1" #t 'show-name-value)
or
(add-attrib object "name1" "value1" #t '(name value))
Exposing the toplevel (w_current) to the scheme side is indeed a bad
idea. To solve the access to this TOPLEVEL structure:
- use the global_window_current from C functions of scheme procedure
(typically in g_add_attrib()). This global variable is updated on
every event. Functions in g_funcs.nw are already using it.
- include toplevel in the OBJECT smob like the ATTRIB smob.
I am not sure which of the previous two options is best.
Comments?
Patrick
