Mat,
I saw your post about a DBus based Inkboard. I was wondering if you were aware of the work Soren has been doing with DBus in Inkscape for Google's Summer of Code. Without knowing a whole lot about how Inkscape can be made to communicate over DBus, I can only assume that there might be some overlap in your DBus integration work. I would like to see both of these projects succeed. Please take a look at how your projects can fit together.
Aaron Spike
Aaron & the Rest,
Hi again!
I should read up on DBus myself, really. It seems like a "lessons learned" framework based on previous designs.
For things like Corba, RPC, RMI, and the many other remote invocation protocols I've seen, you don't really need the entire framework running if you have the "server" application already running and the client knows the host/port where to look for it.
The framework is necessary for: 1) Discovery. Find the desired service (like with RPC's Portmapper)
2) Activation. Where ActiveX gets its name. If the server isn't already running, start it up and register it (maybe your own instance with parameters). For this, you need the framework itself to be running as a service on a well-known port. The client calls this, requests the port#, then calls the client. At first I thought that this wouldn't be necessary for Inkscape. But many users want to call Inkscape from the command-line and run something internal. It would be too much to require end-users to start Inkscape first before running command-line scripts.
Although it isn't necessary to provide all Inkscape functionality on all platforms, it would be good to prevent them from being weaker second-class implementations.
But this looks like a wonderful idea
On a different note: ================== Note that this is different from script-bound DOM. (Not Inkscape tools that manipulate DOM, but DOM itself.) That needs to be handled same-process. The code is mostly done, and is on an Hg server I have been using, if anyone wants to help on it. The final solution is to have an IDL-like XML description file of modules and interfaces to be bound. A small Java tool reads this and generates the C++ class to be bound, (.h defs and .cpp stubs) the script that binds to it, and the C++ binding code between them. This gets around the need to generate many thousands of lines of redundant code for the >164 SVG-DOM classes. Also helps prevent typos. And by generating, we can avoid C++ multi-inheritance problems, by MI delegation. For each inherited interface after the first one, we change "is_a" to "has_a", and avoid any diamond problems.
The generated C++ .h and .cpp stubs and script code currently all compile and link. Not bad for such a huge amount.
Email me or give me a shout on IRC/XMPP if you are interested in helping. I could use someone's advice on separating C++ interface and implementation. Like, the generator makes .cpp stubs for all classes and methods, but I already have most of the C++ implementation code already written (like normalize() or adopt()). How to automatically inject that code into the stubs? Put it in the XML file?
bob (ishmal)
On 7/18/2009 3:37 PM, Aaron Spike wrote:
Mat,
I saw your post about a DBus based Inkboard. I was wondering if you were aware of the work Soren has been doing with DBus in Inkscape for Google's Summer of Code. Without knowing a whole lot about how Inkscape can be made to communicate over DBus, I can only assume that there might be some overlap in your DBus integration work. I would like to see both of these projects succeed. Please take a look at how your projects can fit together.
Aaron Spike
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opporunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
========================= If I had words To make a day for you I sing you a morning golden and new I would make this day Last for all time Give you a night Deep in moonshine
On Sat, 2009-07-18 at 15:37 -0500, Aaron Spike wrote:
I saw your post about a DBus based Inkboard. I was wondering if you were aware of the work Soren has been doing with DBus in Inkscape for Google's Summer of Code. Without knowing a whole lot about how Inkscape can be made to communicate over DBus, I can only assume that there might be some overlap in your DBus integration work. I would like to see both of these projects succeed. Please take a look at how your projects can fit together.
They don't really overlap. In one case Inkscape is a DBus service and the other place it's a client to other services. There should be no conflict using DBus GLib as it takes care of that for us.
--Ted
Thank you, Aaron, Bob, and Ted's reply about the D-Bus related work.
Sure, I would really like to do it :-)
For the start, I think I can try to discuss about the same issue that the both projects encounter.
BTW, Bob, I would like to suggest to try 'd-feet' first to experience how to play d-bus. It really save me from lots of D-Bus explaining and spec. Hope it also helps to you, too :-)
sincerely, Mat.
On 7/19/09, Ted Gould <ted@...11...> wrote:
On Sat, 2009-07-18 at 15:37 -0500, Aaron Spike wrote:
I saw your post about a DBus based Inkboard. I was wondering if you were aware of the work Soren has been doing with DBus in Inkscape for Google's Summer of Code. Without knowing a whole lot about how Inkscape can be made to communicate over DBus, I can only assume that there might be some overlap in your DBus integration work. I would like to see both of these projects succeed. Please take a look at how your projects can fit together.
They don't really overlap. In one case Inkscape is a DBus service and the other place it's a client to other services. There should be no conflict using DBus GLib as it takes care of that for us.
--Ted
On 7/20/2009 1:32 PM, Mat wrote:
Thank you, Aaron, Bob, and Ted's reply about the D-Bus related work.
Mat,
I don't think the discussion affects the API itself in any way, just how we deliver the environment. The API looks great.
But In Win32 (and I guess also with OSX with Fink), Inkscape has always been very much like an outdoorsman. It cannot assume that anything it needs will be provided in the wilderness, but must bring along everything itself. The download is so very large because we provide a complete Gtkmm environment, Freedesktop tools, and all of their many dependencies.
This is just the same chatter as we have when we add other things, like Python, PDF, etc. It's the "how do we do that?" part. We go through this cycle often. Or if you want a better metaphor, a bunch of guys arguing at the local pub. :-)
bob (ishmal)
On Tue, Jul 21, 2009 at 3:36 AM, Bob Jamison <ishmalius@...400...> wrote:
On 7/20/2009 1:32 PM, Mat wrote:
Thank you, Aaron, Bob, and Ted's reply about the D-Bus related work.
Mat,
I don't think the discussion affects the API itself in any way, just how we deliver the environment. The API looks great.
But In Win32 (and I guess also with OSX with Fink), Inkscape has always been very much like an outdoorsman. It cannot assume that anything it needs will be provided in the wilderness, but must bring along everything itself. The download is so very large because we provide a complete Gtkmm environment, Freedesktop tools, and all of their many dependencies.
I agree, too. I wish to help this, but don't know exactly where to start is better. Do you have any hint or suggestion about?
This is just the same chatter as we have when we add other things, like Python, PDF, etc. It's the "how do we do that?" part. We go through this cycle often. Or if you want a better metaphor, a bunch of guys arguing at the local pub. :-)
bob (ishmal)
Besides, I sincerely apologize that I wrote some sentence which cause misunderstanding easily, which is not my true meaning, and hope stop it from offending anyone inadvertently.
It really save me from lots of D-Bus explaining and spec.
"It really save me from reading lots of D-Bus tutorials which contain D-Bus explaining and D-Bus spec when I was learning D-Bus."
participants (4)
-
Aaron Spike -
Bob Jamison -
Mat -
Ted Gould