[Nepomuk] Nepomuk Controller

[Vishesh Handa]

On Fri, May 3, 2013 at 12:55 AM, Jörg Ehrichs <Joerg.Ehrichs at gmx.de> wrote:

> Hi Vishesh
>
> 2013/5/2 Vishesh Handa <me at vhanda.in>:
> >
> > The new controller needs to solve these criteria for all kinds of
> indexing.
> > Not just files. So we need the following use cases to be satisfied -
> >
> > 1. Quick Overview - Quickly see if something is being indexed
>
> see end of mail
>
> > 2. Detailed Information - Which file/email/contact? Progress %?
>
> The progress information need to be added to the services and currently
> I have no clear idea what progress will  be shown.
>
> For the file indexer we could show the progress for each batch of files?
> or 100% means all indexed files and current progress is the amount
> files 100- indexing level 1 ?
>
> the akonadi feeder currently shows just an overall progress and nothing
> that can be split between mails and contacts/calendar
>

I can add the required features to the akonadi feeder.


> > 3. Pause/Resume indexing - (Optional - suspend/resume only some
> > types of indexing - but I personally think the user shouldn't have to
> care
> > that much)
>
> ok.
>
> >
> > And finally, it should provide information about "File Metadata update"
> > operations when the file metadata is being updated after a large file
> > move.
>
> isn't this the data shown from the filewatcher?
>

Yup. That's exactly what I was talking about. Right now it's fairly
configurable and one can choose if they should be shown. Also, it's
disabled by default.


> >
> > The new controller solves (2) and (3) to a certain extent, though I feel
> > it's too technical. The user shouldn't have to care about each service.
> > That's just an implementation detail.
> >
> > In order to solve (1) the following needs to be implemented -
> >
> > The old Nepomuk controller used to only become active if there was
> > activity for more than 2 seconds. In our new one maybe we should keep
> > it to about 10 seconds?
> >
>
> This is already implemented but with 3 seconds delay at the moment.
> The current plasma updated script simply set the " always visible"
> settings for the controller
>
> To get back to the old behaviour change the setings:
> * rightclick the arrow in the taskbar and enter setting
> * Entries -> set nepomuk controller to automatic
>
> I'll change the update script accordingly than
>

That would be perfect.


> >
> > b. Easily know what's going on - This should ideally be done via a
> > system popup when hovering over the widget. Something simple like
> > "Files and Emails are currently being indexed"
> >
>
> At the moment there is a tooltip when you move your mouse over the tray
> icon
> that shows the message retrieved via dbus for each active service
>
>
My bad. I tested the tooltip out with the broken version. It's working
quite well now.


> > -----
> >
> >
> > See the attached image
> >
> > This clearly shows what is being indexed and even gives a kind of
> > progress meter which the user can consult if they are interested.
> > Though it just occurred to me that maybe there should be a global
> > progress bar as well?
>
> What would be the content of the global progressbar?
> I believe this would result in confusing data that goes up/down
> everytime. Currently no usefull progress is emitted from the akonadi
> feeder, nor from any other nepomuk service.
>

We can add that :)


>
> >
> > Please note that the "Indexing Emails/Files/Blah" will only be shown when
> > something is being indexed. Otherwise it will be blank.
> >
>
> Looks nice, but here we have one problem. If I'm not mistaken
> the akonadi feeder does not return what kind of collection it is processing
> at the moment, instead it just processes all available collections and
> tells
> us what the name of the collection is.
>

I can add per collection information.


>
> >
> > One case which I haven't mentioned is that of the file watcher, I'm not
> > sure how to represent that, but we do need to show a message that
> > metadata is being updated to reflect the state of the File System.
> >
>
> If we change the nepomuk service part to return this kind of info thats
> fine
> but how long will this message be shown until we say that the filewatcher
> is idle again? and do we show a message for each moved file or just "big"
> updates?
>

Just big updates - which take more than a couple of seconds. I don't think
we should be
showing "FileWatcher is idle" or even "File Indexer is idle". Just that
"Indexer is idle". The separation of the File Indexer and PIM Indexer and
WebMiner is just an implementation detail. The users don't need to be
concerned with that.


>
> >
> > PS : We could add the web-miner as "Fetching additional data about
> <fileName>"
> > and maybe we could even show some cool icon like a relevant picture. For
> > example say the banner of lost when fetching information about a lost
> episode.
>
> sounds good, just the icon stuff might be problematic, works great if
> the banner is
> available via nfo:depiction already, but otherwise this means we need
> to download
> the image and this is done even though most people might never see it.
>

Just a random thought. It's fine if it cannot be done.


>
> My main concern with all these changes:
> the deadline to get this in is the 22.05 and if I read the plasma
> freeze mail correctly
> afterwards we won't be able to change anything about this controller
> anymore for 4.12
>

Urgh. No. I do want to freeze Nepomuk stuff. That is not acceptable to be.
If they are freezing kde-workspace then this is not going over there. We
can put it in kde-runtime or release a new package.


> So either we/I speed things up, or we agree on a subset of this solution.
> The qml part is changes rather quickly I assume, the main change is in
> the dataengine
> and the nepomuk service part.
>

But I would like to get this into 4.11, so we probably should speed it up.



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130503/d34f0c5c/attachment.html>