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

List:       kfm-devel
Subject:    Re: konqy issues (22.02.2000)
From:       aleXXX <alexander.neundorf () rz ! tu-ilmenau ! de>
Date:       2000-02-29 13:16:21
[Download RAW message or body]

On Die, 29 Feb 2000, Michael Reiher wrote:
> Hi (Alex),

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

I want a detailed view like mc has. :-)

> My idea:
> 
> 1. The View Menu should have entries like this for all file displaying
> views:
> 
Small changes:

------------|
View Mode  >+---------------------------| One Directory
Icon Mode  >+-----------------| Disable | Tree
Additional >+--------| Size   |--------
            |        | Date   | Large
            |        | Perm.  | Medium
            |        | Owner  | Small
            |        | Group  | -------
Sorting    >+--| By Name      | Text below Icons
------------|  | By Date      | Text beneath Icons
               | By Size      |-------------
               | By MimeType 
               |-------------
               | Descending

Yes, would be nice.
But would it allow to integrate user written views easily without
recompiling/changing konqy ?
I think it is an ass-kicking feature if konqy can use plugin-like views to show
the directories, unbelievable open and modifiable.

With this menu-structure the *combination* of switches would decide which
view to use, so either there would have to be a hard-coded logic which decides
which view to use or the views would have to come with a very exact description
of their abilities, but then this would probably not be unambigous.

E.g. iconview would be "One directory" and nothing from
"Additional" selected. "One directory", "Large Icons", "Size", "Date" would be
a heavily modified TreeView or a heavily modified IconView.

E.g. David (me too) mentioned a 3D-view, how could this be integrated ?

The menu you mentioned had some "bugs": it would be possible to select "Text
aside Icons" and "None" together,"Detailed Views" says nothing about
position of icons.

I think a menu with the "installed" views and a style-guide for the menus of
the views would be better and easier.

> 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:)

As far as I understand it up to now, the view menu only depends on the xml-file
assigned to a view, so this is no problem I think.

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

Ehhm, no.
The TreeView contains a lot of code which is not needed for a view which
displays a single directory.
I want to make the text view as fast as possible, maybe less configurable.
What is most important for you to see in "Detailed View" ?
At the moment I have "Type of file" (not MIME-type, but file, executbale
file, dir, socket, link...), name and size.
For a directory containing about 1500 files (qtcopy/html + kde2/lib) it needs
1600 msecs (measured using QTime.elapsed()).
If I add "modification time" formatted with KGlobal->locale() it already takes
2300 msecs. :-(
But this will probably become configurable.

In other words I'm looking for every line of code I can remove to speed up the
thing.

Bye
Alex
-- 
If they say it's necessary to be disciplined and trained
To transform their new ideas into history and pain
Simply say no
Just let them feel you disagree

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