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
I've only had a quick glance at the code so far... but... I'd completely
forgotten something that might be a problem: multiple screens.
if we continue having the activity correspond to exactly one containment, then
you've always got two different activities on your two different monitors. that
On Tue, Mar 9, 2010 at 6:17 PM, Chani wrote:
> but if we make the activity span all monitors, we run into other issues - what
> happens when the number of monitors is reduced? where do all the extra
> containments go? how does the user look at them again, or delete them?
There are also issues whe
On March 9, 2010, todd rme wrote:
> you add a new screen, a new containment is added to all existing
> activities (I'll use "containment" as shorthand for the whole-screen
> containments like desktop and netbook, as opposed to the panel
> containment or container widget).
that would be very heavy
On March 9, 2010, Chani wrote:
> 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?
there are two different topics here:
* coordinating Context<->Containment
* coordinating when a Cont
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/controller
> ActivityController class - access to kded ser
On March 9, 2010 18:49:54 Aaron J. Seigo wrote:
> On March 9, 2010, Chani wrote:
> > 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?
>
> there are two different topics here:
>
> *
On March 8, 2010, Ivan Čukić wrote:
> - services/kded
> The KDED service independent from Nepomuk (that is, it works even if
> Nepomuk is not enabled, otherwise it passes the necessary info to it)
i wonder if the kconfig backed version is really needed. we lose so much
additional information with
On March 9, 2010, Chani wrote:
> well yeah, but then when the screen is disconnected you can't get at the
> containment(s) that were on it until you reconnect a screen.
> or do you think that's just not important?
i can imagine use cases where it's important, but it's something we can
address lat
On March 9, 2010 19:50:52 Aaron J. Seigo wrote:
> On March 9, 2010, Chani wrote:
> > well yeah, but then when the screen is disconnected you can't get at the
> > containment(s) that were on it until you reconnect a screen.
> > or do you think that's just not important?
>
> i can imagine use cases
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo wrote:
>> The critical thing here is that containments have to rescale the
>> widgets they contain depending on the monitor resolution. Otherwise
>
> this is both containment-specific (not all containments follow the same
> layouting strategy) and or
> 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 experie
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.
> >
> > -
> 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-th
On Wednesday 10 March 2010, Aaron J. Seigo wrote:
> On March 9, 2010, Chani wrote:
> > well yeah, but then when the screen is disconnected you can't get at the
> > containment(s) that were on it until you reconnect a screen.
> > or do you think that's just not important?
>
> i can imagine use case
On Wednesday 10 March 2010, todd rme wrote:
> On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo wrote:
> >> The critical thing here is that containments have to rescale the
> >> widgets they contain depending on the monitor resolution. Otherwise
> >
> > this is both containment-specific (not all co
On Wed, Mar 10, 2010 at 7:14 AM, Marco Martin wrote:
> On Wednesday 10 March 2010, todd rme wrote:
>> On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo wrote:
>> >> The critical thing here is that containments have to rescale the
>> >> widgets they contain depending on the monitor resolution. Other
On Wednesday 10 March 2010, todd rme wrote:
> On Wed, Mar 10, 2010 at 7:14 AM, Marco Martin wrote:
> > On Wednesday 10 March 2010, todd rme wrote:
> >> On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo wrote:
> >> >> The critical thing here is that containments have to rescale the
> >> >> widgets th
On March 9, 2010, todd rme wrote:
> On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo wrote:
> >> The critical thing here is that containments have to rescale the
> >> widgets they contain depending on the monitor resolution. Otherwise
> >
> > this is both containment-specific (not all containments
On March 9, 2010, Chani wrote:
> it was mostly the fact that the api has the assumption that there is One
> And Only One "current" activity; wanted to be sure that wouldn't cause us
> headaches someday.
as long as that doesn't mean one current Containment, we'll be fine.
via Plasma::Context, an A
On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo wrote:
>> If someone did this, would you accept the patch? I described a
>
> sure; i'd recommend doing it as a proof-of-concept first in a new Containment
> plugin, so that it isn't bumping into existing layout code. it would make it
> easier to te
On March 10, 2010, Ivan Čukić wrote:
> > do you have any thoughts currently on where the classes in these libs
> > should end up, or do we need to start looking for homes for them?
>
> We talked about it - Consumer would be best suited in kdelibs (maybe base
sorry, i wasn't clear enough. i meant
On March 10, 2010, todd rme wrote:
> On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo wrote:
> >> If someone did this, would you accept the patch? I described a
> >
> > sure; i'd recommend doing it as a proof-of-concept first in a new
> > Containment plugin, so that it isn't bumping into existin
On Wednesday 10 March 2010, todd rme wrote:
> On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo wrote:
> >> If someone did this, would you accept the patch? I described a
> >
> > sure; i'd recommend doing it as a proof-of-concept first in a new
> > Containment plugin, so that it isn't bumping int
On March 10, 2010, Ivan Čukić wrote:
> > 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
On March 10, 2010, Marco Martin wrote:
> or, plasmaoidviewer -c yourcontainment, then drop some applets in it and
> resize as you please ;)
not the best fit for this imho. here's why:
* no Add Widgets interface (which could be added to a test app with a dozen or
so lines of code; see how it is d
> 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 t
> 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 rea
On March 10, 2010, Ivan Čukić wrote:
> > 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.
> > pe
On March 10, 2010, Ivan Čukić wrote:
> > 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
> 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 tho
> 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 gu
On Thursday 11 March 2010, Ivan Čukić wrote:
> > even go so far as to suggest that there should be a LocationResource in
> > the ResourceType enumeration.
>
> Ok, good enough for me, but it can only be added when the Location gets its
> ontology (to be more precise, to get the type uri). Adding an
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 applic
> 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 bu
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 se
On March 26, 2010 11:58:13 Ivan Čukić wrote:
> 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
On March 30, 2010, Chani wrote:
> AppletIconWidget? it does all its own painting, and has some odd-looking
> sizing code,
i suppose you are refering to resizeEvent? if so, it simply reserves enough
space for one line of text below the icon and makes the icon size big enough
to fill the rest.
>
On March 26, 2010, Ivan Čukić wrote:
> - all manager signals converted into listener objects
this is the registeredActivityControllers stuff in the kded service? if so:
turns out that dbus signals aren't as bad as i had been led to believe. it
turns out that some of kdelibs were using certain d
On Wednesday 31 March 2010, Aaron J. Seigo wrote:
> On March 30, 2010, Chani wrote:
> > AppletIconWidget? it does all its own painting, and has some odd-looking
> > sizing code,
>
> i suppose you are refering to resizeEvent? if so, it simply reserves enough
> space for one line of text below the i
> > After the time comes when we can rely on nepomuk 24/7, we can remove
> > the caching kded service since all of this is hidden behind the API.
>
> 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 reason /
> moti
> 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
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. If not, then the weekend?
sounds great; i'll be around :)
> > if we work around subsystems because "they don't wor
> 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
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. If not, then the weekend?
>
> sounds great; i'll be arou
btw, at this moment I am editing Plasma::Context to return some made-up
activities for testing.
I have a midterm tomorrow, but chances are by friday or saturday I'll be
itching to put some *real* data in there... :)
--
This message brought to you by eevil bananas and the number 3.
www.chani3.co
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. If no
47 matches
Mail list logo
