Resource scoring and activity relation
Hi list,
for some time now the idea of scoring resources based on usage
statistics and other criteria is floating around.
1. RESOURCE SCORE
In the beginning the idea was simple: calculate one score for each
resource and remember it as nao:score. This score could have been
maintained by some scoring service and be updated whenever the user
accesses the resource or the resource changes. Ivan and myself came up
with a nice scoring function which allows to update the usage event part
of the score at query time and all seemed easy and nice.
But then activities and app separation came into the mix and the problem
got bigger. Now we want to be able to score by activity and application
also. This means we want to know which resources are of interest in this
specific activity and with this specific application.
Obviously using a single property like nao:score is not enough anymore.
The go-to approach was to create something like a ResourceScore type
which has relations to the resource being scored, the activity, the app,
and the score itself:
RS a nao:ResourceScore .
nao:xxx res .
nao:isRelated A .
nao:isRelated App .
nao:score 42^^xsd:int ;
where App is an application resource (nao:Agent) and A is an
activity (kext:Activity).
This allows to remember scores relative to app and activity. (The
downside may be that we have lots or ResourceScore instances but I see
no way around that except a complicated system of named graphs where
there is one graph per app and activity. But that seems hacky to me) If
we want a general score we simply do a sum over all:
select sum(?score) where {
?rs a nao:ResourceScore .
?rs nao:xxx res .
?rs nao:score ?score .
}
2. ACTIVITIES
In Nepomuk we will soon start to always remember the application that
maintains certain information, ie. for each information stored in
Nepomuk you will know which application created it.
My initial idea was to do the same with activities: remember in which
activity a certain piece of information was created. IMHO this is enough
and provides all the information we need.
3. PUTTING IT ALL TOGETHER
So far so good. But now for the real issue:
How do we maintain the scoring and the activity relations?
I personally would love to see that all handled transparently within
Nepomuk. No client should ever even be allowed to set or change a score.
Instead they (the clients) should simply be able to query the scores.
There are two alternatives: we could provide API to update scores or we
could allow clients to handle resource scores like any other resource
and change them however they see fit.
The latter is certainly the simplest solution but I feel that scoring
should be separated from the rest of the data as it is essentially a
cache which can always be recreated from the other information in the
database. In addition: the more Nepomuk controls itself the less buggy
clients can break stuff.
Please let me know your opinions on the matter.
Cheers,
Sebastian
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [nepomuk-kde] Crystal moved to Git
Hi Sebas, while this is very nice you are writing to the wrong list. Please use nepo...@kde.org in the future. :) Cheers, Sebastian On 03/16/2011 10:59 PM, Sebastian Kügler wrote: Hey, The Crystal Destop Search widget has moved to Git. git clone kde:plasma-crystal Also here, if you're wondering about its status: it works fine for basic usage, is fairly pretty and won't eat your data. As usual, patches welcome :) Cheers, ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Loosing Plasma config on every other update
Hi guys, running on trunk I loose my Plasma configuration on every other svn update. The only exception is the main panel which remains. All the rest is back to defaults or worse - by worse I mean that I end up with no widgets at all. So my only questions are: is this a known problem? Is this simply due to the fact that I run trunk? Can I do anything against it? Can I maybe recover the old config? Thanks a lot, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Loosing Plasma config on every other update
nope, not a single activity there. On 10/14/2010 09:38 AM, Aaron J. Seigo wrote: On Thursday, October 14, 2010, Sebastian Trüg wrote: running on trunk I loose my Plasma configuration on every other svn update. The only exception is the main panel which remains. All the rest is back to defaults or worse - by worse I mean that I end up with no widgets at all. let me guess: if you pull up the activities manager (meta-q or via the toolbox or context menu on the desktop) you see a whole ton of activities? or at least one with your widgets on them? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Loosing Plasma config on every other update
nevermind, kded was not running. On 10/14/2010 09:38 AM, Aaron J. Seigo wrote: On Thursday, October 14, 2010, Sebastian Trüg wrote: running on trunk I loose my Plasma configuration on every other svn update. The only exception is the main panel which remains. All the rest is back to defaults or worse - by worse I mean that I end up with no widgets at all. let me guess: if you pull up the activities manager (meta-q or via the toolbox or context menu on the desktop) you see a whole ton of activities? or at least one with your widgets on them? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 10:38 AM, Ivan Čukić wrote:
by this score and combine that with the restrictions you list which can
all be expressed using a single Term.
Ok
kstandardactions) and add the method and the enum to the
Nepomuk::Query::StandardQueries namespace.
Yet another Ok :)
please check the attached header and tell me if the API is acceptable. I
did not define special standard queries for fav res of type X since
that ca easily be done via:
Query q = standardQuery(MostImportantResourcesQuery);
q.setTerm( ResourceTypeTerm(type) q.term() );
Also I am not quite sure what for an application would mean in a query...
- only resources that have an event related to the app
- only resources of supported mimetype or resource type
both do not really seem useful though as IMHO there would be too many
false-negatives.
Cheers,
Sebastian
/*
This file is part of the Nepomuk KDE project.
Copyright (C) 2010 Sebastian Trueg tr...@kde.org
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) version 3, or any
later version accepted by the membership of KDE e.V. (or its
successor approved by the membership of KDE e.V.), which shall
act as a proxy defined in Section 6 of version 3 of the license.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library. If not, see http://www.gnu.org/licenses/.
*/
#ifndef _NEPOMUK_STANDARD_QUERIES_H_
#define _NEPOMUK_STANDARD_QUERIES_H_
#include nepomukquery_export.h
#include QtCore/QDate
namespace Nepomuk {
namespace Query {
class Query;
/**
* A set of predefined queries that can be created vis standardQuery().
*
* \since 4.6
*/
enum StandardQuery {
/**
* Creates a query that returns all files sorted by descending modification date.
*/
LastModifiedFilesQuery,
/**
* Creates a query that returns all resources sorted by descending score (as calculated
* by the DataMaintenanceService)
*/
MostImportantResourcesQuery,
/**
* Creates a query that returns all files with a usage count of 0
* sorted by descending modification date.
*/
NeverOpenedFilesQuery
};
/**
* Modificators to influence the behaviour of dateRangeQuery().
*
* \since 4.6
*/
enum DateRangeFlag {
/**
* Query for the modification date (nie:lastModified)
*/
ModificationDate = 0x1,
/**
* Query for the content creation date (nie:contentCreated)
*/
ContentDate = 0x2,
/**
* Query for usage events referring to the resource.
*/
UsageDate = 0x4,
/**
* Query for all possible dates.
*/
AllDates = ModificationDate|ContentDate|UsageDate
};
Q_DECLARE_FLAGS( DateRangeFlags, DateRangeFlag )
/**
* Create a standard query as defined by \p query.
* To get a query that only returns files (this is already true for some of the predefined queries)
* use something like the following:
*
* \code
* Query::FileQuery query = Query::standardQuery( Query::LastModifiedFilesQuery );
* \endcode
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query standardQuery( StandardQuery query );
/**
* Create a query that returns resources/files that have been modified/accessed in the range
* from \p start to \p end. The flags specified in \p dateFlags can be used to influence the
* type of dates that are queried.
*
* \since 4.6
*/
NEPOMUK_QUERY_EXPORT Query dateRangeQuery( const QDate start, const QDate end, DateRangeFlags dateFlags = AllDates );
}
}
Q_DECLARE_OPERATOR_FOR_FLAGS( Nepomuk::Query::DateRangeFlags )
#endif
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 08/03/2010 08:41 PM, Ivan Čukić wrote:
I know you're going to hate me, but I have to - recent documents in
the app should be restricted to the activity as well.
Would it work if the term provided would be ResTerm('activity')
ResTerm('application')
Currently this
Comparison( xxx, ResTerm(a) ResTerm(b) )
would result in a broken query.
I could add support for that in the standardQuery call though. But then
again what did we decide? Will the activity be linked to the graph or
the event? I think it was the former in which case we need two different
terms anyway which means we could use the approach of combining standard
queries like so:
standardQuery( ResourcesForActivityQuery, ResourceTerm(activity) )
standardQuery( ResourcesForApplicationQuery, ResourceTerm(app) )
standardQuery( MostImportantResourcesQuery )
IMO, the enum approach provides versatility on one level, but can be
rather restricting if we don't cover most of the use-cases at the
beginning.
how so? and which approach is better? Adding dedicated methods for all
cases has no advantage since that can be done at any point in time once
we reach the boundaries of the enum approach.
But if you don't like the enum - we can also use dedicated methods. I
just think a combination to keep the number of methods small makes sense.
And I also added a hint as to how standard queries can be combined to
I didn't see the hint here
it is in the docs for standardQuery.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/22/2010 01:25 PM, Ivan Čukić wrote: 1. Methods that return Nepomuk::Query::Query objects For the time being we could go for this one. We could always add (4.) if needed (if we or somebody else finds it useful to have) later. OK, then how one method combined with an enumeration? Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Cheers, Sebastian Eventually, we could even turn this into a data model or something like we have for files. Cheerio, Ivan p.s. You've forgotten to cross-post :) original message: agreed. One question that remains: How do we do that? We have the following possibilities: 1. Methods that return Nepomuk::Query::Query objects 2. Methods that return a Nepomuk::Query::QueryServiceClient (weird) 3. Methods that return a list of results (blocking and thus, no good) 4. Methods that return a custom class which emits the results one by one 4.1. emit results as Nepomuk::Query::Result objects 4.2. emit results as custom objects I like 1 the best - mostly because I find working with Query object so convenient. 2 and 3 are not great and 4 is the most work. The question is whether it is worth the trouble. To answer that I suppose we need some use cases. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 09:36 AM, Ivan Čukić wrote: Well, first we need to see what do we want exactly. From my point of view: - fav* resources for an application (to be shown inside the app itself) - fav resources independent on application (to be shown in activity kio) - fav applications (for launchers) - fav resources of a certain type (file, directory, web address, contact...)** * fav as in automatically sorted by access times and access count ** this one seems least important and all of the above should be activity (or something more generic) dependent. This is all very simple. The only thing we need to run is my scoring service and then it is just a matter of have the case query which sorts by this score and combine that with the restrictions you list which can all be expressed using a single Term. Maybe in a dedicated namespace or even in the Nepomuk::Query namespace as a generic access to typical queries used very often. Both are fine with me. Maybe those are too specific to be in Nepomuk::Query, but that's essentially your call. You might be right here. It might be too specific. On the other hand developers would probably search the query API for standard queries. So we could also introduce a file standardqueries.h (very much like kstandardactions) and add the method and the enum to the Nepomuk::Query::StandardQueries namespace. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities and desktop events - Results from the meeting
On 07/23/2010 10:38 AM, Ivan Čukić wrote: by this score and combine that with the restrictions you list which can all be expressed using a single Term. Ok kstandardactions) and add the method and the enum to the Nepomuk::Query::StandardQueries namespace. Yet another Ok :) BTW, how the scoring works? (as in which parameters are involved, and with what weight) Currently I use an exponential function to weight the usage events. In addition the last modification has a slightly higher weight. Then the rating and the file type are taken into account. I tuned the values randomly so they show the desired behavior for my files. This could of course use further tuning. The algorithm (rather simple) can also be found in the mentioned playground code. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Activities and desktop events - Results from the meeting
*Caution: I am cross-posting - please use reply-all*
So yesterday we had a small meeting on activities and the saving of
desktop events. Let me give a very rough overview of the topic:
- The current activity manager links a resource directly to the current
activity when the resource is reported via a DBus call which needs to
be made by the application.
- There also is a Nepomuk service which also has a DBus interface to
report opening and closing of files but it does not link to
activities but creates desktop events, saving a timestamp and the
type of the event.
- We have the NUAO (Nepomuk User Action) ontology which provides the
necessary entities to describe file open/save events. This is what
the nepomuk service uses.
- The scope of the meeting was: how to merge the two services.
Present (and actively discussing) at the meeting were (in no particular
order):
- Ivan Cucic
- Chani
- Marco Martin
- Evgeny (Phreedom) Egorochkin
- and myself
These are the decisions that were taken:
- The current activity manager's DBus interface will be extended to
include methods to start a new readonly resource access event, to
report saving of the resource, and to close the event (parameters are
always: resource URI, application/service ID, and window ID).
- The activity manager will not link resources directly to activities
but rather create NUAO event resources and relate those to the
current activity.
- We will have a nice API for app developers to use (draft of
ResourceAccess is attached.) This class can be implemented in a
synchronous or asynchronous manner without changing the API since the
calling application does not care about when the data has actually we
written.
- The NUAO ontology will be modified slightly to include the save
timestamps attached to an event.
- We will add restricted support for non-KDE apps like OpenOffice or
Acroread or whatever through KRun (and hopefully even Konsole - I
would love that) using a dedicated DBus method which creates events
of lower priority in the service (meaning they are overwritten by a
call from the application itself). A good place to start is all
places where KRecentFiles is updated.
Hoping that I did not forget anything important I now open the floor to
the who does what discussion. :)
In playground[1] you can find the code for my Nepomuk service which also
contains the code for creating the NUAO events. In there is a rather
hacky attampt to merge events from places like KRun and the apps
themselves. IMHO there is room for improvement there.
Cheers,
Sebastian
[1]
http://websvn.kde.org/trunk/playground/base/nepomuk-kde/datamaintenanceservice/datamaintenanceservice.cpp?view=markup
/**
* The ResourceAccess represents an open or modification event
* during its lifetime. A new event is created when the object
* is instanciated and ends when the object is deleted via close().
*
* Typical usage is to create a ResourceAccess for each opened document,
* call saveModification() whenever the user saves the document and call
* close() as soon as the user closes the document.
*
* This will automatically save the statistical data in Nepomuk and update
* the relation to the current activity to be consumed by several parts of
* the KDE desktop.
*/
class ResourceAccess
{
public:
/**
* Save a modification timestamp. Call this whenever the user saves the document.
* This will convert the event into a modification event and add the timestamp.
*/
void saveModification();
/**
* Close the event, store the end timestamp and delete the ResourceAccess
* instance.
*/
void close();
/**
* Create a new ResourceAccess event for the resource at \p url which is
* opened in \p widget.
*/
static ResourceAccess* createAccess( const KUrl url, QWidget* widget );
/**
* Create a new ResourceAccess event for the resource \p res which is
* opened in \p widget.
*/
static ResourceAccess* createAccess( const Nepomuk::Resource res, QWidget* widget );
private:
/**
* Destructor
*/
~ResourceAccess();
class Private;
Private* const d;
};
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities IRC meeting
Any chance we can have this meeting in a jabber conference at nepo...@conference.xabber.de? My internet connection is acting up again. Cheers, Sebastian On 07/16/2010 02:46 PM, Ivan Čukić wrote: Sebastian and me are planning to hold a meeting about activities on Tuesday, 5PM UTC. It is going to be about the inner-workings rather than the UI. So, anyone willing to join is more than welcome. --- Testing out the event inserting: Activities IRC meeting /When/ Tue, 20 July, 7pm – 8pm GMT+02:00 /Who/ • Ivan Čukić • nepo...@kde.org mailto:nepo...@kde.org • plasma-devel@kde.org mailto:plasma-devel@kde.org Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
Exactly. My approach was rather similar to Ivan's I think: I have a dbus service that handles all the events. Apps simply call a set of methods I'm not very fond of having apps call dbus directly. By creating the KActivity* classes, we can keep the dbus interface as minimal as possible, while the classes could handle some logic and provide convenience methods. (and we don't need to keep the dbus api back-compatible) The advantage of a DBus API is simple: we could make it a freedesktop standard and share interfaces with systems like Zeitgeit. maybe we could drop that for 4.6 since optional nepomuk makes everything so much more complicated. I agree. We'll just need to communicate this to KWin guys - they didn't really want to depend on nepomuk. Although, (from my pov) the kded daemon could access nepomuk directly instead of doing it via the service... (it doesn't really matter whether it is a kded module or a nepomuk service...) that is what I think, too. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/15/2010 10:50 AM, Ivan Čukić wrote: The advantage of a DBus API is simple: we could make it a freedesktop standard and share interfaces with systems like Zeitgeit. Yes, that is my idea as well, but still, accessing the dbus api via a higher-layer class makes it easier to change the dbus api as needed (until it becomes fdo standard, and maybe even later) without changing every program that uses it. An example can be the recent addition of application /name/ to the parameters list when opening a document. *1* KActivity* (client) API remained the same while the d-bus interface was changed. The classes are like small wrappers which allow the dbus api to be minimal and change if needed while providing a nice experience for the developer (sine aKademy, I'm practicing my marketing-speak :) ) Cheerio *1* The d-bus api can't be expected to be stable at this point in development, and we need to start patching apps to support activities now Of course there should be a wrapper class in kdelibs. But IMHO it should not be in the activity set of classes since it has nothing to do with activities. The currently opened and saved documents are of interest even without activities, right? Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
Hi Ivan, On 07/13/2010 03:13 PM, Ivan Čukić wrote: 1. The ActivityManager (KDED module) now accepts application name/id when the application notifies it that it has opened a document (or any other type of resource that has an url) If the name is not specified, KWindowInfo is used to try and get it. So applications need to notify it about opening a doc manually? I am asking because I started implementing the exact same thing and we should really not duplicate code. The idea on my end is to create nuao:DesktopEvent instances which link to the opened file and the application opening it. For the latter the ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. KActivityConsumer uses QCoreApplication::applicationName() for this, so it is done 'behind a curtain'. 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? From my point of view, it is something that should be done. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/14/2010 11:53 AM, Ivan Čukić wrote: First of all, I hope you are on plasma-devel since a lot of people didn't take me seriously concerning the cross-posting... did not find the thread in stupid thunderbird (if only kmail would work again here) So applications need to notify it about opening a doc manually? I am asking because I started implementing the exact same thing and we should Yes, the apps report the name, window id and the uri of the resource opened (be it a document, folder or some internal uri) really not duplicate code. This is in the ActivityManager kded module. I will have a look. The idea on my end is to create nuao:DesktopEvent instances which link to the opened file and the application opening it. For the latter the ontology is not stable yet. This is something we should fix as soon as possible so that we can encode applications properly. I wasn't going for anything this pedantic (was trying to limit the data and not remember every event) but it is fine with me to go that extra mile. It is worth it since then we have a lot more information to do cool things with. This is how I think it should be done: rather than linking the file directly to the activity you should link the desktop event to the activity. That way the information is exact and can later be used to suggest the link between file and activity to the user. The problem I see here is /suggesting/. The user usually opens a lot of documents, and I wouldn't really like to have to ask him/her do you want to add this to the activity for every one. That is, if you have an idea about the UI that would make this job non-irritating, I'm more than happy to hear it. From my POV, I'd rather have a system that has 90% precision which doesn't ask the user anything than to have it 100% and annoys the user constantly. (something like the best package manager - Slackware's - aka the user :) ) The suggestion thing was just an idea. You can also use the links to show related documents for the activity. However, as the documents would not be linked directly but via the event the link would automatically be marked as being added automatically and thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
On 07/13/2010 04:04 PM, Marco Martin wrote: On Tue, Jul 13, 2010 at 3:55 PM, Ivan Čukić ivan.cu...@kde.org wrote: On 13 July 2010 15:45, Marco Martin notm...@gmail.com wrote: it must be done indeed. but is it possible to automatically unlink it as well when the window is detached from the activity? Yes, but that would be undesired - if you open a file from an activity, it belongs to it. (and possibly other activities as well) The window containing the document, on the other side, gets unassociated when it doesn't hold the doc in question anymore. ok, but there should really be a mechanism to change the activities associated with an already opened document somehow. coupling it with the activities associated with the window that holds the document could be a good way As mentioned already on nepo...@kde.org, I think the activity relation needs to go into the event itself, not the file. That way we have an indirect relation between file and activity without forcing anything on the user. We can later use that relation in whatever way we want while keeping the file itself clean of any automatically added data. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Activities protocol
On 07/13/2010 09:57 PM, Aaron J. Seigo wrote: On July 13, 2010, Ivan Čukić wrote: a.s. This is a cross-post Hi, A few notifications and questions. 1. The ActivityManager (KDED module) now accepts application name/id when the application notifies it that it has opened a document (or any other type of resource that has an url) If the name is not specified, KWindowInfo is used to try and get it. The reason for this is to make it possible to keep track of recently opened resources (and all the stats/rating stuff Lukas is working on) on a per-application basis. sounds good. 2. Does anyone have objections in automatically linking a resource (that the application reports is opened) with the current activity? this will lead to lots of false positives. a file i open from an email that gets sent to me stands a high likeliehood of having nothing to do with the activity i'm in. other examples abound. if automatic linking is implemented, then i think we'll end up needing a simple ranking system with documents that were automatically (passively?) linked by the system just due to being open with a low ranking, information that is accessed as a result of another item associated with an activity (e.g. if i have an app or window associated with an activity, then things opened with that app / window stand a high chance of being relevant) having a higher ranking and items actively marked as having the highest. once more just so this is not forgotten: there is no need for ranking - at least not on the data level - when linking the activity to the event rather than to the file. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/14/2010 02:32 PM, Ivan Čukić wrote: Sebastian: once more just so this is not forgotten: there is no need for ranking - at least not on the data level - when linking the activity to the event rather than to the file. Agreed. The only problem I see is that we'll need much more complex queries when sorting the results by usage. do the queries really have to be that more complicated. In the end it is one additional edge in the graph. Instead of checking for something like ?r relatedTo activity you do something like ?event nuao:involves ?r . ?r relatedTo activity (just a rough example) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
Just for completeness: I already have a scoring algorithm that takes the desktop events and a bunch of other criteria into account to score all files and thus, guess which files are most important to the user. Cheers, Sebastian On 07/14/2010 07:34 PM, Aaron J. Seigo wrote: On July 14, 2010, Sebastian Trüg wrote: The idea on my end is to create nuao:DesktopEvent instances which link to the opened file and the application opening it. For the latter the that sounds very sensible, and would get rid of the false positives due to automatically associating files issue. files the user tags explicitly would be easily discernable from those that have a DesktopEvent. assuming that DesktopEvent allows for things such as counting the number of times that same event happens, it should even be possible to decrease the importance of files accessed just once or a long tme ago. +1 from me to our ontology overlords. ___ Nepomuk mailing list nepo...@kde.org https://mail.kde.org/mailman/listinfo/nepomuk ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/14/2010 07:03 PM, Ivan Čukić wrote: ?event nuao:involves ?r . ?r relatedTo activity (just a rough example) The sorting is the complicated one - it should be done according to some formula like this: sort rating = number-of-times-used / log (days-from-last-usage) already done in playground. :) This is targetted for 4.6 though. (this formula was for when had only those two fields remembered, if we remember all events we'll be able to do something even more evil :) ) and I do. :P p.s. The kded module should stay clean from nepomuk, for the time being, and just delegate the things to nepomukactivitiesservice maybe we could drop that for 4.6 since optional nepomuk makes everything so much more complicated. p.p.s. If you hadn't done anything related to Nepomuk Queries and ||, , ! (and what else we had), I can start making a patch for it. Already in trunk. :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [Nepomuk] Activities protocol
On 07/14/2010 06:09 PM, Chani wrote: The suggestion thing was just an idea. You can also use the links to show related documents for the activity. However, as the documents would not be linked directly but via the event the link would automatically be marked as being added automatically and thus, less important than a manually added one. When I say suggestion I do not necessarily mean to suggest the link between file and activity but any kind of suggestion. This includes suggesting the file when showing related stuff for an activity. what's all this event stuff? are you doing.. something like zeitgeist or something? indeed. Only integrated with Nepomuk and the semantic desktop. Allows for some cool things. this is still something the application will have to support, I assume, so we probably want just one simple way for it to report the docuements it has open. Exactly. My approach was rather similar to Ivan's I think: I have a dbus service that handles all the events. Apps simply call a set of methods on that interface. In case of non-KDE apps this can be done by KRun or even Konsole. I think here is where Ivan and I should merge our work. in kwin, what I need is which activities are associated with this wid?, so that I can filter out windows that aren't on the current activity. there can be no levels here, no suggestion; either a window is shown or it is not. I mean, I have absolutely nothing against you guys using levels yourselves, it's just that kwin needs a simple yes/no when it asks. :) it is up to you (or the service you ask) where you draw the line - whether automatically annotated files are included or not. Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
State of Plasma API documentation
Hi Plasma devels, I recently found myself in the situation where I wanted to implement a simple popup menu in a Plasma applet. I had to use C++ since the menu is dynamic and an existing C++ class. The problem was that I had no idea what to do other than using something like QToolButton which looks ugly and does not even work properly (menu pops up in the wrong place). I had a look in the Plasma API docs which contains gazillion of classes, many of which have close to no documentation. I ended up trying IconWidget which seemed the right choice (the #plasma irc channel did not get my any further) but that class does not work very nice either. It does not scale with the panel and seems pretty unmaintained alltogether. On top of that the docu contains a lot of private classes. IMHO that is no good situation for a toolkit as important as Plasma. Thus, I would ask that someone takes the time to at least add the proper Doxygen hints to the Mainpage.dox to exclude the private classes. And maybe the maintainers of the Plasma classes could add a brief description to each class so one can understand their purpose. Thanks a lot and keep up the good work. :) (says he after four paragraphs of bitching ;) Cheers, Sebastian ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[PATCH] ftp support in locations runner
The attached patch adds ftp support to the locations runner. I find it very
annoying that I cannot run ftp connections my simply typing ftp.kde.org like
I could in KDE 3.
Ok to commit to 4.2 and trunk?
Cheers,
Sebastian
Index: locationrunner.cpp
===
--- locationrunner.cpp (revision 927493)
+++ locationrunner.cpp (working copy)
@@ -57,7 +57,10 @@
if (idx != -1) {
url.setPath(term.mid(idx));
}
-url.setProtocol(http);
+if (term.startsWith(ftp))
+url.setProtocol(ftp);
+else
+url.setProtocol(http);
}
}
@@ -108,7 +111,7 @@
match.setData(url.url());
if (KProtocolInfo::isHelperProtocol(url.protocol())) {
-//kDebug() helper protocol url.protocol() call external application ;
+//kDebug() helper protocol url.protocol() call external application ;
match.setText(i18n(Launch with %1, KProtocolInfo::exec(url.protocol(;
} else {
//kDebug() protocol managed by browser url.protocol();
@@ -145,7 +148,7 @@
KUrl urlToRun(location);
if ((type == Plasma::RunnerContext::NetworkLocation || type == Plasma::RunnerContext::UnknownType)
-data.startsWith(http://;)) {
+(data.startsWith(http://;) || data.startsWith(ftp://;))) {
// the text may have changed while we were running, so we have to refresh
// our content
processUrl(urlToRun, location);
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Replacing Xesam runner with Nepomuk runner
On Monday 27 October 2008 23:52:32 Aaron J. Seigo wrote: On Monday 27 October 2008, Sebastian Trüg wrote: Kevin (who wrote the Xesam runner) agrees with me on this. Now the only trouble is that I forgot to add the runner to the 4.2 feature list. I hope it's a bug fix: it doesn't work now, but it will. put it in. more good work from the nepomukers =) thanks. :) commited now. -- Sebastian Trueg Sponsored by Mandriva to work on Nepomuk-KDE. http://nepomuk.kde.org ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
