[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Support for callbacks...



I have been quite for a long time,
most of you remember my bitching and moaning, and lots of vapor ware.

There has been little interest in the cross compilation project, and
that has been put aside. I have been using dia alot for diagramming and
am very happy with it. 

I think it is possible in this lifetime to create a collaborative
environment where we can all build in simple components.

Dia will need to gives up some control over the internal representation
of the data, or aleast allow for a network access to that
representation, then we can make truly impressive application out of
dia.

My vision is of a abstract for storing of a dia document,
not just XML, but a active server. 

The entire GUI and representation of the graph is just a view into the
data. The model could be stored on a different server and updated as
needed. Dependancies on who is displaying what can be managed on the
server, with dia updating the server with the client requesting what is
being displayed at the moment, and sending change back.

I feel that this is a viable solution for application integrators, then
you can plug in your own backend and translate your local data into a
format that dia expects, by implementing key functions that return dia
compatible objects.

I intend on building this functionality into dia. Basically replacing
the xml save with a xml-rpc post of the data. Later allowing diffs to
be sent incrementally. (undos as well). The entire system will allow
complete scripting extension of dia via any language that is able to
understand xmlrpc (all can) . 

I have some ideas about also allowing the scripting of dia via this
interface, basically like a jabber client that listens to a port and
display dia as needed.

Of course all these heavy protocols can be implemented using inline
modules that are just linked in via ipc or via static linking... but
then you lose the flexibility.

I think people would use this function of dia, and it would allow you
to make interactive web applications using dia as browser....

mike

--- "TAZ Vukovic, Mirko" <mvukovic@taz.telusa.com> wrote:
> On a related (off topic) note, given infinite time, and finances to
> cover
> mortgage, health, kids education, etc, I was going to write a
> drawing/
> graphing/ diagramming software very much in emacs' image.  By that I
> mainly
> mean ``extendible''.  All the basic drawing and query commands have
> their
> python/lisp equivalent.  Users would then be able to extend the
> package with
> their own additions.  Eventually the most popular and essential
> additions
> would be absorbed by the package via hard-coding.
> 
> (Never having done it), I guess the main point is to have a solid and
> basic
> package that is extendible.  Basic functionality gives it initial
> usefullness, and extendibility allows the users to modify the package
> to
> suit their needs.
> 
> But that may be left for another lifetime.
> 
> Mirko
> 
> > -----Original Message-----
> > From: Lars Clausen [mailto:lrclause@cs.uiuc.edu]
> > Sent: Wednesday, July 16, 2003 12:45 AM
> > To: dia-list@gnome.org
> > Subject: Re: Support for callbacks...
> > 
> > On Tue, 15 Jul 2003, Herman Bruyninckx wrote:
> > > What is the status of callbacks in the Dia roadmap?
> > >
> > > I mean, is it (or will it be) possible to let some dia actions
> call a
> > > user-defined function?
> > >
> > > For example, a callback on each (dis)connection event on the
> canvas
> > > gives a lot of possibilities to add user-specific functionality
> to
> > > Dia. (E.g., to check whether it has a meaning in the users'
> > > application context to connect two given objects together.)
> > 
> > That's funny, I was just thinking about that in the shower this
> morning.
> > A
> > callback function would allow both elements and connectors to
> decide
> > whether they will allow the connection, and if they do, make any
> changes
> > that are needed.
> > 
> > Unless, by 'user-defined function', you mean that the user can add
> a bit
> > of
> > scripting to an object to be evaluated upon connection.  Given the
> above,
> > that could be added using the Python plugin, or any other plugin
> that
> > anyone cares to add.  Design/CPN has something slightly similar,
> > annotating
> > connections with SML expressions that are evaluated during a
> simulation
> > step.
> > 
> > -Lars
> > 
> > --
> > Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of
> Numenor
> > "I do not agree with a word that you say, but I  
> |-----------------------
> > -----
> > will defend to the death your right to say it."   | Where are we
> going,
> > and
> >     --Evelyn Beatrice Hall paraphrasing Voltaire  | what's with the
> > handbasket?
> > _______________________________________________
> > Dia-list mailing list
> > Dia-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/dia-list
> > FAQ at http://www.lysator.liu.se/~alla/dia/faq.html
> > Main page at http://www.lysator.liu.se/~alla/dia
> 


=====
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] Mail converted by Mofo Magic and the Flying D

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

GuideSMACK