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>