Activity Not Available
I Use This!

News

Analyzed 3 months ago. based on code collected 4 months ago.
Posted about 1 hour ago by Krita News
The artists, developers, website maintainers and documentation writers who were in Deventer for the Krita sprint  since Thursday are now slowly returning home. Some will stay for a bit longer, others had to leave on Sunday already. There is ... [More] something extremely exhausting and exhilarating about a real-live meeting like this! Lots and lots of topics were discussed: We discussed, are actually still discussing, the user interaction design for the vector and text projects this year’s kickstarter funded. Lots of work was done to support OSX properly — the opengl patch looks ready to land in Qt! There were also some fixes to tablet handling. We had all three Google Summer of Code students present! Wolthera finished the second part of her project (the first was soft proofing and is in 3.0.1): a new color selector internal to Krita that is fully color managed. Jouni presented his animation work and Julian his work on Qt’s OpenGL QPainter engine.   We discussed the publication of a Pepper and Carrot book by the Krita Foundation with David Revoy. Pepper loves Kiki! We refined the release process and the process by which we take feature requests all the way to implemented and released features. Jouni sat together with Stefan, the author of this post’s sketches and who is also an accomplished animator to go though Krita’s animation workflow We discussed how badly we need a new architecture and UX design for resource management We made plans for improving the website and the webshop Dmitry showed a new brush engine (alcohol markers) that can handle enormous brush diameters — 2500 pixels isn’t impossible We fixed bugs, bugs and bugs…. And finally, we had a great time. Many dedicated contributors to Krita had never met in person before, and now we’ve got faces and voices mapped to chat channel nicknames and commit message email addresses! The 2016 Krita sprint was sponsored by KDE e.V. (travel) and the Krita Foundation (accomodation and food). Thanks! We also happened to have planned the sprint right for the week the Dutch summer decided to present us with a heatwave. Fortunately we could use a nice and cool cellar. Add some internet and power strips, and it was a great hack and dinner room! Builds And we’ve got new builds! With a new splash screen! And some bug fixes. Fixed 100% opacity blobs at the start of a line on OSX Don’t allow users to remove the autogenerated gradients Fix a crash when the resource selector tries to display a deleted resource Update the default workspace set Fix exporting animations to the CSV format Fix translations on Windows Windows On Windows, Krita supports Wacom, Huion and Yiynova tablets, as well as the Surface Pro series of tablets. The portable zip file builds can be unzipped and run by double-clicking the krita link. Krita on Windows is tested on Windows 7, Windows 8 and Windows 10. There is only a Windows 64 bits build for now. Also, there is debug build that together with the DrMingw debugger can help with finding the cause of crashes. See the new FAQ entry. The Windows builds can be slower than usual because vectorization is disabled. krita_3.0.99.91-x64.zip krita3-x64-dbg-latest.zip Linux For Linux, we offer AppImages that should run on any reasonable recent Linux distribution. You can download the appimage, make it executable and run it in place. No installation is needed. At this moment, we only have appimages for 64 bits versions of Linux. This appimage has experimental desktop integration. krita-3.0.99.91-Beta-x86_64.appimage You can also get Krita from Ubuntu’s App Store in snap format. This version includes the translations for Krita itself. Install with snap install --beta krita OSX and MacOS Krita on OSX will be fully supported with version 3.1. Krita 3.0 for OSX is still missing Instant Preview and High Quality Canvas scaling. There are also some issues with rendering the image — these issues follow from Apple’s decision to drop support for the OpenGL 3.0 compatibility profile in their display drivers and issue with touchpad and tablet support. We are working to reimplement these features using OpenGL 3.0 Core profile. For now, we recommend disabling OpenGL when using Krita on OSX for production work. Krita for OSX runs on 10.9, 10.10, 10.11 and is reported to work on MacOS too. krita-3.0.99.91.dmg Source The source tarbal contains all translations. krita-3.0.99.91.tar.gz   [Less]
Posted about 2 hours ago by Kai Uwe Broulik (kbroulik)
In a couple of days Akademy will start and it’s co-hosted with QtCon in Berlin. This will be a super exciting event bringing together not just KDE folks but also enthusiast people from Qt, FSFE, and VideoLAN. I’ll be giving a talk on what it’s like to use Qt to compete on the mobile app development market. See you all soon!
Posted about 2 hours ago by Thomas Pfeiffer (colomar)
It’s finally that time of the year again which many KDE contributors have been looking forward to: The time when we all get together at Akademy, to meet our KDE friends in person, give and listen to talks and make plans for world domination! This ... [More] year is special because Akademy will be part of QtCon, a joint conference with Qt, FSFE, VideoLAN and KDAB, which means even greater opportunities to learn something new, reach an audience beyond KDE, and deepen our alliances! This year, I’ll give three quite different talks: The first one, on Saturday, is titled “Quo Vadis, KDE? – A FOSS Community’s Journey toward its Vision and Mission“. There I will talk, together with Lydia Pintscher, about how the desire to find a direction for KDE lead to the KDE Evolve initiative, which lead to the KDE Vision and Mission initiatives, and beyond. The second one, on Sunday, titled “Meet Kirigami UI – How KDE’s new framework can help to create multi-platform mobile and convergent applications” will be a more product-oriented / technical one. Here, Marco Martin and I present our convergent application framework, Kirigami. I will talk about some design background, whereas Marco will go into technical detail and explain how to set up a project that uses Kirigami. The third talk I’ll be giving (also Sunday), this time together with Jens Reuterberg, is again more on a “meta level”: Under the title “Movements and Products” we will talk about two different mindsets with which contribution to a Free Software community can be approached: A product-focused mindset or a movement-focused mindset. The two are not mutually exclusive, and in fact we’d recommend adopting some of both for a community like KDE to succeed as a movement that creates products. If you can’t be at QtCon or can’t make it to the talks: I assume the pages linked above will have recordings to download at some point. Giving talks is not the only thing I do at Akademy / QtCon, of course. There are also all kinds of BoF sessions to attend: On Monday, I’m planning to be at the Plasma BoF (and especially at the Kirigami-focused part in the afternoon, of course), as well as the “Appstream metadata on software releases” BoF (because I was the one who pushed that topic with Aleix). Tuesday morning will be dedicated to Kube, and where I’ll spend the afternoon mainly depends on whether I’ll be elected into the KDE e.V. board at KDE e.V.’s Annual General Meeting this Thursday. Wednesday morning will be all about Discover. Had I known there were so many important BoFs for me, I’d probably have stayed longer than Wednesday evening, but that wasn’t clear yet at the time I booked my travel, so I’ll have to make as much of the first three BoF days as I can. Aside from all that, there are of course lots of hallway discussions (Akademy is always great for those!) as well as lots of fun to be had! It will be great as always, I’m really looking forward to the second half of this week and the first half of the next one. See you in Berlin!Filed under: KDE [Less]
Posted about 2 hours ago by Boudewijn Rempt (boud)
Last year, I wrote about how library authors should pretty darn well never ever make their users spend time on "porting". Porting is always a waste of time. No matter how important the library author thinks his newly fashionable way of doing stuff ... [More] is, it is never ever as important as the time porting takes away from the application author's real mission: the work on their applications. I care foremost about my users; I expect a library author to care about their users, i.e, people like me. So, today I was surprised by Goodbye, Q_FOREACH by Marc Mutz. (Well known for his quixotic crusade to de-Qt Qt.) Well, fuck. Marc, none, not a single one of all of the reasons you want to deprecate Q_FOREACH is a reason I care even a little bit about. It's going to be deprecated? Well, that's a decision, and a dumb one. It doesn't work on std containers, QVarLengthArray or C arrays? I don't use it on those. It adds 100 bytes of text size? Piffle. It makes it hard to reason about the loop for you? I don't care. What I do care is the 1559 places where we use Q_FOREACH in Krita. Porting this will take weeks. Marc, I hope that you will have a patch ready for us on phabricator soon: you can add it to this project and keep iterating until you've fixed all the bugs. Happy porting, Marc! Come into the real world and learn how well this let's-depracate-and-let-the-poor-shmuck-port-their-code attitude works out. [Less]
Posted about 5 hours ago by KDAB on Qt
Q_FOREACH (or the alternative form, foreach) will be deprecated soon, probably in Qt 5.9. Starting with Qt 5.7, you can use the QT_NO_FOREACH define to make sure that your code does not depend on Q_FOREACH. You may have wondered what all the fuss is ... [More] about. Why is there a continuous stream of commits going to into Qt replacing Q_FOREACH with C++11 ranged for-loops? And why does it take so many commits and several Qt versions to port away from Q_FOREACH? Can’t we just globally search and replace Q_FOREACH (a, b) with for (a : b) and be done with it? Read on for the answers. What is Q_FOREACH? Q_FOREACH is a macro, added for Qt 4, that allows to conveniently iterate over a Qt container: Q_FOREACH(int i, container) doSomethingWith(i); Q_FOREACH(const QString &s : functionReturningQStringList()) doSomethingWith(s); It basically works by copying the second argument into a variable called QForeachContainer, and then iterating over it. I’m only mentioning this for two reasons: First, you will start seeing that internal QForeachContainer at some point in deprecation warnings (probably starting with Qt 5.9), and, second, yes, you heard correctly, it copies the container. This copying has two effects: First, since the copy taken is essentially const, no detaching happens when iterating, unlike if you use the C++98 or C++11 alternatives: for (QStringList::const_iterator it = container.begin(), end = container.end(); it != end; ++it) doSomethingWith(*it); for (const auto &s : container) doSomethingWith((*it); In both cases the (explicit or implicit) calls to begin() and end() cause a non-const container to detach from shared data, ie. to perform a deep-copy to gain a unique copy of the data. This problem is well-known and there are tools to detect this situation (e.g. Clazy), so I won’t spend more time discussing it. Suffice to say that Q_FOREACH never causes detaches. Except when it does. Q_FOREACH is Convenient^WEvil The second effect of Q_FOREACH taking a copy of the container is that the loop body can freely modify the original container. Here’s a very, very poor implementation that takes advantage of this: Q_FOREACH(const QString &lang, languages) languages += getSynonymsFor(lang); Of course, since Q_FOREACH took a copy, once you perform the first loop iteration, languages will detach from that copy in Q_FOREACH, but this kind of code is safe when using Q_FOREACH, unlike when you use C++11 ranged for-loops: for (const auto &lang : languages) languages += getSynonymsFor(lang); // undefined behaviour if // languages.size() + getSynonymsFor(lang).size() > languages.capacity() So, as we saw, Q_FOREACH is convenient—if you write code. Things look a bit different if you try to understand code that uses Q_FOREACH, because you often can’t tell whether the copy that Q_FOREACH unconditionally takes is actually needed in any particular case, or not. A loop that plain falls apart if the container is modified while iterating is much easier to reason about than a Q_FOREACH loop. And this brings us to porting away from Q_FOREACH. Towards a Q_FOREACH-Free World Things would be pretty simple if you could just globally search and replace Q_FOREACH (a, b) with for (a : b) and be done with it. But alas, it ain’t so easy… We now know that the body of a Q_FOREACH loop is free to modify the container it’s iterating over, and don’t even for a minute think that all cases are so easy to recognize as the example with the languages above. The modification of the container may be several functions deep in the call stack originating from the loop body. So, the first question you need to ask yourself when porting a Q_FOREACH loop is: Does the loop body (directly or indirectly) modify the container iterated over? If the answer is yes, you also need to take a copy and iterate over the copy, but as the nice guy that you are, you will leave a comment telling the future You why that copy is necessary: const auto containerCopy = container; // doSomethingWith() may modify 'container' if .... for (const auto &e : containerCopy) doSomethingWith(e); I should note that in cases where the container modification is restricted to appends, you can avoid the copy (and the detach caused by it) by using an indexed loop: for (auto end = languages.size(), i = 0; i != end; ++i) // important: cache 'languages.size()' languages += getSynonymsFor(languages[i]); Avoiding Detaching If your container is a std:: container or QVarLengthArray, you are done. Arguably, Q_FOREACH should never, ever have been used on such a container, since copying those always copies all elements (deep copy). If your container is a const lvalue or a const rvalue, you are done, too. Const objects don’t detach, not even the Qt containers. If your container is a non-const rvalue, simply store it in an automatic const variable, and iterate over that: const auto strings = functionReturningQStringList(); for (const QString &s : strings) doSomethingWith(s); Last, not least, if your container is a non-const lvalue, you have two choices: Mark the variable const, or, if that doesn’t work, use std::as_const() or qAsConst() (new in Qt 5.7, but easily implemented yourself, if required) to cast to const: for (const QString &s : qAsConst(container)) doSomethingWith(s); There, no detaches, no unnecessary copies. Maximum efficiency and maximum readability. Conclusion Here’s why you’ll want to port away from Q_FOREACH, ideally to C++11 ranged for-loops: Q_FOREACH is going to be deprecated soon. It only works efficiently on (some) Qt containers; it performs prohibitively expensive on all std containers, QVarLengthArray, and doesn’t work at all for C arrays. Even where it works as advertised, it typically costs ~100 bytes of text size more per loop than the C++11 ranged for-loop. Its unconditionally taking a copy of the container makes it hard to reason about the loop. Happy porting! The post Goodbye, Q_FOREACH appeared first on KDAB. [Less]
Posted about 8 hours ago by Jos Poortvliet
Now that Nextcloud 9 is out, many users are already interested in migration so I'd like to address the why and how in this blog post.Edit: Nextcloud 10 is out with loads of unique features. We now also have a client! You can find out about client ... [More] account migration here.Why migrateLet's start with the why. First, you don't have to migrate yet. This release as well as at least the upcoming releases of own- and Nextcloud will be compatible so you'll be able to migrate between them in the future. We don't want to break compatibility if we can avoid it!Of course, right now Nextcloud 9 has some extra features and fixes and future releases will introduce other capabilities. With regards to security, we have Lukas Reschke working for us. However, we promise that for the foreseeable future we will continue to report all security issues we find to upstream in advance of any release we do. That means well ahead of our usual public disclosure policy, so security doesn't have to be a reason for people to move.Edit: Nextcloud 10 comes with far more features on top of this. For Nextcloud 11 we have a ambitious road map already but we'll still enable migration from ownCloud 9.1 to Nextcloud 11 so you can migrate at your leisure!Migration overviewIf you've decided to migrate there are a number of steps to go through: Make sure you have everything set up properly and do a backup Move the old ownCloud install, preserving data and config Extract Nextcloud, correct permissions and put back data and config Switch data and config Trigger the update via command line or the web UI Note that we don't offer packages. This has been just too problematic in the past and while we might offer some for enterprise distributions, we hope to work together with distributions to create packages for Nextcloud 9 and newer releases. Once that is done we will of course link to those on our installation page.There are other great resources besides this blog, especially this awesome post on our forums which gives a great and even more detailed overview of a migration with an Ubuntu/NGINX/PHP7/MariaDB setup.Edit: With regard to packages, there are now packages for CentOS and Fedora and other distributions will likely follow soon. See our packages repository if you want to help!PreparationFirst, let's check if you're set up properly. Make sure: You are on ownCloud 8.2.3 or later Make sure you have all dependencies Your favorite apps are compatible (with ownCloud 9), you can check this by visiting the app store at apps.owncloud.com You made a backup Once that's all done, time to move to the next step: cleaning out the old files.Removing old filesIn this step, we'll move the existing installation preserving the data and configuration. Put your server in maintenance mode. Go to the folder ownCloud is installed in and execute sudo -u www-data php occ maintenance:mode --on (www-data has to be your HTTP user). You can also edit your config.php file and changing 'maintenance' => false, to 'maintenance' => true,. Now move the data and config folder out of the way. Best to go to your webserver folder (something like /var/www/htdocs/ and do a mv owncloud owncloud-backup Deploying NextcloudNow, we will put Nextcloud in place. Grab Nextcloud from our download page or use wget: wget https://download.nextcloud.com/server/releases/nextcloud-9.0.50.zip Optional: you can verify if the download went correct using our MD5 code, see this page. Run md5sum nextcloud-9.0.50.zip. The output has to match this value: 5ae47c800d1f9889bd5f0075b6dbb3ba Now extract Nextcloud: unzip nextcloud-9.0.50.zip or tar -xvf nextcloud-9.0.50.tar.bz2 Put the config.php file in the right spot: cp owncloud-backup/config/config.php nextcloud/config/config.php Now change the ownership of the files to that of your webserver, for example chown wwwrun:www * -R or chown www-data * If you keep your data/ directory in your owncloud/ directory, copy it to your new nextcloud/ [*]. If you keep it outside of owncloud/ then you don't need to do anything as its location is in config.php. * Note that if you have been upgrading your server from before ownCloud 6.0 there is a risk that moving the data directory causes issues. It is best to keep the folder with Nextcloud named 'owncloud'. This also avoids having to change all kinds of settings on the server, so it might be a wise choice in any case: rename the nextcloud folder to owncloud.Now upgrade!Next up is restarting the webserver and upgrading. Restart your webserver. How depends on your distribution. For example, rcapache2 restart on openSUSE, service restart apache2 on Ubuntu. You can now trigger the update either via OCC or via web. Command line is the most reliable solution. Run it as sudo -u apache php occ upgrade from the nextcloud folder. This has to run as the user of your webserver and thus can also be www-data or www for example. Then, finally, turn of maintenance mode: sudo -u www-data php occ maintenance:mode --off That's it!At this point, you'll see the fresh blue of a Nextcloud server! If you encounter any issues with upgrading, discuss them on our forums. [Less]
Posted about 9 hours ago by Jan Grulich (jgrulich)
This year I’m giving a bit technical talk called “Bring NetworkManager support to your Qt applications” where I would like to share with you possibilities of NetworkManagerQt framework. I also host a BoF on Monday about Flatpak, where I plan to ... [More] discuss mostly KDE Flatpak portals so anyone interested in this topic is welcome. Aaaand to be honest, I wrote this blog post just to be able to use the lovely “I’m going to Akademy” banner. See you in Berlin!! [Less]
Posted about 10 hours ago by Krita News
Could you tell us something about yourself? I’m a self-taught Sunday digital painter from Tokyo, Japan. I publish my artworks under my alias Omiya Tou. Sometimes I’m also a FLOSS tester or translator and lately I’ve committed translations for G’MIC. ... [More] Do you paint professionally, as a hobby artist, or both? Currently I paint completely as a hobby for fun and stress-relief. What genre(s) do you work in? I usually do 2D drawings/paintings of manga-styled portraits. Whose work inspires you most — who are your role models as an artist? When I create my artwork I always try to convey the tranquility and warmth of Nihon-ga works such as those by Kaii Higashiyama. Also I have been very much impressed by Yoko Tanji’s versatility in styles. How and when did you get to try digital painting for the first time? In 2002, when I was 14, I did what can be called digital painting for the first time.  I think it was a Final Fantasy fanart. In the initial few years I had created my artworks by digitizing pencil linearts with a scanner shared in the school that I was in, taking back the data to my house with floppy discs and coloring them with a mouse and a freeware painting app named Pixia on a Windows XP laptop. What makes you choose digital over traditional painting? It would be that digital media are less time- and space-consuming, easier to revise and enable me to focus on the pure joy of painting, leaving every boring task to the computer. How did you find out about Krita? I did when I was trying out painting apps available in Ubuntu to which I migrated from Windows to run GIMP at its full speed. What was your first impression? When I tried Krita for the first time it was still a sort of tech demo and unsuitable for daily use, but I felt it was worth keeping track of — and actually I’ve been excited seeing how much it has improved since then. What do you love about Krita? There are quite a lot of things, but I especially love the quick pop-up palette, numerous drawing assistants, well-tuned preset brushes, and the hyper-energetic dev team. What do you think needs improvement in Krita? Is there anything that really annoys you? For me Krita is just awesome lately, but if I must say something I think it will be nice if the color curves dialog window is resizeable and the measure tool remains visible when another tool is active. What sets Krita apart from the other tools that you use? Canvas tilting/flipping, GPU acceleration and CMYK capability. If you had to pick one favourite of all your work done in Krita so far, what would it be, and why? I’d pick this because I like the sense of depth and atmosphere: What techniques and brushes did you use in it? I colored this by overlaying a solid blue-gray layer which is set to color dodge mode onto a grayscale image. A lot of this is painted using a brush named Bristles_hairy, definitely one of my favorites. Where can people see more of your work? I cross-post my works onto deviantART, Tumblr and Flickr. Anything else you’d like to share? On my Flickr page I post my artworks under a CC-BY license in their full resolution, so please feel free to use them. Thank you! [Less]
Posted 1 day ago by Daniel Vrátil (dvratil)
If you want to know what we did in KDE PIM in the last year and what we are planning to do and achieve in the next one come to my KDE PIM Status Report talk on Sunday at 1 PM. If you want to get into more technical details and discussions about KDE PIM there will also be a KDE PIM BoF session on Monday afternoon. See you in Berlin!  
Posted 1 day ago by Bhushan Shah (bshah)
QtCon starts on this Sept 1st and I will be traveling to Berlin on this Tuesday. This is second Akademy I am attending after Akademy 2014 in Czech Republic. During QtCon I am giving presentation titled Plasma Mobile: what we achieved in year in ... [More] room A04 on 2nd September. And also I am going to moderate a Student Presentations where students taking part in various mentoring programs in KDE, like GSoC, GCI, SoK, or OPW. Also I am taking part in various BoFs starting from Sept 5, like Plasma BoF, KDE SoC, and KDE Neon BoF. Looking forward to productive QtCon! See you in Berlin! :-) [Less]