gEDA-dev: Re: gEDA-user: gschem modifications

[Carlos Nieves Ónega]

Hi Peter,

El vie, 21-07-2006 a las 14:55 +0100, Peter Clifton escribió:
[snip]
> I'd appreciate advice on better working practices, as to seperate out my
> changes, I now need to checkout the new CVS, make a diff between that
> and my work (after cleaning the build files (.o etc) out), then sort out
> the chances which I have made, so I can then end up with a patch for
> each group of new functionality / changed behaviour I've been working
> on.
> 
> I'm sure this will be a lesson to think more clearly about how I'm going
> to seperate my mods from the CVS download!

As DJ pointed out, you can use the command cvs diff to compare the
modified sources with the original and get a .diff file.
Then, you can submit the patch at:
http://sourceforge.net/tracker/?group_id=161080&atid=818428
, and some of the developers will commit the changes into CVS.

If you are going to work on several unrelated changes, you can have
several working trees, so you will be able to get a different diff for
each set of changes.


> 
> The changes I've made for our use (some of which should will be useful
> back in CVS I hope):
> 
> Mouse behaviour:
> ---------------
> 
>  * Added option to allow mouse panning on middle mouse button, as well
> as RH button.
> 
>  * Changed pan "gain" to 1, rather than 5, so when panning with the
> mouse, the schematic page moves as if you had actually grabbed the page
> at the point when you start panning from
> 
>  * (Hardcoded), scroll wheel behaviour to zoom in/out, with LEFT/RIGHT,
> UP/DOWN with a "shift" / "control" modifier

Cool!

>  * Slightly modified the preview widget / event handler code to allow
> mouse scroll zooming with the same event handler as the main schematic
> view
> We now have a gschem, where the mouse scroll wheel is able to zoom, pan
> by dragging, and pan LR / UD by scrolling with modifier keys - basically
> making it a navigation button / wheel.

This is a feature I liked to see implemented. Thanks for doing it!


> Re-layed out component picker:
> -----------------------------
> 
>  * Eventually, I would like to see the component picker able to dock as
> a side pane along the left or right of the schematic page view. I've
> re-layed out the dialog in a more vertical way, and removed the
> superfluous "Apply" and "Close" buttons.
> 
>  * Split out component selection code from x_fileselect.c into a new
> file, x_compselect.c

Maybe a dockable window, so the user can choose where he was it?

>  * Modified preview widget code to allow it to resize with available
> space

Nice.

> Superficial cosmetic:
> --------------------
> 
>  * First attempt at an icon for gschem ( from a photo of an 8pin SOIC ),
> mainly so I can identify which window is gschem easily in my "Alt-Tab"
> window switcher.
> 
>  * Code to set the icon is a bug hard-coded hack, and needs someone who
> knows how to assist in its proper implementation. (Getting automake /
> whatever to install the icon in the right place, and getting gschem to
> find it - rather than my hard-coded path method).

In gschem/bitmap there are some icons. You can add it there, and add the
name in the variable bitmapdata_DATA in Makefile.am. This way the icon
will be installed into $GEDADATADIR/bitmap, as the other icons.
You can access this file using something like (extracted from
x_window.c):
        filename = g_strconcat(w_current->bitmap_directory, 
                               G_DIR_SEPARATOR_S, "gschem-bus.xpm",
NULL);

> Bugs noted:
> ----------
> 
>  * Some odd behaviour I'm noticing when zooming the window after a
> resize, which can jump the mouse-pointer off the screen, put the
> schematic page origin in a funny place, allow components to be placed
> above the origin.
> 
>  * A crash I saw once - in the autosave code, in s_page_autosave(), from
> libgeda/src/s_page.c. Unfortunatly, I lost the stack dump (which wasn't
> helpful anyway), but the problem appeared to be that toplevel->page_head
> was not equal to NULL, but was not pointing at valid memory.
> I note that this callback is an auto-save system called from a g_timeout
> or something. This timeout is never cancelled once it is setup, so is
> there a possibility that it gets called concurrently with the active
> page being free'd?
> 
> I never saw the crash again (and presuming it could be an unrelated
> memory corruption which caused it), stopped digging at the auto-save
> code.

Mmmm... this bug would need to be tracked down...

> Any ideas on how to seperate these patched functionalities out, and
> which bits are suitable / useful for upstream inclusion?

If you worked all these changes into the same development tree, I'm
afraid you have no automatic way to split the functionalities.
You would have to do it by hand. 
My opinion is that a patch for each functionality is preferred to a huge
patch including all of them. It would be easier to review and to
track...
All changes are suitable to be included into CVS. Usually things having
to do with the user interface need to be configurable, as there are a
lot of user feelings out there.

> I'm keen to hear more about people's thoughts on a component manager /
> database for light -> heavy symbol work on a per company / project
> basis, as this is exactly what I'm wanting to implement as part of this
> project.
> 
> As some will recall, a new project manager is on the cards, although
> I've not yet spent much time working out how it should work, either GUI
> or backend wise.

I like the database approach, although I will let the user to use pure
heavy symbols as well if he wants it. Last time I checked, gschem
doesn't currently support pure heavy symbols, but it's not quite far.

Regarding the database component picker, I follow Stuart's opinion to
have it separated from gschem, but closely to it.
Some kind of IPC is needed. The pipe method is working now, although I
suspect something more powerful is needed. 
Someone suggested to use DBUS, as it is included in GTK already. It is a
possible way which needs to be evaluated.

Another interesting point is that it seems GTK is including some new
socket/plug support. See:
http://developer.gnome.org/doc/API/2.0/gtk/GtkPlug.html
http://developer.gnome.org/doc/API/2.0/gtk/GtkSocket.html

"Together with GtkSocket, GtkPlug provides the ability to embed widgets
from one process into another process in a fashion that is transparent
to the user. One process creates a GtkSocket widget and, passes the ID
of that widgets window to the other process, which then creates a
GtkPlug with that window ID. Any widgets contained in the GtkPlug then
will appear inside the first applications window."

Currently not all the architectures are supported, but I suspect it is
only a matter of time.

Regards,

Carlos

P.S.: You can always connect to #geda IRC channel in irc.seul.org . You
can find there some developers/users. In fact, I usually am there while
I'm hacking geda. 
I think we should encourage people to use the IRC channel more
often....