Re: gEDA-user: next PCB release - 1.99za vs 4.0

[Andrew Poelstra <asp11@xxxxxx>]

On Thu, Sep 09, 2010 at 10:54:37AM +0100, Peter Clifton wrote:
> On Wed, 2010-09-08 at 17:46 -0700, Andrew Poelstra wrote:
> 
> > Well, I am converting the top-level window to its own widget, rather than
> > using a stock GtkWindow and tacking stuff onto it. That way I can migrate
> > a lot of the global variables to member variables, pass more things as
> > parameters, and use the 'const' keyword a lot more.
> 
> I'm not sure I see the point of making the whole top-level window a
> dedicated widget per-se, although the goal to encapsulate various state
> variables sounds excellent.
>

Well, I'm making it a GObject, since I don't have legitimate classes in C.
From there, it seemed natural to subclass GtkWindow, since that's what the
window /was/, and it lets us treat it as a GtkWindow when referencing it
from the other Gtk functions.

My goal is to structure and encapsulate the window and its children,
without having a global GtkGui and GHidPort structure with a thousand
members, all pointing to various components of the GUI.

This is the way that Visual Studio and Mono do things (not that those
are shining examples of how to code), but I think it's a useful thing to
do.
 
> I was never really sure what point to start sub-classing to make a new
> widget. My acid test was usually whether that widget had useful
> self-contained functionality which could be re-used in other places.
>
> For example, I've got a moderately large refactor queued which removes
> most of the drawing back-end specific code from the GTK hid, splitting
> all the GDK specific rendering details into a separate file. With GL
> enabled, it removes that file from the build and swaps in an equivalent
> which uses OpenGL. All render-specific member variables are defined
> locally to those files, avoiding the GDK/GL choice cluttering up more
> global structures.
> 
> When devising this split, I was very tempted to turn the PCB drawing
> area into its own widget, and teach that to draw (and potentially have
> two implementations / sub-classes), but so far I didn't take that route.
> There is code in PCB which depends GDK / GL rendering, but does not
> renders not to a widget, rather to a GdkPixbuf.
> 

I think I would have done it the OO way, only to keep things consistent
with how glib works. Your way is the "natural" C way to do things.

> 
> I think making the whole main window a dedicated widget is perhaps a
> step to far (or too early). There are probably other more useful
> refactors, such as making a layer-selector widget, route-style selector
> widget etc., and defining clean interfaces with those.
> 

This is a very good idea and probably far less controversial :)


Andrew



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