[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: Tabbed pages in gschem (and implications)
On Thu, 2006-07-27 at 07:58 -0400, Stuart Brorson wrote:
> Sorry for the top post.
>
> I like the idea of a tabbed schematic. This might help solve the old
> issue that gschem doesn't have the concept of a project. It only has
> the concept of separate, independent pages. The concept of a tabbed
> schematic and the associataed underlying data structures could be used
> to implement a "project". This is a nice usability enhancement,
> particularly for newbies.
Screenshot at: http://www2.eng.cam.ac.uk/~pcjc2/tabbed_gschem.jpg
> Some thoughts, in no particular order:
>
> * Assuming your changes introduce the concept of a "project", instead
> of just independent pages being displayed, how to save out the project
> into a file? Right now, each page is an independent file. How to
> signal that a bunch of pages belong to the same project?
I never really thought of this as a schematic "project", but it sounds
like it could well go that way. I'm keen to avoid the normal newbie
confusion with most project managers, which goes "File->Open = Open
file", but with "Project->Open" for the master project. Its ok once your
familiar with it, but we must be able to do better.
> Orcad has a .dsn file which holds all schematics, and also has a .opj
> whcih must hold meta information about an entire project. We could
> use this idea to define a .geda file which holds project level
> information, like which pages belong to the schematic, in which order,
> etc. It could also hold session info like the last zoom for each
> schematic, etc. Indeed, if we design the .geda parser correctly, we
> could also embedd into it info pertainent to other programs like
> gsch2pcb and PCB itself. That is, the .geda parser for gschem would
> just have to ignore any tags it didn't understand, the .geda parser
> for pcb would just have to ignore any tags it didn't understand, etc.
>
> An alternative is to just have gschem think that all files with a
> common name (foo_*.sch) belong to the same project. This is what
> ViewDraw does: Your project consists of files called foo.1, foo.2,
> foo.3, etc. Then when running ViewDraw, it just loads all pages
> called foo.*. This approach has a couple of difficulties:
Indeed, this feels bad. For comparison, it is the way ProEngineer
(mechanical / general CAD) stores its revisions of designs.
[snip]
> * I take it that your proposal will create a data structure looking
> like this:
>
> TOPLEVEL -> GtkTable -> PAGE -> OBJECT -> [object list]
> | |
> V V
> [Gtk table PAGE -> OBJECT->[object list]
> graphical |
> widgets] V
> PAGE -> OBJECT->[object list]
> |
> V
> etc.
What I've got at the moment:
TOPLEVEL -> PAGE -> OBJECT -> [ object list ]
| |__-> GtkWidgets...
V
PAGE -> OBJECT -> [ object list ]
| |__-> GtkWidgets...
V
etc..
There is also
TOPLEVEL -> GtkNotebook
which has Notbook pages relevant to each schematic page in the
tabbar.
The idea is that the notebook page parents the GtkWidget responsible for
viewing each page of schematic.
I know this gives one set of DrawingArea etc... widgets PER PAGE, but
this is the way GtkNotebooks work. I didn't find an easy way (hack) to
make the GtkNotebook to just use one set of widgets for all its pages,
(Or reparent them to the newly visible page when the user changes
between the tabs).
My proposition for a "VIEW" structure would be that each tab page or
instance of a widget which shows a schematic page (e.g. preview), would
have its widget etc... pointers stored here.
PERHAPS::
Each tab points at a VIEW structure, and the VIEW structure then points
at the schematic page in memory which it represents.
(You can then have two tabs looking at different areas on the same
schematic if someone works out the way to present this to the user...
reminds me of having two view panes of the same file open in a
text-editor).
I think (although it will be hard work), that the TOPLEVEL structure,
(being a per-main-window structure), should only be used for data
specific to the main-window. (This should leave not very much in
TOPLEVEL). I think many more parameters are VIEW specific.
> If it helps you understand what's going on, I have a drawing of
> gschem's data structures (those relevant to attaching component
> attribues anyway) available here:
>
> http://www.brorson.com/gEDA/
Thanks... had the printed copy infront of my kbd whilst debugging my new
version... It is a fairly big datastructure change, and I'm still
hammering out the kinks. Mostly on gschem's assumption that there is
always a page loaded - this isn't true in my working tree at the moment.
On the side-line, I'm watching out for where the possible auto-save bug
is caused. I've seen it twice or three times now, althogh only once or
twice in the clean CVS codebase where I can be sure its not my major
changes causing it.
I think its may be a rare race between the autosave timer expiring, and
some initialisation / cleanup / closedown functions, cathing the
data-structures in an improper state. (That or a memory corruption).
> Look for "A drawing of the data structures used in libgeda". I also
> have a lot of expository text about how libgeda represents your
> schematic in the gEDA source tree under geda/gaf/gattrib/NOTES. But
> you likely have figured this stuff out already. ;-)
Hadn't spotted that one, but will look.
> * As for widgetizing the drawing area, sounds like fun. I have no
> suggestions to offer since I never did much to the drawing code. I do
> wonder, though, how that will impact the usability gripes which many
> newbies have about gschem? Make it better, or have no effect? I
> dunno . . .
Should be a lot of code changes for no effect... at least in the first
instance. BUT, it should make the codebase cleaner if done correctly, so
potentially redraw bugs caused by odd sequences of events will be fewer.
Turning it into a fully fledged gschem_canvas widget is a possibility,
but I'm not volunteering at the moment!
Peter
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev