cssed-devel — cssed development discussion

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

Re: [cssed-devel] New plugin: developer doc plugin

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

Le 19 sept. 2004, =E0 17:09, Iago Rubio a =E9crit :

> Hi Michelle, sorry for my late response. I've just taken a couple of
> vacation days to celebrate my birdthday (34 years old) :)
Happy birthday to you, then :-)

>
> On Sat, 2004-09-18 at 19:51, Mich=E8le Garoche wrote:
>> Apropos this, you told me you made some changes, but you did not send
>> them to me.
> No I didn't made the changes yet, because I want to give an API access
> to let plugins know the default browser command.
Still not convinced this is the right way to do it. Why do you want to=20=

force the user to use a default browser?

> This will involve changes in the preferences dialog, the configuration
> parser, and the CssedWindow struct, so I will do it in next release.
See what I said about multiple user's machine, there should be a=20
configuration per user if you want to go this way.

> I'd like to start a monthly release ( or each two months ) instead of
> this really long time window betwee 0.2.1 and 0.3.
Oh, much too much. Think the doc should change too, there's no time to=20=

code, test, translate, change the doc in a month, unless we work day=20
and night just for cssed.

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

Re: [cssed-devel] cssed: Added subitems to help menu

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

Le 19 sept. 2004, =E0 17:26, Iago Rubio a =E9crit :
> On Sat, 2004-09-18 at 20:05, Mich=E8le Garoche wrote:
>> Thinking about that, it's not a good option, because the user may =
wish
>> to view either the preview (future addition), or the web site, or the
>> docs in another browser than the default. He should have the choice =
at
>> any time, as cssed is aimed at web site designers, who may want to=20
>> test
>> if the style sheets work correctly in any available browser.
> Yes, you're right. I will do one entry for the default browser, other
> for the help browser, and one "external commads" window to let users =
to
> use whatever command they want.
And don't forgot that you can be on a multiple users machine (as is the=20=

Mac), so that the default browser (if any, I still consider this as a=20
bad option), and any other added browser, should not be a global option=20=

(i.e., not in the pc file), but a user's option.

>> By the way I've discovered that the #ifdef DARWIN is not taken into
>> account, if it is compiled with -DDARWIN. So that I need to know =
where
>> you use that, in all packages. It could have been dramatical with ipc
>> queues.
> It should work with -DDARWIN in the gcc command line.
Yes, I know it now, but I did not know it the day before yesterday.

> ITOH, #ifdef DARWIN is not used in cssed's code, only in the plugins
> code. As example in find in files plugin, #if defined(DARWIN).
It is used in the part I've made for the help menu: access to the web=20
site and to the online doc. This should not be in a plugin, but right=20
in the main package.

> Well, I prefer to do it in next release.
I'll put it in the mac version as is.

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

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

Re: [cssed-devel] cssed: Added subitems to help menu

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

On Sat, 2004-09-18 at 20:12, Mich=C3=A8le Garoche wrote:
> Le 18 sept. 2004, =C3=A0 20:05, Mich=C3=A8le Garoche a =C3=A9crit :
> Sorry, I forgot to add the changes (not committed). I've not translated=20
> the strings yet.

Don't worry, we've got a week.

Tomorrow I will download source for the windows port, but will just be
frozen the src folders.

We can still commit changes to any other folder in CVS.

The Win32 version does not depend on cssed's build scripts, nor in
cssed's language files.
--=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

Re: [cssed-devel] cssed: Added subitems to help menu

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

On Sat, 2004-09-18 at 20:05, Mich=C3=A8le Garoche wrote:
> Le 17 sept. 2004, =C3=A0 12:29, Mich=C3=A8le Garoche a =C3=A9crit :
> > Le 17 sept. 2004, =C3=A0 10:31, Iago Rubio a =C3=A9crit :
> >> On Thu, 2004-09-16 at 23:50, Mich=C3=A8le Garoche wrote:
> >>> I've added two items in the Help menu: web site and online doc.
> >> The problem is to know the default browser in all platforms, that's=20
> >> why
> >> I did not use external viewers yet, I was waiting to add an entry in=20
> >> the
> >> config dialog to let the user to choose his/her preferred browser.
> > Yes, of course, it's better.
> Thinking about that, it's not a good option, because the user may wish=20
> to view either the preview (future addition), or the web site, or the=20
> docs in another browser than the default. He should have the choice at=20
> any time, as cssed is aimed at web site designers, who may want to test=20
> if the style sheets work correctly in any available browser.

Yes, you're right. I will do one entry for the default browser, other
for the help browser, and one "external commads" window to let users to
use whatever command they want.

> >>> If it's ok, just tell me, I'll commit the changes.
> >> If you could add it between ifdefs it would be great.
> > OK, I'll do that.
> I've added ifdefs, so normally it is compiled without help additions.=20
> To compile with it, just add --with-help-menus to configure and=20
> -DWITH_HELP_MENUS to preprocessor compile flags.

Ok.

> By the way I've discovered that the #ifdef DARWIN is not taken into=20
> account, if it is compiled with -DDARWIN. So that I need to know where=20
> you use that, in all packages. It could have been dramatical with ipc=20
> queues.

It should work with -DDARWIN in the gcc command line.

ITOH, #ifdef DARWIN is not used in cssed's code, only in the plugins
code. As example in find in files plugin, #if defined(DARWIN).

Just adding -DDARWIN to CFLAGS if $OSTYPE =3D "DARWIN".

> >> This way I can test it, and disable it if I find problems anywhere :)
> > Basically it is the same command as for plugindoc. So based on what=20
> > you said apropos plugindoc, I'll add  a static field to give the=20
> > strings for most popular browsers, then an entry to change it.
> I did not adventure in this, since it's too difficult for me at the=20
> time being, but there are mozilla, dillo, galeon, gnome as proposed=20
> browser.
>=20
> I'd really like to have it in the release.

Well, I prefer to do it in next release.=20

What I'm sure is I will not wait three months again for a new release :)
--=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

Re: [cssed-devel] cssed: Added subitems to help menu

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

On Fri, 2004-09-17 at 12:29, Mich=C3=A8le Garoche wrote:
> Le 17 sept. 2004, =C3=A0 10:31, Iago Rubio a =C3=A9crit :
>=20
> > On Thu, 2004-09-16 at 23:50, Mich=C3=A8le Garoche wrote:
> >> I've added two items in the Help menu: web site and online doc.
> > The problem is to know the default browser in all platforms, that's why
> > I did not use external viewers yet, I was waiting to add an entry in=20
> > the
> > config dialog to let the user to choose his/her preferred browser.
> Yes, of course, it's better.

I will be done soon :)

> >> If it's ok, just tell me, I'll commit the changes.
> > If you could add it between ifdefs it would be great.
> OK, I'll do that.

Great thanks !

> > This way I can test it, and disable it if I find problems anywhere :)
> Basically it is the same command as for plugindoc. So based on what you=20
> said apropos plugindoc, I'll add  a static field to give the strings=20
> for most popular browsers, then an entry to change it.
>=20
> > Remember we're in code freeeeze ;)
> Oops, forgot that :-)

Don't worry.

> If you prefer, we release as is,

Yes, I prefer to release it as is now. The cahnges - to be well done -
wil require some changes in the plugins API and some parts of cssed.

> just wait till the end of the week-end=20
> that I'll have time to update the doc.

You've got the whole week. I'd like to release it for windows also, and
I must code the port, so I will not release until the end of this -
incoming - week.

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

Re: [cssed-devel] New plugin: developer doc plugin

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

Hi Michelle, sorry for my late response. I've just taken a couple of
vacation days to celebrate my birdthday (34 years old) :)

On Sat, 2004-09-18 at 19:51, Mich=C3=A8le Garoche wrote:
> Apropos this, you told me you made some changes, but you did not send=20
> them to me.

No I didn't made the changes yet, because I want to give an API access
to let plugins know the default browser command.

This will involve changes in the preferences dialog, the configuration
parser, and the CssedWindow struct, so I will do it in next release.

I'd like to start a monthly release ( or each two months ) instead of
this really long time window betwee 0.2.1 and 0.3.

We'll see those changes soon in CVS.
--=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

Re: [cssed-devel] cssed: Added subitems to help menu

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

Le 18 sept. 2004, à 20:05, Michèle Garoche a écrit :
Sorry, I forgot to add the changes (not committed). I've not translated 
the strings yet.

Re: [cssed-devel] cssed: Added subitems to help menu

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

Le 17 sept. 2004, =E0 12:29, Mich=E8le Garoche a =E9crit :
> Le 17 sept. 2004, =E0 10:31, Iago Rubio a =E9crit :
>> On Thu, 2004-09-16 at 23:50, Mich=E8le Garoche wrote:
>>> I've added two items in the Help menu: web site and online doc.
>> The problem is to know the default browser in all platforms, that's=20=

>> why
>> I did not use external viewers yet, I was waiting to add an entry in=20=

>> the
>> config dialog to let the user to choose his/her preferred browser.
> Yes, of course, it's better.
Thinking about that, it's not a good option, because the user may wish=20=

to view either the preview (future addition), or the web site, or the=20
docs in another browser than the default. He should have the choice at=20=

any time, as cssed is aimed at web site designers, who may want to test=20=

if the style sheets work correctly in any available browser.

>>> If it's ok, just tell me, I'll commit the changes.
>> If you could add it between ifdefs it would be great.
> OK, I'll do that.
I've added ifdefs, so normally it is compiled without help additions.=20
To compile with it, just add --with-help-menus to configure and=20
-DWITH_HELP_MENUS to preprocessor compile flags.

By the way I've discovered that the #ifdef DARWIN is not taken into=20
account, if it is compiled with -DDARWIN. So that I need to know where=20=

you use that, in all packages. It could have been dramatical with ipc=20
queues.

>> This way I can test it, and disable it if I find problems anywhere :)
> Basically it is the same command as for plugindoc. So based on what=20
> you said apropos plugindoc, I'll add  a static field to give the=20
> strings for most popular browsers, then an entry to change it.
I did not adventure in this, since it's too difficult for me at the=20
time being, but there are mozilla, dillo, galeon, gnome as proposed=20
browser.

I'd really like to have it in the release.

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

Re: [cssed-devel] New plugin: developer doc plugin

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

Apropos this, you told me you made some changes, but you did not send=20
them to me.

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

Re: [cssed-devel] Version number of next release

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

On Fri, 2004-09-17 at 09:49, Mich=C3=A8le Garoche wrote:
> I'm currently changing the doc to integrate changes between 0.2.1 and=20
> 0.3.0 version.

Great idea.

> Is there any features that are not already in cvs (apart from plugindoc=20
> and the two menus in help menu I've added yesterday, three awaiting for=20
> approval)?

Nope.
--=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

Re: [cssed-devel] cssed: Added subitems to help menu

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

Le 17 sept. 2004, =E0 10:31, Iago Rubio a =E9crit :

> On Thu, 2004-09-16 at 23:50, Mich=E8le Garoche wrote:
>> I've added two items in the Help menu: web site and online doc.
> The problem is to know the default browser in all platforms, that's =
why
> I did not use external viewers yet, I was waiting to add an entry in=20=

> the
> config dialog to let the user to choose his/her preferred browser.
Yes, of course, it's better.

>> If it's ok, just tell me, I'll commit the changes.
> If you could add it between ifdefs it would be great.
OK, I'll do that.

> This way I can test it, and disable it if I find problems anywhere :)
Basically it is the same command as for plugindoc. So based on what you=20=

said apropos plugindoc, I'll add  a static field to give the strings=20
for most popular browsers, then an entry to change it.

> Remember we're in code freeeeze ;)
Oops, forgot that :-)

If you prefer, we release as is, just wait till the end of the week-end=20=

that I'll have time to update the doc.

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

Re: [cssed-devel] New plugin: developer doc plugin

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

On Wed, 2004-09-15 at 03:44, Mich=C3=A8le Garoche wrote:
> I've just finished the plugin to view the doc for plugins in the user's=20
> favorite browser.
>=20
> The whole process consists of:
>=20
> 1 - Copying cssed/include/*.h into cssed-plugin-doc/include to be sure=20
> to have the latest headers
> 2 - Generate html with doxygen to be sure to have the latest docs
> 3 - Integrate cssed-plugin-doc/html into a new plugin, namely=20
> cssed-plugindoc-plugin
>=20
> That's to say the source files are not delivered, just the doc in html=20
> 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.

> As for browsing I use merely the open command, and the doc is placed in=20
> usr/share/cssed/plugindoc. A patch to src/plugindoc.c is necessary if=20
> the doc should not be placed at this location. A new item menu is added=20
> 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"

> Tell me if it's OK. Then I'll upload both new doxygen files (updated to=20
> the latest headers) and the new plugin to my site, because they are too=20
> 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).

> I wonder if the right place in the menu should not be in Help menu=20
> (I've put it in Plugins menu). Then I could do the same for the user's=20
> 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 ?

Should we go for this before this release, and "unfreeze" the code to
get docs into a plugin ??

This way we could make various doc packages depending on the browser
used.

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.

Is there any default help viewer on Mac ?
--=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

Re: [cssed-devel] cssed-findinfiles-plugin: some problems =?ISO-8859-1?Q?=28Modifi=E9?= par =?ISO-8859-1?Q?Mich=E8le?= Garoche)

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

On Thu, 2004-09-16 at 18:28, Mich=C3=A8le Garoche wrote:
> I forward to you because my mail ISP is once again blocked by=20
> sourceforge, kind of crazy. I receive mail-daemon.
>=20
> Le 16 sept. 2004, =C3=A0 11:27, Iago Rubio a =C3=A9crit :
> > On Wed, 2004-09-15 at 23:56, Mich=C3=A8le Garoche wrote:
> >> Le 15 sept. 2004, =C3=A0 10:04, Iago Rubio a =C3=A9crit :
> >>> This dialog must be updated. Right now it only searches from caret
> >>> position to end of document. The bits to search backwards are in=20
> >>> place
> >>> so I must update it.
> >> It works for me backwards and upwards.
> > I'm speking about the find dialog, not the quicksearch plugin :)
> Oh, sorry, misunderstanding. Too late, I'll guess, and too tired :-)
:))

> >> Then of course if you plan to preview an html file with the current=20
> >> css
> >> file, it would be interesting to have a function which changes/add
> >> temporarily the css line in the html file to integrate the css current
> >> document, then open the temporary html file in the default browser.=20
> >> But
> >> that's another story.
> > Yes it was planned, but I have problems with the rendering engines. I
> > tried to build a preview pane in the footer notebook (plugin) but It
> > must have mozilla2 (gtk2) installed and nobody have it.
> > Other rendering engines don0t likes me (gtkhtml and such).
> Or you don't like them :-)

Mostly we don't like each other ;)

> > I'm still working on it, but we must go for the external preview
> > browser.
> Yes, because it is needed to view the online doc, access the web site,=20
> and so on...
> May I try it?

Err ! It seems that you just done it :)=20

Sorry for being so late with my response, yesterday I had to fix my
customer's site and have been out of home almost all day.

> >>> If the problem is to open the browser from the plugin, just use
> >>> g_spanw_command_line_async() and that's all.
> >> I've already done it with open as I told you, are you interested or
> >> not, since you did not answer the mail I posted about that?
> > Oh! Yes, I'm very very sorry.
> > I'm geting a little fooled because you lately CC me in the list, and my
> > mail filters repeats the messages in various folders. It ends with
> > messages repeated four times in four different folders.
> Oh sorry, I wondered what was the quickest way to tell you something=20
> since sometimes there is some delay in replying and I don't know what=20
> you read/receive first: personal or cssed-dev, so I thought cc=20
> systematically, I won't do it, I promise :-)

I've got fetchmail running in the background to download my mail hourly.
It get all my - nine !! - mail boxes and pass messages to a filter to
put them in place. In fact I got all mail at the same time.

Unfortunately I receive around 150 mail messages daily and it's a big
workload for me.

But yours are the first to be reviewed in the queue ;)

> I won't do it, I promise :-)
Thanks :)

> > Of course it's my fault and I must rewrite those filtering rules but
> > meanwhile, please don't CC me :)
> Promise, promise :-))
Thanks, Thanks :))
--=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

Re: [cssed-devel] Impossible to upload manual to web site

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

On Thu, 2004-09-16 at 18:34, Mich=C3=A8le Garoche wrote:
> Le 16 sept. 2004, =C3=A0 11:42, Iago Rubio a =C3=A9crit :
[snip]
> > Tell me if it's fixed. If not I'll upload it myself today.
> That was a bit tedious, one file after another, but it is finished,=20
> I've tested it and it seems to work. I used scp and sftp, but no more=20
> rsync, it just messes the permissions/owner/group.

Thanks for the effort.

> I'll write a script to fix the group and permissions, because otherwise=20
> we will have the problem another time.
>=20
> Could you (a day you have time) fix the group in all directories/files=20
> in htdocs, since some have group 100, should be 96078. And I cannot fix=20
> it since I'm not in this group, so the write permission is of no use=20
> here.

Just done :)
--=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

Re: [cssed-devel] cssed: Added subitems to help menu

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

On Thu, 2004-09-16 at 23:50, Mich=C3=A8le Garoche wrote:
> I've added two items in the Help menu: web site and online doc.

The problem is to know the default browser in all platforms, that's why
I did not use external viewers yet, I was waiting to add an entry in the
config dialog to let the user to choose his/her preferred browser.

> If it's ok, just tell me, I'll commit the changes.

If you could add it between ifdefs it would be great.

This way I can test it, and disable it if I find problems anywhere :)

Remember we're in code freeeeze ;)
--=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

[cssed-devel] Version number of next release

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

I'm currently changing the doc to integrate changes between 0.2.1 and=20
0.3.0 version.

Is there any features that are not already in cvs (apart from plugindoc=20=

and the two menus in help menu I've added yesterday, three awaiting for=20=

approval)?

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

[cssed-devel] cssed: Added subitems to help menu

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

I've added two items in the Help menu: web site and online doc.

If it's ok, just tell me, I'll commit the changes.

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

[cssed-devel] New script on sourceforge web site

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

I've loaded a fix-perm.sh script file to correct permissions/group once=20=

files are uploaded/modified, etc... on the web site.

Could you please run it, so that the permissions/group be updated for=20
the files you own. Then all the files will be OK, I've already done it=20=

for the files I own.

In the future, after updating, it is sufficient to run the script to=20
maintain the group/permissions adequate.

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

Re: [cssed-devel] Impossible to upload manual to web site

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

Le 16 sept. 2004, =E0 11:42, Iago Rubio a =E9crit :
> On Thu, 2004-09-16 at 08:01, Mich=E8le Garoche wrote:
>> Hi Iago,
>>
>> Could you please do something or update yourself, so that the doc be
>> available on the web site, I still cannot upload (permission denied).
> I think I've just fixed the perms in htdocs/manual htdocs/docs
> htdocs/old-docs.
>>  =46rom what I read on sourceforge, it may be that the permissions =
were
>> wrong.
> Yes, they were.
>> Check the manual directory just by ssh into the htdocs directory,
>> permissions seems special on the directory aand the files compared to
>> htdocs, group also is special on some files.
> Just done, please test.
>> The doc had been announced on the web site for three weeks now, but=20=

>> the
>> files are not available and the links go to the old doc.
>> It becomes kind of crucial to get it in order.
> Tell me if it's fixed. If not I'll upload it myself today.
That was a bit tedious, one file after another, but it is finished,=20
I've tested it and it seems to work. I used scp and sftp, but no more=20
rsync, it just messes the permissions/owner/group.

I'll write a script to fix the group and permissions, because otherwise=20=

we will have the problem another time.

Could you (a day you have time) fix the group in all directories/files=20=

in htdocs, since some have group 100, should be 96078. And I cannot fix=20=

it since I'm not in this group, so the write permission is of no use=20
here.

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

Re: [cssed-devel] Impossible to upload manual to web site

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

On Thu, 2004-09-16 at 08:01, Mich=C3=A8le Garoche wrote:
> Hi Iago,
>=20
> Could you please do something or update yourself, so that the doc be=20
> available on the web site, I still cannot upload (permission denied).

I think I've just fixed the perms in htdocs/manual htdocs/docs
htdocs/old-docs.

>  From what I read on sourceforge, it may be that the permissions were=20
> wrong.

Yes, they were.

> Check the manual directory just by ssh into the htdocs directory,=20
> permissions seems special on the directory aand the files compared to=20
> htdocs, group also is special on some files.

Just done, please test.

> The doc had been announced on the web site for three weeks now, but the=20
> files are not available and the links go to the old doc.
>=20
> It becomes kind of crucial to get it in order.

Tell me if it's fixed. If not I'll upload it myself today.

Thanks for the report.

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

Re: [cssed-devel] cssed-findinfiles-plugin: some problems

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

On Wed, 2004-09-15 at 23:56, Mich=C3=A8le Garoche wrote:
> Le 15 sept. 2004, =C3=A0 10:04, Iago Rubio a =C3=A9crit :
>=20
[snip]
> > This dialog must be updated. Right now it only searches from caret
> > position to end of document. The bits to search backwards are in place
> > so I must update it.
> It works for me backwards and upwards.

I'm speking about the find dialog, not the quicksearch plugin :)

[snip]
> > We can avoid maxdepth and set recursive or not.
> > Non recursive:
> > egrep -in term
> > Recursive:
> > egrep -irn term
> > Does it works in your system ?
> It does not work at all on my system, so I've reintroduced the first=20
> string for search, it is not perfect, but that's the most valid one at=20
> the moment.
>=20
> Here's the diff:

Ok will test it. Thanks.
>=20
> ______________________________________________________________________
>=20
> >> And I'm also finishing a plugin for the doc, the interface works fine
> >> (load, unload of a new item in the plugin menu), now I wonder how to
> >> open a browser, I don't want to use netscape or gtk-doc, but more a
> >> default as dillo and then have a preferences where to change the
> >> browser, i.e. Safari for example as a default on Mac, then if the user
> >> prefers Opera, Mozilla, etc..., he can change it, as in gimp for
> >> example.
> > In linux there used to be a script called htmlview that defauts to the
> > preferred browser in the system.
> > In fact it searches among a bunch of browsers checking the environment.
> Open makes exactly that, open the file in the preferred application.
>=20
> > But I think I must to put an entry in the configuration file asking for
> > a browser as cssed needs it to show the help.
> Yes, it would be fine. And also goes to the web site. But this should =20
> go to the help menu, not the plugin menu.
>=20
> > May be I also should wrap a function in the plugins API called
> > open_in_default_browser() to make it avaiable to all plugins.
> Not necessary, just a function which can add a menu to the help menu, =20
> not only to the plugins menu.

Ok will go for it,

> Then of course if you plan to preview an html file with the current css =20
> file, it would be interesting to have a function which changes/add =20
> temporarily the css line in the html file to integrate the css current =20
> document, then open the temporary html file in the default browser. But =20
> that's another story.

Yes it was planned, but I have problems with the rendering engines. I
tried to build a preview pane in the footer notebook (plugin) but It
must have mozilla2 (gtk2) installed and nobody have it.

Other rendering engines don0t likes me (gtkhtml and such).

I'm still working on it, but we must go for the external preview
browser.

> > If the problem is to open the browser from the plugin, just use
> > g_spanw_command_line_async() and that's all.
> I've already done it with open as I told you, are you interested or =20
> not, since you did not answer the mail I posted about that?=20

Oh! Yes, I'm very very sorry.

I'm geting a little fooled because you lately CC me in the list, and my
mail filters repeats the messages in various folders. It ends with=20
messages repeated four times in four different folders.=20

Of course it's my fault and I must rewrite those filtering rules but
meanwhile, please don't CC me :)

>  (titled =20
> New plugin: developer doc plugin). The files are already on my web =20
> site:
> <http://micmacfr.homeunix.org/cssed-plugindoc-plugin/cssed-plugin-
> doc.tgz> (that's the new doc)
>=20
> <http://micmacfr.homeunix.org/cssed-plugindoc-plugin/cssed-plugindoc-
> plugin-2004-09-15.tar.gz> (that's the source for the plugin).

Ok, thanks, will test it this afternoon.

I've just been phoned by a customer to solve a problem in a web
aplication, so I'm out of time this morning.

Sorry again for the lack of feedback about the cssed-plugin-doc :)

Will mail you this afternoon.
--=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

[cssed-devel] Impossible to upload manual to web site

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

Hi Iago,

Could you please do something or update yourself, so that the doc be=20
available on the web site, I still cannot upload (permission denied).

 =46rom what I read on sourceforge, it may be that the permissions were=20=

wrong.

Check the manual directory just by ssh into the htdocs directory,=20
permissions seems special on the directory aand the files compared to=20
htdocs, group also is special on some files.

The doc had been announced on the web site for three weeks now, but the=20=

files are not available and the links go to the old doc.

It becomes kind of crucial to get it in order.

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

[cssed-devel] cssed-tag-plugin: some changes

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

I've added French language, improved English wording, and changed forze 
to force to allow --language-force to change (changes in GUI and 
parameters too, to be consistent), updated pot files, es and fr, and 
committed the whole;

Here's the diff: