Re: [cssed-devel] New plugin: developer doc plugin =?ISO-8859-1?Q?=28Modifi=E9?= par =?ISO-8859-1?Q?Mich=E8le?= Garoche)

[Iago R. <iag...@hi...>]

On Mon, 2004-09-20 at 10:07, Mich=C3=A8le Garoche wrote:
> Le 20 sept. 2004, =C3=A0 9:22, Iago Rubio a =C3=A9crit :
>=20
> > On Mon, 2004-09-20 at 00:28, Mich=C3=A8le Garoche wrote:
> >> which is only for mac in cvs, so that I can have it in the port? Then
> >> when the other way to do it is done, I'll drop the code.
> >
> > :???
> > Why?
> Because, basically it's the same call as for the API plugin doc, if you=20
> add the possibility to have browser, the code is not needed, only for=20
> sure the location of the web site and on the online doc. So once the=20
> structure for the browser is here, I use it to go to the web site or=20
> the online doc.

Well it's still to come, so it could be ok or not.

> >>> The plugin API is open for people to do whatever plugin they wants,=20
> >>> and
> >>> can be platform dependant and shiped only in one platform.
> >> That's not possible, since it requires for the plugin doc for example
> >> to incorporate the html files in it. Hence, it should be put on cvs,
> >> otherwise it is not possible to port it. Or you will end up with a
> >> bunch of plugins you have no control on them.
> > Surely it will end with a bunch of plugins I'll have no control over
> > them :)
> > That's what I want, more people implied, more people coding and
> > mantaining their own plugins.
> Oh, that's a strange idea. But well, we'll see.

I'd like to end with a really modular and configurable cssed, to allow
users to extend it for other tasks not only for css.

I'd like to extend it to support some server configuration files - as
web developers use to deal with servers - and to allow people to code
also PHP if they want.

Of course some of those features are not needed in a css editor, and
most people could find stupid to have autocompletion for Apache conf
files - as example.

That's why the plugins seems for me a big grade of independence and
users' choice.

If you want feature X, use or code a plugin.

This will end with discussions as "I think this feature that adds 30 Mb
dependencies is needed in cssed".

> > We should build a documentation package that follows the fink guide
> > lines.
> The one I've made follow it, except that you should change the location=20
> of the menu, should be under help. And normally, should be supply with=20
> the main package.

I'd like to maintain the main package <1Mb, and it's not possible
shipping the docs.

Lot's of apps in Linux world have a separate doc, as users prefer the
web where docs use to be updated.

ITOH if the doc is necesary in OsX we could ship it in the same package.
What do you need for that ?

>  Then porters can choose to install it or not, I=20
> personally always install the developers doc. As for the location of=20
> the doc itself it all depends if it uses gnome help or not and which=20
> version of gnome it uses. But generally when using gnome, the makefile=20
> already has the right routine to install it. And for the Mac I patch,=20
> to respect special post/pre install/remove scripts.

I'd like to avoid to bound cssed for any desktop environment. It had
it's work to make it desktop independent, and I'd like docs won't break
it.

It's what I told you the help packaging must be carefully planed.

Right now the help menus are a good advance on bringing help for users.

Now we've got time to plan the next step carefully ;)

> > If he wants to be bound to the package manager, he have no need to
> > install something out of fink. If he want to develop or install a third
> > party plugin, I have little to do with that.
> Yes, of course. But then, you have no idea what exists outside of=20
> cssed, no?

Yep :)

> Or do you mean, it would be useful I develop some plugins I put on=20
> sourceforge in my project page, then you can pick up what you find=20
> useful or something like that?

Of course.=20

I suposse fink have some configuration scripts, isn't it ?

Imagine you build a plugin that adds highlighting, autocompletion and
run some tests to build fink scripts.

For me it will be ok if you opens a separate project in sourceforge,
with the fink plugin and distribute it yourself.=20

If I find it usefull for all cssed's users, I could ask you to join the
team and maintain the plugin in cssed's CVS. Or even fork the plugin or
take from it what's ok for cssed ;)

> Anyway at the moment, I don't feel as=20
> skilled as to develop something useful myself.

You know C, and that's the most important thing.

You just need to know a little better g_lib and gtk (both are easy), as
the plugin's API - at least it's my point of view - is really easy.

Requirements to build cssed plugins are (in importance order):
* Good knoweledge of C.
* To know GLib and GTK.
* To know the cssed's API.

ITOH the plugin API should be extended a little, and it's a draft now.

I'm planning some improvements as the CssedToolbar, loadable
CssedFileTypeManagers, loadable CssedUiModules and some changes to the
menus to modularize cssed a little bit further.

But those features are still on paper ;)

I don't want even to think on it until we release current cssed's
version.
--=20
Iago Rubio  =20
- Home page    * http://www.iagorubio.com=20
- Last project * http://cssed.sourceforge.net        =20
- GPG Keyserv  * pgp.rediris.es id=3D0x909BD4DD