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

List:       kfm-devel
Subject:    Re: konqy issues (22.02.2000)
From:       Michael Reiher <michael.reiher () gmx ! de>
Date:       2000-02-29 13:04:22
[Download RAW message or body]

Hi (Alex),

aleXXX wrote:
> 
> My textview is not ready yet, I will update from cvs next week, then adopt it
> to the changes and then commit.
> 
Donīt know how your textview will look like, though. I imagine something
like kfms textview.  If this is the case then it is IMHO the wrong
approach to create yet another view. I planned to attack this and other
related problems after my last exam tomorrow. Let me show you my
thoughts:

1. The View menu is really cluttered. It may be reasonable from a
developers point of view, but not from a users. 

2. I want a Detailed View like KFM had:)

My idea:

1. The View Menu should have entries like this for all file displaying
views:

------------
View Mode  > ---------------------------| Text aside Icons (i.e.
QIconView based)
Icon Size  > -----------------| Large   | Text below Icons (i.e.
QIconView based)
Sorting    > --| By Name      | Medium  | Detailed View    (i.e.
QListView based)
------------   | By Date      | Small   | Detailed Tree    (i.e.
QListView based)
               | By MimeType  | None	| Directory Tree   (i.e. QListView
based)
               | By Size
               |-------------
               | Descending

This is consistent for all views. Which means there are no suddenly
disappearing items and the user finds the same option always at the same
place. This would also allow for instance to have a tree like view with
large font _and_ large icons e.g. for people that have problems with
their eye sight

The question is wether this is kind of menu structure possible with
current KParts(kxmlgui?)?
Perhaps just every view needs to publish the same menu structure? Yeah,
it could be that easy:)

Your textview would be a combination of Detailed View and No icons.

2. Merging of Dirtree, the other tree and the not yet existent detailed
view to one OListView based configurable view.

Feel free to start on that stuff. But IMHO this is the way to go.
Removing code duplication by merging views instead of creating new ones
which do actually the same. But if I understood wrong what you mean with
TextView, please correct me.

Greets

Michael



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

"Beware the woods at night, beware the lunar light!"

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