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