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

List:       kde-core-devel
Subject:    Re: File dialog layout
From:       Adrien BUSTANY <madcat () mymadcat ! com>
Date:       2008-09-12 16:10:41
Message-ID: 48CA9481.9090708 () mymadcat ! com
[Download RAW message or body]

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@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


[Attachment #3 (text/html)]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Aaron J. Seigo a &eacute;crit&nbsp;:
<blockquote cite="mid:200809120852.32158.aseigo@kde.org" type="cite">
  <pre wrap="">On Friday 12 September 2008, Adrien BUSTANY wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Aaron J. Seigo a &eacute;crit :
    </pre>
    <blockquote type="cite">
      <pre wrap="">On Friday 12 September 2008, Celeste Lyn Paul wrote:
      </pre>
      <blockquote type="cite">
        <pre wrap="">On Friday 12 September 2008 05:52:26 Andre Gem&uuml;nd wrote:
        </pre>
        <blockquote type="cite">
          <pre wrap="">On Fri, Sep 12, 2008 at 10:47 AM, Alexander Dymo <a \
class="moz-txt-link-rfc2396E" \
href="mailto:dymo@ukrpost.ua">&lt;dymo@ukrpost.ua&gt;</a>   </pre>
        </blockquote>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->wrote:
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">
            <pre wrap="">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?
            </pre>
          </blockquote>
          <pre wrap="">I think its meant for a search widget once its feasible.
          </pre>
        </blockquote>
      </blockquote>
      <pre wrap="">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.
      </pre>
    </blockquote>
    <pre wrap="">This could be Nepomuk, but there's no class to do that at the moment \
(ie you have to do your queries manually).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
that's what i was planning to do, but i like your idea even better ;)

  </pre>
  <blockquote type="cite">
    <pre wrap="">I could write an AnnotationPlugin
(which are high level classes to query data) for files,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
that would make my life wonderous and happy.
  </pre>
</blockquote>
Well, how could I refuse that then... ;)<br>
<blockquote cite="mid:200809120852.32158.aseigo@kde.org" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">but :
1. We'd first have to agree on how to filter the results (just filename ?)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
we'll want the full URL; we only show the filenme, but we need the full 
location

  </pre>
</blockquote>
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.<br>
<blockquote cite="mid:200809120852.32158.aseigo@kde.org" type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">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 ?)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
  </pre>
</blockquote>
Seems OK to me.<br>
<blockquote cite="mid:200809120852.32158.aseigo@kde.org" type="cite">
  <pre wrap="">
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)
  </pre>
</blockquote>
Well I never got any crash due to AnnotationPlugins... But I'wouldn't
pretend they're bug free :)<br>
<blockquote cite="mid:200809120852.32158.aseigo@kde.org" type="cite">
  <pre wrap="">
what are your thoughts?

  </pre>
</blockquote>
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.<br>
<br>
Cheers<br>
<br>
Adrien<br>
<br>
</body>
</html>



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

Configure | About | News | Add a list | Sponsored by KoreLogic