Re: kactivities update
On Thursday, December 08, 2011 17:12:05 Kevin Kofler wrote: Aaron J. Seigo 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. 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. 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. 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… 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. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: kactivities update
Aaron J. Seigo 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. 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
Aaron J. Seigo 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. 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
On Thursday 08 December 2011 17.12.05 Kevin Kofler wrote: Aaron J. Seigo 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. 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. 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. 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… 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! -- Thomas Zander
Re: kactivities update
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 -- 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
Re: kactivities update
On 5 December 2011 09:54, Aaron J. Seigo ase...@kde.org wrote: On Monday, December 5, 2011 09:31:49 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote: Since kdelibs are frozen, this will never go into master, but will need to wait for kf5. 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 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. -- Cheerio, Ivan -- 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
Re: kactivities update
On Monday, December 5, 2011 10:12:04 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote: On 5 December 2011 09:54, Aaron J. Seigo ase...@kde.org wrote: On Monday, December 5, 2011 09:31:49 Ivan =?utf-8?B?xIx1a2nEhw==?= wrote: Since kdelibs are frozen, this will never go into master, but will need to wait for kf5. 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 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. 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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
