[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 19 sept. 2004, =E0 17:42, Iago Rubio a =E9crit :
>>>> That's to say the source files are not delivered, just the doc in=20=

>>>> html
>>>> format, but the user can browse it from within cssed.
>>> This should be carefully planned as the problems will be - surely -=20=

>>> in
>>> the packaging, not the plugin itself.
>> Just before the release of cssed, I think, then the packaging is no
>> problem. It is just a directories cascade of html files and images
>> files.
> Ok, will go for it next release then :)
Why not this one?

>>>> As for browsing I use merely the open command, and the doc is =
placed
>>>> in
>>>> usr/share/cssed/plugindoc. A patch to src/plugindoc.c is necessary=20=

>>>> if
>>>> the doc should not be placed at this location. A new item menu is
>>>> added
>>>> to the Plugins menu to browse the doc.
>>> Much better to define it at compile time:
>>> plugindocurl =3D PACKAGE_DATA_DIR "/" PACKAGE =
"/plugindoc/index.html"
>> The problem is that's better go in share/cssed/plugindoc, not in
>> share/cssed-plugindoc-plugin/, that's why I've hardcoded, so we need =
a
>> where-to-install-the-doc variable in configure.in or Makefile.am.
> We can partially hardcode it with
> plugindocurl =3D PREFIX "/cssed/plugindoc"
No, you should have the right file to open, i.e. the index.html is=20
necessary.

>
>>>> Tell me if it's OK. Then I'll upload both new doxygen files =
(updated
>>>> to
>>>> the latest headers) and the new plugin to my site, because they are
>>>> too
>>>> big to put them on the mailing list and post here the urls.
>>> I'm making some sightly changes to it, as change system() with
>>> g_spawn_*
>>> to have some error checking (right now it fails silently).
>> Ok, I let you do the hard work :-) Not familiar at all with =
g_spawn...
>> stuff. As of now it fails silently because I don't make any error
>> check, but it can be done too with system().
> Yes, but as we know g_lib is the same in all platforms - and without
> g_lib cssed can't build - I think it's more portable to use g_lib
> instead.
Don't tell me open is not portable, it is in the standard lib :-) and=20
system is on all ports, as far as I know.

>>> Should we go for this before this release, and "unfreeze" the code =
to
>>> get docs into a plugin ??
>> Well, all depends if you think you can do that in a reasonable delay,
>> otherwise we can just release without it, but well it's so nice to=20
>> have
>> it...
> It's a time issue. I'd like to release it with a good interface and
> updating the plugin's API acordling. It can take us a couple of weeks=20=

> to
> have all bits in place and there've been a long time with no release.
That's what I suggest put it as is, as it works, and then change it to=20=

gspawn in the next release.

>
>>> This way we could make various doc packages depending on the browser
>>> used.
>> Oh, no, impossible to do that, you'll never end adding new doc=20
>> packages
>> depending on the wealth of existing browsers. Just a single package
>> with a field where you can change the command, exactly what is used =
in
>> gnome2: open %s, then you can change it if you want. That's why I =
used
>> the system() command. But g_spawn could do the same I'll guess, just
>> the string you send should be open .... %s ....., but we could add a
>> static text field where we explain the strings for the most popular
>> browser.
> Some different systems will use different file formats. yelp (Gnome)
> uses dookbook directly, and Win32 uses *chm compressed files.
> That's why we must plan it carefully.
But I told about html files, not about docbook, anyway you cannot do it=20=

as is, since the files are sgml files for the standard doc and doxygen=20=

files for the API doc, so that anyway you deliver html files and as far=20=

as I know all systems read html files.

Another point which comes in view is that I cannot add 20 plugins for=20
cssed in fink.

> If we limit users to web browsers. But if we use help browsers (as =
yelp
> and htmlhelp ) this will not work.
Anyway, if we use help browsers, the doc should change, as it is not=20
exploitable as is, but any help browser (sgml or doxygen files).
>
> Help browsers have some bennefits over web browsers ( as side panel
> index and search ).
No need to have that since the doc is also in pdf format and with a pdf=20=

plugin, which all browsers have, you can read the index, search the=20
text, etc..

> Should we only use web browsers for help or use also help browsers ?
For me browsers are better, but well...

> As example in Windowsland - from the users' point of view - is =
annoying
> to show the help in a web browser.
Because probably they use Internet Explorer or Netscape which are not=20
the better ones. Or you can make a patch just for window users, and put=20=

browsers for unix users.


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