Mail Archives: geda-user/2013/07/22/14:01:26
I still have little experience with libgeda/gschem code, but in case
it may be useful, here it goes:
I have been working for a few weeks now on a side display which shows
a list of current nets and components while you work on gschem -it may
well be a useless feature for many, but I found it helpful in other
eda software (eg PADS), especially when doing digital stuff with many
nets.
What I have done so far, is to include an "Update button" on the
panel, triggering a callback which goes through the whole toplevel
structure updating the list.
However, I would also like to be able to select a whole net by
clicking its name on the list. The problem I have is, if any of the
nets (segments) has been removed, a will try to access a non-existing
object. So I was thinking of using the weak refs to get a notification
of its destruction
So my suggestion is, why not use the weak refs to implement Stefan's
idea? Right now, it only notifies destruction of the object -correct
me if I am wrong-, but it could well notify a change in the object.
So, in the case of the properties dialog, on creation it would create
a weak ref to the object, with a notification callback. And everytime
an object is modified, the list of weak refs is checked, calling any
existing callback.
Luis
On Mon, Jul 22, 2013 at 6:23 PM, Stefan Salewski <mail AT ssalewski DOT de> wrote:
> On Sun, 2013-07-21 at 18:02 -0700, Edward Hennessy wrote:
>> Implementation of non-modal dialogs requires some form of property
>> change notification. This way, if an object property gets changed,
>> either through the GUI or scripting, the dialog box widgets stay in
>> sync with the value of the property. How should property change
>> notification be implemented in gschem/libgeda?
>>
>> Cheers,
>> Ed
>>
>
> An interesting question.
>
> I think my idea last year was:
>
> We have only one property dialog window or area, which can be visible or
> not. (I prefer an area for my peted clone, instead of overlapping
> windows, but that is a matter of taste.) If the user clicks on an
> element (symbol, text, net...) the property display update its content
> when it is open/visible -- some values may be displayed always like
> color, other like font or footprint only for some elements. A double
> click on an element may open that property display. Updating elements by
> other means (scripts, menu...) should simple gray out that property
> display, or maybe ask that display to update after all is done. It makes
> no sense to update that property display hundred times when a script
> changes textsize for all refdes.
>
> Clicking on elements with right mouse button may open a context menu for
> basic properties, i.e increase font size.
>
- Raw text -