DevHeads.net

kactivities update

hi all.

so as promised, libkactivities is no longer in the KDE/4.7 branch of kdelibs
and kde-workspace now uses libkactivities instead of an old copy of the
classes in libkworkspace. this means kde-workspace now relies on the
kactivities git module which has the current versions of kactivitymanagerd and
libkactivities.

Comments

Re: kactivities update

By Ivan Cukic at 12/05/2011 - 03:31

Cool :)

When we are at it:

Apart from various changes in libkactivities, there is now a branch of
kdelibs called ivan/kparts-activities which provides all kparts-based
applications the ability to report resource events (document
open/close...) to the activity manager.

Since kdelibs are frozen, this will never go into master, but will
need to wait for kf5. Until then:
- plasma active (at least meego version, don't know about sebas'
balsam) will use it;
- i encourage everybody to test it and play with it.

Cheerio!
Ivan

Re: kactivities update

By Aaron J. Seigo at 12/05/2011 - 03:54

On Monday, December 5, 2011 09:31:49 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote:
to expand on why this is a bit more: it requires libkactivities, which will
need to be built after various tier1/2 libraries but before kparts. this can't
happen with kactivities already being a separate module until at least its
dependencies are also modularized. once those deps are modularized, i'd like
to see this merged as it is a very cool feature: open a file in $RANDOM_KPART
and you can send it by email, bookmark it, connect it to an activity ...

... and we have some interesting plans for this in future, such as "send to my
tablet", social network integration (for those who care about such things ;)
and more ..

Re: kactivities update

By Ivan Cukic at 12/05/2011 - 04:12

On 5 December 2011 09:54, Aaron J. Seigo < ... at kde dot org> wrote:
More clarification :)

It doesn't link to libkactivities. It has a few of its classes in
private area - statically linked. I did it this way to avoid recursive
dependencies kdelibs -> libkactivities -> kdelibs.

Re: kactivities update

By Aaron J. Seigo at 12/05/2011 - 04:45

On Monday, December 5, 2011 10:12:04 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote:
yes, i skipped the details. done properly it should be linking libkactivities.
this is an acceptable short term work-around given it's in a branch, while
doing it "right" requires the modularization to be complete for at least
libkactivities dependencies.

Re: kactivities update

By Kevin Kofler at 12/08/2011 - 11:12

Aaron J. Seigo wrote:
Or it'd require just building everything as one package as we've been doing
before, which is the easiest way to avoid circular dependencies…

Modularization keeps causing problems like this.

FWIW, since we're planning to ship Plasma Active alongside Plasma Desktop in
Fedora 17 (parts are already in Rawhide), we'll likely carry these patches
anyway (if they get released as part of the Plasma Active patchset), though
we are no fans of copied classes just to avoid circular dependencies (There
ought to be a better solution!).

I find it also quite funny that the very people complaining about
distributions patching in features into their kdelibs are doing that very
same thing as part of their Plasma Active distribution…

Kevin Kofler

Re: kactivities update

By Thomas Zander at 12/08/2011 - 14:05

On Thursday 08 December 2011 17.12.05 Kevin Kofler wrote:
Kevin, you have brought up your points and made your position very clear on
this and related topics in your 15 mails or so in the last month.
The result of you bringing them up has been that people thought more about the
proper way to do it, but one point has been made clear. The direction of
modularization will continue and is supported by a lot of people.

A sentence like this, that implies an accusation but doesn't straight out say
so is not helpful. Its close to being disrespectful.
If you want to have an influence in KDE, in its direction and its quality and
if you want to enjoy feeling part of a community as wonderful as KDE, this
kind of talking is not very helpful.

Please be part of KDE, in a positive way. :-)

Thanks!

Re: kactivities update

By Kevin Kofler at 12/08/2011 - 11:12

Aaron J. Seigo wrote:
Or it'd require just building everything as one package as we've been doing
before, which is the easiest way to avoid circular dependencies…

Modularization keeps causing problems like this.

FWIW, since we're planning to ship Plasma Active alongside Plasma Desktop in
Fedora 17 (parts are already in Rawhide), we'll likely carry these patches
anyway (if they get released as part of the Plasma Active patchset), though
we are no fans of copied classes just to avoid circular dependencies (There
ought to be a better solution!).

I find it also quite funny that the very people complaining about
distributions patching in features into their kdelibs are doing that very
same thing as part of their Plasma Active distribution…

Kevin Kofler

Re: kactivities update

By Sebastian =?utf... at 12/09/2011 - 08:38

On Thursday, December 08, 2011 17:12:05 Kevin Kofler wrote:
Yet it's worth it and we will finish this effort so the whole situation is
cleaner again. Besides, the code mentioned under "the details" (which you
refer to) is not part of kdelibs for exactly that reason.

You could be more specific, more productive, more reasonable and more friendly
here. :)

Let me explain a bit the situation for those would like to understand it
better: There are two reasons, why we patch some packages for PA:

- QA, while the patches are OK for the limited scope of Plasma Active, they
might not be for the desktop, we're basically not providing *any* guarantee
that the patches we're shipping for PA are usable on Plasma Desktop, and we
haven't tested it. Use at your own risk, make sure you understand what they
do. I'd recommend against doing what you plan. There you go, I still
recommend not to patch kdelibs.

- Timing, with the above bits about QA in mind, we've not yet integrated our
PA-specific changes in master in all cases. (Actually, the stuff we needed
for PA1 has been merged, but we came up with a bunch of new things for
PA2 we'll trickle into master according to the release schedules and freeze
policies. We definitely do *NOT* want to disrupt Plasma Desktop with things
that we need for Plasma Active, and that aren't finished as of yet.

You can be sure that everything we do goes into master eventually.

Patches that go on top of Plasma Active might not be suitable for the desktop,
so I'd be careful with that. You don't want to have the bugs you filed closed
because they're caused by non-standard kdelibs (which is a) the reason they're
not shipped with SC, and b) not waste ours and your time with that.

Bottom line: Please work *with* us, not against us. Assume positive.