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: 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: Re: kdelibs 4.8? What to do about GENERIC_LIB_VERSION?
A Dilluns, 3 d'octubre de 2011, Alexander Neundorf vàreu escriure:
On Monday 03 October 2011, Allen Winter wrote:
Howdy,
A lot of CMakeLists.txt use the ${GENERIC_LIB_VERSION} to set the so
versioning of their libraries. That variable is hard-coded in
kdelibs/cmake/modules/KDE4Defaults.cmake
If we rely on kdelibs-4.7 for the KDE SC 4.8 release, then all the
shared
libraries using ${GENERIC_LIB_VERSION} will be still set to 4.7. for
example the kdepimlbs kcalcore library will be versioned to 4.7.0
instead
of 4.8.0 in the KDE SC 4.8 release.
How about simply increasing the version number to 4.8 ?
This would also give the libs in kdelibs the version number 4.8, but I don't
see a problem with that.
Third time in this thread. This is Dirk's plan all along.
Albert
So... seems to me we will need a kdelibs 4.8 or perhaps we make
kdelibs/cmake into a kde-buildsystem package
We'll basically do this in the frameworks branch.
Alex
Re: Call for the next release codename to be Ritchie
A Dijous, 13 d'octubre de 2011, Ivan Čukić vàreu escriure: I guess I should have posted this to release team mailing list, but this way the topic will have more people involved. As you all (probably) know, Dennis Ritchie has passed away. In my opinion, we should somehow make tribute to him. I'm not sure the idea to name a release after him would be fitting, but that's the only thing I've came up with. You want the release team for this ;-) Albert -- Ivan
Re: [Kde-games-devel] Module layout proposal: Split kdegames-data from kdegames
A Divendres, 14 d'octubre de 2011, Stefan Majewsky vàreu escriure: [@CC: please keep discussion on k-c-d and k-g-d only] Moin moin, EXECUTIVE SUMMARY I propose to move the data files from the kdegames module into a new kdegames-data module to 1. facilitate the move of the remaining source code to Git (while a method of storing binary data files in Git efficiently is still being worked on) and 2. enable developers to fetch and compile the kdegames source without having to download the data files again. As I said before, I disagree with this, it imposes pain into regular contributors (as now I have to checkout two repos and install two instead of one and remember where things I want to commit are) in favour of the mythical drive-by contributor. And then again I do not see the benefit for the drive-by contributor since obviously he'll still need to checkout the data repository if he wants to make sure the patch he is making works. Albert
Re: Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
A Dijous, 27 d'octubre de 2011, Thiago Macieira vàreu escriure: On Thursday, 27 de October de 2011 13:32:51 Rex Dieter wrote: See also, http://bugs.kde.org/285028 ( and https://bugreports.qt.nokia.com/browse/QTBUG-22382 ) In Qt 4.8, QUrl.toLocalFile now seems, by design, to return NULL for urls lacking any scheme. Discovered this the hard way figuring out why all my audio knotifications were quiet. Since audio event sources are simple filenames, e.g. KDE-K3B-Finish-Success.ogg, and QString soundFile = soundFileURL.toLocalFile(); no longer works. Any suggestions or advice on how best to deal with this? As we discussed on IRC, any string source must be properly labelled whether they are a URL or they are a local file. They cannot be both. Personally i find it another joke in the history of Qt, saying you maintain API and ABI (that you do) but then making functions behave totally different from one version to another is just plain useless. Albert -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
A Dijous, 27 d'octubre de 2011, Thiago Macieira vàreu escriure: On Thursday, 27 de October de 2011 22:31:15 Albert Astals Cid wrote: Personally i find it another joke in the history of Qt, saying you maintain API and ABI (that you do) but then making functions behave totally different from one version to another is just plain useless. Right. So we should just not release updates, because fixing bugs changes behaviour. This is not what i meant, and you know it. But as it is obvious you do not want to have a constructive discussion, let's end it here. Albert Good thinking. Call me when you get to make such decisions. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Re: Qt 4.8 QUrl.toLocalFile behavior change, impacts to KUrl (and friends)
A Divendres, 28 d'octubre de 2011, Thiago Macieira vàreu escriure: On Friday, 28 de October de 2011 10:41:36 Sebastian Trüg wrote: So, to be honest, the bug already existed in your code if you're finding these problems now. I just made it blatantly clear, and it's been there for a year for people to see. I'm also calling right now KUrl's fromPathOrUrl a fatally flawed design. Be that as it may but the fact remains that KDE potentially does not work with Qt 4.8. Is that really a risk worth taking? I am all for fixed semantics in the methods but this seems like a problematic case. Let me repeat: the problem already existed. This just made the broken code more evident. You should fix it ANYWAY. Right, it was wrong if it had to accept user input but for internal hardcoded paths, it worked and now it does not. Albert If you had a file path of: /tmp/Who let the dogs out?.mp3 or/tmp/Mambo #5.mp3 In Qt 4.7, toLocalFile on those URLs above would return: /tmp/Who let the dogs out and /tmp/Mambo Which is quite wrong already. From Qt 4.8 on, this returns empty in all cases, showing that you parsed the URL wrongly. It should be easier to spot where you made the mistake because you don't have to use specially-crafted filenames. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Re: Request: remove libkactivites from kdelibs (in experimental/)
A Dilluns, 7 de novembre de 2011, Aaron J. Seigo vàreu escriure: On Sunday, November 6, 2011 10:29:56 Allen Winter wrote: Do you mean to remove it from the kdelibs-4.7 branch? it should definitely be removed from kdelibs-master, if it hasn't been already. KDE/4.7 and master are currently the same thing. so i'm requesting removal from both, essentially. I can see a problem with the next 4.7.x release then :-/ I mean i'm all for dropiing killing changing experimental libs, but not between 4.7.3 and 4.7.4 Maybe we should really resurrect the existence of a master 4.8? 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: Review request for KSecretsService components
A Dimarts, 8 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Again, The freeze will come in less thant two days now and I'd like to know if anyone reviewed these components. Thanks, On 10/31/2011 11:48 PM, Valentin Rusu wrote: Hello, Please be advised three repostories need review before integration into the next release: 1. /kdereview/ksecretservice 2. kdelibs branch ksecretsservice 3. /kdereview/ksecrets *1. /kdereview/ksecretservice* The first one has several subdirectories. The only relevant one is the daemon subdirectory. Other directories contents was already moved to other repositories (see below). This daemon directory contains the sources of the future kde-runtime/ksecretsserviced It needs testing but it's quite usable. *2. kdelibs branch ksecretsservice* kdelibs/kdeui/ksecretsservice This is the API KDE applications will be supposed to use instead of KWallet class. Tools listed below already use this API. This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Or is this API for more complex apps like kwalletmanager? My comments on the kdelibs API: - ksecretsservice/ksecretsservicecodec.h * Seems to be installed but has no documentation at all * Uses references for output parameters when KDE/Qt usually uses pointers * Does not use d-pointers thus maintaining ABI is going to be difficult - ksecretsservice/ksecretsservicecollection.h * I miss a note saying who belongs the ownsership of all those job that come as result of the getters. Do I have to delete them? * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter * There are a few of spacing glitches, e.g. const QVariantMap collectionProperties = QVariantMap(), const WId promptParentWindowId =0 ); * There are a few not implemented signals - ksecretsservice/ksecretsservicedbustypes.h Contains a plain struct and some inline functions, what if those have to change? - ksecretsservice/ksecretsserviceitem.h * Same question about ownership of jobs - ksecretsservice/ksecretsserviceitemjobs.h * Without having at all a clue on what it is used for, i miss a note saying to who belongs the ownership of the SecretItem passed to the constructor and returned in the secretItem() function, i.e. do i have to delete it myself? * SecretItemJob does not have a d-pointer * void finished( ItemJobError, const QString msg =); should probably be void finished( ItemJobError, const QString msg = QString()); - ksecretsservice/ksecretsservicesecret.h Is installed and has no documentation Albert kdelibs/kdeui/util/kwallet.cpp Contains code depending on a configuration flag that directs calls to ksecretsserviced instead of kwalletd, via the new API. *3. /kdereview/ksecrets* Contains several tools in a less or more mature state: a. kwl2kss - tool to import kwallet files to ksecretsservice, b. ksecrets - tool to list the contents of a ksecretsservice collection (e.g. wallet), c. kio - KIO slave in a just started state, intended to show collections in konqueror or dolphin, d. secretsync - this was the tool I initially wanted to do for KWallet, but drought me into ksecretsservice :-) It's half way implemented. The mandatory components for next release would be 1, 2, 3 (a, b), the others may wait, but releasing them may cause no harm if communication is done right (I'll take care of that). Thanks for your comments (any comments), -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet-hasFolder( KPdf ) ) wallet-createFolder( KPdf ); wallet-setFolder( KPdf ); wallet-readPassword( walletKey, retrievedPass ) * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter_Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Of course that is a minor thing and won't complain too much if you decide to disagree with me ;-) Albert
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: Hello Albert, Thanks for the thourough review. On 11/09/2011 03:26 PM, Albert Astals Cid wrote: This is scary, last time i used kwallet, i had to add a single line, and now there are like a billion of classes? Welcome to the asynchronous jobs world. I had the same opinion at start. And, to be honest, that's why it takes so long to implement, as I'm not working on it only during my spare time. Are you saying you don't have anything as simple as this in the new API? QString walletName = KWallet::Wallet::NetworkWallet(); KWallet::Wallet *wallet = KWallet::Wallet::openWallet(walletName, parentwid); if ( !wallet-hasFolder( KPdf ) ) wallet-createFolder( KPdf ); wallet-setFolder( KPdf ); wallet-readPassword( walletKey, retrievedPass ) Yes, your code isn't asynchrounous ! (boo) Yeah well, kparts gives you virtual bool openUrl( const KUrl url ); With that signature you are forced to either use synchronous code or create a nested event loop, pick your poison. Well, I don't fully agree with this point of view, but in Randa they managed to convince me about the benefits. Take a look inside kwallet.cpp class to see how this new API should be used. Another example is the ksecrets API inside kdereview/ksecrets repository. This answer makes me really scared in that it is not going to be 5 lines :-/ Ok, now i've looked at the API and I am not sure i like it, particulary nonQtlike seems the way of searching things by passing a map with a key/value structure of what you want to find. I can see that it is very flexible, but string based api end up with people writing key instead of Key and they lose days debugging why it fails. Also i'm a bit confused about the docu of SearchCollectionItemsJob * searchItems( const StringStringMap attributes ); it says * KSecretsService uses overall the following standard attributes: * Label : item's or collection's label so i understand that Label is the only key of the map that you can use, and then the example says * StrinStringMap attrs; * attrs[Key] = ; and uses Key ? Does this mean Key is a valid attribute too and should be documented? Or should it say Label? Or i totally misunderstood the documentation? Also note it says StrinStringMap, missing g. Albert
Re: Re: Review request for KSecretsService components
A Dijous, 10 de novembre de 2011, Valentin Rusu vàreu escriure: On 11/10/2011 01:00 AM, Valentin Rusu wrote: On 11/10/2011 12:48 AM, Albert Astals Cid wrote: * createItem falls in the let's use a bool instead of an enum because it just have two values trap for the replace parameter Well, I don't agree. When presenting a new item to the collection, you should specify to replace existing item or not. Yes/No is boolean for me. That is the problem, that a boolean is Yes/No, and then you end up with a call that says foo-createItem(label, attributes, mySecret, false); And it seems you do not want to create the item :D while foo-createItem(label, attributes, mySecret, DoNotReplace); is much more obvious. More on my side at http://wiki.qt-project.org/API_Design_Principles#The_Boolean_Parameter _Trap and http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html Ok, I see. I'll change that. Well, In fact I changed my mind, as the enum must be a member of Collection class, but required to be used in the create job and nested enums cannot be forward declared. So that'll require to move the enum outside of the Collection class, leading to even uglier code. There is a solution for this, the CreateCollectionItemJob constructor should accept a CreateCollectionItemJobPrivate instead of all the params (since i understand it does not make sense for me creating one directly and I will only get one thought Collection::createItem (reason to make it private too?)). This way you do not need a replace member in the constructor since Collection passes the CreateCollectionItemJobPrivate directly. Probably the same argument for making the constructor private for all the other jobs applies too. Albert So I'll stay with the boolean, wich also corresponds to the freedesktop.org dbus interfaces spec, btw. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Frameworks mailing list
In case someone is interested since it has never mentioned in this list, there is a frameworks mailing list at kde-frameworks-devel https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Albert
Re: Re: Frameworks mailing list
A Dimecres, 16 de novembre de 2011, Thomas Friedrichsmeier vàreu escriure: On Wednesday 16 November 2011, Albert Astals Cid wrote: In case someone is interested since it has never mentioned in this list, there is a frameworks mailing list at kde-frameworks-devel https://mail.kde.org/mailman/listinfo/kde-frameworks-devel So why have this discussion on a separate list, at all? Isn't that just the sort of topic that kde-core-devel is for? Have no idea, I just discovered the mailing list yesterday minutes before sending the e-mail. Albert Just wondering... Thomas
Re: Re: Frameworks mailing list
A Dijous, 17 de novembre de 2011, Aaron J. Seigo vàreu escriure: On Wednesday, November 16, 2011 09:48:15 Thomas Friedrichsmeier wrote: On Wednesday 16 November 2011, Albert Astals Cid wrote: In case someone is interested since it has never mentioned in this list, there is a frameworks mailing list at kde-frameworks-devel https://mail.kde.org/mailman/listinfo/kde-frameworks-devel So why have this discussion on a separate list, at all? Isn't that just the sort of topic that kde-core-devel is for? i think this already came up once on this mailing list? maybe not.. in any case: the concern was that kde-core-devel is too prone to low-signal discussion, making communication and coordination difficult. those who started working on frameworks wanted somewhere they could coordinate in a high signal environment. i was not sure i agreed with that approach, but i have to say that the last few threads on this topic on k-c-d have supported their point :( This sounds like a If you are going to disagree we don't want you in mantra, which is kind of worrying. Albert meanwhile, everyone on frameworks is also on k-c-d and frameworks is an open list ... -- 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: Review Request: Provide extra options for date keyword display in KDateComboBox
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/#review8351 --- This patch modifies the behaviour, maybe it is better if you change KDateComboBox::NoneKeyword to KDateComboBox::NoNoneKeyword And adapt the if accordingly? This way there is no behaviour change at all and makes old users still work. - Albert Astals Cid On Nov. 10, 2011, 12:36 a.m., David Jarvie wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103103/ --- (Updated Nov. 10, 2011, 12:36 a.m.) Review request for kdelibs and John Layt. Description --- KDateComboBox provides the option to display a list of date keywords with the date picker popup. These keywords currently show dates in the past, present and future, together with a no date item. The no date item is a particular problem since not only is it redundant - since there is already a button in the line edit to clear the date value - but I suspect that many applications will not accept a blank date as valid input. This patch adds two new enum values to allow applications to select which of these date keywords are displayed: one enum value shows the no date item which is now not shown by default, and another enum value hides dates in the past. Currently in KAlarm, which I maintain, the display of date keywords is disabled because dates in the past and blank dates are not valid values to enter, and it would be confusing to users to offer them as options. This patch will make it possible to display only present and future date keywords, which will enable it to make use of date keywords. Diffs - kdeui/widgets/kdatecombobox.h 63bf52f kdeui/widgets/kdatecombobox.cpp fc239bc Diff: http://git.reviewboard.kde.org/r/103103/diff/diff Testing --- Tested in KAlarm. Thanks, David Jarvie
Re: adding a runtime dependency into KDELIBS
El Dimecres, 23 de novembre de 2011, a les 00:00:29, Alex Fiestas va escriure: We're in the process of merging a review which will partly fix the sad situation of MTP/MPI/iPod devices in libsolid, the review I'm talking about is: https://git.reviewboard.kde.org/r/103028/ This as far as I know was (is) working with the linux-deprecated HAL backend, so is something we urge to fix. This patch adds support for media-player-info which is basically what replaces some features HAL has in the new u* stuff. So, Can I give the ship it for this patch? can we add an optional runtime dependency to kdelibs 4.7.x ? I don't see this adding any kind of dependency from the POV of code, that is, it does not do qprocess nor the likes, so can you explain what the optional runtime dependency means here? Also Kevin's code looks like copied/duplicated aka bad stuff. Albert Thanks.
Re: adding a runtime dependency into KDELIBS
El Dijous, 24 de novembre de 2011, a les 15:57:22, Alex Fiestas va escriure: So, do have I have green light to give the ship it to this patch? Thanks and sorry for the mess of me not explaining :p From what i can see it is a bug fix, it changes some code in solid and will not break horribly or work worse for those of us that to not have that dependency installed. So if you are fine living with copied code from somewhere else, go for it. Albert
Re: Hunspell offering Hebrew by default
El Divendres, 2 de desembre de 2011, a les 18:46:42, Steven Sroka va escriure: Just a question here. Why does Hunspell install the Hebrew dictionary by default? I'm running Chakra and I noticed that I had the option in System Settings-Locale-Spell Checker to use Hebrew even though I couldn't find a Hebrew package installed. Later I found out that the main Hunspell package offered the Hebrew dictionary. I'm just wondering because it seems out of place for an english installation. This message is out of topic in this list, we do not maintain hunspell nor chakra. Please find a more appropiate forum for this discussion. Cheers, Albert
Re: Review Request: Add git support to kdesdk: create_tarball.rb
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6842/#review10511 --- Ship it! The changes seem very minor, and from what i can see they will not break the svn support, so just go for it if it works for you. We can fix any new issues in git support as they arise. - Albert Astals Cid On Nov. 29, 2011, 4:42 p.m., Kåre Särs wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6842/ --- (Updated Nov. 29, 2011, 4:42 p.m.) Review request for kdelibs and Release Team. Description --- This patch adds git support to create_tarball.rb in kdesdk. The patch adds two options to the ini file. The first one (gitModule) indicates that the module is located in git and the second optional parameter (gitTag) defines which tag to use for creating the release. (there is no group for kdesdk or extragear) Diffs - trunk/KDE/kdesdk/scripts/createtarball/config.ini 1266277 trunk/KDE/kdesdk/scripts/createtarball/create_tarball.rb 1266277 Diff: http://svn.reviewboard.kde.org/r/6842/diff/diff Testing --- Thanks, Kåre Särs
Re: Review Request: optimize kcolorscheme consting time: avoid calculating luma for the same colors multiple times
On Dec. 6, 2011, 5:58 p.m., Nick Shaforostoff wrote: I have an account called shaforo. i could push to kdepimlibs with it, but i couldn't push to kdelibs. is it because of lack of permissions? Alexander Potashev wrote: You need to clone the `kdelibs` repo from `g...@git.kde.org:kdelibs.git`. Check this in `kdelibs/.git/config` on your machine. kdelibs master is frozen because of the frameworks effort. You either commit it to the frameworks branch and wait until it's released or convince us this is a bugfix (which seems to be) and commit it to the 4.7 branch. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103348/#review8762 --- On Dec. 6, 2011, 5:53 p.m., Nick Shaforostoff wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103348/ --- (Updated Dec. 6, 2011, 5:53 p.m.) Review request for kdelibs. Description --- pretty straightforward and small optimization of kde apps startup time: avoid calculating luma for the same colors multiple times. callgrind shows it is called 4503 times instead of 12087 at startup of kwrite, which is 1.5%. Diffs - kdeui/colors/kcolorutils.cpp efe8cdd Diff: http://git.reviewboard.kde.org/r/103348/diff/diff Testing --- kwrite starts fine with the new kdeui lib Thanks, Nick Shaforostoff
Review Request: Make the action names of KRecentFilesAction not be extremely long
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103360/ --- Review request for kdelibs and David Faure. Description --- Cut the names of KRecentFilesAction to occupy as maximum 3/4 of screen space This addresses bug 288473. http://bugs.kde.org/show_bug.cgi?id=288473 Diffs - kdeui/actions/krecentfilesaction.cpp 190b271 Diff: http://git.reviewboard.kde.org/r/103360/diff/diff Testing --- Tried with short names, names that go inside the first if part and names that go inside the second if part, everything looks nice Thanks, Albert Astals Cid
Re: git and artworks issues
El Dimarts, 20 de desembre de 2011, a les 20:18:17, Dirk Mueller va escriure: On Tuesday 20 December 2011, Davide Bettio wrote: As every year some artworks are changed according to the new default desktop background. This year I noticed some problems: 1) kdm and ksplash default theme is part of kde-workspace. I need to update both, but if I do that I will have to commit about 20/30 MiB of PNGs making git clones bigger. Thats life, you need to push it there. We can decide to move it to other places after 4.8.0, but now it is a bit too late. 2) I need to update kdeui/about backgrounds, but If I do that I will change backgrounds also for the KDE 4.7 branch. There are two possibilities: a) create a kdelibs KDE/4.8 branch for this purpose. (plus the patch to make kdelibs 4.7 actually look like KDE 4.8, which I currently apply to the tarballs only (in kde-common/release/make-kdelibs-4.8.diff) Yes please, create a KDE/4.8 branch too for kdelibs. Albert b) add a tarball of artwork that I need to unpack in kdelibs prior to creating the actual release tarball to kde-common/release/* as well) For me, it would make most sense to create a KDE 4.8 branch in kdelibs, but I would like to have more input before I create the branch. Any opinions on this matter? Thanks, Dirk ___ release-team mailing list release-t...@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: More devices into the Shortcut system...
El Divendres, 23 de desembre de 2011, a les 14:06:27, todd rme va escriure: On Fri, Dec 23, 2011 at 12:57 AM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 20 de desembre de 2011, a les 21:48:30, Rick Stockton va escriure: It is time for us to Fish, or Cut Byte on two alternative ways to introduce Mouse-Oriented Shortcuts into Qt5 and KDE-Next: Todd RME has been suggesting a new design- oriented around DBUS. Unfortunately, I don't know how to do that coding. Todd, if your design gets a more favorable review from THIS group, within the next few days, I'll try to assist you in your work (as best as I can; I'm definitely not the brightest person here.) As an alternative, I'm suggesting the idea of enhancing one or two of the existing classes: I'd prefer to enhance the current QShortCutEvent and QShortCut scheme, so that they can include Mouse Button events within a QKeySequence. (This will including the possibility of _only_ one or more Mouse Buttons, with no keyboard event at all.) If that proves difficult, I could create new Classes to do this-- but I think I can use the 'hasExtendedInfo' trick which one of the smart Qt guys has used to handle a variety of Signatures in the QtMouseEvent() code. I can work with *this* stuff on my own. Please give opinions soon, as we have only 3-5 weeks before the Qt5 API goes into soft freeze. After we have Mouse Buttons done, the same design could be extended to handle other input devices (joystick, multitouch, and so on.) After reading this mail i feel like i don't have all the information to give an opinion since i did not get any pointer to learn what is the Todd RME DBUS design. Albert Please take a look here: https://bugs.kde.org/show_bug.cgi?id=171295 Or here: http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-d evice.html Those are two longs walls of text :D The short version of the idea is to extend the existing dbus-based keyboard shortcut system to allow developers to support other devices besides just keyboards. Users would be able to install plug-ins that provide button press events from other devices besides just keyboards. The dbus service would be very simple and generic, just providing a way to register or unregister devices and receive button press events from the plugins. Things like configuring devices, deciding how to name the button presses, making sure devices of a particular type (like multiple keyboards) don't conflict, and other such issues would be handled by the plugins in whatever way is appropriate for the device. The plugins wouldn't have to be physical devices, either. They could be things like voice recognition (such as simon), time-based triggers, even online signals. If someone wants to provide shortcut events for something, they just need to write the appropriate plugin. Of course none of the plugins would actually do anything unless the user specifically associates an event with a shortcut, and button presses would be tied to individual plugins so no plugin could steal the shortcuts of another plugin. The idea would be that systems like kremotecontrol, simon, even games looking to use joysticks buttons, could all work through the same interface, instead of needing the half-dozen or so radically different shortcut systems and user interfaces we have now. Initially (i.e. for frameworks 5) this could all be behind-the-scenes changes. Basically just create the dbus interface and port the keyboard handler to use it. Once that is done, support for additional devices and changes in the gui to support them could come later. Ok, so after half reading the walls of text and this email what i think that actually what you and Rick suggest are different but not exclusive, Rick suggests improving existing Qt classes so they can handle a few more cases, you suggest creating a new plugabble framework to handle everything, if i was to choose i'd choose both :D But obviously i'm not the one choosing since i'm not the one doing the coding nor I am an expert in the field. Cheers, Albert -Todd
Re: Review Request: Add KFontDialog-setSampleText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/#review9405 --- As far as i understand, this is new api and has to go into frameworks only, not 4.8 since that's basically just a bugfixed 4.7.x - Albert Astals Cid On Dec. 8, 2011, 4:11 a.m., Kurt Hindenburg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/ --- (Updated Dec. 8, 2011, 4:11 a.m.) Review request for kdelibs. Description --- Currently there is no way to change the sample text in KFontDialog. I would like to change the sample text in Konsole to display characters that may appear similar in some fonts (iIlLoO0). Diffs - kdeui/fonts/kfontdialog.h 371345e kdeui/fonts/kfontdialog.cpp efd6a35 Diff: http://git.reviewboard.kde.org/r/103357/diff/diff Testing --- Compiled on master branch and testing in Konsole. Thanks, Kurt Hindenburg
Re: Review Request: Port shutdown dialog to QML
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103621/#review9516 --- Some of your QtQuick imports are 1.0 and some others 1.1, i guess some consistency there would be nice You need to extract the i18n messages from the qml files And having the keyboard not working seems like a huge regression for my own usecase ;-) ksmserver/CMakeLists.txt http://git.reviewboard.kde.org/r/103621/#comment7802 no variable for kdeclarative? ksmserver/shutdowndlg.h http://git.reviewboard.kde.org/r/103621/#comment7803 make theme const , not just - Albert Astals Cid On Jan. 3, 2012, 5:34 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103621/ --- (Updated Jan. 3, 2012, 5:34 p.m.) Review request for KDE Base Apps and KDE Runtime. Description --- Port the shutdown dialog to QML. Two QML themes are included: default, which mimics the current shutdown dialog look fell, and countour, which is used in Plasma Active. Diffs - ksmserver/CMakeLists.txt 295b96e ksmserver/shutdown.cpp 7fd1e11 ksmserver/shutdowndlg.h e5f0942 ksmserver/shutdowndlg.cpp a09a1a7 ksmserver/themes/contour/ContourButton.qml PRE-CREATION ksmserver/themes/contour/main.qml PRE-CREATION ksmserver/themes/contour/metadata.desktop PRE-CREATION ksmserver/themes/default/ContextMenu.qml PRE-CREATION ksmserver/themes/default/KSMButton.qml PRE-CREATION ksmserver/themes/default/MenuItem.qml PRE-CREATION ksmserver/themes/default/main.qml PRE-CREATION ksmserver/themes/default/metadata.desktop PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103621/diff/diff Testing --- Works in Plasma Active Two using MeeGo image and KDE SC 4.8. It does not work in 4.7.x because the patch requires kde-runtime 4.8's declarative imports. There is still one bug left: keyboard nagivation works with TAB, BACKSPACE, and arrow-keys, but only the TAB key works at first. You always have to press the TAB key at least once for the other keys to work for navigation. The first TAB press only activates the navigation, you still need a second press to actually move focus to the next element. Screenshots --- http://git.reviewboard.kde.org/r/103621/s/400/ Thanks, Lamarque Vieira Souza
ktouchpadenabler moved to kdereview
My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. Cheers, Albert
Re: ktouchpadenabler moved to kdereview
El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). Albert Please ask Michael Jansen or Lubos Lunak for help integrating it. Cheers, Albert
Re: Review Request: Port shutdown dialog to QML
On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote: Some of your QtQuick imports are 1.0 and some others 1.1, i guess some consistency there would be nice You need to extract the i18n messages from the qml files And having the keyboard not working seems like a huge regression for my own usecase ;-) Lamarque Vieira Souza wrote: All QtQuick imports in Contour theme are 1.0, all QtQuick imports in default theme are 1.1. Why Contour theme should use 1.1 if it is not required? They are independent implementations. How do I extract i18n messages in qml files? Is there any guide for that? The keyboard works, you just need to press the TAB key once to activate it, then you can use the TAB, SHIFT+TAB and arrow-keys to navigate and ENTER or BAR to click the button. I have not figure out why the first TAB is required. Christoph Feck wrote: Try Qt::StrongFocus, maybe it forces activation of the view. Lamarque Vieira Souza wrote: It did not work but I have found what I did wrong, or more precisely forgot to do. In the original implementation the focus was on the dialog, but now the focus must go to the QML view. Not it works. How do I extract i18n messages in qml files? Just add your *.qml files to the Messages.sh since the syntax is like the C++ one it shall hopefully work - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103621/#review9516 --- On Jan. 4, 2012, 5:03 p.m., Lamarque Vieira Souza wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103621/ --- (Updated Jan. 4, 2012, 5:03 p.m.) Review request for KDE Base Apps and KDE Runtime. Description --- Port the shutdown dialog to QML. Two QML themes are included: default, which mimics the current shutdown dialog look fell, and countour, which is used in Plasma Active. Diffs - ksmserver/shutdowndlg.cpp a09a1a7 ksmserver/shutdowndlg.h e5f0942 ksmserver/shutdown.cpp 7fd1e11 ksmserver/CMakeLists.txt 295b96e ksmserver/themes/contour/ContourButton.qml PRE-CREATION ksmserver/themes/contour/main.qml PRE-CREATION ksmserver/themes/contour/metadata.desktop PRE-CREATION ksmserver/themes/contour/screenshot.png PRE-CREATION ksmserver/themes/default/ContextMenu.qml PRE-CREATION ksmserver/themes/default/KSMButton.qml PRE-CREATION ksmserver/themes/default/MenuItem.qml PRE-CREATION ksmserver/themes/default/main.qml PRE-CREATION ksmserver/themes/default/metadata.desktop PRE-CREATION ksmserver/themes/default/screenshot.png PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103621/diff/diff Testing --- Works in Plasma Active Two using MeeGo image and KDE SC 4.8. It does not work in 4.7.x because the patch requires kde-runtime 4.8's declarative imports. There is still one bug left: keyboard nagivation works with TAB, BACKSPACE, and arrow-keys, but only the TAB key works at first. You always have to press the TAB key at least once for the other keys to work for navigation. The first TAB press only activates the navigation, you still need a second press to actually move focus to the next element. Screenshots --- http://git.reviewboard.kde.org/r/103621/s/400/ Thanks, Lamarque Vieira Souza
Re: Review Request: kcm-grub2
El Dimarts, 3 de gener de 2012, a les 16:47:51, Konstantinos Smanis va escriure: Hi, kcm-grub2 has been in kdereview for months. It would be great if it could be moved back or forth. I am planning a new release soon, I wouldn't like to abuse kdereview. If noone raised extra comments and you fixed the ones that were made there is no need for an extra approval, just move it to the extragear module you want and that's it. Albert Regards, Konstantinos
Re: Review Request: kcm-grub2
El Dimecres, 4 de gener de 2012, a les 20:32:11, Konstantinos Smanis va escriure: On Wed, Jan 4, 2012 at 20:15, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 3 de gener de 2012, a les 16:47:51, Konstantinos Smanis va escriure: Hi, kcm-grub2 has been in kdereview for months. It would be great if it could be moved back or forth. I am planning a new release soon, I wouldn't like to abuse kdereview. If noone raised extra comments and you fixed the ones that were made there is no need for an extra approval, just move it to the extragear module you want and that's it. Albert Regards, Konstantinos Perhaps a sysadmin could do it? Perhaps if you create the proper request in the place syadmins look for work ;-) Albert P.S: https://bugs.kde.org/enter_sysadmin_request.cgi Konstantinos
Re: Review Request: Port shutdown dialog to QML
On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
ksmserver/CMakeLists.txt, line 57
http://git.reviewboard.kde.org/r/103621/diff/1/?file=45363#file45363line57
no variable for kdeclarative?
Lamarque Vieira Souza wrote:
There is one in shutdowndlg.cpp, in KSMShutdownDlg's constructor.
I mean cmake variable like ${SOMETHING_SOMETHING}
- Albert
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103621/#review9516
---
On Jan. 4, 2012, 6:41 p.m., Lamarque Vieira Souza wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103621/
---
(Updated Jan. 4, 2012, 6:41 p.m.)
Review request for KDE Base Apps and KDE Runtime.
Description
---
Port the shutdown dialog to QML. Two QML themes are included: default, which
mimics the current shutdown dialog look fell, and countour, which is used
in Plasma Active.
Diffs
-
ksmserver/CMakeLists.txt 295b96e
ksmserver/Messages.sh 0aa8bab
ksmserver/shutdown.cpp 7fd1e11
ksmserver/shutdowndlg.h e5f0942
ksmserver/shutdowndlg.cpp a09a1a7
ksmserver/themes/contour/ContourButton.qml PRE-CREATION
ksmserver/themes/contour/main.qml PRE-CREATION
ksmserver/themes/contour/metadata.desktop PRE-CREATION
ksmserver/themes/contour/screenshot.png PRE-CREATION
ksmserver/themes/default/ContextMenu.qml PRE-CREATION
ksmserver/themes/default/KSMButton.qml PRE-CREATION
ksmserver/themes/default/MenuItem.qml PRE-CREATION
ksmserver/themes/default/main.qml PRE-CREATION
ksmserver/themes/default/metadata.desktop PRE-CREATION
ksmserver/themes/default/screenshot.png PRE-CREATION
Diff: http://git.reviewboard.kde.org/r/103621/diff/diff
Testing
---
Works in Plasma Active Two using MeeGo image and KDE SC 4.8. It does not work
in 4.7.x because the patch requires kde-runtime 4.8's declarative imports.
TODO:
. implement something equivalent to QLabel's accelerators.
. check if there are bugs in bugs.kde.org that could be solved by this patch.
Screenshots
---
http://git.reviewboard.kde.org/r/103621/s/400/
Thanks,
Lamarque Vieira Souza
Re: ktouchpadenabler moved to kdereview
El Dimecres, 4 de gener de 2012, a les 20:15:27, Thomas Lübking va escriure: Am 04.01.2012, 18:51 Uhr, schrieb Albert Astals Cid aa...@kde.org: I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). I guess what Christoph meant was to avoid having another XSelect daemon. It's not another daemon, it's a kded module. I've not seen the code (and deleted the original mail in case it's linked there - winkwink) Do i need to say that ktouchpadenabler is in kde:ktouchpadenabler? but my approach would be to have a tool to be invoked when something happens, rather than adding yet another keyboard event listening daemon bound to a very specific event. That'd mean doing udev stuff and the like probably, i'll pass on that. Actually I've a setup a udev rule to simply fix things whenever I un/plug a mouse (not sure what or where that particular key is) That has nothing to do with what ktouchpadenabler does. Albert Cheers, Thomas
Re: ktouchpadenabler moved to kdereview
El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). IMHO this isn't about the number of lines of code, but about the runtime performance (how many process to wake up when pressing a key). khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). Albert
Re: ktouchpadenabler moved to kdereview
El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va escriure: Em Wednesday 04 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). IMHO this isn't about the number of lines of code, but about the runtime performance (how many process to wake up when pressing a key). khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt- and.html) you said your patch against Qt was accepted. I thought your patch would add XF86XK_TouchpadToggle support to Qt and then there would be no need for this kded module. If we patch Qt we could add the support for a key as one #define and one enumerate per key in kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also created the patch for that, it works for me. I have never sent my patch to Qt because the upstream bug (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for almost two years now, nobody seems to care about the bug. My patch patch was accepted in Qt5, noone is going to accept stuff like that for Qt 4.8. As far as i can see my patch already includes your changes. Albert My question is: since you know how to send patches to Qt's repository wouldn't be better just send my patch upstream (it is here https://bugs.kde.org/show_bug.cgi?id=182672) and just apply my second patch to kdelibs? My second patch is attached.
Re: ktouchpadenabler moved to kdereview
El Dijous, 5 de gener de 2012, a les 00:56:38, David Faure va escriure: On Thursday 05 January 2012 00:17:33 Albert Astals Cid wrote: khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. Ah, OK. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). Sounds like the Qt5 solution is clear then: adding a Qt key for that X keysym. Should be pretty forward. That's done, but we don't use Qt5 yet ;-) Albert
Re: ktouchpadenabler moved to kdereview
El Dijous, 5 de gener de 2012, a les 01:36:08, Christoph Feck va escriure: On Thursday 05 January 2012 00:17:33 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle [...] Albert Bummer, you are right, didn't think of that. Still I see no reason why it shouldn't be part of kdebase, so make sure you get this into 4.9 feature plan. To me, this sounds like basic functionality, similar to brightness or volume keys on notebooks. They should just work. And I am pretty sure all those keys work on GNOME out-of-the-box. Until then, extragear is fine, if you do not want it in playground. I would suggest extragear/base, that's where the wacomtablet stuff lives, too. Ok, i'll move it to extragear/base and then make a release and then move it somewhere in kdebase, is that fine with you? Albert Christoph Feck (kdepepo) KDE Quality Team
Re: ktouchpadenabler moved to kdereview
El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va escriure: Em Thursday 05 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va escriure: Em Wednesday 04 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). IMHO this isn't about the number of lines of code, but about the runtime performance (how many process to wake up when pressing a key). khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt- and.html) you said your patch against Qt was accepted. I thought your patch would add XF86XK_TouchpadToggle support to Qt and then there would be no need for this kded module. If we patch Qt we could add the support for a key as one #define and one enumerate per key in kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also created the patch for that, it works for me. I have never sent my patch to Qt because the upstream bug (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for almost two years now, nobody seems to care about the bug. My patch patch was accepted in Qt5, noone is going to accept stuff like that for Qt 4.8. As far as i can see my patch already includes your changes. Ok then, I have heard Qt 4 is done from other sources as well. You should change ktouchpadenabler to something else since probably there are other keys that it can also handle. For example the other four keys mentioned in https://bugreports.qt.nokia.com//browse/QTBUG-8956. I am not sure what XF86New has to do with touchpad handling, can you clarify? Albert
Re: ktouchpadenabler moved to kdereview
El Dijous, 5 de gener de 2012, a les 21:59:10, Lamarque V. Souza va escriure: Em Thursday 05 January 2012, Albert Astals Cid escreveu: El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va escriure: Em Thursday 05 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va escriure: Em Wednesday 04 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). IMHO this isn't about the number of lines of code, but about the runtime performance (how many process to wake up when pressing a key). khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-qt- and.html) you said your patch against Qt was accepted. I thought your patch would add XF86XK_TouchpadToggle support to Qt and then there would be no need for this kded module. If we patch Qt we could add the support for a key as one #define and one enumerate per key in kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also created the patch for that, it works for me. I have never sent my patch to Qt because the upstream bug (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for almost two years now, nobody seems to care about the bug. My patch patch was accepted in Qt5, noone is going to accept stuff like that for Qt 4.8. As far as i can see my patch already includes your changes. Ok then, I have heard Qt 4 is done from other sources as well. You should change ktouchpadenabler to something else since probably there are other keys that it can also handle. For example the other four keys mentioned in https://bugreports.qt.nokia.com//browse/QTBUG-8956. I am not sure what XF86New has to do with touchpad handling, can you clarify? That is my point, your daemon enables unknown keysyms so that they can ben be used in KDE programs. It can be more generic than just enabling touchpad, No, my daemon is for enabling the touchpad, that's all. If you want to do something else, feel free to do it, but making my daemon do other stuff than enabling the touchpad will make the code more complex to the point that I no longer want to develop that, if you want to fork my code and take ownership of that more complex code to support more stuff, be my guest. there are other keys users want to enable. For example your daemon handles only the XF86XK_TouchpadToggle keysym, I think it should also handle XF86XK_TouchpadOn
Re: ktouchpadenabler moved to kdereview
El Divendres, 6 de gener de 2012, a les 01:09:40, Albert Astals Cid va escriure: El Dijous, 5 de gener de 2012, a les 21:59:10, Lamarque V. Souza va escriure: Em Thursday 05 January 2012, Albert Astals Cid escreveu: El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va escriure: Em Thursday 05 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V. Souza va escriure: Em Wednesday 04 January 2012, Albert Astals Cid escreveu: El Dimecres, 4 de gener de 2012, a les 23:40:26, David Faure va escriure: On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote: El Dimecres, 4 de gener de 2012, a les 01:53:13, Christoph Feck va escriure: On Wednesday 04 January 2012 00:28:11 Albert Astals Cid wrote: My little kded daemon that listens to XF86XK_TouchpadToggle and enables disables the touchpad accordingly has been moved to kdereview. My plan is moving it to extragear, not really sure if -base or -utils. The code doesn't have a kcm or any kind of configuration since it is designed to just work. I'd appreciate any review or suggestion over it. I cannot test it because I have no touchpad, but if it is supposed to just work without any UI, I suggest to just add it to khotkeys or kaccel daemon (whichever of them is used for global shortcuts), so that we do not filter global X11 keyboard events twice. I don't really see any point in doing that, nothing can be shared between them and the existing ktouchpadenabler so instead of one simple codebase (166 lines with 20 of headers) you end up adding more complexity to existing programs (probably integrating the code in the existing programs would be more than 166 lines). IMHO this isn't about the number of lines of code, but about the runtime performance (how many process to wake up when pressing a key). khotkeys is already a kded module, so there won't be no more processes waking up now than before by adding a new kded module. kglobalaccel seems quite suitable indeed, no? It would, if Qt had a key for XF86XK_TouchpadToggle, as it doesn't i'd need to introduce a big ignore all the workflow of kglobalaccel for this special key since kglobalaccel only understands Qt keys (see KGlobalAccelImpl::grabKey). In your blog (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day- qt- and.html) you said your patch against Qt was accepted. I thought your patch would add XF86XK_TouchpadToggle support to Qt and then there would be no need for this kded module. If we patch Qt we could add the support for a key as one #define and one enumerate per key in kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime overhead. I also created the patch for that, it works for me. I have never sent my patch to Qt because the upstream bug (https://bugreports.qt.nokia.com//browse/QTBUG-8956) has been ignored for almost two years now, nobody seems to care about the bug. My patch patch was accepted in Qt5, noone is going to accept stuff like that for Qt 4.8. As far as i can see my patch already includes your changes. Ok then, I have heard Qt 4 is done from other sources as well. You should change ktouchpadenabler to something else since probably there are other keys that it can also handle. For example the other four keys mentioned in https://bugreports.qt.nokia.com//browse/QTBUG-8956. I am not sure what XF86New has to do with touchpad handling, can you clarify? That is my point, your daemon enables unknown keysyms so that they can ben be used in KDE programs. It can be more generic than just enabling touchpad, No, my daemon is for enabling the touchpad, that's all. If you want to do something
Review Request: Write to the correct xmlFile in KToolBar::Private::slotContextShowText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103812/ --- Review request for kdelibs and David Faure. Description --- KToolBar::Private::slotContextShowText() was assuming that the xmlgui file it had to write was KGlobal::mainComponent.componentName() + ui.rc; which is obviously wrong since we have a setXMLFile function for a reason. I tried using xmlguiClient-xmlFile() directly but in Okular we use the same the same toolbar name defined in two xml files, so that still did not work because this means we end up with just one KToolbar (yes i know that might be a misuse of the API). So i ended up going through the actioncollections to find the action and get the correct client from there. This addresses bug 292574. http://bugs.kde.org/show_bug.cgi?id=292574 Diffs - kdeui/widgets/ktoolbar.cpp cce242b Diff: http://git.reviewboard.kde.org/r/103812/diff/diff Testing --- Fixes the issue in Okular, i tested it does still work with Kate that is using the ui.rc scheme. Thanks, Albert Astals Cid
Re: Review Request: Report file errors when extracting files using karchive
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103808/#review10174 --- kdecore/io/karchive.h http://git.reviewboard.kde.org/r/103808/#comment8363 Needs doxygen documentation - Albert Astals Cid On Jan. 28, 2012, 12:09 p.m., Theofilos Intzoglou wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103808/ --- (Updated Jan. 28, 2012, 12:09 p.m.) Review request for kdelibs. Description --- A simple patch to check if something goes wrong when extracting files from an archive. You can read the error code using copyToErrorCode() Diffs - kdecore/io/karchive.h 7cd7c0c kdecore/io/karchive.cpp 86d61d5 Diff: http://git.reviewboard.kde.org/r/103808/diff/diff Testing --- Thanks, Theofilos Intzoglou
Re: Review Request: Add recentdocuments:/ kio slave to kde-runtime.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103849/#review10300 --- You need a Messages.sh to extract your i18n calls so that they can be translated kioslave/recentdocuments/recentdocuments.cpp http://git.reviewboard.kde.org/r/103849/#comment8488 That kdelibs4 does not make sense, you need your own translation catalog, loading the kdelibs4 catalog only won't help kioslave/recentdocuments/recentdocuments.protocol http://git.reviewboard.kde.org/r/103849/#comment8487 Why 4 maxInstances? - Albert Astals Cid On Feb. 2, 2012, 3:23 p.m., Xuetian Weng wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103849/ --- (Updated Feb. 2, 2012, 3:23 p.m.) Review request for KDE Runtime. Description --- Add recentdocuments:/ kio slave to kde-runtime. Did some little rename recentdocument - recentdocuments, based on http://kde-apps.org/content/show.php?content=145878 Diffs - kioslave/CMakeLists.txt f3d5b00 kioslave/recentdocuments/CMakeLists.txt PRE-CREATION kioslave/recentdocuments/recentdocuments.h PRE-CREATION kioslave/recentdocuments/recentdocuments.cpp PRE-CREATION kioslave/recentdocuments/recentdocuments.protocol PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.h PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.cpp PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.desktop PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103849/diff/diff Testing --- Works for me. Thanks, Xuetian Weng
Re: Review Request: Add recentdocuments:/ kio slave to kde-runtime.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103849/#review10352 --- kioslave/recentdocuments/recentdocumentsnotifier.cpp http://git.reviewboard.kde.org/r/103849/#comment8522 it's not unused ;-) - Albert Astals Cid On Feb. 5, 2012, 5:28 a.m., Xuetian Weng wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103849/ --- (Updated Feb. 5, 2012, 5:28 a.m.) Review request for KDE Runtime. Description --- Add recentdocuments:/ kio slave to kde-runtime. Did some little rename recentdocument - recentdocuments, based on http://kde-apps.org/content/show.php?content=145878 Diffs - kioslave/CMakeLists.txt f3d5b00 kioslave/recentdocuments/CMakeLists.txt PRE-CREATION kioslave/recentdocuments/Messages.sh PRE-CREATION kioslave/recentdocuments/recentdocuments.h PRE-CREATION kioslave/recentdocuments/recentdocuments.cpp PRE-CREATION kioslave/recentdocuments/recentdocuments.protocol PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.h PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.cpp PRE-CREATION kioslave/recentdocuments/recentdocumentsnotifier.desktop PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103849/diff/diff Testing --- Works for me. Thanks, Xuetian Weng
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs (updated) - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/diff Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/diff Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
On Feb. 10, 2012, 12:01 a.m., Christoph Feck wrote: Thanks Albert for looking at it. Not sure if I understand everything correctly, but what happens, when I have a subclass of Q/KComboBox, that does not have its own user property? I am considering the following possible cases: 1) plain QComboBox 2) subclassed QComboBox without custom user property 3) subclassed QComboBox with custom user property 4) plain KComboBox 5) subclassed KComboBox without custom user property 6) subclassed KComboBox with custom user property (e.g. KColorCombo) For 1) 2) 4) 5) it should ignore the new 4.8 user property, and use our custom code. For 3) 6) it should respect the custom user property. If I am following code paths correctly, the patch fails for cases 2) and 5). It does not find the class name in the map, falls back to user property (what Qt provides now since 4.8), and thus not handle our custom code. what happens, when I have a subclass of Q/KComboBox, that does not have its own user property? I don't think that needs to be a supported use case at all, i.e. if you don't tell KConfigDialogManager how to support your class, how are you expecting it to work? By magic? Thus 2) and 5) are non-issues in my opinion - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/#review10470 --- On Feb. 9, 2012, 11:28 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/ Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
On Feb. 10, 2012, 12:01 a.m., Christoph Feck wrote: Thanks Albert for looking at it. Not sure if I understand everything correctly, but what happens, when I have a subclass of Q/KComboBox, that does not have its own user property? I am considering the following possible cases: 1) plain QComboBox 2) subclassed QComboBox without custom user property 3) subclassed QComboBox with custom user property 4) plain KComboBox 5) subclassed KComboBox without custom user property 6) subclassed KComboBox with custom user property (e.g. KColorCombo) For 1) 2) 4) 5) it should ignore the new 4.8 user property, and use our custom code. For 3) 6) it should respect the custom user property. If I am following code paths correctly, the patch fails for cases 2) and 5). It does not find the class name in the map, falls back to user property (what Qt provides now since 4.8), and thus not handle our custom code. Albert Astals Cid wrote: what happens, when I have a subclass of Q/KComboBox, that does not have its own user property? I don't think that needs to be a supported use case at all, i.e. if you don't tell KConfigDialogManager how to support your class, how are you expecting it to work? By magic? Thus 2) and 5) are non-issues in my opinion Christoph Feck wrote: To me it looks like the code part that starts with the qobject_castQComboBox* has been added to actually support combo boxes without a user property. Qt did not handle them back then, now it does, but differently than KDE handles them. Yes, the code part that starts with the qobject_castQComboBox* has been added to actually support combo boxes without a user property, and that is still what it does. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/#review10470 --- On Feb. 9, 2012, 11:28 p.m., Albert Astals Cid wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 9, 2012, 11:28 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION kdeui/dialogs/kconfigdialogmanager.cpp 0890c0b Diff: http://git.reviewboard.kde.org/r/103909/diff/ Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Write to the correct xmlFile in KToolBar::Private::slotContextShowText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103812/ --- (Updated Feb. 20, 2012, 10:15 p.m.) Review request for kdelibs and David Faure. Changes --- New patch is up, not sure i like much the new code in BuildHelper::processContainerElement but it is the only way i found to do what you asked for. Description --- KToolBar::Private::slotContextShowText() was assuming that the xmlgui file it had to write was KGlobal::mainComponent.componentName() + ui.rc; which is obviously wrong since we have a setXMLFile function for a reason. I tried using xmlguiClient-xmlFile() directly but in Okular we use the same the same toolbar name defined in two xml files, so that still did not work because this means we end up with just one KToolbar (yes i know that might be a misuse of the API). So i ended up going through the actioncollections to find the action and get the correct client from there. This addresses bug 292574. http://bugs.kde.org/show_bug.cgi?id=292574 Diffs (updated) - kdeui/widgets/ktoolbar.h 69c482e kdeui/widgets/ktoolbar.cpp d17ff39 kdeui/xmlgui/kxmlguibuilder.cpp 6773c31 kdeui/xmlgui/kxmlguifactory_p.cpp 2f81f18 Diff: http://git.reviewboard.kde.org/r/103812/diff/ Testing --- Fixes the issue in Okular, i tested it does still work with Kate that is using the ui.rc scheme. Thanks, Albert Astals Cid
Re: Review Request: Write to the correct xmlFile in KToolBar::Private::slotContextShowText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103812/ --- (Updated Feb. 20, 2012, 10:22 p.m.) Review request for kdelibs and David Faure. Changes --- Another minor whitespace change Description --- KToolBar::Private::slotContextShowText() was assuming that the xmlgui file it had to write was KGlobal::mainComponent.componentName() + ui.rc; which is obviously wrong since we have a setXMLFile function for a reason. I tried using xmlguiClient-xmlFile() directly but in Okular we use the same the same toolbar name defined in two xml files, so that still did not work because this means we end up with just one KToolbar (yes i know that might be a misuse of the API). So i ended up going through the actioncollections to find the action and get the correct client from there. This addresses bug 292574. http://bugs.kde.org/show_bug.cgi?id=292574 Diffs (updated) - kdeui/widgets/ktoolbar.h 69c482e kdeui/widgets/ktoolbar.cpp d17ff39 kdeui/xmlgui/kxmlguibuilder.cpp 6773c31 kdeui/xmlgui/kxmlguifactory_p.cpp 2f81f18 Diff: http://git.reviewboard.kde.org/r/103812/diff/ Testing --- Fixes the issue in Okular, i tested it does still work with Kate that is using the ui.rc scheme. Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 21, 2012, 11:54 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Changes --- Updated with apaku's suggestion to address Christoph's concerns about derived classes without USER property Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs (updated) - kdeui/dialogs/kconfigdialogmanager.cpp 18bc44e kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103909/diff/ Testing --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the s_propertyMap-insert( KComboBox, ); the editable KComboBox fails Thanks, Albert Astals Cid
Re: Review Request: Fix KConfigDialogManager fails to handle subclasses of QComboBox with custom property
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103909/ --- (Updated Feb. 21, 2012, 11:55 p.m.) Review request for kdelibs, Ben Cooksley, Eike Hein, Christoph Feck, and Jeremy Paul Whiting. Description --- https://git.reviewboard.kde.org/r/101486/ broke subclasses of QComboBox that have a USER property like KColorCombo, this patch reverts this change and introduces a different code path to ignore the USER property of QComboBox and KComboBox and make it use our custom code. This addresses bug 293702. http://bugs.kde.org/show_bug.cgi?id=293702 Diffs - kdeui/dialogs/kconfigdialogmanager.cpp 18bc44e kdeui/tests/CMakeLists.txt 63788f6 kdeui/tests/kconfigdialog_unittest.cpp PRE-CREATION Diff: http://git.reviewboard.kde.org/r/103909/diff/ Testing (updated) --- Ran the attached test, everything worked. Without moving the userproperty = getUserProperty(w); the KColorCombo fails Without adding the propertyIndex stuff the editable KComboBox fails Thanks, Albert Astals Cid
Re: resolving i18n merge conflicts, is there a policy fot i18n commits?
El Dimarts, 13 de març de 2012, a les 23:45:56, Thomas Lübking va escriure: Is there any policy on i18n commits/conflicts, ie. like only 4.8 is up to date (seems to me?) so one can safely git merge -Xtheirs origin/KDE/4.8 The problem is that i get like a bazillion conflicts in .desktop files and i can't resolve them by hand, since i cannot read most of the conflicts :-( scripty updates .desktop files every day, so do whatever you want with them, it will be correct on the next scripty run, so unless you really break something the date of the release it doesn't matter. BUT (i understand you are merging KDE/4.8 to master) If you take KDE/4.8 contents over the master ones you'll get an extra commit of scripty fixing it to the correct master values so you probably want to take the master version not the KDE/4.8 one Albert Cheers, Thomas
Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
El Divendres, 23 de març de 2012, a les 20:12:53, Thomas Zander va escriure: On Friday 23 March 2012 19.39.26 Albert Astals Cid wrote: Removing the functional effects which context markers have, including the /format modifiers, might have a significant effect if this makes everything plain text rather than rich text, so at first sight I'm not too keen on this idea. I agree with David here, the fact that people don't use them does not mean we should aim at using them. And people don't use them because most people probably doesn't know, this can be attributed to a lot of things, like for example us not having a proper style guide where you would write Each time a filename appears in an user visible message write filename%1/filename. Other reason is developers not caring about consistency much, we could easily gather some non-hardcore developers to go other the various i18n messages of a given app and fix them. Looking at the numbers I'm not sure your optimism is warrented; this feature has been around for many years and its documented on techbase yet its being used in very very low numbers. (333 times in all of KDE for the filename tag..) Sure, it may be ignorance. Frankly, I didn't know about this feature. The fact that developers didn't know about this feature is just as much education as that they never needed it and asked how to do it. I think its nice to be optimistic and think that we can get people to fix their UIs and suddenly get people to care. That's only because we are geeks and don't care if half the time a filename appears as '/home/tsdgeos/foo.txt' or /home/tsdgeos/foo.txt or BOLD/home/tsdgeos/foo.txtBOLD or whatever. In a polished environment this is important. IMHO this is something similar to i18n, needs someone that goes after people and nags them to fix it. But can we be certain enough of succeeding now where we clearly failed before that this is actually worth stopping the innovations that Chusslove is working on? I did not understand that it was stopping any innovation, Chusslove can you clarify if you want to remove them for the sake of simpler code (which I don't say it's unimportant) or because they create problems with other features you are developing? Read those numbers again; its kinda depressing really; Yes, they are, but to be honest noone pushed for them, what you expected? Cheers, Albert Only 5 out of 24 KUIT tags were used more than 100 times (filename being the most used with 333 appearances).
Re: [REVIEW]: plasma-mobile repositories
El Divendres, 23 de març de 2012, a les 12:01:04, Aaron J. Seigo va escriure: hi everyone ... the repositories holding the Plasma Active code have been moved into kdereview as plasma-mobile and plasma-mobile-config so as to go through the usual 2 week review period before moving to their permanent home. if there are any question or queries, input or feedback, please don't hesitate :) Please fix i18n :-) Problems i found in a few seconds with a grep shell/widgetsexplorer/kcategorizeditemsviewmodels.cpp has a i18n but the file doesn't seem to be extracted shell/widgetsexplorer/plasmaappletitemmodel.cpp the same components/mobilecomponents/ViewSearch.qml the same And then i stopped looking, please have i18n in mind and once you think you've fixed it tell me again and i'll do an in depth review. Cheers, Albert
Re: [REVIEW]: plasma-mobile repositories
El Dilluns, 26 de març de 2012, a les 12:32:37, Aaron J. Seigo va escriure: On Friday, March 23, 2012 20:38:49 Albert Astals Cid wrote: Problems i found in a few seconds with a grep i've fixed these now in the master branch. please let me know if you find additional issues. thanks. Have you check that your catalogs are loaded? I don't find any reference to libmobilecomponentsplugin other than the one in the Messages.sh file. Albert
Re: [REVIEW]: plasma-mobile repositories
El Divendres, 23 de març de 2012, a les 12:01:04, Aaron J. Seigo va escriure: hi everyone ... the repositories holding the Plasma Active code have been moved into kdereview as plasma-mobile and plasma-mobile-config so as to go through the usual 2 week review period before moving to their permanent home. Lamarque says plasma-mobile-config is still Work In Progress stuff. Please move it back to some playground. Albert if there are any question or queries, input or feedback, please don't hesitate :)
Re: Setting up a Quality Team within KDE
El Diumenge, 8 d'abril de 2012, a les 17:13:54, Pau Garcia i Quiles va escriure: On Sun, Apr 8, 2012 at 4:03 PM, Anne-Marie Mahfouf annemarie.mahf...@free.fr wrote: ** Indeed, Nice idea, I think this is the right focus to (auto)test the functionality/features of the app. I've searched some info about this topic and found this: http://ldtp.freedesktop.org/wiki/Home It has full support for KDE/Qt (4.x) apps and the scripts (for autotesting) can be written with Python. My 0.5 cents :) Cheers, Percy Yes this is maybe the best free tool to do the job. DO you or anybody have used it already? Does that tool support QML? Is there an active team behind it? Writing UI tests (functional tests) is a hell of a lot of work and choosing the wrong tool means in 2 years we may need to maintain the tool ourselves or rewrite all the tests for another tool. I can tell you TestComplete's support for Qt is pretty limited. I have not tested LDTP because we needed support for Windows and Linux for our Qt projects. Squish is the best tool we evaluated at work for Qt, it does support Qt Quick and there is a company maintaining it (Froglogic, founded by KDE developers and employing many KDE developers). A few more arguments pro-Squish: it's cross-platform (which means we can run the same tests on Linux, Windows, Mac and any other platform we support) and the client-server architecture is very useful when testing client-server applications, actual environments and/or using virtualization to run the UI tests after each daily build. Did you guys ever try Testability? I've been using lately and works pretty well and has the added value of being Free Software. Albert Talking about virtualization, what we do at work is we have daily builds for master and stabilization branches and we run tests in virtual machines. We are currently testing on 12 platforms. We have several testing profiles (test suites) so that we can quickly say the equivalent of this version of kdelibs is broken, do not bother performing any further testing: just flag this build as broken. Everything is automated and launched from the continuous integration tool as the build finishes. I'm a bit out of the testing stuff at work, and very very busy, but if we are serious about it, I can still give some advice and ask some of the verification and validation people if they are interested in joining. PS: Let's continue the discussion in kde-testing@
Re: Setting up a Quality Team within KDE
El Diumenge, 8 d'abril de 2012, a les 17:48:03, Pau Garcia i Quiles va escriure: On Sun, Apr 8, 2012 at 5:21 PM, Albert Astals Cid aa...@kde.org wrote: Did you guys ever try Testability? I've been using lately and works pretty well and has the added value of being Free Software. Do you mean this tool? http://code.google.com/p/testability-explorer/ TestComplete, Squish, LDTP, etc are completely different tools with a complete different scope. No, i mean this one. http://projects.developer.nokia.com/Testabilitydriver/ To be honest it's not greatly documented, but it's basically a Free squish replacement (albeit a bit worse), has a client/server separation, has the hability to introspect Qt objects, etc. It's what the Unity-Qt project uses for their automated testing. Cheers, Albert
Re: Question about unittesting
El Diumenge, 8 d'abril de 2012, a les 21:45:34, Giorgos Tsiapaliwkas va
escriure:
Hello,
Why we don't have in KDE a macro like,
if (application_is_in_debug_mode) {
//do some testing
}
Because then you are not testing your real code anymore.
Albert
Why we need a macro like that?
a. Giorgos added a feature which deletes a folder from dolphin. Without
this macro in order Giorgos to
test it he needs,
-to create a dir
-remove the dir
-check if the remove was successful(this is the actual test)
but if we had this macro Giorgos would need to implement the last step.
c. we gain more time and it gets easier for contributors to add some
testing code.
A side note here, of course in vital libs only experienced developers
should write the unittests,
but in small applications contributors could also do the job.
Regards
P.S.: this macro could be enabled by adding in the cmake options something
like enable_unittest
Re: Pairs going to KDE Edu
El Dilluns, 16 d'abril de 2012, a les 03:35:51, Aleix Pol va escriure: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. Your Messages.sh is wrong and you'll see that you are different than the rest. Albert If someone is interested, please take a look into it and tell us what you think. Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs
Re: Pairs going to KDE Edu
El Dilluns, 16 d'abril de 2012, a les 03:35:51, Aleix Pol va escriure: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. If someone is interested, please take a look into it and tell us what you think. text: display+ (game.state==playing ? br/+missed+ +found+ +time : ) word puzzle, please use i18n with context so people can reorder stuff in case they need it Cheers, Albert Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs
Re: Pairs going to KDE Edu
El Dilluns, 16 d'abril de 2012, a les 19:02:25, Albert Astals Cid va escriure: El Dilluns, 16 d'abril de 2012, a les 03:35:51, Aleix Pol va escriure: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. Your Messages.sh is wrong and you'll see that you are different than the rest. Besides being wrong you have two of them ;-) Albert Albert If someone is interested, please take a look into it and tell us what you think. Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs
Re: Review Request: Change Online help icon KHelpcenter
On April 17, 2012, 1:45 p.m., Sebastian Kügler wrote: This change is wrong, as the menu entry has nothing to do with the semantic meaning of the icon, and the icon is not named according to the icon spec. So the correct icon is already set here, if its look doesn't match, then that icon would need to be fixed. In this case, I assume you mean to better reflect the online part in the name, and I agree that it's not reflected in the name. Question is: does it matter where the help is located? (Surely does if the user is offline, but in general ... I think the help! part is important, not the online part. +1 - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104621/#review12573 --- On April 16, 2012, 5:28 p.m., Maarten De Meyer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104621/ --- (Updated April 16, 2012, 5:28 p.m.) Review request for KDE Runtime and Cornelius Schumacher. Description --- Changes the 'Online help' icon in the navigation to a more fitting one.(imho) Diffs - khelpcenter/plugins/onlinehelp.desktop 540f83f Diff: http://git.reviewboard.kde.org/r/104621/diff/ Testing --- compiled and run, works fine Thanks, Maarten De Meyer
Re: Pairs going to KDE Edu
El Dilluns, 16 d'abril de 2012, a les 03:35:51, Aleix Pol va escriure: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. If someone is interested, please take a look into it and tell us what you think. More problems: * The repo is marked as inactive in projects.kde.org, so scripty doesn't run over it * The desktop file has X-DocPath but you removed the doc * The desktop file has X-Ubuntu-Gettext-Domain=desktop_kdesdk Albert Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs
Re: Fwd: import kde-thumbnail-po into kdesdk
El Divendres, 20 d'abril de 2012, a les 23:06:40, Weng Xuetian va escriure: Hi, My friend ask me to forward this mail since maillist seems to think his mail is spam. We do not import projects into kdesdk, they need to follow KDE application life cycle http://techbase.kde.org/Policies/Application_Lifecycle Also I am concerned about the fact that your friend can't post here, how is he going to interact with the community? Through you? Albert -- Forwarded message -- From: nihui shuizhuyuan...@126.com Date: 2012/4/20 Subject: import kde-thumbnail-po into kdesdk To: kde-core-devel kde-core-devel@kde.org hi all I think it is the time to import kde-thumbnailer-po[1] into kdesdk. There was a same plugin in the old kde3 days, but got removed with kbabel altogether. this plugin depends on gettext-po library Though I have already implemented lots of kde thumbnailer plugins and made some releases on kde-apps.org, this po plugin is the most popular and got high voting. I think it should be quite useful for many users, especially the translators using KDE. [1]http://kde-apps.org/content/show.php/KDE+PO+Thumbnailer?content=142036 regards, nihui
Re: Fwd: import kde-thumbnail-po into kdesdk
El Dilluns, 23 d'abril de 2012, a les 01:49:04, nihui水竹院落 va escriure: hi all what about through kde reviewboard, like kio-recentdocuments plugin[1]I don't think it is necessary for a plugin to follow application lifecycle policy to get into kde main modules or extragear ones. Why not? What's the difference between a plugin and an application? Plugins don't need to be reviewed for i18n? Or for bad coding practices? Albert but I couldn't find the reviewboard group for kdesdk, so I may have to put this plugin in kdereview and wait reviewing for weeks. regards,nihui [1]https://git.reviewboard.kde.org/r/103849/
kde-thumbnail-po in kdereview WAS Re: import kde-thumbnail-po into kdesdk
El Dilluns, 23 d'abril de 2012, a les 14:41:40, nihui水竹院落 va escriure: hi the code has already been in kdereview now.[1] I'd like that you changed the find_library(GETTEXTPO_LIBRARY NAMES gettextpo REQUIRED) to macro_optional_find_package macro_log_feature macro_display_feature_log so once it's in kdesdk it behaves like a good citizen disabling itself from build instead of breaking the build for people not having that library. The rest looks good :-) Cheers, Albert regards, nihui [1] http://websvn.kde.org/?view=revisionrevision=1291261
Re: patches too big for kdelibs 4.8?
El Dimecres, 25 d'abril de 2012, a les 20:31:37, Bernd Buschinski va escriure: Hello, I have kjs patches that I think are too big for KDE/4.8. Now I wonder... where should I commit them to? As far as I know kdelibs currently has 3 branches. master: which I was told is like dead KDE/4.8: bug fixes only framework: KDE5 Well, you could call these patches bug fixes as they fix some missing javascript functionality and make some websites work. That's a bugfix in my book. Cheers, Albert But you could also call them new features as you now can use more javascript functionality. Personally I think calling them bugfixes feels somehow sneaky, to just get them in KDE/4.8. So is frameworks the correct branch for me? I think no, as framework does not have a fixed release date it too far away before it reaches the user. I would love to have a KDE/4.9 branch, but looks like it is not planned. As I plan to further hack on kjs there might be more patches coming and if possible I would love to keep the kdelibs-my kjs patches distance close. After all the helpful review and the intense ecmascript testsuite I feel rather confident that these patches work. But as you might know the web is big ;-) So big that it is impossible for to surf on all existing websites. And again 5.0 might be far away, beside from the fact that the topic in #kde-devel says no new features in kdelibs. So as I am a bit lost here, back to my basic question, where should I commit to? Or how should I continue? regards, Bernd
Re: Extra KDE Telepathy modules moving to Extragear
El Dimecres, 25 d'abril de 2012, a les 18:15:00, David Edmundson va escriure: We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Could you add some context to Answer? To the translator it's not obvious if it's the name or the verb that he is translating. Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. utils.h is installed but its class not exported? What's the reason for that? Some installed headers do not have a dpointer, i know this is a obscure library, but i think you should at least try to d-pointify them if you are making this a public library. Cheers, Albert Thanks in advance David Edmundson [1] https://projects.kde.org/projects/kdereview/ktp-call-ui [2] http://gkiagia.wordpress.com/2012/03/29/video-calls-in-kde-telepathy/ [3] http://community.kde.org/Real-Time_Communication_and_Collaboration/Componen ts/Call_UI [4] https://projects.kde.org/projects/kdereview/telepathy-logger-qt [5] http://mail.kde.org/pipermail/kde-telepathy/2012-January/005064.html
Re: Review Request: New KDE Macro for to wrap the noreturn attribute
On Feb. 13, 2012, 11:30 a.m., David Faure wrote: Out of curiosity, if the method returns void anyway, why is this attribute necessary? It's not like the the compiler is going to warn about the lack of a return value... Allen Winter wrote: From the GNU Compiler documentation: The noreturn keyword tells the compiler to assume that fatal cannot return. It can then optimize without regard to what would happen if fatal ever did return. This makes slightly better code. More importantly, it helps avoid spurious warnings of uninitialized variables. From my point-of-view, I just want something that can shutup compiler warnings Allen Winter wrote: ping? It is a very niche use case, but probably makes sense to have, though you'd have to commit it carefully so that it goes into 4.9 given that we don't have a proper 4.9 branch, no? - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103832/#review10589 --- On Jan. 31, 2012, 8:58 p.m., Allen Winter wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103832/ --- (Updated Jan. 31, 2012, 8:58 p.m.) Review request for kdelibs. Description --- This diff adds a new macro KDE_NO_RETURN that wraps the noreturn attribute which is enabled differently based on the compiler. Diffs - kdemacros.h.cmake b93242c Diff: http://git.reviewboard.kde.org/r/103832/diff/ Testing --- did a test compile Thanks, Allen Winter
Re: Extra KDE Telepathy modules moving to Extragear
El Dissabte, 28 d'abril de 2012, a les 16:08:41, George Kiagiadakis va escriure: On Thu, Apr 26, 2012 at 11:07 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 25 d'abril de 2012, a les 18:15:00, David Edmundson va escriure: We would like to move 2 more KDE Telepathy modules to Extragear, to join our existing code. KTp Call UI [1] Provides a GUI for making video calls in telepathy. For details see [2][3] Could you add some context to Answer? To the translator it's not obvious if it's the name or the verb that he is translating. Done. Telepathy Logger Qt [4] This provides Qt bindings for Telepathy-Logger a daemon that logs all text messages received. This is an optional dependency for ktp-text-ui which allows us to show a backlog and a way to view old log messages. This was imported from Collabora's git repository. I moved it into KDE playground where I'm maintaining it after Collabora seemed to lose any interest in keeping it up to date or making a release. This has been discussed on their mailing list. [5]. utils.h is installed but its class not exported? What's the reason for that? Looks like a mistake. I'll fix it. Some installed headers do not have a dpointer, i know this is a obscure library, but i think you should at least try to d-pointify them if you are making this a public library. No, the classes that wrap GObjects do not need a d-pointer. All the calls are forwarded to the underlying GObject and if for any reason we ever need to save extra data on the wrapper class (which is highly unlikely), we should use the GObject qdata for that. Wrapper classes may be destroyed and re-allocated by QtGLib and therefore they shouldn't hold any data. What about the SearchHit struct? On a second header inspection i've also found a weird \ in pending-search.h Cheers, Albert
Re: Review request: AppMenu support for KDE
El Divendres, 27 d'abril de 2012, a les 09:35:14, Lionel Chauvin va escriure: The code that bring support of AppMenu to KDE needs to be reviewed before it entered in KDE main module: https://projects.kde.org/projects/kdereview/kded-appmenu/repository It contains a KDED module and a library. The KDED module exports applications menu through dbus. The library exposes the functionalities of the module so it is not needed to deal with KDED stuff. This support is required by the menu button in the oxygen decoration: https://git.reviewboard.kde.org/r/104344/ It can be tested using an adapted version of the plasmoid menubar: https://code.launchpad.net/~megabigbug/plasma-widget-menubar/appmenu-kde Can you clarify the license of the code? The COPYING says GPL3, kappmenuimporter.* seems to be not exact about the licensing, menuinfo.h says GPL3 again. Note that our licensing policy[1] does not accept GPL3-only code Do we really need generated files in the repository? (importer_interface.*) You have duplicate files $ fdupes -R . ./lib/com.canonical.AppMenu.Registrar.xml ./module/com.canonical.AppMenu.Registrar.xml Your installed library headers do not follow the of suggestions of our library policy, like no inline code in the headers, no d-pointers, etc. Cheers, Albert [1] http://techbase.kde.org/Policies/Licensing_Policy
Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror
On April 26, 2012, 5:09 p.m., Albert Astals Cid wrote: If i understand you correctly you are suggesting to create a bug (option that does nothing)? Doesn't make much sense. Dawit Alemayehu wrote: Huh ? I do not follow. By option that does nothing you mean this change by itself does nothing that is correct. But that is true of every option in that dialog as well. Moreover, it is a well known fact that you cannot post a patch for different components in reviewboard. Anyhow, the option will most definitely be used by kwebkitpart. Whether or not some body implements support for it in khtml is a question I cannot answer. That is what I meant. David Faure wrote: Do you have the kwebkitpart patch ready? I suppose it'll be easy to apply to khtml as well. You are suggesting to add an option that does nothing in our default html rendering engine. That is adding a bug. The fact that you know it and don't care about it makes me sad. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104631/#review12934 --- On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104631/ --- (Updated April 26, 2012, 3:48 a.m.) Review request for KDE Base Apps, kdelibs and David Faure. Description --- A patch to make that provides an option to disable the offer to save website passwords. Note that for this patch to take effect this option will have to be used at at the browser engine level. Those patches are separate to this one. This is just the GUI configuration. Diffs - konqueror/settings/konqhtml/htmlopts.h 69f36d8 konqueror/settings/konqhtml/htmlopts.cpp e5d6deb Diff: http://git.reviewboard.kde.org/r/104631/diff/ Testing --- Screenshots --- Option for disabling KWallet integration http://git.reviewboard.kde.org/r/104631/s/544/ Thanks, Dawit Alemayehu
Re: The Nepomuk Situation
El Dimecres, 2 de maig de 2012, a les 12:14:00, Ivan Cukic va escriure: The first solution - * Remove nepomuk from kdelibs and kde-runtime +1 This is what has been done with kactivities. Instead of having it in kdelibs and runtime, it is now all in one repository. The only difference here is that nepomuk is not in libs/experimental like libkactivities was. This is a huge difference, we *promise* to keep SC and BC of our libs, doing the first solution would totally go against our promises. Cheers, Albert I think that this would help KF5 efforts since applications would start porting early to the new libraries. Again, the only downside being the fact that libnepomuk will not be able to stay binary (or api) back-compatible due to uses of KUrl and similars (it it hasn't already been removed in the nepomuk-core) Cheerio, Ivan * Make nepomuk-core a compile time dependency for kdelibs * Including the missing gui code into nepomuk-core The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/
Re: Pairs going to KDE Edu
El Dimarts, 1 de maig de 2012, a les 22:16:44, Aleix Pol va escriure: On Tue, May 1, 2012 at 9:29 AM, Aleix Pol aleix...@kde.org wrote: On Mon, Apr 30, 2012 at 10:07 AM, Yuri Chornoivan yurc...@ukr.net wrote: написане Mon, 30 Apr 2012 02:36:38 +0300, Aleix Pol aleix...@kde.org: On Mon, Apr 16, 2012 at 3:35 AM, Aleix Pol aleix...@kde.org wrote: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. If someone is interested, please take a look into it and tell us what you think. Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs Since no big complaints were raised and the 2 week period passed already, I'll ask the sysadmin team to move Pairs to KDE Edu. :) Thanks to all those who cared. ^^ Aleix Hi, Just for the record, I think the issues found by Albert Astals Cid [1] were not fixed. Pairs is still untranslatable for KDE translation teams. Thanks for fixing this. Best regards, Yuri [1] http://lists.kde.org/?l=kde-edum=133468189317856w=2 ___ kde-edu mailing list kde-...@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-edu I think these are fixed now. Sorry for missing those! . Aleix Pairs has been moved to KDE Edu. If anybody has any problem with it, don't hesitate to contact us! I do, your repo is still marked as inactive as I wrote in my original e-mail. Please fix that. You know where to find me if you have problems fixing that. Cheers, Albert Aleix
Re: The Nepomuk Situation
El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? Albert Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/
Re: The Nepomuk Situation
El Dilluns, 7 de maig de 2012, a les 22:09:01, Vishesh Handa va escriure: On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? Yes they can still use the old apis, but it would be horribly horribly slow and would create a lot of useless data in the process. Also somethings like change monitoring and merging resources are flat out impossible. I'm not okay with applications having to stick with the old faulty APIs when we have put in so much effort to make these new ones. Also, can we substitute the word old apis with kdelibs/nepomuk apis and new apis with datamangement apis. This is getting a little confusing. There's some problem of communication here. Let me try to explain myself better. As far as I understand: * Dolphin uses the old api at the moment and works fine * When the change you propose (adding new apis), you said the old api will still be there for people to use * The question is: If dolphin is not changed to use the new api and still uses the old api will it still work as it works now or will be worse? Hope i'm clearer now. Cheers, Albert Albert Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/
Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror
On April 26, 2012, 5:09 p.m., Albert Astals Cid wrote:
If i understand you correctly you are suggesting to create a bug (option
that does nothing)?
Doesn't make much sense.
Dawit Alemayehu wrote:
Huh ? I do not follow. By option that does nothing you mean this change
by itself does nothing that is correct. But that is true of every option in
that dialog as well. Moreover, it is a well known fact that you cannot post a
patch for different components in reviewboard. Anyhow, the option will most
definitely be used by kwebkitpart. Whether or not some body implements
support for it in khtml is a question I cannot answer. That is what I meant.
David Faure wrote:
Do you have the kwebkitpart patch ready?
I suppose it'll be easy to apply to khtml as well.
Albert Astals Cid wrote:
You are suggesting to add an option that does nothing in our default html
rendering engine. That is adding a bug. The fact that you know it and don't
care about it makes me sad.
Dawit Alemayehu wrote:
@David: Yes I have a patch for kwebkitpart, but unlike in khtml adding
support for this in kwebkitpart required a very small change in one place in
addition to adding code to read the config option itself in
webkitettings.{h|cpp}. That does not seem to be the case in khtml. It is a
little bit more invovled.
@Albert: Really ?? So how exactly is another browser engine supposed to
provide configuration option to the user if it is supposed to be embedded
into Konqueror ? Why would a developer working on a separate browsing engine
be forced to implement any functionality into khtml ? Would that requirement
apply the other way around ? The last I checked, this is a konqueror setting.
Whether a specific browser engine supports it or not is up to that browser
engine.Just for the record I almost always go out of my way to implement
things in khtml ; especially when I factor out features that are common to
both engines. In this case, I neither have the time nor a complete grasp of
how the KWallet integration works in khtml. As I stated above the change is
not in a single isolated location like it is in kwebkitpart. Feel free to do
a grep in khtml and see for yourself. I can always add the set/get functions
to access the option in KHTMLSettings, but what use would that be if it is
not implemented.
Anyhow, I digress. If there are objections, I will simply move this
feature into the webkit config module I will have to create down the road.
So how exactly is another browser engine supposed to provide configuration
option to the user if it is supposed to be embedded into Konqueror ?
Having it's own engine-only kcm for it's engine-specific options?
Why would a developer working on a separate browsing engine be forced to
implement any functionality into khtml ?
When did i say that?
Would that requirement apply the other way around ?
If you want to use the general apply to all engines options page, of course.
You probably don't have any bit of user mentallity left in your head, because
it's pretty obvious that adding a configuration option to web rendering
configuration that won't work with our default rendering engine it's bad
usability.
But hey, since David promised to implement this for khtml, go ahead, don't let
me block progress.
- Albert
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104631/#review12934
---
On April 26, 2012, 3:48 a.m., Dawit Alemayehu wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104631/
---
(Updated April 26, 2012, 3:48 a.m.)
Review request for KDE Base Apps, kdelibs and David Faure.
Description
---
A patch to make that provides an option to disable the offer to save website
passwords. Note that for this patch to take effect this option will have to
be used at at the browser engine level. Those patches are separate to this
one. This is just the GUI configuration.
Diffs
-
konqueror/settings/konqhtml/htmlopts.h 69f36d8
konqueror/settings/konqhtml/htmlopts.cpp e5d6deb
Diff: http://git.reviewboard.kde.org/r/104631/diff/
Testing
---
Screenshots
---
Option for disabling KWallet integration
http://git.reviewboard.kde.org/r/104631/s/544/
Thanks,
Dawit Alemayehu
Re: Review Request: Added option for disabling the offer to save website passwords in Konqueror
El Diumenge, 13 de maig de 2012, a les 14:27:37, Sebastian Kügler va escriure: On Sunday, May 13, 2012 12:20:00 Albert Astals Cid wrote: You probably don't have any bit of user mentallity left in your head, I think everybody is served better by discussions that do not engage in personal attacks. This was in no way a personal attack. You'll realize when I do a personal attack. Let us please try to keep it respectful and technical I have been respectful and technical. and avoid ad-hominem attacks. No ad-hominem attack happened, an ad-hominem attack would be saying Don't listen to him, he is a communist, since being communist or not does not have any effect on his technical hability, but might put people against him. Respect is an important basis for making progress in a collaborative way. Sure it is. Cheers, Albert Thanks,
Re: Nepomuk - Moving out of kde-runtime
El Dijous, 17 de maig de 2012, a les 19:31:14, Vishesh Handa va escriure: Hey @Translators: You probably want to preserve the translations in kde-runtime/nepomuk. How do we go about this? That's not a problem. Albert
Re: Review Request: Apper on kdereview
El Dilluns, 21 de maig de 2012, a les 18:31:25, Daniel Nicoletti va escriure: Hi, Apper is on playground probably since 2008, it's widely used nowadays so it doesn't make sense to keep it there anymore. So please review the code, make suggestions and such... AppSetup doesn't seem to be loading the apper translation catalog. Albert Right now the code is at (I've asked kde sysadmin to move to kdereview, but afaik it will only reflect the projects url): https://projects.kde.org/projects/playground/sysadmin/apper/repository Thanks :D Daniel
Re: Review Request: Plasma::RunnerManager: only dequeue our ThreadWeaver jobs
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104973/#review14082 --- Does this have unit tests? Would make sense to add a new one forcing this behaviour? What about docs? Should any doc be fixed/improved mentioning the behaviour? - Albert Astals Cid On May 17, 2012, 1:18 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104973/ --- (Updated May 17, 2012, 1:18 p.m.) Review request for kdelibs. Description --- When RunnerManager::reset() is called, all ThreadWeaver jobs are dequeued, including jobs from other parts of the code. This patch changes this to only dequeue the jobs created by this instance of RunnerManager. Diffs - plasma/runnermanager.cpp 49569a3 Diff: http://git.reviewboard.kde.org/r/104973/diff/ Testing --- I have more than one RunnerManager working at once in a project. Without the patch, only one manager return results. Thanks, Aurélien Gâteau
Re: Review Request: Apper on kdereview
El Dimecres, 23 de maig de 2012, a les 13:58:27, Matthias Klumpp va escriure: Hi! This issue has been fixed some time ago. I can't find where the apper catalog loaded in AppSetup, can you point me to it? Cheers, Albert Thanks for the hint! :) Matthias 2012/5/23 Albert Astals Cid aa...@kde.org: El Dilluns, 21 de maig de 2012, a les 18:31:25, Daniel Nicoletti va escriure: Hi, Apper is on playground probably since 2008, it's widely used nowadays so it doesn't make sense to keep it there anymore. So please review the code, make suggestions and such... AppSetup doesn't seem to be loading the apper translation catalog. Albert Right now the code is at (I've asked kde sysadmin to move to kdereview, but afaik it will only reflect the projects url): https://projects.kde.org/projects/playground/sysadmin/apper/repository Thanks :D Daniel
Re: Review request: moving libkgoogle to extragear
El Dissabte, 26 de maig de 2012, a les 17:23:13, Dan Vratil va escriure:
On Saturday 26 of May 2012 11:42:41 Raphael Kubo da Costa wrote:
Dan Vratil d...@progdan.cz writes:
Hi,
LibKGoogle is a new optional dependency of kdepim-runtime. It's used by
the
new Akonadi Google resources.
It's now in kdereview [0] and I'd like to move it to extragear, so I'm
asking for a review on the library.
One thing I have noticed is that libkgoogle seems to be GPLv3+, while
KDE's licensing policy [1] says code under the GPL should be GPLv2+.
As far as I understand the policies, libkgoogle is a subject to point 5,
which says
Any other source files must be licensed under one of the terms listed under
4) or one of the following terms
* GPL version 2 as listed in kdelibs/COPYING or later
* GPL version 2 or version 3 or later versions approved by the membership
of KDE e.V.
* ...
I understand the second item as either GPLv2 or GPLv3 or any later approved
version, so GPLv3+ should be OK too, right?
No, you missed the part that says Note each bulletpoint above is a single
option, it can not be licenced under just part of one bulletpoint option
Albert
But if GPLv3+ should really be a problem, I'm OK with downgrading the
license (I guess I'll have to ask others who contributed).
The ${qjson_LIBRARIES} hack should not be needed anymore anyway, as the
naming scheme was restored months ago in git master (no version was
released with the names messed up).
Thanks, I'll remove it.
[1] http://techbase.kde.org/Policies/Licensing_Policy
Please fix nepomuk-core buildsystem
I find it quite annoying that it tells me -- Soprano version 2.7.5 is too old. Please install 2.7.56 or newer and then tells me - -- The following external packages were located on your system. -- This installation will have the extra features provided by these packages. - * Soprano - Soprano is the Qt-based RDF storage and parsing solution - -- Congratulations! All external packages have been found. - If i get a Congratulations! message I expect that it will build. Cheers, Albert
Please fix kde-runtime buildsystem
If kactivities is not found it gives --- CMake Error at plasma/declarativeimports/plasmaextracomponents/CMakeLists.txt:3 (find_package): Could not find module FindKActivities.cmake or a configuration file for package KActivities. Adjust CMAKE_MODULE_PATH to find FindKActivities.cmake or set KActivities_DIR to the directory containing a CMake configuration file for KActivities. The file will have one of the following names: KActivitiesConfig.cmake kactivities-config.cmake --- It should use a proper macro_log_feature reporting system. Cheers, Albert
Please fix kde-runtime buildsystem (2nd issue)
It seems kde-runtime needs shared-desktop-ontologies 0.9 I would a macro_log_feature error instead of nepomuk/kioslaves/nepomuk/resourcepagegenerator.cpp failing to compile Cheers, Albert
Re: Extra KDE Telepathy modules moving to Extragear
El Dijous, 31 de maig de 2012, a les 20:10:08, David Edmundson va escriure: On Mon, Apr 30, 2012 at 11:28 PM, David Edmundson da...@davidedmundson.co.uk wrote: On Sun, Apr 29, 2012 at 2:42 PM, Kevin Krammer kram...@kde.org wrote: On Sunday, 2012-04-29, Martin Klapetek wrote: On Sat, Apr 28, 2012 at 22:44, Kevin Krammer kram...@kde.org wrote: On Saturday, 2012-04-28, George Kiagiadakis wrote: No, the classes that wrap GObjects do not need a d-pointer. All the calls are forwarded to the underlying GObject and if for any reason we ever need to save extra data on the wrapper class (which is highly unlikely), we should use the GObject qdata for that. Wrapper classes may be destroyed and re-allocated by QtGLib and therefore they shouldn't hold any data. So the GObject has a d-pointer? Any specific reason there is a GObject at all? My very basic understanding of Telepathy was that it is D-Bus based services. Telepathy is based on D-Bus services, however this is about Telepathy logger [1], which is a GObject-based implementation of a central logging Telepathy component, which does not use D-Bus for sending the logs as it is quite heavy data and D-Bus for this purpose is rather slow, so it provides a direct access API. The documentation you linked to seems to be quite of of date (most of the links in it don't work), so I would still need some clarifications. The document claims that the logger is an independent service, i.e. it says: Telepathy Logger is a session daemon. I quite don''t understand the term direct access API in the context of a daemon. Usually daemon refers to a separate process. Communicating with a process is to my best understanding never done by linking the daemon code into the client applications. Yes, starts whilst you're chatting. Closes when you're done. My best guess so far is that there is some library that provides read-only access to files the independent logger writes onto disk. Your guess is effectively correct. Telepathy-logger is a bit more complex as it writes to and reads from multiple backends. XML files or SQLite and it also reads (read only) Pidgin log files as their way of importing old log files. Our telepathy-logger-qt, which we want to move to Extragear, basically just wraps the original logger into Qt-like API, so that it can be used with Qt/KDE apps easily. Based on my guess I would strongly recommend to put the wrapped GObject into the wrapper's d-pointer. Otherwise your only way of ever implementing that natively is to name a struct GObject and use that as the native implementation's d-pointer, making it very hard for any using application to link with any library exposing GObject symbols. If we ever implemented it natively I would make so many other changes to the API that I would bump the major version number and not even try to keep compatibility. Cheers, Kevin [1] - http://telepathy.freedesktop.org/wiki/Logger -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring *bump* So to summarise so far: There were some issues with call-ui which are now all fixed. There were also comments about gobjects in the telepathy-logger and d-pointers which I disagree with and have hopefully explained my rationale. Are there any further objections to moving these forward into extragear? Yes, my mail about SearchHit struct and weird \ in pending-search.h seems to have been ignored. Albert David Edmundon
kdelibs and Qt version dependency
On May 19, Dawit Alemayehu commited a change that uses QSslConfiguration::testSslOption that is only available in Qt 4.8 This means that both kdelibs 4.8.4 and kdelibs 4.9 now depend in Qt 4.8 instead Qt 4.7 I want to ask the kdelibs maintainers: a) Do you think it makes sense to change our Qt required version from Qt 4.7 in kdelibs 4.8.3 to Qt 4.8 in kdelibs 4.8.4 ? b) Do you think kdelibs 4.9 should depend in Qt 4.8 or not? Cheers, Albert
Re: kdelibs and Qt version dependency
El Dimecres, 6 de juny de 2012, a les 11:26:32, Laszlo Papp va escriure: To re-iterate, it is policy that any dependency changes are discussed and approved on k-c-d first. It was discussed and disapproved as far as I understood. Do you have a link for that discussion? Albert Best Regards, Laszlo Papp
Re: kdelibs and Qt version dependency
El Dimecres, 6 de juny de 2012, a les 15:53:36, Dawit A va escriure: On Wed, Jun 6, 2012 at 2:32 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 6 de juny de 2012, a les 20:23:48, Laszlo Papp va escriure: Do you have a link for that discussion? http://lists.kde.org/?l=kde-core-develm=132630064116231w=2 That was in January though, people change their minds :D I count Dirk and Stephen saying to go with 4.8. John and you seem to want to stay. Personally after reading the whole thread you linked i kind of agree with the thread and if there is no *real hard* need to use Qt 4.8 I'd prefer not to allienate those using old distros that only ship Qt 4.7 You mean for KDE 4.8 here, right ? To me it does not make sense to do that for KDE 4.9. No, for KDE 4.8.4 is *obvious* we need to support Qt 4.7 since KDE 4.8.3 compiled with it, changing the required minimum Qt version is a no go from 4.8.3 to 4.8.4. So yes, I'm speaking for kdelibs 4.9 Albert
Re: kdelibs and Qt version dependency
El Dijous, 7 de juny de 2012, a les 09:27:22, Aaron J. Seigo va escriure: On Wednesday, June 6, 2012 20:32:49 Albert Astals Cid wrote: Someone from plasma? summary: no hard requirement to jump to Qt 4.8 from plasma at this time ... Qt 4.8 brings a number of speed improvements and general goodness which certainly helps the various Plasma workspaces, but i do not believe we have any hard requirements on it at this time ... so i'd love to see people using Qt 4.8, but we can keep a minimum 4.8 requirement for the time being. You meant but we can keep a minimum 4.7 requirement for the time being.? Asking because otherwise i don't understand the but in the sentence Albert my only concern is that our team works with Qt 4.8 right now, most of our users will likely get Qt 4.8 with SC 4.9 packages and so our code will be well tested with Qt 4.8 and Qt 4.7 will not be as well tested. i don't think there is much we can do about that though, unless a magic QA fairy passes by dropping testers. :)
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
El Dissabte, 9 de juny de 2012, a les 10:35:15, Modestas Vainius va escriure: Hello, Hi here at Debian we had a really bad experience with 4.8.4. While 4.8.3 was pretty good, 4.8.4 seemed like a huge step backwards in terms of stability (random crashes there and there). After quick investigation of kdelibs 4.8.4 I found the following: I don't know yet if any other modules from 4.8.4 has been mis-packaged in the same way There's no mispackaging. If you followed the list or read the archives before blaming people of wrong doing you'd know that kdelibs for 4.8.4 and 4.8.80 actually come from the same branch. Cheers, Albert
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
El Dissabte, 9 de juny de 2012, a les 13:10:40, Modestas Vainius va escriure: Hello, On šeštadienis 09 Birželis 2012 13:01:20 Albert Astals Cid wrote: here at Debian we had a really bad experience with 4.8.4. While 4.8.3 was pretty good, 4.8.4 seemed like a huge step backwards in terms of stability (random crashes there and there). After quick investigation of kdelibs 4.8.4 I found the following: I don't know yet if any other modules from 4.8.4 has been mis-packaged in the same way There's no mispackaging. If you followed the list or read the archives before blaming people of wrong doing you'd know that kdelibs for 4.8.4 and 4.8.80 actually come from the same branch. Thank you for pushing a bunch of untested huge changes in the minor point release. Really appreciated. Similiar numbers than 4.8.2 to 4.8.3, didn't see you complaining back then. Thank you for asuming everything we do is untested. Really appreciated. Cheers, Albert
Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+
El Dissabte, 9 de juny de 2012, a les 12:28:11, Andreas K. Huettel va escriure: Am Samstag 09 Juni 2012, 12:10:40 schrieb Modestas Vainius: Hello, On šeštadienis 09 Birželis 2012 13:01:20 Albert Astals Cid wrote: here at Debian we had a really bad experience with 4.8.4. While 4.8.3 was pretty good, 4.8.4 seemed like a huge step backwards in terms of stability (random crashes there and there). After quick investigation of kdelibs 4.8.4 I found the following: I don't know yet if any other modules from 4.8.4 has been mis-packaged in the same way There's no mispackaging. If you followed the list or read the archives before blaming people of wrong doing you'd know that kdelibs for 4.8.4 and 4.8.80 actually come from the same branch. Thank you for pushing a bunch of untested huge changes in the minor point release. Really appreciated. Exactly. Thumbs up. Making KDE more stable and predictable than ever. You are all making noise out of nothing, the amount of changes is in the same order of magnitude of other releases. Please stop let's stop throwing shit to the other side of the fence and start being constructive, give gdb backtraces, valgrind backtraces and exact reproducing instructions to problems you are finging. Cheers, Albert
Re: KDE SC 4.8.4 important problems
El Diumenge, 10 de juny de 2012, a les 11:30:13, Aaron J. Seigo va escriure: On Sunday, June 10, 2012 11:20:09 Aaron J. Seigo wrote: On Sunday, June 10, 2012 03:23:04 José Manuel Santamaría Lema wrote: #1 dolphin: #2 gwenview #6 kontact executing various components: calendar, to-do list, journal #7 kmail links these are all the same crash, or at least related to each other. it is crashing in KServiceTypeTrader::defaultOffers or KMimeTypeTrader::query apparently at times in KSycocaDict::find_string. curious: on an affected system, if you delete `kde4-config --localprefix`/cache-freedom/ksycoca4* do the crashes go away? No they don't Cheers, Albert possible culprit commits: 1a07fea2eaa69d571d5818812502edcc1d680d9c e91e5fed6b1aad365e12e919f430c3e8147552d3 neither are super recent, but they both touch the relevant code. there was one change to kmimetype by dfaure but it is not implicated by the backtraces nor can i see how it would be (it added a required method, did not change existing code paths and definitely not the ksycoca code underneath it)
Re: KDE SC 4.8.4 important problems
El Diumenge, 10 de juny de 2012, a les 12:57:09, Andreas Pakulat va escriure: Hi, Am Sonntag, 10. Juni 2012 schrieb Peter Penz : On 06/10/2012 11:20 AM, Aaron J. Seigo wrote: On Sunday, June 10, 2012 03:23:04 José Manuel Santamaría Lema wrote: #1 dolphin: #2 gwenview #6 kontact executing various components: calendar, to-do list, journal #7 kmail links these are all the same crash, or at least related to each other. it is crashing in KServiceTypeTrader::**defaultOffers or KMimeTypeTrader::query apparently at times in KSycocaDict::find_string. The issue has been tracked at https://bugs.kde.org/show_bug.**cgi?id=268064https://bugs.kde.org/show_bu g.cgi?id=268064- updating Soprano to the latest master resolves the crash. But I don't know more about the root-cause of this. Probably a Nepomuk-related update missed a proper versioning-check of Soprano? There has been an abi breakage in soparano's latest release (fixed in the repository already), so updating to that soprano release requires rebuilding all other code that uses it. I've seen backtraces ending in qstring::ref having such abi incompatibilities as cause, so it would fit at least those cases. As Modestias says, this has nothing to do with those ABI changes since it fails with stable soprano. Albert Andreas
