>
>
>
> 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.
--
Newell
Before enlightenment, chop wood and carry water
After enlightenment, code and build circuits
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
