<!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 écrit :
<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 é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ü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"><dymo@ukrpost.ua></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>