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.)
What I plan on doing is that when one of the nodes in the 'Sources' project tree is highlighted this will trigger an event and I will populate the 'Processes' tree with the available processes for this type of file. This will basically take after page 7 for the document that you sent me (roughly of course). In other words, verilog files will have different processes than a schematic file. So, the 'Processes' tree will be redisplayed for each node that is highlighted.
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.
This will be done at runtime because I am only going to save the current project (project file) when they are closed, a new project is created, or an existing one is opened. I will be able to get the file paths from the nodes. I will pass around the paths but only show the names when rendering.
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.
I addressed this above (for reference).
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.
yes that is basically the idea and this page is what 'Processes' will be based on.