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

List:       kfm-devel
Subject:    RE: konqy listview configurability
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-20 12:55:21
[Download RAW message or body]

> On Mon, 20 Mär 2000, David Faure wrote:
> > > I added members m_bShowFileSize and so on to konq_propsview, 
> > > this seemed to me the right place.
> > 
> > You added a ton of member variables ???
> 
> Additionally to m_bShowDot, which belongs to the same category.

Not at all since ShowDot is possibly per-directory.
You don't want per-protocol, so I don't think you want per-directory at all.

Looks how unflexible your approach is.
You bloated KonqPropsView with a ton of hardcoded member variables.

In fact, you removed a flexible feature (that already exists!) and
implemented it in a hardcoded way, because you don't see how to implement 
the UI for the flexible feature, and I think that's wrong.
The UI should match the best features, not lead to reduce them.

> > > Here where I have cvs access I have cvs from thursday, at home too.
> > > If I copy the fresh cvs over the old cvs at home I'm sure 
> > > everything will be
> > > recompiled (around 5 hours), I'm not sure what happens to 
> > > Makefile.am's, new
> > > directories and so on.
> > 
> > I'm not sure I understand the problem here.
> 
> I'd like to spend less than 5 hours for recompiling ;-)
> If I cvs update here and carry it home and compile 
> everything, it takes 5 hours.
> I'm not sure what happens if I simply copy the updated cvs
> tree over my sources at home (new directories, changes in 
> admin/ , removed/added files and so on). 
> Is there a way to get only the modified files into an extra 
> directory ?
> Something with diff ? 
> Some nice script ?
> (as you see I don't know very much about using cvs)

Just do a tar file, and it will keep time stamps. Or 
do both copies using cp -a. But since kapp.h changed, you're in
for the full recompilation anyway.
You could try just libkonq and konqueror first, but I'm pretty
sure it will break somewhere.

> > > * default to almost all columns in the following (fixed) order
> > >   -name always, then size,modification time,rights,owner,group,link
dest
> > Why hardcode this ?
> 
> If the order isn't hardcoded a dialog for configuring the 
> order is required, I think. This is to far away for the user IMHO.

We agree on that. A menu is much nicer - but doesn't allow
changing the order. But that's true with both approachs !!
At least the current one allows to edit the config file to change
the order. And the default order would still not be random, it
would be the one listed in the protocol's desktop file.
With your approach, you (the developer) hardcodes the order,
and I think that's worse.

> > What about protocols that don't support all of this ?
> 
> Empty columns ;-)
> And they will actually always be at the right edge
Why ?
How can you ensure that ?

> that's why it's no big problem to me, there won't be gaps between columns.

No, but a ton of ugly empty columns...

> I don't like it very much if things appear/disappear and I didn't do it.
You did, when you changed the current protocol.
You're looking at a completely different kind of information, possibly,
so why not change the way it is shown ?

> E.g. I know actually nothing about gopher. If I would try to 
> access something with gopher, then suddenly columns would disappear. 
> I would try to reenable them in the menus.
Why, since those are empty ?
Why would you look for "Link" in the menus, if you don't need it ?
You can't need it, since gopher has no idea what a link is.
Keeping the column is even worse. It means: there may be links, keep me in.
But since you don't know gopher, you don't know you can remove the column.

> Then I would see it is disabled -> aha, maybe
> automatically disabled because it's not supported by gopher ?  
Well, yes, and that makes sense.

> Otherwise -> column is empty -> aha, no information available !
That makes sense too, when the information _could_ be available,
like symlinks on local dirs. In gopher (and a ton of other protocols)
symlinks have no meaning at all. So it's more than
"no info". It's "this column is nonsense with this protocol, let's remove
it".

> > > Opinions ?
> > > (maybe also somebody additional to David ?)
> > Yeah, you don't like my point of view on this, do you ? :-)
> > I also would be interested in other's point of view.
> 
> I wanted to clearly state the two variants, state my opinion 
> and hear opinions from others.
ok

> My opinion was "_maybe_ a _little_ bit better, but _much_ more code"
> -> more bugs possible and slower startup, e.g. konqy still takes
> some seconds to load on my machine, the kdeinit (is it 
> actually used now by konqy ?) didn't decrease startup time "feelable".
This has _nothing_ to do with the issue at hand.
And no, sorry, it's not MUCH more code. It's even less if you
compare iterating over a dict with a lot of manual code
for each hardcoded member variable.

> The "ok" below your conclusion meant "ok with me, if others also
> prefer this I'll do it this way".
Oh, ok, sorry. I missed this one.

> P.S. I could send you my sources so you could see how it 
> works. I commented your code out, because I wasn't sure, 
> that's why I asked.
Yes, I'd be glad to look at that tonight.

David.

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