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

List:       kfm-devel
Subject:    Re: konqueror issues
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       1999-02-13 1:46:44
[Download RAW message or body]

Simon Hausmann wrote:
> 
> On Thu, 11 Feb 1999, David Faure wrote:
> > On Thu, Feb 11, 1999 at 06:19:15PM +0100, Michael Reiher wrote:
> > > > Come on, let's make it _really_ generic, with as many views as the \
> > > > user wants to.
> > > OK! And the views should be OpenParts.
> > 
> > That's a good point... To OpenParts experts (Simon, ...) : is this \
> > possible ? Would it mean that a view could be a kword document ? :)
> > That would be great ! - Although a bit special :)
> 
> Well, embedding koffice apps won't work for several reasons:
> a) Konqueror uses OPMainWindow, and KOffice apps use koView. And \
> registering a koView to an OPMainWindow doesn't work.
Whatīs the reason that for that? Could you please give a more detailed
description? I mean all the important KOffice classes are derived from
similar op classes. KoViewIf : OPViewIf, KoMainWindow : OPMainWindow and
so on. (btw I didnīt find koView, do mean KoViewIf?). The other thing is
that I thought that it doesnīt matter how the classes are implemented,
they only need to have the same interface? So that you have an interface
for view components for some basic functions e.g. to export *bar entries
and all components that export this interface can be used as a view
component. I thought thatīs what CORBA is about?!?
Please consider that I didnīt had the time yet to take a deeper look in
that KOM/OpenParts/KOffice stuff:)

> b) KOffice apps don't support \
> OpenParts::Application::{createPart,createDocument,createMainWindow} . \
> Instead they use KOffice::DocumentFactory to create document objects, and \
> so we'd need to link libkoffice* to konqueror, and that's of course not \
> our intention.
Well, I donīt exactly know what that means but could that be implemented
afterwards? Or maybe write a wrapper?
> 
> BUT:
> I think that in the future more and more KDE applications will use \
> OpenParts, and embedding opViews/opParts is possible if these apps \
> support one of the OpenParts factories or directly the \
> createPart/createDocument/createMainWindow methods of OPApplication \
> (perhaps we then need to do minor adjustments to support the \
> document<->view model) 
> And then there's still one problem left: .......a kind of trading/imr \
> service for KDE (just like in koffice) . (hello Torben :-)
> 
> I like the idea of making konqueror "open" . What I'd like
> to see in konqueror
> is for example:
> - a plugin interface for views (perhaps using khtml's
> embed tag) .
Do you think that this is a good idea? I mean there should be a HTML
component an that should be exchangable. So I donīt think that it is
good to rely on special tags. I would say make the web browser just
another view.

[snip]
> > > > Only issue is about trees : are they just another view in tree \
> > > > mode, or are they opened as 'the tree for view X', so that it \
> > > > follows the navigation in view X ?
> > > First I would say only one "tree" class, but that _completely_
> > > configurable. You should be able to configure the shown columns and
> > > their order and switch between different sets with a key
> > > combination(like MCs Alt-t), their starting dir. Further it should \
> > > have user defineable top level items i.e. root, home, desktop, cdrom, \
> > > other hds or ftp servers. Maybe that UDS stuff is useful for that? \
> > > Does anyone know where I can get more information about that? Open \
> > > ftp servers could be added(and removed) at runtime. Trees could be \
> > > made connectable to any view by the user at runtime. It shoulnīt also \
> > > be so hard to turn the current tree widget into a long list view. Iīm \
> > > currently forced to work with 800x600 and there I would prefer only \
> > > to have the file names in the first column and not a tree structure \
> > > because all the indents are wasted space. And that is limmited.
> > > That are only some of my ideas:)
> > > Are there already any detailed design plans for that stuff? Torben?
> > Those ideas about the tree view are great. I don't think there are any
> > design plans for something as elaborate as the above. Feel free to
> > contribute :)
> 
> WOW! THIS SOUNDS REALLY EXCITING!!!!
> (...and imagine this "tree" class would be also accessable via a CORBA
> interface....
> <dream>
> Other apps can "remotely" extend/modify the tree
> </dream>
> )
Yeah! Thatīs also something I have in mind. But didnīt think about it
how it can be done in detail.
So I would go ahead with that tree stuff, if you donīt mind. But I canīt
start at once, because I have really no time right now. Although Iīd
really like to:( 
But in one or two weeks I will have time again. 
> 
> Ciao,
> Simon (who's trying to come back to reality ;-))
Good luck!:) I donīt even try:)

Michael
> 
> --
> Simon Hausmann - Tronical^Colorfast - <tronical@gmx.net> - IRCNet \
> #colorfast 
> Life's not fair. But the root password helps. :-)

-- 
Michael Reiher  
     Student at Dresden University of Technology
          Department of Computer Science
               email: michael.reiher@gmx.de


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