From kde-devel Sat Jun 04 16:19:21 2005 From: "Aaron J. Seigo" Date: Sat, 04 Jun 2005 16:19:21 +0000 To: kde-devel Subject: Re: Unified document viewer, lack of communication Message-Id: <200506041019.22369.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-devel&m=111790198411428 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0083251650==" --===============0083251650== Content-Type: multipart/signed; boundary="nextPart1339513.CgAaSMUPuX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1339513.CgAaSMUPuX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 June 2005 09:14, Stefan Kebekus wrote: > since Wilfried Huss and me have been working on a unified viewer for quite > a while now, and have already produced a good viewer, with a > well-documented API that already supports 3 file types. as i've been trying to explain to Wilfried, what kviewshell provides and wh= at=20 the bounty is looking for are two slightly different things. one is a=20 "application that can morph into several types of viewers" and the other is= =20 "a viewer the supports several types of files". > Since I have only limited time, I would very much like to support others > working on the problem of a unified viewer. I would like to ask, however, > what will become of my contributions to KDVI. I am working on the project i would hope that it continues to be used. kpdf is now using xpdf-as-a-libr= ary=20 for rendering, and i think that is a very sane route to take for this=20 specific use case. KDVI could be perhaps similarly utilized. > Do you believe=20 > that we can find a modus vivendi where everyone can contribute, or do you > believe that people like me who have only limited time should better not > work for the KDE project? seeing as 95%+ of people working on KDE have limited time and that the gene= ral=20 mode of operation in KDE already is "working together" i don't think this=20 will be a problem. the area of viewers, be they image or document viewers,= =20 has been very bad at this in the past (look at how many of them we have), b= ut=20 that's something that we can fix. > Can we agree on a transition process that will preserve the work that I > plan to do in the next few monthes (good printing support for DJVU, > bookmark support for KDVI (mostly done), some more) will not be lost? Do > you already have a well-documented API that one could use? How much of the > API that I have documented recently do you plan to use? first, the person who takes on the bounty will be the final arbiter in what= =20 they decide to do. on top of that, their code may not even get finished or = be=20 good enough for inclusion, and no one may even take up that bounty. so this= =20 is a bit of "putting the cart before the horse". > Do you plan to keep that DCOP-interface of KDVI that is used, e.g. by KIL= E? > How do you plan to integrate forward/inverse search? these are design decisions that would be made largely by the person doing t= he=20 work. as mentors, Zack and i would be responsible for ensuring that they ha= ve=20 access to the right information and people. in this case, you'd be one of=20 those people. but again, until we even have someone who's interested in this, we're jumpi= ng=20 the gun and getting excited for no reason =3D) =2D-=20 Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 --nextPart1339513.CgAaSMUPuX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCodSK1rcusafx20MRAqltAKCgiG3Q/F2tLidnHody06207tm9/QCfbV5p 6tAG4tANNCqwZNfGbr7FQjk= =huoS -----END PGP SIGNATURE----- --nextPart1339513.CgAaSMUPuX-- --===============0083251650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0083251650==--