Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE - http://planetKDE.org/
Updated: 6 hours 2 min ago

Interview with Julius Grels

Monday 16th of September 2019 08:00:25 AM
Could you tell us something about yourself?

Sure. I’m Julius Grels, and “I like to call myself an artist whenever I’m wasted enough”. In all seriousness though, I think I’d describe myself more as a self-taught caricaturist or illustrator. I usually like to take some existing premise from real life or history, e.g. painting a picture of a (famous) person, depicting wildlife, et cetera. I’m also very fond of making comics, music and video games whenever I have the time (if only?).

Do you paint professionally, as a hobby artist, or both?

I’m most definitely a hobbyist, since I haven’t done any professional commissions (apart from some miniscule design work in the past), and what I do for living right now isn’t even remotely connected to art! That said, I’d most certainly would love to work as an illustrator, comic artist, or anything alike! My biggest wish would be to illustrate (and/or write) a children’s book someday.

What genre(s) do you work in?

I’m most comfortable when doing caricatures and comics; in the latter I can also infuse my story-telling abilities, the little there are. I prefer to illustrate living things; people, animals and nature itself. I’m not exactly keen on drawing in-animate objects, though I’m learning to force myself out of this comfort zone. I like to keep things simple and clean, or at least I try my best not to get lost in time-consuming detailing. Guess that’s one argument I can use as to why I prefer using simple black background on most of my works…

Whose work inspires you most — who are your role models as an artist?

I mostly draw (clever, eh?) influence and inspiration from animation, comics and video game art. I’m hesitant to drop any names because I don’t really have role models per se, and I tend to find pretty much any artist’s work interesting and inspiring. I guess as a Finn I could mention Tove Jansson and Mauri Kunnas. Jansson is of course famous for creating the Moomins, but she was also an accomplished artist and writer in her own right. Kunnas is a well-loved artist best known for his children’s books – pretty much every child in Finland has read at least one of his stories. In my opinion he’s also one of the greatest illustrators this country has to offer.

In addition to the aforementioned, I basically inhaled Franco-Belgian comics as a child; I loved reading Astérix, Lucky Luke, Iznogoud and the rest, so artists like Uderzo, Tabary and Tardi have also had a huge influence on me. Whenever possible, I browse through concept art of different video games. Video games are an interesting subject anyway because they not only combine art, design and technology but have to make all three work together even-handedly to create an enjoyable interactive experience.

 

How and when did you get to try digital painting for the first time?

If we don’t count MS Paint doodles, I think my first real try at digital painting was at elementary school somewhere around the late 90’s where we were introduced to Paint Shop Pro as a part of some “build your own website” -course. We were only able to use mouse for drawing, which was extremely clunky and made me think the whole idea of drawing and painting with a computer was just insane; I’d rather stick to my pencils and brushes, thank you very much. It wasn’t until later when I realised there are equipment specifically made for digital artwork, and once I got my hands on a Wacom tablet, I was sold.

What makes you choose digital over traditional painting?

Nothing? I mean, they are completely different working methods, and I still paint traditionally. Nevertheless, I’ve started to slowly leer towards digital painting, since it’s much easier to control your work and you can experiment more without the fear of ruining something irreversibly (especially when it comes to inking comics and other drawings). While it’s arguable whether digital painting is more cost-efficient than traditional methods in the long run, I think it’s at least less painful to start working with; you only need to set up your computer and programs ready, while with traditional painting you need to take out easel, canvas, gesso, colours, brushes, pencils? you get the idea. Furthermore, in my case where I don’t have a separate studio I have to find and clear a space in my apartment to set all that stuff up. Hassle, hassle!

How did you find out about Krita?

At one point I started to search for open source alternatives for the myriad number of programs I was using, and Krita was a recommendation somewhere to replace Photoshop, with high ratings from users.

What was your first impression?

I guess I’m still languishing in my first impression, because I haven’t been able to use Krita as much as I have wanted. In any case, my very first impression upon opening the program was a relieved “this looks familiar” sigh, and it was incredibly easy to start using Krita from there on.

What do you love about Krita?

Like I mentioned above, I find the interface very easy to use. I also love the fact the community is so alive, and you can find answers to just about any dilemma. All in all, Krita is a magnificent tool for making 2d artwork.

What do you think needs improvement in Krita? Is there anything that really annoys you?

Majority of my problems with Krita are due to the fact I’ve yet to learn most of its nuances, so I can’t really say about improvements that much. Krita seems to be quite a memory-hog, which can cause lot of lag and freezing especially when working with bigger canvases. That, and I’m not too happy with the text tool/editor either and prefer not to use it at all. It’s the one thing in Krita that’s needlessly complicated in my opinion.

What sets Krita apart from the other tools that you use?

Krita is the only digital painting software I use. Being open source is probably what makes it stand out the most. I use other open source programs as well, e.g. Blender, OpenToonz and Aseprite, but they obviously aren’t that much similar to Krita?

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

Not much to choose from, but nevertheless, I’d say Megantereon, which was my first serious Krita artwork that I actually managed to finish. The main reason why I like it so much is simply because I had no initial planning; I took my Wacom, opened Krita and started doodling “something tiger-like”. After an hour or so, I began to realise there might be more to it, and continued working. The first version had plain fur, simplistic ear and lifeless green eye. I published it on deviantart.com, but wasn’t happy with the result, and later on decided to tweak the cat a bit. The fur got more detailed with stripes and spots, and I completely overhauled both the ear and the eye. The final result is what you see here, and I quickly replaced my previous attempt with this better version. I also like Megantereon as it neatly represents my interests (wildlife, history) and my preferred style (stylized, semi-realistic).

What techniques and brushes did you use in it?

Every brush I used is a Krita default. I used Basic and Fill Circle for outlining and some detail, Bristle Texture and Square for texturing and Inkpens for smaller detailing. There might be some Smudge tool I used too, but I honestly can’t remember.
I made a rough outlining on one layer against a black background and constructed the beast from bones to muscles to fur et cetera from there on. In the end I had laid out 23 layers with such genius descriptions as “skull”, “Layer 17”, “BLOOD SALIVA”, “hideTheBeard” and “washing”. In retrospect, I highly recommend people to use layers more scarcely if possible – they slow down the program, and the whole working process ends up confusing. At least name your layers better than I did!
I have two versions of the final work; with and without Noise Effect, which I used to achieve a more horror-esque vibe. I send the noiseless version here so the details aren’t obstructed too much.

Where can people see more of your work?

At the moment, my most recent work will be published at https://www.deviantart.com/jgrels . Don’t hold your breath, though; I publish work at a snail’s pace. You can also follow me on Twitter @JuliusGrels if you so desire, where I’m giving more information about my possible future projects, like a couple of webcomics I’ve planned to do.

Anything else you’d like to share?

Maybe just some general advice to any aspiring artist: never stop honing your skills, get out of your comfort zone, don’t fear experimenting, and most importantly; have confidence. Believe in yourself. Even if you don’t think you’re that great of an artist but love doing art, just keep working and publishing your work for everyone to see. You can doubt your talent, but never doubt your passion.

Finally, I want to send my thanks to the Krita Foundation and give my highest appreciation for the great work you’ve done. Thank you!

New webpage for Plasma Desktop

Monday 16th of September 2019 07:35:35 AM

In my quest to improve the website of KDE, I updated the Plasma Desktop webpage. This is a huge improvement to the old website, which didn’t show any screenshots and didn’t list any Plasma features.

I already teased the improvements I made in the Plasma BoF in Milan to the Akademy.

The redesign got a lot of positive feedback by the Plasma team and after some small modifications the changes landed.

The webpage looks like this now:

Thanks to all the people from the Promo team and vinz who helped me write the text and give me some ideas.

Improving the KDE websites: Junior Jobs

If you want to help improving the web presence of KDE, I regularly add some Junior Job to this Phabricator Workboard. Lots of things need to be updated, so don’t hesitate to propose other changes in the kde-www mailing list.

Discussion: Reddit or Mastodon

Qt Quick on Vulkan, Metal, and Direct3D

Monday 16th of September 2019 06:00:00 AM

Now that the first beta of Qt 5.14 is getting closer, it is time to start talking about one of the big new features. We cannot possibly cover all the details around the graphics stack improvements and the road to Qt 6 in one post, so in part 1 and 2 we will describe the background and take a closer look at what 5.14 will ship with, and then dive into the technical details and future directions in another set of posts later on.

This week in KDE

Sunday 15th of September 2019 01:03:17 PM

See, I told you I’d continue to blog about the cool things that have happened in KDE-land.

On that subject… Kate is now available for free on the Microsoft Store! So far the ratings are quite good. KDE has always aspired to make our apps available to as many users as possible, and getting them on today’s distribution platforms continues that.

For those of you who switched from Windows or macOS, think back to how helpful it was that a bunch of your favorite apps (Firefox, Chrome, VLC, LibreOffice, Inkscape, Blender, Krita, etc) were already available on Linux and you already knew how to use them. Getting more of our apps on other platforms is a key part of easing the transition for future generations of switchers.

Beyond that, it’s been a somewhat light week because everybody was off at Akademy planning the future. A lot of really great things got discussed and decided, the results of which should start to trickle into subsequent weeks’ blog posts. So stay tuned!

New Features Bugfixes & Performance Improvements User Interface Improvements How You Can Help

This is a new section I’m adding to these weekly blog posts, highlighting a new way to get involved every week!

Do you have any web design experience? KDE community members are currently working on redoing the ancient and inconsistent assortment of websites hosted on kde.org, and help is needed! If this sounds like your cup of tea, join the kde-www mailing list and check out the tasks on the Phabricator Workboard.

You can also check out https://community.kde.org/Get_Involved, and find out other ways to help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

Finally, consider making a tax-deductible donation to the KDE e.V. foundation.

KDE Akademy 2019 Recap

Sunday 15th of September 2019 09:45:00 AM

After eight densely packed days Akademy 2019 is over. As always it was very nice to meet everyone again, as well as to meet some people I have been working with online for the first time in real life.

CC-BY Photo by Paul Brown Talks

There was some interesting feedback for my talks, and overlap with work of others:

  • Secure HTTP usage (slides) - my suggestion to encapsulate secure defaults for QNetworkAccessManager (QNAM) in a KF5 class that isn’t bound by as strict backward compatibility requirements as QNAM itself is didn’t seem popular with the Qt community, and started a discussion to instead fix this in QNAM itself, at least for Qt 6. That’s of course the even better solution.
  • KPublicTransport (slides) - I mentioned the lack of public transport data coverage especially in India and Asia, which resulted in Bhushan digging up a few Indian GTFS feeds that can probably be added to Navitia to fix that.
  • KDE Frameworks on Android (slides) - There’s some overlap with the needs of the Kirogi drone control app that Eike presented, regarding Android support in existing frameworks as well as further things like embedding an interactive map. So even more reasons to address this all properly on the KF5 level.
Akademy Awards

The yearly Akademy awards ceremony provided a very unexpected surprise as I was given this year’s Jury Award. Thanks to David for the nice words, and to everyone for signing the award :)

Akademy Jury Award 2019 Meetings/BoFs

Monday to Friday saw a large number of meetings on a wide range of topics, the BoF wrap-up session videos (Monday, Tuesday, Wednesday/Thursday) provide a good overview on those. The below are my key takeaways from some of the sessions I participated in.

KDE Frameworks 6 (KF6)

With Qt 6 on the horizon we need to start looking into what we want to achieve with KF6, beyond just porting to Qt 6 and cleaning up obsolete/deprecated API. We now have a Phabricator workboard to collect and discuss plans and tasks around that, and hopefully we’ll have a sprint in the not too distant future to plan this in more detail. If you have issues with or wishes for KDE Frameworks that might require breaking API or ABI, or otherwise require more invasive changes such as moving functionality between libraries, now is the time to bring this up.

More details: David’s summary

PIM

The most important goal for me here was to get some more collaboration between the Plasma Mobile team and the currently desktop-focused PIM team going, and it looks like we made progress there :)

The move of KContacts and KCalendarCore to KDE Frameworks also got its final go and should be executed next week. The next module to look at is the KDAV protocol library, which ties in with reviewing the KF5 HTTP stack.

More details: Notes, Dan’s KAccounts integration demo

Creating KItinerary Extractor Scripts

I hosted a session on how to create custom extractors for KItinerary in which we looked at the kinds of data we can encounter, the methods and tools we have available for processing this, as well as on how KItinerary Workbench can help with writing and debugging extractors. As a result there were a few new extractor contributions already.

More details: Slides

KDE Frameworks on Android

Aleix had already addressed my top agenda item before the meeting, the F-Droid repository holding the nightly builds from binary factory is synchronized again correctly and should be distributing continuous updates again.

Other topics included where to put the JNI helpers from KDE Itinerary, and how to improve packaging with androiddeployqt for plug-ins with mandatory dependencies.

More details: Notes

KUserFeedback

With all the policy/legal/procedural questions now hopefully sorted out in form of the Telemetry Policy and the Software Privacy Policy we can finally start to deploy the KUserFeedback telemetry and survey system.

More details: Notes

Hacking

Next to all the meetings and discussions there was of course also some time for more hands-on work. My personal highlight is Kai’s work on KDE Itinerary browser integration, it has come a long way since our initial research on this.

We also managed to collect quite some sample data for improving KDE Itinerary, thanks to everyone who donated their data! Some of the immediate results are Daniele’s work on completing our understanding of the barcodes from Trenitalia, as well as initial support for Renfe tickets thanks to Luca.

Thanks

A big thanks to everyone who made this event possible, the Kennys, the local team and everyone else who helped, as well as the sponsors and the KDE e.V.! Akademy is immensely valuable, the above is just a tiny glimpse into the productivity we achieve when having everyone together for a week, not to mention the massive motivational boost we get out of this.

Back from Akademy 2019 in Milan

Saturday 14th of September 2019 01:05:01 PM

The last week I was in Milan with my wife Aiswarya to attend Akademy 2019, the yearly event of the KDE community. Once again it was a great experience, with lots of interesting conferences and productive BoF sessions (“Birds of a Feather”, a common name for a project meeting during a conference).

On Sunday, we presented our talk “GCompris in Kerala, part 2”. First, Aiswarya told some bits of Free-Software history in Kerala, gave examples of how GCompris is used there, and explained her work to localize the new version of GCompris in Malayalam (the language of this Indian state). Then I made a quick report of what happened in GCompris the last 2 years, and talked about the things to come for our next release.

On Monday, I attended the KDE e.V assembly. On a side note, if you are a KDE contributor, you should probably consider joining KDE e.V. as an active member.

On Tuesday morning, we attended the KDE India BoF, where we discussed why the conf.kde.in conference didn’t happen for 2 years and how we can make sure it will happen next year.

On Tuesday afternoon, we had the GCompris BoF. We discussed about using the KDE Wiki for our documentation instead of self-hosting our own wiki. We also discussed the state of some translations that need to be updated. On that topic, if your language is not yet supported in the latest version of GCompris, maybe you can help us (you can check the translation status on this page). Also during this session, Aiswarya started working on some new options to adapt the speed in some activities to make them usable for people with cognitive or physical difficulties.

On Wednesday morning, we attended the “Wayland user feedback” BoF. I discussed with the plasma team about the biggest issues for using Krita on Wayland, namely tablet support and color management. The team seemed very interested to fix those, so I’ll try to provide useful feedback to help them.

On Wednesday afternoon, it was the “Day trip” to the Lake Como, a great occasion to relax and have fun with old and new friends in a beautiful place.

Congratulations to the team for organizing a great event, and also big thanks to KDE e.V. for providing travel support.

Akademy Report

Friday 13th of September 2019 06:30:00 PM

“Who are you people?”

That’s what the woman selling the ferry tickets at Varenna asked me once she realized I speaked Italian. She was definitely not used to a group of ~80 people wearing a blue badge. Another woman who was selling stuff on the street asked me if we were a school.

It’s been an amazing week and a very productive Akademy. A lot has been discussed and a lot has been decided. On my side, I’ve hosted a Dolphin BoF where we discussed both boring things (e.g. where to send bugzilla notification mails) as well as the awesome new features we are getting into Dolphin. Alexander talked about the status of the KIO Fuse project, while Méven talked about his work on the kioslave for the recently used files.

On the coding side, I wish I could have done more, but I lost a lot of times fighting with Google bureaucracy which was required to create a new API key for KIO GDrive. We need to urgently sort this out because it is blocking a working Google support in Kontact. Despite that, I managed to write a simple PoC of KUserFeedback usage in Dolphin. KUserFeedback is very easy to use if you just want the basic reportings (OS version, Qt version, and so on.). Hopefully it won’t be too hard to also get more interesting information, such as which are the features that our users use the most.

And finally, a big thanks goes to the Akademy team and the local team for the organization of the event. See you next year!

Squish - Test automation tool for our HMI build with Qt

Friday 13th of September 2019 08:47:27 AM

When test engineers hear about test automation the first word that comes to mind is of course Selenium which is the most popular testing library that helps us writing scripts for web applications. There are also ready solutions for mobile apps like Appium, Robotium, Espresso, UI Automator and others. The challenge is when we have some project-specific technologies that are not as easy to automate as web applications. But while using Qt we have some advantage over other non-web applications because there is some ready solution that we can use. 

Akademy was a blast!

Friday 13th of September 2019 12:00:00 AM

I attended my first ever Akademy! The event was held at the University of Milano-Bicocca in Milan, Italy this year. And the experience was splendid. During the 2 day conference, I had the opportunity to talk at the Student Showcase, where all of the SoC students presented their work to the community. There were about 8 students, and everyone gave a good briefing on their project.

My project this summer was with Kdenlive, the open source non linear professional video editor. I proposed to revamp one of the frequently used tools in the editor, called the Titler tool, which is used to create title clips. Title clips are video clips that contain text and/or images that are composited or appended to your video (eg: subtitles). The problem with the titler tool as it is, is that it uses QGraphicsView to describe a title clip and QGraphicsView was deprecated since the release of Qt5. This obviously leads to problems - upstream bugs crawling affecting the functionality of the tool and an overall degradation in the ease of maintenance of the codebase. Moreover, adding new features to the existing code base was no easy task and therefore, a complete revamp was something in sights of the developer community in Kdenlive for a long time now. I proposed to rework on the backend for the period of GSoC replacing the use of XML with QML and use a new rendering backend with QQuickRenderControl, along with a new MLT module to handle the QML frames. I was able to cover most of the proposed work, I seek to continue working on it and finish evolving the titler tool.

The folks from Kdenlive have always been very warm and helpful especially with the whole learning curve (which definitely was steep) and working with the community so far has been great, I’ve learned a lot from the experienced developers in Kdenlive and from the Kdenlive community. I seek to continue working with the Kdenlive team and KDE to continue making Kdenlive a great tool to use and a great community to be a part of.

All in all, Akademy was an unforgettable experience, I met a lot of brilliant people from the KDE community in person and the other SoC students from other parts of the world. I’m extremely thankful to the KDE community for presenting us, students, with such a fine opportunity and a platform to work and talk on our projects. Kudos to the Akademy Team for orchestrating such an event!

Here’s my GSoC Work Report: https://community.kde.org/GSoC/2019/StatusReports/AkhilKGangadharan

Kate in the Windows Store

Thursday 12th of September 2019 04:25:00 PM

Our Windows Store submission succeeded, we are now officially in the store.

Try out how the Kate text editor performs on Windows for your personal workflow.

If you see issues and want to help out, contributions are welcome on our GitLab instance.

Our Windows team is small, any help is very welcome! Thanks again to all the people that made it possible to use Kate nicely on Windows.

Kubuntu Meets at Milan Akademy 2019

Thursday 12th of September 2019 03:42:37 PM

A few Kubuntu Members (and Councillors!) met Thursday before KDE Akademy’s end. We discussed the coming release (will be 19.10) and the upcoming LTS (20.10) – which will be Plasma LTS *and* Qt LTS. This combination will make this LTS super-supported and stable.

We also discussed snaps and when Ubuntu possibly moves to “all snaps all the time” for applications at least. This may be in our future, so it is worth thinking and discussing.

Tobias Fischbach came by the BOF and told us about Limux which is based on Kubuntu. This has been the official computer distribution of Munich for the past few years. Now however, unless the Mayor changes (or changes his mind) the city is moving to Windows again, which will be unfortunate for the City.

Slightly off-topic but relevent is that KDE neon will be moving to 20.04 base soon after release, but they will not stay on the Plasma LTS or Qt LTS. So users who want the very latest in KDE Plasma and applications will continue to have the option of using Neon, while our users, who expect more testing and stability can choose between the LTS for the ultimate in stability and our interim releases for newer Plasma and applications.

Of course we continue to ask for those of our users who want to help the Kubuntu project to volunteer, especially to test. We’ll soon need testers for the upcoming Eoan, which will become 19.10. Drop into the development IRC channel: #kubuntu-devel on freenode, or subscribe to the Kubuntu Development list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

Kate got submitted to the Windows Store

Thursday 12th of September 2019 12:25:00 PM

Since a few years Kate is working well on Windows. You can grab fresh installers since then from our download page.

But the visibility of it was very low for Windows users.

Already last year the plan was made to increase the visibility of KDE applications by getting them into the official Windows Store.

Like always, Akademy is a great chance to get the last bits ironed out and the stuff done!

Now, thanks to the help of Hannah von Reth and others, we finally got Kate submitted to the Windows Store!

The submission still needs to be processed by Microsoft, stay tuned when our nifty editor will really be available there for download!

Thanks to all people that contributed to this!

Qt 5.12.5 Released

Wednesday 11th of September 2019 11:42:54 AM

I am happy to Announce we have released Qt 5.12.5 today.

News from KDE PIM in July/August 2019

Wednesday 11th of September 2019 09:57:58 AM
KDE Project:

Following Volker's last blog on this topic, here are some highlights of the recent work that has been done around Kontact / PIM during this summer. First of all, stats: there were around 1200 commits in the past two months, leading to the new 19.08 release.

KDE Itinerary

You can have a good overview of Volker's work by following this blog.

Kontact

It seems our team was mostly focused on cleaning, fixing and introducing little UI features during summer:

Laurent added folder specific exportation from PIM within its PIM data exporter, contact selection from LDAP servers, refactoring some PIM libraries to new ECM macros and cleaned up deprecated method preparing for a Qt 6 future.
In addition to that some bug fixes got in, most notably adding reminders to new events in KOrganizer, text-to-speech fixes and general KMail behavior corrections.

Reminders to new events in Korganizer:

Choosing a contact from LDAP server :

All of the libraries have been adapted to compile with Qt 5.13 and soonish we should reach 5.14 compilation state.

Volker spent time unifying instant message address storage in vCards to KContacts, KContacts soon to be its own framework. The visual style for inline messages in KMail's message viewer was updated too, following the Breeze style as you can see in the picture.

Visuals for inline message boxes in the mail view :

Sandro Knauß worked on the begining of an implementation for MemoryHole support : the idea is to encrypt the mail header (containing metadata) to enforce even further user privacy. In order to achieve that, they wrote a new interface between MimeTreeParser and MessageViewer so we now can update mail headers for later extraction, stay tune for more deails about that next blog posts. In addition and with the help of Glen Ditchfield they put their effort on making messagelib tests green again!

David Faure ported the all of KDE PIM to D-Bus activation as a way to start applications, which enabled the deprecation of KDBusServiceTrader and maybe in a long term future a refactor to simplify KLauncher.

Akonadi

Dan worked on a better support of PostgreSQL (better handling of table name case sensitivity and the sorting of versioned directories). Akonadi server received some love with a few cleanup and modernization treats, you will have more detail about what Dan cooked in his kitchen in his blog so stay tuned!

Infrastructure

Volker and Laurent made sure all KDE PIM modules would appear correctly under the api.kde.org, to make the KDE PIM codebase easier to follow and discover.

Help us make Kontact even better!

All these efforts to provide good free software to the world would not be possible without our committers, if you want to take part on that feel free to contact us #kontact and #akonadi IRC channels on Freenode, see the below section to get started:
https://community.kde.org/KDE_PIM/Development.

And again, if you are attending Akademy, feel free to come see us !

This is a guest post from Franck Arrecot due to technical issues with his blog.
Thanks Franck for writing up the above!

KStars v3.3.6 is released

Wednesday 11th of September 2019 06:40:33 AM
The KStars team is glad to announce the release for KStars v3.3.6 for Windows, MacOS, and Linux.

This release is packed with many small quality of life improvements and bug fixes.

Intuitive Popup MenuWe cleaned up the popup menu so that mount actions are more intuitive. Took this chance as well to add some lovely Breeze icons to the mix.

We will continue to make mount controls even more accessible, especially to users over VNC.Live Debayering
The KStars Live Video window can now debayer frames in real-time, thereby allowing for color video streams.



FITS Viewer
A few improvements landed in FITS Viewer:

  • Updated Statistics display that can display value for each color channel separately, if present.
  • Faster loading times thanks to a performance patch by Hy Murveit.
Astrometry.net Config and Indexes
Robert Lancaster made huge improvements to the handling of Astrometry.net configuration management and indexes. This should make these features a lot more accessible to a wider pool of users.

You can edit the astrometry.net configuration file directly in KStars. Furthermore, you can easily add/remove folders that that contain the index files. Many users have the indexes files stored in external hard drivers, and with this feature, it is now very easy to add the additional folders so they get utilized by the solver.

This change is accompanied by changes to the index downloader. Now you can check all your collections, and you have the ability to download indexes to a particular folder in your collection. A green index file indicates that the file is available in the system and does not require to be downloaded.Observatory Weather Info
Wolfgang Reissenberger continued his outstanding work in improving the Observatory Module. With this release comes weather data directly displayed in the module. Along with the configurable thresholds for Warning and Alert states, you can rest easily knowing that KStars can take the appropriate actions to protect your observatory from adverse weather conditions.


Meridian Flip
A small quality-of-life improvement to the Meridian Flip value. You can now toggle between Degrees (default) and hours. Many mounts indicate the meridian flip limit in degrees so we opted to make this as default.

Mount Control Motion Reverse
You can now reverse the direction of each axis of motion separately, in case you prefer to controls to behave in the way you expect them to in the Mount Control Panel.
Setting Coordinates Manually
The dialog now opens pre-populated with the currently selected object coordinates. You can easily switch between JNow, J2000, or your own custom Epoch.

Under The Hood
Yuri Chornoivan is the unsung hero of internationalization efforts in KStars. Many volunteers work in KDE internationalization effort and Mr. Chornoivan keeps a vigilant eye on KStars to make sure it remains accessible to the widest audience possibly globally.

Mr. Chornoivan replaced many obsolete functions in KStars with their up-to-date alternatives.


OpenForum Academy Workshop - Exploring Modern Dimensions of Openness

Tuesday 10th of September 2019 06:00:00 PM

The OpenForum Academy held its second 2019 workshop in Brussels this week. OpenForum Academy is a European-based independent think tank which explains the merits of openness in computing to policy makers, industry and communities across Europe. This workshop series aims at being a forum for practitioners, academics and policy makers to collaborate on various topics of openness and freedom. It is organized by OpenForum Europe, enabling it to bridge between the abstract academic world and policy discussions at the European Commissions. We set out to explore focus topics to answer current challenges to openness that the academy will develop insights and recommendations for. These topics will shape the work of OpenForum Academy for the near future.

Krita 4.2.6 released

Tuesday 10th of September 2019 10:55:39 AM

A bit later than expected, because of a regression found during beta testing, we’re releasing Krita 4.2.6. Over 120 people have participated in the beta test survey, so this is something we’ll repeat for the next release.

This release also contains an important workaround for users with an AMD Ryzen 5 3500 CPU. This CPU has a bug in its hardware random generator that caused crashes.

New features:
  • Add new layer from visible to layer right-click context menu.
  • When running Krita for the first time on Windows, Angle is now the default renderer. Note that if you have an NVidia GPU and Krita’s window is transparent, you need to select Angle manually in Krita’s settings; if you have another GPU and you have problems with the canvas not updating, you might need to manually select OpenGL in the same window.

We want to especially thank Karl Ove Hufthammer for his extensive work on polishing the translatable string.

Bugs fixed
  • Allow selection overlay to be reset to default. (BUG:410470)
  • Set date for bundle creation to use ISO-Date. (BUG:410490)
  • Fix freeze with 32bit float tiff by using our own tiff reader for the thumbnails. (BUG:408731)
  • Ensure filter mask button is disabled appropriately depending on whether the filter supports it. (BUG:410374)
  • Enable the small color selector if opengles is available as well (BUG:410602)
  • Fix mixed Zoom, Pan, Rotate on macOS (BUG:410698)
  • Ensure that checkboxes are shown in menus even when using the fusion theme
  • Isolate Layer Crash (BUG:408785)
  • Properly fix font resetting when all the text in the editor removed (BUG:409243)
  • Fix lags in Move Tool when using tablet device (BUG:410838)
  • Fix Shift and Alt modifiers in Outline Selection Tool (BUG:410532)
  • Ensure Convert group to Animated Layer shows text in the toolbar. (BUG:410500)
  • Allow ‘Add Clone Layer’ to Work on Multiple Layers (BUG:373338)
  • Fix saving animated transparency masks created through conversion (BUG:409895)
  • Partially fix the curve change despite ‘Share curve across all settings’ checked (BUG:383909)
  • Try harder to make sure that the swap location is writable
  • Properly handle timezones in bundles
  • Make sure all the settings dialogs pages are always shown in the same order
  • Make the settings dialog fit in low-res screens (BUG:410793)
  • Remove misleading ‘px’ suffix for ‘move amount’ shortcut setting
  • Make string for reasons for image export problems translatable (BUG:406973)
  • Fix crash when creating a bezier curve (BUG:410572)
  • Fix deadlocks in KoShapeManager (BUG:410909, BUG:410572)
  • Fix a deadlock when using broken Wacom drivers on Linux (BUG:410797)
  • Fix absolute brush rotation on rotated canvas (BUG:292726)
  • Fix deadlock when removing reference image (BUG:411212)
  • Fix a deadlock in handling of vector objects (BUG:411365)
  • Fix autosave saving only once (BUG:411631)
Download Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.

Linux

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

OSX

Note: the gmic-qt is not available on OSX.

Source code md5sum

For all downloads:

Key

The Linux appimage and the source .tar.gz and .tar.xz tarballs are signed. You can retrieve the public key over https here: 0x58b9596c722ea3bd.asc. The signatures are here (filenames ending in .sig).

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

KIOFuse – Final Report

Tuesday 10th of September 2019 10:23:50 AM

The GSoC coding period is now over and it is only appropriate that it is discussed what has been achieved and what needs to be done to see KIOFuse officially included in as a KDE project, allowing the 75324 bug report to be finally closed after a whole 15 years! Before I continue, I’d like to thank my mentors, Fabian Vogt (fvogt) and Chinmoy Ranjan Pradhan (chinmoyr) for all their support and advice during the course of GSoC. I’d also like to thank various reviewers of upstream code who quickly reviewed and merged code that I submitted. My previous posts (here and here) have discussed the work accomplished in May/June in detail.

Currently the way KIOFuse works is that I/O is implemented on top of a file-based cache, in particular, on temporary files. Reading and writing occurs on the temp file. Flushing works by calling KIO::put, which sends the data in our cache to the remote side via a TransferJob. However, whilst this is happening, there’s nothing stopping write requests coming in for that same node, which marks the cache as dirty. Once the job is done, we check if the node is dirty. If it is, we start another TransferJob, as it would be incorrect to say that the node is flushed. If this scenario keeps occurring, we’d never reply with a successful flush. A simple solution, which doesn’t guarantee that this scenario doesn’t occur but can decrease its likelihood, is as follows: every time a chunk of data is requested by the TransferJob we check if the node is dirty. If so, if it is less than 85% complete, restart the job, otherwise let it finish. The patch for this can be found here.

Another task was to refresh the attributes of nodes after a while. Currently, the existence of nodes is only checked lazily, i.e. if lookup or readdir are called. For each new node found (or created) the stat struct (the node’s attributes) is filled with the values from KIO::UDSEntry. However, this is only done once and any changes on the remote side are not noticed. One could always refresh the attributes on every lookup but that may be overzealous, and so the solution chosen was to do a KIO::listDirin readdir if it hasn’t been called on that node in the last 30 seconds. The patch for this can be found here.

Another problem that KIOFuse had was that write permission wasn’t checked, we’d just forward the permission bits received from the remote side and if we in fact couldn’t write we’d only know during flush, which is a bit too late. Although we cannot fully guarantee write access, there are steps taken to try and get as close as possible to a guarantee. First we start a KIO::chown job, which changes the owner to ourself. If we can, then we assume that the owner permission bits are valid, and forward them. If KIO::chown isn’t supported we just allow write requests to go through, as there is simply no way we can actually check. If the job fails (i.e. we’re not the owner of the file), then changing the modification time can actually help us; it doesn’t help us if we’re the owner as we can change the modification time independent of our write permission. If we can change it, then we can write, if KIO::setModificationTime isn’t supported, we just allow write requests to go through. The patch for this can be found here.

As mentioned previously, file I/O is implemented on top of a file-based cache. Data on the remote side is transferred via the help of KIO::get and KIO::put. Some slaves support KIO::open, in particular sftp/smb/file, which means that it is possible to engage in seek-based file I/O. This means that we do not need to use a file-based cache for those slaves, and can simply read and write directly from and to the remote side. This obviously introduces a bit more latency, but also means that we can easily handle large files, such as videos. The biggest issue with getting this implemented is that the documentation on the how to implement KIO::open correctly and its assorted functions consists of one-liners. This means that each slave author has their own idea of what it means to read/write/seek. The solution to this was to study what all three slaves did, and converge on one definition of what we mean by the different functions provided by the FileJob interface. In addition several bugs were squashed. The most surprising of which was the close signal never being emitted; a big sign that no one has used this API properly since its inception in 2006! Issues in the smb/sftp slaves and the mtp slaves were also fixed. The above mentioned patches have all been merged meaning that KIOFuse now requires KF5 Frameworks 5.62 (and kio-extras 19.08.1). The patch that allows KIOFuse to take advantage of KIO::open can be found here.

The main benefit of KIOFuse is obviously integration into KIO itself. The idea is to create a KIOFuse KDED module loaded at startup, which starts the kio-fuse process. On the KIO side, every time we wish to send a KIO URL to an app that we identify as not supporting the given URL, a DBus request is sent to our KDED module, which mounts the URL and sends back the local path of the URL. We then pass it to the application. The beauty of this is that the conversion is transparent and requires no setup from the user; it also induces no slowdown to KIO-enabled applications. In fact, many people won’t even be able to tell that they’re using KIOFuse, non-KDE apps will seamlessly access the KIOFuse path instead of KIO URLs they don’t understand. The patch for the KDED module can be found here, and the patch in KIO that uses that KDED module can be found here.

So, what’s required for KIOFuse to be production ready? Firstly, some of the linked MRs have not been merged, which just requires a bit of time to get it reviewed and in. Secondly, there are still some bugs that need resolving. GDrive files which don’t have a size (usually GDoc files) get corrupted on read (and potentially write), this issue has been looked at but I’ve not yet found a resolution. MTP doesn’t seem to work at all for some reason. Whether this is an issue in the MTP slave or KIOFuse has not been determined, which is making it harder to resolve this issue. Another thorny issue is that conversion from a local path to a remote URL is a bit buggy. This should be resolvable, but it needs to time to get it right. Ideally, we’d like more testing on all slaves. One potential cool way of testing KIOFuse is using fio, which performs several intensive tests, usually for kernel file systems; this is something we definitely should explore. There is also the question of how KIOFuse will be included in KDE, for example, will it be a framework?

Note that I’m at Akademy, so feel free to ask any questions about it either there or on this blog.

More control over warnings for and visibility of deprecated library API via generated export macro header

Monday 9th of September 2019 05:10:30 PM

Or: More preparation for the autumn of version 5 of KDE Frameworks

Consumer and producer interest in legacy in a library API

During the development life-time of a library in a API-compatible major version, quite some part of its API can be found to be insufficient and thus be deprecated in favour of API additions that serve the purpose better. And the producers of the library want to make the consumers of the library aware about those changes, both to make the investment into the improved API pay out for the consumers as well as prepare them for the future removal of the old API. As a deprecation note in the API documentation or release notes might be missed for existing consumer software, the compiler is pulled into the game using deprecation attributes on the API symbols, so developers looking at the build log have a chance to automatically be pointed to use of deprecated API in their software.
Next, once the chance for dropping the legacy parts of an API arrives on a change to a new major version, again having the compiler support pointing out that part is easier then grepping over the codebase for potentially pattern-less informal notes in code comments or the documentation.

At the same time consumers of a library might be well aware about API deprecations. But they might want to support a range of released versions of the library, using a single code base without variants for the different library versions. They might have more important issues to solve than deprecated API and want to get rid of any deprecation warnings at all. Or they want to ensure that no new uses of deprecated API is added.
Others consumers again might want to use custom builds of the library with all the implementation for deprecated API dropped, at least until a certain version, to save size when bundling the library product.

KDE Frameworks: … TODO

KDE Frameworks, the continuation of the “kdelibs” bundle of libraries, but with emphasis on modularization, is now at API-compatible major version 5. Yet one can find legacy API already deprecated in version 3 times, but done so only as comment in the API dox, without support by the compiler. And while lots of API is also properly marked as deprecated to the compiler, the consumer has no KDE Frameworks specific option to control the warnings and visibility. While some “*_NO_DEPRECATED” macros are used, they are not consistently used and usually only for deprecations done at version 5.0.

As you surely are aware, currently the foundations of the next generation of Qt, version 6, are sketched, and with the end of 2020 there even exists a rough date planned for its initial release. Given the API breakage then happening the same can also be expected for the libraries part of KDE Frameworks. And which would be a good time to also get rid of any legacy cruft.

New: ECMGenerateExportHeader, enabling more control about deprecated API

A proposed new addition to KDE’s Extra CMake Modules (ECM) should allow to improve the situation with KDE Frameworks, but also other libraries: ECMGenerateExportHeader (review request).

It would generate an extended export macro definition header which also includes macros to control which parts of the deprecated are warned about, are visible to the compiler for library consumers or included in the build of the library at all. The macros would be inspired by similar macros introduced with Qt 5.13, so the mind model can be transferred.
(Inspired, but not a plain copy, as e.g. the name “QT_DISABLE_DEPRECATED_BEFORE” is a bit misleading, as the macro is specified to work as “before and including”, so the proposed inspired name uses “*_DISABLE_DEPRECATED_BEFORE_AND_AT”.)

More elaborated example usage would be like this (note the difference between FOO_BUILD_DEPRECATED_SINCE and OO_ENABLE_DEPRECATED_SINCE, see documentation for explanation):

CMakeLists.txt:

include(ECMGenerateExportHeader) set(EXCLUDE_DEPRECATED_BEFORE_AND_AT 0 CACHE STRING "Control what part of deprecated API is excluded from build [default=0].") ecm_generate_export_header(foo VERSION ${FOO_VERSION} EXCLUDE_DEPRECATED_BEFORE_AND_AT ${EXCLUDE_DEPRECATED_BEFORE_AND_AT} DEPRECATION_VERSIONS 5.0 5.12 )

Installed header foo.hpp:

#include <foo_export.h> enum Bars { One, #if FOO_BUILD_DEPRECATED_SINCE(5, 0) Two, #endif Three, }; #if FOO_ENABLE_DEPRECATED_SINCE(5, 0) /** * @deprecated Since 5.0 */ FOO_DEPRECATED_VERSION(5, 0) void doFoo(); #endif #if FOO_ENABLE_DEPRECATED_SINCE(5, 12) /** * @deprecated Since 5.12 */ FOO_DEPRECATED_VERSION(5, 12) FOO_EXPORT void doBar(); #endif class Foo { #if FOO_BUILD_DEPRECATED_SINCE(5, 12) /** * @deprecated Since 5.12 */ FOO_DEPRECATED_VERSION(5, 12) virtual void doFoo(); #endif

Source file foo.cpp:

#include "foo.hpp" #if FOO_BUILD_DEPRECATED_SINCE(5, 0) void doFoo() { // [...] } #endif #if FOO_BUILD_DEPRECATED_SINCE(5, 12) void doBar() { // [...] } #endif #if FOO_BUILD_DEPRECATED_SINCE(5, 12) void Foo::doFoo() { // [...] } #endif Other, better approaches?

The author is not aware of other approaches currently, but would be happy to learn about, to compare, improve, or even discard in favour of another the proposed approach.

Please also have a look at the documentation for the proposed CMake macro ECMGenerateExportHeader (review request) and tell your thoughts.

For this macro being applied, see a patch for KCoreAddons and a patch for KService.

Kate Planning

Monday 9th of September 2019 03:44:00 PM
The Opportunity

During Akademy 2019 here in Milan, Dominik and me had time to sit together and discuss a bit what we shall do to evolve Kate :)

Whereas Kate already works well as a general purpose editor, the competition in the text editor space got more intense in the last years.

Beside the well established stuff like GNU Emacs & Vim, new editor projects got started that did set the bar higher on what users expect from a advanced GUI text editor.

For example Sublime, Atom and Visual Studio Code are things to keep an eye on feature & polishing wise.

Therefore we decided it would make sense to think a bit about which stuff should be improved or altered in the near future.

The Rough Ideas Kate Plugin Interfaces

From the KDE 4.x Kate to the KF5 based Kate version, we removed the Kate specific plugin interfaces and went with more generic interfaces in KTextEditor.

The idea was to be able to share more plugins e.g. between Kate and KDevelop. This idea never really did take off, at the moment just two of our plugins are shared at all…

On the other side, this makes it much harder to expose new functionality to our plugins, as we need to stay binary compatible.

Moving back to having some Kate only stuff that has not even installed headers but is just usable for the plugins we bundle in our kate.git will make it again more flexible what to expose.

One can still think about moving “proven in practice” parts back to the KTextEditor interface part.

Make Projects a Core-Feature

At the moment the projects feature is located in a plugin.

For exposure of some things like the current project files some evil Qt property hacks are used.

By moving this feature into the Kate core we can use a sane way to search in project, list project stuff in quick open, …

Other state of the art editors provide that per default, too

Still stuff like “shall we create projects on the fly” can be deactivated like today

LSP Support per default

We shall get the LSP support in a shape that it can be shipped enabled per default.

Users expect that modern editors provide advanced language integration off the shelf, like Atom, Visual Studio Code, …

Great code navigation

We shall provide the user with better code navigation.

We will provide the plugins with an interface to register location jumps.

This will enable the user to seamlessly jump back and forth for any kind of location change e.g. due declaration lookup or search in files match lookup, …

Consolidate the plugins

The new LSP plugin shall subsume stuff like the Rust or D specific code completion plugins.

Think about the future of unmaintained plugins!

External Tools Plugin

Revive the external tools in a improved way, e.g. like in Qt Creator.

Improve Port to KSyntaxHighlighting

Porting the highlighting over to KSyntaxHighlighting was a big success.

Kate and Qt Creator now finally share the same highlighting engine and we got a lot of new contributions to our highlightings. (we support now over 300 different languages, something to be proud of)

Still, e.g. the theme support is still not moved over to what the new framework provides.

Further Brainstorming Git Integration

We shall take a look what other editors provide.

Diff/Patch Viewer

Want we to integrate with stuff like KDiff3/Kompare/… to have a better handling of e.g. git diff, patches, …?

Improve View Management

Try to improve the way we handle splitting the views and the tabbing.

Take a look how other editors do that!

KDevelop vs. Kate?

Given already today we enter the area of KDevelop by providing the LSP client, we need to think about what happens in the future with overlapping features.

It is no goal to evolve Kate into an IDE.

We think Kate shall be a competitor for editors like Atom, not for full-fledged IDEs like KDevelop or Visual Studio.

Still, e.g. in the area of project management/code navigation/version control support there will be some overlap.

The question is: can we share stuff there? What shall be the focus of Kate and KDevelop in e.g. language support?

I think here it will be interesting which future direction the KDevelop project will take.

Discussion

If you want to chime in on this, feel free to join the discussion at the KDE reddit.

If you want to contribute, just join us at invent.kde.org or on kwrite-devel@kde.org.

More in Tux Machines

Announcing the release of LTTng 2.11

We're happy to announce the release of LTTng 2.11 "Lafontaine". This is a combined release announcement for the 2.11.0 - "Lafontaine" release of the LTTng Tools, LTTng UST, and LTTng modules projects. This release is named after a modern Saison beer from Montréal's Oshlag microbrewery. It is a refreshing, zesty, rice beer with hints of fruit and spices. Some even say it makes for a great Somaek when mixed with Chamisul Soju, not that we've tried! Lafontaine is also a tongue-in-cheek reference to a water leak that affected EfficiOS's offices during the development of this release. Read more Also: LTTng 2.11.0 "Lafontaine" released

Top 20 Best Openbox Themes for Linux System in 2019

Have you ever heard about the stacking window manager, Openbox? It is broadly used in Unix-like systems. Most probably, it’s among the most customizable parts out there. You can easily modify and beautify this with a little bit of effort. The question may arise- with what and how can you do this? Well! We are going to disclose it now. It’s by Openbox themes, which lets you have a minimalist and fantastic visual interface for your desktop manager. Read more

Fedora IoT Review

With the rise in IoT use, we are witnessing a demand for ready-made operating systems to support smart device development. Currently, the race is between proprietary versions such as IoT Plug and Play by Microsoft and open source operating systems. One such emerging open source player is Fedora which has a workstation that supports virtualization and containers. Fedora is also slated to release an Internet of Things edition called “Fedora IoT” in future. Here is a review of the open source product’s support capabilities for IoT and relevant installation details. Read more

5 Practical Examples of the Read Command in Linux

With read command, you can make your bash script interactive by accepting user inputs. Learn to use the read command in Linux with these practical examples. Read more