Hi,
Note though, that the plasma folks have their own thing in their head
regarding this topic, so maybe I am missing someone important who
Heh, I am one of the Plasma folks. :)
The reason I started this topic now is that we are approaching Tokamak 3
(meeting of Plasma developers / hackaton)
Btw, a bit offtopic, but shall we share favourites between those menus?
you're not sharing them? :(
There are both pros and cons for this. Pros are easy to recognize.
The main con (and the reason why Lancelot only loads the favs from Kickoff on
first start, but doesn't share them) is that
what would you do with an activity type that you couldn't do with just the
activity name?
The type could be used by the /activity switching/ plasmoid - to group the
activites, or to show only a certain type of activity...
(this is the only thing that comes to my mind at the moment :) )
be in it anyways, the contextChanged signal would have the new context,
that would contain not only the activity name but also the type..
I'd rather have a typeForActivity(String activityName) than having the
parameter type as a part of the signal. (since type is defined by the activity
The activity type can have the following options (these need be set
only while defining a new activity type, not while creating every
activity!)
- Activity Type Name (user given string)
- Show apps (in menu) related to productivity, etc
- Allow / Disallow / Provide hint about messages from
+1 for not before 10 :)
2009/9/1 Aaron J. Seigo ase...@kde.org:
On September 1, 2009, Martin Gräßlin wrote:
So we just need a time. I think we should do it somewhen in the morning or
early afternoon (UTC time) so that Lucas can join us. So perhaps on
Thursday morning.
works for me. before
A few errors:
Rob's surname (beginning of the text)
Community and Team-building efforts passage is not finished - it ends in
during the sprint, and a number of
While Kickoff is in theory a competitor, or rather a replacement for Kickoff,
Cukic showed great team... - strange isn't it - like
Here is the list of current runners (that I have installed)
http://pastebin.ca/1560026
Which ones should be enabled in kickoff? (that is, which ones don't crash :) )
Cheerio!
___
Plasma-devel mailing list
Plasma-devel@kde.org
On Thursday 10 September 2009 21:13:38 Aaron J. Seigo wrote:
On September 9, 2009, Ivan Čukić wrote:
Here is the list of current runners (that I have installed)
http://pastebin.ca/1560026
Which ones should be enabled in kickoff?
i think just the locations, shell, services
1. Keyboard navigation of the search results appears to have broken,
can you please have a look at that.
The only thing changed is the data model. Do you have any idea how that could
screw up the keybd nav?
2. The search results for applications now take longer to appear than
they used to
so setAllowedPlugins probably needs to store its list in a separate key and
compare against it first. will commit a patch shortly.
OK, I'll cancel the review request
___
Plasma-devel mailing list
Plasma-devel@kde.org
p.s. the tracker is http://drako.homelinux.org/announce (i hope it works)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
On Saturday 12 September 2009 11:03:27 Shantanu Tushar Jha wrote:
And someone upload the pictures on flickr for unfortunate people like me
whose admins have blocked torrents.
I'll upload some of them - they are 100MB in total - a bit too much to send
via http :)
cheers
I've posted some photos:
http://www.flickr.com/photos/ivan-cukic/sets/72157622346934426/
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Hi all,
Here is the preview of the nepomuk activities for plasma started at T3.
This is not in any sense a final version, that is, it will need a lot more
testing (with nepomuk both enabled and disabled). Currently, I'm hunting a few
bugs left related to activity storing.
The good thing is
any chance you could put it up on reviewboard? :)
Ok, although it is not yet meant for merging.
http://reviewboard.kde.org/r/1699/
http://reviewboard.kde.org/r/1700/
Cheerio
___
Plasma-devel mailing list
Plasma-devel@kde.org
Hi,
what happens when you just restart plasma (kquitapp plasma-desktop; sleep 2;
plasma-desktop) - does it load the data then?
How do you access nepomuk? Via its classes or via d-bus?
session, when KDE starts, it seems, plasma is started before Nepomuk
You can check whether this is the case
On Tuesday 13 October 2009 19:17:26 Aaron J. Seigo wrote:
On October 13, 2009, Ivan Čukić wrote:
Since there are bound to be some changes in the concepts behind
activities, virtual desktops etc. I'll postpone the plasma+nepomuk
integration in order to introduce it alongside the new overview
I'd still like to see a minimal implementation of this to already get used
to having this kind of stuff. So please, don't postpone. Plasma is not the
only potential user of this ...
Heh, Sebas, you haven't read the rest of the mails :)
I was talking about the plasma-ui integration (the
Hi all,
After some time I spent on the ice due to problems with compiling Qt 4.6,
I've finally been able to polish the activities service.
It is now in kdereview/nepomuk-activities-service
We can not really start doing anything else concerning the activities until
this gets accepted. A few
As I understand the code, current activity is globally modal?
Yes. Although plasma will be the main manager of activities, other
applications can be as well.
I'm currently preparing a bit of nepomukification of the storage (as per
Sebastian's instructions) - will be committed very soon.
That's interesting, but I am interested in the UI implications of having a
single modal current activity. That implies that exactly one activity is
visible at one time - including in such exotic setups as second monitors. ee
How does your model handle that?
Well, this was discussed before
Updated version in kdereview - it uses nepomuk in a much better way.
Since the ontology is not yet written, it uses a dummy link
http://www.kde.org/ontologies/activities#Activity
which can later be changed or made to redirect to a real rdf.
If anyone (Sebastian) has a better idea for the url,
Here is a idea for a way to remove widgets and more than one of the same
kind http://imagebin.ca/view/UaQTcxW.html
The idea for listing and removing/killing running widgets was to have it in
Ctrl+Escape dialogue - just like when killing/listing normal processes.
Cheerio.
--
You know,
who raises hand? :)
Would really need a couple more of yes, i'm interested :p
I love gadgets, so when not working on plasma+nepomuk, I could join the mobile
group as well :)
Cheerio
--
A positive attitude may not solve all your problems, but it will annoy enough
people to make it worth
Hi,
Are there any requirements for libs in kdeplasma-addons/libs?
API, ABI compatibility?
I'm asking because I'm thinking of moving liblancelot and liblancelot-
datamodels there so that other projects could use them.
(including plasma dataengines based on models in L)
Cheerio,
Ivan
that they are maintained ;)
lol :)
Ok, so expect two /new/ libs there soon :)
Cheerio!
--
Before you talk to me, I should warn you: I am kind of strange
___
Plasma-devel mailing list
Plasma-devel@kde.org
last thing i was thinking about was something that resembles rssnow:
http://imagebin.ca/view/fiFONCc.html
It /looks/ like a nice idea but whether it really is is hard to tell.
The problem I see with it is that it complicates the interaction even more
than it is now.
We really need Seele for
On Tuesday, 26. January 2010. 11.57.36 Riccardo Iaconelli wrote:
On Monday 25 January 2010 13:20:56 Marco Martin wrote:
opinions? comments?
would like to hear some feedback before implementing anything since each
solution would lead to a different total screwing of the current
in general, i agree with the approach you describe, but i think it needs to
be a bit more involved behind the scenes to ensure a spammy app doesn't
take over and that the notifications and jobs are sensible.
which is what my looong email reply describes :)
Cool, so we take a operating
if you do have a topic you'd like to do a full presentation on, please do
add it to the wiki and we will work out a schedule for them.
Chani and I will cover the activities. We'll meet on IRC soon to discuss how
to divide the topic.
Cheerio
--
Money can't buy happiness, but neither can
On Wednesday, 3. February 2010. 23.22.20 Lukas Appelhans wrote:
Hey!
Just to give an update from my side... I will arrive at 18:24 on Friday and
will depart at 17:33 on sunday... anyone got the same times (and maybe the
same train, it's some ICE)?
You should fill that info to T4 page on
We seem to have two or three definitions of the word activity in kdebase
now. Oops.
First, there's the original: desktop containments.
Second, there's the nepomuk activities: they're UIDs that can have an
associated name, and then other arbitrary things can be associated with
them. Third,
On Friday, 5. February 2010. 21.02.37 Aaron J. Seigo wrote:
On February 5, 2010, Lukas Appelhans wrote:
I think we should have a working group (only for a few hours maybe) about
how we manage application menus... (especially interesting for Ivan,
ruphy, Nuno et moi)
sounds good; let's
We may want to integrate it with Nepomuk, get some thoughts about sharing
as most code as possible and get some enlightenment on the concept of
TOM...
This could probably be merged with the mobile one for like even just a
couple of hours.
I'm not for merging - then we'd have to merge
On Thursday 18 February 2010 Marco Martin wrote:
On Thursday 18 February 2010, Sebastian Kügler wrote:
if you would like to give a presentation, add it to the list as well.
I wonder if I should give one on Silk. Not sure in how far it's actually
+1 :)
Cheerio,
Ivan
--
Before you
Ok gang, check out the
https://svn.kde.org/home/kde/trunk/playground/base/nepomuk-kde/libactivities
The code is currently organized into following:
- services/kded
The KDED service independent from Nepomuk (that is, it works even if Nepomuk
is not enabled, otherwise it passes the necessary info
so i finally uploaded tokamak 4 pics :) sorry, I'm late as always ;-)
That reminds me, I should post these few of mine as well :)
I created (and am now seeding) a torrent with small versions of the pics i
took in nuremberg (already filtering out most crap). photos are small
resolution
so... I dunno... should we build the API so that it's possible to have 1
visible activity? or should we decide that the activity is completely
global, and then figure out how to gracefully handle changes in the number
of monitors?
I'd prefer the latter, but I just don't have experience
On Wednesday 10 March 2010 Aaron J. Seigo wrote:
On March 8, 2010, Ivan Čukić wrote:
- libs/consumer
ActivityConsumer - basic access to kded service for normal apps
ActivityInfo - access to extra info provided by nepomuk - this one will
probably get expanded in future.
- libs
hmm. am i reading this correctly that this kded service is only needed if
nepomuk is not there, and that it serves as a cache-in-the-middle between
nepomuk and the applications? this seems like a lot of overhead just to
this was one of the kwin people wishes. Even with nepomuk, a cache-in-the
sorry, i wasn't clear enough. i meant where in kdelibs :)
:) I have no idea :)
i'd recommend workspace/libs/kworkspace/. runtime isn't for libs :)
Ok :)
runtime isn't for libs; and i think it does make sense next to Consumer.
perhaps they could both go into kdelibs/nepomuk? would have to
there's also a penalty for keeping the cache in sync across multiple
clients.
the other concern is memory usage due to having that cache around ...
The cache is in the kded service - so no need to sync anything. Or I
misunderstood you? So the memory overhead is not big at all.
i'd really
kdeui and even kio do not currently depend on nepomuk. a puzzler :) we
should ask Sebastian Trueg for some guidance here i think.
Well, these classes don't depend on nepomuk directly, that is, no nepomuk
linking required. The Controller class is completely usable without it.
That's why I
ah, and it's transfered over dbus to the client app on each call?
Only on request - if the client wants list of activities, it is sent to it.
The same goes for (soon to be) activitiesForResource. It is not like those
methods should be called that often.
The alternative (discussed with kwin
On Thursday 11 March 2010 Marco Martin wrote:
even go so far as to suggest that there should be a LocationResource in
the ResourceType enumeration.
Just a note about types - the enum values are for the built-in support of
resource types and are provided for *convenience*, if an application
registerDocumentWindow? :)
Since we are renaming Document to Resource in the API, any pretty names for
this one with the resource in it?
(I'm not that thrilled about registerResourceWindow, although it will have to
do if we don't find something better...)
Cheerio,
Ivan
--
Money can't
Updates:
- all manager signals converted into listener objects
- consumer signals left as is (they are not invoked that often, and are
something most applications should respond to eventually)
- changed d-bus API to fit the style of other KDE services
- added test shell script for nepomuk
can we get together on irc soon and do a once-over of this and then get it
moved into kdereview?
Ok, I'll try to be online tomorrow. If not, then the weekend?
if we work around subsystems because they don't work well yet then the
odds they ever will work well goes down as there is less
the important motivator for nepomuk is applications using it. aka
relevance.
I agree on this one, I just wanted to point out that our usage of Nepomuk is
not that advanced, thrilling or anything to be a driving force for devels. As
for relevance, your statement stands ;)
how can i say no
On Wednesday 07 April 2010 Chani wrote:
On March 31, 2010 11:37:51 Aaron J. Seigo wrote:
On March 31, 2010, Ivan Čukić wrote:
can we get together on irc soon and do a once-over of this and then
get it moved into kdereview?
Ok, I'll try to be online tomorrow
You might want more control over the applets than the newspaper
containment---again, I'm not sure, but in my experience, apps with
different use-cases, form factors, and intended plasma widgets will want
While I agree that no containment can suit all applications, if we choose the
way of
in one of those better late than never, right? things: i'd like to see us
pre-pend org.kde. to all of the X-KDE-PluginInfo-Name= entries in our
.desktop files for new plugins we ship, to avoid potential name collisions
outside our little universe.
Does that mean we could even change the names
There appears to be a bug, or at least a change in behavior for panel icon
sizing in KDE 4.4 (specifically Debian 4.4.3-2). In previous versions of
KDE (e.g., 4.3), panel icons would resize with the panel up to at least
48x48. However, as of KDE 4.4 panel icons appear to be restricted to
wait a sec... it's not greyed out for me. I can change the icon size.
however, X randomly crashed before I could test whether plasma follows it.
now I'm pissed off at my computer, so I'm gonna go do something else.
Strange, for the panel icon, it was disabled (for me) since I can remember :)
This will be needed in Plasma::PopupApplet as well. I'll can do
it when this gets accepted.
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
___
Seems to do the trick on my end. Your thoughts?
popupapplet:866
When on desktop, popup applet is not an icon, so it should return
Plasma::Applet::sizeHint(...)
Other things seem ok
Cheerio,
Ivan
--
The bleeding hearts and artists,
Make their stand.
-- Pink Floyd
Hi Lukas,
Or scrape that library and make it a private implementation in krunner
It is too late for 4.5. Which is good from my POV since it will be able to
integrate with activities in 4.6*.
BTW, where is the code located?
Cheerio,
Ivan
* Maybe even get it integrated into the activities
Well we need if we want to have the applications ranked/get a useful
score...
AppStats::score() does some final calculations based on the last launched
date...
Oh, I forgot that.
I could make it like: StatsLib::launched(Nepomuk::Resource)... and then
And this :) so, we need API
One more issue: the simple Application Launcher Menu (which I prefer to
kickoff) needs to be fixed too. Attached is a patch based on the Icon
applet changes that fixes the MenuLauncher applet too.
Sorry, my bad, forgot to commit the changes... it should be ok now.
Cheerio,
Ivan
--
While
80 euro per hour. That's a tad low (esp with the low euro now) so let
me know if that would be completely unacceptable.
it completely depends on where in the world the person lives. i'd suggest
drafting the timeline and then finding out, based on that, what can be
From my point of view
On Monday, 7. June 2010. Lukas Appelhans wrote:
Ok to give you guys an update on this...
I will try to move from our own ontology to a more generic one which is
already in shareddesktopontologies, for that I've mailed Evgeny so we can
discuss how to continue here...
The stats need to be
For me, it'd be perfect if this doesn't happen before Monday.
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
Hi all,
At aKademy, Nuno proposed a bit different design for identicons used
for plasma activities.
1. The identicons should be showed inside a bubble with background and
an overlay.
2. He will make some default icons for users that want to choose
specific ones instead of the automatically
now, what if $plasmoid wants to use the icon (eg, activity bar)? what if
$application wants to use the icon (eg. when associating something with an
activity)? it'd be nice if I could see the icons when assigning windows to
activities, but I dunno if that'd be possible with autogenerated
0. Not going to discuss about the reasoning behind identicons again.
1. Activities are no more only /desktop-setups-group-of-widgets/ so
making thumbnails can be counter-productive - you can keep the desktop
empty in all activities and still want to use other activity-related
features. Or if you
me realy does not care much as long as we have something that looks pretty and
is easy to recognize by the user, i proposed to do those icons because wen I
saw how our Chani chose random icons to represent them, i had my typical your
icons look soo ugly used like that feeling... so I proposed
-in the activity configuration, there would be something that looks like a
combobox to chose icons, that shows just the set of 20 good ones or an
other... option
Yeah, we'll need to discuss this one a bit more - whether it is good
(usability-wise) to make a separate UI for icon choosing. Maybe
WORKSFORME as well
On 11 July 2010 16:21, Ryan Rix r...@n.rix.si wrote:
On Sun 11 July 2010 7:32:14 am Chani wrote:
On Saturday, July 10, 2010 03:41:47 am Marco Martin wrote:
On Saturday 10 July 2010, Aaron J. Seigo wrote:
On July 9, 2010, Marco Martin wrote:
oh, fsck, scrap that: i
separate UI? wuh?
1 - menu of icons and a 'more...' option
2 - standard icon chooser when 'more...' is clicked
I'm starting to wonder if maybe it's not so bad to leave it to the user. After
all, we don't try to auto-name the activity for them, new activities currently
start at unnamed...
One
Yeah, I could do that, but while I'm not afraid of reading blogs, typical
users won't do that. It'd be really great if by SC 4.6 it was easily
I completely agree. For 4.5 it was not the case since we only
scratched the surface.
discoverable for common users (and advanced users alike) what
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
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
Hi Sebastian,
First of all, I hope you are on plasma-devel since a lot of people
didn't take me seriously concerning the cross-posting...
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
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.
i think windows outside of the current activity should be hidden from the
taskbar, at least by default.
and this must be done in 4.5, otherwise will cause another ser revolt.
I agree. The current plan is to have it in 4.5.1 - Chani thinks it
would be risky to do it for .0 - not enough testing.
I'm not against doing it in 4.5, if someone can do it without introducing bugs
I'm willing, but I'll need a hint - how to expose the things you did
to libtaskmanager?
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the
?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)
(this formula was for when had only those two fields remembered,
On July 14, 2010, Luca Beltrame wrote:
From what I'm reading on the forums these days, it may happen, as there is
already a lot of discussion on activities (sometimes heated).
this is not a good reason to make these kinds of decisions. being directed by
the popular topic of the day amongst a
which is a bit of a design flaw imho. being able to know what URI(s) a window
It is not a design flaw, it is about the design not being used at the moment :)
Naturally, once the apps start using our new protocol, we'll have the
wid-uri association.
(this is the most awesome side effect of
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.
Ok then, no complaints from me :)
Cheerio
only thing that concernes me a bit is that this kind of association in kwin,
and in the kded seems a bit uhm separate
This is only temporary
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
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. :)
Fantastic :)
Exactly. My approach was rather similar to Ivan's I think: I have a dbus
service that handles all the events. Apps simply
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
nothing to do with activities. The currently opened and saved documents
are of interest even without activities, right?
+1
--
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
I'm not gonna be here before 7 (5pm utc)
On 15 July 2010 10:23, Marco Martin notm...@gmail.com wrote:
On Thursday 15 July 2010, Chani wrote:
On July 14, 2010 21:15:23 Ryan Rix wrote:
On Wed 14 July 2010 8:41:57 am Marco Martin wrote:
just a reminder for everybody
meeting at 9:00 am UTC
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20100720T17Z
DTEND:20100720T18Z
DTSTAMP:20100716T124616Z
ORGANIZER:mailto:ivan.cu...@gmail.com
UID:41s1c5vr71v3f44tsd1lvkn...@google.com
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20100720T17Z
DTEND:20100720T18Z
DTSTAMP:20100716T124615Z
ORGANIZER:mailto:ivan.cu...@gmail.com
UID:41s1c5vr71v3f44tsd1lvkn...@google.com
Probably #nepomuk - less traffic there, so we will not get distracted (I hope)
2010/7/17 Chani chan...@gmail.com:
Activities IRC meeting
*When*
Tue, 20 July, 7pm – 8pm GMT+02:00
*Who*
erm... there's no where mentioned. :)
#plasma? #nepomuk?
--
While you were hanging yourself on
A small update:
- KIdenticonGenerator can now create QIcons as well as QPixmaps
- More states - all QIcon::Modes supported
- Test applet
- Rather pretty :) (maybe kdegames would like pretty marbles like this :) )
- in plasma's playground under libs (Chani will kill me for this)
Todo:
-
maye there could still be a little bit of shading more.
like a ight gradient in the bottom part of the marble too and have a 1 pixel
light border inside the dark border?
The theme can be easily changed. I'll probably leave it up to Nuno :)
Cheerio
--
While you were hanging yourself on
This is just an idea that came to me looking at some mobile GUIs (or was it
websites?), but I think that could really work in order to have the common
user find out our best features.
What do you think?
problems with those things is that users tend to find this kind of things
abboying
speaking of which... *coughs* we still don't have a Welcome Plasmoid, do we?
Yep :) Well, this would be nice to have in the welcome plasmoid, but
it would be a *huge* thing to implement.
--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was
BTW, to add to this question, why is the applet background drawn now
for the items in applet/activity browser!?
On 19 July 2010 19:54, Chani chan...@gmail.com wrote:
someone adjusted the list thingy that the add-widgets and activity-manager UIs
use so that it's prettier and shows the names on
at that point icons seemed completely detached to the text, so something to
join them was needed. the applet background seemed a good choice since
those icons represent indeed, applets.
From my POV, it would be better to introduce a new svg than to use the
applet background. It is like if we
fine with me, if I succeed in connecting to it :)
2010/7/20 Sebastian Trüg tr...@kde.org:
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
I'm updating the d-bus service and merging the currently separated
nepomuk service into it. (and the playground thingie)
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
I think we forgot one thing to discuss - API for data retrieval.
We have the API for apps to tell us what they are doing, but we don't
have the API for the apps to get, for example, a list of
recent/popular/high-rated docs
Cheerio
--
While you were hanging yourself on someone else's words
For me that always was nepomuk queries but maybe it would be nice to
have convenience methods for some special cases.
The problem with this approach is that people would need to know how
we save the data so that they could write queries. Most of the time,
for simple things, this would be too
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.
Eventually, we could even turn this into a data model or something
like we have for files.
Cheerio,
Ivan
1 - 100 of 1101 matches
Mail list logo
