File dialog layout

[Adrien BUSTANY]

Aaron J. Seigo a écrit :
> 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.
>   
Well, how could I refuse that then... ;)
>   
>> 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
>
>   
AnnotationPlugins return AnnotationResources, which are wrappers around 
a standard Nepomuk::Resource object (from the core Nepomuk classes). 
This wrapper adds a label, a description and an icon to make the object 
"displayable" easily. You can at any time access the function from the 
underlying Resource object, for example its uri.
>> 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.
>   
Seems OK to me.
> 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)
>   
Well I never got any crash due to AnnotationPlugins... But I'wouldn't 
pretend they're bug free :)
> what are your thoughts?
>
>   
I definitely agree with you. That'd be a real use of AnnotationPlugins, 
which were designed to be the equivalent of Lego bricks for Nepomuk (ie 
allow developpers to use Nepomuk without worrying about how it really 
works under the hood). All the projects I developped this summer at 
Mandriva's (KRunner module, people tagging app, nepouk resource 
explorer, konqueror extension...) all live in the playground for the 
curious.

Cheers

Adrien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080912/89ea7cdf/attachment.htm>