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

List:       kfm-devel
Subject:    Re: Modified Konqueror
From:       Martijn Klingens <mklingens () ism ! nl>
Date:       2001-10-17 11:37:19
[Download RAW message or body]

On Wednesday 17 October 2001 12:49, David Faure wrote:
> Yes and no. Konqueror has a fullscreen mode, as you have certainly seen,
> and you can activate it with DCOP, doing
> dcop konqueror  'konqueror-mainwindow#1' activateAction fullscreen

We tried exactyle this for our kiosk application, but it turned out not to be 
the best solution.

> However the user will be able to exit the fullscreen mode using the
> right-mouse-button, but you can easily disable that using konqview's
> enablePopupMenu(false). Hmm, but how to get hold of the KonqViewIface dcop
> interface ? I think you need to call dcopObject() in the KonqView::KonqView
> constructor, after m_dcopObject=0. Whoever added that dcop call is
> certainly on kfm-devel and will be able to comment, hopefully ;)

Besides, the keyboard accellerator is not disabled this way. There were so 
much ways to regain parts of the 'interactive' Konqueror that it would have 
taken serious effort to close all of those potential security holes.
Not to mention that polling Konqueror whether e.g. fullscreen was turned off 
and turning it on again was rather slow.

> I'm not too sure how you could do that, either.
> If you were using two konqueror views (a splitted window), you could use
> KonqView's openURL. With an HTML frameset and HTML frames, it's all one
> view as far as konqueror is concerned. You could then use some javascript
> to change the location of one frame, but I'm not sure how to activate
> javascript code from a DCOP call. Anyone ?
>
> Note that you could simply modify the code, add a dcopinterface to
> khtml_part, with a single "executeScript" method, that allows to do that.
> Or a dcop call that changes the url of the frame directly, to avoid any
> javascript in the middle.

I'd recommend you to write your own application instead, using KHTMLPart, 
unless you really really need features that Konqueror provides and KHTML does 
not. The only two things that spring to mind here are the Konqueror GUI 
itself and the Konq plugins. The file management portion is obviously not 
needed for your app and is hence not an argument for using the 'real' Konq.

The help for KHTMLPart is very complete and easy to use. Also, a 
recent kapptemplate (from the KDE SDK package) that I tried shows a pretty 
complete 'browser' to play with.

> > IBM is investing a lot of money in Linux this year.
> > It is one of our big focuses. You will hear even more things about IBM
> > support for Linux next year, because it will be THE main focus.
>
> Hehe, I know that since IBM is sponsoring hardware for KDE development ;)

Not my hardware, though ;-)

Martijn

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