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 Fri, 2004-09-17 at 12:26, Mich=C3=A8le Garoche wrote:
> Sorry, again sourceforge net blocks my ISP, so I forward to you. They=20
> become really crazy, or I become crazy with them :-)

Well slashdot blocked the whole Telefonica's IPs some time ago (The
bigger spanish ISP).

I think they're getting crazy, not you.

> Le 17 sept. 2004, =C3=A0 11:57, Iago Rubio a =C3=A9crit :
>=20
[snip]
> >> That's to say the source files are not delivered, just the doc in html
> >> format, but the user can browse it from within cssed.
> > This should be carefully planned as the problems will be - surely - in
> > the packaging, not the plugin itself.
> Just before the release of cssed, I think, then the packaging is no=20
> problem. It is just a directories cascade of html files and images=20
> files.

Ok, will go for it next release then :)

> >> As for browsing I use merely the open command, and the doc is placed=20
> >> in
> >> usr/share/cssed/plugindoc. A patch to src/plugindoc.c is necessary if
> >> the doc should not be placed at this location. A new item menu is=20
> >> 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=20
> share/cssed-plugindoc-plugin/, that's why I've hardcoded, so we need a=20
> where-to-install-the-doc variable in configure.in or Makefile.am.

We can partially hardcode it with=20
plugindocurl =3D PREFIX "/cssed/plugindoc"

> >> Tell me if it's OK. Then I'll upload both new doxygen files (updated=20
> >> to
> >> the latest headers) and the new plugin to my site, because they are=20
> >> 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=20
> > 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...=20
> stuff. As of now it fails silently because I don't make any error=20
> 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.

> >> I wonder if the right place in the menu should not be in Help menu
> >> (I've put it in Plugins menu). Then I could do the same for the user's
> >> doc, probably in the same plugin.
> > I will write the "default browser" part of the configuration file.
> > It's something that should be done a long time ago.
> > I must also interface in some way all help functions with the plugins
> > to  fix all documentation/help issues.
> > Then we could do the doc plugin much more usable.
> > What do you think ?
> Yes, of course, that would be the best thing to do.

Will go for it, then.

> > 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,=20
> otherwise we can just release without it, but well it's so nice to have=20
> 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 to
have all bits in place and there've been a long time with no 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 packages=20
> depending on the wealth of existing browsers. Just a single package=20
> with a field where you can change the command, exactly what is used in=20
> gnome2: open %s, then you can change it if you want. That's why I used=20
> the system() command. But g_spawn could do the same I'll guess, just=20
> the string you send should be open .... %s ....., but we could add a =20
> static text field where we explain the strings for the most popular=20
> 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.=20

> > I mean here, a web browser - as mozilla - or a help browser as yelp on
> > Gnome or *chm viewer on Win using the htmphelp API.
> The strings used for the most popular browser are already in bluefish,=20
> I give them below:
>=20
> open %s : pick the default browser
> open -a 'Safari' %s
> open -a 'Firefox' %s
> open -a 'Opera' %s
> dillo %s
> galeon -x %s
> mozilla -remote 'openURL(%s,new-window)' || mozilla %s
> gnome-moz-remote --newwin %s
> opera -remote 'openURL(%s,new-window))' || opera %s
> {libdir}/netscape/477/communicator/communicator-smotif %s

Those will be fine in the "externall command" window I'm planning :)

> > Is there any default help viewer on Mac ?
> No, there's a default browser, Safari, but the users are free to change=20
> it, and they do it. So I don't think, this is a good approach, but just=20
> a browser, then I can patch it for Mac, and put a dialog to change the=20
> browser. This way, it will work on all platforms with any browser.

If we limit users to web browsers. But if we use help browsers (as yelp
and htmlhelp ) this will not work.

Help browsers have some bennefits over web browsers ( as side panel
index and search ).

Should we only use web browsers for help or use also help browsers ?

As example in Windowsland - from the users' point of view - is annoying
to show the help in a web browser.=20
--=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