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

List:       kde-pim
Subject:    Re: RFC: A different proposal
From:       Don Sanders <dsanders () cch ! com ! au>
Date:       1999-08-02 7:59:47
[Download RAW message or body]

> On Sat, 31 Jul 1999, Tim Rohrer wrote:
> > Hello Everyone,
> > 
> > Since it turns out that I don't need to write an API for LDAP support in KDE,
> > I have been thinking about another project.
Am I right in thinking that you don't need to write an API for LDAP as your
goal is to share an address book between KDE (Kmail) and Netscape Communicator
(as your mail to kde-pim on Jul 8 stated) and you expect Rik's backend to
support storage in a netscape friendly (ldif) format? Just want to make sure I
understand. 

I'm not aware of anyone actively working on a LDAP backend for the
pim-addressbook (bit worried about calling it kab since I haven't seen Mirko
giving us his 'blessing'), indeed it isn't required in the short term,
(lower priority than supporting printing) but it does still seem desirable.

 >  This time, before I start working
> > I will propose it to you all and make sure someone else isn't already taking
> > care of it.
> > 
> > The proposal I have is to start working on getting printed output for the pim.
> >  In particular, I would start with pulling data from an LDAP server and
> > formatting it to different forms for printing.  Eventually, the different
> > forms would include labels of most varieties and printouts for daytimers, etc.
> >  This may be a trivial project if routines exist for formatting data properly
> > to fit on printers.

I have spent some time thinking about printing, indeed it is on my todo list.
It would be great if you could work on printing as I have no printer at home
so am ill equipped for the job. 
> > framework? If so, I'll write stuff to make use of it so the integration into
> > kab, etc., is easier.
> > 
> > Thoughts, comments, etc.?

On Sun, 01 Aug 1999, Rik Hemsley wrote:
> Interesting plan. Here's the current situation:
> 
> KOrganiser: Already know how to print, and does it reasonably well.
> KMail: Asks the HTML widget to print.
> Empath: Asks the HTML widget to print.
> kab: No printing capability
OK (i guess this means you have a printer Rik :-)

>
> So what's missing is kab's printing capability. We're looking at having a
> set of standard fields in kab, plus an undefined set of non-standard.
> 
> This will probably mean we'll be giving the user these choices:
> Print the whole thing as just name: value
> Print the set of defined fields in a pretty way.
> 
> Once we're sure exactly which fields will be in the defined set, then we
> can say for sure what the layout should be.

Well here are my thoughts. You seem interested in routines for formatting
output on printers. I have very little experience printing with QT
but I have read the portion in Kalle's book that deals with printing and I have
used a very similar system on a different windowing system.

Have a look at qprinter.html in the qt documentation if you have not done so
already. The basic idea is that your application already supports drawing to the
screen via a qpainter class, and you use a qprinter class (which is derived from
qpainter) to direct output to the printer. You just have to specify when to
break pages. This allows you to reuse all the code for drawing to screen.

Now this assumes that your app is set up to display documents as a sequence of
pages (like a word processor). Unfortunately our case isn't that simple we will
need specialized routines for making the printed output look nice.

Specialized routines for printed output seem warranted. Tim, were you
considering supporting output of spreadsheet style views? (If you're familiar
with MS Outlook you probably know what I mean, otherwise I
can send you some screenshots if that would help). If you weren't intending to
support these I could give them a try and it would be most helpful to me if
someone could help me test this.

As far as the selection of what fields to print. The GUI I'm working on
supports a pretty extensive list and also allows for custom fields as Rik
stated. The main address book view will support the user choosing which fields
they wish to have displayed (and in which order since a qlistiview will be
used). This has already been done for the Address Book Entry Browser (which I
haven't checked in CVS yet). This list of fields could be used, at least for
printing of the spread sheet like views anyway). For the other printing formats
I guess you'll have to use your own best judgement, if you can get the address
book gui stuff in cvs to compile (you'll need to read the readme file) you'll be
able to see which fields the GUI I'm working on supports (very similar to MS
Outlook). Alternatively I can send you a list.

Well I think I'm close to exceeding my word limit :-) so I had better stop soon.
Some other related things are it would be nice if print preview was supported
(some other kde apps do this), and a related topic is exporting to HTML (I had
begun to work on exporting a spread sheet style view but not done any stuff on
card views).

> Pulling data from an LDAP server won't be something you'll need to concern
> yourself with. That'll be handled by kab. You'll just talk to the KAB API.
> 
> One thing I have in mind is being able to save and load all PIM data as
> XML. Seeing as there's only really me and Don coding at the moment, I don't
> know whether there will be time before KDE 2.
This XML talk has taken me a little by surprise. I might comment later (I know
SGML hence I know XML). I want to save some time for looking at the address book
code you checked into cvs, Rik.

> Do you know anything about XML ? If I knew _how_ to write it, I'd knock
> something up, but I'm having to learn CORBA on-the-fly and without a book
> at the moment for kab, so I'm a little snowed under :)
> 
> Being able to save a mail message as XML just sounds cool to me ;)
> 
> Do you think this (XML export) is worth it, to help with printing ?
> 
> Cheers,
> Rik
> 
> -- 
> KDE - Colour Outside The Lines - http://www.kde.org
BFN,
Don.

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