Re: gEDA-dev: Toolbar Project

[ehennes-at-NOSPAMsbcglobal_dot_net]

On Jul 24, 2008, at 9:32 AM, Bernd Jendrissek wrote:
>
>> - Change scheme functions (g_keys.c) to activate GtkActions rather
>> than invoking the callbacks directly.  This change keeps toggle and
>> radio action's state in sync.
>
> While I don't want to stop you from doing what seems good to you [*],
> I hope you can preserve the scheme-ness that's currently available
> from keypresses, all the way to the callbacks.  I'm working towards
> being able to script user input, so that gschem could do things like
> replay GUI events (think of tutorials) or have user-defined drawing
> helpers a la AutoLisp "macros".  Eventually I want to define menu /
> key actions as, for example,
>  (add-box (get-xy-with-prompt "Choose one corner of the rectangle")
>           (get-xy-with-prompt "Choose the other corner of the  
> rectangle"))
> instead of the hardcoded state machines in gschem/src/x_event.c.
> (Incomplete example due to missing rubber boxes etc.)  Can you
> preserve an optional list of arguments through to the i_callback_*
> functions?

It will preserve the scheme interface.  The change keeps GTK in sync  
with calls from scheme.  If scheme calls a function to "add net," the  
toolbar will update to reflect the change.

The signal handlers for GtkActions must use a specific signature.   
However, I'm sure there will be some way to pass the data through.

> [*] Your patch to the list from a few days ago seemed to be from a
> private git repository via git-format-mail or similar.  Is that
> repository publicly available somewhere?  If so, what is its URL that
> I can fetch from?

That is a branch of my local clone of git://git.gpleda.org/gaf.git.   
Unfortunately, I do not have the branch available anywhere.

>> I'd also like the core developers opinion of using GtkBuilder and
>> GtkUIBuilder for UI construction as apposed to using straight C or
>> some form of guile.
>
> I would much rather prefer using things like libglade -> GtkBuilder,
> but the project culture favours compatibility with quite old
> environments over the delta in developer productivity it would bring.
> Which stands to reason if you consider that the gEDA project is hosted
> at seul.org - *Simple* End User Linux.  (But also an annoyance
> sometimes when having to bend over backwards to NOT use awesome new
> feature #X.)

Sounds like a job for Python: a GtkBuilder XML to C converter.

Ed


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev