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

List:       koffice
Subject:    Re: Progress Report - Page Scrolling by Paper Size Done
From:       Thomas <zander () xs4all ! nl>
Date:       2000-09-20 7:07:54
[Download RAW message or body]


> I have finished coding and testing scrolling pages by page number or
> paper size, using Control-PageUp and PageDown as we discussed.  

Great!

[snip]

> We really need a page indicator in the status area of the frame. I
> suggest a nifty spin button using the Kde LEDS like the digatal clock
> applet. Not only could you see the curent page number you are on, but
> you could change it and invoke the scroling to that page with the widget
> by entering a new page number or holding down the spinners on the side.

Hmm, this is really not going to be in before the release.. But you are right.
I'll propose a pagenumber in the title-bar for the mean time..

> I have not attached a diff file although the code is done because I need
> to pull from cvs again - it's been two days, and so I need to rebuild
> everything and work in my changes.  

Kword has not really changed much in that time, you only need to recompile
the koffice/libs and the koffice/kword directories if you do a update.
Other directories can be compiled at a later date if you wish.

To automate this do a :
  export DO_NOT_COMPILE="killustrator kpresenter kspread koshell"
and a
rm config.cache
and a new configure.

Also don't recompile kdelibs/kdebase if you dont really have to, its a great
time saver..

> 
> Question:  Before logging on and doing the command :
>               cvs diff kword_page.cc kword_page.h > kword_page.diff

you should always do a cvs update before making a patch. It makes sure 
the patch is made against the most recent cvs-version (otherwise your
patch will include all your changes and the changes between the versions)

Cvs keeps versions of files, every time someone does a commit the version
is updated. So that is how cvs knows which files it should update. Has
nothing to do with dates.

The nice thing about cvs is that it can merge differences; if you changed
a file and someone committed changes as well, cvs will create a new
file which is a combination of the latest version of cvs and your
changes. (This is what you want)

Common cvs practive:

after coding and (extensively) testing your code:
cvs update
make & test (again)
cvs diff >patchfile.diff

> I will probably send the attachment tomorrow night unless somebody
> objects and wants to do things differently, and then on to navigating
> the frame heirarchy with the keyboard as we discussed a few days ago
> using the Control and <> keys. The goal here is to have really smooth
> navigation for KWord concurrent with the release of Kde 2, and a few
> bugfixes related to navigation and mouse clicks (the infamous right
> mouse click crash - I know what causes that).

We are aiming for somewhere next week as a release date. I am not sure
this is still the current planning since everyone is so busy. But that
is common practice. Simply sent the patches as soon as possible.
 
> This is great fun except I now realize I need a new computer to do
> development work on something this big with large files and lots of
> them.  Compling takes forever and I can't do much else when compiling
> Kde because it uses so much swap.  What are the minimum specs for a
> development machine you guys would recommend?  

Hmm, it should never go into swap. That makes it REALLY slow. I don't know
about minimum specs but I word on a 256 Mb machine (PII450), the more memory
the better. But with the current memory prices...

Thanx again for working on this!
-- 
Thomas Zander                                            zander@earthling.net
The only thing worse than failure is the fear of trying something new

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