Re: Gitlab Evaluation & Migration
On Monday, 25 February 2019 09:12:47 CET Eike Hein wrote: > On 2/25/19 4:31 AM, Martin Flöser wrote: > > Changing the tooling will not solve any of the contribution problems. > > I'm aware of several projects who would like to incubate with KDE.org > (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new > contributor ecosystems) but are waiting for the outcome of this > decision, because they believe being part of KDE wouldn't be worth the > cost of losing access to contributors that Phabricator imposes to them. > > It's difficult to get hard data on this, of course. From Gnome I've been > told their contributon numbers from new contributors have seen a massive > uptick since adopting GitLab, however their infra pre-GitLab was (to me) > worse than Phabricator. > > It's unclear to me what exactly would happen for us. However, it seems > clear to me that the world outside of the existing cadre of KDE > contribtors has a consensus on this: When the news about the GitLab eval > leaked to Reddit and other venues, "finally I'll be able to submit my > patch" was a recurring theme. > > One thing that strikes me is that KDE upstream relations have usually > been a defining trait of our tooling decisions. We've adopted things > like gitolite, CMake and even Qt based on having an upstream to talk to. > This is currently not the case with Phabricator, but it is the case with > GitLab. I'm hesistant of saying it's awesome just yet (there's some > features in the GitLab Enterprise Edition we would like GitLab to move > to the Community Edition for us, and it's not been decided there yet), > but they've done regular calls with us, opened a master ticket to track > our account with them, and have multiple times expressed an interest in > attending KDE's upcoming Onboarding sprint. This is very nice. > > It's also worth noting that we're the only big FOSS player using > Phabricator at the moment. To contribute to KDE, people have to learn > Phabricator. If they've already contributed to freedesktop, Gnome, or > hundreds of other projects, they've already learned GitLab. > > My personal take is this: I'm used to Phabricator and fine with it. It > doesn't impede my work. But I think it would be a mistake to make this > decision based on what I'm fine with, because I'm equally able to adjust > to GitLab and be fine with that. I'd rather make this decision based on > what people who aren't KDE contributors yet find attractive, and that > seems overwhelmingly in GitLab's favor from everything I've read and > heard. New contributors showing up would affect me a lot more than > having to adjust to typing a different command does. > > I also have reason to believe this delta between "I'm fine with it" and > "Others want X" is only going to increase based on the relative > development speeds of Phabricator and GitLab. The latter seems more > likely to keep up with the state of the art currently. I'd like KDE to > be on board with the state of the art. Heya, +1 on everything Eike said. I think adopting GitLab will be a huge benefit for KDE. Some two-digit million amount of projects hosted on GitLab+GitHub+BitBucket (systems which all share the same "workflow" principles) cannot be wrong. At least there are /tons/ of developers out there which are familiar with them by heart, which makes it super easy for them to contribute to KDE, in theory. Even after having worked a couple of years with Phabricator's review system it stills feels alien to me, mostly b/c it does not integrate that well with Git. I always get slight shivers when having to work with it. I'm contributing to several other projects on either GitLab, GitHub, BitBucket, and the whole experience is simply better. I think there's no doubt about that. The move to yet another system is ambitious but let's rather do it sooner than later. Looking forward to GitLab adoption across the board! Thanks for the effort, guys! Cheers, Kevin > Cheers, > Eike -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: vnc client keyboard mapping
On Tuesday, 31 July 2018 09:02:49 CEST Stéphane Ancelot wrote: > Hi, > > I don't manage to have my local client keyboard mapping when I connect > to vnc server (x11vnc) in a kde plasma system. > > Are there some settings needed in order to make it recognized ? Are you maybe running into this problem here? https://unix.stackexchange.com/questions/346107/keyboard-mapping-wrong-only-in-specific-applications-under-tightvnc I suggest trying out TurboVNC or TigerVNC as VNCServer. Using TigerVNC solved this issue for me -- it's very easy to install on a Linux system. (see https://github.com/TigerVNC/tigervnc/releases) Regards, Kevin > Is it supported in KDE plasma (that works fine in other systems.) > > Regards, > > S.Ancelot -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Unable to compile KWidgetsAddons
On Thursday, 29 March 2018 15:53:25 CEST Nate Graham wrote: > In trying to test out a KWidgetsAddons patch, I find that I'm unable to > compile it on KDE Neon dev unstable the code due to a CMake error: > > > CMake Error in autotests/CMakeLists.txt: >No known features for CXX compiler > >"GNU" > >version 5.4.0. > > Full output available at https://paste.kde.org/piyy4wsnl Heya, FYI: The compile-feature [1] is used by the CMake Config files installed by Qt. For Qt it is used to figure out when and how to pass the i.e. the resp. `- std=...` flag for GNU-like compilers for users of Qt. Usually you get that kind of error in case you're trying to use an unsupported compiler for which CMake doesn't know the availability of the C++ features. A typical example is Android GCC. I'm surprised you get that error by a standard GCC...? Would be nice to figure out what's going wrong. Maybe `cmake --trace` or `cmake --debug-output` can help. Please check the following link for a work-around: https://stackoverflow.com/a/40256862/592636 [1] https://cmake.org/cmake/help/v3.8/manual/cmake-compile-features.7.html Regards, Kevin > My g++ version looks okay: > > $ g++ --version > g++ (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 > Copyright (C) 2015 Free Software Foundation, Inc. > > > Nate -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: releaseme new requirement: non-conflicting files on case-insensitive FS/OS
On Tuesday, 21 November 2017 14:24:04 CET Felix Miata wrote: > Sven Brauch composed on 2017-11-21 12:25 (UTC+0100): > > Felix Miata wrote: > >> Case sensitive filesystems are one of the most annoying things about > >> FOSS. > > > > I'd count that as a win. > > InsaniTY > INSaniTy > InSAnItY > inSANity > INsANItY > INSANiTY > iNSaNiTy > InsAnItY > > Boss: Worker, please get me the insanity file. > > Worker: which one Boss? > > Boss: The one spelled I N S A N I T Y! > > Worker: There's at least 8 spelled that way! > > Boss: How is that possible? > > Worker: A & a sound the same, B & b sound the same, C & c sound the same, ad > nauseum. There's no rhyme or reason for the case differences. It's > anarchistic. *yawn*. Really, that discussion is completely moot. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: releaseme new requirement: non-conflicting files on case-insensitive FS/OS
On Monday, 20 November 2017 16:50:58 CET Harald Sitter wrote: > Guten Abend Everyone! > > To aid with use of our tarballs on Windows and case-insensitive file > systems, releaseme now makes sure [1] that the tarballs it generates > are safe to use in such contexts. Thanks for helping out on that front! Regards, Kevin > As this is a major problem for pretty much every source tarball as it > prevents people from doing Windows builds and/or unpack on exfat/fat32 > this is considered a fatal flaw in the tarball. To that end if you use > releaseme you may want to run tarme now so your next release doesn't > get held up by case-insensitive file conflicts. > > If you have any questions please do ask. > > [1] > https://phabricator.kde.org/R572:0936ab0e02551fe6d3e8ad07b97cd7d7d3d26838 > > HS -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Is there interest in participating in Google Code-in this year?
On Thursday, 12 October 2017 23:15:27 CEST Valorie Zimmerman wrote: > Hello folks, when I've written about GCi before this, I got few to no > replies. My feeling is that previous enthusiastic mentors are without > the energy and time to participate this year. Heya, I also feel that for KDevelop we'd rather be taking a break this year. The last years with GCI have been reaaally exhaustive; managing a bunch of students who have looots of questions all day :) And also, working on KDevelop tasks usually requires a very good understanding of Qt/C++ which is sometimes difficult to demand from 14-17 years olds. And life's getting more busy over here, so I'm afraid we'll have to skip participating here. *If* it's going to happen we'll try to come up with tasks, there's no pressure to participate from our side at least. Sorry, Kevin > Org applications are open, but unless I hear a swell of enthusiasm > here, I'm inclined to not apply. > > Thoughts? > > Valorie, for Student Programs admin team -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: How to start contributing?
On Friday, 29 September 2017 13:36:53 CEST rhkra...@gmail.com wrote: > On Friday, September 29, 2017 04:41:57 AM Tomaz Canabrava wrote: > > Seriously, it's that. > > We can't say to you "do that change in my software" because it's > > opensource, you work on what you want and like. > > Well, actually we could tell you (or suggest to you) things to work on. > > Do you have an interest in some application--is there something in some open > source application which you don't like or doesn't work as well as you'd > like? You could start looking into that. > > Or, if you don't have anything in mind, I have a few things in mind. One of > them would be a lexer for a variation of the TWiki markup language for the > Scintilla editing widgit / control / thingie, to be written in C++. > > If you're interested, let me know, and I'll tell you more. > > You may want to check out scintilla.com, and join the scintilla-interest > mail list (on googlegroups). Dead link. And since when is Scintilla a KDE project? Regards, Kevin > Randy Kramer -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Cant build KDE EDU Blinken from source code
On Monday, 5 June 2017 13:37:28 CEST Aman Gupta wrote: > I'm trying to build Blinken using the source but am getting an error > regarding Phonon4qt5 which i'm not able to resolve. I've attached a > screenshot with this mail which shows the error. I hope someone may please > reach out to me for help. Next time please include more information: - What distro - Which version of Blinken Also, please paste the compilation/configure error in *text* form so one can easily copy from it. Anyhow, from your screenshot one can deduce you're using Ubuntu. CMake reports you're missing libphonon4qt5experimental.so.4.8.3. => Check which package provides this file, e.g. with 'apt-file': % apt-file search phonon4qt5experimental.so libphonon4qt5experimental-dev: /usr/lib/x86_64-linux-gnu/ libphonon4qt5experimental.so libphonon4qt5experimental4: /usr/lib/x86_64-linux-gnu/ libphonon4qt5experimental.so.4 libphonon4qt5experimental4: /usr/lib/x86_64-linux-gnu/ libphonon4qt5experimental.so.4.8.3 => Solution: Install libphonon4qt5experimental4 via apt-get. Hope that helps, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Commit notifications
On Monday, 13 March 2017 13:57:01 CET Kåre Särs wrote: > Hi, Heya, > I want to do some changes to what git commit notifications I get and I > have searched the KDE web-pages to find the information on how to do > it, but no luck :( > > Almost all places I have searched mention commitfilter.kde.org, but that > server has been shut down some time go already. > What is the new place for this? There is none. commitfilter is still sending out mails, but there's no configuration interface anymore. That's sad. :( I'd welcome a resurrection or an alternative to commitfilter. Bhushan (CC'd) wanted to start writing a new interface -- any progress in this regard? Cheers, Kevin > Regards, > Kåre -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: KF5-based kdesvn doesn't display the authorization dialog
CC'ed maintainer. I'm not sure he's reading kde-devel@. On Sunday, 29 January 2017 09:24:26 CET Safa Alfulaij wrote: > Hello world. > > I have updated my *kdesvn* from KDE4 to KF5 recently, but didn't tried to > use it back then. > I'm having a problem that is that kdesvn doesn't ask me for my ssh > password, and just displays the common error in the errors box: > > Unable to connect to a repository at URL 'svn+ssh://s...@svn.kde.org/home/kde > > ' > > To better debug SSH connection problems, remove the -q option from 'ssh' > > in the [tunnels] section of your Subversion configuration file. > > Filling log cache in background finished. > > I tried running it from the terminal, and I saw that the it is requesting > my password from there "*Enter passphrase for key '/home/safa/.ssh/id_rsa':* > "! > I entered the password and it worked for caching log entries (that progress > bar appears now, which did not before when started graphically). > For updating to HEAD, I see 3 password promots, and entering my password > whatever number of times doesn't work. > > Is this a bug? *kdesvnaskpass* is installed and works when executed from > terminal. > > Regards, > Safa -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Kdevelop5 - Xdebug
On Wednesday, 28 December 2016 19:57:26 CET Rick Timmis wrote: > Hello KDE Devs > > Thank you for the work you have been doing on Kdevelop. Thank you Kevin, > I especially appreciated your Blog post on building Kdevelop from source. > > http://kfunk.org/2016/02/16/building-kdevelop-5-from-source-on-ubuntu-15-10/ > > I have been trying to get kdev-xdebug to compile for KF5, but getting > very stuck ( My lack of knowledge ) Heya Rick, Regarding kdev-xdebug: Unfortunately this hasn't been ported over to Qt5/KF5 yet. > I have been advised by the Kubuntu Developers to contact kde-devel for > your advice. I'm CC'ing kdevelop-de...@kde.org, which is the better place for this discussion. > Are you aware of a port to KF5 for this tool ? No-one stepped up so far to do it, but you're welcome to give it a try. Porting should be pretty straight forward, just follow the changes we did in e.g. kdevelop.git for other plugins. > It looks to me as though it just needs appropriate changes to the > CMakeLists.txt file, am I correct ? > > Are there any other Gotcha's or things I need to be aware of ? > > Currently I am referencing the following doc's, am I looking in the > right place ? > > https://techbase.kde.org/KDevelop5/KDevPlatformPluginExample As said above, I'd rather have a look at the changes done in e.g. kdev- python.git or kdevelop.git. That'll get you started quickly. Here are the porting notes for porting towards KF5 in case you're experiencing problems: https://community.kde.org/Frameworks/Porting_Notes (super helpful) Hope that helps. Looking forward to a kdev-xdebug port to KF5! :) Cheers, Kevin > Many Thanks > > Rick -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Dropping the svn kio from kdesdk-kioslaves
On Friday, 16 December 2016 06:31:46 CET Christian Ehrlicher wrote: > Am 15.12.2016 um 23:12 schrieb Kevin Funk: > > On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote: > >> Why? > >> > >> * It doesn't compile with newer libsvn > >> * It's kdelibs4-based > > > > Heya, > > > > I know a few people that use kdesvn, how's the relation to that? > > > > I saw that Christian (CC'ed) put quite some effort in porting kdesvn over > > to a KF5-based kdelibs4support-free code base. If I understand correctly > > kdesvn.git even contains a copy of the KIO SVN implementation (c.f. > > kdesvn.git:src/ kiosvn)? > > > > Please elaborate :) > > You're correct - kdesvn contains a kioslave for svn and I ported it to > KF5 (just released kdesvn 2.0.0 some days ago). I don't know if > kdesdk-kioslaves has more functionality but from my point of view it can > be dropped. If the SVN kioslave is standalone, wouldn't it make more sense to actually keep it in a separate repository/package? So users who just want the Dolphin integration can just use that? Wouldn't it make more sense to move your kioslave implementation into kdesdk- kioslaves, replacing the older copy? I'm not sure whether Albert just wants to kill the repository or he's just phasing old unmaintained software. In case of the latter, updating the copy with the better maintained version probably makes more sense. Cheers, Kevin > Cheers, > Christian -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Dropping the svn kio from kdesdk-kioslaves
On Thursday, 15 December 2016 22:14:38 CET Albert Astals Cid wrote: > Why? > * It doesn't compile with newer libsvn > * It's kdelibs4-based Heya, I know a few people that use kdesvn, how's the relation to that? I saw that Christian (CC'ed) put quite some effort in porting kdesvn over to a KF5-based kdelibs4support-free code base. If I understand correctly kdesvn.git even contains a copy of the KIO SVN implementation (c.f. kdesvn.git:src/ kiosvn)? Please elaborate :) PS: /me never uses SVN directly usually. Cheers, Kevin > Any disagreement on dropping it? > > Cheers, > Albert -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: What in plasma/fw5 monitors laptop function keys for backlight control?
On Tuesday, 6 December 2016 21:57:29 CET David C. Rankin wrote: > All, > > Plasma/fw5 key-stroke handler is properly monitoring the 'function-F9' and > 'function-F10' keys for backlight control (brightness down/up). However, > when using the nvidia driver, the keystrokes are translated into updating > the following in sysfs: > > /sys/class/backlight/acpi_video0/brightness > > instead of > > /sys/class/backlight/nvidia_backlight/brightness > > Setting the first (range 0-20) has no effect on backlight and must be > translated to a range of 0-127 for the nvidia setting. Where would I look in > the source code to find what is handling the brightness function keys? > kdelibs? kdebase? Heya, You might want to have a look at the Powerdevil sources, e.g.: powerdevil.git:daemon/backends/upower/backlighthelper.cpp [1] Hope that helps, Kevin [1] https://cgit.kde.org/powerdevil.git/tree/daemon/backends/upower/ backlighthelper.cpp -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Dropping kdelibs4-based applications in KDE Applications 17.12
On Thursday, 17 November 2016 00:51:50 CET Sven Brauch wrote: > On 11/11/16 16:45, Dominik Haumann wrote: > > What do you think about having a Randa meeting (or similar) with focus > > on finishing ports to KF5? Would that make sense? > > +1 actually. There are a few applications on that list which would, in > my eyes, be a real loss if they were not maintained any more; I'm > especially looking at kcachegrind (I know of no comparable tool and it's > really good), maybe kopete. kmag is nice too on occasion but I don't > know if it will die with wayland anyways. +1 on kcachegrind, that would be a real loss. Actually there's an actively maintained frameworks branch, maybe we just need to poke Josef? ;) @Josef: Is the frameworks branch stable? If yes, let's release! > I'd be in for a sprint (or a few days of a sprint) to port those. Consider me in as well. Cheers, Kevin > Greetings, > Sven -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: ktexteditor crash opening a specific file
On Wednesday, 9 November 2016 11:12:47 CET Tomaz Canabrava wrote: > Tracked to file kateviewinternal.cpp, line 1415, hits this assert: > Q_ASSERT(thisLine.virtualLine() == virtualCursor.line()); > > I tried to open the file with another editor just to create a simplified > version of it that I could send, and now I cannot trigger the assert > anymore even with the original file, sigh. > how should I track this down? > Tomaz CC'ed the correct mailing list -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Scrap Baloo Thread Feedback
On Friday, 7 October 2016 17:24:26 CEST Vishesh Handa wrote: > Hey guys > > I was told there is a thread about scrapping Baloo. All Baloo > discussion used to happen on kde-devel and that's where the review > requests go. It's the only reason I am still subscribed to kde-devel. Heya, Baloo is a framework nowadays, therefore it totally makes sense to have the discussion on kde-framework-devel. There's been tons of discussion around Baloo on kde-framework-devel already. kde-frameworks-devel is also where the CI messages for the baloo repo go to. It likely makes sense for you to subscribe, no? Cheers, Kevin > (snip) -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Installation of KDE5 in ubuntu 14.04
On Thursday, June 2, 2016 12:02:33 PM CEST Martin Graesslin wrote: > On Thursday, June 2, 2016 1:01:53 PM CEST Sayan Biswas wrote: > > Hi, > > > > I was trying to install plasma 5 in my ubuntu 14.04.. Can anyone tell me > > what will be the exact process because I have gone through a lot of > > procedures available but none is providing a solid answer for it. I know > > there is some problem with the PPA and the neon 5. Can someone help me > > with > > this? > > Hi, > > I suggest you to not try to install plasma 5 in 14.04. Better upgrade to the > new LTS version which already includes Plasma 5. > > I have here one system with 14.04 and decided against that as I just don't > expect it will be a good experience. +1. I'd definitely recommend to upgrade to 16.04 LTS. Cheers, Kevin > Cheers > Martin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Review Request 127727: There is no QT_LSTAT on Windows, use QT_STAT and follow symlink (if needed), only on Windows, instead.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127727/#review94801 --- Ship it! Ship It! - Kevin Funk On April 23, 2016, 4:44 p.m., Andrius da Costa Ribas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127727/ > --- > > (Updated April 23, 2016, 4:44 p.m.) > > > Review request for Baloo and kdewin. > > > Repository: baloo > > > Description > --- > > This fixes compilation on Windows, where QT_LSTAT is not available. > > > Diffs > - > > src/engine/idutils.h 7c4f898 > > Diff: https://git.reviewboard.kde.org/r/127727/diff/ > > > Testing > --- > > Fixes compiling error on MSVC 2015. No further testing done. > > > Thanks, > > Andrius da Costa Ribas > >
Re: Review Request 127726: Fix EXPORT usage.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127726/#review94792 --- Ship it! Ship It! - Kevin Funk On April 23, 2016, 4:44 p.m., Andrius da Costa Ribas wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127726/ > --- > > (Updated April 23, 2016, 4:44 p.m.) > > > Review request for Baloo and kdewin. > > > Repository: baloo > > > Description > --- > > The export macro should not be used in the namespace declaration. > > > Diffs > - > > src/engine/global.h aba5495 > > Diff: https://git.reviewboard.kde.org/r/127726/diff/ > > > Testing > --- > > Fixes compiling error on MSVC 2015. No further testing done. > > > Thanks, > > Andrius da Costa Ribas > >
Re: Configuring a prefix
On Friday, March 18, 2016 12:22:45 AM CET Aleix Pol wrote: > Hi, > One of the weirdest tasks for newcomers is probably the setting up of > a new prefix. It requires setting quite some environment variables > that are often not trivial and it's always a really boring task. > > At some point, out of such frustration, I created this little cmake > project that creates a prefix.sh file that can be "sourced" easily. > > If anyone thinks it's useful, please use it. If changes are needed, > let's change it. > https://quickgit.kde.org/?p=scratch%2Fapol%2Fprefixsetup.git > > Happy hacking! > Aleix Thanks for your effort! IMO this needs to be part of kdesrc-build, one way or the other, in order to be useful. The setup of kdesrc-build needs to made as *easy* as possible; since that is what we tell newcomers to use. As I've said elsewhere already, in a perfect world you have to just download a kdesrc-build tarball (or git archive) and invoke a wizard-like script which sets up everything in one go. Cheers, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Trouble in setting up qt libraries in emerge
On Wednesday, March 16, 2016 9:50:12 AM CET Alexander Semke wrote: > > I download qt libraries and install it > > the command : > > emerge qt ; > > the error : > > emerge error: SHA1 hash for file C:\k\download\svn-win32-1.8.8-1.zip > > (e9b72154fcd3fdd28c23a3ee64d33ba1a08714b0) does not match > > (917f34143b259d8f03a9860a5c5996ba6943abc6) > > The last line with "emerge error" states the actual problem, doesn't it? > It's about svn for windows and not about Qt. Looks like something is wrong > with your setup, emerge expects another version of the file than you're > trying to install. This is neither related to Qt, nor to KDE. Well, it surely is KDE-related since Emerge is a KDE project. We already handled the issue on kde-wind...@kde.org, though. @Reporter: Please don't cross-post, if you have troubles with Emerge then mailing kde-wind...@kde.org is sufficient. Cheers, Kevin > Alexander -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: Developing a new KIO Slave (GSoC 2016)
On Thursday, January 21, 2016 10:30:18 AM Luca Ferrari wrote:
> On Wed, Jan 20, 2016 at 11:08 AM, Arnav Dhamija
wrote:
> > My solution to this problem is to add a Places option in Dolphin where the
> > links to files and folders can be temporarily saved for a session. The
> > files and folders are "staged" on this panel. Files can be added to this
> > tray by using a right-click context menu option, using the mouse scroll
> > click, or drag and drop. As an additional option, the session for the
> > File Tray Panel can be saved for later use. Hence, complex file
> > operations such as moving files across many devices can be made easy by
> > staging the operation before performing it.
>
> Maybe I'm misunderstanding your proposal, but the first thing that
> comes into my mind is to build this feature on top of tags: assign a
> special tag to files in different locations and then filter by tags,
> copy, paste (and optionally remove the special tag).
+1. Exactly my thought.
This is a common way to organize your image galleries. Digikam has great
support for this kind of usage scenario.
You first go through an arbitrary list of images (not necessarily in the same
directory), label each of them as you wish (I think Digikam offers Alt+{1,2,3}
shortcuts), and then just filter by label and do the move operation.
I don't see why this particular feature needs a dedicated KIO slave.
Greets,
Kevin
> Another approach, less intuitive, could be to use the clipboard
> content: if you select "copy" from right click menu on one file at
> time, without pasting it, the clipboard content stores the selected
> files. You can then pop from the clipboard all the "mark for copy"
> files later.
>
> Hope this helps.
> Luca
> ___
> Kde-soc mailing list
> kde-...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-soc
--
Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: robots.txt in quickgit.kde.org
On Wednesday, January 06, 2016 10:30:52 AM Ben Cooksley wrote: > On Wed, Jan 6, 2016 at 3:17 AM, Kevin Funk wrote: > > On Wednesday, December 30, 2015 12:57:23 PM Ben Cooksley wrote: > >> On Tue, Dec 29, 2015 at 11:16 PM, Kevin Funk wrote: > >> > On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote: > >> >> On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher wrote: > >> >> > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley > > > > wrote: > >> >> >>> Is there some place where search engines can easily index our > >> >> >>> source > >> >> >>> code or are we shooting ourselves in the foot here? > >> >> >> > >> >> >> We could probably make it available by publishing the source trees > >> >> >> used by LXR / EBN. > >> >> >> This would only have the main branches obviously rather than > >> >> >> everything > >> >> >> though. > >> >> >> > >> >> >> I haven't checked, but LXR may already make it's copy of the code > >> >> >> accessible...> > >> >> > > >> >> > I think making our sourcecode available to search engines is pretty > >> >> > important for the reasons already mentioned by others. Do you need > >> >> > help for it? If you write down what's needed I can help find someone > >> >> > to do it. > >> >> > >> >> I've now provisioned https://sources.kde.org/ > >> > > >> > I'm not sure this is super useful, to be honest (as mentioned in #kde- > >> > sysadmins already). > >> > > >> > This is really just plain file serving, with no cross-references to > >> > either > >> > LXR (or apidocs). This is basically a dead-end when you follow a result > >> > on Google. > >> > > >> > Wouldn't it be possible to let robots index https://lxr.kde.org/source/ > >> > > >> > instead? We have the infrastructure... > >> > >> We'll give it a shot. > > > > Just to stress again this would be *really* useful to have. > > Ah, I see robots.txt on lxr.kde.org allows crawling source/ now. Thanks! > > I answered a post on SO: > > http://stackoverflow.com/a/34612692/592636 > > > > Tried to link kwallet's FindGpgpme.cmake into the answer; and there's *no* > > easy way quickly get a link to KDE infrastructure serving the file via > > Google (not even api.kde.org). > > > > Try googling for "kwallet findgpgme.cmake" (very specific search after all): > > https://www.google.de/search?q=kwallet+findgpgme.cmake > > > > -> First result: Github..., rest: mildly interesting > > > > > > Different issue I just noticed: There's no way to get the plain-text (raw) > > representation of a given file on LXR, is there? Would be useful as well. > > There isn't a link in our templates, but my Google fu (and subsequent > tests confirm) that adding the parameter "_raw=1" to a LXR source view > URL will return the file without any HTML around it. > > > Cheers, > > Kevin > > Regards, > Ben > > >> > Of course we need to blacklist all the pages allowing to actively > >> > *search* > >> > LXR for robots, in order to avoid abuse. > >> > >> Note that despite robots.txt, many spiders (including Google, Yahoo > >> and Bing) will actively disregard the instructions in there. > >> While they may not return the results - or omit snippets of the page > >> content - they have all been guilty (at least in the past) of > >> disregarding our restrictions, resulting in downtime (which have in > >> some cases necessitated full host reboots to fix) for numerous KDE.org > >> subsites in the past. > >> > >> This is why QuickGit and WebSVN have extremely restrictive robots.txt > >> policies, in addition to blacklist rules within our web server > >> configurations. > >> > >> > Cheers, > >> > Kevin > >> > >> Regards, > >> Ben > >> > >> >> > Cheers > >> >> > Lydia > >> >> > >> >> Regards, > >> >> Ben > >> >> > >> >> > -- > >> >> > Lydia Pintscher - http://about.me/lydia.pintscher > >> >> > KDE e.V. Board of Directors / KDE Community Working Group > >> >> > http://kde.org - http://open-advice.org > >> >> > > >> >> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> >> >>> unsubscribe <<>> > >> >> >> > >> >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> >> >> unsubscribe > >> >> >> << > >> > > >> > -- > >> > Kevin Funk | kf...@kde.org | http://kfunk.org > > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: robots.txt in quickgit.kde.org
On Wednesday, December 30, 2015 12:57:23 PM Ben Cooksley wrote: > On Tue, Dec 29, 2015 at 11:16 PM, Kevin Funk wrote: > > On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote: > >> On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher wrote: > >> > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley wrote: > >> >>> Is there some place where search engines can easily index our source > >> >>> code or are we shooting ourselves in the foot here? > >> >> > >> >> We could probably make it available by publishing the source trees > >> >> used by LXR / EBN. > >> >> This would only have the main branches obviously rather than > >> >> everything > >> >> though. > >> >> > >> >> I haven't checked, but LXR may already make it's copy of the code > >> >> accessible...> > >> > > >> > I think making our sourcecode available to search engines is pretty > >> > important for the reasons already mentioned by others. Do you need > >> > help for it? If you write down what's needed I can help find someone > >> > to do it. > >> > >> I've now provisioned https://sources.kde.org/ > > > > I'm not sure this is super useful, to be honest (as mentioned in #kde- > > sysadmins already). > > > > This is really just plain file serving, with no cross-references to either > > LXR (or apidocs). This is basically a dead-end when you follow a result > > on Google. > > > > Wouldn't it be possible to let robots index https://lxr.kde.org/source/ > > > > instead? We have the infrastructure... > > We'll give it a shot. Just to stress again this would be *really* useful to have. I answered a post on SO: http://stackoverflow.com/a/34612692/592636 Tried to link kwallet's FindGpgpme.cmake into the answer; and there's *no* easy way quickly get a link to KDE infrastructure serving the file via Google (not even api.kde.org). Try googling for "kwallet findgpgme.cmake" (very specific search after all): https://www.google.de/search?q=kwallet+findgpgme.cmake -> First result: Github..., rest: mildly interesting Different issue I just noticed: There's no way to get the plain-text (raw) representation of a given file on LXR, is there? Would be useful as well. Cheers, Kevin > > Of course we need to blacklist all the pages allowing to actively *search* > > LXR for robots, in order to avoid abuse. > > Note that despite robots.txt, many spiders (including Google, Yahoo > and Bing) will actively disregard the instructions in there. > While they may not return the results - or omit snippets of the page > content - they have all been guilty (at least in the past) of > disregarding our restrictions, resulting in downtime (which have in > some cases necessitated full host reboots to fix) for numerous KDE.org > subsites in the past. > > This is why QuickGit and WebSVN have extremely restrictive robots.txt > policies, in addition to blacklist rules within our web server > configurations. > > > Cheers, > > Kevin > > Regards, > Ben > > >> > Cheers > >> > Lydia > >> > >> Regards, > >> Ben > >> > >> > -- > >> > Lydia Pintscher - http://about.me/lydia.pintscher > >> > KDE e.V. Board of Directors / KDE Community Working Group > >> > http://kde.org - http://open-advice.org > >> > > >> >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> >>> unsubscribe <<>> > >> >> > >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> >> unsubscribe > >> >> << > > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: New developer
On Wednesday, December 30, 2015 06:44:49 PM Yosef Levy wrote: > Most of bugs are resolved already. Uh? http://kde.org/jj only shows open bugs. Cheers, Kevin > בתאריך 30 בדצמ׳ 2015 12:49, "Kevin Funk" כתב: > > On Wednesday, December 30, 2015 03:51:49 PM Anirudh GP wrote: > > > Hi guys, > > > > > > I'm Anirudh and I want to start contributing to the KDE community. How > > > > do I > > > > > get started? > > > > > > Thanks > > > Anirudh > > > > Heya, > > > > this question has been asked a few times on this mailing list already. Let > > me > > give you starting aid: > > > > Welcome to KDE community. Please have a look at this guide: > > http://flossmanuals.net/kde-guide/ which contains useful information for > > starters. > > > > If you're ready to go and looking for something relatively easy to start > > with, you can take care of one of the junior jobs present here: > > http://kde.org/jj > > > > Or just try to fix any annoyances with a KDE application you regularly > > use. > > > > Cheers, > > Kevin > > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > unsubscribe << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: New developer
On Wednesday, December 30, 2015 03:51:49 PM Anirudh GP wrote: > Hi guys, > > I'm Anirudh and I want to start contributing to the KDE community. How do I > get started? > > Thanks > Anirudh Heya, this question has been asked a few times on this mailing list already. Let me give you starting aid: Welcome to KDE community. Please have a look at this guide: http://flossmanuals.net/kde-guide/ which contains useful information for starters. If you're ready to go and looking for something relatively easy to start with, you can take care of one of the junior jobs present here: http://kde.org/jj Or just try to fix any annoyances with a KDE application you regularly use. Cheers, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: seeking guidance
On Tuesday, December 22, 2015 02:46:12 PM nitish chauhan wrote: > Hello, > Myself Nitish an undergrad. Engineering student from India. > > I am very much willing to contribute to kde. > My area of expertise are C++,Android Application development,Java & > Qt(learning). > > I am very new to open source development , so it would be very nice if > someone could guide me the path.I am very much willing to learn and will > surely not disappoint. Heya, this question has been asked a few times on this mailing list already. Let me give you starting aid: Welcome to KDE community. Please have a look at this guide: http://flossmanuals.net/kde-guide/ which contains useful information for starters. If you're ready to go and looking for something relatively easy to start with, you can take care of one of the junior jobs present here: http://kde.org/jj Or just try to fix any annoyances with a KDE application you regularly use. Cheers, Kevin > > thanks. > > Regards, > Nitish Chauhan > my linkedin profile :- https://in.linkedin.com/in/nitish-chauhan-060a66a5 -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: robots.txt in quickgit.kde.org
On Tuesday, December 29, 2015 10:39:01 PM Ben Cooksley wrote: > On Tue, Dec 29, 2015 at 7:59 AM, Lydia Pintscher wrote: > > On Sun, Dec 27, 2015 at 12:35 PM, Ben Cooksley wrote: > >>> Is there some place where search engines can easily index our source > >>> code or are we shooting ourselves in the foot here? > >> > >> We could probably make it available by publishing the source trees > >> used by LXR / EBN. > >> This would only have the main branches obviously rather than everything > >> though. > >> > >> I haven't checked, but LXR may already make it's copy of the code > >> accessible...> > > I think making our sourcecode available to search engines is pretty > > important for the reasons already mentioned by others. Do you need > > help for it? If you write down what's needed I can help find someone > > to do it. > > I've now provisioned https://sources.kde.org/ I'm not sure this is super useful, to be honest (as mentioned in #kde- sysadmins already). This is really just plain file serving, with no cross-references to either LXR (or apidocs). This is basically a dead-end when you follow a result on Google. Wouldn't it be possible to let robots index https://lxr.kde.org/source/ instead? We have the infrastructure... Of course we need to blacklist all the pages allowing to actively *search* LXR for robots, in order to avoid abuse. Cheers, Kevin > > Cheers > > Lydia > > Regards, > Ben > > > -- > > Lydia Pintscher - http://about.me/lydia.pintscher > > KDE e.V. Board of Directors / KDE Community Working Group > > http://kde.org - http://open-advice.org > > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>> unsubscribe <<>> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: robots.txt in quickgit.kde.org
On Monday, December 28, 2015 04:37:47 PM Thomas Lübking wrote: > On Montag, 28. Dezember 2015 11:35:23 CEST, Albert Vaca wrote: > > Lxr can't search across every open source project in the world, so that's > > a > > point for Google. > > Presuming google could, why would I. Or anyone? > I dig for certain variables or strings in specific code, but why would I > look for m_foo or "SomeSetting" "across every open source project in the > world"? Lower STR? Search who copied "my" code? Are you aware that not even every KDE developer knows about LXR? I constantly have to tell people about it. Now consider someone outside of KDE even, trying to figure out where KAwesomeClass is defined, or how it is implemented quickly -> bummer. (right now there's api.kde.org, which at least gives results about signatures, but the content of the .cpp or .h files are not indexed afaics) So having KDE source code indexed by Google would be definitely a win for everyone. It being linked back to LXR even more (=> people learn LXR exists when googling for KDE source code) Cheers, Kevin > Don't get me wrong, I don't care if anyone can - fine. But the inability > doesn't exactly like shooting yourself. > > Shrug, > Thomas > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Phabricator Questions
On Thursday, November 05, 2015 09:25:58 PM Ben Cooksley wrote: > On Thu, Nov 5, 2015 at 12:58 AM, Kevin Funk wrote: > > On Wednesday, October 28, 2015 10:47:54 AM Milian Wolff wrote: > >> Hey all, > >> > >> I got a few questions regarding Phabricator, can anyone answer them for > >> me: > >> > >> (snip) > > > > Cont'd: > > > > Currently it's not possible abandon patches owned by someone else. Can we > > change this? (It's possible in ReviewBoard.) > > If you are able to abandon your own patch, then you may need to > commandeer a patch first - then it will likely allow you to abandon > it. Aha! Indeed, that works. Thanks a lot! So, for the others. In a differential revision page: - Go to the Bottom - Select Action: Commandeer Revision - Submit Then its yours! > > Cheers, > > Kevin > > Regards, > Ben > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org > > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>> unsubscribe <<>> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Phabricator Questions
On Wednesday, October 28, 2015 10:47:54 AM Milian Wolff wrote: > Hey all, > > I got a few questions regarding Phabricator, can anyone answer them for me: > > (snip) Cont'd: Currently it's not possible abandon patches owned by someone else. Can we change this? (It's possible in ReviewBoard.) Cheers, Kevin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Input from OS X developers wanted
On Sunday, September 13, 2015 12:28:30 PM Ian Wadham wrote: > Hi Alex, > > For general info, the title of review 125163 is "Disable X11,XCB etc. > detection on OS X". > On 13/09/2015, at 7:33 AM, Alex Merry wrote: > > Could OS X developers please give input on > > https://git.reviewboard.kde.org/r/125163/ ? > Gods give me patience! > > > I'm particularly interested in knowing whether building KF5-based software > > with X11 support on OS X (via homebrew or macports) is a thing people do. > I don't know about Homebrew, but on Macports I do not think anybody is > building KF5-based software PERIOD. And the prospect of any KF5-based > software ever being released on Macports is vanishing to non-existent > AFAICS. > > Even KDE4-based software *still* has many problems. And we do not yet have > an official Macports solution to the problem of making Qt 5 and Qt 4 > co-exist in an OS X installation, let alone KF5 and KDE 4. > So your query is somewhat moot. > > For most of last year and some of this year, a few of us tried hard to make > KDE 4 apps run better on OS X, but we were crying out for help from KDE > developers all the time, particularly with regard to the > kdeinit/klauncher/kded/kio complex which underlies so much of the software > from the KDE Community and which functions badly, if at all, in an OS X > environment. Right, kdeinit/klauncher/kded/kio is an issue when porting apps, but it got *a lot* better in KF5 already (inter-dependencies between those modules have been relaxed, KIO got cleaned up a lot). In fact, if you did follow the KF5 mailing list a bit; on Windows it's now possible to just run KDevelop *without* ever invoking kdeinit/klauncher/kded. Just a few patches needed in KF5 libraries -- all upstreamed already. This also helped the OSX world. > "Oh no," we were told, "we are far too busy with Frameworks and KF5 and > anyway KDE 4 is now becoming obsolete and unsupported". So help never > came. > But we still managed to fix a few things in KDE 4 and Marko Käning > developed the first CI system for OS X. Some of our fixes were relevant in > KF5 and even in Linux, notably https://bugs.kde.org/show_bug.cgi?id=337742, > where Dr Konqi was failing to submit crash reports. > > A few months ago I spent WEEKS trying to KF5 and Qt 5 to build on OS X and > finally gave up. What's the problem with that? Did you ask for help? Clearly, and people out there are using it (https://github.com/haraldF/homebrew-kf5) > Since then I have gone back to apps programming on KDE 4, > which is the only version I can get to run on my Macbook. I know it is a > dead-end, but I have been working on features the users have requested. > Maybe I can port the apps to pure-Qt4 or even Cocoa… ;-) I think work on > Qt5/KF5 on OS X is currently blocked by the QStandardPaths problem and has > been for a while. Then, please join efforts and help in resolving *this* issue. We in the "KDE on Windows" world also just worked-around the issue by patching Qt. The QStandardPaths issue is not the end of the world, either, though... > So you see, if anyone has read this far, it is OS X developers who need > help, serious help, from KDE developers… not the other way around. Please keep in mind that we can only to drastic changes in development versions (KF5), not legacy(!) versions (KDE4) ... Also, on Windows, we have the same problem: KDE4 apps are not working perfectly fine either; but we've accepted the fact KDE4 is a dead-end and now try to focus on improving based on KF5 instead. Thanks, Kevin > FWIW, X11 is pretty much a dead issue on OS X and has been for years, since > Qt 4 supported native OS X graphics and Apple stopped releasing X11 > (Quartz) with OS X. AFAIK, a few FOSS packages available via Macports or > supplied in Apple versions by their developers still use Quartz/X11. > Notable among these are Gimp and Inkscape. > > Cheers, Ian W. > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 125004: Make "querying for remaining time" thread safe
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125004/#review84742 --- src/file/timeestimator.cpp (line 46) <https://git.reviewboard.kde.org/r/125004/#comment58641> Oh, right, you also changed the code inside the loop accordingly. I was so focussed on the loop-merge that I didn't notice... Alright, sorry for the noise. LGTM. - Kevin Funk On Sept. 2, 2015, 7:54 a.m., Pinak Ahuja wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125004/ > --- > > (Updated Sept. 2, 2015, 7:54 a.m.) > > > Review request for Baloo and Vishesh Handa. > > > Repository: baloo > > > Description > --- > > * Previously the m_batchTimeBuffer could be read while it was being written > to by another thread. > * Now only a single thread (the main thread) deals with m_batchTimeBuffer > avoiding the above mentioned situation. > > > Diffs > - > > src/file/filecontentindexer.h 186eb35 > src/file/filecontentindexer.cpp 5a504b1 > src/file/fileindexscheduler.h c30f358 > src/file/fileindexscheduler.cpp dcf45f8 > src/file/timeestimator.h 68253f9 > src/file/timeestimator.cpp b9fefcb > src/tools/baloo-monitor/monitor.cpp 4b0148e > > Diff: https://git.reviewboard.kde.org/r/125004/diff/ > > > Testing > --- > > Querying for remaining time seems to working from baloo-monitor. > > > Thanks, > > Pinak Ahuja > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 125004: Make "querying for remaining time" thread safe
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125004/#review84740 --- src/file/timeestimator.cpp (line 46) <https://git.reviewboard.kde.org/r/125004/#comment58639> I'm not sure this change is correct: This changes semantics wrt weights. I presume the prior approach assigned increasing weights for [first,last]; now it just does that for [0,end[. Double-check... - Kevin Funk On Sept. 2, 2015, 7:54 a.m., Pinak Ahuja wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125004/ > --- > > (Updated Sept. 2, 2015, 7:54 a.m.) > > > Review request for Baloo and Vishesh Handa. > > > Repository: baloo > > > Description > --- > > * Previously the m_batchTimeBuffer could be read while it was being written > to by another thread. > * Now only a single thread (the main thread) deals with m_batchTimeBuffer > avoiding the above mentioned situation. > > > Diffs > - > > src/file/filecontentindexer.h 186eb35 > src/file/filecontentindexer.cpp 5a504b1 > src/file/fileindexscheduler.h c30f358 > src/file/fileindexscheduler.cpp dcf45f8 > src/file/timeestimator.h 68253f9 > src/file/timeestimator.cpp b9fefcb > src/tools/baloo-monitor/monitor.cpp 4b0148e > > Diff: https://git.reviewboard.kde.org/r/125004/diff/ > > > Testing > --- > > Querying for remaining time seems to working from baloo-monitor. > > > Thanks, > > Pinak Ahuja > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
kdesrc-buildrc: Show compile output
Heya guys, A few revisions ago, kdesrc-buildrc had that "hidden" --debug option that allowed me to see compile output right away. This no longer works but I'd like to have the feature back, one way or the other. So, is it possible atm? I'd really like to have --verbose print command invocations (cmake, gcc, clang++) + compile output, too... Am I missing something? (I'm not the Perl guru either...) Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Interested in Contribution
On Tuesday 05 May 2015 02:08:15 Aleix Pol wrote: > On Tue, May 5, 2015 at 1:48 AM, Claudio Autiero > > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi Alex & Albert, > > > > @Alex I only congratulated for Okular APP :P > > > > @Albert How Dhriti Shikhar I'm a new and if it is ok for you we can > > try to make this implementation together. > > > > Claudio. > > > > Il 05/05/2015 01:37, Aleix Pol ha scritto: > >> On Tue, May 5, 2015 at 1:23 AM, Claudio Autiero > >> > >> wrote: > >>> Albert, > >>> > >>> https://bugs.kde.org/show_bug.cgi?id=342927 should be relatively > >>> "simple". > >>> > >>> This is a future request ;-) and Okular it's ok for now (I > >>> think). > >>> > >>> We can ask to a devel of Okular if is smart to make this new > >>> implementation. > >>> > >>> All the best, Claudio > >>> > >>> Il 04/05/2015 22:44, Albert Astals Cid ha scritto: > >>>> El Dilluns, 4 de maig de 2015, a les 16:12:20, Dhriti Shikhar > >>>> > >>>> va escriure: > >>>>> Hello, > >>>>> > >>>>> I am Dhriti Shikhar from Pune, India. I am currently > >>>>> studying engineering in Pune University. > >>>>> > >>>>> I program in Python, C, C++, javascript/jquery, HTML. I have > >>>>> hands-on experience on git, Flask, Vim, reStructured Text, > >>>>> shell scripting. I have also worked on PHP, MySQL, mongodb > >>>>> for my college assignments. I have been using Fedora > >>>>> distribution of Linux for over a year now. > >>>>> > >>>>> I am interested in contributing to KDE. I have gone through > >>>>> the following link: https://techbase.kde.org/ > >>>>> > >>>>> I have also gone through Junior Jobs of KDE. I would be > >>>>> really grateful if you could help me find a good first bug. > >>>> > >>>> https://bugs.kde.org/show_bug.cgi?id=342927 should be > >>>> relatively "simple". > >>>> > >>>> Cheers, Albert > >>>> > >>>>> Awaiting reply, > >>>>> > >>>>> Regards, Dhriti Shikhar > >>>>> > >>>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub > >>>>>> to unsubscribe << > >>>>> > >>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>>>> unsubscribe << > >> > >> Hi Claudio, Albert is an Okular developer and maintainer and he's > >> doing exactly what you suggest already. > >> > >> Aleix > >> > >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>>> unsubscribe << > > > > -BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQIcBAEBAgAGBQJVSAVfAAoJEGqF11c5vK3T7/cP/024LmV9esxnmmUyz6kTtebz > > DhmF3yKG3jQ2dm+/jcDSdbMGFwH7Yqn6mYaSpMnc/Ast3nRJdjlD66+4ULpKZZxH > > d/HSRC5fBwTg+L0Zc/0qywV6Wndf+9P6cbxopQTaGjWqlpUIXEkz/hi5YSP0DK7N > > jDcuOs3KntVyUbegePOBDFpAmw5cOmNm1XHECgIGRYoUYaxJkTYx4qK6gfMNtjIs > > AFDOxcTNhb5GBGTckKPS+HUbccVthdpUFW744K4ymgCeb7kyfiCBadc9LCWttoz1 > > d0nOvZrrocIW8H30eFH1Q9R3/ggZqoUps0xH+biAVveA7v8dkstWRdPn7IE4kJkC > > SAqsF9a4G/dKyB/gTOgtjT0seSuVSIb4vRe/kdmIHd3BCbh9uc73hYxY8ZjimIrT > > cRcqaxl6EC6oKFrM6/tszsri5dPB1K0Sthn3fuygAC93WnX7JRco/upLEFxYASkr > > 4d7mmCiS3EYe2jrC71LyN8IGAw5+LuC3RXBl3ksKTrevHtD8VZhLrhwzldaNT6aF > > cKUaDFcSk6EJnHeB1b4LkzRw9t/vRnYVWbMn/TCjsBzyMwW6ZZub7b+dVMhVbat+ > > AxuRqH/h1aX6y0LvsJSvxRmS0bhGEJ7e+OPOuBH4M3DQRyuhx8lUy+8m+s9+xJqy > > IbSOnkeIwMoU9f3iGqTN > > =cgBU > > -END PGP SIGNATURE- > > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>> unsubscribe << > Hi Claudio, > If you're interested in contributing, feel free to get in touch and > we'll manage to find something to work on for you as well. If you'd also be interested in working on Okular, my own little pet-peeve that I'd like to see fixed at some point is part of https://bugs.kde.org/show_bug.cgi?id=311885: I'd *reeeally* like the bottom "page bar" to be merged into the top toolbar in order to save vertical space without losing the functionality of the page bar. I think it'd be trivial enough, but I don't have the time to work on it :) Just my two cents, maybe you're interested? @Albert, do you like the idea? Cheers! Kevin > Cheers! > Aleix > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KF5 with qmake problems
On Friday, April 24, 2015 20:34:33 Christian Gagneraud wrote: > On 24/04/15 19:35, Kevin Funk wrote: > > On Friday, April 24, 2015 08:48:53 Kevin Funk wrote: > >> On Friday, April 24, 2015 17:24:34 Christian Gagneraud wrote: > >>> Hi there, > >>> > >>> I've just installed kubuntu-15.04, and I'm trying to run this tutorial > >>> [1]. I'm using stock Qt5, KF5 and Qt Creator. > >>> > >>> In my .pro file, I have "QT += KXmlGui KI18n KTextWidgets", but qmake > >>> complains with "Project ERROR: Unknown module(s) in QT: I18n", if I > >>> remove KTextWidgets, then qmake is happy (same happens with QT += > >>> KParts). > >>> > >>> Did I missed something or is it a KF5 or KUbuntu bug? > > > > Whoops. We've just found out this indeed a bug. > > > > In qmake terms, there's only 'KI18n', but no 'I18n'. qt_KTextWidgets.pri > > incorrectly references 'I18n', though. > > > > Here's the fix: > > http://quickgit.kde.org/?p=ktextwidgets.git&a=commitdiff&h=b83617d59b14941 > > b1e26d295e9ea300301365321 > > > > You could apply the patch locally and be fine. > > Yes, that was it, in > /usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_KTextWidgets.pri > > Is it worth opening an issue to track this? No, not needed. It's already fixed in our repo. > Thanks for the help. > Krys > > > Thanks for reporting. > > Cheers > > > > PS: @devs: We should have really used the 'KF5' prefix for all qmake > > module > > names here. Now there's an inconsistency in the naming scheme for the > > modules.> > > Compare: > >KF5::Attica (CMake) - Attica (QMake) vs. > >KF5::I18n (CMake) - KI18n (QMake) > > > > To fix and to avoid SIC we could generate/install an additional set of > > .pri > > files for KF5 which prefixes every module with 'KF5'? > > > >> Do you have the development packages for those libraries installed? > >> > >> I.e. on Ubuntu: > >> - libkf5textwidgets-dev > >> - libkf5i18n-dev > >> - libkf5xmlgui-dev > >> > >> > >> For helping you to debug your issue it may help to understand how this > >> all > >> works: > >> > >> So when you do 'QT += KTextWidgets', qmake needs to find a file called > >> 'qt_KTextWidgets.pri' somewhere within the QTDIR. I.e. on Ubuntu, this > >> should be > >> /usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_KTextWidgets.pri. > >> > >> Make sure these files are around, by installing the resp. development > >> packages. > >> > >> Hope that helps > >> > >>> As a workaround, I'm doing this instead: > >>> INCLUDEPATH += /usr/include/KF5/KTextWidgets/ > >>> LIBS += -lKF5TextEditor > >>> INCLUDEPATH += /usr/include/KF5/KParts/ > >>> LIBS += -lKF5Parts > >>> > >>> Thx, > >>> Krys > >>> > >>> [1] > >>> http://thenoobietips.blogspot.co.nz/2014/06/kf5-tutorial-2-how-to-use-kx > >>> ml > >>> gu iwindow.html > >>> > >>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>>>> unsubscribe > >>>>> << > >>> > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >>> unsubscribe <<>> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KF5 with qmake problems
On Friday, April 24, 2015 08:48:53 Kevin Funk wrote: > On Friday, April 24, 2015 17:24:34 Christian Gagneraud wrote: > > Hi there, > > > > I've just installed kubuntu-15.04, and I'm trying to run this tutorial > > [1]. I'm using stock Qt5, KF5 and Qt Creator. > > > > In my .pro file, I have "QT += KXmlGui KI18n KTextWidgets", but qmake > > complains with "Project ERROR: Unknown module(s) in QT: I18n", if I > > remove KTextWidgets, then qmake is happy (same happens with QT += KParts). > > > > Did I missed something or is it a KF5 or KUbuntu bug? Whoops. We've just found out this indeed a bug. In qmake terms, there's only 'KI18n', but no 'I18n'. qt_KTextWidgets.pri incorrectly references 'I18n', though. Here's the fix: http://quickgit.kde.org/?p=ktextwidgets.git&a=commitdiff&h=b83617d59b14941b1e26d295e9ea300301365321 You could apply the patch locally and be fine. Thanks for reporting. Cheers PS: @devs: We should have really used the 'KF5' prefix for all qmake module names here. Now there's an inconsistency in the naming scheme for the modules. Compare: KF5::Attica (CMake) - Attica (QMake) vs. KF5::I18n (CMake) - KI18n (QMake) To fix and to avoid SIC we could generate/install an additional set of .pri files for KF5 which prefixes every module with 'KF5'? > Do you have the development packages for those libraries installed? > > I.e. on Ubuntu: > - libkf5textwidgets-dev > - libkf5i18n-dev > - libkf5xmlgui-dev > > > For helping you to debug your issue it may help to understand how this all > works: > > So when you do 'QT += KTextWidgets', qmake needs to find a file called > 'qt_KTextWidgets.pri' somewhere within the QTDIR. I.e. on Ubuntu, this > should be > /usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_KTextWidgets.pri. > > Make sure these files are around, by installing the resp. development > packages. > > Hope that helps > > > As a workaround, I'm doing this instead: > > INCLUDEPATH += /usr/include/KF5/KTextWidgets/ > > LIBS += -lKF5TextEditor > > INCLUDEPATH += /usr/include/KF5/KParts/ > > LIBS += -lKF5Parts > > > > Thx, > > Krys > > > > [1] > > http://thenoobietips.blogspot.co.nz/2014/06/kf5-tutorial-2-how-to-use-kxml > > gu iwindow.html > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > >> unsubscribe > > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: KF5 with qmake problems
On Friday, April 24, 2015 17:24:34 Christian Gagneraud wrote: > Hi there, > > I've just installed kubuntu-15.04, and I'm trying to run this tutorial > [1]. I'm using stock Qt5, KF5 and Qt Creator. > > In my .pro file, I have "QT += KXmlGui KI18n KTextWidgets", but qmake > complains with "Project ERROR: Unknown module(s) in QT: I18n", if I > remove KTextWidgets, then qmake is happy (same happens with QT += KParts). > > Did I missed something or is it a KF5 or KUbuntu bug? Do you have the development packages for those libraries installed? I.e. on Ubuntu: - libkf5textwidgets-dev - libkf5i18n-dev - libkf5xmlgui-dev For helping you to debug your issue it may help to understand how this all works: So when you do 'QT += KTextWidgets', qmake needs to find a file called 'qt_KTextWidgets.pri' somewhere within the QTDIR. I.e. on Ubuntu, this should be /usr/lib/x86_64-linux-gnu/qt5/mkspecs/modules/qt_KTextWidgets.pri. Make sure these files are around, by installing the resp. development packages. Hope that helps > As a workaround, I'm doing this instead: > INCLUDEPATH += /usr/include/KF5/KTextWidgets/ > LIBS += -lKF5TextEditor > INCLUDEPATH += /usr/include/KF5/KParts/ > LIBS += -lKF5Parts > > Thx, > Krys > > [1] > http://thenoobietips.blogspot.co.nz/2014/06/kf5-tutorial-2-how-to-use-kxmlgu > iwindow.html > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: What's the correct strategy to resolve i18n merge conflicts?
On Sunday 08 March 2015 23:21:59 Albert Astals Cid wrote: > El Diumenge, 8 de març de 2015, a les 22:00:33, Thomas Lübking va escriure: > > merging 5.2 into master gets me several merge conflicts in desktop > > services, which I cannot reasonably resolve, mostly because: > > > > ++<<<<<<< HEAD > > > > +Comment[zh_TW]=桌面效果使用的組合器設定 > > > > ++=== > > + Comment[zh_TW]=桌面效果使用的組合器組態 > > ++>>>>>>> Plasma/5.2 > > > > I cannot read that (nor other translations) > > > > => which branch to I pick? > > I have the feeling this has been asked/answered quite a few times, anyone > has any idea of a place where to put such a FAQ so that people would find > it? > > Short answer: The one you're in (i.e. in this case i guess HEAD/master) This is easy to automate with .gitattributes, for the record (we've been using that for ages in KDevelop land): $GITROOT/.gitattributes *.desktop merge=ours Then add this to your .git/config: [merge "ours] driver = true Now 'git merge mystablebranch' will just resolve merge conflicts in .desktop files using the 'ours' strategy (i.e. favoring *the current branch's* changes) Hope that helps > > Medium answer: It doesn't matter, scripty will just make it right on the > next day. > > Long answer: It doesn't matter, scripty will just make it right on the next > day. The translations on .desktop files are the output of a script, the real > translation is in .po files in the .svn repo. > > Cheers, > Albert > > > Cheers, > > Thomas > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > >> unsubscribe > > >> << > >> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Macaw-Movies: KDE-Incubator
On Wednesday 25 February 2015 11:30:48 Olivier CHURLAUD wrote: > Hey! > > We began last year to write a program to manage a video collection. For > now, it's hosted on Github and we are only 2 people working on it. We > realize that if we code this just the both of us we will miss a lot of > (good) advices from others and we may end with an unsustainable code. > We think of KDE community as an amazing and inspiring group from witch > we can learn a lot. Besides, we think our project as a useful tool for > movie collection management that could enrich KDE apps. So we would need > a mentor and some...guideline for the beginning of the process. > > It's a little long below We tried to describe the state of the art > honestly. > We hope it will work! Where are teh screenshots? ;) Get potential users interested by actually showing off some of your features in a wise way. Greets > > About us > > We are two frenchies: I'm studying in Berlin, and Seb is working in France. > . > About the Macaw-Movies > == > * Macaw-Movies is written in C++ with the Qt Framework (5.4) > * It is written for Linux/Mac/Windows (developed with Linux, and > compiles and works also on Mac/Windows) > > * Our github is https://github.com/macaw-movies > * We began a blog https://macawmovies.wordpress.com to try to be more > visible. > * We have a logo =D > > How far is the project from a release > = > * All the most important functions are written > * We have a first acceptable design (to be improved, though) > * The documentation is for now almost nonexistent but we since the > core seems to be stable, we are going to write it (a draft) in the next > few weeks.. Maybe a first v0.1 could be released on the end of april? > > How clean is the project? > == > * We tried to follow rules we found on Google projects, KDE and so on. > * Not enough documentation, still some black magic here and there. > > Cheers! > > Olivier & Seb -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: AppData/AppStream progress in KDE
On Friday 19 December 2014 09:23:29 Richard Hughes wrote: > Hi all, > > My name is Richard Hughes, and I'm one of the guys behind the > AppData/AppStream initiative. I've uploaded a page with the current > AppStream metadata status for Fedora 22 -- quite a few KDE > applications are missing easy-to-add things like desktop comments and > keywords and some important apps are missing AppData and HiDPI icons. > It's awesome so many KDE apps are shipping AppData already (61.9%!) > and I'm hugely grateful for that, so we're really polishing things up > now. > > The page is here (warning 964k HTML page!), and is updated nightly: > https://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html Would be nice to get details about each validation result as well, if it's easy enough. > I'd appreciate it if you could have a look there and check your > application is green. If there are any false-positives or missing > applications then please let me know. I'm also happy to answer > questions about AppData files here or in private emails, although most > questions are already covered in this mini-site: > http://people.freedesktop.org/~hughsient/appdata/ FYI: Just tried to validate kdevelop's appdata file on that page, but http://hughsient.no-ip.biz/validate.php is apparently down. appstream-util doesn't seem to be available for my distro (Ubuntu 14.10) yet (going to check how to get it, though). > > Thanks! > > Richard > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe > >> << -- Kevin Funk | kf...@kde.org | http://kfunk.org >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: kubuntu plasma 5 login error
On Thursday 18 December 2014 09:15:14 Kevin Funk wrote: > On Thursday 18 December 2014 05:12:10 anu mittal wrote: > > Okay I will give it a try. Thanks. > > > > On Thu, Dec 18, 2014, 6:43 AM Aleix Pol wrote: > > > On Wed, Dec 17, 2014 at 7:35 PM, anu mittal wrote: > > > > Hi everyone, > > > > I have been using kubuntu plasma 5 via VMware Workstation 9.0 for > > > > > > porting an > > > > > > > application to kf5,everything was working perfectly but when i tried > > > > > > logging > > > > > > > in kubuntu today via same vmware, after accepting the login password > > > > and > > > > loading the system the screen faded and turned blank. > > > > The error message which i got from .xsession-error was: > > > > > > > > kded5 : org.kde.powerdevil.backlighthelper.brightnessvaluemax failed > > > > list is empty > > > > lock called > > > > > > > > I would like to know if there any solution for it or should i dual > > > > boot > > > > > > my > > > > > > > laptops's main memory and try working on kubuntu from there.? > > > > -- > > > > Regards, > > > > Anu. > > > > > > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > > > unsubscribe > > > > > > >>> << > > > > > > Something I've seen doing a plasma 5 kubuntu user today is: > > > - getting the blank screen. > > > - opening a konsole > > > - killall plasmashell > > > - plasmashell > > > > > > It worked for him, still it seems to be a downstream problem. > > > > > > Aleix > > > > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > > > > > > unsubscribe << > > Heya, I'm also having issues with Plasma 5 from Kubuntu PPA's packages. > > Seems related to this one. After some suspend/resumes cycles it seems that > something in in the kded+powerdevil integration breaks and I can no longer > use any Power Management related features. > > One issue: Clicking on "Power Management" in system settings just freezes > the application. Suspending no longer works. > > Attaching GDB to kded5 brings the following backtrace, which seems to > indicate some issue with Polkit, it hangs in > 'polkit_authority_check_authorization'. Did anyone else see this already > and could provide some pointers where to look at? > > Backtrace attached > > Greets Alright, looking at all threads gives the following interesting backtrace for thread 3: Thread 3 (Thread 0x7f522a7fc700 (LWP 797)): #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 #1 0x7f5251588931 in _L_lock_14320 () at malloc.c:5206 #2 0x7f5251586cc1 in __libc_calloc (n=139990700916768, elem_size=) at malloc.c:3197 #3 0x7f524d896527 in ?? () from /usr/lib/nvidia-331- updates/tls/libnvidia-tls.so.331.113 #4 0x7f525256c998 in KCrash::defaultCrashHandler(int) () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5 #5 #6 malloc_consolidate (av=av@entry=0x7f522020) at malloc.c:4151 #7 0x7f5251583fd8 in _int_malloc (av=av@entry=0x7f522020, bytes=bytes@entry=2032) at malloc.c:3423 #8 0x7f5251586cfc in __libc_calloc (n=, elem_size=) at malloc.c:3219 #9 0x7f524d8971ae in ?? () from /usr/lib/nvidia-331- updates/tls/libnvidia-tls.so.331.113 #10 0x7f524e3ca822 in g_malloc0 (n_bytes=2032) at /build/buildd/glib2.0-2.42.1/./glib/gmem.c:127 #11 0x7f524e3e1fbc in thread_memory_from_self () at /build/buildd/glib2.0-2.42.1/./glib/gslice.c:519 #12 g_slice_free1 (mem_size=, mem_block=0x7f521c002270) at /build/buildd/glib2.0-2.42.1/./glib/gslice.c:1088 #13 0x7f524ee21ea2 in __nptl_deallocate_tsd () at pthread_create.c:157 #14 0x7f524ee220b8 in start_thread (arg=0x7f522a7fc700) at pthread_create.c:322 #15 0x7f52515fd77d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Seems like kded5 already crashed, but still keeps running because it deadlocked in the signal handler... Still, cannot find any sign of bug report about this issue on the interwebs... Just me? -- Kevin Funk | kf...@kde.org | http://kfunk.org >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: kubuntu plasma 5 login error
On Thursday 18 December 2014 05:12:10 anu mittal wrote:
> Okay I will give it a try. Thanks.
>
> On Thu, Dec 18, 2014, 6:43 AM Aleix Pol wrote:
> > On Wed, Dec 17, 2014 at 7:35 PM, anu mittal wrote:
> > > Hi everyone,
> > > I have been using kubuntu plasma 5 via VMware Workstation 9.0 for
> >
> > porting an
> >
> > > application to kf5,everything was working perfectly but when i tried
> >
> > logging
> >
> > > in kubuntu today via same vmware, after accepting the login password and
> > > loading the system the screen faded and turned blank.
> > > The error message which i got from .xsession-error was:
> > >
> > > kded5 : org.kde.powerdevil.backlighthelper.brightnessvaluemax failed
> > > list is empty
> > > lock called
> > >
> > > I would like to know if there any solution for it or should i dual boot
> >
> > my
> >
> > > laptops's main memory and try working on kubuntu from there.?
> > > --
> > > Regards,
> > > Anu.
> > >
> > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >
> > unsubscribe
> >
> > >>> <<
> >
> > Something I've seen doing a plasma 5 kubuntu user today is:
> > - getting the blank screen.
> > - opening a konsole
> > - killall plasmashell
> > - plasmashell
> >
> > It worked for him, still it seems to be a downstream problem.
> >
> > Aleix
> >
> > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >
> > unsubscribe <<
Heya, I'm also having issues with Plasma 5 from Kubuntu PPA's packages.
Seems related to this one. After some suspend/resumes cycles it seems that
something in in the kded+powerdevil integration breaks and I can no longer use
any Power Management related features.
One issue: Clicking on "Power Management" in system settings just freezes the
application. Suspending no longer works.
Attaching GDB to kded5 brings the following backtrace, which seems to indicate
some issue with Polkit, it hangs in 'polkit_authority_check_authorization'.
Did anyone else see this already and could provide some pointers where to look
at?
Backtrace attached
Greets
--
Kevin Funk | kf...@kde.org | http://kfunk.org#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x7f524e4089a9 in g_mutex_lock_slowpath
(mutex=mutex@entry=0x7f524e6893e0 ) at
/build/buildd/glib2.0-2.42.1/./glib/gthread-posix.c:1314
#2 0x7f524e409372 in g_mutex_lock (mutex=mutex@entry=0x7f524e6893e0
) at /build/buildd/glib2.0-2.42.1/./glib/gthread-posix.c:1338
#3 0x7f524e3e1c2f in magazine_cache_pop_magazine (countp=0x1ec1638, ix=9)
at /build/buildd/glib2.0-2.42.1/./glib/gslice.c:725
#4 thread_memory_magazine1_reload (tmem=, ix=9) at
/build/buildd/glib2.0-2.42.1/./glib/gslice.c:801
#5 g_slice_alloc (mem_size=160) at
/build/buildd/glib2.0-2.42.1/./glib/gslice.c:996
#6 0x7f524e4069e9 in tuple_allocate_members (n_members=0x235a318,
members=0x235a310, type=0x22f32f0) at
/build/buildd/glib2.0-2.42.1/./glib/gvarianttypeinfo.c:359
#7 tuple_info_new (type=0x22f32f0) at
/build/buildd/glib2.0-2.42.1/./glib/gvarianttypeinfo.c:665
#8 g_variant_type_info_get (type=type@entry=0x22f32f0) at
/build/buildd/glib2.0-2.42.1/./glib/gvarianttypeinfo.c:761
#9 0x7f524e3ff729 in g_variant_alloc (trusted=1, serialised=0,
type=0x22f32f0) at /build/buildd/glib2.0-2.42.1/./glib/gvariant-core.c:477
#10 g_variant_new_from_children (type=type@entry=0x22f32f0, children=0x22526e0,
n_children=n_children@entry=5, trusted=trusted@entry=1) at
/build/buildd/glib2.0-2.42.1/./glib/gvariant-core.c:565
#11 0x7f524e3fc3f3 in g_variant_builder_end
(builder=builder@entry=0x7fff1c542f40) at
/build/buildd/glib2.0-2.42.1/./glib/gvariant.c:3612
#12 0x7f524e3fdf53 in g_variant_valist_new (str=str@entry=0x7fff1c542ff8,
app=app@entry=0x7fff1c543020) at
/build/buildd/glib2.0-2.42.1/./glib/gvariant.c:5083
#13 0x7f524e3fe2c7 in g_variant_new_va (format_string=0x7f52327626d4 "",
endptr=0x0, app=0x7fff1c543020) at
/build/buildd/glib2.0-2.42.1/./glib/gvariant.c:5256
#14 0x7f524e3fe55a in g_variant_new (format_string=0x7f52327626c0
"(@(sa{sv})s@a{ss}us)") at /build/buildd/glib2.0-2.42.1/./glib/gvariant.c:5191
#15 0x7f52327589d1 in polkit_authority_check_authorization () from
/usr/lib/x86_64-linux-gnu/libpolkit-gobject-1.so.0
#16 0x7f5232759dc1 in polkit_authority_check_authorization_sync () from
/usr/lib/x86_64-linux-gnu/libpolkit-gobject-1.so.0
#17 0x7f52329756f1 in PolkitQt1::Authority::checkAuthorizationSync(QString
const&, PolkitQt1::Subject const&,
QFlags) () from
/usr/lib/x86_64-linux-gnu
Re: Announcing heaptrack - a Heap Memory Profiler for Linux
On Wednesday 10 December 2014 15:12:08 Milian Wolff wrote:
> On Tuesday 09 December 2014 23:51:04 Albert Astals Cid wrote:
> > El Dimarts, 9 de desembre de 2014, a les 02:15:58, Milian Wolff va
escriure:
> > > On Wednesday 03 December 2014 01:51:57 Aleix Pol wrote:
> > > > On Tue, Dec 2, 2014 at 6:59 PM, Milian Wolff wrote:
> > > > > Hey all,
> > > > >
> > > > > I have just finished writing a lengthy introduction to heaptrack, an
> > > > > alternative to Massif, see:
> > > > >
> > > > > http://milianw.de/blog/heaptrack-a-heap-memory-profiler-for-linux
> > > > >
> > > > > I'd like to see more people starting to use it. Any feedback, or
> > > > > even
> > > > > patches,
> > > > > is welcome!
> > > > >
> > > > > Especially, I'd love to see more people use it on their pet project
> > > > > in
> > > > > KDE.
> > > > > Quite often, you'll find useless temporary allocations, overly large
> > > > > memory
> > > > > consumption or even significant memory leaks. C++/Qt/KDE code can be
> > > > > extremely
> > > > > efficient, but you have to code accordingly. If you have any
> > > > > questions
> > > > > to
> > > > > the
> > > > > results you obtain from heaptrack, or how to improve the situation,
> > > > > don't
> > > > > hesitate to ask me. Please ask on a public mailing list, such that
> > > > > others
> > > > > can
> > > > > benefit from the discussion as well.
> > > > >
> > > > > Furthermore, I hereby request an official code review. Heaptrack
> > > > > currently
> > > > > lives in a scratch repository:
> > > > >
> > > > > http://quickgit.kde.org/?p=scratch%2Fmwolff%2Fheaptrack.git
> > > > >
> > > > > I want to move this to extragear, skipping playground altogether, if
> > > > > possible.
> > > >
> > > > Cool stuff! I'll definitely give it a try!
> > > >
> > > > Regarding the move to extragear, you can start requesting the
> > > > repository
> > > > to
> > > > get it in playground and then request the move to kdereview, if you're
> > > > confident it's pristine. ;)
> > >
> > > Heaptrack is now in kdereview, I'd like to invite everyone to review my
> > > code at the new location:
> > >
> > > git clone kde:heaptrack
> >
> > Doesn't link here.
> >
> > Linking CXX executable heaptrack_print
> > CMakeFiles/heaptrack_print.dir/heaptrack_print.cpp.o: In function `main':
> > heaptrack_print.cpp:(.text+0x3f4f): undefined reference to
> > `boost::program_options::options_description::m_default_line_length'
>
>
>
> Can you update and try again? I think I was missing the REQUIRED in the
> find_package statements, which should have triggered an early-return. You
> don't have Boost installed, do you?
>
> Hm, but thinking about it - you seem to have the headers around, otherwise
> it wouldn't even get that far. So something is fishy with your system,
> compared to mine. Can you debug this a bit please?
On Ubuntu it's the same, the libboost-program-options1.55-dev pkg just
contains the .a and .so. Headers are part of the (generic) libboost1.55-dev
pkg.
With the REQUIRED in place it errors out early now. => All fine.
> make heaptrack_print VERBOSE=1 |& tee make_log.txt
> -> esp. the linker invocation would be interesting, it should be something
> like
>
> /usr/lib/icecream/libexec/icecc/bin/g++-std=c++11 -O2 -g -DNDEBUG
> CMakeFiles/heaptrack_print.dir/heaptrack_print.cpp.o -o heaptrack_print -
> rdynamic -lboost_iostreams -lboost_program_options
>
> If this does not include the -lboost_* stuff, can you try to add
>
> message(FATAL_ERROR "Boost libs: ${Boost_LIBRARIES}")
>
> below the find_package in the CMakeLists.txt? What CMake do you use, btw.?
> And maybe play with the following options, and toggle them on/off:
>
> set(Boost_USE_STATIC_LIBS OFF)
> set(Boost_USE_MULTITHREADED ON)
> set(Boost_USE_STATIC_RUNTIME OFF)
>
> (see
> http://stackoverflow.com/questions/6646405/how-do-you-add-boost-libraries-i
> n-cmakelists-txt)
>
> Bye
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> >> <<
--
Kevin Funk | kf...@kde.org | http://kfunk.org
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Maintaining KAppTemplate
On Thursday 11 September 2014 17:21:11 Simon Waechter wrote: > Hey there > > At the moment I am porting the KAppTemplate application to KF5 and I > wanted to ask, if it is possible to take over maintainership from > Anne-Marie Mahfouf, which is more or less inactive as far as I know. > > Beside porting to KF5 (Experimental patch: > https://git.reviewboard.kde.org/r/120135/ ) I also plan to update and > introduce new templates, fix several problems & memory leaks. Another > idea is to move the core functionality inside a shared library so > KDevelop/KDevplatform can use that library and avoid a code duplication > of the whole template code, which is quite annoying at the moment. There > might also be the possibility to add a file generator and a VCS option. > > So what are your thoughts about that ? > > Greetings from the Akademy, > Simon +1. He's already been doing a lot of work on templates in KDevelop/KDevplatform, so it'd only make sense to let him take care of kapptemplate a bit. Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Review Request 119622: Make compile for me
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119622/ --- (Updated Aug. 6, 2014, 6:31 a.m.) Status -- This change has been marked as submitted. Review request for Baloo. Repository: baloo Description --- Make compile for me Port away from methods deprecated since Qt 5.0 Diffs - src/file/removablemediacache.cpp b1872f0ddfa84fc7847b9ea0f127fd26f14ba681 src/kioslaves/search/kio_search.cpp dc8dfcc3c2c28b6d2dd6df94f8f4627b15d08261 src/kioslaves/timeline/timelinetools.cpp 4972a570ca9ef9e8e1d191ffee7f011747adbcf4 Diff: https://git.reviewboard.kde.org/r/119622/diff/ Testing --- Thanks, Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Review Request 119622: Make compile for me
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119622/ --- Review request for Baloo. Repository: baloo Description --- Make compile for me Port away from methods deprecated since Qt 5.0 Diffs - src/file/removablemediacache.cpp b1872f0ddfa84fc7847b9ea0f127fd26f14ba681 src/kioslaves/search/kio_search.cpp dc8dfcc3c2c28b6d2dd6df94f8f4627b15d08261 src/kioslaves/timeline/timelinetools.cpp 4972a570ca9ef9e8e1d191ffee7f011747adbcf4 Diff: https://git.reviewboard.kde.org/r/119622/diff/ Testing --- Thanks, Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Problem with KCompTreeNode on Windows (or: destruction order of static objects?)
Am Donnerstag, 12. Dezember 2013, 11:27:07 schrieb Frank Reininghaus: > Hi, > > 2013/12/11 Kevin Funk: > [...] > > >> > > Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't > >> > > help > >> > > either. I get the same destruction order + crash with that on > >> > > Windows. > >> > > > >> > > Dynamic allocation inside KCompTreeNode doesn't work either, because > >> > > KZoneAllocator needs to be there *before* the first KCompTreeNode is > >> > > created and needs to there *until* the last one has been destroyed. > >> > > > >> > > Any ideas? > >> > > >> > Well, here is one idea (untested): use a > >> > QSharedPointer to ensure that the KZoneAllocator is > >> > not destroyed before the last KCompletion instance using it. > >> > > >> > Replace > >> > > >> > static KZoneAllocator alloc; > >> > > >> > in KCompTreeNode by > >> > > >> > static QSharedPointer alloc; > >> > > >> > and, in kcompletion.cpp, > >> > > >> > KZoneAllocator KCompTreeNode::alloc(8192); > >> > > >> > by > >> > > >> > QSharedPointer KCompTreeNode::alloc; > >> > > >> > In KCompTreeNode's operator new/delete, replace "alloc." by "alloc->". > >> > > >> > Furthermore, add a QSharedPointer member to > >> > KCompletionPrivate. In KCompletionPrivate's constructor, first check > >> > if KCompTreeNode::alloc isNull(), initialize it if that is not the > >> > case, and then copy "alloc" to the new member. > >> > > >> > I think that this might work, and it might also improve application > >> > start-up time because the KZoneAllocator would only be initialized on > >> > first use of a KCompletion object. > > > > Hey Frank, > > > > thanks a lot for sharing your thoughts! > > > > I just tried your suggestion, and it indeed fixes the issue on Windows > > (and > > doesn't cause havoc on Linux either). See attached patch (v1). I think it > > pretty much resembles your thoughts. > > great, I'm glad to hear that! I'd recommend to remove the unrelated > changes in KZoneAllocator though - they just make the patches harder > to understand. Unfortunately it's not really unrelated -- When using qDebug() in ~KZoneAllocator, that sometimes seems to crash in deep inside Qt (QTextCodec/QIconvCodec) during __cxa_finalize. Apparently it is too late to call qDebug() at this point. (Reduced) Backtrace: #0 malloc_consolidate (av=av@entry=0x76061740 ) at malloc.c:4088 #1 0x75d210e1 in _int_malloc (av=0x76061740 , bytes=32640) at malloc.c:3379 #2 0x75d234d0 in __GI___libc_malloc (bytes=32640) at malloc.c:2859 #3 0x75cc2b19 in __gconv_open (toset=0x44db30 "\002", toset@entry=0x7fffd660 "//", fromset=0x7fff , fromset@entry=0x7fffd640 "UTF-16//", han dle=handle@entry=0x7fffd680, flags=flags@entry=0) at gconv_open.c:283 (and further:) #4 0x75cc24a1 in iconv_open #5 0x774703b2 in QIconvCodec::createIconv_t #6 0x7746fd13 in QIconvCodec::convertFromUnicode #7 0x77469aa7 in QTextCodec::fromUnicode #8 0x77346b24 in QString::toLocal8Bit #9 0x776a10ac in QDebug::~QDebug #10 0x777da9f6 in KZoneAllocator::~KZoneAllocator #11 0x77b82e48 in QtSharedPointer::ExternalRefCount::deref > > However, I'm not quite sure this approach is going to be accepted > > upstream. > > One issue, for example, is that KCompTreeNode now has a publicly > > accessible > > static KZoneAllocator* member and explicitly setting the allocator from > > within KCompletion seems odd. That completely makes KCompTreeNode(s) > > depend on KCompletion. > > > > I'm proposing another approach: > > - Still using QSharedPointer > > - But: Initialize this shared-pointer directly (as with the static KZA > > member) - And: Keep a strong-ref in KCompletion on that shared pointer > > See attached patch (v2) > > > > Any objections? Otherwise I'll post that patch to reviewboard ASAP. > > well, I guess it might be considered a matter of taste. The reason why > I find v1 slightly better is that the initialization of the custom > allocator is deferred until it is really needed. Right now, the > KZoneAllocator constructor will be called on startup fo
Re: Problem with KCompTreeNode on Windows (or: destruction order of static objects?)
Am Mittwoch, 4. Dezember 2013, 16:36:12 schrieb Milian Wolff: > On Wednesday 04 December 2013 16:01:03 Frank Reininghaus wrote: > > Hi, > > > > 2013/11/30 Kevin Funk: > > > Hey guys, > > > > > > My recent attempts to make KDevelop shine on Windows revealed some odd > > > behaviour inside kdelibs. > > > > > > I need some help in order to find the right approach to fix an at least > > > 3 > > > year old bug [1] ultimately caused by the use of a static member object > > > in the KCompTreeNode class (kcompletion.h) in kdelibs. Please see the > > > attached bug report [2]. > > > > > > Note that the error *only shows up on Windows*, on Linux we don't have > > > this > > > problem. I'll try to explain what's wrong in this mail. > > > > > > The actual issue: > > > - KDevelop running: > > > - We have an instance of KateGlobal owned by KateFactory, > > > > > > a plugin loaded by KDevelop > > > > > > - Some descendant of KateGlobal (KateCmd) owns a KCompTreeNode instance > > > - KCompTreeNode uses a custom allocator for creating/deleting instances > > > > > > of itself, holds a static member of type KZoneAllocactor for that > > > > > > - KZoneAllocator holds the memory for all the instantiated > > > KCompTreeNodes > > > > > > So we have the following object ownership (some levels omitted): > > > - KateFactory > > > > > > KateGlobal > > > > > > KCompTreeNode > > > > > > KZoneAllocator (static) > > > > > > When closing KDevelop *under Linux*: > > > - ~KateFactory, via QObjectCleanupHandler during __run_exit_handlers > > > (glibc)> > > > > > > ~KateGlobal, via call to KateGlobal::decRef() > > > > > > ~KCompTreeNode > > > > > > - ~KZoneAllocator, during __cxa__finalize (glibc) > > > > > > The order is fine in this case. No segfaults. > > > > > > However, on Windows the destruction order is different (and I cannot > > > really > > > explain why). When closing KDevelop *under Windows*: > > > - ~KZoneAllocator is called first, via > > > > > > "kdeui.dll!`dynamic atexit destructor for > > > 'KCompTreeNode::alloc''()" > > > > > > - ~KateFactory, via QObjectCleanupHandler > > > > > > ~KateGlobal > > > > > > Call to KCompTreeNode::removeItem() > > > > > > => Crash because memory for the KCompTreeNode instances was already > > > freed > > > > > >by ~KZoneAllocator > > > > > > I wonder how to fix that: > > > The easiest solution obviously: Get rid off the custom allocator in > > > KCompTreeNode. Having a class owning its custom allocator is just plain > > > wrong, right? But removing that probably has performance impacts. (Does > > > anyone have benchmarks here?) > > > > well, having a custom allocator may have some benefits. I guess that > > KCompletion uses one to ensure that all KCompTreeNodes are close to > > each other in memory and thus to reduce cache misses? I don't know how > > much dropping the custom allocator would affect the performance, one > > would have to do some benchmarking with typical KCompletion use cases. > > I agree that it might be a good performance improvement. But I want to note > neither KDevelop nore Kate uses this technique for its code completion in > the editor. And we probably have much more completion tree nodes than a > usual KCompletion user. I just mention this to show that removing this > performance improvement should not kill the performance, rather decrease it > slightly. > > > Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't help > > > either. I get the same destruction order + crash with that on Windows. > > > > > > Dynamic allocation inside KCompTreeNode doesn't work either, because > > > KZoneAllocator needs to be there *before* the first KCompTreeNode is > > > created and needs to there *until* the last one has been destroyed. > > > > > > Any ideas? > > > > Well, here is one idea (untested): use a > > QSharedPointer to ensure that the KZoneAllocator is > > not destroyed before the last KCompletion instance using it. > > > > Replace > > > > stati
Problem with KCompTreeNode on Windows (or: destruction order of static objects?)
Hey guys, My recent attempts to make KDevelop shine on Windows revealed some odd behaviour inside kdelibs. I need some help in order to find the right approach to fix an at least 3 year old bug [1] ultimately caused by the use of a static member object in the KCompTreeNode class (kcompletion.h) in kdelibs. Please see the attached bug report [2]. Note that the error *only shows up on Windows*, on Linux we don't have this problem. I'll try to explain what's wrong in this mail. The actual issue: - KDevelop running: - We have an instance of KateGlobal owned by KateFactory, a plugin loaded by KDevelop - Some descendant of KateGlobal (KateCmd) owns a KCompTreeNode instance - KCompTreeNode uses a custom allocator for creating/deleting instances of itself, holds a static member of type KZoneAllocactor for that - KZoneAllocator holds the memory for all the instantiated KCompTreeNodes So we have the following object ownership (some levels omitted): - KateFactory KateGlobal KCompTreeNode KZoneAllocator (static) When closing KDevelop *under Linux*: - ~KateFactory, via QObjectCleanupHandler during __run_exit_handlers (glibc) ~KateGlobal, via call to KateGlobal::decRef() ~KCompTreeNode - ~KZoneAllocator, during __cxa__finalize (glibc) The order is fine in this case. No segfaults. However, on Windows the destruction order is different (and I cannot really explain why). When closing KDevelop *under Windows*: - ~KZoneAllocator is called first, via "kdeui.dll!`dynamic atexit destructor for 'KCompTreeNode::alloc''()" - ~KateFactory, via QObjectCleanupHandler ~KateGlobal Call to KCompTreeNode::removeItem() => Crash because memory for the KCompTreeNode instances was already freed by ~KZoneAllocator I wonder how to fix that: The easiest solution obviously: Get rid off the custom allocator in KCompTreeNode. Having a class owning its custom allocator is just plain wrong, right? But removing that probably has performance impacts. (Does anyone have benchmarks here?) Just using K_GLOBAL_STATIC for the KZoneAllocator instance doesn't help either. I get the same destruction order + crash with that on Windows. Dynamic allocation inside KCompTreeNode doesn't work either, because KZoneAllocator needs to be there *before* the first KCompTreeNode is created and needs to there *until* the last one has been destroyed. Any ideas? Greets [1] https://bugs.kde.org/show_bug.cgi?id=243375 (initial bug report) [2] https://bugs.kde.org/show_bug.cgi?id=327599 (contains stack traces) -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Amarok
On Saturday 24 March 2012, 00:14, Bezruchenko Alexandr wrote: > Does amarok have library to send requests to the Spotify? Hey, First, Amarok has its own mailing list: amarok-de...@kde.org Second, there is not Spotify integrated yet but there is a GSoC proposal for 2012 [1]. [1] http://community.kde.org/GSoC/2012/Ideas#Project:_Spotify_Collection Greets -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Re: KConfigXT and settings external changes
On Tuesday 06 September 2011 00:14:21 Milian Wolff wrote: > Milian Wolff, 06.09.2011: > > Francesco Di Muccio, 05.09.2011: > > > Hello all, > > > > > > In my application I'm using KConfigXT, everything works fine when I > > > change the settings values from the dialog inherited by > > > KConfigDialog, > > > but if I write the configuration values using the class generated > > > from > > > the kcfg file the changes are not reflected into the settings > > > dialog. > > > Here is the flow: > > > > > > 1) Open the settings dialog (it will be cached by KConfigDialog), > > > change some values and close it > > > 2) Call some code that writes the same values using the class > > > generated by kcfg generator > > > 3) Reopen the dialog cached instance. The values shown by the > > > widgets > > > are the old ones. > > > > > > I read the docs and the tutorial at > > > http://techbase.kde.org/Development/Tutorials/Using_KConfig_XT, but > > > didn't find anything that pointed me to a wrong use of the > > > framework, > > > so maybe it is a bug. > > > > > > To be sure I read the sources of KConfigDialog and maybe spotted the > > > problem: in KConfigDialog::showEvent() there is a check to a boolean > > > flag KConfigDialog::KConfigDialogPrivate::shown that get set to > > > true at the end of the method but never set to false. > > > In the showEvent() method there is the code that updates the widgets > > > according to KConfigSkeleton state. Since "shown" is never set to > > > false that code will not be executed the next time the > > > dialog->show() > > > is called. > > > I didn't find a way to force KConfigDialog to update the widgets; > > > the > > > responsible to update them is KConfigDialogManager and it's enclosed > > > in KConfigDialog::KConfigDialogPrivate. > > > > > > I did an ugly hack to make it work: discarding the cached instance > > > in > > > place of a new one each time the settings dialog is opened. > > > > > > I didn't fill a bug report because i was unsure if it was an > > > expected > > > behavior or not. Am I missing something? > > > > Do you ever call YourConfig::writeConfig() ? > > > > Otherwise take a look at e.g. > > > > https://projects.kde.org/projects/extragear/sdk/massif- > > visualizer/repository/revisions/master/changes/app/configdialog.cpp > > and > > https://projects.kde.org/projects/extragear/sdk/massif- > > visualizer/repository/revisions/master/changes/app/mainwindow.cpp > > > > it works like a charm there. To be honest though I'm not sure whether I > > leak the settings dialogs in app::preferences, I should investigate that > > > > :) > > Ah ok - I delete the dialog on close (via the attribute). Probably that is > all that is required? > > bye Yep, although I would not set the attribute in the dialog's constructor. For external users of your class it is quite hidden and modifies normal behaviour. Assume: ConfigDialog* dlg = new ConfigDialog(); dlg->show(); // ... // dlg gets closed // ... delete dlg; // error: double-free Better do: ConfigDialog* dlg = new ConfigDialog(); dlg->setAttribute(...); // so people *know* it's getting deleted. Not a serious issue after all. Sorry for the nit-picking, I was bored. Greets -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Widget Focus
Wednesday 22 June 2011, Steven Sroka : > Is there any way to set focus to manually a widget when a window opens? I > used QRadioButton::setFocus(Qt::ActiveWindowFocusReason), but it doesn't > help, the first widget placed on the window always has focus. Hey, Do you call setFocus *after* creating/layouting the widgets? Constructing other widgets afterwards will change the keyboard focus, so be sure to make this call last. Other than, it might help to use the event loop for calling the setFocus() slot on a widget, e.g.: QTimer::singleShot(0, widget, SLOT(setFocus())); This ensures that the widget(s) is/are fully constructed before receiving the focus activation. Hope this helps, Greets -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: How to load KDE plugins from a dev directory?
Friday 25 February 2011, augustin : > On Friday 25 February 2011 04:02:16 pm Kevin Krammer wrote: > > Welcome to KDE development :) > > Thank you Kevin for your welcome and for your prompt response. > You gave me a lot of useful information. I'll take time to test it and > digest it all. I'll check the techbase, too. > I'll post again if I get stuck somewhere :) > > Blessings, > > Augustin. > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to > >> unsubscribe << This might be also very interesting to you: http://techbase.kde.org/Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc (sourcing this basically sets all the required environment variables you need) I'm using this to install the complete KDE environment (and other cmake based applications) to user-space. Very helpful for development purposes. Greets -- Kevin Funk >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
