File dialog layout

[Aaron J. Seigo]

On Friday 12 September 2008, Adrien BUSTANY wrote:
> Aaron J. Seigo a écrit :
> > On Friday 12 September 2008, Celeste Lyn Paul wrote:
> >> On Friday 12 September 2008 05:52:26 Andre Gemünd wrote:
> >>> On Fri, Sep 12, 2008 at 10:47 AM, Alexander Dymo <dymo at ukrpost.ua> 
wrote:
> >>>> This does mean
> >>>> that there's much less space left for the useful information (like the
> >>>> list of
> >>>> files). Why don't we put the breadcrumbs back to the toolbar?
> >>>
> >>> I think its meant for a search widget once its feasible.
> >
> > i actully added the search widget yesterday, at least on the file dialog
> > side. now i need to hook it up to .. nepomuk? i haven't decided exactly
> > how to handle that part of it, but once it's actually working i'll commit
> > that bit too.
>
> This could be Nepomuk, but there's no class to do that at the moment (ie
> you have to do your queries manually).

that's what i was planning to do, but i like your idea even better ;)

> I could write an AnnotationPlugin
> (which are high level classes to query data) for files,

that would make my life wonderous and happy.

> but :
> 1. We'd first have to agree on how to filter the results (just filename ?)

we'll want the full URL; we only show the filenme, but we need the full 
location

> 2. AnnotationPlugins are in the playground, and although the API is much
> more stable than when I started them, it might maybe change again one
> day (maybe without breaking BC ?)

we can keep them private to the file dialog library which would make BC 
irrelevant. this would also give them a use case to test them out against.

so ... how to move forward ... 

the easy way would be to just copy the relevant files into kdelibs/nepomuk/ and 
build them with kdelibs/kfile/ as private classes, and we wouldn't install the 
headers.

the plugins would live in the same area and so if/when the API/ABI changes, 
the plugins would as well. eventually the plugins should move to 
kdebase/runtime, but that would require a stable API/ABI. until that point, we 
can house them temporarily in kdelibs/nepomuk/

that would make my life a lot easier with the file dialog and would start to 
expose the value of nepomuk to users in yet another very visible area. of 
course, since we'd be using these classes in the file dialog, while the API/ABI 
doesn't have to be stable, the code itself needs to be stable (no crashes, 
hangs, etc)

what are your thoughts?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080912/ff8d1b36/attachment.sig>