cssed-devel — cssed development discussion

Re: [cssed-devel] Just one more thing to cssed 0.3.0

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

On Tue, 2004-09-21 at 13:02, Michèle Garoche wrote:
> Le 21 sept. 2004, à 12:42, Iago Rubio a écrit :
[snip]
> > Can it go this way or is inusable ?
> Strictly speaking, it is usable, but frankly if you should move the 
> window each you want to access a field or an icon on the toolbar, and 
> remove it just thereafter, it'll get on your nerves very quickly :-)

It must change it  then, Does it needs to fit in less height it's
fitting now ?

> > We must write it down in the web site "requires 800x600" :(
> Yes, because, of course you can split another time the toolbar, but 
> then you have very little place for the document, and in particular no 
> more place for viewing the scan selector panel (it cuts before the end 
> of the hide the lower panel icon).

I will test it in the BSD box, it's attached to a small 14' screen and -
I think - in 800x600.

> Another option, but no for this release, would be to use a tool window 
> (with access to the lower panel in it and all plugins), instead of 
> using the toolbar, this way the window remains relatively small, and 
> the user can place both windows overlapping each other.

I must think on it, now I'll write some code for the toolbars.

We can also float the toolbars, so the user could attach and dettach
them.

> I wonder if it is not the way to go, since as the number of plugins 
> will grow we have to face that very problem more and more.

We must think on it. ITOH I don't expect too much people will use all
plugins, or even a huge number of plugins.

I also expect more menu based plugins when I fix menu access, and more
non ui plugins as file managers and css dialogs.

What's sure is the UI - the main window I mean - is limited in the
number of widgets.

> > Great thanks, will split the find in files plugin commands in two lines
> > and we'll see if the whole fits on 800x600.
> OK.

Please test the changes in cvs. Patch attached.
-- 
Iago Rubio   
- Home page    * http://www.iagorubio.com 
- Last project * http://cssed.sourceforge.net         
- GPG Keyserv  * pgp.rediris.es id=0x909BD4DD

Re: [cssed-devel] Just one more thing to cssed 0.3.0

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

Le 21 sept. 2004, =E0 12:42, Iago Rubio a =E9crit :
>>>> 2 - split the second line in tags plugin, so that the same rule
>>>> applies
>>> I think what's failing is the find in files.
>>> I can srink the window to toolbar width without it loaded.
>>> Could you please test it ?
>> Not exactly right, but it improves things, the fact is when you =
unload
>> the find in files plugin, the shrink goes to the end of the Show all
>> field of the tags plugin, so there remains circa 2 cm free.
> Can it go this way or is inusable ?
Strictly speaking, it is usable, but frankly if you should move the=20
window each you want to access a field or an icon on the toolbar, and=20
remove it just thereafter, it'll get on your nerves very quickly :-)

> We must write it down in the web site "requires 800x600" :(
Yes, because, of course you can split another time the toolbar, but=20
then you have very little place for the document, and in particular no=20=

more place for viewing the scan selector panel (it cuts before the end=20=

of the hide the lower panel icon).

Another option, but no for this release, would be to use a tool window=20=

(with access to the lower panel in it and all plugins), instead of=20
using the toolbar, this way the window remains relatively small, and=20
the user can place both windows overlapping each other.

I wonder if it is not the way to go, since as the number of plugins=20
will grow we have to face that very problem more and more.

> Great thanks, will split the find in files plugin commands in two =
lines
> and we'll see if the whole fits on 800x600.
OK.

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

Re: [cssed-devel] Just one more thing to cssed 0.3.0

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

On Mon, 2004-09-20 at 22:33, Mich=C3=A8le Garoche wrote:
> Le 20 sept. 2004, =C3=A0 15:27, Iago Rubio a =C3=A9crit :
> > On Mon, 2004-09-20 at 13:46, Mich=C3=A8le Garoche wrote:
> >> Sorry not to have caught it sooner.
> >> There is a small annoyance in cssed right now if you load the tags
> >> plugin or findinfiles plugin. The screen is very large, hence the
> >> window could not be reduced conveniently.
> > My fault, I code in a 21' screen at 1600x1200 :/
> Sorry I was out the whole afternnon.
> And I on 1440*900, so that we're both guilty :-)

Well at least we're in time to pay for it ;)

> >> 2 - split the second line in tags plugin, so that the same rule=20
> >> applies
> > I think what's failing is the find in files.
> > I can srink the window to toolbar width without it loaded.
> > Could you please test it ?
> Not exactly right, but it improves things, the fact is when you unload=20
> the find in files plugin, the shrink goes to the end of the Show all=20
> field of the tags plugin, so there remains circa 2 cm free.

Can it go this way or is inusable ?

> 3 - split the first line in findinfiles plugin the same way.
> >
> > Yes, I think it's the solution. Please test if without this plugin
> > loaded, and with tags one loaded, you can resize the window to fit on
> > screen.
> >
> > Not sure if cssed will fit in 640x480.
> No it will no fit into 640x480 even with no plugin at all, but it could=20
> in 800x600, provided that the height be shrinked a bit. I've shrinked=20
> the terminal to 50x7, this way it fits in 800x600.
> It seems to be a good balance.

We must write it down in the web site "requires 800x600" :(

> >> I think here about small portables with are only 12, 14''. I'm not=20
> >> sure
> >> the window will fit into the screen. On my screen, which is a 17'', it
> >> does not fit in the screen when I use 1024*768 resolution, only with
> >> 1152*720 or higher.
> >
> > I suposse we should make it fit in 800x600.
> Change committed to cvs.

Great thanks, will split the find in files plugin commands in two lines
and we'll see if the whole fits on 800x600.
--=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] Just one more thing to cssed 0.3.0

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

Le 20 sept. 2004, à 15:27, Iago Rubio a écrit :
> On Mon, 2004-09-20 at 13:46, Michèle Garoche wrote:
>> Sorry not to have caught it sooner.
>> There is a small annoyance in cssed right now if you load the tags
>> plugin or findinfiles plugin. The screen is very large, hence the
>> window could not be reduced conveniently.
> My fault, I code in a 21' screen at 1600x1200 :/
Sorry I was out the whole afternnon.
And I on 1440*900, so that we're both guilty :-)

>> 2 - split the second line in tags plugin, so that the same rule 
>> applies
> I think what's failing is the find in files.
> I can srink the window to toolbar width without it loaded.
> Could you please test it ?
Not exactly right, but it improves things, the fact is when you unload 
the find in files plugin, the shrink goes to the end of the Show all 
field of the tags plugin, so there remains circa 2 cm free.

3 - split the first line in findinfiles plugin the same way.
>
> Yes, I think it's the solution. Please test if without this plugin
> loaded, and with tags one loaded, you can resize the window to fit on
> screen.
>
> Not sure if cssed will fit in 640x480.
No it will no fit into 640x480 even with no plugin at all, but it could 
in 800x600, provided that the height be shrinked a bit. I've shrinked 
the terminal to 50x7, this way it fits in 800x600.
It seems to be a good balance.

>> I think here about small portables with are only 12, 14''. I'm not 
>> sure
>> the window will fit into the screen. On my screen, which is a 17'', it
>> does not fit in the screen when I use 1024*768 resolution, only with
>> 1152*720 or higher.
>
> I suposse we should make it fit in 800x600.
Change committed to cvs.

Here's the diff:

Re: [cssed-devel] Just one more thing to cssed 0.3.0

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

On Mon, 2004-09-20 at 13:46, Mich=C3=A8le Garoche wrote:
> Sorry not to have caught it sooner.
>=20
> There is a small annoyance in cssed right now if you load the tags=20
> plugin or findinfiles plugin. The screen is very large, hence the=20
> window could not be reduced conveniently.

My fault, I code in a 21' screen at 1600x1200 :/

> I wonder if:
>=20
> 1 - we could not add the third tool bar for quick-search plugin, and=20
> any other new ones which will need to add something in the toolbar, and=20
> put as principle that the addition in toolbar should not exceed the=20
> width of the largest toolbar without plugin.

It will be better to wait for the incomming changes :)

>  Or put it in the second=20
> bar, though it will only be temporary until you make the architecture=20
> for that, since it is not really the right place for it, but this way=20
> the window is not enlarged as much as when putting in the first toolbar

Ok, commited to CVS.

> 2 - split the second line in tags plugin, so that the same rule applies

I think what's failing is the find in files.
I can srink the window to toolbar width without it loaded.

Could you please test it ?

> 3 - split the first line in findinfiles plugin the same way.

Yes, I think it's the solution. Please test if without this plugin
loaded, and with tags one loaded, you can resize the window to fit on
screen.

Not sure if cssed will fit in 640x480.

> I think here about small portables with are only 12, 14''. I'm not sure=20
> the window will fit into the screen. On my screen, which is a 17'', it=20
> does not fit in the screen when I use 1024*768 resolution, only with=20
> 1152*720 or higher.

I suposse we should make it fit in 800x600.
--=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] Just one more thing to cssed 0.3.0

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

Sorry not to have caught it sooner.

There is a small annoyance in cssed right now if you load the tags=20
plugin or findinfiles plugin. The screen is very large, hence the=20
window could not be reduced conveniently.

I wonder if:

1 - we could not add the third tool bar for quick-search plugin, and=20
any other new ones which will need to add something in the toolbar, and=20=

put as principle that the addition in toolbar should not exceed the=20
width of the largest toolbar without plugin. Or put it in the second=20
bar, though it will only be temporary until you make the architecture=20
for that, since it is not really the right place for it, but this way=20
the window is not enlarged as much as when putting in the first toolbar

2 - split the second line in tags plugin, so that the same rule applies

3 - split the first line in findinfiles plugin the same way.

I think here about small portables with are only 12, 14''. I'm not sure=20=

the window will fit into the screen. On my screen, which is a 17'', it=20=

does not fit in the screen when I use 1024*768 resolution, only with=20
1152*720 or higher.

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

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

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

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

Le 20 sept. 2004, =E0 12:21, Iago Rubio a =E9crit :
> On Mon, 2004-09-20 at 09:50, Mich=E8le Garoche wrote:
>> Le 20 sept. 2004, =E0 9:25, Iago Rubio a =E9crit :
>>>
>> Yes, I know, but this is the Fink policy. Of course I have to disable
>> what does not work at all or is not at relevant, but should patch =
what
>> is possible to run with a patch.
> Good policy, but put's lots of weight on the packager as it must code
> and fix, that's a developer task.
Yes, that's why I fear not to be able to port something. It comes from=20=

the fact the majority of maintainers are actually developers on Unix,=20
Linux, BSD or even Apple, and very good ones.

>> That's the theory, and you can be sure that if I don't make a release
>> as soon as you do one, I have mailing either in my box or directly in
>> user's/developer's mailing list complaining I don't port the new
>> release. That's Mac users, they are used to have the most updated=20
>> thing
>> quickly.
> Ask him to join the cssed-devel and scream here his complains :))
I doubt he wants and I'll get in return a bunch of imprecations. :-))))

> If you "don't know how" you cannot do it. If "it cannot be done" =
nobody
> can do it ;)
If I don't know, I have to ask other developers, other maintainers,=20
many mailing lists, forums, read a bunch of literature till I find a=20
way either to do it or to be sure it's undoable. And that's what I've=20
made for cssed. It was not at all obvious form, huge crisis of panic=20
when you announce you'd make plugins :-)

> There'll be things non portable as mmap for windows or ipc for Mac.
Yes, but there is a way to patch it so that it works, so that's what I=20=

call portable, even if I don't know exactly how to do it.

As for ipc queue, I must investigate since Apple has made changes in=20
ipc recently, not sure it is enough to support full ipc queue, but it=20
may have improved. So what was false yesterday could be true tomorrow.


> Well, lot's of people adds features to packages. As example Fedora=20
> ships
> ls with the new -Z option for NCSA/SElinux contexts.
> It's also based in the original sources ... but extended a bit.
> Meanwhile you publish your code, and document the changes, it's up to
> you to add anything to cssed.
Yes, but that's what I told you, it must be someone who makes an=20
addition as developer, here NCSA/SELinux, then Fedora can use it. So if=20=

I want to add something I've made to cssed, I have to put the addition=20=

under my name on SF for example, then I can effectively add it as a=20
plugin to cssed as maintainer this time. But I cannot simply make my=20
plugin on my disk and add it surreptitiously to cssed.  Anyway I don't=20=

like both ways, since it can lead to great discrepancy between ports.

> If a small feature is added it will be release as revision # ( mean
> 0.3.1 "adds a turtle icon to the toolbar, once clicked cssed will run
> twice slower" ;)
That, I'll add it :-)))

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

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

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

Le 20 sept. 2004, =E0 11:57, Iago Rubio a =E9crit :

> On Mon, 2004-09-20 at 09:36, Mich=E8le Garoche wrote:
> Changes commited, patch attached.
>
> Please test the -DDARWIN stuff.
perfect.

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

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

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

On Mon, 2004-09-20 at 09:50, Mich=C3=A8le Garoche wrote:
> Le 20 sept. 2004, =C3=A0 9:25, Iago Rubio a =C3=A9crit :
[snip]
> >>> Of course in Mac world, you've got the word about when a new feature
> >>> deserves a release or not :)
> >> No, that's not the way it works. If I maintain a package, I have to
> >> port any new release, be it at my convenience or not.
> >
> > No other distros do that. As example Gentoo only packaged "full"
> > releases ( they relesed 0.1 and 0.2 ), and RedHat is  still in 0.1.
> Yes, I know, but this is the Fink policy. Of course I have to disable =20
> what does not work at all or is not at relevant, but should patch what =20
> is possible to run with a patch.

Good policy, but put's lots of weight on the packager as it must code
and fix, that's a developer task.

> That's the theory, and you can be sure that if I don't make a release =20
> as soon as you do one, I have mailing either in my box or directly in =20
> user's/developer's mailing list complaining I don't port the new =20
> release. That's Mac users, they are used to have the most updated thing =20
> quickly.

Ask him to join the cssed-devel and scream here his complains :))

> > The packaging proccess is not exactly the same as the development
> > proccess. Packagers must follow some considerations that developers =20
> > have
> > no need to take into account.
> Yes, I know, but I make both, so when I think about code, I think also =20
> about portability on the Mac.
> > As a packager, you must ensure the release will fit in your environment
> > and if it does not fit, you should not package it just because it was
> > released.
> No, except that I have kind of duty to make it portable, if possible at =20
> all. Not just drop it because I don't know how to port it.

If you "don't know how" you cannot do it. If "it cannot be done" nobody
can do it ;)

There'll be things non portable as mmap for windows or ipc for Mac.

> >> And if the
> >> package does not contain a feature, I cannot release it as part of the
> >> package, unless I develop myself a part and release it as
> >> developer/maintainer.
> >
> > Well, lots of packagers adds - or cuts - features on the main package.
> > RedHat use to modify most packages they release, and they adds any
> > feature they think will be ok for RedHat's desktops.
> I can cut, I can patch, but I cannot add, because I should use the =20
> original package, not a package of mine. That's Fink policy (it's a =20
> package manager, no more, so it's based on the original sources).

Well, lot's of people adds features to packages. As example Fedora ships
ls with the new -Z option for NCSA/SElinux contexts.

It's also based in the original sources ... but extended a bit.

Meanwhile you publish your code, and document the changes, it's up to
you to add anything to cssed.

> >>> As example if 0.3.2 would be released with a new short of ipc queue,
> >>> useful on BSD and Linux, but useless for you, it's in your hands to
> >>> release on Mac or not ;)
> >> No, I should release it, even if this does not add anything to the =20
> >> Mac.
> > I still think you have no need to do it :)
> Well, maybe I can drop a revision if it really add nothing to Mac, but =20
> not a major release in the same condition.

Of  course no major release will contain no important features :)

If a small feature is added it will be release as revision # ( mean
0.3.1 "adds a turtle icon to the toolbar, once clicked cssed will run
twice slower" ;)
--=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 Mon, 2004-09-20 at 09:36, Michèle Garoche wrote:
[ßnip]
> > I'm still waiting for you to upload it to CVS :)
> OK, in a few minutes.

Small changes commited to define DARWIN and WITH_HELP_MENUS at configure
time.

I've just added those lines to configure.in

dnl Define WITH_HELP_MENUS at CFLAGS if requested.
dnl If it's requested but headers are not found
dnl it will not reach here.
dnl ====================================
if test "$use_helpmenus" = yes; then
	PACKAGE_CFLAGS="$PACKAGE_CFLAGS -DWITH_HELP_MENUS"
fi 

dnl Define DARWIN at CFLAGS if it's OsX
dnl ====================================
if test "x$OSTYPE" = "xDARWIN";then
	PACKAGE_CFLAGS="$PACKAGE_CFLAGS -DDARWIN"
fi

Changes commited, patch attached.

Please test the -DDARWIN stuff.
-- 
Iago Rubio   
- Home page    * http://www.iagorubio.com 
- Last project * http://cssed.sourceforge.net         
- GPG Keyserv  * pgp.rediris.es id=0x909BD4DD

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

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

Le 20 sept. 2004, à 9:36, Michèle Garoche a écrit :
>> I'm still waiting for you to upload it to CVS :)
> OK, in a few minutes.
There are committed now, sorry for the delay

Here's the diff:

[cssed-devel] =?ISO-8859-1?Q?Re:_[cssed-devel]_Re:_[cssed-devel]_Re:_[cssed-de?= =?ISO-8859-1?Q?vel]_New_plugin:_developer_doc_plugin_=28Modifi?= =?ISO-8859-1?Q?=E9_par_Mich=E8le_Garoche=29?=

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

Le 20 sept. 2004, =E0 9:22, Iago Rubio a =E9crit :

> On Mon, 2004-09-20 at 00:28, Mich=E8le 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.

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

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

> 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?
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? Anyway at the moment, I don't feel as=20
skilled as to develop something useful myself.

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

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

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

Le 20 sept. 2004, =E0 9:25, Iago Rubio a =E9crit :

>> Well not sure, may be three or four times a year is a balance. When =20=

>> you
>> release small changes you have not a clear vision of the whole =20
>> package.
>> And in the case of this release, there was a complete change of the
>> architecture, so that may not be a good criteria of comparison.
>
> It's just to follow "Release Early, Release Often" :)
> http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/=20=

> ar01s04.html
>
>>> Of course in Mac world, you've got the word about when a new feature
>>> deserves a release or not :)
>> No, that's not the way it works. If I maintain a package, I have to
>> port any new release, be it at my convenience or not.
>
> No other distros do that. As example Gentoo only packaged "full"
> releases ( they relesed 0.1 and 0.2 ), and RedHat is  still in 0.1.
Yes, I know, but this is the Fink policy. Of course I have to disable =20=

what does not work at all or is not at relevant, but should patch what =20=

is possible to run with a patch.

That's the theory, and you can be sure that if I don't make a release =20=

as soon as you do one, I have mailing either in my box or directly in =20=

user's/developer's mailing list complaining I don't port the new =20
release. That's Mac users, they are used to have the most updated thing =20=

quickly.

> The packaging proccess is not exactly the same as the development
> proccess. Packagers must follow some considerations that developers =20=

> have
> no need to take into account.
Yes, I know, but I make both, so when I think about code, I think also =20=

about portability on the Mac.

> As a packager, you must ensure the release will fit in your =
environment
> and if it does not fit, you should not package it just because it was
> released.
No, except that I have kind of duty to make it portable, if possible at =20=

all. Not just drop it because I don't know how to port it.

>> And if the
>> package does not contain a feature, I cannot release it as part of =
the
>> package, unless I develop myself a part and release it as
>> developer/maintainer.
>
> Well, lots of packagers adds - or cuts - features on the main package.
> RedHat use to modify most packages they release, and they adds any
> feature they think will be ok for RedHat's desktops.
I can cut, I can patch, but I cannot add, because I should use the =20
original package, not a package of mine. That's Fink policy (it's a =20
package manager, no more, so it's based on the original sources).

>>> As example if 0.3.2 would be released with a new short of ipc queue,
>>> useful on BSD and Linux, but useless for you, it's in your hands to
>>> release on Mac or not ;)
>> No, I should release it, even if this does not add anything to the =20=

>> Mac.
> I still think you have no need to do it :)
Well, maybe I can drop a revision if it really add nothing to Mac, but =20=

not a major release in the same condition.

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

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

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

Le 20 sept. 2004, =E0 9:22, Iago Rubio a =E9crit :

> On Sun, 2004-09-19 at 22:52, Mich=E8le Garoche wrote:
>> Le 19 sept. 2004, =E0 22:26, Iago Rubio a =E9crit :
>>
>>> On Sun, 2004-09-19 at 17:56, Mich=E8le Garoche wrote:
>>>> Le 19 sept. 2004, =E0 17:26, Iago Rubio a =E9crit :
>>>>> On Sat, 2004-09-18 at 20:05, Mich=E8le Garoche wrote:
>>> I will make those changes for you, so let the #ifdef DARWIN parts on
>>> CVS.
>>>>> Well, I prefer to do it in next release.
>>>> I'll put it in the mac version as is.
>>> It's ok for me :)
>> No, it's not ok for me, if it is not in cvs.
>
> I'm still waiting for you to upload it to CVS :)
OK, in a few minutes.

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

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

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

Sorry, I replied this message with an internal mail address.
Here you've got it again.

On Sun, 2004-09-19 at 22:48, Mich=C3=A8le Garoche wrote:
> Le 19 sept. 2004, =C3=A0 22:19, Iago Rubio a =C3=A9crit :
> > On Sun, 2004-09-19 at 18:02, Mich=C3=A8le Garoche wrote:
> >> Le 19 sept. 2004, =C3=A0 17:09, Iago Rubio a =C3=A9crit :
> >>> 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=20
> >>>> send  them to me.
> >>> No I didn't made the changes yet, because I want to give an API=20
> >>> 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
> >> force the user to use a default browser?
> > It's not to force, it's to let him to choose :)
> Say I have four browsers available, all of them have preferences set so=20
> that when I open a new file, it is opened in the already open window=20
> (not a new tab and not a new window) if any. Say that I already use=20
> three of them to various operations, reading, downloading, and so on.=20
> Say now you have a default command browser in cssed and I click on it=20
> to view the doc on line, then I'm angry with you because it has simply=20
> overriden what I was viewing.=20

What I want here is to let the user choose what browser he wants to be
opened when viewing help.

As it's a user's choice, he can not be angry with me.

He could be angry if I hardcode a browser to view the help, not if let
him to choose what browser he want to use for help.
=20
> That's why I'm more in favour of a choice=20
> of browsers (maybe 4 or 5) without any default browser at all, but=20
> still with the possibility to add new ones which will be stored in an=20
> rc file in the user's home directory.

That's what I want to do, and it involve the changes I told you in
previous messages,

> >>> This will involve changes in the preferences dialog, the=20
> >>> 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
> >> configuration per user if you want to go this way.
> > Yes, in the main cssed configuration file.
> No, it is impossible at the moment, the main cssed configuration file=20
> is a global one.=20

I'm speaking the users's file in $HOME/.cssed/cssed-cfg.xml

> So there is a need to have both, a global one and a=20
> user's one which are the same at the beginning, then the user has the=20
> possibility to change his own, not the global one, and the user's=20
> configuration always overrrides the global configuration (in the part=20
> where they are not the same).=20

cssed only users the global configuration file as a fallback if it's the
first boot of cssed. Then it's copied to the user's cssed folder and all
changes are made in a per user file.

> It's completely against security that the=20
> user could change a global configuration, at least inside the package.=20

It's imposible in cssed. Only root can write the global configuration
file.

> If he really wants to do it, it's at his own risk, and it has to be=20
> presupposed that he has the right to do it, which is not always the=20
> case, he may not be the administrator on the system (for example, on my=20
> mac, you cannot change a global configuration, even if you can access=20
> the mac. I can when I log as admin, but I cannot if I log as a simple=20
> user and it is good as is).

cssed is not made with root security in mind, and it's discouraged to
use it as root.

> > That's why it will envolve this big number of changes in cssed.
> Yes, and that's why I think it's not for tomorrow, and why I think the=20
> part I've made, even if not perfect, and surely temporary, could be=20
> integrated in this release, until the big changes will be made.

That's what I told you in the last five mails :)

I'm still waiting for your changes in CVS,

> >>> 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
> >> code, test, translate, change the doc in a month, unless we work day
> >> and night just for cssed.
> > Of course we'll not do it ... at least I can't ;-)
> > But a plan to release when a small change is ready, instead of wait for
> > big changes to be done.
> > As example is easier to add small feature - as external command
> > execution, or the integrated help - and release it, than to have a huge
> > bunch of features to document and test.
> Well not sure, may be three or four times a year is a balance. When you=20
> release small changes you have not a clear vision of the whole package.=20
> And in the case of this release, there was a complete change of the=20
> architecture, so that may not be a good criteria of comparison.

It's just to follow "Release Early, Release Often" :)
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04=
.html

> > Of course in Mac world, you've got the word about when a new feature
> > deserves a release or not :)
> No, that's not the way it works. If I maintain a package, I have to=20
> port any new release, be it at my convenience or not.

No other distros do that. As example Gentoo only packaged "full"
releases ( they relesed 0.1 and 0.2 ), and RedHat is  still in 0.1.

The packaging proccess is not exactly the same as the development
proccess. Packagers must follow some considerations that developers have
no need to take into account.

As a packager, you must ensure the release will fit in your environment
and if it does not fit, you should not package it just because it was
released.

> And if the=20
> package does not contain a feature, I cannot release it as part of the=20
> package, unless I develop myself a part and release it as=20
> developer/maintainer.

Well, lots of packagers adds - or cuts - features on the main package.
RedHat use to modify most packages they release, and they adds any
feature they think will be ok for RedHat's desktops.=20

> > As example if 0.3.2 would be released with a new short of ipc queue,
> > useful on BSD and Linux, but useless for you, it's in your hands to
> > release on Mac or not ;)
> No, I should release it, even if this does not add anything to the Mac.

I still think you have no need to do it :)

--=20
=C2=A1=C2=A1=C2=A1=C2=A1=C2=A1 NO ME USES !!!!!!!
Solo para correo interno
--=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 Sun, 2004-09-19 at 22:52, Mich=C3=A8le Garoche wrote:
> Le 19 sept. 2004, =C3=A0 22:26, Iago Rubio a =C3=A9crit :
>=20
> > On Sun, 2004-09-19 at 17:56, Mich=C3=A8le Garoche wrote:
> >> Le 19 sept. 2004, =C3=A0 17:26, Iago Rubio a =C3=A9crit :
> >>> On Sat, 2004-09-18 at 20:05, Mich=C3=A8le Garoche wrote:
> > I will make those changes for you, so let the #ifdef DARWIN parts on
> > CVS.
> >>> Well, I prefer to do it in next release.
> >> I'll put it in the mac version as is.
> > It's ok for me :)
> No, it's not ok for me, if it is not in cvs.

I'm still waiting for you to upload it to 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] Re: [cssed-devel] 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 00:28, Mich=C3=A8le Garoche wrote:
> [snip] open is not portable, it is in the standard lib :-) and
> >> system is on all ports, as far as I know.
> > This does not ensure system will return the same values in all=20
> > platforms
> > and errno values are know to vary between POSIX and non POSIX systems.
> Oh, yes, of course. But here, as it is only for Mac, there is no=20
> problem.

That's why I told you to add it between ifdefs :)

> >>>>> Should we go for this before this release, and "unfreeze" the code=20
> >>>>> to
> >>>>> get docs into a plugin ??
> >>>> Well, all depends if you think you can do that in a reasonable=20
> >>>> delay,
> >>>> otherwise we can just release without it, but well it's so nice to
> >>>> 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
> >>> 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
> >> gspawn in the next release.
> > It does not work on Linux nor in BSD.
> But, again it's only for Mac.
>=20
> > To hardcde the command is always a bad idea, as it can not be present=20
> > in
> > all systems. Well, it's true - at least - in multi platform
> > applications.
> Yes, but the ifdef or patch are here to do that, to port. You cannot=20
> expect every single bit of the package will work as is on any system.=20
> The port of cssed on mac has little to do with the original package. It=20
> is splitted in two packages and patches are made on some locations,=20
> just to tell some changes.

Ehemmm !!!
That's what I told you to add it between ifdefs :))

> > The find in files plugin, and the file browser plugin will not be
> > shipped in windows as example.
> Yes, but they are in cvs, so why don't you want I put the help part,

:?=20
Michelle, I'm waiting for you to upload those changes to CVS. I've never
said I don't want to put it in CVS.


> which is only for mac in cvs, so that I can have it in the port? Then=20
> when the other way to do it is done, I'll drop the code.

:???
Why?

> > The plugin API is open for people to do whatever plugin they wants, and
> > can be platform dependant and shiped only in one platform.
> That's not possible, since it requires for the plugin doc for example=20
> to incorporate the html files in it. Hence, it should be put on cvs,=20
> otherwise it is not possible to port it. Or you will end up with a=20
> 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.

> > The only think I expect to be in Fink is cssed itself, and the plugins
> > you'll find useful for the Mac community.
> I can put them in fink, if they are in cvs, otherwise I cannot. Then of=20
> course, I can choose to add or not a plugin, but it should be in cvs=20
> before hand, i.e. you should release it.

I see.

> > Right now, I will add the -DDARWING stuff to make your defines to work,
> > so in Mac will be shiped with the help menu.
> > I will add some code to test if the doc is present, but you must=20
> > provide
> > a path to search for it.
> No, you misunderstood me. What I've added is not the doc itself, this=20
> could be done later. I've just added a link to the web site and a link=20
> to the online doc. Because Mac users will never know where and how to=20
> add the doc, besides it has no sense to let them install the doc and=20
> then just provides a link to it in the package. Plus it is completely=20
> against fink policy: fink has a trace of what is installed, then when=20
> you remove a package, all is removed.

Common to all package managers :)

>  If you allow a user to add=20
> something manually or even worse encourage it to do so, fink has no=20
> idea this has been installed, then it cannot remove it later, and the=20
> user ends up with a big mess in his system.

We should build a documentation package that follows the fink guide
lines.

ITOH, I don't encourage the user to add something manually. I give him
the freedom to extend cssed in whatever way he wants.

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.
--=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] =?ISO-8859-1?Q?Re:_[cssed-devel]_Re:_[cssed-devel]_New_plugin:_d?= =?ISO-8859-1?Q?eveloper_doc_plugin_=28Modifi=E9_par_Mich=E8le_Ga?= =?ISO-8859-1?Q?roche=29?=

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

Le 19 sept. 2004, =E0 23:58, Iago Rubio a =E9crit :
> On Sun, 2004-09-19 at 18:16, Mich=E8le Garoche wrote:
>> Le 19 sept. 2004, =E0 17:42, Iago Rubio a =E9crit :
>>> 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
>> system is on all ports, as far as I know.
> This does not ensure system will return the same values in all=20
> platforms
> and errno values are know to vary between POSIX and non POSIX systems.
Oh, yes, of course. But here, as it is only for Mac, there is no=20
problem.

>>>>> Should we go for this before this release, and "unfreeze" the code=20=

>>>>> to
>>>>> get docs into a plugin ??
>>>> Well, all depends if you think you can do that in a reasonable=20
>>>> delay,
>>>> otherwise we can just release without it, but well it's so nice to
>>>> 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
>>> 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
>> gspawn in the next release.
> It does not work on Linux nor in BSD.
But, again it's only for Mac.

> To hardcde the command is always a bad idea, as it can not be present=20=

> in
> all systems. Well, it's true - at least - in multi platform
> applications.
Yes, but the ifdef or patch are here to do that, to port. You cannot=20
expect every single bit of the package will work as is on any system.=20
The port of cssed on mac has little to do with the original package. It=20=

is splitted in two packages and patches are made on some locations,=20
just to tell some changes.

> The find in files plugin, and the file browser plugin will not be
> shipped in windows as example.
Yes, but they are in cvs, so why don't you want I put the help part,=20
which is only for mac in cvs, so that I can have it in the port? Then=20
when the other way to do it is done, I'll drop the code.

> The plugin API is open for people to do whatever plugin they wants, =
and
> can be platform dependant and shiped only in one platform.
That's not possible, since it requires for the plugin doc for example=20
to incorporate the html files in it. Hence, it should be put on cvs,=20
otherwise it is not possible to port it. Or you will end up with a=20
bunch of plugins you have no control on them.

> The only think I expect to be in Fink is cssed itself, and the plugins
> you'll find useful for the Mac community.
I can put them in fink, if they are in cvs, otherwise I cannot. Then of=20=

course, I can choose to add or not a plugin, but it should be in cvs=20
before hand, i.e. you should release it.

> Right now, I will add the -DDARWING stuff to make your defines to =
work,
> so in Mac will be shiped with the help menu.
> I will add some code to test if the doc is present, but you must=20
> provide
> a path to search for it.
No, you misunderstood me. What I've added is not the doc itself, this=20
could be done later. I've just added a link to the web site and a link=20=

to the online doc. Because Mac users will never know where and how to=20
add the doc, besides it has no sense to let them install the doc and=20
then just provides a link to it in the package. Plus it is completely=20
against fink policy: fink has a trace of what is installed, then when=20
you remove a package, all is removed. If you allow a user to add=20
something manually or even worse encourage it to do so, fink has no=20
idea this has been installed, then it cannot remove it later, and the=20
user ends up with a big mess in his system.

> I'm speaking about the cssed's doc not the plugins doc.
Yes, and I too here.

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

Re: [cssed-devel] 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 Sun, 2004-09-19 at 18:16, Mich=C3=A8le Garoche wrote:
> Le 19 sept. 2004, =C3=A0 17:42, Iago Rubio a =C3=A9crit :
> >>>> 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?

Because I want to integrate it in the configuration file.

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

I know :), It was just an example.


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

This does not ensure system will return the same values in all platforms
and errno values are know to vary between POSIX and non POSIX systems.

As example take a look at this bug:
http://www.onlamp.com/pub/a/onlamp/2001/06/07/linux_bsd.html?page=3Dlast

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

It does not work on Linux nor in BSD.=20

That's why I want to make a better system to handle help.

To hardcde the command is always a bad idea, as it can not be present in
all systems. Well, it's true - at least - in multi platform
applications.

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

Yes, it'll be better to use only html for the help.

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

Of course there'll be no need to add yelp help, or Win32 htmlhelp to
fink :)

The find in files plugin, and the file browser plugin will not be
shipped in windows as example.

The plugin API is open for people to do whatever plugin they wants, and
can be platform dependant and shiped only in one platform.

That's one of the thinks that drived me to write the plugins API. As
cssed grows is more difficult to get it multi platform and dependent
only in GTK/Glib.

With the plugin API this problem is solved - at least partially - as
anyone can use Gnome libs - or any other library they want - to add
functionality to cssed while we maintain the main cssed try small and
with sort dependecies.

The only think I expect to be in Fink is cssed itself, and the plugins
you'll find useful for the Mac community.
=20
> > 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..

Well, this hardly depends on user's preferences.=20

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

We'll do it just with html - so with browsers.

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

I'd like to do it, but letting the user to choose what browser he wants
to use.

Right now, I will add the -DDARWING stuff to make your defines to work,
so in Mac will be shiped with the help menu.

I will add some code to test if the doc is present, but you must provide
a path to search for it.

I think the place is $DATADIR "/doc/cssed" in Linux (
$PREFIX/share/doc/cssed ), is it ok on Mac ?

I'm speaking about the cssed's doc not the plugins doc.
=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

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

Le 19 sept. 2004, =E0 22:26, Iago Rubio a =E9crit :

> On Sun, 2004-09-19 at 17:56, Mich=E8le Garoche wrote:
>> Le 19 sept. 2004, =E0 17:26, Iago Rubio a =E9crit :
>>> On Sat, 2004-09-18 at 20:05, Mich=E8le Garoche wrote:
> I will make those changes for you, so let the #ifdef DARWIN parts on
> CVS.
>>> Well, I prefer to do it in next release.
>> I'll put it in the mac version as is.
> It's ok for me :)
No, it's not ok for me, if it is not in cvs.

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

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

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

Le 19 sept. 2004, =E0 22:19, Iago Rubio a =E9crit :
> On Sun, 2004-09-19 at 18:02, Mich=E8le Garoche wrote:
>> Le 19 sept. 2004, =E0 17:09, Iago Rubio a =E9crit :
>>> 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=20
>>>> send
>>>> them to me.
>>> No I didn't made the changes yet, because I want to give an API=20
>>> 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
>> force the user to use a default browser?
> It's not to force, it's to let him to choose :)
Say I have four browsers available, all of them have preferences set so=20=

that when I open a new file, it is opened in the already open window=20
(not a new tab and not a new window) if any. Say that I already use=20
three of them to various operations, reading, downloading, and so on.=20
Say now you have a default command browser in cssed and I click on it=20
to view the doc on line, then I'm angry with you because it has simply=20=

overriden what I was viewing. That's why I'm more in favour of a choice=20=

of browsers (maybe 4 or 5) without any default browser at all, but=20
still with the possibility to add new ones which will be stored in an=20
rc file in the user's home directory.

>>> This will involve changes in the preferences dialog, the=20
>>> 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
>> configuration per user if you want to go this way.
> Yes, in the main cssed configuration file.
No, it is impossible at the moment, the main cssed configuration file=20
is a global one. So there is a need to have both, a global one and a=20
user's one which are the same at the beginning, then the user has the=20
possibility to change his own, not the global one, and the user's=20
configuration always overrrides the global configuration (in the part=20
where they are not the same). It's completely against security that the=20=

user could change a global configuration, at least inside the package.=20=

If he really wants to do it, it's at his own risk, and it has to be=20
presupposed that he has the right to do it, which is not always the=20
case, he may not be the administrator on the system (for example, on my=20=

mac, you cannot change a global configuration, even if you can access=20
the mac. I can when I log as admin, but I cannot if I log as a simple=20
user and it is good as is).

> That's why it will envolve this big number of changes in cssed.
Yes, and that's why I think it's not for tomorrow, and why I think the=20=

part I've made, even if not perfect, and surely temporary, could be=20
integrated in this release, until the big changes will be made.

>>> 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
>> code, test, translate, change the doc in a month, unless we work day
>> and night just for cssed.
> Of course we'll not do it ... at least I can't ;-)
> But a plan to release when a small change is ready, instead of wait =
for
> big changes to be done.
> As example is easier to add small feature - as external command
> execution, or the integrated help - and release it, than to have a =
huge
> bunch of features to document and test.
Well not sure, may be three or four times a year is a balance. When you=20=

release small changes you have not a clear vision of the whole package.=20=

And in the case of this release, there was a complete change of the=20
architecture, so that may not be a good criteria of comparison.

> Of course in Mac world, you've got the word about when a new feature
> deserves a release or not :)
No, that's not the way it works. If I maintain a package, I have to=20
port any new release, be it at my convenience or not. And if the=20
package does not contain a feature, I cannot release it as part of the=20=

package, unless I develop myself a part and release it as=20
developer/maintainer.

> As example if 0.3.2 would be released with a new short of ipc queue,
> useful on BSD and Linux, but useless for you, it's in your hands to
> release on Mac or not ;)
No, I should release it, even if this does not add anything to the Mac.

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

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

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

On Sun, 2004-09-19 at 17:56, Mich=C3=A8le Garoche wrote:
> Le 19 sept. 2004, =C3=A0 17:26, Iago Rubio a =C3=A9crit :
> > On Sat, 2004-09-18 at 20:05, Mich=C3=A8le 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 mayfilosophy wa=
nt 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.

My plan is to do it in the main user configuration file.=20

So it will be per user in all platforms but windows - were we'll follow
the windows philosophy "one machine, one user" ;)

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

Adding it to CFLAGS also works.

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

The plugin's and main cssed build files are completly independent.

DARWIN was not defined in the cssed's code because all cssed's code
builds on MAc - at least until now ;)

It just need to work, to add it in the configure.in or Makefile.am

I will make those changes for you, so let the #ifdef DARWIN parts on
CVS.

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

It's ok for me :)
--=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...>]

On Sun, 2004-09-19 at 18:02, Mich=C3=A8le Garoche wrote:
> Le 19 sept. 2004, =C3=A0 17:09, Iago Rubio a =C3=A9crit :
>=20
> > 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 :-)

Thanks :-)

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

It's not to force, it's to let him to choose :)

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

Yes, in the main cssed configuration file.=20

That's why it will envolve this big number of changes in cssed.

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

Of course we'll not do it ... at least I can't ;-)

But a plan to release when a small change is ready, instead of wait for
big changes to be done.

As example is easier to add small feature - as external command
execution, or the integrated help - and release it, than to have a huge
bunch of features to document and test.

Of course in Mac world, you've got the word about when a new feature
deserves a release or not :)

As example if 0.3.2 would be released with a new short of ipc queue,
useful on BSD and Linux, but useless for you, it's in your hands to
release on Mac or not ;)
--=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