Re: KTextEditor Frameworks question
On Monday 06 January 2014 08:36:14 Christoph Cullmann wrote: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? Yes, you can just try it, see the instructions in that initial commit :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Problem with kf5-development/kde-build-metadata/dependency-data-common
Hi!
I have tried to build KF5 from scratch. When running ./kdesrc-build, I get
the following:
david@nimfa:~/devel/kf5-development$ ./kdesrc-build
Script started processing at Mon Jan 6 11:53:41 2014
* Downloading projects.kde.org project database...
Updating kde-build-metadata (to branch master)
* Problems encountered trying to sort modules into correct order:
* Unable to open
/home/david/devel/kf5-development/kde-build-metadata/dependency-data-common:
File or directory doesn't exist at
/home/david/devel/kf5-development/extragear/utils/kdesrc-build/modules/ksb/Application.pm
line 643.
at
/home/david/devel/kf5-development/extragear/utils/kdesrc-build/modules/ksb/Application.pm
line 643
eval {...} called at
/home/david/devel/kf5-development/extragear/utils/kdesrc-build/modules/ksb/Application.pm
line 627
ksb::Application::runAllModulePhases('ksb::Application=HASH(0x9830c08)')
called at ./kdesrc-build line 232
eval {...} called at ./kdesrc-build line 218
* Will attempt to continue.
I have checked that
/home/david/devel/kf5-development/kde-build-metadata/dependency-data-common
doesn't exist.
Many frameworks then don't build properly.
What should I do? Should that file actually be there?
Thanks in advance
David Gil
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem with kf5-development/kde-build-metadata/dependency-data-common
On Monday 06 January 2014 12:03:26 David Gil Oliva wrote: I have checked that /home/david/devel/kf5-development/kde-build-metadata/dependency-data-common doesn't exist. Indeed; chicken and egg problem (I was waiting for kdesrc-build to support it before moving stuff to it). Created now, does it work better? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Monday 06 January 2014 09:33:38 Martin Graesslin wrote: On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? That's a good question. In my opinion it's fine for a maintainer to delegate the duties to make things work on a given platform to someone else, but, he has to be able to answer at all time is this platform supported? is there anything broken there?. I think that's important that at the end of the day the maintainer is the point of contact for the given framework. This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. Of course, for most of the frameworks it shouldn't be an issue (if they're pure Qt), that's a very valid concern for frameworks which make native calls. In that case I think it's very important that we're blunt and honest about the situation. I'd rather see a few frameworks where we claim sorry, we don't support platform X yet/at all, than having a list where we claim we support all platforms for all frameworks while we're in fact lying for some of them. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? I'd rather have a person name to be honest. It's really for the single point of contact situation in case of big troubles and to avoid diluting the responsibility. How in practice the work is then distributed for a framework is to the discretion of the appointed maintainer, if there's a whole team helping all the better. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Problem with kf5-development/kde-build-metadata/dependency-data-common
Yes, it works. Thanks! David Gil El 06/01/2014 13:49, David Faure fa...@kde.org va escriure: On Monday 06 January 2014 12:03:26 David Gil Oliva wrote: I have checked that /home/david/devel/kf5-development/kde-build-metadata/dependency-data-common doesn't exist. Indeed; chicken and egg problem (I was waiting for kdesrc-build to support it before moving stuff to it). Created now, does it work better? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 23:54:46 Kevin Ottens wrote: On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... If everything else fails (in other words, if we really want to have a name listed, but nobody else steps up), I am willing to maintain these frameworks: - kiconthemes - kimageformats (including webp plugin from kde-runtime) - kplotting - kwidgetsaddons I may also be interested in kconfigwidgets, kcmutils, kcompletion, and kguiaddons in the future (I don't know the code good enough yet). Christoph Feck (kdepepo) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann: I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tue, Jan 7, 2014 at 3:03 AM, Kevin Funk k...@gmx.de wrote: Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann: I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Yes, it makes sense. When I created those we didn't do it like that in KF5 yet, this changed over time. Feel free to change it :). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: KClasses vs. Qt5Classes
Le mardi 31 décembre 2013 12:42:22 Martin Graesslin a écrit : On Tuesday 31 December 2013 12:15:09 David Faure wrote: QSystemTrayIcon = KNotificationItem No clue. I can't even find KNotificationItem in KF5 anywhere !?!? In fact it doesn't exist in kdelibs4 either. I think it got replaced with KStatusNotifierItem since 4.4 ? That one is still valid in KF5 (framework knotifications). I have no idea if/why it means QSystemTrayIcon is bad though. QSystemTrayIcon uses XEmbed which is bad by definition ;-) We have discussed this in the plasma team and think that the best solution would be to extend QSystemTrayIcon to use the status notifier API if available. Might need some hooks into the QPA as we probably cannot depend on D-Bus on that level. But as that doesn't exist yet, at the moment the proper suggestion should be to use KStatusNotifierItem. For what it's worth, I created something like that for Qt4 while I was at Canonical: sni-qt [1]. It requires a Qt patch though. The patch is in the sni-qt tarball (and here [2]) Aurélien [1]: https://launchpad.net/sni-qt [2]: http://bazaar.launchpad.net/~indicator-applet-developers/sni-qt/trunk.13.04/view/head:/patches/qsystemtrayicon-plugin-system-4.7.4.diff
Re: KDE Frameworks: Moving toward 5.0 final and Governance
Hello, On Monday 06 January 2014 09:33:38 Martin Graesslin wrote: On Monday 06 January 2014 07:52:50 Kevin Ottens wrote: The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). I have a question concerning the platforms: must a maintainer be able to support/maintain all platforms or can a maintainer say I only maintain the framework for platform foo? That's a good question. In my opinion it's fine for a maintainer to delegate the duties to make things work on a given platform to someone else, but, he has to be able to answer at all time is this platform supported? is there anything broken there?. I think that's important that at the end of the day the maintainer is the point of contact for the given framework. This is a very important point given that our community comes from a Linux background and testing patches on other platforms requires to buy software and/or new hardware. Of course, for most of the frameworks it shouldn't be an issue (if they're pure Qt), that's a very valid concern for frameworks which make native calls. In that case I think it's very important that we're blunt and honest about the situation. I'd rather see a few frameworks where we claim sorry, we don't support platform X yet/at all, than having a list where we claim we support all platforms for all frameworks while we're in fact lying for some of them. To make a very practical example: so far maintainership of KWindowSystem was in the KWin team, but obviously we can only maintain the X11 part of it. To go with that: can a framework be team maintained? E.g. could I write down KWin team or just write down KWin maintainer to bind the maintainership to KWin as it used to be? I'd rather have a person name to be honest. It's really for the single point of contact situation in case of big troubles and to avoid diluting the responsibility. How in practice the work is then distributed for a framework is to the discretion of the appointed maintainer, if there's a whole team helping all the better. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Review Request 114889: Fix KIO::convertSize(...) returning string with (I18N_ARGUMENT_MISSING) inside
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114889/ --- Review request for kdelibs. Repository: kio Description --- Seems the code behind i18n() in kf5 does not like %-placeholders without any arguments passed in the i18n call. And thus inserts the warning. (Effect can be seen e.g. in Okteta's File Info tool). Attached patch fixes that, by delaying the argument substitution as proposed in http://api.kde.org/frameworks-5.x-api/frameworks-apidocs/ki18n/html/prg_guide.html#spec_usage Diffs - src/core/global.cpp 42f453b Diff: https://git.reviewboard.kde.org/r/114889/diff/ Testing --- Results of KIO::convertSize(...) displays fine in Okteta with the patch. Thanks, Friedrich W. H. Kossebau
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014, Kevin Ottens wrote: Hello all, Now that TP1 is almost out of the door, it is time to move toward the final release and put in place the governance of KDE Frameworks. It is a very large and multi-faceted product, so we will need people with longer term commitment if we want it to shine on release day. ## What's left for a final? Short answer: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation (Tasks for Final Release section) To get there, we'll move into a monthly release schedule: * Alpha 1, February 1st; * Alpha 2, March 1st; * Beta 1, April 1st; * Beta 2, May 1st; * Final, June 1st; Between beta 2 and final we'll insert release candidates following a shorter weekly cycle to nail down the remaining minor issues. We don't expect the source code to drastically change between now and final. At least, short term, we shouldn't see code flying from one framework to another one. As you can see most of the tasks revolve around the tooling next to the code (CI, buildsystem, apidox, etc.)... Still there's one big elephant missing there as it's not really something actionable: code quality. I urge everyone, and in particular people volunteering to maintain a framework, to do a pass of review of our code base and APIs to modernize them when appropriate. It is a very big task, and in no way can be coordinated in the way we've been working so far. Maintainers will be a crucial part of a successful code quality review, which leads me to the governance... ## Frameworks Governance? I used to say that the maintenance model of kdelibs was David Faure by default. It's great to have someone like David around, but at the same time it's delusional and dangerous to think that he'll always be able to save the day. This model has to stop now. And hopefully having smaller packages will help people to feel responsible for their modules. The current list of modules is there: http://community.kde.org/Frameworks/List As you can see there's quite some holes in the table, and quite a few entries marked unmaintained. KDE Frameworks as a set of technologies will only be taken seriously if we get something more complete there. I urge everyone with an interest in KDE Frameworks to step up, look at that list and volunteer to maintain a framework. If you volunteer, know that the following will be expected from you: 1) Complete in the table the information regarding your framework; 2) Do an API review and modernization pass in your framework (possibly with the help of others); 3) Stick around for a long period to act as maintainer (see below for details); 4) The day you want to move away from your duties, do so responsibly, don't just disappear, make sure you pass the torch to someone else (probably the most important point in the list!). ### Governance at the framework level At the framework level, the maintainer will be responsible for the quality of the code produced. In particular he'll have to make sure the different policies in place are respected inside his module: http://community.kde.org/Frameworks/Policies In practice that means that the day to day activities (and minimum required from a maintainer) will be to: * Review others' code; * Make sure that his module is always in a releasable state (in particular the CI is always green); * Decide on the direction his module is going in case of conflicts. Note that we're not expecting maintainers to have ideas on features or on a direction to give to the module (of course they can, it's just not required). That means it is fine to be more of the reactive type of maintainer if you want to, letting contributors propose directions and trying to move the lines, you just have to pick one in case of conflicting goals. ### Governance at the KDE Frameworks level Because of the structure of KDE Frameworks (which is already more than 50 modules and that number will likely increase again for 5.1), we also need to have a body that looks at the overall coherency of the whole. My goal here is not to create a huge bureaucracy, so we'll start as small as possible and grow if the need arises. To bootstrap this body, we'll reuse something as close to the status quo as possible. In our case that means that the KDE Frameworks Release Team will start with David Faure and myself. The responsibilities of that team will be the following: * Beating the drum on the product rhythms (mostly the release schedule, but also interim meetings); * Defining the content of the overall product; * Defining the rules of work. All of that in the usual KDE fashion, that is by collecting information from the trenches (that is the maintainers and contributors). IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Alex
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: KDE Frameworks: Moving toward 5.0 final and Governance
On Monday 06 January 2014 23:54:46 Kevin Ottens wrote: On Monday 06 January 2014 22:26:27 Alexander Neundorf wrote: IMO something like proposing the maintainers and approving them, similar to Qt, would be good, i.e. at least some kind of voting by who we will be governed. Definitely something we'll need at some point. For bootstrapping I'm more looking for volunteers ATM, we have more seats to feel than declared candidates... If everything else fails (in other words, if we really want to have a name listed, but nobody else steps up), I am willing to maintain these frameworks: - kiconthemes - kimageformats (including webp plugin from kde-runtime) - kplotting - kwidgetsaddons I may also be interested in kconfigwidgets, kcmutils, kcompletion, and kguiaddons in the future (I don't know the code good enough yet). Christoph Feck (kdepepo)
Re: Review Request 112335: In oxygen: Use the iconSize from mainToolbar
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112335/#review46952 --- Hey hugo, is this in somehow now that oxygen uses KStyle again? - Àlex Fiestas On Aug. 28, 2013, 5:09 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/112335/ --- (Updated Aug. 28, 2013, 5:09 p.m.) Review request for kde-workspace and Hugo Pereira Da Costa. Repository: kde-workspace Description --- In the qplatformplugin we use information from MainToolbar (which makes sense) but in the styles we use information from Toolbar. This unify both by using MainToolbar in styles (if accepted will modify kstyle as well). Diffs - kstyles/oxygen/oxygenstyle.cpp 83aaf5c Diff: https://git.reviewboard.kde.org/r/112335/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 111164: Create FavIconsModule namespace in kdebug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/#review46953 --- This review has been submitted with commit 1346d19ad2716dc69aa612279460ecd4ef0c1234 by Àlex Fiestas to branch master. - Commit Hook On June 21, 2013, 6:55 p.m., Àlex Fiestas wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/ --- (Updated June 21, 2013, 6:55 p.m.) Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Make FaviIconsModule a better neighbor of the KDED community by having its own namespace :p Diffs - lib/konq/favicons/favicons.cpp 45d6c19 Diff: https://git.reviewboard.kde.org/r/64/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 111164: Create FavIconsModule namespace in kdebug
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/64/ --- (Updated Jan. 7, 2014, 5:50 a.m.) Status -- This change has been marked as submitted. Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Make FaviIconsModule a better neighbor of the KDED community by having its own namespace :p Diffs - lib/konq/favicons/favicons.cpp 45d6c19 Diff: https://git.reviewboard.kde.org/r/64/diff/ Testing --- Thanks, Àlex Fiestas
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) What do you mean? It all works fine here. - Luis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Dec. 23, 2013, 4:14 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Dec. 23, 2013, 4:14 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Yes, because the compiler does not read comments. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Dec. 23, 2013, 4:14 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Dec. 23, 2013, 4:14 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Jan. 6, 2014, 5:47 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs (updated) - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Christoph Feck wrote: Yes, because the compiler does not read comments. Thomas Lübking wrote: Aside this, the approach seems too naive? DOIs have a defined structure, leading doi: 10 (ignoring the case and making colon and whitespace optional) and in general the problematic tokens will have a massive digit overhead - so this could be used as additional test ( 25 looksLikeIndex()) @Christoph: Just (finally) understood what you meant with breaking the comment. I uploaded a new patch that (hopefully) fixes the issue in the correct way. @Thomas: The approach was meant to be naive. In this simple form, this patch takes care of all index-like cases as well as most other short garbage titles without further parsing. What would be the point of actually knowing if a very short title was actually a doi or an index? - Luis --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Dec. 23, 2013, 4:14 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Dec. 23, 2013, 4:14 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Christoph Feck wrote: Yes, because the compiler does not read comments. Thomas Lübking wrote: Aside this, the approach seems too naive? DOIs have a defined structure, leading doi: 10 (ignoring the case and making colon and whitespace optional) and in general the problematic tokens will have a massive digit overhead - so this could be used as additional test ( 25 looksLikeIndex()) Luis Silva wrote: @Christoph: Just (finally) understood what you meant with breaking the comment. I uploaded a new patch that (hopefully) fixes the issue in the correct way. @Thomas: The approach was meant to be naive. In this simple form, this patch takes care of all index-like cases as well as most other short garbage titles without further parsing. What would be the point of actually knowing if a very short title was actually a doi or an index? echo The Lord of the Rings | wc -m 22 And that's not a short title - not to mention the typical Stephen King (It) or other languages that use hanzi, kanji or hanja and will never met your arbitrary 25 glyph requirement. Though many academic papers (in western cultures at least) in fact have clumsy long titles, that doesn't hold for other document types. OTOH, if the title (=index) is some (md5, sha*) hash of the text, that will easily outnumber 25 glyphs. So the more honest solution seems to just omit the title field altogether. The alternative (don't know how expensive the document scan is) would be to check whether the title field seems like reasonable text, what could invoke the digit ratio, the longest non-digit sequence (0x12a21f56ea5) and maybe whether there's any digitless word at all. - Thomas --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Jan. 6, 2014, 5:47 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Jan. 6, 2014, 5:47 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Christoph Feck wrote: Yes, because the compiler does not read comments. Thomas Lübking wrote: Aside this, the approach seems too naive? DOIs have a defined structure, leading doi: 10 (ignoring the case and making colon and whitespace optional) and in general the problematic tokens will have a massive digit overhead - so this could be used as additional test ( 25 looksLikeIndex()) Luis Silva wrote: @Christoph: Just (finally) understood what you meant with breaking the comment. I uploaded a new patch that (hopefully) fixes the issue in the correct way. @Thomas: The approach was meant to be naive. In this simple form, this patch takes care of all index-like cases as well as most other short garbage titles without further parsing. What would be the point of actually knowing if a very short title was actually a doi or an index? Thomas Lübking wrote: echo The Lord of the Rings | wc -m 22 And that's not a short title - not to mention the typical Stephen King (It) or other languages that use hanzi, kanji or hanja and will never met your arbitrary 25 glyph requirement. Though many academic papers (in western cultures at least) in fact have clumsy long titles, that doesn't hold for other document types. OTOH, if the title (=index) is some (md5, sha*) hash of the text, that will easily outnumber 25 glyphs. So the more honest solution seems to just omit the title field altogether. The alternative (don't know how expensive the document scan is) would be to check whether the title field seems like reasonable text, what could invoke the digit ratio, the longest non-digit sequence (0x12a21f56ea5) and maybe whether there's any digitless word at all. Honestly I don't even know why there is the rule for needing a space, looking at my shelf of books i can see Cryptonomicon, Azogue, Portico, Hyperion, Endymion, 1984, and then I have stopped. Please, don't try to be that much clever, i can understand if you want to rule out stuff like Microsoft Word - something.doc, but imho you're being already too broad with the rule of it includes microsoft. What about if i have a manual about Microsoft Visual Basic? Honestly omiting or mangling the title is a very bad thing to do. If you have a sensible thing to run over the 1500 test pdf files i have here i'm happy to help. - Albert --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Jan. 6, 2014, 5:47 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Jan. 6, 2014, 5:47 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Review Request 114632: Improve pdf title extraction
On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote: Hm, you broke the comment :) Luis Silva wrote: What do you mean? It all works fine here. Christoph Feck wrote: Yes, because the compiler does not read comments. Thomas Lübking wrote: Aside this, the approach seems too naive? DOIs have a defined structure, leading doi: 10 (ignoring the case and making colon and whitespace optional) and in general the problematic tokens will have a massive digit overhead - so this could be used as additional test ( 25 looksLikeIndex()) Luis Silva wrote: @Christoph: Just (finally) understood what you meant with breaking the comment. I uploaded a new patch that (hopefully) fixes the issue in the correct way. @Thomas: The approach was meant to be naive. In this simple form, this patch takes care of all index-like cases as well as most other short garbage titles without further parsing. What would be the point of actually knowing if a very short title was actually a doi or an index? Thomas Lübking wrote: echo The Lord of the Rings | wc -m 22 And that's not a short title - not to mention the typical Stephen King (It) or other languages that use hanzi, kanji or hanja and will never met your arbitrary 25 glyph requirement. Though many academic papers (in western cultures at least) in fact have clumsy long titles, that doesn't hold for other document types. OTOH, if the title (=index) is some (md5, sha*) hash of the text, that will easily outnumber 25 glyphs. So the more honest solution seems to just omit the title field altogether. The alternative (don't know how expensive the document scan is) would be to check whether the title field seems like reasonable text, what could invoke the digit ratio, the longest non-digit sequence (0x12a21f56ea5) and maybe whether there's any digitless word at all. Albert Astals Cid wrote: Honestly I don't even know why there is the rule for needing a space, looking at my shelf of books i can see Cryptonomicon, Azogue, Portico, Hyperion, Endymion, 1984, and then I have stopped. Please, don't try to be that much clever, i can understand if you want to rule out stuff like Microsoft Word - something.doc, but imho you're being already too broad with the rule of it includes microsoft. What about if i have a manual about Microsoft Visual Basic? Honestly omiting or mangling the title is a very bad thing to do. If you have a sensible thing to run over the 1500 test pdf files i have here i'm happy to help. Would it make sense to refactor the code to use the (PDF supplied) document title, and, if for whatever reason it is believed to be wrong, append the extracted text that is believed to be a better title? - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/#review46156 --- On Jan. 6, 2014, 5:47 p.m., Luis Silva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114632/ --- (Updated Jan. 6, 2014, 5:47 p.m.) Review request for Baloo and Vishesh Handa. Repository: kfilemetadata Description --- A good portion of scientific papers in my collection had a doi or an index number in the title. These are in general short string chains, shorter than the real title. I improve extraction of titles from pdf's by setting a minimum size below which parsing of the first page is forced. The cut-off size is arbitrarily set to 25 characters (three big words). Diffs - src/extractors/popplerextractor.cpp b056581f51d10b632799586eed3cc15ac539fe80 Diff: https://git.reviewboard.kde.org/r/114632/diff/ Testing --- This improved the title extraction on my pdf collection of scientific papers by quite a lot. Thanks, Luis Silva Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: [Kde-hardware-devel] Review Request 114393: Add support for logind interfaces on upstart = 1.11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114393/#review46941 --- Has this been submitted? if so, please close the review. - Àlex Fiestas On Dec. 18, 2013, 6:54 p.m., Rohan Garg wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114393/ --- (Updated Dec. 18, 2013, 6:54 p.m.) Review request for Solid, Àlex Fiestas and Harald Sitter. Repository: kde-workspace Description --- Upstart implemented logind API's and powerdevil can use these interfaces on upstart systems by just fixing the check for the version inside the upower daemon. Diffs - powerdevil/daemon/BackendConfig.cmake 71eeef3 powerdevil/daemon/backends/upower/dbus/com.ubuntu.Upstart.xml PRE-CREATION powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp ab53ffd Diff: https://git.reviewboard.kde.org/r/114393/diff/ Testing --- System suspends to disk and RAM System resumes successfully. Thanks, Rohan Garg ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 107415: [High-dpi issues] Fix BluetoothDevicesDelegate with huge fonts and icon sizes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/107415/#review46944 --- Kai can you finish the patch please? I'd like to include it in next releases. Thanks ! - Àlex Fiestas On Feb. 11, 2013, 10:50 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/107415/ --- (Updated Feb. 11, 2013, 10:50 p.m.) Review request for Bluedevil, Àlex Fiestas and Michael Zanetti. Repository: bluedevil Description --- This fixes bluetooth devices delegate having overlapping fonts and small icons when using them with high dpi settings and big icon sizes, which is likely on high-dpi screens such as the Macbook Pro Retina. Diffs - src/kcmodule/bluedevildevices.cpp 86accf5 Diff: https://git.reviewboard.kde.org/r/107415/diff/ Testing --- Tested with up to 200 dpi and bigger icons. This does not fix the initial problem but is an easy fix for the most common case (ie. if I have huge fonts I am likely to have huge icons as well, so when the icons are bigger, the fonts don't overlap if they are bigger as well). Since there is no 48px default size, I am using Dialog icon size (default is 32) and multiply it by 1.5 to get the 48 which matches SizeLarge. Screenshots --- Bluedevil with 200 dpi https://git.reviewboard.kde.org/r/107415/s/846/ Thanks, Kai Uwe Broulik ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 114160: Fix segmentation fault when no address is given in input
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114160/ --- (Updated Jan. 7, 2014, 5:35 a.m.) Status -- This change has been discarded. Review request for Bluedevil and Àlex Fiestas. Repository: bluedevil Description --- Invoking bluedevil-audio with no args causes a segfault. Diffs - src/actionplugins/audio/helper/main.cpp 633608ef297c2253382cfc111253a5f116f535b9 Diff: https://git.reviewboard.kde.org/r/114160/diff/ Testing --- It doesn't start bluedevil-audio anymore if no argument is given. Thanks, Andrea Scarpino ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 114172: Fix wrong signals/slot connection
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114172/#review46947 --- Ship it! Ship It! - Àlex Fiestas On Nov. 28, 2013, 8:35 a.m., Andrea Scarpino wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114172/ --- (Updated Nov. 28, 2013, 8:35 a.m.) Review request for Bluedevil and Àlex Fiestas. Repository: bluedevil Description --- Fix some wrong connection between non-existant signals and slots. I don't know the right way to fix: connect(adapter, SIGNAL(devicesChanged(QListDevice*)), this, SLOT(adapterDevicesChanged())); maybe this way? connect(adapter, SIGNAL(deviceChanged(Device*)), this, SLOT(adapterDevicesChanged())); Diffs - src/actionplugins/sendfile/helper/discoverwidget.cpp 84756a3 src/kcmodule/bluedevildevices.cpp 68ccdb2 src/monolithic/monolithic.cpp 12e1d73 Diff: https://git.reviewboard.kde.org/r/114172/diff/ Testing --- Thanks, Andrea Scarpino ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 114280: make libbluedevilaction library private
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114280/ --- (Updated Jan. 7, 2014, 5:36 a.m.) Status -- This change has been discarded. Review request for Bluedevil, Àlex Fiestas and Pino Toscano. Repository: bluedevil Description --- Patch from Debian Author: George Kiagiadakis kiagiadakis.geo...@gmail.com Author: Pino Toscano p...@debian.org Description: Modifies CMakeLists.txt so that libbluedevilaction.so is installed in a subdirectory of /usr/lib, as recommended by the Debian policy and sets RPATH for everything that uses this library. In addition, the command to install actionplugin.h is removed. Forwarded: not-needed Last-Update: 2013-05-17 Diffs - src/actionplugins/CMakeLists.txt d4b0f62 src/actionplugins/audio/CMakeLists.txt 9613a89 src/actionplugins/audio/helper/CMakeLists.txt 0f18cc2 src/actionplugins/input/CMakeLists.txt ded9635 src/actionplugins/input/helper/CMakeLists.txt 7b137fe src/actionplugins/networkdun/CMakeLists.txt 41c57b3 src/actionplugins/networkdun/helper/CMakeLists.txt 17883d1 src/actionplugins/networkpanu/CMakeLists.txt de76aa4 src/actionplugins/networkpanu/helper/CMakeLists.txt f099f29 src/actionplugins/sendfile/CMakeLists.txt c7ea5a7 src/wizard/CMakeLists.txt 7036411 Diff: https://git.reviewboard.kde.org/r/114280/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 108503: Add link to Downloaded Files directory in kio bluetooth
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108503/#review46949 --- Is the added i18n string already in the catalog? If so please commit to Master. If I will ask Albert first. - Àlex Fiestas On Feb. 11, 2013, 10:14 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108503/ --- (Updated Feb. 11, 2013, 10:14 p.m.) Review request for Bluedevil and Àlex Fiestas. Bugs: 302964 https://bugs.kde.org/show_bug.cgi?id=302964 Repository: bluedevil Description --- This patch adds a link to the folder configured for Download folder to the bluetooth:/ kio. Maybe makes sense to also add the Shared Files folder. Diffs - src/kio/bluetooth/CMakeLists.txt ef1f1e2 src/kio/bluetooth/kiobluetooth.h f5035c5 src/kio/bluetooth/kiobluetooth.cpp a70eca1 Diff: https://git.reviewboard.kde.org/r/108503/diff/ Testing --- Works, directory opens, even displays thumbnails and the user-configured folder icon (if used, which I do in my case). Folder text also gets translated if translation available. Only thing I want: the folder should always appear as first item. But probably not possible because those are all folders and so are sorted alphabetically Thanks, Kai Uwe Broulik ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 108503: Add link to Downloaded Files directory in kio bluetooth
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108503/#review46950 --- Ship it! Ship It! - Àlex Fiestas On Feb. 11, 2013, 10:14 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108503/ --- (Updated Feb. 11, 2013, 10:14 p.m.) Review request for Bluedevil and Àlex Fiestas. Bugs: 302964 https://bugs.kde.org/show_bug.cgi?id=302964 Repository: bluedevil Description --- This patch adds a link to the folder configured for Download folder to the bluetooth:/ kio. Maybe makes sense to also add the Shared Files folder. Diffs - src/kio/bluetooth/CMakeLists.txt ef1f1e2 src/kio/bluetooth/kiobluetooth.h f5035c5 src/kio/bluetooth/kiobluetooth.cpp a70eca1 Diff: https://git.reviewboard.kde.org/r/108503/diff/ Testing --- Works, directory opens, even displays thumbnails and the user-configured folder icon (if used, which I do in my case). Folder text also gets translated if translation available. Only thing I want: the folder should always appear as first item. But probably not possible because those are all folders and so are sorted alphabetically Thanks, Kai Uwe Broulik ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] Review Request 109491: Set as active only Activated ActiveConfigs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/109491/ --- (Updated Jan. 7, 2014, 5:42 a.m.) Status -- This change has been marked as submitted. Review request for Solid. Repository: networkmanagement Description --- Only set as active the ActiveConnection with Activated status Diffs - connection-editor/connectioneditor.cpp 7fe21b1 Diff: https://git.reviewboard.kde.org/r/109491/diff/ Testing --- Thanks, Àlex Fiestas ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
