davinci-develop — Discussions on development of DaVinci

Josué Gutiérrez has invited you to Dropbox

[Dropbox <no-...@dr...>]

We're excited to let you know that Josué Gutiérrez has invited you to Dropbox!

Josué has been using Dropbox to sync and share files online and across computers, and thought you might want it too.

Visit http://www.dropbox.com/link/20.uvPDOFRnU0/NjEyMjMxNTAwNw to get started.

- The Dropbox Team

____________________________________________________ 
To stop receiving invites from Dropbox, please go to http://www.dropbox.com/bl/3a380d0f6f70/davinci-develop%40lists.sourceforge.net

[Fwd: Re: [davinci-develop] Plugin SDK]

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

Forwarded because Elio's post was sent to /dev/null :?

Re: [davinci-develop] Plugin SDK

[<el...@mi...>]

> Great! That sounds good :). Hopefully I'll get my computer back on 
> it's legs soon...the transformer died, and I also got my new HDD, so 
> I've been copying everything over.
>
Don't worry, take your time.

>> Perhaps the most obvious way is to create a separate CVS module, so 
>> we  don't have a mess in the main davinci module. This aproach have 
>> one important inconvenient: Some unit code have to be shared between 
>> the main DaVinci program and the plugins, so we would need to have a 
>> duplicate in each module. I don't have to say that it will be a pain 
>> when the file updates in one module, and it's not updated in the other.
>
>
> Well, I donno... The advantage to having the sdk code in a different 
> module is that we can develop is seperately keep stable sdk in the 
> main davinci module as well develop another version of the sdk. Of 
> course, this does have the problem that you highlighted...a bunch of 
> different versions of the files to keep current :(. Maybe we could 
> have a script that would check out the sdk source and make 
> symlinks...that wouldn't be very compatible with Windows though. So I 
> agree that having everything in the same module would probably be the 
> best...
>
If we put a cvs co sdk then we no longer have the stable copy of th SDK :).
We should only share data structure definitions and function prototypes,
i. e. the interface sections of the SDK units (think c header files),
but still there's the problem of stability, maybe we can just develop
the IDE and the SDK togheter and just release them togheter?

>> Alternatively, we can put the SDK code into a sdk directory inside 
>> davinci module. This way we have everything in one place, and 
>> everything is sync'ed. We have to make sure we don't mess with other 
>> units.
>
>
> Sounds good to me :).
>
Good, cause that's the way i'm making it :).

Re: [davinci-develop] Plugin SDK

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

> Great! That sounds good :). Hopefully I'll get my computer back on 
> it's legs soon...the transformer died, and I also got my new HDD, so 
> I've been copying everything over.
>
Don't worry, take your time.

>> Perhaps the most obvious way is to create a separate CVS module, so 
>> we  don't have a mess in the main davinci module. This aproach have 
>> one important inconvenient: Some unit code have to be shared between 
>> the main DaVinci program and the plugins, so we would need to have a 
>> duplicate in each module. I don't have to say that it will be a pain 
>> when the file updates in one module, and it's not updated in the other.
>
>
> Well, I donno... The advantage to having the sdk code in a different 
> module is that we can develop is seperately keep stable sdk in the 
> main davinci module as well develop another version of the sdk. Of 
> course, this does have the problem that you highlighted...a bunch of 
> different versions of the files to keep current :(. Maybe we could 
> have a script that would check out the sdk source and make 
> symlinks...that wouldn't be very compatible with Windows though. So I 
> agree that having everything in the same module would probably be the 
> best...
>
If we put a cvs co sdk then we no longer have the stable copy of th SDK :).
We should only share data structure definitions and function prototypes,
i. e. the interface sections of the SDK units (think c header files),
but still there's the problem of stability, maybe we can just develop
the IDE and the SDK togheter and just release them togheter?

>> Alternatively, we can put the SDK code into a sdk directory inside 
>> davinci module. This way we have everything in one place, and 
>> everything is sync'ed. We have to make sure we don't mess with other 
>> units.
>
>
> Sounds good to me :).
>
Good, cause that's the way i'm making it :).

Re: [davinci-develop] Plugin SDK

[<el...@mi...>]

> Great! That sounds good :). Hopefully I'll get my computer back on 
> it's legs soon...the transformer died, and I also got my new HDD, so 
> I've been copying everything over.
>
Don't worry, take your time.

>> Perhaps the most obvious way is to create a separate CVS module, so 
>> we  don't have a mess in the main davinci module. This aproach have 
>> one important inconvenient: Some unit code have to be shared between 
>> the main DaVinci program and the plugins, so we would need to have a 
>> duplicate in each module. I don't have to say that it will be a pain 
>> when the file updates in one module, and it's not updated in the other.
>
>
> Well, I donno... The advantage to having the sdk code in a different 
> module is that we can develop is seperately keep stable sdk in the 
> main davinci module as well develop another version of the sdk. Of 
> course, this does have the problem that you highlighted...a bunch of 
> different versions of the files to keep current :(. Maybe we could 
> have a script that would check out the sdk source and make 
> symlinks...that wouldn't be very compatible with Windows though. So I 
> agree that having everything in the same module would probably be the 
> best...
>
If we put a cvs co sdk then we no longer have the stable copy of th SDK :).
We should only share data structure definitions and function prototypes,
i. e. the interface sections of the SDK units (think c header files),
but still there's the problem of stability, maybe we can just develop
the IDE and the SDK togheter and just release them togheter?

>> Alternatively, we can put the SDK code into a sdk directory inside 
>> davinci module. This way we have everything in one place, and 
>> everything is sync'ed. We have to make sure we don't mess with other 
>> units.
>
>
> Sounds good to me :).
>
Good, cause that's the way i'm making it :).

Re: [davinci-develop] Plugin SDK

[<el...@mi...>]

> Great! That sounds good :). Hopefully I'll get my computer back on 
> it's legs soon...the transformer died, and I also got my new HDD, so 
> I've been copying everything over.
>
Don't worry, take your time.

>> Perhaps the most obvious way is to create a separate CVS module, so 
>> we  don't have a mess in the main davinci module. This aproach have 
>> one important inconvenient: Some unit code have to be shared between 
>> the main DaVinci program and the plugins, so we would need to have a 
>> duplicate in each module. I don't have to say that it will be a pain 
>> when the file updates in one module, and it's not updated in the other.
>
>
> Well, I donno... The advantage to having the sdk code in a different 
> module is that we can develop is seperately keep stable sdk in the 
> main davinci module as well develop another version of the sdk. Of 
> course, this does have the problem that you highlighted...a bunch of 
> different versions of the files to keep current :(. Maybe we could 
> have a script that would check out the sdk source and make 
> symlinks...that wouldn't be very compatible with Windows though. So I 
> agree that having everything in the same module would probably be the 
> best...
>
If we put a cvs co sdk then we no longer have the stable copy of th SDK :).
We should only share data structure definitions and function prototypes, 
i. e. the interface sections of the SDK units (think c header files), 
but still there's the problem of stability, maybe we can just develop 
the IDE and the SDK togheter and just release them togheter?

>> Alternatively, we can put the SDK code into a sdk directory inside 
>> davinci module. This way we have everything in one place, and 
>> everything is sync'ed. We have to make sure we don't mess with other 
>> units.
>
>
> Sounds good to me :).
>
Good, cause that's the way i'm making it :).

Re: [davinci-develop] Plugin SDK

[<el...@mi...>]

Sorry to take all that time to reply.

Paul Hampson wrote:

> Is there no way to link in CVS? So like you would create links in Linux?
>
The problem is that we don't control the server. Also, CVS doesn't 
handle symlinks very well and Symlinks only work in POSIX systems.

> After a bit of digging on google, i came up with this... 
> http://lists.gnu.org/archive/html/info-cvs/2003-07/msg00024.html is it 
> of any use?
>
That's complicated... May work, dunno. Didn't read all of it :).

Re: [davinci-develop] Plugin SDK

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

Hi Elio,

> I'm starting to write the plugin SDK (the set of libraries and tools 
> to create DaVinci plugins)

Great! That sounds good :). Hopefully I'll get my computer back on it's 
legs soon...the transformer died, and I also got my new HDD, so I've 
been copying everything over.

> Perhaps the most obvious way is to create a separate CVS module, so 
> we  don't have a mess in the main davinci module. This aproach have 
> one important inconvenient: Some unit code have to be shared between 
> the main DaVinci program and the plugins, so we would need to have a 
> duplicate in each module. I don't have to say that it will be a pain 
> when the file updates in one module, and it's not updated in the other.

Well, I donno... The advantage to having the sdk code in a different 
module is that we can develop is seperately keep stable sdk in the main 
davinci module as well develop another version of the sdk. Of course, 
this does have the problem that you highlighted...a bunch of different 
versions of the files to keep current :(. Maybe we could have a script 
that would check out the sdk source and make symlinks...that wouldn't be 
very compatible with Windows though. So I agree that having everything 
in the same module would probably be the best...

> Alternatively, we can put the SDK code into a sdk directory inside 
> davinci module. This way we have everything in one place, and 
> everything is sync'ed. We have to make sure we don't mess with other 
> units.

Sounds good to me :).

-- 
Taj

Re: [davinci-develop] Plugin SDK

[Paul H. <p.h...@ds...>]

Is there no way to link in CVS? So like you would create links in Linux?

After a bit of digging on google, i came up with this...=20
http://lists.gnu.org/archive/html/info-cvs/2003-07/msg00024.html is it=20
of any use?

Paul

Elio Cuevas G=F3mez wrote:

> Hi all, how are you doing?
>
> I'm starting to write the plugin SDK (the set of libraries and tools=20
> to create DaVinci plugins) and i want to know your opinion in how and=20
> where should the SDK be in the CVS repository.
>
> Perhaps the most obvious way is to create a separate CVS module, so=20
> we  don't have a mess in the main davinci module. This aproach have=20
> one important inconvenient: Some unit code have to be shared between=20
> the main DaVinci program and the plugins, so we would need to have a=20
> duplicate in each module. I don't have to say that it will be a pain=20
> when the file updates in one module, and it's not updated in the other.
>
> Alternatively, we can put the SDK code into a sdk directory inside=20
> davinci module. This way we have everything in one place, and=20
> everything is sync'ed. We have to make sure we don't mess with other=20
> units.
>
> I'm more inclined to the last alternative, but if you have other ideas=20
> and comments, then we can discuss (and show some activity in the=20
> process).
>
> Good day.
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> davinci-develop mailing list
> dav...@li...
> https://lists.sourceforge.net/lists/listinfo/davinci-develop

[davinci-develop] Plugin SDK

[<el...@mi...>]

Hi all, how are you doing?

I'm starting to write the plugin SDK (the set of libraries and tools to 
create DaVinci plugins) and i want to know your opinion in how and where 
should the SDK be in the CVS repository.

Perhaps the most obvious way is to create a separate CVS module, so we  
don't have a mess in the main davinci module. This aproach have one 
important inconvenient: Some unit code have to be shared between the 
main DaVinci program and the plugins, so we would need to have a 
duplicate in each module. I don't have to say that it will be a pain 
when the file updates in one module, and it's not updated in the other.

Alternatively, we can put the SDK code into a sdk directory inside 
davinci module. This way we have everything in one place, and everything 
is sync'ed. We have to make sure we don't mess with other units.

I'm more inclined to the last alternative, but if you have other ideas 
and comments, then we can discuss (and show some activity in the process).

Good day.

Re: [davinci-develop] More help!

[<taj...@wi...>]

Hi Elio,
>
> But back in bussisnes, you probably noticed we have a new member. Well,
> you can blame me for that.
Yay! Sounds good, we could also use some more help :).

-- 
Taj

Re: [davinci-develop] I'm BLACKNASH

[<taj...@wi...>]

Hola Josué!
Bienvenido a el proyecto DaVinci! We could also use some more help
DaVinci! I'm Taj, one of the initial developers of DaVinic, along with
Elio and Paul. We haven't done too much work on DaVinci, but hopefully
getting another developer will get us to work more on it :).

I use Slackware, and am trying Gentoo Linux now...

Sounds good for the translation. I'll get you an login for our webpage and
setup support for multiple languages. If you want to start translating the
pages now, please feel free and send me the translations
(ta...@wi...).

-- 
Taj
> Hello .. How are you?
>
> I'm a new integrant of the Davinci group. Excuse me if my english
> doesn't very well, I'm mexican and I have all the wishes to learn
> about linux, and the best way of this, is doing a Distributions of
> these. I 'm a little boy in these themes, i have only 6 months working
> with DEBIAN , but since the first day I had the need to learn more.
>
> I propuse tralate the principal page to Spanish, i want to help in all
> of you want.
> I will search all the information to learn and do all about DAVINCI.
>
> Thanks for read this MAIL (my english is bad and i hope that you
> understead)
>
> Atte
>
> Josué  alias BLACKNASH
>
> BB||~BB
> The mind is the door to other universes...
> The mind is the door to be free...
> but .....
> I have the keep of your mind ...
> And I know all about your little world ..... BlacKNasH
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
> _______________________________________________
> davinci-develop mailing list
> dav...@li...
> https://lists.sourceforge.net/lists/listinfo/davinci-develop
>

[davinci-develop] More help!

[<el...@mi...>]

Hi all.

Well, first of all, i got tired of that Yahoo account so now i'm 
switching to this one (el...@mi...). I'm still reading my old account 
tho.

But back in bussisnes, you probably noticed we have a new member. Well, 
you can blame me for that.

So i guess i abused my admin rights a bit, cause i didn't ask you, mea 
culpa, just hope you are not too angry :). Anyway some extra help can't 
hurt, even if is small.

So let me be the first to say Welcome! I hope you have all the fun we 
are having developing DaVinci, the universal IDE. And learn some stuff 
in the proccess.

--Elio.

[davinci-develop] I'm BLACKNASH

[<eus...@gm...>]

Hello .. How are you?

I'm a new integrant of the Davinci group. Excuse me if my english
doesn't very well, I'm mexican and I have all the wishes to learn
about linux, and the best way of this, is doing a Distributions of
these. I 'm a little boy in these themes, i have only 6 months working
with DEBIAN , but since the first day I had the need to learn more.

I propuse tralate the principal page to Spanish, i want to help in all
of you want.
I will search all the information to learn and do all about DAVINCI.

Thanks for read this MAIL (my english is bad and i hope that you understead=
)

Atte=20

Josu=E9  alias BLACKNASH

BB||~BB
The mind is the door to other universes...
The mind is the door to be free...
but .....
I have the keep of your mind ...
And I know all about your little world ..... BlacKNasH

Re: [davinci-develop] HOWTO: Generate PDF's, HTML's from DocBook Files

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

Hi Elio,

> I think all document names in CVS should be lowercase, you know, to 
> prevent confusion and make typing commands easier ;).

I agree.

What about different directories for different guides?
I think we should have them, but make sure we don't end up with too many 
folders!
For example, we could have an API guide, a users guide, and other guides 
seperated into different folders. What do you guys think?

> Anyway i write this to inform you that a new Makefile is ready in docs 
> modules (if you are suscribed to davinci-cvs you already noticed). To 
> create the html documentation use just type "make". 

> This makefile can generate html, manpages and pdf, but only tried 
> html. I don't have fop and manpages require some special fields (i 
> think).

Great! I'll work on adding PDF and manpages soon. fop isn't the only 
processor...if you find another one let me know. fop was recommended by 
most websites... It was a bit hard to figure out and get working, but 
works fine after that ;). Some of you might already have it installed ;).

Neways, thanks!

As always, feel free to edit my texts.

-- 
Taj

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

Re: [davinci-develop] HOWTO: Generate PDF's, HTML's from DocBook Files

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

I think all document names in CVS should be lowercase, you know, to 
prevent confusion and make typing commands easier ;).

Anyway i write this to inform you that a new Makefile is ready in docs 
modules (if you are suscribed to davinci-cvs you already noticed). To 
create the html documentation use just type "make".

This makefile can generate html, manpages and pdf, but only tried html. 
I don't have fop and manpages require some special fields (i think).

Well, enjoy.

Re: [davinci-develop] HOWTO: Generate PDF's, HTML's from DocBook Files

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

Taj Morton escribió:

> Hi All,
> As you might of noticed, I just committed a bunch to CVS today 
> :D...Sorry!
>
> Here's how to generate (X)HTML file(s) from a DocBook file:
> cd to the directory which contains the docbook file. (davinci/docs?)
> xsltproc -o AboutPlugins.html xsl/html/docbook.xsl AboutPlugins.xml
>
> To generate a PDF, you need need fop from the Apache Project:
> http://xml.apache.org/fop/ (if you don't already have it).
>
> Then, run
> ~/fop-0.20.5/fop.sh -xml AboutPlugins.xml -xsl 
> docbook-xsl-1.66.0/fo/tldp-print.xsl -pdf AboutPlugins.pdf
>
Good! Now to put that in a Makefile.

[davinci-develop] HOWTO: Generate PDF's, HTML's from DocBook Files

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

Hi All,
As you might of noticed, I just committed a bunch to CVS today :D...Sorry!

Here's how to generate (X)HTML file(s) from a DocBook file:
cd to the directory which contains the docbook file. (davinci/docs?)
xsltproc -o AboutPlugins.html xsl/html/docbook.xsl AboutPlugins.xml

To generate a PDF, you need need fop from the Apache Project:
http://xml.apache.org/fop/ (if you don't already have it).

Then, run
~/fop-0.20.5/fop.sh -xml AboutPlugins.xml -xsl 
docbook-xsl-1.66.0/fo/tldp-print.xsl -pdf AboutPlugins.pdf

(given that you untarred the fop binary into your home directory).

Have fun!

(Note that I accidently called the xsl xls...I asked SF support to 
rename it, I'll assume they'll do it soon.)

-- 
Taj

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

Re: [davinci-develop] Plugin Implementation Document

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

Paul Hampson wrote:

>On Fri, 2004-09-10 at 16:00, Taj Morton wrote:
>  
>
>>Hi All,
>>Here's a document I just whipped up:
>>http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.pdf
>>http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.sxw
>>
>>It should answer your questions. Let me know what I should add. I'm 
>>going to convert to DocBook format and add to CVS (in the docs module).
>>    
>>
>
>The PDF contained lots of squares (which I presume are supposed to be
>letters?).. May need re-exporting :p
>  
>
That's odd. I just tried the PDF with xpdf and it worked.

BTW, I've converted to the file to docbook and put it in CVS under the 
docs module. I guess it'll show up in the webcvs in ~5 hrs. In the mean 
time you can check it out and mess with it.

You can view it here: http://www.wildgardenseed.com/Taj/AboutPlugins.html
Thanks to http://www.xml-dev.com/blog/test.php (DocBook XML converter 
and validator)

-- 
Taj

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

Re: [davinci-develop] Plugin Implementation Document

[Paul H. <p.h...@ds...>]

On Fri, 2004-09-10 at 16:00, Taj Morton wrote:
> Hi All,
> Here's a document I just whipped up:
> http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.pdf
> http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.sxw
> 
> It should answer your questions. Let me know what I should add. I'm 
> going to convert to DocBook format and add to CVS (in the docs module).

The PDF contained lots of squares (which I presume are supposed to be
letters?).. May need re-exporting :p

[davinci-develop] Plugin Implementation Document

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

Hi All,
Here's a document I just whipped up:
http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.pdf
http://www.wildgardenseed.com/Taj/davinci/AboutPlugins.sxw

It should answer your questions. Let me know what I should add. I'm 
going to convert to DocBook format and add to CVS (in the docs module).

-- 
Taj

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

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

Re: [davinci-develop] Plugin SDK and GUI

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

Elio Cuevas Gómez escribió:

> I'll leave the GUI for another moment.

I think this is the moment :)

I was thinking building the GUI into Davinci and call the GUI functions 
form plugins, but a better aproach as Taj said is to build the GUI into 
the plugins.

I like the idea, but there's a little problem: Libraries can't display 
LCL forms. Seems like a LCL problem so we'll probably need to hack it.

Alternatively we can define a generic GUI interface into DV, but that 
doesn't display GUI elements itself but relies in the plugins to draw 
them. For example a Qt plugin, a Gtk plugin, a Win32 plugint, etc...

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
>
>  
>

Re: [davinci-develop] Plugin SDK and GUI

[Paul H. <p.h...@ds...>]

On Wed, 2004-09-08 at 21:49, Elio Cuevas G=C3=B3mez wrote:
> So we need to create the GUI system and  a interface to access it form=20
> 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...

>=20
> So we need to provide a way to call DaVinci functions from plugins. My=20
> first idea is to let plugins resolve DaVinci symbols and use them. I'm=20
> not sure it's possible or portable. My other idea is to make davinci=20
> "export" it's sysbols by putting them in predefinded adresses.
>=20

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.

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

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

> What do you think?
>=20

I think I am going to learn a lot :p better go and buy some kind of
"Advanced Pascal" book...

Paul