[Redirected onto geda-dev]
On Fri, 2008-06-27 at 16:22 -0700, Newell Jensen wrote:
> The attached document (two available formats) is something I put
> together that has a brief over view of the different objects in the
> gEDA Manager as well as the next steps that I planned on tackling.
That is brilliant, and exactly along the lines I was hoping to see,
thanks!
Please send the design document to the list, it would be a great way to
show how things are progressing. I'd expect some people won't want to
use the window nesting, and might be negative about that, but take it
with a pinch of salt.
I'd be a little weary of copying ISE too much, especially referencing
screen-shots directly in the gEDA manager design documentation. I do
think its fair look how other tools do things though.
The other bit of design work it would be really nice / useful to see in
the near term is filling in more details about how "processes" are
configured / specified, and take a look at what algorithms you might
find to plan dependency routes to get to a particular target.
E.g. "run postscript export process", "run postscript -> pdf converter"
if the user wants a ".pdf" out, and assuming the tool they want the .pdf
from can only emit ".ps". (Ok, a contrived example, but this is the kind
of thing gEDA Manager needs to get right.)
I recall we talked a little bit about this on IRC, and how mime-types
might play a part. (Although probably, our targets have more detail than
mime-types... we could have two ".ps" files, which represent different
targets, and they might be generated via different tool paths).
> For now, I am going to work on getting the project tree working
> ('Sources'). After this, I need to interface the other geda apps with
> mine. Do you guys think you would have time to help me with this?
I can help with gschem and PCB, as volunteered. (I presume we're talking
about process integration at the moment, not the GUI window stuff). So,
after getting the sources list to work (which actually requires some
integration itself), start writing the process handling classes, and
path-finding algorithm etc.
After the processes are coming together, we can look at the GUI window
integration. I can probably help code / point in the right direction for
gschem / PCB, you'll just need to tell me how you're getting the window
IDs back. (Could be via DBus, or perhaps some other way).
Regarding sources, I'd suggest you tag each one with a file-type (at
least a mime-type). This tagging might be saved in the project file, or
it might be determined at run-time.
If possible, we should use any mime-type handling APIs provided by the
desktop, although off the top of my head, I don't know what they are.
Anjuta wraps this in a function:
gchar* anjuta_util_get_uri_mime_type (const gchar *uri);
If new enough libraries are installed on the users system, you can do
some intersting stuff with "GIO".
http://library.gnome.org/devel/gio/unstable/
g_file_info_get_content_type () might be interesting to look at.
Alternatively, we might just ask the user what type of file they are
adding when creating a project, and / or determine child types by their
context / file extension.
Once we know the file-type of each source, the gEDA manager would be
able to determine how to interrogate for child-files. (This ought to be
configurable). In the case of gschem / libgeda files, this interrogation
routine might be executing a child process, such as the one I started as
groundwork for this project.
(See:
http://repo.or.cz/w/geda-gaf/pcjc2.git?a=shortlog;h=refs/heads/master_comp2
)
Let me know what it needs, and I can flesh it out more if necessary. You
might be interested in me implementing the DBus interfaces, rather than
calling the program and parsing its pipe output.
> If you think it would be good for this document to be seen by the
> developer's list go ahead and forward it. Something that would save a
> ton of time is a
....
Reading your document, I think I see the context, take a look at this
document:
http://www-mdp.eng.cam.ac.uk/CD/engapps/geda/starting_gEDA_long.pdf
Somewhat out of date, but have a look at the diagram on page 7. "gEDA
overview". The document also describes the old gEDA manager, which might
be of some interest.
I'm leaving for Scotland on Sunday (teaching a course for two weeks),
but will still (hopefully) be on the Internet. I will engage my brain a
bit more on the task when I get some free time up there.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
