[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Kword - Good and Bad News
From:       John Califf <jcaliff () usit ! net>
Date:       2000-09-25 7:51:58
[Download RAW message or body]

If you wonder why I haven't responded to email for a few days it's
because I cannot get any mail off the server at my ISP.  The ISP was
sold to a larger company which is forwarding mail sent to my current
address to nowhere, and nobody answers the phone but a tape recording. 
The new ISP is Earthlink.  What's the scoop? Are they trying to become
another AOL?  Looks like I'll have to get a new ISP this week,
preferably a small local company that won't be assimilated anytime soon
and where real people work. I can still connect and send email, though,
using the old server and read what shows up on this list with a browser.

The good news is that I have completed work on a major upgrade to the
scrolling  and several bugfixes for mouse handling.  The patches I sent
in last week have been completely rewritten, more efficienty and
according to the specs desired by Thomas.  Page scrolling now sets the
cursor in place for editing at the top of the page, and scrolling within
frames by viewport follows the flow, continues to end of paragraph or
beginning, etc. I will send in the patch tomorrow after a little more
testing to make sure....  However, I have already tested on some complex
pages and it looks very usable.  Regarding mouse handling, the right
click crash is now fixed and middle click now inserts text where you
click the mouse (or as near as possible), not where the cursor was,
which could be at a great distance from the mouse click location.  Also
no more insertion of an ugly "<empty clipboard>" message into you Kword
document when clipboard is empty.  (That's a klipper bug but it can be
worked around for now).

Regarding discussions recently about documentation, etc., I was hoping
that others would be willing to discuss such issues here as well as
plans in general. How else can such things be decided?  Even if some
people have contributed a lot to the project or wrote most of the
original code they should at least mention plans and changes here, so
that others might be informed and have a chance to influence things, as
they do on the core dev list. Even if ideas are not earthshaking it is
better to discuss them than not in this kind of project.

One thing I have tried to do is to increase the amount of discussion on
this mailing list, which seemed very inactive for such an important
project - all of KOffice.  If this comes across as too critical, I'm
sorry.  I do think the classes are well organized to the degree I
understand them, but how to get from here to there remains obfuscated
and more difficult than it needs to be.  It's like somebody
intentionally refused to document or notate much of anything.  Well, I
intend to notate the hell out of the code from here on (including any
existing KOffice code written by others that I use directly), but would
prefer that we agreed on a systematic way of doing that.  Class
relationships generated using automatic documentation tools cannot meet
this need.  That also has its uses, but has to be supplemented by
descriptive information about meaning, hand written by people. I do
notice that Shaheed puts such notes in his code, but nobody else seems
to. 

For example, I had to read almost all of the kword_doc code to find out
how to get the frame and frameset from a set of coordinates in a
document and switch to a new one, and what the paramaters stood for, and
had to output debugging messages to make sure just what the offsets used
were taken from.

Code documentation does take time, as Shaheed emphasized, and there is
no big hurry. It is important, though, to get KOffice as usuable as
possible by the time Kde 2.0 is released, even if there are bugs and
crashes and incomplete features. I feel that the immediate goal is just
to get people to use KOffice, and they will tolerate bugs so long as the
applications are attractive and useful. An attractive and up to date web
page is also very important.  On the other hand if there are big
usability issues or ineffective presentation of what the app can do
people will avoid a desktop app, even if it never crashes and has a
beautiful code design internally.

Nobody should be offended because I've fallen in love with Kword and
enjoy using it now.  It really is fun to use. So is Killustrator. In my
opinion there are only a few big usability issues remaining, like frame
borders for new frames that don't show up until you've already gone past
them so you don't know where they are soon enough. The other issues I
brough up weeks ago about memory and performance problems with large
files can't be addressed until later, but at least users could be
encouraged to break long documents up into smaller ones or chapters
using the a common template for now, to avoid critical performance
problems.  And, I do agree that it's possible to address that in a more
permanent way without changing the existing classes much externally now
that I'm a little more familiar with the document code. Actually the
paragaph seems to be the basic unit that can be referenced to locate
data or load it as needed to keep from having to load everything into
memory up front.

Dep - since programmers feel complimented when they are called "hackers"
I figured journalists likewise would feel complimented when they are
called "hack journalists".  It seems that the term goes back to the
Civil War era and now means "one who performs a service for hire".  I'd
take that as a compliment meaning that a hack, hackney or hacker is
flexible and adaptable to the needs of the situation, rather than
adhering to lofty and impractical ideals, professional or otherwise.

John

[prev in list] [next in list] [prev in thread] [next in thread]