Re: Review Request: Fix Object::connect: No such slot AbstractItemView::iconSettingsChanged(int)
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102719/#review6941 --- Ship it! yes, the slot moved to the FolderView class itself, so this is no longer needed here. - Aaron J. Seigo On Sept. 27, 2011, 4:31 p.m., Romain Perier wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102719/ --- (Updated Sept. 27, 2011, 4:31 p.m.) Review request for KDE Base Apps. Description --- Hi, there are a lot of Object::connect: No such slot AbstractItemView::iconSettingsChanged(int) in my ~/.xsession-errors - in folderview there is no AbstractItemView::iconSettingsChanged(int). Also, no such slot can be connected to KGlobalSettings::iconChanged(int) in this class. My proposal: remove the line connecting the signal to the unexisting slot :) Diffs - plasma/applets/folderview/abstractitemview.cpp 2634650 Diff: http://git.reviewboard.kde.org/r/102719/diff/diff Testing --- Thanks, Romain Perier
Re: The case for a kdelibs 4.8
On Thursday, September 29, 2011 18:11:12 Kevin Kofler wrote: Wait and see the chaos that will come up when users open their Help/About in Konqueror and it tells them that they're using Konqueror 4.8.0 under KDE 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked 4.7 or 4.8 for whether that's fixed there.) it says KDE Development Platform x.y.z. The rule so far has always been that the kdelibs version must be the same as the KDE SC version. There is no rule – at most a common practise A common practice which had been enforced by minimum required kdelibs versions in CMakeLists.txt. for, e.g. kde-workspace, that minimum version for kdelibs is 4.7. it may be even lower for other modules (many apps probably compile with rather older kdelibs than that). this really isn't an argument for or against a 4.8 .. -- 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: The case for a kdelibs 4.8
On Thursday, September 29, 2011 23:57:53 Scott Kitterman wrote: I don't like the fact that KDE developers decided to ignore their own policy on maintenance updates. I think it breaks your contract with your downstreams. In the case of what's been done so far, it doesn't have an impact on us. The changes were in before our release and are technically the features that got into the 4.7 branch to date have been things that were already worked on before the Frameworks decision was made. it's was an odd cas were features had been worked on while 4.7 was frozen with the expectation of a 4.8 ... and that left us with the choice of having a 4.8 release which we didn't want for those few features, leaving those features out and screwing up the planning of the applications depending on those changes or fudging a little bit. it was a compromise choice made to mimize downside. as with all such compromises, it isn't perfect (ergo the label of 'compromise'), but after looking at the issues and looking at different scenarios we decided this was the best option available to us compared to the others. note that some of the more actively changing and developed code in kdelibs have moved to separate git repositories already to make this issue moot for them (kactivities, nepomuk) -- 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: The case for a kdelibs 4.8
On Thursday, September 29, 2011 23:57:56 Kevin Kofler wrote: https://git.reviewboard.kde.org/r/102175/ https://git.reviewboard.kde.org/r/102291/ https://git.reviewboard.kde.org/r/102350/ none of these are critical feature additions. they elevate the usability of libplasma and are valuable, but we've lived just fine without these features to date. if we were working on and releasing a 4.8 version of kdelibs, our users would have to wait for these features until 4.8 was released (e.g. in january) and distributions made packages available to their users (often much later than that). instead, they'll have to wait until frameworks is ready. and this code can, and should, go into libplasma in the frameworks branch today. -- 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: The case for a kdelibs 4.8
On Thursday, September 29, 2011 14:01:50 Kevin Kofler wrote: 1. This puts kdelibs 4 into maintenance mode even before KDE Frameworks 5 is anywhere near a release, let alone versions of the workspace and applications actually using it. As a result, we will fail to deliver new features to our end users for months if not years. we will deliver no new features in kdelibs, yes. but certainly we will be shipping new features in applications (including the workspaces) using those libraries. so our users will indeed be getting new features and we will indeed be improving the software our users get. bug fixes and performance improvements also continue, and those are things that our users really do care about as well. features are valuable, but they aren't the only thing of value. as 4.7 is still being actively maintained, even kdelibs is very much still being improved from a user's POV. And no, kdelibs features do not only target developers: Some application or workspace features require kdelibs changes, or in some cases, even consist of kdelibs changes only, e.g. my Plasma PackageKit integration work is entirely in kdelibs (libplasma). many application and workspace features do not require changes in kdelibs. though, as you note, some do. there are already many improvements in libplasma2 that the workspaces will only get to take advantage of when frameworks is released. in the meantime, we're still rolling out new features and even whole new shells (the Contour work and plasma-device shell, for instance) using the 4.7.x platform libraries. so some features will indeed have to wait .. and that's not a horrible thing because it means that frameworks will get more developer attention and the attention it is getting already will not be slowed even further by having to deal with bringing over features from 4.7.x into the re-arranged libraries in frameworks. the result will be that the time between now and 5.0 libs being available will be shortened, which is exactly what we, as application developers, need. 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. The rule so far has always been that the kdelibs version must be the same as the KDE SC version. that's not a rule anymore, and hasn't been for a while now. other than the packaging specfile changes that seem to be required in the Fedora packages, i'm not sure what the real world confusion would be. when we release apps and workspace 4.8, we'll also do a platform 4.7.x release. the release communication will not say SC 4.8 it will say Platform 4.7, Plasma Workspaces 4.8 and application updates (or something along those lines). that was not just a marketing ploy, but an attempt to align our public communication with the realities that already existed in KDE development. backported to the compatibility libraries as well. For example, when we switched our default spell checker in Fedora from aspell to hunspell in Fedora 9 (i.e. 4.0 era), I had to add support for hunspell to kdelibs3, or our users would have had to install 2 spell checkers to use KDE apps! (Even several apps in the default KDE installation hadn't been ported to kdelibs4 yet in Fedora 9.) That change never got upstreamed because kdelibs3 is no longer maintained, yet it would have been useful to many distributions. there is apparently a fundamental misunderstanding here: KDE Platform 4.7 is being maintained. but only maintained. if such a spell checker thing happened right now, we could enable that in the 4.7 branch. many of us are still committing bug fixes and other improvements to that branch, which are then merged regularly into the frameworks branch. what we aren't doing it focussing new feature development efforts in the 4.7 branch. that is happening in frameworks instead, but 4.7 is still very much maintained. as such, there should be zero reason for downstream packaging efforts to require patching bugfixes into their builds themselves. 4. The core developers, for whose convenience this change was made, are not the only ones working or willing to work on kdelibs. it wasn't convenience, which sort of makes it sound like we weren't trying hard enough ;), but necessity. the necessity is driven by resource constraints and the need for changes in kdelibs that require changes to the ABI (and which will happen anyways with Qt5) The main reason that was given for dropping kdelibs 4.8 is that this means one less branch to worry about for the people working on kdelibs, but the people who'd work on 4.8 and 5.0 are NOT the same people! which begs the very good question: why aren't they? they should be the same people. we need the 5.0 release, and that will happen faster if we don't split our resources. remember how long the 4.0 development took, in part because we kept equivocating between more 3.x releases and getting on with 4.0? I understand that the developers who are
Who relies on Soprano::Model::statement[s]Added|Removed signals?
Hi lists, with frameworks in the building and Nepomuk probably going that direction already for 4.8 I would like to clean up a bit. One of these cleanup tasks targets the Soprano::Model statement signals. So far these were the only way to get informed about changes in Nepomuk - with a very bad impact on performance and bad usability. With 4.7 we already introduced a preliminary version of the Nepomuk::ResourceWatcher[1] which is now in charge of informing clients about changes. I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. Cheers, Sebastian [1] Funnily enough only the docs for the copy in Akonadi is online at the moment: http://api.kde.org/4.x-api/kdepim-runtime-apidocs/agents/html/classNepomuk_1_1ResourceWatcher.html
Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?
On 30/09/11 12:36, Sebastian Trüg wrote: I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. You might want to contact developers using the signals directly. lxr.kde.org suggests: Digikam, Amarok, kdepim, telepathy, ginkgo and the nepomuktags Plasma dataengine. Everything else looks like your domain (although the nepomuk backupsync service might not be). Alex
Re: The case for a kdelibs 4.8
On Thursday 29 September 2011 14:01:50 Kevin Kofler wrote: Hi, as you probably already know, a decision was recently made that kdelibs 4.7 would be the last 4.x release series of kdelibs, and work would be ongoing in the 5.0 (frameworks) and 4.7 (KDE/4.7) branches only. I think this is a huge mistake, for several reasons (the TL/DR crowd can stop right here, but if you want to know why, please read on!) [..] From what I remember from the desktop summit the picture you draw here is quite an exaggeration of what is actually happening. kdelibs 4.7 is meant to be frozen for new features, but not for bugfixes. Bugfix releases of kdelibs-4.7 happenend and I'm sure will continue on happening. As for the versioning I don't see why one of those bugfix releases couldn't be rebranded as 4.8.0 if that makes things easier (that was even briefly mentioned at the release team BoF). It does not solve feature backports of course. The KDE Frameworks 5.0 development is not meant to take forever. In fact I think it's meant to be finished around early 2012, which would leave us with a frozen kdelibs for one KDE SC release, maximum two. It's also not a huge *we will break everything! Kittens will die!* release, but basically just a restructuration of the code, with little to no adjustments necessary for applications. (that was how it was marketed, anyway). The way I understood it was that there could very well be a KDE SC 4.9 release shipping a 4.9 workspace on top of 5.0 frameworks. As for the version numbers, I don't really see the problem. As long as the integrity of the KDE SC releases remains, different version numbers in its components are not really /that/ important. I do see how it could help though. Grs, Heinz signature.asc Description: This is a digitally signed message part.
Re: The case for a kdelibs 4.8 (fwd)
Forwarding my answer to kde-core-devel in order to give us packagers a voice outside our own closed mailing list. Cheers, Eric -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -- Forwarded message -- Date: Thu, 29 Sep 2011 10:37:20 -0700 (PDT) From: Eric Hameleers al...@slackware.com To: Wulf C. Krueger philant...@exherbo.org Cc: kde-packa...@kde.org Subject: Re: The case for a kdelibs 4.8 On Thu, 29 Sep 2011, Wulf C. Krueger wrote: On 29.09.2011 14:01, Kevin Kofler wrote: [Lots of excellent explanations deleted] So I am urging you to reconsider your decision and reopen master for those people willing to work on 4.8. It's not too late yet, there's a month left until the soft feature freeze for KDE SC 4.8. I totally agree with Kevin. This would lead to another packaging nightmare and would be confusing to users as well. Kevin's plea has my fullest and strongest support. Cheers, Eric -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager
Review Request: Fix HTTPProtocol::put
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102743/ --- Review request for kdelibs and Andreas Hartmetz. Description --- Fix the regression caused by a patch that addressed bug# 60898 some 8 years ago. The client should handle the message body returned by the server as a result of a PUT request since the only difference between a PUT and POST action is how the Request-URI is supposed to be handled by the server. See RFC 2616 section 9.6. More importantly this patch should fix the annoying and intermittent server error message that pops up when using git.reviewboard.kde.org. Diffs - kioslave/http/http.h b337e96 kioslave/http/http.cpp ca84f86 Diff: http://git.reviewboard.kde.org/r/102743/diff/diff Testing --- - Log into git.reviewboard.kde.org - Create a sample review request. - Attempt to change the People: assigned to it. - If you do not get a server error message, then try to Discard your changes. Thanks, Dawit Alemayehu
Re: Review Request: Fix KPasswdServer usage of KWallet
On Sept. 29, 2011, 8:14 p.m., Dawit Alemayehu wrote: Sorry, but this is simply wrong. There is a specific reason why passwords are not blindly saved into the wallet before they are validated. The idea of prompting the user for password and actually storing that password need to be two separate actions. So the question is from which application or ioslave are you having this problem ? Fixed correctly. See https://projects.kde.org/projects/kde/kdelibs/repository/revisions/c0cb2f6f489fabb0776319cfc4d2f772c28f61da - Dawit --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102729/#review6926 --- On Sept. 29, 2011, 5:37 a.m., Ben Cooksley wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102729/ --- (Updated Sept. 29, 2011, 5:37 a.m.) Review request for KDE Runtime, Dawit Alemayehu and David Faure. Description --- As of commit 2317acb1da0eefef322d9bac046187fc067cc27b (by adawit) KWallet is never used for password storage by KPasswdServer. It still reads, but never writes. This patch very roughly fixes it to get password saving in KWallet functional again. There is probably a much nicer way to fix it, but I just wanted it to work again. Diffs - kpasswdserver/kpasswdserver.cpp cc8ded2 Diff: http://git.reviewboard.kde.org/r/102729/diff/diff Testing --- Checking the Save Password box when KWallet is enabled leads to the password being saved. Thanks, Ben Cooksley
Re: The case for a kdelibs 4.8
On Thursday, 2011-09-29, Rolf Eike Beer wrote: The reason to stop master was (as far as I understand) to make the frameworks branch easily to maintain. If someone is working on 4.8 (bugfixing, features) all this has to be ported to frameworks, too. So you develop a moving target on a moving target. What about a more stricter than usual policy for additions to 4.8? Like every new feature wanted in 4.8 has to go through reviewboard for 4.8 and frameworks 5. That way the developer doing the feature work for 4.8 will also take care of the forward porting task. 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: The case for a kdelibs 4.8
On Fri, Sep 30, 2011 at 10:07 AM, Aaron J. Seigo ase...@kde.org wrote: On Thursday, September 29, 2011 14:01:50 Kevin Kofler wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. The rule so far has always been that the kdelibs version must be the same as the KDE SC version. that's not a rule anymore, and hasn't been for a while now. other than the packaging specfile changes that seem to be required in the Fedora packages, i'm not sure what the real world confusion would be. when we release apps and workspace 4.8, we'll also do a platform 4.7.x release. the release communication will not say SC 4.8 it will say Platform 4.7, Plasma Workspaces 4.8 and application updates (or something along those lines). that was not just a marketing ploy, but an attempt to align our public communication with the realities that already existed in KDE development. I am not saying this is the best solution, I am just putting out as a possible compromise. Would it be possible to just call kdelibs 4.7.8 or whatever it ends up being kdelibs 4.8, without adding any significant new features? I know you can, by KDE policy, add new features at a x.x release, but is there any requirement that you have to? I know there are numerous other issues involved so this may be a terrible idea. -Todd
Re: The case for a kdelibs 4.8
On Thursday 29 September 2011 20:01:00 Kevin Kofler wrote: But one of my points is that we need features too, not just bugfixes. Continuing 4.7.x releases solves the problem of bugfixes just fine, but entirely fails to address the issue of features. But who is (or would be) working on features in kdecore | kdeui | kio | kfile? Feel free to prove me wrong, but with most kdelibs developers working on either bugfixing or frameworks, I don't see who's left to work on features in kdelibs. I agree that e.g. plasma and nepomuk might be in a different situation though. Maybe with a proper git merge support for kdelibs master we could re-evaluate the decision to freeze it, it's less work than having to cherry-pick every fix into 3 branches. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: The case for a kdelibs 4.8
On Donnerstag 29 September 2011 18:11:12 Kevin Kofler wrote: Wait and see the chaos that will come up when users open their Help/About in Konqueror and it tells them that they're using Konqueror 4.8.0 under KDE 4.7.6. (And yes, it still says only KDE in 4.6.5, I haven't checked 4.7 or 4.8 for whether that's fixed there.) True but only in one line ans the explanation that the Dev Platform is meant, is written in About KDE. That said, I'm toying with ideas about a complete redesign of the About window for KF5. When/If I come up with a somewhat presentable mock-up, I'll post it and hopefully a programmer implements something based on that. A completely new About window will also fix legacy issues like that string. and strangely shipping Kontact 4.4.11 with SC 4.5+ was also not confusing to most users. Actually, that was (and still is) quite confusing to many users. Look at the mailing lists and forums. I really don't think it was the majority and the Kontact case is user-visible software unlike Frameworks/Platform which normal users usually do not care about. MS Office 2003 also ran on Windows 2000 and the majority of users had no problems understanding that. ;-) And we better continue to educate our users that Platform version and Workspace version does not need to match. I have yet to see any ideas for KDE Plasma Desktop 5.0 which means that maybe KPD 4.9 in summer 2012 will require KF 5.0. So unless someone completely rewrites KPD for the summer release (maybe basing it on Plasma Active) and therefore justifying a major version jump to 5.0, as a promo person I'd rather educate our users now before we see people (at worst: reviewers) complaining that KDE 5 looks just like KDE 4.8. (As a side note I also think that KDE Applications should completely lose their version number and get date-based versioning because any application can get major new features at any time – see Dolphin 2.0 in SC 4.8.) Fedora 15 actually has KDE SC 4.6.x, not 4.7. Just a few days ago someone on your mailing list claimed otherwise but whatever... that's not the main topic here.
Re: The case for a kdelibs 4.8
On Friday, September 30, 2011 04:15:51 PM Markus Slopianka wrote: (As a side note I also think that KDE Applications should completely lose their version number and get date-based versioning because any application can get major new features at any time – see Dolphin 2.0 in SC 4.8.) Today, for Kubuntu, we work very hard to package all of the KDE SC because we think it's an important value to deliver this upstream set of packages as a complete set to our users (IIRC, except for bindings we accomplished that for 4.7 even with all the package splits). If there is no more integrated release of a KDE SC, then we really don't need to worry about that and so we'll probably focus more just on stuff we use (I know the Debian KDE packagers are already planning this due to all the package splits). So I expect that one side effect of doing away with the traditional KDE release process will be less KDE software packaged in distributions. Scott K
Review Request: fix sycoca off by one
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102748/ --- Review request for kdelibs and David Faure. Description --- fixing sycoca, this time fixing the off by one in ALL the methods (not like in the previous attempt). Diffs - kdecore/sycoca/ksycocadict.cpp 4be935b Diff: http://git.reviewboard.kde.org/r/102748/diff/diff Testing --- git pull kdelibs with modifications. Compiled/installed kdelibs in the kde session (linking all the .so and programs again). None of the kde programs crashes, nor any protocol is missing. No valgrind errors (except fontconfig). Thanks, Jaime Torres Amate
Re: The case for a kdelibs 4.8
On Thursday 29 September 2011, Andras Mantia wrote: On Thursday, September 29, 2011 21:43:34 Stefan Majewsky wrote: Without judging on the other arguments which look very reasonable to me... On Thu, Sep 29, 2011 at 2:01 PM, Kevin Kofler kevin.kof...@chello.at wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. [...] ...what exactly stops you from advertising kdelibs 4.7.x as version 4.8? (And I mean advertise, so only the user-visible parts, not version numbers in .so files or whatever.) Now that would add a lot of confusion. Can the version number of kdelibs 4.7.x simply be increased to 4.8 when 4.8 is branched ? It would have only bugfixes, but it seems it would make life simpler for some people. Alex
Re: Re: The case for a kdelibs 4.8
A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure: On Thursday, September 29, 2011 11:47:22 PM Albert Astals Cid wrote: A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure: On Thursday, September 29, 2011 08:01:00 PM Kevin Kofler wrote: On Thursday 29 September 2011, Heinz Wiesinger wrote: From what I remember from the desktop summit the picture you draw here is quite an exaggeration of what is actually happening. kdelibs 4.7 is meant to be frozen for new features, but not for bugfixes. Bugfix releases of kdelibs-4.7 happenend and I'm sure will continue on happening. As for the versioning I don't see why one of those bugfix releases couldn't be rebranded as 4.8.0 if that makes things easier (that was even briefly mentioned at the release team BoF). It does not solve feature backports of course. But one of my points is that we need features too, not just bugfixes. Continuing 4.7.x releases solves the problem of bugfixes just fine, but entirely fails to address the issue of features. Even worse, features have already creeped into the 4.7 branch because they are needed and there's no 4.8 branch, so this isn't a theorectical point. Why is that bad, that is what was agreed when the freeze took place. Agreed on by who? Read this list Plan to transition to KDE Frameworks. Albert
Re: Re: The case for a kdelibs 4.8
A Divendres, 30 de setembre de 2011, Aaron J. Seigo vàreu escriure: On Thursday, September 29, 2011 23:57:56 Kevin Kofler wrote: https://git.reviewboard.kde.org/r/102175/ https://git.reviewboard.kde.org/r/102291/ https://git.reviewboard.kde.org/r/102350/ none of these are critical feature additions. they elevate the usability of libplasma and are valuable, but we've lived just fine without these features to date. if we were working on and releasing a 4.8 version of kdelibs, our users would have to wait for these features until 4.8 was released (e.g. in january) and distributions made packages available to their users (often much later than that). instead, they'll have to wait until frameworks is ready. and this code can, and should, go into libplasma in the frameworks branch today. I sincerely think you are being unfair here. The stuff you needed was merged in, and probably was more invasive than those features. You justify yourself in that it was developed before we knew 4.8 was not going to be there. I'd say that can easily qualify for Kevin too. Albert -- 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
Re: Re: The case for a kdelibs 4.8
A Divendres, 30 de setembre de 2011, Alexander Neundorf vàreu escriure: On Thursday 29 September 2011, Andras Mantia wrote: On Thursday, September 29, 2011 21:43:34 Stefan Majewsky wrote: Without judging on the other arguments which look very reasonable to me... On Thu, Sep 29, 2011 at 2:01 PM, Kevin Kofler kevin.kof...@chello.at wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. [...] ...what exactly stops you from advertising kdelibs 4.7.x as version 4.8? (And I mean advertise, so only the user-visible parts, not version numbers in .so files or whatever.) Now that would add a lot of confusion. Can the version number of kdelibs 4.7.x simply be increased to 4.8 when 4.8 is branched ? It would have only bugfixes, but it seems it would make life simpler for some people. As I already said in this thread, that is Dirk's plan as he stated in the Release Team BoF in Berlin. Albert Alex
Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?
of course this is for the frameworks thingi. On 09/30/2011 07:09 PM, Sune Vuorela wrote: On 2011-09-30, Albert Astals Cid aa...@kde.org wrote: A Divendres, 30 de setembre de 2011, Sebastian Trüg vàreu escriure: Hi lists, with frameworks in the building and Nepomuk probably going that direction already for 4.8 I would like to clean up a bit. One of these cleanup tasks targets the Soprano::Model statement signals. So far these were the only way to get informed about changes in Nepomuk - with a very bad impact on performance and bad usability. With 4.7 we already introduced a preliminary version of the Nepomuk::ResourceWatcher[1] which is now in charge of informing clients about changes. I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. Removing signals of what seems to be an existing public class/daemon is a very bad idea and you should wait until 5.0. Full ack. /Sune
Re: Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?
A Divendres, 30 de setembre de 2011, Sebastian Trüg vàreu escriure: of course this is for the frameworks thingi. Oh, sorry for the misinterpretation. Albert On 09/30/2011 07:09 PM, Sune Vuorela wrote: On 2011-09-30, Albert Astals Cid aa...@kde.org wrote: A Divendres, 30 de setembre de 2011, Sebastian Trüg vàreu escriure: Hi lists, with frameworks in the building and Nepomuk probably going that direction already for 4.8 I would like to clean up a bit. One of these cleanup tasks targets the Soprano::Model statement signals. So far these were the only way to get informed about changes in Nepomuk - with a very bad impact on performance and bad usability. With 4.7 we already introduced a preliminary version of the Nepomuk::ResourceWatcher[1] which is now in charge of informing clients about changes. I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. Removing signals of what seems to be an existing public class/daemon is a very bad idea and you should wait until 5.0. Full ack. /Sune
Re: The case for a kdelibs 4.8
Am Freitag, 30. September 2011, 10:07:27 schrieb Aaron J. Seigo: will say Platform 4.7, Plasma Workspaces 4.8 and application updates (or something along those lines). that was not just a marketing ploy, but an attempt to align our public communication with the realities that already existed in KDE development. I hope I am not the first to note that this sounds really horrible. Take this message: KDE releases 4.8: Platform and Workspaces got some spectacular changes, while applications received much polish. In a blog, this becomes YAY! KDE releases 4.8! Take your example. It becomes: Plasma 4.8 released! Well, where is KDE in that? Suddenly the community it is all about becomes a sidenote. And a newspaper will likely only see “hm, some stuff our readers won’t understand” instead of “new version of the tools from KDE!” There is a reason why Apple releases MacOSX 10.8 and not “Xcode 4.1, Apple Mach 1.3, Quartz 4.7, …” Technically it is cool to have a kmail 5.8 which depends on frameworks =5.1, but as a User I am interested in the changes KDE did for 5.8: All the changes, to Frameworks as well as to the Workspaces and the Applications. If I then decide to not use the testing frameworks, it makes me happy when an application only needs an earlier version. But do you actually think that most people can follow the info-input of having different version numbers in a release - and really remember the news? Due to 3 hours daily travel time, 40h work per week and wife and son, I won’t be able to do that in the near future, so there are likely many more people who can’t. Best wishes, Arne -- singing a part of the history of free software: - http://infinite-hands.draketo.de signature.asc Description: This is a digitally signed message part.
gamer mouse button shortcuts (LONG)
I've been inspired by the 'shortcut doc' Thread on kwin ML. This concerns mouse devices with extra buttons driving our desktop, and creating mouse-based shortcuts. SAD STORY You may recall that, many months ago, I was encouraged to try a Qt enhancement for this. Qt consumes X11 ButtonPress and ButtonRelease events for X11 button numbers greater than 9, doing nothing with them -- and NOT passing them up to the Window Manager when a programmer tells Qt to pass along the Button Events I didn't use. After a couple of 'false' starts, I had a design which could preserve binary BC; but it did not meet the time frame for the end of of Qt4 series, and I have been unable to obtain a contact a 'coach' about Qt input programming anyway / SAD STORY Back then, Aaron also gave a tentative thumbs up! to my fallback proposal: If we can't fix Qt to 'handle' ButtonPress and ButtonRelease events for the buttons which are greater than 9 (the Events can show a button as high as #31), we can still create some pretty amazing shortcut capabilities in kwin -- before QT-based Apps even have a chance to flush the events down the toilet. That is, *IF* you masters of Kwin and the KDE Workspace are willing to help me mess around with it. My Goal is to define new shortcut output commands as needed, to be at least as feature-rich as Compiz. We can provide vastly more usability, actually, by adding the the mouse button modifiers trick into the project. I know that the timeframe is short. I therefore suggest that we restrict these mouse-based shortcuts to the land of kwin 'global' and kwin-controlled window-specific rules. GUI PROPOSAL: *PART 1* Re-do our KCM module for desktop effects, using CCSM as a guide to the GUI implementation. (BTW, CCSM == CompizConfigSettingsManager. If you're not familiar with Compiz, you can play around with it in most Distros by running compiz --replace from a Konsole. You'll still be running KDE, and the only breakage I've noticed in my Distro, Mageia-1, occurs in the Panel: the KDE Panel desktop pager shows Compiz desktops, but Compiz uses virtual desktops to implement our scheme of desktops. Their design has two layers of Desktops, while we use only one. My panel pager contains only one desktop, because I'm doing all of my switching and cube-spinning is done among the more numerous virtual desktops.) In CCSM, each setting has TWO lines for defining the user's choice of input. We have only the wrench button to view/change the keyboard sequence which invokes the change (with the info button following the wrench button). Their first line implements keyboard shortcuts, almost exactly as our wrench. But their second line, with a mouse icon, implements a choice of buttons (with modifier keys) to execute the same effect. Even though the extra line take up more screen Real Estate,I like their scheme, because it separates the logic for both the user and the programmer: The keyboard shortcut, and whether it has been changed, or whether it is even enabled, is completely separate from the mouse shortcut. The row is associated with one kind of shortcut and one kind of input device, not two.) Can someone please join in this, to handle CCSM? BTW, I don't know the proper way to encode hand-off of a mouse-shortcut keyboard sequence (containing mutiple keystrokes) to a Window. *PART 2* Modify the Compiz mouse scheme to ALSO allow the buttons within the XI Version 1 mask (Raw Buttons 1-3, Left and Middle and Right) to function as 'modifier keys' for other buttons. (This is my best idea: it gives a mouse user with limited numbers of buttons a whole slew of additional virtual buttons.) For example: under my hand, it is very easy to hold down ButtonRight, the context button while doing another mouse action: scrolling Up/Down (two more Buttons), Scrolling Right/Left (two more Buttons), or pressing a side button. (I've got FOUR of them, even though Qt flushes two of them down the toilet if we ever hand them off to a Qt program.) Or pressing a top button-- I've got 3 more. For me, holding RightButton and spinning the up/down wheel would be a GREAT implementation of scroll in/scroll out. People with more flexibility could use ButtonLeft instead, or in addition to, my use of ButtonRight. For me, ButtonLeft is an easy modifier for only BackButton (AKA XButton1 which is Button #8 from X11), ForwardButton/XButton2 (Button #9), Button #10, and Button #11, Plus wheel up and wheel down (X11 Button #4 and Button #5). So, I'd end up with 5 scroll axis choices, and 12 additional, virtual buttons for invoking various effects and keyboard sequences. Most people with tilt-wheel mice would have 6 'pretty comfortable' scroll axis choices (I have a tendon problem which makes right-left with ButtonLeft a difficult combination for me. Except when typing text, I'd be able to pretty much drive my computer with just the mouse. PART 3, MAYBE: Should we re-organize
