Re: proposal: remove KTextEditor interface from kdelibs repository
Aaron J. Seigo wrote: On Tuesday, February 1, 2011, Harri Porten wrote: On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. agreed; and in the case of KFileDialog, i would expect it to be classified as platform target and moved higher up the chain than the dev frameworks. and then there is no sideways dep between it and anything in libkdeui: libkdeui would be dev framework, KFD would be platform target. a more layered approach, iow. the purpose of all this would be to create something that has a profile which 3rd party developers are more likely to take up. right now all of kdelibs is too much and we're losing lots of potential developers. being able to cherry pick just libsolid, e.g., would be a big win. kdelibs is better than it was in kde3 times, but there's still some serious mashing going on between app dev frameworks and platform target stuff (this is an insight i first heard from thiago, btw; i take zero credit and/or blame for it ;) There is a wiki page for this stuff by the way. Feel free to review it or add to it. http://techbase.kde.org/Projects/KDELibsModifications
Re: proposal: remove KTextEditor interface from kdelibs repository
Alexander Neundorf wrote: On Wednesday 09 February 2011, Stephen Kelly wrote: Aaron J. Seigo wrote: On Tuesday, February 1, 2011, Harri Porten wrote: On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. agreed; and in the case of KFileDialog, i would expect it to be classified as platform target and moved higher up the chain than the dev frameworks. and then there is no sideways dep between it and anything in libkdeui: libkdeui would be dev framework, KFD would be platform target. a more layered approach, iow. the purpose of all this would be to create something that has a profile which 3rd party developers are more likely to take up. right now all of kdelibs is too much and we're losing lots of potential developers. being able to cherry pick just libsolid, e.g., would be a big win. kdelibs is better than it was in kde3 times, but there's still some serious mashing going on between app dev frameworks and platform target stuff (this is an insight i first heard from thiago, btw; i take zero credit and/or blame for it ;) There is a wiki page for this stuff by the way. Feel free to review it or add to it. http://techbase.kde.org/Projects/KDELibsModifications From the page: TODOkdelibsMerge kdesupport(which is all functional libraries) into kdelibs Sounds good. But kdesupport is not what it once was, stuff has been moved out of it, e.g. phonon. There are also other nice Qt-addon libraries, like probably most prominently Qwt (http://qwt.sourceforge.net) or maybe also Qxt (http://dev.libqxt.org/libqxt/wiki/Home). Having a set of non-platform, basically Qt-extension libraries, like stuff in kdesupport is, is not too different from those. Maybe we could invite them (Qwt) to become part of the KDE-powered Qt extension libraries ? From a thread linked in the page :) : Benjamin and I were in the qxt channel to see what kind of stuff they have, how it's licenced, and organized etc. It's not clear yet if that would be a good place to put classes like these. Personally, I'd prefer something tied to the kde release schedule. I'm not sure the qxt guys would go for that though. Things have changed, as you said. I'm all for making something more inclusive of the existing community of extensions to Qt if that's possible. Evaluating whether some kde libraries can be made Qt only without kde interdependencies needs to happen first though I think. Qxt may also have the same problem KDE has. http://libqxt.bitbucket.org/doc/tip/qxtapplication.html Do you have to use a QxtApplication to use some features of Qxt? Is that at odds with KApplication? I have no idea. Does Qwt have something similar?
Re: proposal: remove KTextEditor interface from kdelibs repository
On Wednesday 09 February 2011, Stephen Kelly wrote: Alexander Neundorf wrote: On Wednesday 09 February 2011, Stephen Kelly wrote: Aaron J. Seigo wrote: On Tuesday, February 1, 2011, Harri Porten wrote: On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. agreed; and in the case of KFileDialog, i would expect it to be classified as platform target and moved higher up the chain than the dev frameworks. and then there is no sideways dep between it and anything in libkdeui: libkdeui would be dev framework, KFD would be platform target. a more layered approach, iow. the purpose of all this would be to create something that has a profile which 3rd party developers are more likely to take up. right now all of kdelibs is too much and we're losing lots of potential developers. being able to cherry pick just libsolid, e.g., would be a big win. kdelibs is better than it was in kde3 times, but there's still some serious mashing going on between app dev frameworks and platform target stuff (this is an insight i first heard from thiago, btw; i take zero credit and/or blame for it ;) There is a wiki page for this stuff by the way. Feel free to review it or add to it. http://techbase.kde.org/Projects/KDELibsModifications From the page: TODOkdelibsMerge kdesupport(which is all functional libraries) into kdelibs Sounds good. But kdesupport is not what it once was, stuff has been moved out of it, e.g. phonon. There are also other nice Qt-addon libraries, like probably most prominently Qwt (http://qwt.sourceforge.net) or maybe also Qxt (http://dev.libqxt.org/libqxt/wiki/Home). Having a set of non-platform, basically Qt-extension libraries, like stuff in kdesupport is, is not too different from those. Maybe we could invite them (Qwt) to become part of the KDE-powered Qt extension libraries ? From a thread linked in the page :) : Benjamin and I were in the qxt channel to see what kind of stuff they have, how it's licenced, and organized etc. It's not clear yet if that would be a good place to put classes like these. Personally, I'd prefer something tied to the kde release schedule. I'm not sure the qxt guys would go for that though. Ooops, sorry, didn't see that. Actually I heard from Qxt the first time just a few weeks ago. Things have changed, as you said. I'm all for making something more inclusive of the existing community of extensions to Qt if that's possible. Evaluating whether some kde libraries can be made Qt only without kde interdependencies needs to happen first though I think. Yes. One question is where to draw a line. E.g. for me (speaking as commercial developer) I'd be fine to have to link a few more libraries, as long as they don't require to run some extra daemons or something. So if there was some library which depends on Qt and some library from the KDE non-platformy libs this would probbaly be fine with me. IOW, I wouldn't want to have to start virtuoso to use some graphing widget ;-) Qxt may also have the same problem KDE has. http://libqxt.bitbucket.org/doc/tip/qxtapplication.html Do you have to use a QxtApplication to use some features of Qxt? Is that at odds with KApplication? I have no idea. Does Qwt have something similar? No, Qwt is really just a set of widgets. Alex
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: --nextPart3865859.bpjpIik9D5 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true f= or things that require libs in kde-support, kdepimlibs or kdegraphics, though. =20 This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. I have commented on the kate developers plans more than once, but people just seems to bring it up over and over again. But no. Nothing has changed in my perception of things. So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. I'm unsure why we wants to break the promises we made to the rest of the world about the stability of our libraries. (oh. and why should a kile/kdevelop/... user compile and install kate?) /Sune - who as a packager will have a hard time effectively undoing this work in order to *keep* the compatibility. As a packager, I actually trust KDE to live up to their promises.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote: On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: --nextPart3865859.bpjpIik9D5 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true f= or things that require libs in kde-support, kdepimlibs or kdegraphics, though. =20 This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. I have commented on the kate developers plans more than once, but people just seems to bring it up over and over again. But no. Nothing has changed in my perception of things. So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. I agree that this will lead to additional dependency to kate package for some modules, but is this that bad? Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) Yeah, and because of this requirement, which I can agree on, I didn't remove it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime components moving to other modules is not a SC/BC problem. It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. They never can do that. Every now and then new dependencies come up. New versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely that you can just up + recompile kdelibs and be fine. Normally it not even compiled... I'm unsure why we wants to break the promises we made to the rest of the world about the stability of our libraries. (oh. and why should a kile/kdevelop/... user compile and install kate?) Because it uses katepart? We could even split it up more, in more repos, like katepart, kate, kwrite, but given they interdepend a lot, that is even more hassle. Beside, kile users won't compile it, they will use the versions shipped with the distro. /Sune - who as a packager will have a hard time effectively undoing this work in order to *keep* the compatibility. As a packager, I actually trust KDE to live up to their promises. I still no get this problem. kdelibs adds more and more dependencies over the last years, same for other modules. Why is this dependency change different at all? It is not even a compile time dependency change... Beside: I am grateful for your work as packager and don't want to annoy you. But really, the whole git moving only makes sense, if stuff that is related is grouped. And no, beside using kdelibs stuff, katepart and co. is not really related. And working over 3 repositories is a hassle. (you need to clone all, thats slow on dialup, you need to send at most 3 patches, you need to fiddle with CMake to build only the kate parts, if you want only to have katepart and co. fresh and not all libs, ...) I can understand that new dependencies are work, but I don't see the problem in comparison to other dependencies which change the whole time. To get new contributors for Kate, it is essential, that working on it is EASY. And the current way is easy (http://kate-editor.org/get-it/), the old not. Greetings Christoph -- -- Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, 2011-02-01, Christoph Cullmann wrote: On Tuesday, February 01, 2011 11:11:08 am Sune Vuorela wrote: So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. I agree that this will lead to additional dependency to kate package for some modules, but is this that bad? It would require a new kdelibs package (the new one will no longer satisfy the same needs) or require that the packagers extract the interface related things from kate and add them as a dependency for the kdelibs meta package. Application developers has made their *current* apps based on this, and stuff will break by moving e.g. katepart out of kdelibs. Now KTextEditor. KTextEditor is a public library in kdelibs. This means that people can actually expect KTextEditor to be there when they do find_package(KDE4 REQUIRED) Yeah, and because of this requirement, which I can agree on, I didn't remove it from kdelibs, as its public API and I wanted to be SC + BC. And no, runtime components moving to other modules is not a SC/BC problem. While it is SC/BC, it changes the contents of the kdelibs package. Either packagers put in extra effort of extracting the now missing parts from Kate and add them as dependencies to kdelibs or they create a new version of kdelibs which no longer satisfies the dependency rules of all applications packaged against the old one (or with even more effort adding the old kdelibs package as an alternative for all program packages that do not use the runtime dependency). It also means that people who builds from source can do svn up / git pull in kdelibs and install new requirements,make, make install and still have all apps working. They never can do that. Every now and then new dependencies come up. New versions of virtuoso needed, new lib*, whatever. You NEVER was able to rely that you can just up + recompile kdelibs and be fine. Normally it not even compiled... The difference is that new dependencies add things to kdelibs so they can only be used by applications built against that new version. Removing a dependency would mean you'd have to check all applications on whether they need the removed dependency and explicitly add it to their dependency list. Or do you mean kate would become an additional depencency of kdelibs (however that would work)? I still no get this problem. kdelibs adds more and more dependencies over the last years, same for other modules. Why is this dependency change different at all? It is not even a compile time dependency change... My guess is that there are different rules for removal of functionality than there are for adding. On source or binary level we can always add (non-virtual) functions but we cannot remove any. When we make kdelibs depend on something, we usually put quite some effort into our layer to make sure we can change dependencies without changing dependencies for apps built on kdelibs, e.g. make kdelibs depend on different libraries for new Solid backend implementations without requiring new dependency rules for all applications using Solid. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: proposal: remove KTextEditor interface from kdelibs repository
erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go then ... hm.. looking at it, only khtml has a build-time dependency on it. if the texteditor part isn't available (or the source of the crash even? :) what does the debugger do at that point? Pop up an error message and abort execution, as it expects it to be part of kdelibs. Which is coincidentally very similar to what KTextEditor tutorials suggest --- see http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example (except it needs katepart in specific) So, as far as I am concerned, this is an incompatible change. (Moving to kdebase-runtime would be fine, of course).
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 16:43, Maksim Orlovich a écrit: erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go then ... hm.. looking at it, only khtml has a build-time dependency on it. if the texteditor part isn't available (or the source of the crash even? :) what does the debugger do at that point? Pop up an error message and abort execution, as it expects it to be part of kdelibs. Which is coincidentally very similar to what KTextEditor tutorials suggest --- see http://techbase.kde.org/Development/Tutorials/Kate/KTextEditor_Example (except it needs katepart in specific) Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Sune Vuorela wrote: So far, we as packagers have been told that applications can expect all plugins (kio slaves, kparts, ...) located in kdelibs and kdebase-runtime to be available, and segfault is a acceptable way of handling missing things. to boil it down to its essence, then, the primary issue is that we have a black box with various runtime plugins in it that applications may or may not rely on. perhaps we should think about being more clear in our runtime definitions and stricter with requiring apps to advertise their runtime expectations, so that we can go from having a huge pile of dependencies to just the requirements for a given application. there's also a conflict of interest between packaging and development going on here. development needs/wants one thing, packaging needs/wants a different thing. exploring ways to more clearly and cleanly create a working division bewteen development and release management may be something for us to consider as well. (i'm thinking about the above mostly in the context of the upcoming Platform11 dev sprint in June .. gathering topics :) -- 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.
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. And I'm not sure there should be such a thing. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Aaron J. Seigo ase...@kde.org wrote: perhaps we should think about being more clear in our runtime definitions a= nd=20 stricter with requiring apps to advertise their runtime expectations, so th= at=20 we can go from having a huge pile of dependencies to just the requirements = for=20 a given application. I'm all for modularizing and being more clear, but it should not be done by tearing out parts of kdelibs to see what happens. Rather: Identify how we want apps to communicate their runtime requirements. Get apps to specify it using the communication way described above. This is for all apps built on the KDE Platform, no matter if they resides in git.kde.org, gitorious, launchpad or sourceforge. Get packagers and others to test that things work Break things apart at tarball generation. Test that things work Break up repositories Profit. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. Actually splitting up repos is the easy and less interesting part overall. Ian
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, and we shouldn't set up a complete development environment for him. /Sune
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Kevin Krammer wrote:
On Tuesday, 2011-02-01, Christoph Cullmann wrote:
...
Yeah, and because of this requirement, which I can agree on, I didn't
remove it from kdelibs, as its public API and I wanted to be SC + BC. And
no, runtime components moving to other modules is not a SC/BC problem.
While it is SC/BC, it changes the contents of the kdelibs package.
Either packagers put in extra effort of extracting the now missing parts
from Kate and add them as dependencies to kdelibs or they create a new
version of kdelibs which no longer satisfies the dependency rules of all
applications packaged against the old one (or with even more effort adding
the old kdelibs package as an alternative for all program packages that do
not use the runtime dependency).
This is about removing libktexteditor, installed currently by kdelibs, from
kdelibs, and moving it into the kate repository, right ?
This would be a source incompatible change.
find_package(KDE4 REQUIRED)
add_executable(Foo ${mySrcs})
target_link_libraries(Foo ${KDE4_KTEXTEDITOR_LIBS})
- does not work anymore, because you cannot rely on that libktexteditor is
there if kdelibs has been found.
So, from my POV, this can't be done for KDE 4.x.y.
Alex
Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P I think this might be related: http://www.kdedevelopers.org/node/4232 Alex
Re: proposal: remove KTextEditor interface from kdelibs repository
Mardi, le 1 février 2011, à 20:14, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 19:42, Alexander Neundorf a écrit: On Tuesday 01 February 2011, Friedrich W. H. Kossebau wrote: Mardi, le 1 février 2011, à 18:53, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: Uh, that is old-fashioned. Should instead ask the user whether she wants to install the proper text editor module. Isn't there some simple standard api for that these days? A simple standard api for what? installations of scripts and wallpapers and stuff, sure. there is the ghns things. For isntallation of compiled stuff, no. Not something related to packagekit or similar? Eh, IMHO there should be something like that if there isn't. With OBS and Co. compiled stuff is not that much different, you just get a variant tailored to your (hardware) profil. Can someone please empty my TODO list? :) And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? I think Lubos proposed something like this recently, i.e. at some point last year here on this list. Others have done now and then as well, e.g., ahem, me ;) here a few years ago: http://markmail.org/message/xo2b4zw2ee6si6g2 Oh, how cheap talk is :P I think this might be related: http://www.kdedevelopers.org/node/4232 Oh, nice, missed that before, thanks for the pointer, Alex :) Indeed, that is pretty related. Hm, might be an interesting GSoC task to merge this with DrKonqi's debug packages loading, Phonon's new codec pulling and all the other GHNS/OCS related stuff... so at some not to distant time the KTextEditor example can be changed to code with a better user experience :) Cheers Friedrich -- Desktop Summit 2011 - Berlin, Germany - August 6-12th - www.desktopsummit.org
Re: proposal: remove KTextEditor interface from kdelibs repository
A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? Albert Actually splitting up repos is the easy and less interesting part overall. Ian
Re: proposal: remove KTextEditor interface from kdelibs repository
On 01.02.11 19:49:10, Albert Astals Cid wrote: A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Andreas -- You are confused; but this is your normal state.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday 01 February 2011, Andreas Pakulat wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: A Dimarts, 1 de febrer de 2011, Ian Monroe va escriure: On Mon, Jan 31, 2011 at 21:19, Aaron J. Seigo ase...@kde.org wrote: [snip] oh well, KTextEditor isn't an option, Should we give up so easily on this? The whole point of modularization is to remove cross-module dependencies, just like KHTML depending on KTextEditor. Ideally this sort of sideways dependency wouldn't exist. What is your ideal then? Writing KTextEditor in KHTML again since we can not depend on it? Or using a worse component? No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. I agree. Which would mean that khtml would depend on kate. Also the webkit part if it uses the kate component. Which makes the build order harder to get right, as Michael notes in the other thread. Do we want that ? Probably. Can we have that for KDE 4.x.y ? I don't think so. I can remember that a point of criticism about gnome was that it is hard to get it built correctly with all the relatively small independent libs. I think we are moving in that direction... Are we aware of this and is this ok with us ? Alex
Re: Installing specific packages on demand (was: Re: proposal: remove KTextEditor interface from kdelibs repository)
On Tue, Feb 1, 2011 at 1:55 PM, Friedrich W. H. Kossebau kosse...@kde.org wrote: Mardi, le 1 février 2011, à 19:39, Sune Vuorela a écrit: On 2011-02-01, Friedrich W. H. Kossebau kosse...@kde.org wrote: And I'm not sure there should be such a thing. Hm. You don't agree that a user experience like Sorry, missing X to do Y. Would you like to get X now for that? is better than one à la Na, no way to do Y.? Yes. since we can't assume the user has the right to install to the system directory, We can't assume for all, but in many installations the user does. Like the ususal private computer. For administrated systems, there could be a substitute which instead of allowing to install rather aids the user to file a request to the admin, for convenience and getting things done. and we shouldn't set up a complete development environment for him. I was thinking of interfacing to the normal packaging system of the system. He, something like DrKonqi installing the debug info packages on request. So something like that is existing already, just needs to be generalized perhaps. Cheers Friedrich openSUSE's version of KDE has something like this as well. It might be worth seeing how they do it. -Todd
Re: proposal: remove KTextEditor interface from kdelibs repository
On 2/1/11, Andreas Pakulat ap...@gmx.de wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Funny, I would think the proper fix would be for people who put their work into kdelibs to honor the requisite commitment to backwards compatibility, rather than to punish other libraries for doing the right thing in using existing facilities.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Maksim Orlovich wrote: On 2/1/11, Andreas Pakulat ap...@gmx.de wrote: On 01.02.11 19:49:10, Albert Astals Cid wrote: No, the natural fix is to make the dependency chain proper, i.e. KTE depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml cannot be part of kdelibs anymore if KTE is not part of kdelibs anymore. Funny, I would think the proper fix would be for people who put their work into kdelibs to honor the requisite commitment to backwards compatibility, rather than to punish other libraries for doing the right thing in using existing facilities. it's not about punishing any library or individuals' work. if we modularize kdelibs, then that means we may end up with a small set of interconnected repositories with clear dependency chains. for instance... we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. we may even decide to split things up into dev framework vs platform target. (if this sounds like KDE5 sort of stuff .. well .. yes :) then we'd have other pieces that have been put into kdelibs in the past that maybe should live on as part of the KDE Platform (or whatever call it) but in their own repositories. that could include the KTextEditor interface, perhaps libplasma as well. so in the case of something that uses KTextEditor and is part of kdelibs now, it could still be part of the KDE Platform but be its own module with a dep on corelibs+kate. which is really no different than it is right now, except everything would be explicit and not in one single repository. the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. the domino effect there would be altering CMakeLists.txt for apps that need KTextEditor (for example) to explicitly include it. alternatively, we could maintain a compatibility FindKDE4-style macro that would pull in all those pieces. so apps that did nothing would still have the same build profile without any modifications, just risk pulling in more libraries than they really need as build requirements. a virtual kdelibs if you will. we sort of have this already with kde-support, imho. apps could then be updated as desired to more accurately note their needs, bringing dependency definition into sharper definition. but most importantly, new apps, or existing Qt apps, could then much more easily say I just want libkdecore or I just want libsolid and get it. there are a hell of a lot of details in between all those broad strokes. if we start pondering them now, though, by the time we hit Randa in June we may be in a very good position to have effective discussions that result in actual decisions :) -- 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.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Alexander Neundorf wrote: I can remember that a point of criticism about gnome was that it is hard to get it built correctly with all the relatively small independent libs. I think we are moving in that direction... Are we aware of this and is this ok with us ? yes, i am aware of this; and no, i'm not personally ok with it :) if this is to work, we absolutely must find solutions that ballance the benefits of greater modularity with ease of build. there are many possible answers (better build tools; keeping things within the same repositories but with more modular builds within those repostories; relying on packaging instead of upstream tarballs for the modularization) and lots of details to get right (e.g. how to deal with dependencies pulled in at runtime via kde- runtime) i think it is innevitable that we will need to compromise in places to find our optimal mix. it is not a trivial set of questions. we do not, however, need to have an answer today. we have a Platform meeting in June, and we can use the months leading up to that to play around with different scenarios, tugging at the threads to find complications that arise (as we are doing in this thread) and try to have a very good overall picture by the time that in person meeting happens. it's great that we are aware of and thinking about these knock-on effects. it'll take longer than just charging headlong forward, but we will come out with a good solid KDE solution as a result... -- 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.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. Unless unless we find some real technical means to manage compile-time and runtime-dependencies. Maybe even MS Windows can serve as an example of a platform that has gone through all of this, is very extensible and at the same time very much backward compatible? One part of the puzzle I can think of a interfaces (pure .h files) that can be queried at runtime. In one way or the other that has been excersised in KDE in the past already (Corba, KParts, DCOP/D-Bus, KService etc.). Harri.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Tuesday, February 1, 2011, Harri Porten wrote: On Tue, 1 Feb 2011, Aaron J. Seigo wrote: we could end up with a new kdelibs module that contains just the core stuff such as kdecore, kdeui, kio .. there could be requirements in there about allowable dependencies between those libraries. [...] the big change here would be that applications that require different parts of the KDE Platform might have to define which parts to include (e.g. KTextEditor interface) rather than them being provided implicitly in one big chunk as it is now. Would that be really such a big change? We can certainly redefine a new kdelibs. But I think it will always be just another set where some (sometimes arbitrary boundaries) are drawn. In my eyes, KTextEditor is just a very random example. Will we next have the same discussion about KFileDialog? It uses KPushButton. Should we move out both to avoid sideways dependencies? What I want to say: we can always define what kdelibs comprises. It can be small, it can be big. I don't see a technically perfect optimum, though. At best we can strive for reasonable. agreed; and in the case of KFileDialog, i would expect it to be classified as platform target and moved higher up the chain than the dev frameworks. and then there is no sideways dep between it and anything in libkdeui: libkdeui would be dev framework, KFD would be platform target. a more layered approach, iow. the purpose of all this would be to create something that has a profile which 3rd party developers are more likely to take up. right now all of kdelibs is too much and we're losing lots of potential developers. being able to cherry pick just libsolid, e.g., would be a big win. kdelibs is better than it was in kde3 times, but there's still some serious mashing going on between app dev frameworks and platform target stuff (this is an insight i first heard from thiago, btw; i take zero credit and/or blame for it ;) we also need to ask ourselves how we can encourage packagers to split things up better so that libsolid does come in its own binary package on a system ... even if we include it in a larger source module. packagers do this with our applications already, the challenge is in the sorts of things that sune is bringing up .. and much of that is our policy (or lack thereof) surrounding what kdelibs means and what implicit guarantees are provided to apps built using it. Unless unless we find some real technical means to manage compile-time and runtime-dependencies. Maybe even MS Windows can serve as an example of a platform that has gone through all of this, is very extensible and at the same time very much backward compatible? One part of the puzzle I can think of a interfaces (pure .h files) that can be queried at runtime. In one way or the other that has been excersised in KDE in the past already (Corba, KParts, DCOP/D-Bus, KService etc.). yeah, that could definitely be part of the solution to teasing out the runtime 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.
proposal: remove KTextEditor interface from kdelibs repository
hi :) since Ian already brought it up and suggested a separate thread for it, let me do just that. we discussed this a bit on the release mailing list, but the discussion really ought involve more people since it will impact us all. the idea is this (and the Kate devs are just fine with it, btw): * remove the KTextEditor interface from the kdelibs repository * enable KTextEditor in the build for the kate git module * introduce a FindKTextEditor.cmake to kdelibs/cmake/modules/ that looks for the interface and directs people to the kate repo if it doesn't exist there * make all KDE apps that use the KTextEditor interface use that the reason for this is: * the Kate team wants to develop all kate related code in one place and make it easier for people to try out Kate from mainline (by not making people check out kdelibs just for the kate pieces that are in there) * it would be an interesting and useful experiment with modularization of kdelibs for cases such as these, namely when a library is used by a number of apps but is not general purpose like kdecore, kdeui, kio, etc. are. potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true for things that require libs in kde-support, kdepimlibs or kdegraphics, though. thoughts? -- 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.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true for things that require libs in kde-support, kdepimlibs or kdegraphics, though. This is more a package management concern, and while I do want to avoid having hundreds of dependencies just to build a single KDE Platform application, I don't think this is too difficult as long as we make it clear which dependencies are actually in place for our packagers (e.g. kate/kwrite requires KTextEditor from libktexteditor, etc.) The concern that I have, on the other hand, is whether this can be done in a source and binary compatible fashion. I just took a look at kdelibs/interfaces/ktexteditor, and indeed there already exists a separate libktexteditor (i.e. it's not directly part of e.g. libkdecore). So given that it seems like it should easily be doable without breaking source or binary compatibility my opinion is that moving the interface out should be fine. It would be interesting to see if the various mobile development groups have already done something like this in fact. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Monday, January 31, 2011, Michael Pyne wrote: On Monday, January 31, 2011 17:42:56 Aaron J. Seigo wrote: potential caveats are that it makes it harder to build certain KDE apps because now you need not only kdelibs, but kate. this is already true for things that require libs in kde-support, kdepimlibs or kdegraphics, though. This is more a package management concern, and while I do want to avoid indeed; i'm hoping one or more of the packagers will chime in at some point. The concern that I have, on the other hand, is whether this can be done in a source and binary compatible fashion. I just took a look at yes, it can. and i don't believe anything in kdelibs itself uses it. should be fine. It would be interesting to see if the various mobile development groups have already done something like this in fact. they tend to strip out lots of things like this, yes. they also tend to do things that aren't BC in other libraries in kdelibs to get their size down further. -- 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.
Re: proposal: remove KTextEditor interface from kdelibs repository
On Monday, January 31, 2011, Andreas Pakulat wrote: On 01.02.11 01:18:58, Pino Toscano wrote: Alle martedì 1 febbraio 2011, Aaron J. Seigo ha scritto: The concern that I have, on the other hand, is whether this can be done in a source and binary compatible fashion. I just took a look at yes, it can. and i don't believe anything in kdelibs itself uses it. khtml does (but we know very few people care about it). Indeed the debugger does use it erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go then ... hm.. looking at it, only khtml has a build-time dependency on it. if the texteditor part isn't available (or the source of the crash even? :) what does the debugger do at that point? i should go hunt down ervin and find out where that nice kdelibs interdependencies chart has gone to ... * it would be an interesting and useful experiment with modularization of kdelibs I don't think taking out random pieces of kdelibs piece-by-piece is something useful to do over time: either you split the whole at once, or you don't. As there's not even a clear idea of where to split kdelibs, this request is just a different way of saying don't do it. Not to mention the amount of work necessary to do such a modularization at once. exactly ... i think it would be wise for us to try it with something small and non-critical first to discover what the challenges are and what issues arise when doing so. oh well, KTextEditor isn't an option, -- 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.
