Re: [davinci-develop] Plugin SDK and GUI

[Taj M. <ta...@wi...>]

>> <>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!), but they say that ignorance can sometimes be
>> an advantage... 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.
>
Hmm...we've got to get our ideas straight...so we're all on the same 
page. I was thinking that the actually DV implementation of ./davinci 
(the executable) would be as simple as possible (with only the plugin 
loading and the mainform) in the core. Plugins and the API would provide 
the rest. I'm writing a document that should clarify all this and will 
upload it tonight/tomorrow.

>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
>  
>
I actually think these should be moved to individual plugins. As Elio 
said, that will make DV more flexable. For writing webpage, we don't 
need to call a compiler. For an image editor, we don't need a syntax 
editor or form designer. For an IDE, we need a Form Designer and syntax 
editor. For a word processor (/me ducks, I'm kidding), we'd need neither 
a Syntax Editor, a compiler, or a form desiger. You get the idea :).

>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)
>  
>
Hmm...I'm not sure what's best here. I think it's the best idea to have 
the plugins generate the code (syntax for form designs). That would 
probably be faster, and maybe more flexable.

>	-> 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)
>  
>
Sounds good.

>	-> Syntax highlighting/completion functions and procedures
>  
>
Yes, I guess.

>	-> All necessary compiler information
>  
>
Yup.

>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).
>  
>
I'll leave this up to Elio...we could probably have some communication 
pipe or something. We could have a davincid daemon that runs in the 
background for comminucation between plugins and ./davinci. We'll see.

>>What do you think?
>>
>>    
>>
>
>I think I am going to learn a lot :p better go and buy some kind of
>"Advanced Pascal" book...
>  
>
Good idea...I need one too :). Let me know what's a good book!

-- 
Taj

http://www.wildgardenseed.com/Taj/blog
"Those who give up liberty for the sake of security deserve neither
liberty nor security." --Ben Franklin