Re: Git merge workflow: reverse it?
On Wednesday, 26 August 2020 10:32:24 CEST Ingo Klöcker wrote: > Boud, please don't look with your Krita glasses on other projects. Well, this goes two ways, and when people argue for a certain workflow as the KDE workflow, then I'll have to note that that workflow only is fine for repositories that don't see much work. It is not best practice; it's make-do. It's the same with the retirement of createtarball in favor of releaseme: the releaseme workflow of creating a tarball from a branch and only then tagging is wrong for actively maintained projects. It's the same with keeping translations in svn instead of in the project repository. While we can recognize they make life simpler for people tasked making regular releases of a whole bunch of repositories that change very little, we'll also have to recognize that these policies deviate from what is seen as best practice in the rest of the world. > In my opinion, there can't be a one-size-fits-all git merge workflow/policy. Sure -- but I feel that not everyone in this thread actually realizes that -- that there are people who think that all of KDE does one thing, and that it's the best way of doing things for all the variety in KDE. My idea of a normal development and release workflow is: * An MR either for master or stable * A new MR for the other branch, or cherry-picking if simple enough * When releasing setting a tag * Which generates a tarball from the repo -- for which reason the repo should include the translations * Copying the resulting tarball from invent to files.kde.org -- preferably with a KDE generated signature so I don't have to do that myself. * Start the binary builds (although, ideally, that would also be done automatically on the setting of a tag...) -- https://www.krita.org
Re: Git merge workflow: reverse it?
On Tuesday, 25 August 2020 23:16:52 CEST Elvis Angelaccio wrote: > Now: > * Test the fix on stable > * Push to stable > * Merge stable to master > > After: > * Test the fix on master > * Push to master > * Test the fix on stable > * Cherry-pick to stable > > In the second model I need to test twice because I can't change the > stable branch without testing. > Er... You don't even test master after merging something to it? -- https://www.krita.org
Re: Git merge workflow: reverse it?
On Tuesday, 25 August 2020 23:44:02 CEST you wrote: > Or you can merge stable to master and be sure you won't forget anything. > Of course if master changed a lot you can't (easily) do that. But we > have a lot of repos that don't change very often and merging stable to > master works very well with them. ... > The problem is we don't always have a maintainer. A lot of apps are > community-maintained and if we wouldn't merge stable to master before a > new release we would reintroduce fixed bugs quite often. Basically, what you're saying is that KDE releases a lot of software that just basically never changes, and apart from some translation work is actually unmaintained. I don't think that those projects, or rather repositories, since if there's no work being done, it's hard to see that as a project, should shape policy. If a repo can get by with just merging stable to master, I don't think it's seeing meaningful development -- why should it even be released? -- https://www.krita.org
Re: Discontinuing legacy infrastructure
On dinsdag 23 juni 2020 13:38:59 CEST Ben Cooksley wrote: > On Tue, Jun 23, 2020 at 10:58 PM Boudewijn Rempt wrote: > > > > Hi, > > Hi Boud, > > > > > Did this have any consequences for kde-comm...@kde.org? I'm not getting > > commit mails except for translations at the moment. > > There has been a regression in Gitaly, the component of Gitlab that > manages Git repositories, which means the notification functionality > of our hooks is currently inoperative. > We are currently investigating potential solutions to this issue. > Okay, good luck and thanks for the update! -- https://www.krita.org
Re: Discontinuing legacy infrastructure
Hi, Did this have any consequences for kde-comm...@kde.org? I'm not getting commit mails except for translations at the moment. Boud On donderdag 11 juni 2020 11:11:48 CEST Ben Cooksley wrote: > Hi all, > > As previously announced by Sysadmin, following the Gitlab migration we > would be shutting down a number of services that were part of the old > Git infrastructure, as they were replaced with our new Gitlab based > infrastructure. > > This is a change which has now been actioned, and means the following: > > 1) git:// protocol support has now been discontinued > > Prior to the move to Gitlab, the anongit network offered access to our > repositories over both the git:// protocol as well as https://. This > has now been discontinued, and access is now provided solely via https > to ensure that connections cannot be intercepted and tampered with > > 2) CGit has been discontinued > > The CGit instance previously available at cgit.kde.org has now been > shutdown and is no longer available. All repository browsing should > now take place via Gitlab at https://invent.kde.org/ > > 3) The anongit network in general has been discontinued > > Following the migration to Gitlab, all developers as well as automated > systems began to use the master server for their traffic exclusively. > Load monitoring since then has indicated that the system is fully > capable of handling this load without the assistance of any additional > systems. > > To avoid issues that have come up in the past (with people trying to > push to anongit, or systems being out of sync) it has been decided > that the anongit service is no longer providing benefit to us and as > such it has also been discontinued. > > A legacy compatibility redirector will continue to operate under the > hostname 'anongit.kde.org' for https urls and will redirect older > style urls to their replacement Gitlab equivalents. > > If anyone has any questions on the above, please let us know. > > Thanks, > Ben Cooksley > KDE Sysadmin > -- https://www.krita.org
Re: Fixing QNetworkAccessManager use
On woensdag 19 februari 2020 14:09:06 CET Friedrich W. H. Kossebau wrote: > Am Mittwoch, 19. Februar 2020, 08:05:01 CET schrieb Ben Cooksley: > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote: > > > It would also help to know where specifically we have that problem, so we > > > can actually solve it, and so we can figure out why we failed to fix this > > > there earlier. > > > > Just bringing this up again - it seems we've not had much movement on > > this aside from the Wiki page. > > The wiki page currently still just recommends to set > "networkAccessManger->setAttribute(QNetworkRequest::FollowRedirectsAttribute, > true);" > Which confuses me a bit, because that doesn't build? [ 44%] Building CXX object libs/ui/CMakeFiles/kritaui.dir/KisNetworkAccessManager.cpp.o /home/boud/dev/krita/libs/ui/KisNetworkAccessManager.cpp: In constructor ‘KisNetworkAccessManager::KisNetworkAccessManager(QObject*)’: /home/boud/dev/krita/libs/ui/KisNetworkAccessManager.cpp:30:5: error: ‘setAttribute’ was not declared in this scope setAttribute(QNetworkRequest::NoLessSafeRedirectPolicy, true); ^~~~ /home/boud/dev/krita/libs/ui/KisNetworkAccessManager.cpp:30:5: note: suggested alternative: ‘setstate’ setAttribute(QNetworkRequest::NoLessSafeRedirectPolicy, true); ^~~~ Shouldn't it be setRedirectPolicy(QNetworkRequest::NoLessSafeRedirectPolicy); -- https://www.krita.org
Re: Blacklisting of PIM from the CI system
On dinsdag 3 december 2019 22:13:43 CET Allen Winter wrote: > On Tuesday, December 3, 2019 2:52:31 PM EST Volker Krause wrote: > > The complexity of the dependency graph is also a problem for onboarding new > > people, and with kdelibs4support gone IMHO the largest technical dept here. > > It's being worked on, albeit slowly, currently we are losing ~1 module per > > release I think. > > > Silly questions > > Why do we need 50-60 repos to build kontact? > why not 1 repo for kontact and all its stuff? (I miss kdepim) > > do Krita or any of the other large applications have so many repositories > devoted to them? Krita is just one repo. Of course, we've got our own little complications when it comes to building on binary factory , but for CI that's not relevant. > After all these years since the svn->git move I still understand why so many > repostitories for Kontact. > For frameworks it makes sense, but I don't get it for applications -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Work Branches
On woensdag 9 oktober 2019 12:32:39 CEST David Edmundson wrote: > > 2) Protect all branches, aside from a given prefix (proposed to be work/) > > Works for me. > Would protection here also cover deletion? If so we need some heads up > notice in Plasma to do a mass move of people's forks. > In krita, our convention for work branches is to use the identity name of the person working on them: rempt/T379-resource rewrite , for instance. It's proven pretty useful, but I'm not proposing we'd write a hook that scans identity to identify work branches :-) So, I'm also fine with this proposal. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Tipping the apple cart?
On dinsdag 2 juli 2019 13:07:02 CEST Ben Cooksley wrote: > I assume this means most of your new users are people who have never > worked with Github/Gitlab before in that case... I don't know; it might mean that, but I cannot be sure. I can only report the reactions from my newbies :-) > So in terms of workflow here, what you're saying is that for the > contributors Krita sees, submitting a classical patch file is what is > required to be viewed as non-painful? yes, that's what people tend to want, it seems. > (This is a critical distinction, because there has been an enormous > amount of criticism of the pain Arcanist causes) I've never been able to use arcanist myself... I just could figure out how to make it work for me. > I opened this just now on my system and it gave me no issues (using > both Google Chrome and Firefox). > > It did take a little while to open (around 20 seconds or so from the > moment I hit refresh), but that's to be expected given it is a review > spanning 509 files, with circa 14,500 additions and 7,000 removals, > comprising 382 commits so I think it's doing quite well there to load > the whole lot up and display it nicely with some syntax highlighting > even. > > The only time I managed to make it stall was when switching from > inline diff view mode to side-by-side diff view mode on that review. > Subsequent refreshes loaded fine, and remembered the preference to use > side-by-side view mode without issue. You can open reviews with > /diff?view=parallel appended to the URL to shortcut straight to the > changes view in side-by-side mode. Weirdly enough, gitlab never seems to remember the side-by-side setting for me :-( more than one assignee. > > > > Yes, and we need more than one assignee. > > Can you please explain why your workflow is not suited to using > reviewers and requires use of the assignee field? Is there a place where we can assign multiple reviewers? I haven't found one. -- https://www.krita.org signature.asc Description: This is a digitally signed message part.
Re: Tipping the apple cart?
On maandag 1 juli 2019 09:10:59 CEST Valorie Zimmerman wrote: > > This tells me that Gitlab can be worse, which is not surprising. > > And can it be better? Will some folks who have a good experience with this > on Gitlab speak up? > > This is something that all of us want and need to know. > Krita has switched from Phabricator to Gitlab a while ago, so maybe I can add our experience. It's not that great, though. Bad: * For new users who want to submit one or two patches, gitlab is way harder to use. They need much more help and handholding. * Gitlab has an exceedingly confusing UI where many options are very hard to find. The first thing I want to see when I get a MR is the diff, and that means scrolling and hunting for a very small button. * I haven't managed to make Gitlab remember to show me the diffs side-by-side, though that seems to work for others * The code review tools are crap, with every little comment being a separate thing, as Kai noted. * gitlab is slow * it's much harder to follow my gsoc students who work in a fork instead of a branch, for some reason I could only enable email notifications for one out of four students. * you cannot have more than one reviewer for a MR * using the label system for approving a MR is cumbersome Good: * sometimes, the merge button works, and then that's nice. * the on-line editor is very handy for the docs.krita.org project. * gitlab is actively maintained My takeaway: Gitlab might be maintained, and phabricator not, but when it comes to making life easier for newcomers, it's not working (1). We can live with it, but it isn't a huge improvement. When it comes to email, phabricator worked better for me, but yes, sometimes I got too much mail. Now I don't get enough. Right now, my biggest email problem is bugs.kde.org, but that's because we get too many bug reports. -- https://www.krita.org (1) Which reminds me -- we ought to have a discussion on whether matrix actually achieved its goals of making life easier for newcomers. signature.asc Description: This is a digitally signed message part.
Re: EBN Still Needed?
Speaking for myself, I think I stopped looking at EBN years ago when it broke down; I had not known it had been revived. On dinsdag 26 maart 2019 21:15:31 CET Allen Winter wrote: > I was notified today that the Krazy runs on the EBN have been stuck (due to a > stale lockfile) > for over 3 months. Is this an indication that nobody looks at the EBN > reports any longer? > > I still maintain Krazy and am happy to make modifications, but I don't see > the point > unless someone actually reads and acts on the reports. > > Note that clazy does replace Krazy on most everything (C++) so it could > very well be that people are relying on Clazy instead of Krazy. > > This is not about the API dox generation side of things, which of course we > keep. > > But has the EBN code and documentation checking service out lived its > usefulness? > Shut it down? -- https://www.valdyas.org | https://www.krita.org
Re: Python bindings using cppyy (was: An update on Python bindings)
On Sat, 4 Nov 2017, Chris Burel wrote: > I think this is a remarkably short sighted statement. It assumes that people > that would use these bindings have no existing Python codebase at all, and > can afford to start a brand new project. The reality is much different. > > Let's take a specific example. I have 6 years experience writing Python for > the visual effects industry. We have a 10 year old Python 2 codebase. We also > use an application from Autodesk called Maya. It has been a Qt 4 application > with Python 2 embedded since 2012. In 2016 they jumped to qt 5 and pyside2. > Now Autodesk knows that companies have built large codebase around their > product that requires Python 2. What would've happened if pyside2 did not > support Python 2.7? They'd be stuck either forcing all their customers to > move to Python 3 and risk people not wanting the new version of the software, > or they'd be prevented from moving to Qt 5. > You will have to switch to Python 3 by 2019, since that's what the VFX Reference Platform says. If you haven't started on the migration yet, you're very late. And the VFX Refernece Platform is basically Autodesk telling the rest of the industry what to use, including their weird patchset for Qt... > So no, Python 2 is not dead. Not by a long shot. For VFX, it will be dead in 2019. See http://www.vfxplatform.com/ -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Application usage statistics and targeted user surveys
On Sun, 23 Apr 2017, Boudewijn Rempt wrote: > Did I just miss it -- or didn't you tell us where we can find the library? > Curiously enough, there's a gsoc proposal this year for krita that has > pretty much this as its goal... Nevermind... Found it. My eyes were scanning for a full url :-) -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Application usage statistics and targeted user surveys
Did I just miss it -- or didn't you tell us where we can find the library? Curiously enough, there's a gsoc proposal this year for krita that has pretty much this as its goal... On Sun, 23 Apr 2017, Volker Krause wrote: > Hi, > > we have talked about the above topics a couple of times in the past, from > what > I remember usually agreeing it would be nice to have some more statistical > information about our users, so we know what our applications are used for, > and to measure impact of changes. Similarly, it would be nice to be able to > actually ask our users questions without statistical bias by using > out-of-band > channels like blogs or social media. This can be obviously addressed by > adding > this into application code, but that raises some valid privacy concerns. > > Wanting this for GammaRay I attempted to implement a generic framework for > this, with the goal to make this fully transparent, and give the user full > control over what data is shared, and how often they want to participate in > surveys, ie. make this solid enough on the privacy side that even I would > enable it myself. You'll find the code in Git (kde:kuserfeedback). > > Feature-wise it so far contains: > - a set of built-in data sources (app version, Qt version, platform, > application usage time, screen setup, etc) that applications can choose to > enable > - generic data sources for tracking the time ratio a Q_PROPERTY has a > specific > value, allowing to track e.g. which application view is used how much > - the ability to add custom/application-specific data sources > - reference widgets for customizing what data you want to share, and showing > exactly what that means, in human readable translated text and if you insists > also all the way down to the raw JSON sent to the server. > - survey targeting using simple C++/JS-like expressions that can access all > the data sources (ie. you can target e.g. only users with high DPI multi- > screen setups) > - configurable encouragement of users to contribute (ie. after X starts > and/or > Y hours of usage, repeated after Z months, suggest the user to participate if > they aren't already doing so). > - a management and analytic tool that allows you to manage products and > survey > campaigns, and view recorded data using configurable aggregations > - the entire thing works without unique user ids. Fingerprinting can still be > an issue on too small user sets and/or when using too much detail in the data. > - by default all of this is opt-in of course, although technically the API > doesn't prevent applications to change this > - it can deal with multiple products, each product can have different data > sources and survey campaigns > > Technically, this consists of the following parts: > - a library that goes into the target application, backward compatible all > the > way to Qt4.8/MSVC2010 (needed for my GammaRay use-case), depending only on > QtGui > - a library with the reference widgets, also with extended backward > compatibility > - the server, written in PHP5 and supporting sqlite/mysql/postgresql. Not the > most fun technology, but that stuff is available almost anywhere, and easy to > deploy and maintain > - the management tool, recent Qt5/recent C++, using QtCharts for the data > analysis > - a command line tool for data import/export, useful for eg. automated backups > > All of this is LGPLv2+ licensed. > > Feedback obviously very welcome, in particular around privacy concerns, or > reasons that would make you enable/disable such a feature. > > Regards, > Volker > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: karchive and QSaveFile
On Sat, 1 Apr 2017, Sune Vuorela wrote:
> On 2017-03-28, Boudewijn Rempt <b...@valdyas.org> wrote:
> > I'm now wondering whether to hack QSaveFile's close to just not
> > abort, or add inherits("QSaveFile") checks all over KArchive --
> > or whether there's a third, better option that I've missed...
>
> Without having put too much thought into it, add an "Don't close the
> device underlying device" boolean option to the relevant KArchive
> classes?
Logically, if I were to design the api from scratch, passing an io device
should mean "this is mine, keep your mittens off, don't close it", but that
would break so much existing code...
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
karchive and QSaveFile
I'm trying to make Krita use QSaveFile instead of the home-grown
mess of temporary files that get copied over the original file
after saving succeeded. The problem is that Krita, like Calligra,
uses KArchive. And KArchive, even when a KZip is created with
an existing QIODevice, decides on its own to call close(), which
is not allowed with QSaveFile.
I've tried to set KZip's io device to 0 just before closing the
kzip, but that means the zip file doesn't get written correctly.
I'm now wondering whether to hack QSaveFile's close to just not
abort, or add inherits("QSaveFile") checks all over KArchive --
or whether there's a third, better option that I've missed...
--
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
File overwrite warning missing?
Hi, Users with the latest plasma/frameworks who build Krita themselves are reporting that the file dialog no longer warns about overwriting existing files: https://bugs.kde.org/show_bug.cgi?id=360666 I'm not sure what's going on here, the warning correctly appears with the GTK file dialog, the Qt file dialog, the Windows file dialog and the OSX file dialog. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: A new attempt on PyKDE5 binding generation
On Sat, 26 Mar 2016, Shaheed Haque wrote: Hi all, I've given up on trying to get the twine2 PyKDE bindings generator working [1] because not only is the code there broken, but it seems a Sysiphusian task to maintain a C++ parser. Instead, a few evenings with clang 3.9 have yielded what I hope is the basis of a way forward: about 800 lines of Python code [2] which can already create 684 .sip files [3]. Oh, that's exciting! Would that tool also work to generate sip files for, say, krita, for krita's python scripting plugin? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Qt5 version of qimageblitz
On Wed, 9 Mar 2016, Albert Astals Cid wrote: I guess for that we need to decide if it should be a framework first or not. Isn't kolourpaint the only user of qimageblitz at the moment? Krita used to use it, years and years ago, but that's no longer the case. If Kolourpaint is the only user, I'd actually suggest just taking the code into kolourpaint and dropping the library entirely. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On Thu, 10 Dec 2015, Boudhayan Gupta wrote: On 10 December 2015 at 12:04, Boudewijn Rempt <b...@valdyas.org> wrote: I'm right now using msvc 2015 myself -- which gives other problems with other dependencies. Microsoft now has clang (running on the Microsoft Code Generator as well as LLVM) - maybe we could look into using that on Windows? It's supposed to be an (optional, IIRC) part of VS2015 and will be continually supported and updated. So if we can kick out cl.exe support, that's one less compiler frontend to support. Note that clang with Microsoft CodeGen is theoretically pretty much the same as cl.exe (in both cases the AST is converted to machine code by MSCG only), except that with clang we get superior parser and C++11/14 and C90 support. Well, it's more like "building boost with msvc 2015 doesn't add the compiler version number to the dll names, which means that the cmake code that looks for boost fails to find the dll's, even though they are there, because the name pattern cmake is hard-coded for fails, so you need to manually rename the dll's" or "msvc 2015 still insists on really small stacks, so g'mic's stack based recursive parser, which needs 8mb of stack minimum, runs out of stack". It's all those effing little things that add up and make building an application with a few dozen dependencies a herculean task. And every dependency seems to have _something_. In the Qt4 days, Qt didn't want to link to zlib.lib, it needed libzlib.lib, for instance. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Luca Beltrame wrote: Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. Given you've said this multiple times, Yes, and I'll go on saying it until I feel people are listening... Which I feel hasn't happened yet. with my packager hat on I'll just mention this: just don't make it harder *for us* to work just because you're targeting another platform. There are two sides, of course: if making it easier for a distribution to package KDE software makes it harder for an application to be packaged for another distribution, where do we go? What's most important? Just adding a dependency because all linux distributions have it so it's no sweat can cause huge problems. You may not care for Linux distros, but there are people who *do*. I care about Linux, I care for Linux distributions and I've always done. I hate having to work on OSX (especially OSX) or Windows, but I don't have a choice here. And if the KDE frameworks are supposed to be cross-platform, development needs to reflect that, and anything that's making life easy for a distribution should be weighed and considered and maybe rejected if it's making life harder for users of the KDE frameworks on other platforms. The alternative is doing what Gnome did: declare the KDE Frameworks Linux-only. That would be a clear, honest step to take, and I wouldn't actually oppose it. But it would put an end to the story that KDE Frameworks are just additions to Qt that everyone can use. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Why is C90 enforced in KDE?
On Mon, 7 Dec 2015, Kevin Kofler wrote: +1, of course we should not. Generated files have no business being in a source control or in source tarballs. "BuildRequires: flex" is one line in a distro specfile. Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: KF5-QT5 branchgroup - jobs that need developeer attention
On Wed, 15 Apr 2015, Scarlett Clark wrote: calligra - All - compile fail. One way to make it build would be to remove the Vc dependency. We've still not figured out a way to make Vc's handling of INCLUDE_DIRECTORIES work with the new kf5 way of creating include directories -- see my mail to kde-core-devel. Boud
Getting the real include directories for frameworks?
I've got a problem porting calligra to kf5 that I don't know how to solve.
We use a 3rd party library called Vc, which does vectorization for us. It
takes a certain object file and builds it for different processor
architecturres. In order to do that, it generates a new gcc line for every
architecture, using the value of INCLUDE_DIRECTORIES, like this:
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
With kf5, the value of ${Kf5_INCLUDES} is set to
$TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES
And that means, of course, that the final build command looks like:
cd /home/boud/kde/build/calligra/libs/pigment /usr/bin/c++ -std=c++0x
-fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
-Wformat-security -Wno-long-long -Wpointer-arith -Wundef
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wabi
-fabi-version=0 -ffp-contract=fast -mtune=core-avx-i -fPIC
-I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
-I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtWidgets;/usr/include/qt5/;/usr/include/qt5/QtGui;/usr/include/qt5/;/usr/include/qt5/QtCore;/usr/lib64/qt5//mkspecs/linux-g++;/usr/include/qt5/;/usr/include/qt5/QtDBus;/usr/include/qt5/;/usr/include/qt5/QtPrintSupport;/usr/include/KF5/KCoreAddons;/usr/include/KF5;/usr/include/KF5/KCrash;/usr/include/KF5;/usr/include/KF5/KWidgetsAddons;/usr/include/KF5;/usr/include/KF5/KConfigCore;/usr/include/KF5;/usr/include/KF5/KConfigWidgets;/usr/include/KF5;/usr/include/KF5/KCodecs;/usr/include/KF5;/usr/include/KF5/KConfigGui;/usr/include/KF5;/usr/include/qt5/;/usr/include/qt5/QtXml;/usr/include/KF5/KAuth;/usr/include/KF5;/usr/include/KF5/KIOCore;/usr/include/KF5;/usr/include/KF5/KService;/usr/include/KF5;/usr/include/KF5/KIOFileWidgets;/usr/include/KF5;/usr/include/KF5/KIOWidgets;/usr/include/KF5;/usr/include/KF5/KJobWidgets;/usr/include/KF5;/usr/include/qt5/;/usr
/include/qt5/QtNetwork;/usr/include/KF5/KCompletion;/usr/include/KF5;/usr/include/KF5/KBookmarks;/usr/include/KF5;/usr/include/KF5/KItemViews;/usr/include/KF5;/usr/include/KF5/KXmlGui;/usr/include/KF5;/usr/include/KF5/Solid;/usr/include/KF5;/usr/include/KF5/KI18n;/usr/include/KF5;/usr/include/KF5/KNotifications;/usr/include/KF5;/usr/include/KF5/KIconThemes;/usr/include/KF5;/usr/include/KF5/KWindowSystem;/usr/include;/usr/include;/usr/include/KF5;/usr/include/KF5;/usr/include/KF5/KGuiAddons;/usr/include/KF5;/usr/include/KF5/KUnitConversion;/usr/include/KF5;/usr/include/KF5/KTextWidgets;/usr/include/KF5;/usr/include/KF5/SonnetUi;/usr/include/KF5;/usr/include/KF5/KParts;/usr/include/KF5
-I/usr/include/qt5 -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5
-I/usr/include/qt5/QtGui -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++ -I/usr/include/qt5
-I/usr/include/qt5/QtXml -I/usr/include/qt5/QtCore
-I/usr/lib64/qt5/mkspecs/linux-g++
-I/home/boud/kde/src/calligra/libs/koplugin
-I/home/boud/kde/src/calligra/libs/version
-I/home/boud/kde/build/calligra/libs/version
-I/home/boud/kde/src/calligra/libs/pigment
-I/home/boud/kde/src/calligra/libs/pigment/compositeops
-I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
-I/usr/include -I/usr/include/OpenEXR -I/usr/local/include -mavx
-DVC_IMPL=AVX -c -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
/home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
And that doesn't work:
/home/boud/kde/src/calligra/libs/pigment/pigment_export.h:24:23: fatal
error: kdemacros.h: No such file or directory
#include kdemacros.h
^
compilation terminated.
I guess that the line
-I/usr/include/KF5/KDELibs4Support;/usr/include/KF5/KDELibs4Support/KDE;/...
Must somehow bew broken up into proper -I/usr/include/KF5/KDELibs4Support
-I/usr/include/KF5/KDELibs4Support/KDE -- the question is, how do I do
that? How do I expand this list, parse it and add the contents of this
string to include_directories?
Boudewijn
Re: Getting the real include directories for frameworks?
On Fri, 3 Apr 2015, Boudewijn Rempt wrote:
On Fri, 3 Apr 2015, Alexander Richardson wrote:
2015-04-03 10:08 GMT+02:00 Boudewijn Rempt b...@valdyas.org:
I've got a problem porting calligra to kf5 that I don't know how to solve.
We use a 3rd party library called Vc, which does vectorization for us. It
takes a certain object file and builds it for different processor
architecturres. In order to do that, it generates a new gcc line for every
architecture, using the value of INCLUDE_DIRECTORIES, like this:
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
I haven't tested this, but according to the CMake documentation
(http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html)
this strange construction will probably work:
list(APPEND _flags $$BOOL:${_i}:-I$JOIN:${_i}, -I)
I'll give that a try -- since Vc is a 3rd party library I'll have to do
that in our own code, of course.
Weird, I must be doing something wrong because even if I use that in the
vc macro (which I shouldn't of course), it doesn't seem to make any
difference. And even after reading the documentation page, I'm completely
unsure about _why_ we'd need such expressions here.
Boudewijn
Re: Getting the real include directories for frameworks?
On Fri, 3 Apr 2015, Alexander Richardson wrote:
2015-04-03 10:08 GMT+02:00 Boudewijn Rempt b...@valdyas.org:
I've got a problem porting calligra to kf5 that I don't know how to solve.
We use a 3rd party library called Vc, which does vectorization for us. It
takes a certain object file and builds it for different processor
architecturres. In order to do that, it generates a new gcc line for every
architecture, using the value of INCLUDE_DIRECTORIES, like this:
get_directory_property(_inc INCLUDE_DIRECTORIES)
foreach(_i ${_inc})
list(APPEND _flags -I${_i})
endforeach()
I haven't tested this, but according to the CMake documentation
(http://www.cmake.org/cmake/help/v3.2/manual/cmake-generator-expressions.7.html)
this strange construction will probably work:
list(APPEND _flags $$BOOL:${_i}:-I$JOIN:${_i}, -I)
I'll give that a try -- since Vc is a 3rd party library I'll have to do
that in our own code, of course.
Boudewijn
Re: Review Request 122922: Remove two asserts from kzip.cpp
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122922/ --- (Updated March 13, 2015, 8:34 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Bugs: 343214 http://bugs.kde.org/show_bug.cgi?id=343214 Repository: kdelibs Description --- These asserts should never hit, return false is much safer. I'll submit the same patch for karchive. Diffs - kdecore/io/kzip.cpp 26ee9a7 Diff: https://git.reviewboard.kde.org/r/122922/diff/ Testing --- Tested with Krita in circumstances descibed in the bug. Thanks, Boudewijn Rempt
Review Request 122922: Remove two asserts from kzip.cpp
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122922/ --- Review request for kdelibs. Bugs: 343214 http://bugs.kde.org/show_bug.cgi?id=343214 Repository: kdelibs Description --- These asserts should never hit, return false is much safer. I'll submit the same patch for karchive. Diffs - kdecore/io/kzip.cpp 26ee9a7 Diff: https://git.reviewboard.kde.org/r/122922/diff/ Testing --- Tested with Krita in circumstances descibed in the bug. Thanks, Boudewijn Rempt
Re: Another proposal for modernization of our infrastructure
On Mon, 2 Feb 2015, Milian Wolff wrote: Sigh, I find it highly sad to read this over and over again. Well, this whole discussion makes me extremely sad. What people have to learn is that _arguments_ only go so far. People can feel they're double-plus extra-super right, and still at one point they have to accept that they're not going to change the other people's point of view. So, here is my point of view, put very simply: * replacing reviewboard with gerrit will mean fewer contributors to many of the projects KDE hosts. * following from that, projects that want to stay alive and relevant will move away from the kde infrastructure. * which makes gerrit a Bad Thing. This is what I am sure _will_ happen, no matter how much anyone argues that gerrit is cool, can be cool, will be cool, won't be as uncool as it's for Qt, how lovely gerrit's git integration is, how nice it is to train people to contribute to Qt, that nobody has tested phabricator yet and so on ad infinitum. I've read it all, and I'm not convinced. There are people who like gerrit and would love to use it. I accept that. But there is not going to be a broadly supported consensus that gerrit is cool and should be used by KDE in the development workflow. There is not going to be a consensus that gerrit should replace reviewboard, sorry, no matter over how many mails the same arguments get rehashed. That's something people who like gerrit have to accept. Now, phabricator might be just as crappy, though if Blender uses it... (But that's the same argument as Qt uses it is for gerrit and just as invalid), but let's first _test_ it, as Ben proposed. Boudewijn
Re: Another proposal for modernization of our infrastructure
On Sat, 31 Jan 2015, Christoph Feck wrote: On Saturday 31 January 2015 20:07:42 Eike Hein wrote: [...] Qt is using gerrit and we intend to remain a major stakeholde in Qt development, which means a sizable number of KDE developers need to be familiar with gerrit anyway [...] Excuse me, but if KDE developers will have to follow equivalent steps as described at http://qt-project.org/wiki/Setting-up-Gerrit to contribute, then I predict another big loss of developers. Christoph Feck (kdepepo) Maybe quite a few KDE developers would want to contribute to Qt, and maybe Qt would like more contributors, but KDE is so much bigger -- I'd like to see some numbers, but I seriously doubt that the majority of KDE developers are potential Qt developers. Even if we have to work around Qt bugs quite often. In any case, if Qt wants more contributors out of the KDE developer pool, they'd better ease up their submission process and drop using gerrit. I know that I, and I've been a KDE developer for over a decade, won't do anything for Qt in my spare time as long as they have this gerrit-based workflow. If people are paying me for it, well, that's different, but no way am I going to submit to that process for fun and for for free. In short, Qt uses gerrit is a bogus argument in favor of gerrit. And I am pretty sure that if gerrit becomes a requirement for working on KDE projects, KDE will not just lose a lot of developers, it will lose a lot of projects. Boudewijn
Re: Feature matrix for future infrastructure
On Thu, 22 Jan 2015, Milian Wolff wrote: Hey all, I started this page just now: https://community.kde.org/Sysadmin/FutureInfrastructure It's pretty limited, so far. I hope everyone could help out and extend it and fill it with the information and verify that each contestant is displayed in a fair light. Please add links, comments etc. pp. wherever possible. Hm... That matrix needs a heck of a lot of work before it's worth spending time on. It perpetuates the illusion that phabricator and gerrit are equivalents, which isn't true. Gerrit is just a kind of reviewboard with a git integration, phabricator is a whole integrated development platform. And, apart from detail-by-detail comparisons, gerrit would be an exceedingly bad choice for a community like KDE, with its enormous diversity of skill levels. Gerrit is uninviting and complicated. There is no way an artist who has a nice patch for Krita is ever going to be able to inducted into becoming a Krita developer if they have to follow instructions like this: https://techbase.kde.org/Development/Gerrit Even reviewboard works better for that. Honestly, this discussion is misguided. I'm sure there are people who like gerrit as a tool, probably influenced by the fact that gerrit is used by the Qt project, and we have a history of doing what the Qt project does. But gerrit is not the answer to the question what should our future infrastructure be, because it's only a replacement for reviewboard. Boudewijn
Re: Feature matrix for future infrastructure
Hm... That matrix needs a heck of a lot of work before it's worth its while. It basically perpetuates the illusion that phabricator and gerrit are the same thing, which isn't correct. Gerrit is basically a reviewboard with a git integration, phabricator is a whole integrated development platform. And, apart from detail-by-detail comparisons, gerrit would be an exceedingly bad choice for a community like KDE, with its enormous diversity of skill levels. Gerrit is uninviting and complicated. There is no way an artist who has a nice patch for Krita is ever going to be able to inducted into becoming a Krita developer if they have to follow instructions like this: https://techbase.kde.org/Development/Gerrit Honestly, this discussion is really misguided. I'm sure there are people who like gerrit as a tool, probably influenced by the fact that gerrit is used by the Qt project, and we have a history of doing what the Qt project does. But it's not the answer to the question what should our future infrastructure be, because it's only a replacement for reviewboard. (And reviewboard, at least, can be explained to newcomers, gerrit can't). On Thu, 22 Jan 2015, Milian Wolff wrote: Hey all, I started this page just now: https://community.kde.org/Sysadmin/FutureInfrastructure It's pretty limited, so far. I hope everyone could help out and extend it and fill it with the information and verify that each contestant is displayed in a fair light. Please add links, comments etc. pp. wherever possible. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: Sysadmin report on the modernization of our infrastructure
Hi, I am all for the proposal -- though I would like to use Phabricator for issue tracking as well, actually. I would also like to propose Calligra/Krita as one of the test projects. On Wednesday 21 January 2015 Jan 17:12:07 Ben Cooksley wrote: Hi all, As promised in the earlier thread, i'd like to present the sysadmin report on the state of the infrastructure surrounding our code. It contains a detailed summary of what is broken with our existing systems, why change is necessary and an evaluation of the options we considered. We have also made a proposal based on our evaluations and the wishlist of functionality drawn up the community. Please find it attached - and let us know what you think. Feedback is welcome. Cheers, Ben Cooksley KDE Sysadmin -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org
Re: Changes to our Git infrastructure
On Tue, 6 Jan 2015, Jan Kundrát wrote: On Monday, 5 January 2015 22:22:19 CEST, Boudewijn Rempt wrote: Usually, half-way through they ask me, why doesn't KDE use github I do not understand how stuff would change if we used GitHub, though. I'm just relaying what usually happens when I get a newcomer in #krita. I would encourage you to read https://techbase.kde.org/Development/Gerrit#Getting_Started . Do you think that the workflow proposed there is reasonably beginner-friendly? Well, I find the page not very penetrable, to the point that I don't get the proposed workflow, but that might just be me, or the prose, which certainly needs editing. But I'm the wrong person to ask in any case. What you should do is hang out on #kde-devel and the next time someone comes on the channel who says, Hello! I'm new here. I want to develop on KDE. What do I need to do?, grab him and ask them to go through this process, and make notes whenever they get confused. Boudewijn
Re: Changes to our Git infrastructure
On Tue, 6 Jan 2015, Thiago Macieira wrote: Unfortunately, as long as the tool permits line-by-line commenting, you're going to get nitpicking. My experience is that people are linear and will start reading the patch, calling out what they see when they see it. They should instead look at the big picture first and that isn't easy. See http://sarah.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/ Lovely article. I know some people would object that the awful indentation makes the patch impossible to read, but apart from that specious argument, it's great advice. I wonder if we can tweak a tool to only allow line-by-line comments after two high-level reviews have been written... Boudewijn
Re: Changes to our Git infrastructure
Well, this getting to a pretty useless discussion. You set out to prove that you find it all very simple, and I am sure you find it simple. You don't have to rebut everything I say point by point to prove whatever you think you are proving because the point is this: you find it simple, others don't. What you have to do is accept is this: others don't. The rest of the world is fine with accepting that you think it's simple, that's not the point of the discussion. So, yes, you cannot write a git-for-dummies manual, for that we need a genius like David Revoy. Just get this: you hope everyone has met a DVCS. I regularly meet people for whom git is a magic way of getting new features, and who have _no_ idea at all about what version control is, or what source code is. And many of them turn out to be awesome contributors, and some even, after a year or two, help with git bisecting a particular bug. So all I want to make sure here is that participation in KDE is as accessible as possible to the great majority of the world that doesn't want to play the 'serious software engineer', qt-project.org-style. That is why I've given the link to what non-engineers active in #krita think about KDE's infrastructure, and that's why I've tried to show you how intimidating something you find very simple actually is, how many steps that you know are optional, or necessary, you actually forgot to mention in your little list. On Mon, 5 Jan 2015, Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure: On Mon, 5 Jan 2015, Albert Astals Cid wrote: I think this is due to the fact that it's quite simple git clone kde:repo This requires: * setting up gitconfig with the kde: alias. That requires finding the right info on techbase, as well as the awareness that techbase exists. You can always just use the full url. * figuring out the reponame for a particular project (and that isn't as easy as just downloading the entire trunk of kde's svn repo -- even if I never did that myself) Sure, if you don't know the repo name you're out of luck, not that downloading the whole trunk would help you much more (you can still grep but it may take ages) do coding git commit * using the commit template You don't really need a commit template (though it's nice if you use it) * with the relevant keywords You don't really need to use the keywrods (though it's nice if you use it) * having a grasp of what a git commit is, especially that a commit isn't visbile to anyone else Any modern (i.e. DVCS) has that concept, sure it's complicated for cvs/svn people, i'd like to think most of us has worked with a DVCS at the moment. git push But not before you have * realized that you need to push, i.e. what local and remote is Same as above, it's DCVS. * figured out what branches are for, and how different projects handle those Right, that's hardly documentable though (and will get old soon most probably) * got your kde indenity Every system needs it's own identity system, we use ours. * posted it on the right reviewboard Reviewboard is not mandatory (though it's nice) * to the right reviewers Yes, you either have to pick the reviewers or let a robot do your job. That said, i'm not saying contributing is easy, i'm just saying the pure git part is not that hard, it's all the project overhead (branches, review, account, etc) that really makes it harder (in my opinion). Cheers, Albert
Re: Changes to our Git infrastructure
I'm just trying to make clear that reviewboard is a crappy tool inciting people to write crappy reviews that drive people away. Apart from any other nonsense about cultural differences (the standard cop-out from Dutchmen and Germans -- I ain't rude, I'm just honest, it's cultural!), I think that people should read Ian's mail, with attention: Speaking for myself, I find this a huge turnoff in the KDE world and am now planning to retire from KDE as soon as I can. But then I am 76 and git is my 10th source-code control system since 1965-66, so I have little interest in mastering it. I have also found ReviewBoard utterly counter-productive this year, either because one writes an entry and nobody reviews it, or nobody understands it, or because one gets nitpicked about syntax and white space when one is really looking for helpful advice about how better to solve the problem at hand. I think I must have lost a month or two on ReviewBoard during the year, with very little helpful advice gained. I consider nitpick reviews harmful. If you have nothing better to do than nitpick, don't, and reviewboard is a tool which encourages you to do. On Mon, 5 Jan 2015, Thomas Lübking wrote: On Montag, 5. Januar 2015 22:58:43 CEST, Boudewijn Rempt wrote: For me, personally, RB's mails are even worse. Ok, but that's pretty much OT, isn't? (Same problem with this thread, or rather mailing list. Why the heck do I need to get two copies of every reply to a mail of mine... One is _enough_. And yes, I know about the whole reply-to-mangling-is-dangerous lunacy.) You get them, because you send them. kcd is cc'd by your mails what will in the end make mail clients reply to all rather than just to the mailing list. Reviewboard isn't limited to kde-core-devel. It's not only not limited, it's not even bound to kcd. The receivers depend on the groups you attach to the RR. And it doesn't answer my main complaint: reviewboard, by its design, is made to whine about whitespace, extra white at the end of lines and other one-line complaints. a) breaking coding style is bad style anyway. Get a better editor, don't introduce tabs and trailing spaces and weird indention etc. and there'll be no complains. b) You missed my argument. MANY ppl. can give you an abstract review (whitespace, hot loop, performs crap, this may crash) but only VERY FEW ppl. can make a feature comment. If none of the latter ever shows up because the component has vacant maintainance, you might oc. feel that ppl. only nitpick, but the alternative is that your patch remains entirely uncommented and if you at some point just push it, you'd introduce unnecessary style breaks and bad code on top of that. It gives the reviewer a happy feeling of a job well-done That's nonsense. It ideally maintains general code quality by many eyes. If you are in charge of a component and have fundamental comments, you certainly won't restrict yourself to comment the patch on an abstract level. and the submitter a cold shower. Eye of the beholder? It's a tasklist. Nothing more, nothing less. If that scares you, you probably would not want to hear fundamental concerns at all. There might be a cultural gap between rather polite (lying) and rather direct (offending) societies, but that won't be fixed by any communcation tool in the near future. Cheers, Thomas
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Aaron J. Seigo wrote: On Monday, January 5, 2015 22.26:24 Boudewijn Rempt wrote: In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. That is a development culture issue than no tool can fix. Not fix, but a tool can encourage one way or another. Reviewboard is great for discussing changes in the hands of people who value that sort of interaction. It also can be used to deliver only nitpicking in a non- constructive manner. The difference in experience comes down to the what the people using it value. Where reviewboard is not good enough is in making it easy to quickly try the patch (bi-directional scm integration) ... but the commenting and discussion features are pretty much as good as it gets. -- Aaron J. Seigo
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Jeff Mitchell wrote: I do disagree about needing a KDE identity to submit things like bug reports; it is not useful to be unable to follow-up with someone, and if they don't have an email address they're much less likely to remember to check back. Not to mention link spam and all sorts of other nastiness. Possibly allowing non-Identity account providers for non-developers is a good middle ground (Google, Twitter, Facebook, GitHub). Yes, that should be totally fine. The intersection of people who don't want a kde identity (or find it too much bother) and those people who feel g, t, f, gh are too invasive is really small, and, honestly, likely too individual to be helpful. Boudewijn
Re: Changes to our Git infrastructure
On Mon, 5 Jan 2015, Albert Astals Cid wrote: I think this is due to the fact that it's quite simple git clone kde:repo This requires: * setting up gitconfig with the kde: alias. That requires finding the right info on techbase, as well as the awareness that techbase exists. * figuring out the reponame for a particular project (and that isn't as easy as just downloading the entire trunk of kde's svn repo -- even if I never did that myself) do coding git commit * using the commit template * with the relevant keywords * having a grasp of what a git commit is, especially that a commit isn't visbile to anyone else git push But not before you have * realized that you need to push, i.e. what local and remote is * figured out what branches are for, and how different projects handle those * got your kde indenity * posted it on the right reviewboard * to the right reviewers Of course it's doable, but even with cats just getting source and building it poses hurdles that need articles like http://www.davidrevoy.com/article193/building-krita-on-linux-for-cats to help people jump them. I am a very fortunate and happy person: there is hardly a week when I don't have to guide someone through the process. Usually, half-way through they ask me, why doesn't KDE use github (or, less often) phabricator. Then I point them at the manifesto, and we usually spend another half hour discussing that -- most often with good results! Our story about not using github is not hard, but our contribution process often is. Obviously i think it is simple but you think it's not, i can't write a guide for dummies because i think it's simple and you can't write it because you don't know how to write it, it'd need to people to collaborate on it. If you can write somewhere your questions I'm sure we can find people to write the answers :) Cheers, Albert Having said that, the mail flood I get from Qt gerrit also isn't fun. After every comment a new review is requested... I don't have that time. Having a system where every repository (project) automatically has its own wiki and bug tracker is something I would really like to have. I think this is especially useful with the frameworks effort. I'd really like to see a homepage for each of the frameworks, and such a wiki page would be a natural place to put it. Alex
Re: Changes to our Git infrastructure
Well, _obviously_ reviewboard supports raising issues and adding comments , but neither facilitates actual conversation, i.e. discussion on what's up with a particular patch at a deeper level. In short, what I meant is that as a tool to dicuss code changes, Reviewboard is a poor thing. It facilitates nit-picking, which is off-putting and useless, but at least gives the reviewer the feeling he's done his job, while it fails at making it easy to discuss the why, wherefore and how of a particular change. On Mon, 5 Jan 2015, Albert Astals Cid wrote: El Dilluns, 5 de gener de 2015, a les 18:40:54, Boudewijn Rempt va escriure: I do agree, btw, with Ian, that the current reviewboard workflow is badly broken and can be very discouraging. It doesn't support conversation What do you mean it doesn't support conversation? Cheers, Albert
Re: Changes to our Git infrastructure
On Sun, 4 Jan 2015, Thomas Friedrichsmeier wrote: True, but don't forget about the other side of the story: - potential contributors will have to learn more stuff, before they can even _start_ contributing, which may be a real turn-off in some cases. Your project's situation may be very different from mine. Personally, I'm much more worried about keeping the entry barrier as low as possible, than about reducing the amount of effort that I have to put into supporting and educating contributors. Getting first-timers and non-coders to even create a patch and post it to a bug is often already a challenge. But I managed to make someone do a proper and succesful git bisect! Anyway, and coincidentally, Here's something artists and other interested people wrote up for Krita, some time ago: https://notes.kde.org/p/YWlSAP98tl (Needs a KDE identity to access...) Boudewijn
Re: Changes to our Git infrastructure
Just to make sure -- I didn't write any of this, this is stuff that committed users of Krita were coming up with some time ago when the question arose of why is krita not on github (which got answered satisfactorily, but then sequed in what people are missing). On Sun, 4 Jan 2015, Boudewijn Rempt wrote: On Sun, 4 Jan 2015, Thomas Friedrichsmeier wrote: True, but don't forget about the other side of the story: - potential contributors will have to learn more stuff, before they can even _start_ contributing, which may be a real turn-off in some cases. Your project's situation may be very different from mine. Personally, I'm much more worried about keeping the entry barrier as low as possible, than about reducing the amount of effort that I have to put into supporting and educating contributors. Getting first-timers and non-coders to even create a patch and post it to a bug is often already a challenge. But I managed to make someone do a proper and succesful git bisect! Anyway, and coincidentally, Here's something artists and other interested people wrote up for Krita, some time ago: https://notes.kde.org/p/YWlSAP98tl (Needs a KDE identity to access...) Boudewijn
Re: Changes to branch management
On Wed, 24 Dec 2014, Ben Cooksley wrote: Hi all, As the other thread has gotten a bit congested with various threads, I thought I would split up the topics to make things a bit easier to manage. The first seems the least contentious: allowing all developers to delete branches on our mainline repositories, except for certain protected branches (like master and KDE/* for instance). Any suggestions or variations on this? Note: the protected branches really do need to be universal across all repositories to be effective - otherwise the effort required to add the protection will introduce an extremely high maintenance burden. Would it be possible to add the Calligra/* release branches to that list, or should we better rename them toe KDE/*? I'll also add that there is never a risk of work being lost courtesy of the backup refs. The hooks automatically create these refs (including the unix time of the event) whenever a destructive event is made to a ref. The hooks will also explicitly prohibit any attempt to alter the backup refs - they're read only and untouchable. These can be manually fetched using git fetch if necessary to restore a branch which is mistakenly deleted. That's reassuring :-) Boud
Re: [Kde-pim] Problems with infrastructure
On Mon, 15 Dec 2014, Luca Beltrame wrote: In data sabato 13 dicembre 2014 08:21:15, hai scritto: We had three ones on plate: - Phabricator http://phabricator.org/ https://github.com/phacility/phabricator I think I've taken a look at that, but it was way too complex than what I could handle: I have no idea if it fits KDE's needs. Just as a datapoint: phabricator is what blender is using now: http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator Boud
Re: Scripting/Extensions BoF at Akademy?
On Sat, 9 Aug 2014, Kevin Krammer wrote: Greetings all, I'd like to ask if there is any interest of having a BoF around the topic of script language based extensions for KDE applications. I would love it, being engaged in adding Python scripting to Krita right now (following the example of Kate), but unfortunately it's vanishingly unlikely I'll be able to attend Adkademy. Boudewijn
Re: KF5 Update Meeting Minutes 2014-w28
On Tue, 8 Jul 2014, John Layt wrote: We already have a link to the donations page buried deep in the About KDE dialog under the Support KDE tab where no-one ever sees it. A Help menu item for Donate to KDE... that pops up a dialog explaining why would be far more visible, but easily disabled by distros who object. We could also include a Donate to KDE tip in every KTipDatabase and ensure it's the first tip shown by default on an apps first run. As an admin note, whenever we do add a donate link anywhere we should make it unique so that we can track how successful each channel is. As a datapoint, and not something most apps will want to do... Adding a splash screen with a donation link to the development build of Krita meant getting three out-of-the-blue donations a week more than the zero I had before. No huge numbers, but then, Krita still is small compared to other apps. Boud
Re: Compatibility problems with latest GTK+ applications
On Fri, 9 May 2014, John Layt wrote: Exactly, they seem to have forgotten what the G actually stands for :-) Which makes me wonder how apps like Gimp who use Gtk but are not part of Gnome and want to be cross-desktop and cross-platform are going to be affected? And how are the other Gtk desktops like XFCE affected? Well, from what I see from Gimp and MyPaint, GTK3 is a big problem already. Gimp's development is glacial, of course, but they started their GTK3 port ages ago and still haven't merged it. MyPaint uses GTK3 now, which means it doesn't work on Windows anymore. Tablet support is completely broken. As for inkscape, it builds against GTK3, but isn't stable at all yet, and GTK2 remains preferred. And in the meantime, the GTK developers themselves have made pretty clear that GTK is for Gnome applets, not big cross-platform desktop applications: https://lwn.net/Articles/562856/. GTK+ is primarily intended to be used on the GNOME desktop, using X11 as the backend. GTK+ must focus on being the toolkit of the GNOME platform first, and tackle integration second. And so on... Boudewijn
Re: What to test for 4.13?
On Sat, 8 Mar 2014, GEO wrote: On Friday 07 March 2014 20:17:16 Christoph Feck wrote: In other words, let us ask the are we there yet? question again for KDEPIM, and invite users to report thing that still might need to be addressed. If you ask me, KDEPIM offers a stable experience since 4.11 (Using it since 4.11 and everything just works for me, but I am just using it for Mails). Well, I have to use kmail since I cannot figure out a way to migrate my mail archive to something else, but happy I am not. Over the past months, I have experienced: * content of mails getting deleted, seemingly randomly. It often happens that a whole bunch of mails turn out to be empty when looking for some old mail * filters going haywire: suddenly _everything_ is filtered into the spam folder * kmail suddenly shows zero folders, fortunately restarting kmail and akonadi fixes that. * all folders are suddenly shown red, same remedy * the content of a mail isn't shown, same remedy... * the conflict resolution dialog pops up a dozen times in a row The first two issues have bug reports btw, I'm not sure what the current status is. Boud
Re: Review Request 114011: Add ctrl-shift-s as default shortcut for save-as
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114011/ --- (Updated Nov. 27, 2013, 8:34 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Bugs: 279388 http://bugs.kde.org/show_bug.cgi?id=279388 Repository: kdelibs Description --- This patch adds ctrl-shift-s as default shortcut for save-as, following the cua standard which the rest of KDE seems to follow. Diffs - kdeui/shortcuts/kstandardshortcut.cpp 669f750 Diff: http://git.reviewboard.kde.org/r/114011/diff/ Testing --- Thanks, Boudewijn Rempt
Re: Review Request 113965: Possible fix for bug 321100
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113965/ --- (Updated Nov. 23, 2013, 8:51 a.m.) Status -- This change has been discarded. Review request for kdelibs. Bugs: 321100 http://bugs.kde.org/show_bug.cgi?id=321100 Repository: kdelibs Description --- While I haven't been able to reproduce the issue on Linux, many Krita users encounter a crash in the destructor of KArchiveDirectoryPrivate, where all entries are removed with qDeleteAll. This patch removes the use of qDeleteAll. I'm not 100% sure whether this is correct, but it works for me with the Windows build of kdelibs I use. Diffs - kdecore/io/karchive.cpp 88e1de0 Diff: http://git.reviewboard.kde.org/r/113965/diff/ Testing --- Thanks, Boudewijn Rempt
Review Request 113965: Possible fix for bug 321100
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113965/ --- Review request for kdelibs. Bugs: 321100 http://bugs.kde.org/show_bug.cgi?id=321100 Repository: kdelibs Description --- While I haven't been able to reproduce the issue on Linux, many Krita users encounter a crash in the destructor of KArchiveDirectoryPrivate, where all entries are removed with qDeleteAll. This patch removes the use of qDeleteAll. I'm not 100% sure whether this is correct, but it works for me with the Windows build of kdelibs I use. Diffs - kdecore/io/karchive.cpp 88e1de0 Diff: http://git.reviewboard.kde.org/r/113965/diff/ Testing --- Thanks, Boudewijn Rempt
Re: Adopting AppData in KDE?
Okay... Couple of questions: * screenshot: which theme/color scheme should be used (btw, for Krita, on Gnome3, Plastique is hard-coded, because other themes are broken.) * license: is that the license of the appdata file or of the application? * How much of marketing and how much of dry description in the description field? -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Adopting AppData in KDE?
On Sat, 2 Nov 2013, Martin Graesslin wrote: On Saturday 02 November 2013 12:53:14 Boudewijn Rempt wrote: Okay... Couple of questions: * screenshot: which theme/color scheme should be used (btw, for Krita, on Gnome3, Plastique is hard-coded, because other themes are broken.) You want to sell your app to the user: use what makes it look best. In the case of Krita I would say: * Oxygen widget style * Krita dark color scheme * KWin color scheme adjusted to take the same color scheme For us in KDE I would suggest that we set up rules on how the screenshot has to be taken, it's impressive how wrong people can use ksnapshot ;-) (I have seen screenshots with KSnapshot capturing itself during the fade-out animation also very common is to capture the transition period between active/inactive app). It was easyish for me... I don't have any effects enabled. Here is the current shot: http://heap.kogmbh.net/downloads/krita_appdata_1.png I excluded the window decorations, btw -- maybe also something to discuss. Boud
Re: gdk_x_error (was: Re: [kile] [Bug 321759] Kile crashes when file is opened from menu)
On Friday 05 July 2013 Jul 15:34:06 Sven Brauch wrote: 2. GDK installs a deadly X error handler, causing the application to exit, instead of just printing an error message. See multiple backtraces containing gdk_x_error[3] There have recently been similar reports for KDevelop, too. Phew... It got fixed, apparently: https://bugs.launchpad.net/ubuntu/+source/kile/+bug/1195007 -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: gdk_x_error (was: Re: [kile] [Bug 321759] Kile crashes when file is opened from menu)
On Friday 05 July 2013 Jul 15:06:22 Christoph Feck wrote: On Friday 05 July 2013 04:01:04 Jekyll Wu wrote: https://bugs.kde.org/show_bug.cgi?id=321759 Actually, I have noticed a few similar 'crash' reports (bug 321931, bug 321972, bug 321954) created recently, and all of them are from Ubuntu systems. There are two issues here: 1. The application somehow issued an X error, most probably when trying to get X window properties of an already closed window. Might be an issue in KDE, see multiple backtraces containing NETWinInfo::update[1] or XGetWindowProperty[2] 2. GDK installs a deadly X error handler, causing the application to exit, instead of just printing an error message. See multiple backtraces containing gdk_x_error[3] Even if the first issue got fixed, I consider the second issue rather critical, and suggest to not call a previously installed X error handler. Comments? I've got the same problem for Krita (it apparently happens when trying to access the display profile atom, which may or may not be set): http://forum.kde.org/viewtopic.php?f=139t=111593 -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Review Request 111291: New Windows solid backend
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111291/#review35251 --- I am not competent to judge the code, but krita users are ecstatic about the improvements (I've been building installers with this backend for some time now). - Boudewijn Rempt On June 28, 2013, 6:05 p.m., Patrick von Reth wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111291/ --- (Updated June 28, 2013, 6:05 p.m.) Review request for kdelibs, kdewin and Solid. Description --- 1) Fixes ui blocking 2) Fixes problems where some drives could result in a unusable KDE system. 3) The wmi backend was broken from the beginning because the all wmi calls depend on the wmi host which can be just to slow for intense usage. This addresses bugs 178455, 306994 and 314317. http://bugs.kde.org/show_bug.cgi?id=178455 http://bugs.kde.org/show_bug.cgi?id=306994 http://bugs.kde.org/show_bug.cgi?id=314317 Diffs - solid/solid/backends/win/winstorageaccess.cpp PRE-CREATION solid/solid/backends/win/winstorageaccess.h PRE-CREATION solid/solid/backends/win/winprocessor.cpp PRE-CREATION solid/solid/backends/win/winprocessor.h PRE-CREATION solid/solid/backends/win/winopticaldrive.cpp PRE-CREATION solid/solid/backends/win/winopticaldrive.h PRE-CREATION solid/solid/backends/win/winopticaldisc.cpp PRE-CREATION solid/solid/backends/win/winopticaldisc.h PRE-CREATION solid/solid/backends/win/wininterface.cpp PRE-CREATION solid/solid/backends/win/wininterface.h PRE-CREATION solid/solid/backends/win/wingenericinterface.cpp PRE-CREATION solid/solid/backends/win/wingenericinterface.h PRE-CREATION solid/solid/backends/win/windevicemanager.cpp PRE-CREATION solid/solid/backends/win/windevicemanager.h PRE-CREATION solid/solid/backends/win/windevice.cpp PRE-CREATION solid/solid/backends/win/windevice.h PRE-CREATION solid/solid/backends/win/winblock.cpp PRE-CREATION solid/solid/backends/win/winblock.h PRE-CREATION solid/solid/backends/win/winbattery.cpp PRE-CREATION solid/solid/backends/win/winbattery.h PRE-CREATION solid/solid/backends/win/winacadapter.cpp PRE-CREATION solid/solid/backends/win/winacadapter.h PRE-CREATION solid/solid/CMakeLists.txt a5aba96b1c8b3f3147e9653ff5f244ea03cf2211 CMakeLists.txt 3d6c6beb8826ed98380d7ba9fa68efe2fde2fcb1 solid/solid/backends/win/winstoragedrive.h PRE-CREATION solid/solid/backends/win/winstoragedrive.cpp PRE-CREATION solid/solid/backends/win/winstoragevolume.h PRE-CREATION solid/solid/backends/win/winstoragevolume.cpp PRE-CREATION solid/solid/managerbase.cpp beaeac5d39198ce5aa53bea23a032621fa934088 Diff: http://git.reviewboard.kde.org/r/111291/diff/ Testing --- Testing has been don on windows. Thanks, Patrick von Reth
Re: Review Request 106581: Make KFileDialog remember settings
On April 10, 2013, 10:52 p.m., Albert Astals Cid wrote: Aurelien: David: apaku: Ping? Aurélien Gâteau wrote: Still in my TODO list :/ Looks there _is_ user demand: 16:17:17 RaktenUser while I am compiling Why are the mounts resolved to places in the file requester? We had put a lot of effort to have special filestructure which need to be honored e.g. for the asset managment systems. I tired to turned that off but I did not find a option. 16:18:19 boud that's stuff kde does by default for us. 16:18:53 boud I don't know exactly how to configure that, but I can take a look 16:19:58 RaktenUser hm in dolphin i can just uncheck the places sidebar ... 16:20:38 boud well, that works in krita too, doesn' tit? 16:20:52 RaktenUser no. 16:21:00 boud ah, the setting isn't remembered 16:26:32 boud https://git.reviewboard.kde.org/r/106581/... in dolphin it's remembered as part of the dockers setting 16:26:44 boud but for kfiledialog/kfilewidget it's pending - Boudewijn --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106581/#review30891 --- On Oct. 2, 2012, 10:55 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/106581/ --- (Updated Oct. 2, 2012, 10:55 a.m.) Review request for kdelibs and Andreas Pakulat. Description --- This patch makes KFileDialog remember settings such as which view mode is selected and whether the places sidebar should be visible. Original code tried to save those to kdeglobals so that changes would be shared among all applications but it did so the wrong way. The patch writes the configuration to kdeglobals correctly, but saves the KDirOperator to the application config file (KDirOperator configuration settings are sort settings, show preview, show hidden files, view style (icon, detail, treeview)) There are two reasons for not saving KDirOperator config to kdeglobals: 1. It is right now not possible to tell KDirOperator::writeConfig() to save to kdeglobals. It could be done by adding a new version of writeConfig() which would accept a KConfigBase::WriteFlags argument though. 2. It probably would not be a good idea to remember KDirOperator settings globally anyway because depending on the application one may want to use different settings. For example if user wants to select images or videos he might set the file dialog to show big icons and the preview pane (so that videos can be played). This setup would however not be adapted in an application where one wants to select a text file. This addresses bug 139475. http://bugs.kde.org/show_bug.cgi?id=139475 Diffs - kfile/kfilewidget.cpp 8e2f967 Diff: http://git.reviewboard.kde.org/r/106581/diff/ Testing --- Tested with two different KDE applications. Settings are correctly remembered. Thanks, Aurélien Gâteau
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Yuri Chornoivan wrote: Hi, Just a minor remarks on using UserBase for documentation. 1. It does not matter where you *do not* write your documentation. New Krita manual was started 5-01-2010 [1]. For now, it is not ready even at 1/10 level. The activity is extremely low. The content is badly formatted and hardly useful. Yet, it is 100% more than the effort that was expended on the 2.0 docbook manual. The reasons I never got further were: * no time * I hate writing wiki markup * no time The reason no users took up the effort were: * I mistakenly tried to keep the manual writing to myself, because I thought I could do the job and create a nice, uniform, consistent manual, just like the Krita 1.6 manual, which people have told me was about the best manual of any KDE app. That didn't work out. But without the wiki link, the user currently working on the manual would ever have offered his help. The projection can be made (by exploring similar wiki documentation projects, like Fedora, openSUSE, Mandriva, and Debian/Ubuntu) that when it will be ready it becomes obsolete for the current version. That holds for all manuals... Example of the manual that once was written and now partially outdated is Amarok Manual [2]. 2. Simple conversion docbook to wiki does not make manual useful. Example: Kexi handbook [3] was roughly converted to wiki with broken formatting, lost of index, and no substantial changes. Thanks to Burkhard it was polished (as a docbook) and converted back thanks to Claus Christensen. 3. Manuals can live without wiki conversion. Examples: Calligra Stage [4] and Calligra Sheets [5] manuals were never converted to wiki. For whatever reason, they are now in much more helpful state than Words and Krita docs (not saying that they have offline versions). That's because those applications didn't change so much; it had nothing to do with the conversion to wiki or not, but more with the applications not changing enough to outdate the manual. Because the 1.x krita manual was so good, it was impossible to update it for 2.0; there was too much that was irrelevant, and it needed to be rewritten completely. 4. Proper formatting allows very easy conversion from wiki XML to docbook. Once well-formatted, wiki pages can be converted into offline form (docbook, PDF, or EPUB) in almost no time[6]. Examples: Amarok, Kexi, Kdenlive, KrossWordPuzzle, part of KMail offline manuals are converted (and slightly fixed) UserBase manuals. Just for curiosity, you can compare the level of the translation covering for these docs in kde-i18n Subversion [7] and on UserBase. Conclusion I know that it is hard for developers to keep backward compatibility. But please do not cease to maintain DocBook compatibility in KDE 5. If you do, you will likely lost most of your docs and most of your documentation translators. I am far from making decision for developers, but it is always good to have some plan with real results. Just moving docs in hope that after that someone definitely write them is counterproductive. Just my 2 cents. Best regards, Yuri KDE Ukrainian team coordinator [1] http://userbase.kde.org/User:Boudewijn/Krita/Manual [2] http://userbase.kde.org/Amarok/Manual [3] http://userbase.kde.org/Kexi/Handbook [4] http://docs.kde.org/development/en/calligra/stage/index.html [5] http://docs.kde.org/development/en/calligra/sheets/index.html [6] http://userbase.kde.org/How_To_Convert_a_UserBase_Manual_to_Docbook [7] http://l10n.kde.org/stats/doc/trunk-kde4/team/ -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Anne Wilson wrote: I'm not subscribed to this list, so please cc me in any replies. Sort of proves my point that Mirko is right and that we need a KDE-wide mailing list for all contributors. ... Boud - I'm not arguing, but is email notification essential? Maybe it is, but it's possible to craft an RSS/Atom feed for Recent Changes affecting your pages. Would that help? Oh, that would work as well. I get forum updates in akregator, and that's fine. I just need all changes to a certain project pushed to me, because I simply don't have the time to check manually what is changed. ... Something I'd really like to see is applications having links to UserBase and forum.kde.org (maybe to a specific sub-forum) in the Help menu. Perhaps that's what Christoph had in mind. Good point about the link to the forum. I definitely want that! -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Eike Hein wrote: On 07/01/2012 07:02 AM, Boudewijn Rempt wrote: After yesterday's discussion where David said that for frameworks/qt5 the help center invocation is actually one of the trickier things, I'm giving this out for consideration for other app developers... Over at Konversation we've likewise struggled to keep our Docbook manual going: It's still among the better ones around, but we've been terribly lazy and let it rot, and if it hadn't been for Burkhard Lück showing it some love last year, it'd would probably be too outdated to use by now. At the same time we're doing reasonably well at maintaining our Userbase presence. We used to have our own MediaWiki installation but migrated everything to Userbase last year, and I wrote some software that sends report mails to our development mailing list highlighting changes and new pages so we can review them and make sure the quality stays high. I want that! I _so_ want that, too! Newly written documentation is now usually added to the wiki, not the manual, e.g. I wrote this this month: http://userbase.kde.org/Konversation/Configuring_SASL_authentication I can't really put my finger on it, but somehow it's just more convenient and enoyable to do it in the wiki. It gets you easy preview, makes collaboration easier, and somehow it feels like a more appropriate place for topic-focused guides than the book- structured Docbook manual. At the same time topic-focussed guides seem to be the best fit for us, because being an IRC client our helpdesk naturally is the IRC channel and handing out links that answer a particular question comprehensively works very well there. Plus, the wiki allows lots of extra stuff, like embedded video, links and so on. Ultimately Albert isn't wrong with his concern, but the reality seems to be that we just can't get our act together on the offline documentation while maintaining the wiki comes a lot easier to us. And it's better to have wiki documentation than no good documentation, IMHO. = -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Kevin Ottens wrote: And i'm going to be a pain here, but i do not agree userbase scale better either. Let's see Krita manual at http://userbase.kde.org/Krita it's translated to 7 languages only two of them being at 100% Now let's see KMail manual at http://l10n.kde.org/stats/doc/stable-kde4/po/kmail.po/ and we have 12 at 100% and a few more over 90% Right but that said, the number of translations is not the only metric to take into account regarding documentation. Overall quality of it and its coverage of the application features, keeping up with changes, are equally important IMO. The krita manual also isn't an import of an existing docbook manual, we scrapped the old one completely -- in other words, it hasn't been around as long as the kmail manual. That's where I think the wiki is actually superior to the docbook stuff we're doing (as Boud and Eike pointed out). Now the low number of translations? That's likely in part because our translators are not used to look there to translate. Which raises the question of: If we were to consistently use the wiki how do we best support our documentation translators? Would they just be happy with being pointed to the wiki as it is a simple enough tool? Or would they need the wiki content extracted as po files so that they use their current toolchain for translation (aka the wiki is a too simple tool)? I can't answer to that, but the fact that the krita manual in its current stage already has so many translations is encouraging. Both possibilities are fine IMO. Means in the second case we need to write an equivalent to our current docbook extractor but for the wiki somehow. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Using userbase for manuals
On Sunday 01 July 2012 Jul, Boudewijn Rempt wrote: On Sunday 01 July 2012 Jul, Eike Hein wrote: On 07/01/2012 07:02 AM, Boudewijn Rempt wrote: After yesterday's discussion where David said that for frameworks/qt5 the help center invocation is actually one of the trickier things, I'm giving this out for consideration for other app developers... Over at Konversation we've likewise struggled to keep our Docbook manual going: It's still among the better ones around, but we've been terribly lazy and let it rot, and if it hadn't been for Burkhard Lück showing it some love last year, it'd would probably be too outdated to use by now. At the same time we're doing reasonably well at maintaining our Userbase presence. We used to have our own MediaWiki installation but migrated everything to Userbase last year, and I wrote some software that sends report mails to our development mailing list highlighting changes and new pages so we can review them and make sure the quality stays high. I want that! I _so_ want that, too! I just got that :-). I'm very happy with it, but Eike is right that it probably wouldn't scale, being a poller. It's really something that needs to be fixed in the wiki system, so we can get a mail for every change to a manual done in the wiki. I'm just to dependent on getting all my updates in kmail... -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Using userbase for manuals
I'm actually not sure kde-core-devel is the right list... But the e.V. mailing list certainly isn't, and we don't seem to have any place for discussions that affect KDE as a whole. In any case, Ingo Malchow said in his blog (http://blog.neverendingo.de/?p=125) We have a great userbase.kde.org but developers don’t use it that much, nor is there any links from applications towards Userbase. Well, actually we have. I replaced the offline help documentation in Krita with a link to the manual on userbase. I have done this for two reasons: * I couldn't maintain the offline manual anyway after the change to 2.0 * this way the user gets sent right to the place where they can contribute to the manual (and I've got users contributing to it now) I'm not concerned that users cannot access the help when they are off-line. That's a vanishingly rare situation these days, the big thing is that it gets users right where they can fix the manual (Except on windows, where the browser invocation seems broken). After yesterday's discussion where David said that for frameworks/qt5 the help center invocation is actually one of the trickier things, I'm giving this out for consideration for other app developers... -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: mimetype for files with a wrong extension?
On Tuesday 10 April 2012 Apr, David Faure wrote:
On Monday 09 April 2012 12:41:52 Boudewijn Rempt wrote:
I'm trying to figure out why kmimetype returns image/jpeg for a png file
that was renamed to have a jpg extension (which apparently happens a lot
for real users).
Yes, we trust the extension, because this allows user to be in control, for
the case where magic-detection is incorrect.
I see... For image files, the magic tends to be pretty robust and the users to
be not always totally competent...
If you want to detect misnamed files for mimetypes where magic can be trusted
(JPEG/PNG are indeed in that case), you can call findByContent and compare
with
findByUrl, and warn the user if they differ (or just use the magic result).
Okay, I've done that for Calligra now.
In the dox for KMimeType::findByUrl it's said that if only the filename is
used to determine the mimetype, accuracy is set to 80 -- but it's not, it's
set to 100.
diff --git a/kdecore/services/kmimetype.cpp b/kdecore/services/kmimetype.cpp
index 955bf62..74f371d 100644
--- a/kdecore/services/kmimetype.cpp
+++ b/kdecore/services/kmimetype.cpp
@@ -211,6 +211,7 @@ KMimeType::Ptr KMimeType::findByUrlHelper( const KUrl
_url, mode_t mode, kWarning() Glob file refers to selectedMime
but this mimetype does not exist!; mimeList.clear();
} else {
+accuracy = 80;
return mime;
}
}
lines 1-12/12 (END)
Commit that if you want [after running kmimetypetest] -- but I removed the
whole concept of the accuracy number in KF5.
Okay :-)
When doing this I can at least see that only the filename was used. But I'm
wondering why checking the magic numbers for jpg, png and so on from the
content isn't given a higher accuracy, since if do a findByContent, I get
an accuracy of 50 for my file, but the magic numbers for image files are
pretty much completely reliable.
shared-mime-info says magic priority=50 indeed, which is the default
value. Higher values are only used to order magic things relative to each
other. This shows another reason why I want to get rid of these numbers in
the
public API.
Hm, yes, I see. Thanks for the explanation!
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
mimetype for files with a wrong extension?
I'm trying to figure out why kmimetype returns image/jpeg for a png file that
was renamed to have a jpg extension (which apparently happens a lot for real
users).
In the dox for KMimeType::findByUrl it's said that if only the filename is used
to determine the mimetype, accuracy is set to 80 -- but it's not, it's set to
100.
diff --git a/kdecore/services/kmimetype.cpp b/kdecore/services/kmimetype.cpp
index 955bf62..74f371d 100644
--- a/kdecore/services/kmimetype.cpp
+++ b/kdecore/services/kmimetype.cpp
@@ -211,6 +211,7 @@ KMimeType::Ptr KMimeType::findByUrlHelper( const KUrl
_url, mode_t mode,
kWarning() Glob file refers to selectedMime
but this mimetype does not exist!;
mimeList.clear();
} else {
+accuracy = 80;
return mime;
}
}
lines 1-12/12 (END)
When doing this I can at least see that only the filename was used. But I'm
wondering why checking the magic numbers for jpg, png and so on from the
content isn't given a higher accuracy, since if do a findByContent, I get an
accuracy of 50 for my file, but the magic numbers for image files are pretty
much completely reliable.
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Review Request: include KolorManager in kdegraphics
On Saturday 31 March 2012 Mar, Kai-Uwe Behrmann wrote: Given the recent discussions in this thread, there is not something fundamentally technical to change inside KolorManager. Many have expressed the opinion to move it not into kdegraphics ATM and use kdeextragear instead. As most applications on Linux use the Xorg atoms to do ICC monitor compensation, a KolorManager to setup device profiles might help them already. Can we proceed with the move into extragear? I would welcome that step. (Also, in the cetero censeo vein, I would welcome a step to make the wacom config kcm more generally available.) -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Bugzilla upgrade.
On Thursday 15 March 2012 Mar, David Jarvie wrote: On Wed, March 14, 2012 9:41 pm, Burkhard Lück wrote: And to have the Additional Comments field above the BR and all comments is like tofu (http://en.wikipedia.org/wiki/Top-posting#Top-posting) There is now a preference setting which lets you choose whether to display the Additional Comments field at the top or the bottom. On Wed, March 14, 2012 7:32 pm, Daniel Nicoletti wrote: I don't think so, I think it has some huge icons but I thought it was my browsers problem, the huge header and footer it's real hard to see the content on my small screen, the new version fews snappier but the theme needs polishing imo. I also renders the footer strange using Chrome, but I hope someone is still working on this... :D Yes, the header fields waste a _lot_ of space. The old theme was far better in that respect. And the footer field tends to obscure the line I was searching for, at least in firefox. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote: Request: After working on KolorManager and Oyranos in the past months for the last Oyranos-0.4.0 release, we feel the stack is ready to review for inclusion into KDE. KolorManager resides currently in Playground/Graphics: http://quickgit.kde.org/?p=kolor-manager.gita=summary Just a quick question, currently we have two CMS stacks, colord and oyranos, while I have nothing against having two of them in KDE, I wonder if this would become a problem for colord-kde [1] to enter in kdegraphics too? There should be only one. In that case would be better to both go to kdeextragear or is there some different policy in this case? No. There should be color management by default in KDE, that's really important; and there should be only one solution by default. We shouldn't let distributions, or even worse, users decide which solution they use. That way madness lies. KDE's Color management solution shouldn't be in extragear. As to which one is selected, there are a couple of ways to decide. The first is, first come, first go. Kolormanager has been in development for quite some time now, and colord is an upstart, gnome-derived technology. Integration of colord in kde was only started very recently. Everyone is free to start a competing project, even inside KDE, but to make that project block a pre-existing project isn't the way to go. The second way to decide would be on technical merits. I'm not going to go into that discussion; I've seen too many tiresome discussions already, and I don't feel really competent anyway. For me as an application developer, life sucks anyway, since I have to support Linux, Windows and OSX, so for the time being, the application will offer its own way to select profiles, in addition to using the X11 display atom that both colord and kolormanager support. (And I don't want to think about printing anyway.) I'm actually targeting KDE SC 4.9 as gnome-color-manager is very mature and I am pretty much just rewriting it with Qt/KDE libs. 1- http://dantti.wordpress.com/2012/03/12/coloring-you-desktop-with-colord-kde/ Best, Daniel Nicoletti -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 Mar, Daniel Nicoletti wrote: No. There should be color management by default in KDE, that's really important; and there should be only one solution by default. We shouldn't let distributions, or even worse, users decide which solution they use. That way madness lies. KDE's Color management solution shouldn't be in extragear. As to which one is selected, there are a couple of ways to decide. The first is, first come, first go. Kolormanager has been in development for quite some time now, and colord is an upstart, gnome-derived technology. Integration of colord in kde was only started very recently. Everyone is free to start a competing project, even inside KDE, but to make that project block a pre-existing project isn't the way to go. I'm not talking about blocking pre-existing projects, I'm really looking forward a solution where the two could live. Well, I am really not looking forward to that situation. Sometimes having a choice is a bad thing. Sometimes starting a new project instead of helping out an existing project is not the right thing to do. Sure we don't want users/distributions to decide but they do. The second way to decide would be on technical merits. I'm not going to go into that discussion; I've seen too many tiresome discussions already, and I don't feel really competent anyway. For me as an application developer, life sucks anyway, since I have to support Linux, Windows and OSX, so for the time being, the application will offer its own way to select profiles, in addition to using the X11 display atom that both colord and kolormanager support. (And I don't want to think about printing anyway.) Well if we go into the merits discussion I really think we will get nowhere, as we didn't sort this first we won't sort this out now, KDE and GNOME primary goals is Linux, so I really don't think supporting platforms where they already have good solutions for this is a way to go. No, Gnome's primary goal is Gnome, while KDE offers a framework for building applications on many platforms next as well as desktop environment. My own desktop environment is KDE's plasma, but my goal for Krita is to have it run everywhere, not just on the plasma desktop. In fact, until Gnome 3 and Unity drove them away, most of my users were on Gnome... And that was fine, because colord and oyranos both set the relevant X11 atom, so Krita is fine, as long as I explicitly don't care about scanners and printing. So how do we go into the merit discussion without creating yet another flame war? I don't know. I don't know of a extensive comparison between colord and oyranos. And I'm not sure it's possible anymore to find anyone who can do that competently, honestly and impartially. Realistically speaking, we'll have colord on Linux as the standard whether we want it or not, because it's in Fedora, and whatever Redhat puts in Fedora will be the standard for Linux. Of course other distributions will package it, because they will want to package gnome. Even if we had been faster to the finish line and had had kolor-manager ready for KDE 4.6 or 4.7, no way colord would not have replaced our own work. Apart from all technical merits. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Review Request: include KolorManager in kdegraphics
On Wed, 14 Mar 2012, Matthias Klumpp wrote: Hi! Colord - just to mention that - is also not a GNOME project, it's a FreeDesktop project. (Doesn't mean it's standard, but does mean that it's not GNOME) Well, no, having something on freedesktop.org doesn't mean it's not a gnome project; it is a gnome project, and it's widening its scope. The reason it's used at all is that is is used inside gnome. So everyone is free to contribute to it, and the maintainer is interested in collaborating with KDE. (which he already does very nicely) There's one thing about Oryanos I'd like to mention: I wanted to find out why Oryanos is not packaged yet on many distributions. Reasons are the strange build system it uses (looks like a custom thing to me), which makes it difficult to build it on multiple architectures. It also has dependencies like Elektra, which looks dead to the public. (But is still developed, as it's maintainer says) Oryanos requires a special version of Elektra packaged. There's also some other stuff going on which needs to be clearified before Oryanos can be shipped in distributions easily. It's easy enough to package -- the opensuse packages I use work perfectly fine, so I cannot imagine that there are any real and relevant problems for other distributions. It also has some legacy stuff, like Compiz plugins - a KWin plugin would be better for KDE, IMHO ;-) So that is irrelevant -- it used to be relevant some years ago, which sort of shows that oyranos is a project that has been going already for quite some time and has made several transitions already. Which is a good thing. On the other hand, colord has a clean codebase, less dependencies and it just works for GNOME. And oyranos + kolormanager just works for KDE. Although I don't have experience in color management, Well, that's the issue really: nearly nobody has a real and thorough understanding of color management. I've been working with color management in Krita since 2004, and I still have to admit that I don't have a good overview of all issues. seeing the younger project replacing the older one so fast shows me that colord at least provides enough and well-working functionality for color management on Linux. The only reason colord spreads is because it's by default part of gnome3. That in itself doesn't show anything about its technical merits. And within gnome, it is actually barely used. In the end, it's the applications that make the difference. Therefore, it might be a good thing for KDE to choose it. (Maybe do some tests with it first) I also want to point you to this comparison colord against Oryanos: = http://www.freedesktop.org/software/colord/faq.html#oyranos Given the extremely tense and nasty discussions we've had, with Alexandre Prokoudine calling Kai-UWe a liar and so on, I am not sure that relying on one project's assesment of the other project is a good idea. In fact, I am sure it is not. I'm also sure unless people are prepared to spend some time on figuring out what color management is all about instead of posting lists of statistics, the question is not being considered on its technical merits. pop-contests, lines-of-code, dependencies and so on are all non-technical when it comes to determining whether the color management works. But then, as I've said before, for me, as the author of an application for which color management is actually essential, both colord and oyranos work fine. Boudewijn
Re: Review Request: include KolorManager in kdegraphics
On Wed, 14 Mar 2012, Sune Vuorela wrote: On 2012-03-14, Boudewijn Rempt b...@valdyas.org wrote: It's easy enough to package -- the opensuse packages I use work perfectly fine, so I cannot imagine that there are any real and relevant problems for other distributions. Sure it can be done. but it is just useless churn if it doesn't really provide anything that matters to the end user that colord doesn't. And, of course, the other way around -- but that's the point isn't it? Until a library is used, it isn't packaged. And until we actually have input from people who know what they are talking about, or listen to them, we cannot decide whether anything provides anything that matters to the end user. I think it's true, though that What _is_ missing is a clear list of what oyranos provides right now -- apart from making it possible to select the display profile for X11. And then, if that list is available, it's of course very much the question whether enough people can understand it properly. I could package oyranos and the weird things it requires. I wish we could do without being pejorative. but in the same time I_could probably fix 20 small annoyances for all users and package the new nice nepomuk ioslaves. What is the best use of my time? That depends. If KDE uses kolor-manager, then oyranos needs to be packaged. Should we let that decision depend on whether it's already packaged? Sounds like the wrong way around. Boudewijn
Re: Review Request: include KolorManager in kdegraphics
On Wednesday 14 March 2012 Mar, Alexander Neundorf wrote: On Wednesday 14 March 2012, Thomas Zander wrote: On Wednesday 14 March 2012 21.29.09 Alexander Neundorf wrote: The wiki page somebody pointed to mentioned that colord is linux-only, while oyranos also works on Windows and OSX. If we chose colord, how does our solution for Windows and OSX look like ? Does kolormanager work under Windows and OSX ? Matthias answered your question very well, and I agree with him. Let me ask you a return question; with the heavy dependency on X11 in oyranos but with colord already starting work on wayland, how will we support wayland soon? I know basically nothing about color management systems. Well, that's true for nearly everyone in this discussion. It's not a discussion based on facts, it's a discussion based on impressions, guesses, hunches and misconceptions. Don't some applications needs some kind of interface to use the color management system ? Yes. Right now, the only interface Krita uses is the X11 atom to set the monitor profile, and for the rest, we let people select profiles from disk. This is very limited. We're not interested yet in printing or scanning, but once that comes we need to talk to the platform color management system directly. Unless there is something cross-platform that we can talk to instead. That's worth any amount of dependencies in my book. Or is it only for setting up X, the printer, Wayland, etc. In the first case, if applications (e.g. krita) need some way to work with the color management system, wouldn't it be good if KDE provided one interface on all platforms ? That is definitely true. If oyranos papers over the differences between the Linux, Windows and OSX color management systems, that is absolutely fantastic. I don't want to write my own abstraction library to query colorsync, colord and so on. I actually started doing that last year, in fact, and then decided not to continue. It was when I tried to implement colord support during LGM, and figured that I'd need to implement similar support on Windows and OSX since my cross-platform app now was using platform-dependent things. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Re: DrKonqi improvement idea
On Tue, 13 Mar 2012, Ben Cooksley wrote: Hi all, Whilst I have not evaluated it's compatibility with Bugzilla 4.2, I do not suppose anyone has looked at https://launchpad.net/bugzilla-traceparser ? That looks very interesting and user-friendly to me. Boudewijn (who still has nightmares from having implemented breakpad and socorro at a $DAYJOB).
Re: bugzilla situation
On Fri, 24 Feb 2012, Alex Merry wrote: On 24/02/12 09:22, Thorsten Zachmann wrote: Why not have a state for bugs that you know are worth fixing? Then the developers can concentrate on those and Other people can do the initial cleaning to get the bugs to a state they can be closed or the proper state set. That would be assigned, I'd have thought. Or perhaps new, although bugzilla makes the assumption that all developers will file real bugs straight away. For Krita, I assume that developers know what they are doing, so I'm fine with bugs being set to New immediately, although I would prefer if every bug started out as unconfirmed. I only mark bugs as assigned if it's clear who should work on it; until then, as soon as I can confirm a krita bug, it becomes new. I try to give every report a respons within a week, as well, and I've noticed that if I say thank you for your report, reporters don't mind waiting for a fix, me asking them for more information, closing the bug as duplicate, or telling them to get a newer version and closing the bug as already fixed. It might be a little bit of social engineering, but I try to never close a bug as wontfix or worksforme; in those cases I close the bug as needsinfo. If the user gets back to me with more information, I'll thank them again and look at the bug again. But I'm lucky, I'm not getting dozens of reports a day yet, and bugzilla is an extremely useful tool for me. Boudewijn
Re: Color Managing KDE
On Wednesday 22 February 2012 Feb, Nuno Pinheiro wrote: A Quarta, 22 de Fevereiro de 2012 10:46:53 Richard Hughes você escreveu: First, I apologise about the cross posting. Please drop any list which isn't relevant in your replies, and please also cc me as I'm not subscribed to either list. GNOME has been a color managed desktop by default for two releases now, and I deliberately designed colord to have an open Freedesktop DBus API that could be used by both desktops. Really, KDE just has to include a KCM module to do the 6 things on this list and also perhaps include a simple control center panel to configure it. Basically, I need a KDE dude. Of course, I can help quite a lot and mentor the project, but I’ve never really coded Qt or C++ in anger, so to speak. If you’re interested, I could maybe even set up a Google summer of code place as well, although I’d prefer it to be an existing person familiar with the KDE community so there is some ongoing maintainer. If anybody is interested, let me know and I’ll set up a meeting and we can talk and discuss details. Thanks. Richard Hughes Use case here I want this :D, please guys help Richard. Yill make you free icons :D and mybe pay you a beer or 2. While I agree that KDE needs colormanagement built-in, especially with artists moving to KDE (I get almost no bug reports for Krita from gnome users anymore, while that used to be the majority...) it's not like nothing has been done before for KDE: Especially: http://www.oyranos.org/2011/11/kde-and-colour-management/ http://www.oyranos.org/kolormanager/ which are now, afaik, being used in OpenSUSE. There's quite a bit of contentiousness between around this topic, and I have to say, while I don't get the technical differences all the time, I do understand the friction I see happening on, e.g., the openicc mailing list. With all the respect I feel for Richard, I do think that this is yet another of those technologies that get developed in splendid isolation for Gnome, forced upon the Linux world by Redhat, claimed to be a standard and which is then used to complain about KDE's lack of involvement yet again. It makes me feel a bit unhappy. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: hard-dep for Qt 4.8
On Thursday 19 January 2012 Jan, David Faure wrote: On Wednesday 18 January 2012 10:26:13 Thomas Zander wrote: As far as I know there are no forward incompatible behavior changes between Qt4.7 and Qt 4.8 One can dream :-) ... There might be more. For one thing... In Qt 4.8, QSplashScreen is broken. The splash is only painted over a gray rectangle once main window is shown. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: hard-dep for Qt 4.8
On Tuesday 24 January 2012 Jan, Thomas Lübking wrote: Am 24.01.2012, 23:53 Uhr, schrieb Boudewijn Rempt b...@valdyas.org: For one thing... In Qt 4.8, QSplashScreen is broken. The splash is only painted over a gray rectangle once main window is shown. Tried with eg. plastique? (The background gradient painting of oxygen/bespin/qtcurve could interfere with this) Yes, there's no difference. Try e.g. Choqok or Krita. First it shows a gray rectangle, then hides it, then shows the main window (as a gray rectangle) then paints the splash. This is new in Qt 4.8 and is not dependent on the style. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Who relies on Soprano::Model::statement[s]Added|Removed signals?
On Wednesday 05 October 2011 Oct, Volker Krause wrote: On Friday 30 September 2011 13:36:22 Sebastian Trüg wrote: Hi lists, with frameworks in the building and Nepomuk probably going that direction already for 4.8 I would like to clean up a bit. One of these cleanup tasks targets the Soprano::Model statement signals. So far these were the only way to get informed about changes in Nepomuk - with a very bad impact on performance and bad usability. With 4.7 we already introduced a preliminary version of the Nepomuk::ResourceWatcher[1] which is now in charge of informing clients about changes. I would like to anyone using the old API to change to the new ResourceWatcher as soon as possible because I would like to disable the old signals soon. They simply entail to many problems and clutter the API. kdepim uses those signals in the following places: - libmessagelist (kdepim/messagelist) - kmail - Nepomuk tag resource (kdepim-runtime/resources/nepomuktag) Calligra doesn't use them, according to grep. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Proposal to use QIcon in APIs in KF5.
On Wednesday 07 September 2011 Sep, Olivier Goffart wrote: On Wednesday 07 September 2011 08:53:25 Boudewijn Rempt wrote: On Wednesday 07 September 2011 Sep, John Layt wrote: Porting a dozen or so lines from KIcon(foo) to KIconFactory::icon(foo) is nowhere near the effort Just to make sure that everyone has the right perspective on the size of any porting effort: Calligra alone has over 1200 of KIcon(foo) lines. Try this command: git grep -Osed -i 's/KIcon(/QIcon::fromTheme(/g' KIcon and I am pretty sure this simple line 'port' over 99% I'm sure you're mostly right. I'm also sure that as soon as there's the assumption that any change only affects a dozen or so lines, but in fact affects a hundred dozen lines, the assumption that the porting effort will minor will be wrong. In other words, before changing something so it needs porting, people really should look at the real, actual codebase of a couple of big projects that might be affected. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Proposal to use QIcon in APIs in KF5.
On Wednesday 07 September 2011 Sep, Oswald Buddenhagen wrote: On Wed, Sep 07, 2011 at 01:42:47PM +0300, Boudewijn Rempt wrote: In other words, before changing something so it needs porting, people really should look at the real, actual codebase of a couple of big projects that might be affected. it doesn't matter how many TLOC are affected if the change is fully automatable. All I wanted to say, irrespective of whether you think you can automate the porting, that the actual task of porting a real codebase is much, much, much, like orders of magnitude, bigger than it seems. in fact, for qt5 we defined source compatible to mean porting can be fully automated. Would be nice, but it means that Qt5 won't be source compatible following the definition, nor will KDE5. But I'd be happy to be proven wrong, of course. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Sunday 21 August 2011 Aug, Oswald Buddenhagen wrote: On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote: On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote: yes, when the faulty module crashes. not so when it deadlocks or busy-loops. also, a restart typically loses state. True, but I don't remember that happening a single time to me in the past 3 years. I remember seeing people complain about kded taking 100% CPU, but it hasn't happened to me. yes, things have stabilized meanwhile. but the problem will re-appear during the kde5 cycle. it's inherent, after all. Actually kded using 100% cpu happened to me last week, when I was travelling. Took me some googling to figure out that it was some incompability with libntrack and that I needed to install that from source. I even had to use gnome as my desktop for a day before I had time to figure out what was going on... -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Summary from Buildsystem BoF at Desktop Summit
On Monday 15 August 2011 Aug, Alexander Neundorf wrote: Me (Alex) argued that most of the stuff in these macros adds only convenience for (lazy) KDE developers, and will probably not be accepted. Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). - requiring that developers add find_package(kcore), find_package(kio), find_package(kjob) etc. is acceptable - there won't be a KDE4 compatibility file, among others because due to the reorganization there may not be libraries which exactly represent the functionality contained e.g. in kio now Altogether it looks like there will be a huge porting effort needed for a suite like calligra :-( -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011 Aug, Stephen Kelly wrote: Boudewijn Rempt wrote: Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). Which do you use? Do you also use them when creating libraries, not just apps? Yes, also for creating libraries, unittests -- not for plugins, but that's all. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: Requested Moratorium on hard to build dependency bumps for KDE 5
On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. In my opinion, almost always needing the development version of e.g. GTK is what is keeping GIMP a project with hardly any contributors. But that's an application, not a framework. Still -- if you want to have a healthy project with many contributors, making it hard to develop by requiring lots of unpackaged isn't a good idea. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: getting rid of qt3support in kde-workspace
On Wed, 25 May 2011, Albert Astals Cid wrote: A Wednesday, May 25, 2011, Aaron J. Seigo va escriure: hi :) i just finished pushing a set of changes to the (ironically named?) qt3support branch in kde-workspace which leaves no traces of qt3support or kde3support left in that module. huzzah! i'm ok with holding on to the branch until 4.8, but if there is interest in getting this into 4.7 it should be a fairly safe merge and would allow distributors to ship kde-workspace without a dependency on qt3/kde3support. Is there a real demand for this? Yes, I'd say there's a real demand. qt3/kde3 support takes space and qt3-support doesn't exist on OSX anymore, and is going to disappear everywhere else. After Qt 4.8, no Qt3 support anymore. Best get it removed everywhere as soon as possible. (As well as QWidget/QPainter code, too, of course.) Boudewijn
Re: Git Worflow, branch creation.
On Thursday 19 May 2011 May, Cornelius Schumacher wrote: On Thursday 19 May 2011 Aaron J. Seigo wrote: http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Workf low Wow. This is a pretty complex workflow, and it's breaking with quite some practices KDE used to use for a very long time. We have to make sure that we don't leave developers behind with such a drastic change. The approach of having one central repository and all committers being equal has served us well. Maybe it's time to move forward to a different model, but I think this should be done with care, and without changing more than needed. A lot of this is about semantics and how to name things, not necessarily about technical processes. For example, if master is the stable branch or a release branch doesn't make a big difference technically, but it might affect our development culture quite a bit. This needs to be discussed. I'm looking forward to the upcoming face-to-face meetings, but we should also have a wider discussion, as this is affecting many more people than those who will have the opportunity to be at these meetings. In Calligra, we sort of discussed that we might call the staging branch where everyone can commit master, and that we'll try to get an automated system to copy commits that didn't break unittests to the release branch, which only the automated system can commit to. That keeps everyone in the loop on master, at the expense of having a release branch that nobody really runs. We're not there yet, obviously :-) -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Qt5 - KDE5?
On Monday 09 May 2011 May, Olivier Goffart wrote: - Do we want KDE 5 to be a big change, or just a small increment? Given that an app like krita has only just now reached enough maturity to reach an audience, any hint of big changes to the KDE platform make me really afraid. We (the krita guys) need at least another five or ten years without churn! (And for us QML is churn, QGraphicsWidget is churn -- there's nothing that we need to do which cannot be done with a QWidget or directly in OpenGL.) -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Replacement for Qt's Undo Framework
On Monday 25 April 2011 Apr, Alexander Potashev wrote: ... Just want to say I think it's really nice to see Matus' Google Code In work noticed :-) -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: OpenPrinting Summit - Print Dialog and Colour Management
On Thursday 17 March 2011 Mar, Kai-Uwe Behrmann wrote: Am 17.03.11, 07:29 +0100 schrieb Boudewijn Rempt: On Thursday 17 March 2011 Mar, Christoph Feck wrote: Also on the agenda is integrated end-to-end Colour Management possibly using colord [4], something I know absolutly nothing about, so any feedback or suggestions people have on that will be very welcome. For starters the dependencies for colord are glib and policykit. Kai-Uwe Behrmann (maintainer of KDE color management applications) can help you here. Grab him on http://www.oyranos.org/ and make sure he attends the meeting ;) Well... Kai-Uwe and Richard Hughes have had huge discussions on colord on the openicc mailing list (http://lists.freedesktop.org/mailman/listinfo/openicc) -- too huge for me to follow them. This list might be a good starting place for more info. For what I got out of it, colord seems to be, like so many generic libraries be focussed on gnome/gtk-first, while oyranos (Kai-Uwe's system) is burdened by using a config system that nobody packages. But that impression might be outdated and is certainly over-simplified. Agreed, the discussion threads are very long. But we are about to extract important ideas[1][2] and turn them into proposals[3]. That's so cool! Oyranos ships with the needed configuration code inside its source tree since the last release at begin of this year. Great! The library comes with a CUPS module for printing, and further SANE (which needs patches), Xorg, Quarz monitor and CameraRAW modules. What would be cool to have are a Quarz module for printing and make the library fit for Windows' WCS. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: irc meeting for kdelibs git workflow
On Wednesday 02 February 2011, i...@michael-jansen.biz wrote: Zitat von John Layt johnl...@googlemail.com: On Wednesday 02 February 2011 09:19:29 Oswald Buddenhagen wrote: On Tue, Feb 01, 2011 at 01:37:26PM -0800, Aaron J. Seigo wrote: * adapting http://techbase.kde.org/Policies/SVN_Commit_Policy i'd suggest a look at http://qt.gitorious.org/qt/pages/CommitPolicy, in particular point 8 of the rules. the point it makes is independent from using git (in fact, we have a similar point already), except that with git it is so much easier to do that, so at least a certain percentage of people may actually adopt it. +1 to that, especially the commit template and more descriptive commit messages. In fact, attached is my attempt at such a template based on the Qt one. It's a bit verbose as it's intended as an educational tool, once people know what's expected they can delete all the comments in their local copy. If the Commit Digest guys want some tags added to make their life easier, now would be the time to speak up. John. I like it but would propose: # ===[ Subject ]===| # ---[ One line only, short meaningful description to show in logs ]---| # ===[ Details ]===| # ---[ Blank line above intentional. Do not remove ]--| # ---[ Describe what has changed and explain why it has changed ]--| It think that is more robust . I like it as well. How can I make sure calligra hackers get to see this when they try to commit? -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
Re: Usefulness of Subject-header of git commit mails
On Sunday 23 January 2011, Milian Wolff wrote: But probably my problem is that I only work on semi-large repositories like KDevelop/KDevplatform/Kate. There I'm interested in *everything* that goes on. In Calligra you have only one big repo for all the apps, correct? Here I indeed can understand how the path has still some information value. Yes, that's right -- and I totally understand why it's useless for other projects. -- Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
