Re: Support for callbacks...
- From: James Michael DuPont <mdupont777 yahoo com>
- To: dia-list gnome org
- Subject: Re: Support for callbacks...
- Date: Fri, 18 Jul 2003 08:59:17 -0700 (PDT)
--- Krzysztof Foltman <kfoltman portal onet pl> wrote:
James Michael DuPont wrote:
Basically what I would like to help here with is making a clean
object
model for scripting dia, and on the basis of that create a very
abstract API that can be used for network based and non-network
based
applications.
I'd prefer basic usability first, fireworks (like scripting and
collaboration) next. What's the use of network editing-capable
diagram
editor if it doesn't do basic things well enough ? (well enough =
[almost?] as comfortable as commercial counterparts).
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...
While big goals like adding scripting are a real challenge and add a
lot
to the program's value, they also get in a way when the priority is a
bug free release that general public can use (and I've got the
impression that that's where Dia is so far). So far, a general public
is not complaining about lack of scripting or collaboration - we're
mostly complaining more about things like inconsistent dialogs,
imperfect shape
library, lack of autorouting information in some shapes, assertions
failures and many other minor annoyances.
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.
Make an interface between the two modules, and make it possible to
allow plugins for them.
However, both scripting and network editing seem to be good
candidates
for 2.0 - and it looks like the research/design phase is going to
take
quite a lot of time - doing locking, change propagation and conflict
resolution properly seem to be worth months of work.
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. Dia is just too big and has many dependancies. It takes
forever to get all the parts togeather.
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....
Just my 0.02PLZ worth of rant.
:)
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]