File dialog layout

[Sebastian Trüg]

On Monday 15 September 2008 21:41:39 Aaron J. Seigo wrote:
> On Monday 15 September 2008, Sebastian Trüg wrote:
> > On Monday 15 September 2008 18:18:40 Aaron J. Seigo wrote:
> > > > As for the info: so far you only get normal file information or
> > > > actual Nepomuk resources which are of course not handled by KDE apps
> > > > yet.
> > >
> > > perhaps i could make the file dialog handle those resources and have it
> > > spit out urls on the other side?
> >
> > All resources have an URI.
>
> ...
>
> > > KDE 4.3:
> > > * make the file dialog aware of Nepomuk resources
> >
> > I think this makes only sense once applications become able to handle
> > Nepomuk resources.
> > Until then it could be useful to always add another search parameter to
> > restrict to file resources... but we can work on the details later. :)
>
> yes, we would always have to restrict the *file* dialog to resources that
> resolve down to files and then provide an additional parameter that
> applications can set, much like they do with filters, that describes what
> sort of resources they understand.

very good.

> my motivation for uses resources direction in the file dialog, though,
> would be to get at things like properties, tags, annotations and
> descriptions. these could be used as additional hints in the search results
> or as categorization labels.
>
> > > * create a view for these returns if one doesn't already exist in
> > > Nepomuk-KDE and use that view when searching instead of browsing
> >
> > Again: here I do not follow and don't get why there needs to be an
> > additional view.
>
> where in KDirOperator will we be able to show to the user why the item was
> selected?

see below for a basic idea.

> we can do grouping with KCategorizedView, but KDirOperator doesn't provide
> that itself and we'd need to populate a categorizabe model as well.
>
> listing the contents of a physical folder is fairly straightforward and
> simple, while listing the results of a search and doing a good job of it i
> sprobably a slightly different story.
>
> imagine if google's search results looked like a directory listing. =)
>
> for the immediate time, having a simple listing is probably fine. but we
> can do a lot better given the information Nepomuk gives us access to. or am
> i overestimating the usefulness of Nepomuk? ;)

not at all. All we need to do is get the information and show it. I would 
propose that we define a query API extension to the Nepomuk query API that 
returns "result explanations". This could then be added as an extra field to 
the UDSEntries. Then the simplest way would be to make KDirOperator aware of 
this field.

Cheers,
Sebastian