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 around :)
hey
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.
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 not, then the
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
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 icon and
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 /
motivation to
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 work well
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 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 KDE
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
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, 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 item
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
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.
-
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
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 cases where
On Wednesday 10 March 2010, todd rme wrote:
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo ase...@kde.org 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
On Wed, Mar 10, 2010 at 7:14 AM, Marco Martin notm...@gmail.com wrote:
On Wednesday 10 March 2010, todd rme wrote:
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo ase...@kde.org wrote:
The critical thing here is that containments have to rescale the
widgets they contain depending on the
On Wednesday 10 March 2010, todd rme wrote:
On Wed, Mar 10, 2010 at 7:14 AM, Marco Martin notm...@gmail.com wrote:
On Wednesday 10 March 2010, todd rme wrote:
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo ase...@kde.org wrote:
The critical thing here is that containments have to rescale
On March 9, 2010, todd rme wrote:
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo ase...@kde.org 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
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
On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo ase...@kde.org 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
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 where
On March 10, 2010, todd rme wrote:
On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo ase...@kde.org 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
On Wednesday 10 March 2010, todd rme wrote:
On Wed, Mar 10, 2010 at 12:55 PM, Aaron J. Seigo ase...@kde.org 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
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 people
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
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
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 the
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 chan...@gmail.com 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
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
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 service
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
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 later
On Tue, Mar 9, 2010 at 9:44 PM, Aaron J. Seigo ase...@kde.org 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
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
45 matches
Mail list logo
