Re: Support for callbacks...

[Krzysztof Foltman <kfoltman portal onet pl>]

James Michael DuPont wrote:

> Dia? I am using it every day now, even an old version 0.88.1. It
> crashes  on the uml class editor sometimes... but I would like to use
> this now to make a larger application. It is fine as it is...
"I've heard some people actually use vi for something" ;-)

> Ok, I say, take the shape lib and the dialogs and the autorouting
> information out of the core program, and make it user editable and
> configurable.
The shape library is already somewhat taken out of the core program 
(.shape files), but of course it's only limited to fixed shapes, not 
ones like UML, which need user input and do some custom things like 
automatic resizing, adding connections etc.  Which all may be done using 
a scripting language.

> Make an interface between the two modules, and make it possible to
> allow plugins for them.
I think there's a lot of functionality to cover in such an API.

- Provide a manager for tools/menu options/modeless dialogs
- Expose existing functionality of a display, built in (and pluggable) 
tools, document management etc
- Allow altering the way the diagram is displayed (including user 
interaction)
- Undo

And it needs to be fast, stable and bug-free. Doesn't sound like an easy 
task.

Maybe if it's done step by step ? Like: first finish shape format, 
adding things like autorouter information, then add a layer to expose 
object's data to a scripting language, then expose the context menu API 
etc. This way, the goal can be reached without breaking too much things 
at once.

> I dont think this is going to take that long to define an API
> the whole idea of an API interface is to hide the chagnes
> to hide the details, to make an interface that is supported, and does
> not change.
See above. I've seen a couple of API design attempts before :-)

> Dia is just too big and has  many dependancies. It takes
> forever to get all the parts togeather.
What do you mean ? The parts of Dia code I've seen are better than most 
C code I've seen. Adding a lot of intermediate layers won't help a lot 
(it will make it even more messed up and complex).

> This cannot be such a major problem to create cleaner and simplier
> interfaces, DIA needs that. That is what is preventing progress on this
> system, a boiling lava flow of intertwined modules....
What would be the goal ? Feature list, maybe ?

Krzysztof