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

List:       kde-commits
Subject:    Re: kdegraphics/kview
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-08-09 20:48:59
[Download RAW message or body]

On Mon, 9 Aug 1999, David Faure wrote:

> On Sun, Aug 08, 1999 at 11:08:39PM +0200, Simon Hausmann wrote:
> > On Sun, 8 Aug 1999, Stephan Kulow wrote:
> > 
> > > CVS by shausman wrote:
> > > > 
> > > > kdegraphics/kview Makefile.am,1.37,1.38 kview_view.cc,1.19,1.20 kview_view.h,1.12,1.13
> > > > Author: shausman
> > > > CVSROOT: /home/kde
> > > > Sun Aug  8 00:57:22 MET DST 1999
> > > > Update of /home/kde/kdegraphics/kview
> > > > In directory zeus:/tmp/cvs-serv23112
> > > > 
> > > > Modified Files:
> > > >         Makefile.am kview_view.cc kview_view.h
> > > > Log Message:
> > > > - cleanups
> > > > - linking against libkonq and using KonqProgressProxy to use the new cool
> > > >   progress bar of Konqy :-)
> > > > 
> > > > (yes, embedding works better and better, but still unstable :-(
> > > Hmm, if libkonq is supposed to be linked against something else than
> > > kdebase's
> > > tools, it should be in kdelibs!
> > 
> > We should ask David, as he started libkonq.
> > 
> > David - what do you think?
> 
> I think people are mixing up stuff here.
> 
> The DESIGN file for libkonq says :
> libkonq is the construction kit for a file manager
> 
> To me, kdesktop, konqueror and possibly kfind are some sort of file managers.
> kview isn't.
> If something is in libkonq currently and is needed by kview, then it has nothing
> to do with file management and should be moved to kdelibs/corba (this KonqProgressProxy
> stuff, which I don't know, looks like a generic OPProgressProxy to me, isn't it ?)

Ok, this way I misunderstood your idea behind libkonq, I'm sorry for that.

KonqProgressProxy is a plain tool. You *can* live without it, but it
avoids code duplication.

It's meant for implementations of the Browser::View interface. I just
recently added two signals for progress indication (see progressbar plus
transfer-speed item in Konqy's statusbar) .

Since most (currently all) views use KIOJobs, their informative signals
are good as "source" for these Browser::View signals. As the process of
mapping the information of these signals to the Browser::View stuff is
always the same, I put the handling in this separate class, to avoid code
duplication. As KView uses KIOJob's as well, I though it'd be nice to use
this class there, too, and I therefore put it in libkonq.

However it seems this is the wrong place, so I wonder whether you have an
idea where to put it? Or should we leave it closed in konqueror and
requiring every Browser::View implementation using KIOJobs do have to the
same code all the time?
Perhaps they should just copy the konq_progressproxy.* files?

> > (IMHO kdebase is a nice place for it, as it isn't use that widely, yet) .
> > And as it contains konqueror specific stuff a place near konqueror looks
> > nice to me (although it itself (and kview) does *not* depend on
> > konqueror).
> We can't ask people to install some libs from kdebase before compiling kview.

see KIOJob issue. (same for apps using mimetypes)
 
> > And in addition we require an installed kdebase with the current setup
> > anyway.
> We don't (at least not for other apps in kdegraphics besides kview), do we ?

All apps using KIOJobs for example. (and you know yourself which apps use
them, as your ported most of them :-)


Bye,
 Simon

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