[cssed-devel] =?ISO-8859-1?Q?Re:_[cssed-devel]_New_plugin:_developer_doc_plugi?= =?ISO-8859-1?Q?n_=28Modifi=E9_par_Mich=E8le_Garoche=29?=

[<mic...@ea...>]

Le 20 sept. 2004, =E0 12:53, Iago Rubio a =E9crit :
> On Mon, 2004-09-20 at 10:07, Mich=E8le Garoche wrote:
>> Le 20 sept. 2004, =E0 9:22, Iago Rubio a =E9crit :
>>> On Mon, 2004-09-20 at 00:28, Mich=E8le Garoche wrote:
>> Because, basically it's the same call as for the API plugin doc, if=20=

>> you
>> add the possibility to have browser, the code is not needed, only for
>> sure the location of the web site and on the online doc. So once the
>> structure for the browser is here, I use it to go to the web site or
>> the online doc.
> Well it's still to come, so it could be ok or not.
Oh, yes, of course, it will surely need changes, but the basis will be=20=

there.

> 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.
That's good.

> [snip]

> If you want feature X, use or code a plugin.
Yes, I understood this that way, but would not be a good thing that the=20=

cssed project be the location where all the plugins are grouped? So=20
that anyone can know which one exists on which platform.

> 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=20
> package.
> What do you need for that ?
I need a change in the plugin architecture so that I can hook up the=20
menu in the help menu. I need also a path for the plugin doc in the=20
configure (at the moment it is hardcoded), this way it can be easily=20
adapt to any system. Then let me think about it after I have made the=20
new doc (end of the week). I'll test what changes it involves to patch=20=

the plugin as an integrated part and will tell you if I really need=20
something more. I don't think so, but who knows. I think I can make a=20
bundle with both sources, I should try it.

More generally, I think if you add in mind a whole integration for=20
different languages, etc..., we need access to any existing menu in the=20=

main package.

> 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.
That goes without saying 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 ;)
Perfectly ok here.

>> Or do you mean, it would be useful I develop some plugins I put on
>> sourceforge in my project page, then you can pick up what you find
>> useful or something like that?
> Of course.
> I suposse fink have some configuration scripts, isn't it ?
Yes, but there are mainly to build the package, so I don't think there=20=

is any useful to plugin, apart from compiling it.

> Imagine you build a plugin that adds highlighting, autocompletion and
> run some tests to build fink scripts.
There is no such concept as fink scripts. Or do you mean something like=20=

perl script, python script, ruby script? Yes, this is possible, though=20=

it presupposes I know those language, which is far from being the case.

> For me it will be ok if you opens a separate project in sourceforge,
> with the fink plugin and distribute it yourself.
I don't feel like so at the moment. Maybe in the long run.
>
> 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 ;)
That's better for me, at least it has more sense. It ensures that all=20
plugins go the same direction.

> You know C, and that's the most important thing.
A bit rusty.

> You just need to know a little better g_lib and gtk (both are easy),
Not at all for me, as I don't know anything about it; I discover it=20
with cssed.

>  as
> the plugin's API - at least it's my point of view - is really easy.
Yes, this one I've understand it.

> 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.
Perfect
>
> But those features are still on paper ;)
> I don't want even to think on it until we release current cssed's
> version.
Sure.

Now I'll work only on the user's doc version 0.3.0. Hope this will be=20
finished at the end of the week.

Mich=E8le
<http://micmacfr.homeunix.org>