--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 09, 2002 at 02:34:44PM -0500, Eric S. Raymond wrote:

> 1. Koffice data formats
>=20
> First, I think the design of the KOffice format (tar archive of XMLs and =
PNGs)
> was a mistake.  Koffice files ought to be XML dumps with binary objects=
=20
> embedded in them in MIME base-64 enconding.
>=20
> Why do I say this?  Because the existing format buys only a minor
> increase in space efficiency (none for the existing XML portions, and
> only about one bit out of eight for the binary objects).=20

Encoding a png/mp3/whatever inside an XML stream looks VERY obscure in my e=
yes.=20
Plus you forget the fact that the archive is compressed. The gzip compressi=
on=20
means a huge gain for the xml file. (over 500%)

> gives away is format transparency and hackability with standard tools.
> This loses much more than you have gained.

It is hackable with standard tools; I am surprised I have to tell you its
a tar gzip file since '/usr/bin/file' gives this away.
I wonder how many complaints we would get if the files were huge because=20
we do it the way you describe.

Now (with out solution) its easy to replace a picture in a document, embedd=
ing=20
documents in others is transparent since we can use a directory structure w=
here=20
embedded docs are in a subdir, the DTDs are all open (and correctly maintai=
ned btw).

Anyway, I hope you won't blame KOffice for choosing a solution which users=
=20
appriciate (and they have) and hackers are able to open up.=20
See; its a compromise and IMO a good one.
In the future it is likely we will move to use a zip file as the archive, t=
o come
in line with other unix-using office suites out there.=20


> On today's machines, the traditional arguments for tight-packed binary
> formats are specious.  Disks are cheap; processor clocks for parsing=20
> and decoding are cheap.  It makes much more sense to optimize for=20
> minimizing *human* use of time -- which means transparent data, the
> counterpart of open source code.

Unfortunately bandwith is (still) not as cheap as disk space, sending a fil=
e to=20
someone else is still almost impossible with documents over 1MB. The text-o=
nly 50
page document flatland is 90Kb compressed, and 500Kb uncompressed.=20
If we start to talk about spreadsheets the default file gets bigger in a hu=
rry!

> 2.  Failure to follow basic principles of good UI design
>=20
> And, at least with Kpresenter, you have not gotten the surface gloss
> right either.

I am a UI designer by trade, and I agree with KPresenters missing that glos=
s.=20
I would like to spend some time going over the UI. But time is (as always) =
the=20
one thing I do not have a lot to spare of.

<...>

> Here's another one.  You have many pulldown entries that duplicate=20
> icon functions.  Why?  Sure, users may want pulldowns or they may
> want icons, but they are unlikely to want both at once.  Choose one
> as a default, not both.

Rule number one in menu/toolbar design; put all actions in the menus. Icons
are shortcuts for the menus, and thus always a subset.

But you are right on most other points.


> I hear people tell me that the documentation is behind because KPresenter
> us evolving too fast.  What this tells me is that the developers are
> masturbating -- coding strictly to please themselves, not documenting, and
> not thinking or not caring that the lack of documentation makes KDE=20
> frustrating and impossible for the end-users for which it is supposed to
> be targeted.

Ok, let me clear up a misunderstanding here; we have found that geeks are n=
ot=20
capable of writing documentation. We have also found that there are plenty =
of=20
people very capable and willing to do so.=20
In other words; we have people who write the documentation and people who c=
ode.
This gives a number of advantages in the way docs _are_ written and UIs are=
 described.

If people say that documentation is playing catch-up then we have to look i=
nto
why that is, and not jump to an uninformed and mainly cursing conclusion li=
ke
you do up here. Nothing personal though..

> If you think you can win the desktop battle this way, you are smoking cra=
ck.
> Don't tell me "oh, we'll get the documentation in shape eventually" becau=
se
> that never happens.  The gap between code and docs just gets wider and
> more intimidating as you neglect it.  You need to tackle this *now*.

No, we don't.

First rule of coding; make sure you have a good basis to build on. This is =
the=20
thing being worked on.
Rule number two is that the product you put out of the door is stable. This
is the other thing.
Then a good UI can be created (yes it can be created meanwhile, but alas th=
is
is not a requirement I am willing to ask of the volunteer coders)
After a good UI is created the writing documentation can be done in an inte=
lligent
manner; before this point all documentation is patchwork.


Bottom line; the file format is open, but maybe that needs to be made a bit=
 more
public at sites like www.koffice.org
the example application KPresenter needs some finish, you are right.
Documentation is not something the coders are concerned with, the writers a=
re=20
working on the docs.  Its not finished; thats correct; blame us for releasi=
ng
too early too often.

KOffice is evolving; and with a team of about 4-10 people I think they are =
not
doing a bad job.=20

Thank you for your opinion.

--=20
Thomas Zander                                            zander@earthling.n=
et
The only thing worse than failure is the fear of trying something new

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8Zk5DCojCW6H2z/QRAtzMAKDUGeqKFmJ8uagANsa6wEtNp4EsGQCg5IAj
Y9rXUlEG8I2tZrQrnZ3e7ik=
=M1ej
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--