Re: Supporting MSVC2010 in ktexteditor framework
Hi! On 05 Nov 2014, at 09:02, Kevin Ottens er...@kde.org wrote: I propose to bump the required compiler versions across the board to compilers that fully 100% implement C++11. It is 2014 and C++14 is finalised. And we are a Free Software project and none of our compilers have any problems with that. In the case of VC there's no such compiler yet. Even VS2013 is not 100% compliant. There will always be small differences. The big picture is important. And the big picture IMO is that restricting ourselves in 2015 to the feature set of a compiler released in 2009 and is two major revisions of the language behind is bonkers. It also deters more users and contributors than we can ever gain with it (that is my similarly unprovable claim :-) ). My reasoning is that KDE’s frameworks need to be showcases of excellent pieces of software to attract users and contributors and this limitation plays against that. In more general terms, the benefits we can gain from fully utilising our excellent programming language outweigh by far the potential fringe utility of gaining 0.5% users of non-free outdated compilers. I strongly disagree here because of the above. There's quite a few potential users on non-free platforms (some I already talked to in fact). It happens that one of those platforms is Windows where VC is the most pervasive compiler. Now, my experience when visiting customers is that quite a few are still stuck with VS2010 but the majority seems to be actively using VS2012 now. Early on I was wondering if those VS2010 users could be using our stuff, I'm more and more thinking with their profile it won't be the case. “Potential users” are a void claim without any data to back this up, and we do not have any data AFAIK. In todays numbers, these potential users (who aren’t users yet) are not a significant group. I would say that a reasonable threshold to consider such a limitation would be something like 20% or even 10% of existing contributors. From what I can tell, those Windows developers that contribute use more modern VC compilers than 2010. If need be, ask the contributors for their preference. Poll for it. Do something about it. I do not think that this limitation in language features has the support of the contributors. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Supporting MSVC2010 in ktexteditor framework
Hi, On 05 Nov 2014, at 04:33, Nicolás Alvarez nicolas.alva...@gmail.com wrote: So, I hereby propose making an exception and bumping the minimum compiler version *for ktexteditor only* to MSVC2012. Opinions? I propose to bump the required compiler versions across the board to compilers that fully 100% implement C++11. It is 2014 and C++14 is finalised. And we are a Free Software project and none of our compilers have any problems with that. In more general terms, the benefits we can gain from fully utilising our excellent programming language outweigh by far the potential fringe utility of gaining 0.5% users of non-free outdated compilers. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [dot] KDE Frameworks 5.2.0 release
Hello David, notable changes are: * The maximum worker count will now decrease if a lower value is set after workers have been created. Previously, workers would remain active once they have been created. * Examples from the previous ThreadWeaverDemos Github repository are being merged into the KF5 ThreadWeaver repo. * The maximum worker count can now be set to zero (the previous minimum was 1). Doing so will effectively halt processing in the queue. * Documentation of various aspects of ThreadWeaver use is becoming part of the KDE Frameworks Cookbook. Parts of it is located in the examples/ directory. These should be the high level changes. Cheers, Mirko. On 09/10/2014 11:05 AM, David Faure wrote: I extracted the following changelog items from git commits. But I don't really understand the plasma-framework and threadweaver commits Mirko and Plasma people: can you tell me the relevant changes ? -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Snippetextractor comments in framework examples
Hi, On 08/18/2014 09:50 AM, David Faure wrote: On Monday 11 August 2014 10:34:40 Rohan Garg wrote: Hi everyone As part of writing the KDE Frameworks 5 book, we were wondering if it's fine with all the framework maintainers if we started adding snippetextractor comments in the examples to be able to directly quote things in the book from the examples in the framework we're writing about. No objection. I wonder if this can be useful for the apidox too -- just like Qt marks code for extraction into the api docs It should probably do this out of the box. Depending on the intended output format, some minor changes may be required (specifying what format is exptected, basically). At the moment it only produces Markdown output, but Doxygen is able to process thart AFAIK. The book and the threadweaver repo have some simple examples on how to use the extractor. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 ThreadWeaver Examples?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Brian, On 08/02/2014 03:54 AM, Brian Duffy wrote: I'm interested in toying around with ThreadWeaver in my Qt5 application. I installed ThreadWeaver on my Fedora box from the repo on COPR. I can't find any example code. I'm not sure where else to look. Any suggestions? Sorry for the late response. I just came back from the Randa meeting. You can now find examples in the ThreadWeaver repo, and 10 pages of introduction in kde:kf5book. Have fun, and if you have any questions, please let me know. Mirko. - -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPucEQACgkQYSSaITCTnKXLPQCdE2dW82c8cxPfWfGt3zzzv4yU QKEAn38KGHQtReoKyXM02+EkibNAX0va =TXiH -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: For Book Sprint team: Frameworks Cookbook
Hello, at the moment, we look at authoring two chapters of the frameworks book: The first chapter will be relatively short introductory sections that explain how some common problems are solved by using KF5. Sample questions are * dealing with archives and compressed data * reaching a wider audience with translations * adding crash reporting to an application * making apps more efficient using concurrency * escalating privileges More may follow (for example, KConfig is also on the table). Each of these is planned to be a combination of one or two illustrated programming examples and a page or two of explanation of the very basic concepts. Details will be deferred to the later chapters. The second chapter will then contain detailed articles about the individual frameworks. They should build on the introduction in the first chapter, and cover questions that developers do not need to be concerned with at the start. These detailed chapters probably require the author of the framework to take part in writing them. There are a few questions that have been discussed at length: * Our target audience are developers new to the frameworks, but with existing programming experience. The book will not cover basics about Qt, but will instead refer to the Qt documentation and introductions. It is also not meant to replace API documentation. * We would like to achieve a natural build up from consuming the introduction to reading about the details to moving on to working mostly with the documentation. For that, we are still discussing where tutorial like content should be stored (as this could possibly reference multiple frameworks) and how the book can be produced without duplicating content. Your help and input is welcome. * We are trying to solve the issue of not having to copy-paste code from the examples and framework sources but still show it in the book. Here is an attempt: https://github.com/endocode/snippetextractor This in the end means that where the book format (PDF, ePub, ...) is produced from the input files, the frameworks and examples sources need to be available. We are still discussing about the best way to achieve that. For now, we are working in a scratch repo at kde:scratch/garg/book. Cheers, Mirko. On 08/10/2014 02:26 PM, Valorie Zimmerman wrote: Even more basic: for right now, we've created a scratch git repo: kde:scratch/garg/book -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: For Book Sprint team: Sample Frameworks Cookbook
Ok, I am signed up and good to go. See you all in Randa. Mirko. On 08/06/2014 12:22 PM, Valorie Zimmerman wrote: Hi folks, I've started a book for you to play with. Load up http://booki.flossmanuals.net/kde-frameworks-cookbook/_edit/ and have fun. Make a login, make some chapters, drag them around, and see what everything looks like. Unfortunately the editor won't save for me tonight; I actually did add content to a chapter, but I can't see it. I'll consult the flossmanuals folks about this or try different browsers tomorrow. See you soon in Randa! -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks Cookbook book sprint
Hi Valorie, On 07/31/2014 10:50 AM, Valorie Zimmerman wrote: It would be good to decide on what writing platform we'll use. Rohan and I are both familiar with Booki at Flossmanuals. I found a book (available as an epub too) about Booki itself: http://www.flossmanuals.net/booki-user-guide/ Flossmanuals also has a nice guide to running book sprints: http://flossmanuals.net/book-sprints/ It has also been suggested that we use Sourcefabric: http://www.sourcefabric.org/en/booktype/ There was a meet where both these platforms were discussed: http://www.flossmanuals.org/news/booktype-floss-manuals-ebooks-learning-platform-future-cetis-2014 Perhaps we should test these out a bit, and see which suits the majority of us -- including you remote writers. I don't really have an opinion because I have no first-hand experience with these tools. Considering you two are familiar with Booki - if you consider it a good tool, let's go for it, unless anybody comes up with a different opinion. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Writing a Frameworks book at Randa
Hi, On 05.05.2014 11:21, Valorie Zimmerman wrote: it would be great if you could make remote participation possible. While it's too difficult for me to participate in the sprint directly I would be able to remote participate. Cheers Martin Excellent idea, Martin. I'll try to have instructions for those who want to participate remotely all set up before we arrive in Randa. For now, I hope people will start filling in the wiki page, and get ideas percolating. Of course we will have IRC, but I hope it will be easy for people to directly work on the book text from everywhere. I think I mentioned it before, but just to be sure - I am happy to join in effort this during Randa. As for getting more contributors to it, I suggest to have a look at booktype (http://www.sourcefabric.org/en/booktype/). Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forwarding headers for ThreadWeaver
Hi! On 01 Jan 2014, at 18:37 , David Faure fa...@kde.org wrote: On Wednesday 01 January 2014 18:27:36 Mirko Boehm wrote: Hi, On 01 Jan 2014, at 17:26 , David Faure fa...@kde.org wrote: I'm converting all frameworks to ecm_generate_headers, which creates Framework/File forwarding headers for framework/file.h headers. But ThreadWeaver creates an issue: it has File.h headers (titlecase), to be included like Weaver/Job.h Shall we leave it as is then? Or convert it to weaver/job.h (lowercase) and Weaver/Job? Both are fine with me. It should be done the same way as with the other modules. Which way is the official one? The official way used by all other modules would be threadweaver/job.h (lowercase real header) and ThreadWeaver/Job (forwarding header) Ok. Why was the Thread word been removed? I cannot say, I did not change it (at least not purposefully, maybe this is a side effect of changes in the build system). The Weaver/ directory was always the subfolder in the source directory, and threadweaver/ was used when installing. Oh OK, I should have been looking outside (e.g. in plasma), not in TW itself. Indeed plasma uses threadweaver/Job.h, so I was wrong, Weaver hasn't been removed. OTOH to really make threadweaver like the other modules, I would move src/Weaver/* to src/*, the subdir isn't useful. Is that a change that has any meaning to the outside world? If not, that can be done later as well. Since I was sick most of December, I am not completely done with the final touches for the release. I get back home on the 3rd, and will finish the last items on the TODO list on the 4th. Since this includes a few final class name changes, it needs to be synced with the followup changes in Plasma (nothing big). So from my point of view, ThreadWeaver should be ready early week 2. I want to release TP1 asap (i.e. once all forwarding headers are installed), but SIC changes can still be done afterwards. Threadweaver cannot be released before the class name changes are done, because those will be source incompatible. I get back tomorrow night, and will finish it on Saturday. After that, all other changes are incremental and BC, so the release would get unblocked. Sorry for that. We are not having the threadweaver/ and ThreadWeaver/ directories in the same folder, right? Because that would not work on either OSX nor Windows (stating the obvious, I think). Well, not that obvious - we didn't think about that :) But thinking about it, I don't think it will create a problem. We install into threadweaver/job.h and ThreadWeaver/Job, on Windows it might end up in the same directory, but that's just fine, right? The includes will work whichever case the directory has. Not sure how OSX works. OSX uses a case insensitive but in all other aspects UNIX like file system (with symlinks et cetera) by default. I feel slightly uncomfortable with installing into the same directory because it may lead to weird clashes if there are file names that only differ in case - those will end up being the same file on Windows and OSX. Can be avoided, but is a potential pitfall. Ok, so train ride tomorrow, then hacking to get through the final TODO list. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forwarding headers for ThreadWeaver
Hi, On 02 Jan 2014, at 15:37 , David Faure fa...@kde.org wrote: On Thursday 02 January 2014 15:29:13 Mirko Boehm wrote: The official way used by all other modules would be threadweaver/job.h (lowercase real header) and ThreadWeaver/Job (forwarding header) Ok. Is this a green light for us to convert all of threadweaver (and its users) to this scheme? (or do you plan to do so?) Actually, I *know* I have unpushed changes at home where I started with the class renaming. These will very likely clash with header file renamings. So I can take care of that on Saturday. If I need help, I will holler on IRC. OTOH to really make threadweaver like the other modules, I would move src/Weaver/* to src/*, the subdir isn't useful. Is that a change that has any meaning to the outside world? If not, that can be done later as well. Well, it makes sure that nothing can include Weaver/File.h :) But OK, only two unittests do that, I thought there was more. I'll make that change unless you object, because it makes it easier to script stuff across all frameworks (like I've been doing in the last 48 hours, and will do again since we changed the include path a little bit...). Please wait, for the same reason as above. If you want to, we can set a time for Saturday and meet, and get everything ready. Sorry for being a pain here :-) What you could do is change the occasions you find that use the Weaver/ subdirectory to use the official include directory. Then removing the subdirectories should not affect anybody outside of the ThreadWeaver source. I want to release TP1 asap (i.e. once all forwarding headers are installed), but SIC changes can still be done afterwards. Threadweaver cannot be released before the class name changes are done, because those will be source incompatible. I get back tomorrow night, and will finish it on Saturday. After that, all other changes are incremental and BC, so the release would get unblocked. Sorry for that. As I said, TP1 does NOT include a SC promise, it's ok to make SC changes afterwards. The class name changes will be source *in*compatible. But yeah, with the unexpected delays due to the forwarding header stuff it's too late for tagging today, so I'll do that on Sunday, with your changes from Saturday in. OSX uses a case insensitive but in all other aspects UNIX like file system (with symlinks et cetera) by default. I feel slightly uncomfortable with installing into the same directory because it may lead to weird clashes if there are file names that only differ in case - those will end up being the same file on Windows and OSX. Can be avoided, but is a potential pitfall. Only the directories clash, never the actual files, since the lowercase headers have a .h extension and the CamelCase headers have no extension. And we can't fully fix the clash anyway... for non-namespaced frameworks like kcoreaddons we can (KCoreAddons/kjob.h and KCoreAddons/KJob) but for namespaced frameworks like KIO and KParts (and ThreadWeaver) we'll still have KIOCore/KIO/Job and KIOCore/kio/job.h, since there's a lot of code that uses kio/job.h out there. My planned fix is to never lowercase the framework name anymore, but the prefix can be lowercased, leading to KIO and kio dirs side by side. No filename clash though, ever. Agreed, it is only a remote possibility and that can be managed when needed. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forwarding headers for ThreadWeaver
Hi, On 01 Jan 2014, at 17:26 , David Faure fa...@kde.org wrote: I'm converting all frameworks to ecm_generate_headers, which creates Framework/File forwarding headers for framework/file.h headers. But ThreadWeaver creates an issue: it has File.h headers (titlecase), to be included like Weaver/Job.h Shall we leave it as is then? Or convert it to weaver/job.h (lowercase) and Weaver/Job? Both are fine with me. It should be done the same way as with the other modules. Which way is the official one? Or weaver/Job.h and Weaver/Job? But ecm_generate_header doesn't support non- lowercase headers so I'm not sure how to do that. KDE4 had threadweaver/Job.h and ThreadWeaver/Job. Why was the Thread word been removed? I cannot say, I did not change it (at least not purposefully, maybe this is a side effect of changes in the build system). The Weaver/ directory was always the subfolder in the source directory, and threadweaver/ was used when installing. Since I was sick most of December, I am not completely done with the final touches for the release. I get back home on the 3rd, and will finish the last items on the TODO list on the 4th. Since this includes a few final class name changes, it needs to be synced with the followup changes in Plasma (nothing big). So from my point of view, ThreadWeaver should be ready early week 2. We are not having the threadweaver/ and ThreadWeaver/ directories in the same folder, right? Because that would not work on either OSX nor Windows (stating the obvious, I think). Happy new year, guys and girls! 2014 will certainly be the year of the Linux desktop! Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 01:37 PM, Kevin Ottens wrote: if a package foo uses ecm (or that non existing tier0 cmake package) itself, this does not mean that another package which uses foo, also needs ecm (or that tier0 package) at buildtime. Well, if the tier 0 package contains the compiler settings for our frameworks, it'd mean everything tier 1 and up would use it. The alternatives right now being: duplicate the info or have it in cmake/ecm. So far we chose the have it in cmake/ecm route. If we had what Mirko refers to, then that'd open the door to another solution. Anyone up for hacking this up next week? I am available starting Monday afternoon. Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzoR4ACgkQYSSaITCTnKWHFACgv1aFktYPptBQ+G5hksS8qD/b 6ycAoJ09e/NwkonRqgMgtO3g70SyHJY8 =rnOY -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 01:53 PM, Sune Vuorela wrote: So far we chose the have it in cmake/ecm route. If we had what Mirko = refers=20 to, then that'd open the door to another solution. And it would open the first door towards alienating linux distributions. Of course, we could say and so what?. But that is our current primary way of getting our stuff to our users - so we shouldn't put obstacles in their way. Maven, ruby and stuff is all communities where there seem to be a strong tension with the linux distributions over issues like this. Let's not try to embrace that. Sune, with what I have suggested, there would be no difference for distributions regarding ECM. Now, they have to get ECM installed and tell CMake where to find it. Then, they will have to get the ECM repo installed, and tell CMake where to find it. For the offline case, I do not see a big difference. I don't want to downplay the concerns, but I think the problem is manageable. Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzpRMACgkQYSSaITCTnKXsZACfTa+FNQBFCwAW33kIXtcWcIzY BFcAoLDFhevjYbESagkg4J5V+uuX3+YQ =yVwn -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113535: Fix build with latest ThreadWeaver
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/#review42771 --- Ship it! Looks good to me, approved. - Mirko Boehm On Nov. 1, 2013, 1:31 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113535/ --- (Updated Nov. 1, 2013, 1:31 p.m.) Review request for KDE Frameworks and Plasma. Repository: plasma-framework Description --- With recent API updates in ThreadWeaver, enqueueRaw() was obsoleted. According to ThreadWeaver maintainers, the correct way to restart threads is to call reschedule(), but I am not sure if my fix is correct, partly because the comment seems to be in the wrong place. Diffs - src/plasma/private/runnerjobs_p.h dfc2aca src/plasma/runnermanager.cpp ee4851f Diff: http://git.reviewboard.kde.org/r/113535/diff/ Testing --- Compiles, no further testing. Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Exceptions in KDE Frameworks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, in ThreadWeaver, I would like to be able to catch exceptions thrown from the run() method of Jobs. You know we cannot trust the user :-) I can work around if exceptions are disabled in the compiler if I know about it. What I would like to be able to do is a) catch JobAborted and JobFailed exceptions thrown by the user, and set the job's status accordingly, b) catch other unhandled exceptions, print an error message and re-throw them. Unhandled exceptions in the worker thread basically mean the end of the program, as far as I am concerned, but I would like to be able to exit cleanly. Two questions: 1) Are we sure we want to disable exceptions in libraries released in 2014? 2) What is the _BLBAFASEL_EXCEPTIONS_ENABLED_ preprocessor variable that I can use to implemented the exception- and non-exception based code paths? Thanks, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJz1woACgkQYSSaITCTnKVaoQCeI9L48n2Cn8TA5X9nC1tLctzV XagAoIyUwA9sBOhFbkSWupsCA2P2YJHt =hAER -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Getting ecm files from the ECM package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/01/2013 06:46 PM, Nicolás Alvarez wrote: and so forth. That would be a real breakthrough. It is related to the approach taken by Maven and others. All it takes is a built-in way for CMake to download the find_modules into a cache location and update them when needed, or on request. Yes, that's definitely something we've been missing for a long time compared to the java crowd who massively use Maven. It is an *excellent* feature, and would solve this kind of headaches we have with the build system. I don't know how to even begin arguing against this, because if you don't see how wrong it is to download stuff during compilation, I don't know what arguments would help. I actively avoid any build system that automatically downloads dependencies. In fact, I avoid any tool that automatically downloads and installs software except for my distro's package manager and kdesrc-build. That means no easy_install, pip, rubygems, npm, maven, or whatever NIH package manager the $language community invented now. Maven is a disgusting monstrosity used by the Java crowd where backwards compatibility rarely exists, and the approach to make things not break is to make packages depend on exact versions of dependencies and download them automatically from who-knows-where. And then the same craziness gets copied or reinvented for other languages too. You don’t want a build tool which automatically downloads unresolved dependencies before cleaning out your build output directories. You don’t want a build tool which automatically downloads unresolved dependencies, PERIOD! Automatically downloading unresolved dependencies makes your build process nondeterministic! -- http://kent.spillner.org/blog/work/2009/11/14/java-build-tools.html I'm also surprised at Almost everybody has internet access for build machines. Is there *any* Linux distro where that's the case?? Pretty strong language. Not much proof. Do you *know* how Red Hat or SuSE build their packages? To me, build systems should not download anything sounds like a movie from the 80ies. I haven't heard much in terms of pro and con arguments in this discussio, just how dare you. I have been in extensive discussions about this topic, and both sides have good arguments. The truth is somewhere in the middle, because it depends on your situation. For example, from a developers point of view, what is the difference between me pulling the ECM repo and CMake doing it automatically? A brain? In my opinion, a central repository of community maintained find module packages has a chance of making a real difference. We have been debating the deployment problem of find modules for a long time, and obviously the solutions we currently have do not make everybody happy. Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJ0IAkACgkQYSSaITCTnKUyIACeLd9CDT9WRqifYP9zEYv6YejG tXAAnRGswOSmcYwJzBZ1UTqOVfxQazOs =7ZOv -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: please make it easier to hack on frameworks
On Apr 29, 2013, at 18:13 , Alexander Neundorf neund...@kde.org wrote: I am all for requiring only released versions of cmake. Or at least announcing it when an update is required. But it seemed to be the majority opinion that this is not necessary in kf5. Majority by what definition? :-) Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist and Trainer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: The (unknown) KDE-Platform-independent libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2013 11:13 PM, David Gil Oliva wrote: --From Wikipedia: *ThreadWeaver* is a programming library developed for KDE 4 http://en.wikipedia.org/wiki/KDE_Software_Compilation_4^[1] http://en.wikipedia.org/wiki/ThreadWeaver#cite_note-CNET-1 by Mirko Boehm that allows developers to easily take advantage of multi-core processors http://en.wikipedia.org/wiki/Multi-core_processor.^[1] http://en.wikipedia.org/wiki/ThreadWeaver#cite_note-CNET-1 In ThreadWeaver the workload is divided into individual jobs, then relationship between jobs (what order they should be completed or which has a higher priority); from that ThreadWeaver will work out the most efficient way to execute them. Krita http://en.wikipedia.org/wiki/Krita has implemented visual filter previews using ThreadWeaver to prevent GUI lockups. I think that the fact that developers don't use KDE-Platform-independent libraries won't cease until something is done about the texts of these packages. Something like Multiplatform C++ Qt-based multithreaded library would be so much appealing! I know I can use ThreadWeaver because I have entered this project. Otherwise, I would have never considered it. Hello David, thanks for the encouragement. It is actually a good time to talk about this, since the KDE Frameworks that we are just building are meant to be more mix-and-match type extensions to Qt than before. For ThreadWeaver, I plan to write a number of posts about how it can be used, and will stress the fact that it can be used in about any C++ project. I hope the other framework developers agree when I say that the best time to begin advertising this is around the KDE conference this year, which will be held together with the Qt Contributor Summit. Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFeo9AACgkQYSSaITCTnKWedQCgniPL04UxBbNG7uR7oWC+2379 8rwAniaEF75heUicj5Az+xtAGtN3CoZJ =u9Ep -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: FYI: Updates in ThreadWeaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2013 05:05 PM, Sebastian Kügler wrote: - - Examples are currently in the kdelibs tree, at tier1/threadweaver/examples. I like that they are in the same repository, but still - is this the right place? If not, we have the kdeexamples repository for such things. Two more questions: - - I have some code that should only be compiled for debug builds. Which is the preferred macro to do that? At the moment, I am using the classical NDEBUG, which probably is not what we are using: #if not defined NDEBUG d-debugExecuteWrapper.wrap(setExecutor(d-debugExecuteWrapper)); #endif - - As for tests, I now have four unit tests programs amounting to ~40 tests total. One of them has 28 of the tests. I wonder if I should simply put all the tests into one unit test binary, or not. Note that this does not include benchmarks, those are separate. What is the preferred way? Cheers, Mirko. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFb49QACgkQYSSaITCTnKWMggCgvbd7QLpSLZZpp0RmgqEbu4h4 W0IAnimAvQahHgavHTNSSTYYscAAzCUY =yyMu -END PGP SIGNATURE- ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Separating everything ?
Hi, On Feb 8, 2013, at 02:07, Patrick Spendrin ps...@gmx.de wrote: One of the reasons of splitting kdelibs into separate repositories is to simplify the usage of single modules. From the perspective of a full *KDE* desktop, there is no problem in building using all of kdelibs, since each library will be used several times from several applications. I actually fail to see how splitting the libraries will make things simpler. It does make handling the repositories harder, especially for newcomers who have to learn a whole new (and unintuitive) side of git, as Kevin said. If you do not have a full *KDE* desktop (running a single KDE application on a gnome desktop or maybe the wish to use KDE technology in your Qt application), this will not be the case, and you will generate overhead. Of course the overhead can be cut down by (1) splitting kdelibs either at buildtime (by switching libraries on or off at cmake time) or (2)after building it (currently done by some distros to some extend). For KDE on Windows e.g. (1) will bring the overhead of having a complete kdelibs package for rather tiny libraries and (2) is simply forbidden by missing manpower. I actually have a patch laying around here that makes all the libraries into optional subdirectories that can be enabled and disabled at cmake time. This very nicely solves the turnaround time issue when hacking on one specific framework. Another argument against splitting is that developers will have to update multiple repositories. As mentioned by others this problem can be solved by using git submodules, or even other ways of scripting. From a packagers point of view, I doubt that the number of repositories/tarballs matters since packaging is scripted. I cannot see any advantage from keeping tierX together in one repository too because the same problems apply. I fail to see the advantage of creating a Qt-like repo hierarchy. And it adds the problem of possible dependencies between frameworks. As Frank said: I haven't seen any convincing argument yet why multiple repositories are better. +1. Cheers, Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Separating everything ?
Hi, On Feb 8, 2013, at 12:46, Sune Vuorela nos...@vuorela.dk wrote: There are several things here intermixed 1) is the release tarball layout 2) is the way the software is built 3) is the repository layout all of them is different things with different arguments for and against. So... which ones of it is it we are talking about? I am mostly arguing that to achieve 1) and 2), we do not have to have 3), a multi-repository structure. It can all be achieved by email. Mirko. -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow, FSFE Team Germany Qt Certified Specialist ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdelibs split: February Iteration reminder
Hi, I realized I am surprisingly unaware of the current ongoings. Because of that, I will reserve some time for weekend hacking (good to have an excuse anyway), and bug you guys on IRC about what needs to get done. All the best, Mirko. On Feb 6, 2012, at 19:45, Kevin Ottens wrote: Hello dear splitters[*], I'm sending this email today as you are the lucky few choosen to be in the february iteration. From the look of the relevant table, we're in a pretty good situation already for this month: http://community.kde.org/Frameworks/Epics/Splitting_kdelibs#February_Iteration Still, I'd like to make sure that everyone is aware of the goal of getting those frameworks done by the end of the month which will arrive quickly now. As I said the situation seems well engaged so far, I see only very minor issues with the february batch, but we need to make sure steady progress happens to hit the target. In case something is blocking you, or you have any questions/concerns, please let me know either by email or IRC. Indeed, if I stick to the wiki I have only a somewhat high level overview, this email is also an opportunity for you to send me back information from the trenches. :-) Happy splitting! Cheers! [*] I still need to find a catchy name for KDE Frameworks maintainers. :-) -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com -- Mirko Boehm | mi...@kde.org | KDE e.V. FSFE Fellow Qt Certified Specialist ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
