[haiku-commits] Re: r35085 - in haiku/trunk/src: kits/tracker system/libroot/os
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 15 Jan 2010 15:30:12 +0100
Rene Gollent <anevilyak@xxxxxxxxx> wrote:
> On Fri, Jan 15, 2010 at 2:01 AM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > wrote:
> > anevilyak@xxxxxxxxx wrote:
> >> More Tracker refactoring:
> >> * TrashWatcher now keeps icons in sync on all volumes.
> > Does that really make much sense?
> The reason I did so was because, since the Trash dir is now visible
> from the root of every volume, it would look odd if you added an item
> to Trash and only the one on /boot showed up with the "trash full"
> icon while all the others showed empty (regardless of which volume
> the
> item was moved to trash on).
Besides the general attribute issue with multi-user, maybe it would
make more sense to use a standard folder icon for the trash, as you
cannot know the contents of the trash of the other users.
> > What were your reasons not to follow the symlink approach, btw?
> > I'm just asking; I don't really mind, as it doesn't really change
> > anything from the status quo, anyway.
> The main issue I had with the symlink approach is it's quite
> cumbersome as far as showing the correct context menu, since it means
> that the mouse handling logic would need to resolve the model's link
> to determine it's in fact pointing at the trash, which, afaict is not
> a reversible op on the model, so I wanted to avoid side effects there.
> Also it seemed odd to me to have what looks like a symlink but doesn't
> allow you to do any of the usual symlink ops, so I went with this
> approach instead. Also since this way doesn't require any actual file
> to exist in the Desktop dir.
At least in Haiku you could actually delete the Trash directory from
your Desktop, though :-)
Not that I would miss that.
> > I'm not sure if uppercase "Trash" is the name we should choose, as
> > we
> > only have lowercase directories otherwise.
> With respect to the uppercase name, the problem is that BPose adopts
> the on-disk name of its Model, and since the desktop instance of
> Trash
> is essentially now a pose with a model pointing at /boot/Trash, that's
> the name it will take, whichever case it has. I could possibly
> override that with a Model subclass though, will need to research
> that
> a bit, as we'll want to be able to override the name anyhow for
> localization reasons.
Which could be a genuine Model feature then, I think.
> If that's workable, should I modify
> find_directory to make the on-disk name /trash? Ideally I'd really
> rather just not have the trash dir visible from the volume root but
> I'm not sure as to the best way to go about that for the moment
> without hurting dir population performance and/or the caveats of
> resurrecting the previous hidden pose approach.
Not sure what you are referring here exactly. What possible performance
problems do you see because of what change?
> > That reminds me: our FAT file system isn't called "dos" anymore...
> Will update that too, what does ours name itself as?
"fat".
Bye,
Axel.
Other related posts:
