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

List:       kde-core-devel
Subject:    RE: konqy issues (22.02.2000)
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-02-29 9:54:59
[Download RAW message or body]

> Hi,
> 
> some more thoughts on konqueror, still from 22.02.2000:

I strongly suggest you subscribe to kfm-devel@kde.org,
which is the real list for konqueror development :)

> While working on a text-only view for konqy I had to add a 
> friend-declaration (correct term ? ) of my class in konq_props.h (not sure
if 
> this is the exact filename). I had to do this because the members of
KonqProps 
> are protected and there are no access-functions.
> Is there a reason for this ?
There was a the time but you're right, this shouldn't be the case anymore,
in order to be flexible.
I don't like classes that have setXyz() and xyz() accessors - this means
they just act as repository whereas real classes do all the stuff
with their data and don't need to provide accessors.
So I suggest we make those public, i.e. the whole thing could
be a struct in fact.
That's what view properties are : a struct of data, but which
also knows how to save itself to a file and load itself from a file.

> Would be good to have, then views could be written without 
> changing a single line in konqy. (users could write a doom-like view,
where 
> your files are monsters and you kill them if you want to delete them or 
> whatever views) :-)
Don't joke, a 3D view is coming, apparently :)
Not a doom one though :)
BTW, your idea is dangerous: you kill more monsters in doom than you delete
files in reality... End of the game: go to the trash and put the files
back in place :)

> Bug: if I have konqy in my textview (or treeview), click on a 
> file, the file is displayed, click the up-button, the view changes to
iconview 
> (instead of the formely active view-mode).
It doesn't do that with the treeview (afaik), so I guess
it's only a matter of registering your view as a service
for inode/directory. konqueror is supposed to prefer the current
view if the servicetype matches.

But if you commit, I'll be able to look into this more easily.

> Would be nice to have a function "Close sibling view" (i.e. a 
> function which closes not the current avtice view, but all 
> "siblings" of the active view).
Ah, you mean : close all but this view, to make it full-window ?
Sounds like a good idea.

> Would be nice to have a function "Open view in new window", 
> i.e. not create a cloned konqy with all views, but a konqy containing only
the 
> currently active view.
MMB an icon on the iconview does that.
Doesn't RMB/New View do that as well ? Hmm, perhaps not.

> I was really impressed how easy it is to create a new 
> view-mode and how little has to be changed in konqy therefor (just the one
line 
> mentioned above).
> I also tried to add a "Close sibling"-like thing 
> (close(chooseNextView()), gave not the expected result), and was also
impressed how easy 
> this was to add the the action-stuff :-)

:)

Thanks !

David.

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