Re: [davinci-develop] Plugin SDK and GUI

[<el...@ya...>]

Paul Hampson escribió:

>On Wed, 2004-09-08 at 21:49, Elio Cuevas Gómez wrote:
>  
>
>>So we need to create the GUI system and  a interface to access it form 
>>plugins (Plugin SDK). I'll leave the GUI for another moment.
>>    
>>
>
>I can deal with GUI programming if you want me to focus on that area, I
>just need to know how we are going to structure everything, i.e how the
>plugin interacts with the GUI, obviously we need to finalise most of the
>features of the plugin, and how it will interact with the GUI...
>
>  
>
Yeah.

>>So we need to provide a way to call DaVinci functions from plugins. My 
>>first idea is to let plugins resolve DaVinci symbols and use them. I'm 
>>not sure it's possible or portable. My other idea is to make davinci 
>>"export" it's sysbols by putting them in predefinded adresses.
>>
>>    
>>
>
>Hmm, I thought the idea of a plugin was to provide the functions for the
>software, rather than the other idea, that is the point of .so/.dll
>isn't it? A lot of the technical stuff is over my head (i.e. i'm
>learning a lot of stuff!),
>
:D. Yeah, but DaVinci should provide something right? e. g. code to load 
other plugins.

> but they say that ignorance can sometimes be
>an advantage...
>
... for the goverment.

> I sounds to me like you are suggesting that we build a
>lot of the functionality into the software, I understand some of the
>reasons behind this but we need to outline what
>information/procedures/functions come from the plugin itself, and what
>comes from the software that is being plugged into.
>  
>
DV have basic plugin management, provedes interfaces to other parts of 
the system (i. e. other plugins) and define general protocols.
The plugins provide all the "superflous" functionality such as syntax 
definitions and the GUI :).

>So, from the 'front end' software we need this (and then some more
>probably):
>
>	-> Form Designer
>	-> Designer "pallette" to hold components
>	-> Syntax editor
>	-> Calls to the appropriate compiler
>
>  
>
Maybe these things should be defined in plugins. For example what if you 
want to make DV an image editor (and only that)? You don't need a form 
editor do you?

>And from the plug-in we need:
>	-> Syntax for form designs... unless a generic one is used but this
>needs to then be defined (i.e. Glade syntax or something)
>  
>
I don't know Glade. But an standard format would be useful. XForms maybe?
Anyway we should make Form Designer sufficiently flexible to export in 
HTML or Delphi.

>	-> Pallette definitions, so we don't have components that can't be used
>in some other language (like hidden fields in html and data access
>components from LCL in pascal)
>	-> Syntax highlighting/completion functions and procedures
>	-> All necessary compiler information
>
>This is a very 2-way road between the plugin and front-end, .so's and
>.dll's are expected to be used in a one way system. Like a book, you
>take information from it, you don't tend to write information to it. Is
>there any more convenient way to have a 2-way system? It looks like its
>going to be quite hard to implement a 2-way system (as it appears to
>me).
>
>  
>
It's not to hard if you don't care about compatibility (and we don't), 
we can implement our own "propietary" 2 way comunication system for 
example with shared memory, stacks, etc...

>>What do you think?
>>
>>    
>>
>
>I think I am going to learn a lot :p better go and buy some kind of
>"Advanced Pascal" book...
>
>  
>
Huh?

>Paul
>
>  
>