mirror of
https://invent.kde.org/system/dolphin
synced 2024-09-19 16:31:21 +00:00
Renamed DESIGN into IDEAS. It's basically ideas.
Created DESIGN. It's the current design of konqueror. Classes and stuff. -> This is intended to help new contributers in understanding konqy better. Added a very small TODO - just things not to forget, but to do later. (no need to duplicate the wishlist in it !) Some cleaning in the .h svn path=/trunk/kdebase/konqueror/; revision=21028
This commit is contained in:
David Faure
parent
0b40037c7b
commit
5317330ac7
281
konqueror/DESIGN
281
konqueror/DESIGN
|
|
@ -1,223 +1,84 @@
|
|||
Konqueror Design Document
|
||||
|
||||
Author:
|
||||
David Faure, faure@kde.org
|
||||
|
||||
Last modified: 8 May 1999
|
||||
|
||||
Authors:
|
||||
Waldo Bastian
|
||||
David Faure
|
||||
Simon Hausmann
|
||||
Overall design of konqueror :
|
||||
=============================
|
||||
|
||||
Last modified: 7 Mar 1999
|
||||
The design of konqueror is based on the parent/child part mechanism
|
||||
(basically, a part, i.e. what can be embedded in another application,
|
||||
can have several child parts which are, in the case of konqueror,
|
||||
the different views shown : icon views, tree views, html views...)
|
||||
|
||||
Intro
|
||||
=====
|
||||
I am trying to create a picture of how Konqueror should look
|
||||
like in KDE 2.0. If such a picture is clear, it is easier to
|
||||
build Konqueror such that it will feel like a consistent piece
|
||||
of software. This is of course only my view of the things. If
|
||||
someone has other views please let this know. It will help if
|
||||
a sort of common idea about the future of Konqueror exists.
|
||||
The parent part is called the "main view", implemented in KonqMainView,
|
||||
which derives from OPPartIf.
|
||||
|
||||
KDE 2.0
|
||||
=======
|
||||
I think we should keep Konqueror a "browser": You can browse
|
||||
with it, and look at things. But when you want to _DO_ things,
|
||||
you will need a full-fledged application.
|
||||
The window that contains it, and handles the File and Help menu, is
|
||||
KonqMainWindow, which derives from OPMainWindowIf.
|
||||
|
||||
So you can view HTML with it.
|
||||
You can view directories with it.
|
||||
You can view text-files with it (read-only). (basically kless)
|
||||
You can view images with it.
|
||||
You can view mail-folders with it.
|
||||
You can view newsgroups with it.
|
||||
You can view xxx....
|
||||
The main(), including all the startup mechanism is in konq_main.*
|
||||
Among other things, it creates a KonqTopWidget in order to handle session
|
||||
management - and create the initial KonqMainWindows.
|
||||
|
||||
When you want more advanced manipulating options, modify things,
|
||||
or create things (writing a mail for instance) the "Real (tm)"
|
||||
application should pop up with its own menubars etc.
|
||||
The main view contains several "child views", in order to view several URLs
|
||||
at once, possibly using several modes. Each child view is a KonqChildView
|
||||
- this class implements the view-mode switching, adds the
|
||||
frame header on top of the view (KonqFrameHeader), ...
|
||||
The KonqChildView contains the child part, which can be :
|
||||
- an icon view (KonqKfmIconView)
|
||||
- a tree view (KonqKfmTreeView)
|
||||
- an HTML view (KonqHTMLView) - inherits KBrowser (??)
|
||||
- a text view (KonqTxtView)
|
||||
- a part view (KonqPartView) - to embed a part from any other application
|
||||
KonqChildView uses KonqPlugins, to parse the .desktop files in order to look
|
||||
for plugins, and create a KonqPartView when wanted.
|
||||
|
||||
There is of course a thin line between viewing and modifying.
|
||||
With the file browser you want to be able to move/rename/delete
|
||||
files. So if we allow this functionality for file-browsing, we
|
||||
should also allow it for mail-browsing or news-browsing.
|
||||
(e.g. move/delete message cq. postings).
|
||||
At this point, it would be interesting to read the IDL. It details most of
|
||||
the classes above, defining an interface for it.
|
||||
|
||||
Creating does not really belong in a browser (apart from
|
||||
directories) because you will almost always need an application
|
||||
for this anyway. I seldom go to a directory to select "create xyz".
|
||||
Most of the time you start an application to create "xyz" and
|
||||
when you are done, you think of a nice place to store it.
|
||||
(I think Microsoft wants us to believe otherwise, with their
|
||||
"document-orientated" Windows95 marketing)
|
||||
((Well, sometimes you are browsing and have a sudden urge to put
|
||||
a text-file like README in a directory. But for that you still
|
||||
need a text-editor. Just creating an empty file is of little use.))
|
||||
All of those classes inherit from KonqBaseView, the base class for the child views.
|
||||
|
||||
Why is this important?
|
||||
Additionnally, the icon and tree view define items (one per file). KonqIconViewItem
|
||||
and KonqTreeViewItem, which both inherit KonqKfmIconViewItem (defines common
|
||||
functionality such as url, mimetype, status bar info, dnd drop...).
|
||||
|
||||
Where to find those classes
|
||||
===========================
|
||||
|
||||
kbrowser.* : KBrowser
|
||||
kfmrun.* : Re-implementation of KRun (see libkio) for konqueror. Treats
|
||||
HTML and directory in a special way compared to KRun.
|
||||
kiconcontainer.* : Widget containing icons, for KonqKfmIconView. Will
|
||||
probably be moved somewhere else (libkonq ? kdeui ?)
|
||||
konq_baseview.* : KonqBaseView, base class for all builtin views.
|
||||
konq_childview.* : KonqChildView, class used by KonqMainView to handle child views
|
||||
konq_frame.* : KonqFrame - not used anymore for now - and KonqFrameHeader.
|
||||
konq_htmlview.* : KonqHTMLView, html view
|
||||
konq_iconview.* : KonqKfmIconView and KonqKfmIconViewItem, for icon views
|
||||
konq_kfmview.* : KonqKfmViewItem, base class for items in the icon and tree view
|
||||
konq_main.* : The main() and the definition of KonqApp and KonqApplicationIf
|
||||
konq_mainview.* : KonqMainView, main view, one per main window
|
||||
konq_mainwindow.* : KonqMainWindow, konqueror window
|
||||
konq_partview.* : KonqPartView, embeds parts (e.g. from kview)
|
||||
konq_plugins.* : KonqPlugins, used to parse .desktop files looking for plugins
|
||||
konq_propsmainview.* : -- main view properties stuff, not sure it will remain as is --
|
||||
konq_propsview.* : -- view properties stuff, not sure it will remain as is --
|
||||
konq_topwidget.* : KonqTopWidget, the hidden widget used for session management
|
||||
konq_treeview.* : KonqKfmTreeView and KonqKfmTreeViewItem, for tree views
|
||||
konq_txtview.* : KonqTxtView, a builtin text viewer
|
||||
konqueror.cc, konqueror.h : Files generated from konqueror.idl
|
||||
|
||||
konq_defaults.h : Default configuration values, used by konqueror and kcmkonq (todo!)
|
||||
mousemode.h : Needed by kiconcontainer, to choose between single and double
|
||||
click - do we want to keep this ?
|
||||
|
||||
Libs used by konqueror
|
||||
======================
|
||||
There must be a clear distinction between what can be done with
|
||||
Konqueror and what can be done with the application self. If there
|
||||
is no distinction we don't need Konqueror.
|
||||
|
||||
Smooth integration
|
||||
==================
|
||||
With this Konqueror thing we have to tell the user a thing or
|
||||
two. We have to tell the user what he/she is doing:
|
||||
"Viewing a text-file", "Viewing a web-page", "Viewing a FTP-site",
|
||||
"Viewing e-mail". Because the options available to the user, depend
|
||||
on what he is doing: You can reply to e-mail. But you can't reply
|
||||
to a FTP-site. You can sort the entries of a FTP directory, but
|
||||
you can't sort a web-page.
|
||||
|
||||
At the same time, we have to tell the user that he/she is "Viewing".
|
||||
If you want to edit the web-page, the web-editor comes up. If you
|
||||
want to reply to the e-mail, the mail-composer comes up. At that
|
||||
time the user is editing/changing/modyfying.
|
||||
|
||||
From the users point of view, the "viewing" part is konqueror. The
|
||||
editing part is the application.
|
||||
|
||||
From the developers point of view, this can be different. The view
|
||||
e-mail mode of Konqueror could (but it doesn't have to) be handled
|
||||
by the same instance of kmail as the "edit" mode of kmail. If this
|
||||
will be indeed the case should depend on programming considerations.
|
||||
|
||||
What should not depend on programming considerations, is how it is
|
||||
presented to the user.
|
||||
|
||||
An Example
|
||||
==========
|
||||
Teodor Romeo Mihai wrote:
|
||||
> Well, I've been working for a few months now on a Outloook-clone for
|
||||
> KDE, handling mail/contacts/schedule/journal/notes/groups. It is a bit
|
||||
> different from all KDE applications I've seen, being very close to
|
||||
> Outlook in look&feel rather than KMail - which I find unusable.
|
||||
> If you are seriously planning to put mail in kfm, maybe you should
|
||||
> consider some kind of integration with an external mailer, in
|
||||
> Explorer/Outlook style.
|
||||
|
||||
I'm serious about integrating mail-viewing in Konqueror.
|
||||
(From a user point of view).
|
||||
|
||||
I think it is a very bad idea to put mail-reading code in
|
||||
Konqueror. (From a developers point of view).
|
||||
|
||||
Konqueror should be able to display mail/mailboxes by embedding
|
||||
a mail-viewer. This mail-viewer should (in the case of a mail-viewer)
|
||||
be a seperate application from a developers point of view, but should
|
||||
integrate seemless with Konqueror from the user point of view. This
|
||||
application can be kmail, a light version of kmail, or any other
|
||||
application that can display mails and supports this embedded KFM-view
|
||||
idea.
|
||||
|
||||
For viewing HTML or GIF files, Konqueror will most likely implement
|
||||
the functionality itself. For the user it should not make any difference
|
||||
if a view is implemented in Konqueror itself or in a seperate
|
||||
application.
|
||||
|
||||
The technology to embed the mail-viewer should be something CORBA based.
|
||||
Most likely KOM/Openparts.
|
||||
|
||||
Konqueror should not become a program like Netscape Communicator:
|
||||
A program that tries to do everything itself, and as result, does
|
||||
everything very poorly.
|
||||
|
||||
Konqueror should do it better and the Unix way: Have speciliazed
|
||||
components which are very good in their task. Konqueror provides
|
||||
the seemless integration of them and provides easy navigation
|
||||
abilities.
|
||||
|
||||
|
||||
<tfischer> This means i can create an application (container) which host two parts,
|
||||
which are both ACTIVE, that
|
||||
means i do not need to click the parts before they start repsonding.
|
||||
|
||||
|
||||
Konquerer Views
|
||||
===============
|
||||
When an embedded part gets the focus (e.g. when the users clicks on it)
|
||||
the mainwindow (shell) gets notified about this (the focus change).
|
||||
You can "manually" activate a part by calling a method in the mainwindow
|
||||
interface. There can be only part that has the focus.
|
||||
If you click on a non-activated part the click action itself is not "eaten up"
|
||||
An activated part means the part has focus (keyboard, ...)
|
||||
When you have "plain" parts they usually "have" their own GUI which get's
|
||||
"enabled" (created dynamically) when the part gets the focus
|
||||
Normally this would bring a big problem inside konqueror
|
||||
Because then we'd have lots of duplicated *bar creation code and
|
||||
stuff like this. That is the reason why in konqueror functionality is
|
||||
implemented in openparts to have so called child parts.
|
||||
A child part does _not_ have it's own GUI (as a normal openpart has)
|
||||
instead the part part's gui is used.
|
||||
We still allow konqueror views to have their own view specific gui elements
|
||||
When a konqueror view (=part child) gets the focus the part parent
|
||||
(the mainview) will receive an event (eventChildGotFocus)
|
||||
and this helps the mainview to send yet another event to the just
|
||||
activated view (=part) , an konqueror specific event
|
||||
these events are described in konqueror.idl
|
||||
|
||||
The result is:
|
||||
A konqueror view (that's important, the view must support this interface)
|
||||
can now specify it's own, view specific, menu entries in the edit/view menu
|
||||
plus it's own toolbar.
|
||||
|
||||
This integration is in fact not sooo seamless because:
|
||||
whenever the use activates your khelpcenter part
|
||||
a complete GUI "switch" will take place, meaning all the *bars from
|
||||
konqueror will be replaced by the *bars from the child view
|
||||
|
||||
Therefor another approach is developed:
|
||||
The *bars of konqueror will contain entries for all child-views which are
|
||||
inside the main-view.
|
||||
|
||||
Care should be taken when multiple views want to add the same entries to
|
||||
one of the *bars.
|
||||
|
||||
In the case of a toolbar, only one entry could be added, the child-view which
|
||||
has supplied this entry will be made active when his entry is used and will
|
||||
get the event. If multiple child-views have provided this entry, the currently
|
||||
active child will get the event.
|
||||
|
||||
For the menubar, the entries will be presented grouped per child-view. The same
|
||||
entry could be listed twice in the same menu, but listed under two differents
|
||||
views.
|
||||
|
||||
Transcript
|
||||
==========
|
||||
<tronical> we have a usual mainview (looks/behaves quite like a current kfm window on the screen)
|
||||
<tronical> now we have two views inside, on the left we've got an iconview
|
||||
<tronical> and on the right we've got an htmlview
|
||||
<tronical> now let's say the iconview wants to add a special entry in the common view menu
|
||||
<tronical> no, let's say three entries: mini-/medium-/large icons
|
||||
<tronical> and for the htmlview we've got (in the view menu as well):
|
||||
<tronical> whatevery...hm...*thinking*, perhaps charset-selection of stuff like this
|
||||
<tronical> now when the iconview is active the view menu will contain
|
||||
<tronical> all the usual konqueror (mainview) entries (what could this be for example?) plus the three iconview
|
||||
entries
|
||||
<tronical> and when the users activates the htmlview then view menu will silently change
|
||||
<Zogje> I think it makes sense to have both sets of entries in the view-menu at the sma time
|
||||
<tronical> ok, well, it's possible to do this
|
||||
* tfischer thinks zogje is right.
|
||||
<tronical> there's no change in the design necessary
|
||||
<Zogje> because the user just has a html-view and an inco-view on his screen, and has no idea which one is
|
||||
"active"
|
||||
<tronical> hm, you're right
|
||||
<tronical> ok, but I think we can easily solve this:
|
||||
<tronical> first we create the common konqueror menu entries
|
||||
<tronical> then insertSeparator( -1 );
|
||||
<Zogje> ack
|
||||
<tronical> and then the first views' entries
|
||||
<tronical> then another separator, ...and so on
|
||||
<Zogje> yes
|
||||
<Zogje> that seems quite good
|
||||
<tronical> we might do something like this:
|
||||
<tronical> common konqy entries
|
||||
<tronical> separator
|
||||
<tronical> dummy-not-doing-anything-entry named viewName()
|
||||
<tronical> separator
|
||||
<tronical> view entries
|
||||
<tronical> yet another separator
|
||||
<tronical> second view's name as dummy entries
|
||||
<tronical> and so on
|
||||
<Zogje> yes.. because if we have two html-views... you want to be able to select things for both independntly
|
||||
|
||||
|
||||
kdecore, kdeui, kfile, khtml, kparts - usual stuff :)
|
||||
libkio - I/O stuff, mimetypes, services, registry
|
||||
libkonq - bookmarks, properties dialog, templates ("new") menu
|
||||
|
||||
|
|
|
|||
223
konqueror/IDEAS
Normal file
223
konqueror/IDEAS
Normal file
|
|
@ -0,0 +1,223 @@
|
|||
Konqueror "Ideas" Document (specification, general ideas)
|
||||
|
||||
Authors:
|
||||
Waldo Bastian
|
||||
David Faure
|
||||
Simon Hausmann
|
||||
|
||||
Last modified: 7 Mar 1999
|
||||
|
||||
Intro
|
||||
=====
|
||||
I am trying to create a picture of how Konqueror should look
|
||||
like in KDE 2.0. If such a picture is clear, it is easier to
|
||||
build Konqueror such that it will feel like a consistent piece
|
||||
of software. This is of course only my view of the things. If
|
||||
someone has other views please let this know. It will help if
|
||||
a sort of common idea about the future of Konqueror exists.
|
||||
|
||||
KDE 2.0
|
||||
=======
|
||||
I think we should keep Konqueror a "browser": You can browse
|
||||
with it, and look at things. But when you want to _DO_ things,
|
||||
you will need a full-fledged application.
|
||||
|
||||
So you can view HTML with it.
|
||||
You can view directories with it.
|
||||
You can view text-files with it (read-only). (basically kless)
|
||||
You can view images with it.
|
||||
You can view mail-folders with it.
|
||||
You can view newsgroups with it.
|
||||
You can view xxx....
|
||||
|
||||
When you want more advanced manipulating options, modify things,
|
||||
or create things (writing a mail for instance) the "Real (tm)"
|
||||
application should pop up with its own menubars etc.
|
||||
|
||||
There is of course a thin line between viewing and modifying.
|
||||
With the file browser you want to be able to move/rename/delete
|
||||
files. So if we allow this functionality for file-browsing, we
|
||||
should also allow it for mail-browsing or news-browsing.
|
||||
(e.g. move/delete message cq. postings).
|
||||
|
||||
Creating does not really belong in a browser (apart from
|
||||
directories) because you will almost always need an application
|
||||
for this anyway. I seldom go to a directory to select "create xyz".
|
||||
Most of the time you start an application to create "xyz" and
|
||||
when you are done, you think of a nice place to store it.
|
||||
(I think Microsoft wants us to believe otherwise, with their
|
||||
"document-orientated" Windows95 marketing)
|
||||
((Well, sometimes you are browsing and have a sudden urge to put
|
||||
a text-file like README in a directory. But for that you still
|
||||
need a text-editor. Just creating an empty file is of little use.))
|
||||
|
||||
Why is this important?
|
||||
======================
|
||||
There must be a clear distinction between what can be done with
|
||||
Konqueror and what can be done with the application self. If there
|
||||
is no distinction we don't need Konqueror.
|
||||
|
||||
Smooth integration
|
||||
==================
|
||||
With this Konqueror thing we have to tell the user a thing or
|
||||
two. We have to tell the user what he/she is doing:
|
||||
"Viewing a text-file", "Viewing a web-page", "Viewing a FTP-site",
|
||||
"Viewing e-mail". Because the options available to the user, depend
|
||||
on what he is doing: You can reply to e-mail. But you can't reply
|
||||
to a FTP-site. You can sort the entries of a FTP directory, but
|
||||
you can't sort a web-page.
|
||||
|
||||
At the same time, we have to tell the user that he/she is "Viewing".
|
||||
If you want to edit the web-page, the web-editor comes up. If you
|
||||
want to reply to the e-mail, the mail-composer comes up. At that
|
||||
time the user is editing/changing/modyfying.
|
||||
|
||||
From the users point of view, the "viewing" part is konqueror. The
|
||||
editing part is the application.
|
||||
|
||||
From the developers point of view, this can be different. The view
|
||||
e-mail mode of Konqueror could (but it doesn't have to) be handled
|
||||
by the same instance of kmail as the "edit" mode of kmail. If this
|
||||
will be indeed the case should depend on programming considerations.
|
||||
|
||||
What should not depend on programming considerations, is how it is
|
||||
presented to the user.
|
||||
|
||||
An Example
|
||||
==========
|
||||
Teodor Romeo Mihai wrote:
|
||||
> Well, I've been working for a few months now on a Outloook-clone for
|
||||
> KDE, handling mail/contacts/schedule/journal/notes/groups. It is a bit
|
||||
> different from all KDE applications I've seen, being very close to
|
||||
> Outlook in look&feel rather than KMail - which I find unusable.
|
||||
> If you are seriously planning to put mail in kfm, maybe you should
|
||||
> consider some kind of integration with an external mailer, in
|
||||
> Explorer/Outlook style.
|
||||
|
||||
I'm serious about integrating mail-viewing in Konqueror.
|
||||
(From a user point of view).
|
||||
|
||||
I think it is a very bad idea to put mail-reading code in
|
||||
Konqueror. (From a developers point of view).
|
||||
|
||||
Konqueror should be able to display mail/mailboxes by embedding
|
||||
a mail-viewer. This mail-viewer should (in the case of a mail-viewer)
|
||||
be a seperate application from a developers point of view, but should
|
||||
integrate seemless with Konqueror from the user point of view. This
|
||||
application can be kmail, a light version of kmail, or any other
|
||||
application that can display mails and supports this embedded KFM-view
|
||||
idea.
|
||||
|
||||
For viewing HTML or GIF files, Konqueror will most likely implement
|
||||
the functionality itself. For the user it should not make any difference
|
||||
if a view is implemented in Konqueror itself or in a seperate
|
||||
application.
|
||||
|
||||
The technology to embed the mail-viewer should be something CORBA based.
|
||||
Most likely KOM/Openparts.
|
||||
|
||||
Konqueror should not become a program like Netscape Communicator:
|
||||
A program that tries to do everything itself, and as result, does
|
||||
everything very poorly.
|
||||
|
||||
Konqueror should do it better and the Unix way: Have speciliazed
|
||||
components which are very good in their task. Konqueror provides
|
||||
the seemless integration of them and provides easy navigation
|
||||
abilities.
|
||||
|
||||
|
||||
<tfischer> This means i can create an application (container) which host two parts,
|
||||
which are both ACTIVE, that
|
||||
means i do not need to click the parts before they start repsonding.
|
||||
|
||||
|
||||
Konquerer Views
|
||||
===============
|
||||
When an embedded part gets the focus (e.g. when the users clicks on it)
|
||||
the mainwindow (shell) gets notified about this (the focus change).
|
||||
You can "manually" activate a part by calling a method in the mainwindow
|
||||
interface. There can be only part that has the focus.
|
||||
If you click on a non-activated part the click action itself is not "eaten up"
|
||||
An activated part means the part has focus (keyboard, ...)
|
||||
When you have "plain" parts they usually "have" their own GUI which get's
|
||||
"enabled" (created dynamically) when the part gets the focus
|
||||
Normally this would bring a big problem inside konqueror
|
||||
Because then we'd have lots of duplicated *bar creation code and
|
||||
stuff like this. That is the reason why in konqueror functionality is
|
||||
implemented in openparts to have so called child parts.
|
||||
A child part does _not_ have it's own GUI (as a normal openpart has)
|
||||
instead the part part's gui is used.
|
||||
We still allow konqueror views to have their own view specific gui elements
|
||||
When a konqueror view (=part child) gets the focus the part parent
|
||||
(the mainview) will receive an event (eventChildGotFocus)
|
||||
and this helps the mainview to send yet another event to the just
|
||||
activated view (=part) , an konqueror specific event
|
||||
these events are described in konqueror.idl
|
||||
|
||||
The result is:
|
||||
A konqueror view (that's important, the view must support this interface)
|
||||
can now specify it's own, view specific, menu entries in the edit/view menu
|
||||
plus it's own toolbar.
|
||||
|
||||
This integration is in fact not sooo seamless because:
|
||||
whenever the use activates your khelpcenter part
|
||||
a complete GUI "switch" will take place, meaning all the *bars from
|
||||
konqueror will be replaced by the *bars from the child view
|
||||
|
||||
Therefor another approach is developed:
|
||||
The *bars of konqueror will contain entries for all child-views which are
|
||||
inside the main-view.
|
||||
|
||||
Care should be taken when multiple views want to add the same entries to
|
||||
one of the *bars.
|
||||
|
||||
In the case of a toolbar, only one entry could be added, the child-view which
|
||||
has supplied this entry will be made active when his entry is used and will
|
||||
get the event. If multiple child-views have provided this entry, the currently
|
||||
active child will get the event.
|
||||
|
||||
For the menubar, the entries will be presented grouped per child-view. The same
|
||||
entry could be listed twice in the same menu, but listed under two differents
|
||||
views.
|
||||
|
||||
Transcript
|
||||
==========
|
||||
<tronical> we have a usual mainview (looks/behaves quite like a current kfm window on the screen)
|
||||
<tronical> now we have two views inside, on the left we've got an iconview
|
||||
<tronical> and on the right we've got an htmlview
|
||||
<tronical> now let's say the iconview wants to add a special entry in the common view menu
|
||||
<tronical> no, let's say three entries: mini-/medium-/large icons
|
||||
<tronical> and for the htmlview we've got (in the view menu as well):
|
||||
<tronical> whatevery...hm...*thinking*, perhaps charset-selection of stuff like this
|
||||
<tronical> now when the iconview is active the view menu will contain
|
||||
<tronical> all the usual konqueror (mainview) entries (what could this be for example?) plus the three iconview
|
||||
entries
|
||||
<tronical> and when the users activates the htmlview then view menu will silently change
|
||||
<Zogje> I think it makes sense to have both sets of entries in the view-menu at the sma time
|
||||
<tronical> ok, well, it's possible to do this
|
||||
* tfischer thinks zogje is right.
|
||||
<tronical> there's no change in the design necessary
|
||||
<Zogje> because the user just has a html-view and an inco-view on his screen, and has no idea which one is
|
||||
"active"
|
||||
<tronical> hm, you're right
|
||||
<tronical> ok, but I think we can easily solve this:
|
||||
<tronical> first we create the common konqueror menu entries
|
||||
<tronical> then insertSeparator( -1 );
|
||||
<Zogje> ack
|
||||
<tronical> and then the first views' entries
|
||||
<tronical> then another separator, ...and so on
|
||||
<Zogje> yes
|
||||
<Zogje> that seems quite good
|
||||
<tronical> we might do something like this:
|
||||
<tronical> common konqy entries
|
||||
<tronical> separator
|
||||
<tronical> dummy-not-doing-anything-entry named viewName()
|
||||
<tronical> separator
|
||||
<tronical> view entries
|
||||
<tronical> yet another separator
|
||||
<tronical> second view's name as dummy entries
|
||||
<tronical> and so on
|
||||
<Zogje> yes.. because if we have two html-views... you want to be able to select things for both independntly
|
||||
|
||||
|
||||
|
||||
13
konqueror/TODO
Normal file
13
konqueror/TODO
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
(from kfm)
|
||||
- Nice ftp dialog for users who do not know how to put their
|
||||
use name in a URL.
|
||||
- Sorting by date, ...
|
||||
|
||||
- (Following to discussion with Sven) : Update kpropsdlg so that it can show
|
||||
up with a default mimetype / application / .... It would _know_ the
|
||||
filename but would only use it to write, not read at startup.
|
||||
This involves making New/Mimetype and New/Application built-in
|
||||
templates, just like New/Folder, since the file would be not used at all.
|
||||
|
||||
and see http://bugs.kde.org/db/pa/lkfm.html !
|
||||
|
||||
|
|
@ -37,7 +37,6 @@
|
|||
#include <kio_interface.h>
|
||||
#include <kurl.h>
|
||||
|
||||
class KonqKfmView; //below
|
||||
class KMimeType;
|
||||
|
||||
class KonqKfmViewItem
|
||||
|
|
|
|||
Loading…
Reference in a new issue