
Lee Braiden wrote:
Off the top of my head, and thinking very long-term (I realise it's a bit of work to implement), I'd want a python scripting interface something like this:
- Probably most important: direct access to the DOM, or better yet, an
object-oriented abstraction of it that, which allows you to use the subclasses in the next points.
Exposing a DOM is the current long-term goal. I'm not sure how much arbitrary subclassing we can facilitate, but we'll do what we can.
- Ability to subclass existing objects
Not sure.
- Ability to subclass and add existing tools, and to define event handlers in
this tool class for only what is needed beyond the default handler. For example, a slice would act very much like a rectangle, except for:
My current thinking is that since we're exposing the SVG as a DOM tree, we can expose the UI through a DOM also. This would allow extension writers to access things in a consistent manner, and have a unified approach.
Much dynamic behavior would be tied into DOM Events.
My current bent is towards following XForms to do this, since it's pretty close to what we want, and uses DOM and DOM Events, etc.
- Ability to add menus, submenus, and menu items, including toggles, mutually
exclusive items, and items that are disabled unless certain conditions are met. For example, I imagine I'd want menu items that are ghosted unless a particular kind of object is selected.
This is exactly the kind of "forms-ish" behavior that XForms is good at.
- Some way of offering extended options for export, that's uniform and appears
when expected rather than when a simpler architecture allows.
Yes. Some of the autogui work extended with an XForms interface should give you exactly this.
With those, you would have a very complete and powerful plugin system, imho. With one more, which requires a more fundamental change to Inkscape, I'd be both very happy, and very optimistic about Inkscape's success:
- Eventually, the ability to define "property panels", such as those in 3DS
Max etc, which scroll and collapse in a side bar. This is probably the most extensible, powerful, and usable plugin interface I know of. It's great for building complex apps with lots of add-ons in a without things getting messy :)
Oooohhhh....
That's much of why I'm doing the Panel/Dockable stuff now. The plugins should only have to define a bare data oriented view, and the plugin system should manage that in a pretty way for the users.
Agreed. I think it would be better to define a good framework, and move toward that slowly, implementing the most crucial features first, rather than
Good. It appears that what you're asking for falls in line with what we're trying to do long term. Among other things, that validates our assessments of what users are going to need.
Once infrastructure is coming together, I'll be able to start gluing some of the work Ishmal, Ted and others are doing together. After that, things will start to become clearer and I think the pace will pick up as they see where this can be taken. So keep an eye out for progress, and keep in the loop so that we can be sure to get the most robust system possible.