22 Aug 2019

feedPlanet KDE

Day 88

Today, I'll talk about my GSoC experience and won't focus so much on Khipu, but in the next days I'll publish a post about Khipu and what I've done.

As I said in the old posts, the begin was the most complicated part for me. I made a project thinking that I'd be able to complete, I started studying the code and the things I'd make many weeks before the start. But I couldn't understand the code and I think it's my fault. I even lost three weeks after the start stuck in this situation. It was hard for me, because I was really scared about failing and at the same time dealing with my college stuff, because in Brazil, our summer (and our summer vacation), is in December-February, in July we have a three week vacation, but GSoC lasts three months. I wasn't having a good time at college as well, but with the help of my mentors I found a way to deal with the both things and as everything went well.

After this complicated start, to not fail, my mentor suggested that I could change my project. My initial project was to create new features to Khipu and Analitza (Khipu's main library) to make it a better application and move it out from beta. Then, my new project was to refactor Khipu (using C++ and QML). I was scared because I didn't know if I'd be able to complete it, but the simplicity of QML helped me a lot, and before the first evaluation (approx. two weeks after I decided my new project) I finished the interface, or at least most of it.

During the second period, in the start, I slowed down my code activities because I was in the end of my college semester and I had to focus on my final tests. But after this, I started to work in the backend and learned about models, connections between C++ and QML, and the most important: I improved my programming skills. I needed to learn to build a real program, and not making small patches as I used to do in my open source contributions history. In the end of this period, the screen was already working and showing 2D and 3D spaces and plotting functions.

So here I am, in the end of the third and last period writing about this experience. In this period, I worked in the program buttons and options, created dialogs, improved the readability of my code, documented my functions and files, and the technical stuff that I'll explain in the next post.
This period is being nice, because I gained so much maturity, not only for coding, but to my life. I feel I'm able to fix the bugs that still are there and to deal with new situations in my professional and even in my personal life.

This post has the purpose to share my experience to the students that will participate on the next years. So I'd like to give two advices based on my experience:
1- don't freak out, ask for help. The time that you lose scared and nervous, use it to think rationally on what you can do to solve that problem.
2- make a weekly activities schedule, it maybe will sound obvious, but after I started doing it, my productivity increased a lot, because is easier to control how much time I'm working and allocate time to my other activities.
And, of course, I'd like to say to KDE, Google and my mentors: thanks for this opportunity.

22 Aug 2019 3:00am GMT

21 Aug 2019

feedPlanet KDE

LabPlot's Welcome screen and Dataset feature in the finish line

Hello Everyone! This year's GSoC is coming to its end. Therefore I think that I should let you know what's been done since my last blog post. I would also like to evaluate the progress I managed to make and the goals set up at the beginning of this project.

As I told you in my last post, my main goal, in this last period, was to clean up, properly document, refactor, optimise the code and make it easier to read, so it would be fit to be brought to the master branch and to be used by the community.

My next proposition was to search for bugs and fix them, in order to make the implemented features more or less flawless. I can happily state, that I succeeded in this.

As proposed, I implemented a unit test for the main dataset related features. This proved to be useful since it helped discover some hidden problems which were all corrected. The main features, that tests were developed for, are:
I managed to create some "real" example projects so the users can explore the possibilities provided by LabPlot. These include the already existing ones (3 by count) and I added some dataset related ones. I also proceeded with the collecting of datasets. I managed to double the previous amount. Now we have 2000 datasets categorized, which is already a considerable amount.

As I said, the main priority was to improve and correct the code and not to develop major new features. However, some minor new ideas were still implemented. The first step was to improve the downloading and naming of the datasets. I also developed some caching mechanism for the downloaded files. When downloading a file, if an earlier copy is available it needs to be checked whether or not it was created earlier than 1 day. If it was, then the file needs to be deleted in order to proceed with the downloading, otherwise the downloading isn't necessary.

Another, more observable, feature is that the users can now easily display the full name and the description of the selected dataset, so they may be able to retrieve additional information before choosing a dataset to work with. Previously the users could also see the short name of the dataset which wasn't really practical since it didn't really offer much information about the dataset itself. I also added a counter to every collection, category and subcategory so now the users can see how many datasets belong to the previously listed units of categorization. I thought it might be useful. The following demo video will present these new features in use:

Show Details functionality of ImportDatasetWidget

I also created a backup functionality for ImportDatasetWidget. When the users press the "Refresh" button the metadata files "shipped with LabPlot" are copied to the "dataset folder", and the files which were previously there are kept as a backup. This was needed because by pressing refresh any newly added dataset disappears. This can be very unpleasant if done unintentionally, I speak out of experience. So by pressing the "Restore" button the effect of the "Refresh" button can be undone, meaning that the current metadata files are deleted, the backup files are restored and the widget is updated accordingly. The following video illustrates this functionality:

Restore backup functionality of ImportDatasetWidget

As I've already presented you the improvements and new features, I think it's high time I present to you an overall image of what has been accomplished during this summer's GSoC. I will present the new features in two groups: dataset related and welcome screen related. I will provide a demo video for each of them.

I'd like to start with the welcome screen since that will be the first thing people will see when they start using LabPlot. I think that the welcome screen turned out to be quite good looking, clean and simple (in the best possible meaning). It is quite responsive and by allowing the users to resize the different sections, it is customisable to a degree. I think it provides a great deal of functionality that can be useful for the great majority of the users, and it also helps in the process of getting to know LabPlot. In the next demo video I will present every aspect of LabPlot's welcome screen:

LabPlot's welcome screen

The other main part of the project was to implement functionality to import online datasets. This could be useful for those who like working with data or in the field of statistics. These datasets can be visualized by creating different plots: curves and histograms. This way LabPlot may be used for educational purposes as well. LabPlot comes with a great number of datasets which may be expanded individually by adding own datasets. I really hope that the users will find this new functionality useful and practical. Here is a video that demonstrates adding a new dataset and creating some plots based on it:

LabPlot's Dataset Functionality

And finally here comes the evaluation/summary. I truly think that every feature presented in my proposal is implemented and working. So I think the main aim is met: LabPlot now has full support for downloading and processing online datasets and has a gorgeous welcome screen. There were difficulties along the way, but with work, and help from my mentors, everything was dealt with. As I said everything works, but some unforeseen bugs or errors might appear in the future. Some steps for the future may be to improve the overall performance of the new features and improving the overall look of the welcome screen.

Working on this project for the last 3 months has been a great experience, and I can honestly say that I improved my coding skills and way of thinking in a way I haven't even dreamt for. I also improved my ability to work alone and solve problems on my own. I'm more than grateful to my mentor, Kristóf, who always helped me and had my back if I encountered any hardship. I'd also like to express my gratitude towards Alexander Semke, my mentor's former mentor and an invaluable member of the LabPlot team, who also helped me a great deal. I am determined to further improve the features, even after GSoC ended. I would be more than happy to stay in this amazing team and help them whenever they need me. It's my goal to work, in the future, on LabPlot with them, since I really liked being part of this team. I truly think that people should contribute more to the open-source community, and the end of GSoC shouldn't mean the end of the involvement as well.

This is it, guys. Thank you for reading the post, and thank you for your interest in my project. If there's any development regarding my project or a new task (in the future) I'll let you know here. Bye :)

21 Aug 2019 3:12pm GMT

Distributed Beta Testing Platforms

Do they exist? Especially as free software? I don't actually know, but I've never seen a free software project use something like what I've got in mind.

That would be: a website where we could add any number of test scenarios.

People who wanted to help would get an account, make a profile with their hardware and OS listed. And then a couple of weeks before we make a release, we'd release a beta, and the beta testers would login and get randomly one of the test scenarios to test and report on. We'd match the tests to OS and hardware, and for some tests, probably try to get the test executed by multiple testers.

Frequent participation would lead to badges or something playful like that, they would be able to browse tests, add comments and interact - and we, as developers, we'd get feedback. So many tests executed, so many reported failure or regressions, and we'd be able to improve before the release.

It would be a crowd-sourced alternative to something like Squish (which I've never found to be very useful, not for Krita, not at the companies where it was used), it would make beta testers not just feel useful, it would make beta testing useful. Of course, maintaining the test scripts would also take time.

It sounds simple to me, and kind of logical and useful, but given that nobody is doing this - does such a thing exist?

21 Aug 2019 10:10am GMT

20 Aug 2019

feedPlanet KDE

Shubham (shubham)

Third month progress

Hello visitors!! I am here presenting you with my final month GSoC project report. I will be providing the links to my work at the end of the section.
Final month of the work period was much more hectic and tiring than the first couple of months. I had been busy more than I had anticipated. Nonetheless, I had to write code which I enjoyed writing : ) . In the first half of this work period, I was focused on completing the left-over QDBus communication from the phase 2, which I did successfully. But as when I thought my task was all over, I was faced with some regression in the code, which I utilised my rest half a month to fix it. I will talk about it later in the post. Coming to the progress made during this period, I have done the following:
Complete left-over QDBus communication from Phase 2:
During the first 2 months of the work period, I have completed the rest of the QDBus communication from Helper to Application. This was pretty easy to do, just had to follow the same as done by the Application when it contacts the helper. Earlier, it was QDBus which was used from Application towards Helper and KAuth from Helper towards Application. Now it is QDBus both ways.

Tried kick starting the helper:

As I had said above in the intro, I was faced with some real difficulty during the second half of the work period. As soon as I finished up QDBus thing, a regression was caused (Which I should have noticed before, my bad), helper was no longer started by the main application. I spent rest of the days brain-storming the issue but due to shortage of time, could not fix it. I plan to try fixing it in the next few days before GSoC ends(26th August), if I successfully do that, I will update the status here as well .

Things yet to work:

There are couple of things which are yet to work before we reach complete independence from KAuth:
1. Helper as a standalone application not able to start from the main application
2. Scanning issue: This is an issue in which after successfully authenticating, KDE Partition Manager is stuck on the scanning window. I believe this issue is directly related to the one mentioned above, but can't say for sure.

The above mentioned issues are obstacles in between achieving a KAuth free KDE Partition Manager.

Plans after GSoC:

I plan to complete the left over parts and issues after the GSoC ends. I look forward to contributing to KPM and KPMCore in future as well.


Links to my patches:
1. QDBus communication from Helper towards Application:
Link to cgit repository:

20 Aug 2019 6:46pm GMT

KDE's Onboarding Sprint: Making it easier to setup a development environment

The Megasprint Between the 19th and 23rd of July 2019, around 20 KDE contributors met in Nuremberg, Germany, to work on 3 different projects, in what turned out to be a KDE Megasprint: KDE Connect, the amazing application that intuitively connects and integrates your mobile and desktop devices KWin, Plasma Desktop's powerful window manager Streamlined Onboarding Goal, focused on making it easy to setup a development environment. There were so many KDE people around, split in teams, discussing and working on a variety of projects, that at times this felt like a mini conference and not a sprint!

20 Aug 2019 12:00am GMT

19 Aug 2019

feedPlanet KDE

KMyMoney 5.0.6 released

The KMyMoney development team today announces the immediate availability of version 5.0.6 of its open source Personal Finance Manager.

Another maintenance release is ready: KMyMoney 5.0.6 comes with some important bugfixes. As usual, problems have been reported by our users and the development team fixed some of them in the meantime. The result of this effort is the brand new KMyMoney 5.0.6 release.

Despite even more testing we understand that some bugs may have slipped past our best efforts. If you find one of them, please forgive us, and be sure to report it, either to the mailing list or on bugs.kde.org.

From here, we will continue to fix reported bugs, and working to add many requested additions and enhancements, as well as further improving performance.

Please feel free to visit our overview page of the CI builds at https://kmymoney.org/build.php and maybe try out the lastest and greatest by using a daily crafted AppImage version build from the stable branch.

The details

Here is the list of the bugs which have been fixed. A list of all changes between v5.0.5 and v5.0.6 can be found in the ChangeLog.

Here is the list of the enhancements which have been added:

19 Aug 2019 7:48pm GMT

Kontact and Google Integration Issues

Lately there were some issues with the Google integration in Kontact which caused that it is no longer possible to add new Google Calendar or Gmail account in Kontact because the log in process will fail. This is due to an oversight on our side which lead to Google blocking Kontact as it did not comply with Google's policies. We are working on resolving the situation, but it will take a little bit.

Existing users should not be affected by this - if you already had Google Calendar or Gmail set up in Kontact, the sync should continue to work. It is only new accounts that cannot be created.

In case of Gmail the problem can mostly be worked around when setting up the IMAP account in KMail by selecting PLAIN authentication1 method in the Advanced tab and using your email and password. You may need to enable Less Secure Applications in your Google account settings in order to be able to log in with regular email address and password.

If you are interested in the technical background of this issue, the problem comes from Google's OAuth App Verification process. When a developer wants to connect their app to a Google service they have to select which particular services their app needs access to, and sometimes even which data within each service they want to access. Google will then verify that the app is not trying to access any other data or that it is not misusing the data it has access to - this serves to protect Google users as they might sometimes approve apps that will access their calendars or emails with malicious intent without them realizing that.

When I registered Kontact I forgot to list some of the data points that Kontact needs access to. Google has noticed this after a while and asked us to clarify the missing bits. Unfortunately I wasn't able to react within the given time limit and so Google has preemptively blocked login for all new users.

I'm working on clarifying the missing bits and having Google review the new information, so hopefuly the Google login should start working again soon.

  1. Despite its name, the PLAIN authentication method does not weaken the security. Your email and password are still sent safely encrypted over the internet.

19 Aug 2019 6:53pm GMT

Qt Visual Studio Tools 2.4 RC Released

We have released Qt Visual Studio Tools 2.4 RC (version 2.4.0); the installation package is available in the Qt download page. This version features an improved integration of Qt tools with the Visual Studio project system, addressing some limitations of the current integration methods, most notably the inability to have different Qt settings for each project configuration, and lack of support for importing those settings from shared property sheets.

Using Qt with the Visual Studio Project System

The Visual Studio Project System is widely used as the build system of choice for C++ projects in VS. Under the hood, MSBuild provides the project file format and build framework. The Qt VS Tools make use of the extensibility of MSBuild to provide design-time and build-time integration of Qt in VS projects - toward the end of the post we have a closer look at how that integration works and what changed in the new release.

Up to this point, the Qt VS Tools extension managed its own project settings in an isolated manner. This approach prevented the integration of Qt in Visual Studio to fully benefit from the features of VS projects and MSBuild. Significantly, it was not possible to have Qt settings vary according to the build configuration (e.g. having a different list of selected Qt modules for different configurations), including Qt itself: only one version/build of Qt could be selected and would apply to all configurations, a significant drawback in the case of multi-platform projects.

Another important limitation that users of the Qt VS Tools have reported is the lack of support for importing Qt-related settings from shared property sheet files. This feature allows settings in VS projects to be shared within a team or organization, thus providing a single source for that information. Up to now, this was not possible to do with settings managed by the Qt VS Tools.

To overcome these and other related limitations, all Qt settings - such as the version of Qt, which modules are to be used or the path to the generated sources - will now be stored as fully fledged project properties. The current Qt Settings dialog will be removed and replaced by a Qt Settings property page. It will thus be possible to set the values of all Qt settings according to configuration, as well as import those values from property sheet files.

A closer look

An oversimplified primer might describe MSBuild as follows:

Properties may apply to the project itself or to a specific file in the project, and can be defined globally or locally:

The Qt Visual Studio Tools extension integrates with the MSBuild project system by providing a set of Qt-specific targets that describe how to process files (e.g. a moc header) with the appropriate Qt tools.

The current integration has some limitations, with respect to the capabilities of the MSBuild project system:

As discussed above, the solution for these limitations has been to make Qt settings fully fledged project properties. In this way, Qt settings will be guaranteed in-sync with all other properties in the project, and have the possibility of being defined differently for each build configuration. It will be possible to import Qt settings from property sheets, and the property page of Qt tools that generate C++ code, like moc, will now allow overriding compiler properties in generated files.

The post Qt Visual Studio Tools 2.4 RC Released appeared first on Qt Blog.

19 Aug 2019 5:17pm GMT

Interview with Chayse Goodall

Could you tell us something about yourself?

Hi, my name is Chayse Goodall. I am 14 years old. I just draw for fun!

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

I do animate and draw for a hobby. My artwork improves little by little, but I don't think it'll be good enough for a profession!

What genre(s) do you work in?

I don't know what my style is, but people tell me that I have an anime style.

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

I have many inspirers, two of which was my art teachers, and one of which was my math tutor. They both motivate me to keep going with my progress.

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

I tried digital art in 2015. I only had a phone at the time, so it was hard at first. It's a million times better now, and I have a touch screen computer, so I've been trying different art programs!

What makes you choose digital over traditional painting?

There are more tools, and there is an undo button!

How did you find out about Krita?

I was looking up free art programs, and stumbled across this program.

What was your first impression?

My experience was great! It was easy to follow once you get the hang of it!

What do you love about Krita?

All the brushes and how easy it is to save.

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

It is a bit confusing and it looks complex to newcomers.

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

It has amazing features and it doesn't require me to "sign up" or pay for anything!

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

I only made one picture. She doesn't have a name, she was just a test character to see how good the program was. (It came out great!)

What techniques and brushes did you use in it?

I normally draw the sketch first in a dark red color. Then I draw the plain body in a light green. I sketch the clothes, hair, and accessories on in a neon color.

I just use the pen for coloring and shading.

Where can people see more of your work?

My instagram- panstables
My youtube- Nubbins

19 Aug 2019 8:00am GMT

18 Aug 2019

feedPlanet KDE

KDE sprints in summer heat

End of June I attended the annual Plasma sprint that was this year held in Valencia in conjunction with the Usability sprint. And in July we organised on short notice a KWin sprint in Nuremberg directly following up on the KDE Connect sprint. Let me talk you through some of the highlights and what I concentrated on at these sprints.

Plasma sprint in Valencia

It was great to see many new faces at the Plasma sprint. Most of these new contributors were working on the Plasma and KDE Apps Ui and Ux and we definitely need some new blood in these areas. KDE's Visual Design Group, the VDG, thinned out over the last two years because some leading figures left. But now seeing new talented and motivated people joining as designers and Ux experts I am optimistic that there will be a revival of the golden time of the VDG that brought us Breeze and Plasma 5.

In regards to technical topics there is always a wide field of different challenges and technologies to combine at a Plasma sprint. From my side I wanted to discuss current topics in KWin but of course not everyone at the sprint is directly working on KWin and some topics require deeper technical knowledge about it. Still there were some fruitful discussions, of course in particular with David, who was the second KWin core contributor present besides me.

As a direct product of the sprint my work on dma-buf support in KWin and KWayland can be counted. I started work on that at the sprint mostly because it was a feature requested already for quite a long time by Plasma Mobile developers who need it on some of their devices to get them to work. But this should in general improve in our Wayland session the performance and energy consumption on many devices. Like always such larger features need time so I was not able to finish them at the sprint. But last week I landed them.

Megasprint in Nuremberg

At the Plasma sprint we talked about the current state of KWin and what our future goals should be. I wanted to talk about this some more but the KWin core team was sadly not complete at the Plasma sprint. It was Eike's idea to organize a separate sprint just for KWin and I took the next best opportunity to do this: as part of the KDE Connect and the Onboarding sprints in the SUSE offices in Nuremberg just a few weeks later. Jokingly we called the whole endeavor because of the size of three combined sprints the Megasprint.

KDE Connect sprint

I was there one or two days earlier to also attend the KDE Connect sprint. This was a good idea because the KDE Connect team needs us to provide some additional functionality in our Wayland session.

The first feature they rely on is a clipboard management protocol to read out and manipulate the clipboard via connected devices. This is something we want to have in our Wayland session also in general because without it we can not provide a clipboard history in the Plasma applet. And a clipboard selection would be lost as soon as the client providing it is closed. This can be intentionally but in most cases you expect to at least have simple text fragments still available after the source client quit.

The second feature are fake inputs of keyboard and mouse via other KDE Connect linked devices. In particular fake input via keyboard is tricky. My approach would be to implement the protocols developed by Purism for virtual keyboards and input methods. Implementation of these looks straight forward at first, the tricky part comes in when we look at the current internal keyboard input code in KWayland and KWin: there is not yet support for multiple seats or for one set multiple keyboards at the same time. But this is a prerequisite for virtual keyboards if we want to do it right including the support of different layouts on different keyboards.

KWin sprint

After the official begin of the KWin sprint we went through a long list of topics. As this was the first KWin sprint for years or even forever there was a lot to talk about, starting with small code style issues we needed to agree on till large long-time goals on what our development efforts should concentrate in the future. Also we discussed current topics and one of the bigger ones is for sure my compositing rework.

But in the overall picture this again is only one of several areas we need to put work in. In general it can be said that KWin is a great piece of software with many great features and a good performance but its foundations have become old and in some cases rotten over time. Fixes over fixes have been put in one after the other increasing the complexity and decreasing the overall cohesion. This is normal for actively used software and nothing to criticize but I think we are now at a point in the product life cycle of KWin to either phase it out or put in the hours to rework many areas from the ground up.

I want to put in the hours but on the other side in light of possible regressions with such large changes the question arises if this should be done dissociated with normal KWin releases. There was not yet a decision taken on that.

Upcoming conferences

While the season of sprints for this year is over now there are some important conferences I will attend and if you can manage I invite you to join these as well. No entry fee! In the second week of September the KDE Akademy is held in Milan, Italy. And in the first week of October the X.Org Developer's Conference (XDC) is held in Montreal, Canada. At XDC I have two talks lined up myself: a full length talk about KWin and a lightning talk about a work-in-progress solution by me for multi DPI scaling in XWayland. And if there is time I would like to hold a third one about my ongoing work on auto-list compositing.

In the beginning I planned only to travel to Canada for XDC but just one week later the WineConf 2019 is held close to Montreal, in Toronto, so I might prolong the stay a bit to see how or if at all I as a compositor developer could help the Wine community in achieving their goals. To my knowledge this would be the first time a KWin developer attends WineConf.

18 Aug 2019 8:00pm GMT

KDE Usability & Productivity: Week 84

Get ready for week 84 in KDE's Usability & Productivity initiative! 84 weeks is a lot of weeks, and in fact the end is in sight for the U&P initiative. I'd say it's been a huge success, but all good things must come to an end to make room for new growth! In fact, KDE community members have submitted many new goals, which the community will be able to vote on soon, with the three winners being unveiled at Akademy next month.

But fear not, for the spirit of the Usability & Productivity initiative has suffused the KDE community, and I expect a lot of really cool U&P related stuff to happen even after the initiative has formally ended-including the long-awaited projects of PolicyKit support and mounted Samba and NFS shares in KIO and Dolphin! These projects are making steady progress and I hope to have them done in the next few months, plugging some longstanding holes in our software.

And finally, I'll be continuing these weekly blog posts for the foreseeable future! It's just too much fun to stop. Anyway, here's what we've got this week:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

If you're getting the sense that KDE's momentum is accelerating, you're right. More and more new people are appearing all the time, and I am constantly blown away by their passion and technical abilities. We are truly blessed by… you! This couldn't happen without the KDE community-both our contributors for making this warp factor 9 level of progress possible, and our users for providing feedback, encouragement, and being the very reason for the project to exist. And of course, the overlap between the two allows for good channels of communication to make sure we're on the right track.

Many of those users will go on to become contributors, just like I did once. In fact, next week, your name could be in this list! Not sure how? Just ask! I've helped mentor a number of new contributors recently and I'd love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can 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!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

18 Aug 2019 6:01am GMT

The Titler Revamp: QML Producer in the making

The previous month's been a ride!

At the beginning of this month, I started testing out the new producer as I had a good, rough structure for the producer code, and was only facing a few minor problems. Initially, I was unclear about how exactly the producer is going to be used by the titler so I took a small step back and spent some time figuring out how kdenlivetitle worked, which is the producer in use.

Initially, I faced integration problems (which are the ones you'd normally expect) when I tried to make use of the QmlRenderer library for rendering and loading QML templates - and most of them were resolved by a simple refactoring of the QmlRenderer library source code. To give an example, the producer traditionally stores the QML template in global variables which is taken as a character pointer argument (which is, again, traditional C) The QmlRenderer lib takes a QUrl as its parameters for loading the Qml file, so to solve this problem all I had to do was to overload the loadQml() method with one which could accommodate the producer's needs - which worked perfectly fine. As a consequence, I also had to compartmentalise (further) the rendering process so now we have 3 methods which go sequentially when we want to render something using the library ( initialiseRenderParams( ) -> prepareRenderer( ) -> renderQml( ) )

(Code: https://github.com/akhilam512/mlt)

At around the beginning of the 2nd week, I resumed testing the producer code. I used melt for this purpose:

melt qml:~/path/to/test.qml

and now, I was faced with a blocker that would keep me for little more than a week - a SEGFAULT

The SIGSEGV signal was from QtOpenGLContext::create( ) -> the method tries to create an OpenGL context for rendering (done while constructing the QmlRenderer class) and the bug was quite weird in itself - initially, I thought it might due to something related to QObject ownership and tried putting a wrapper class (both a wrapper for the renderer class, and a Qt wrapper for the producer wrapper itself - which might sound stupid) around my producer wrapper - and the code still produced a SIGSEV. The next thing I could think of was maybe it is due to OpenGL and I was feeling confident after I found we have had issues with OpenGL context creation and thread management as OpenGL context and OpenGL functions need to be created and called on the same thread

( an excellent reference: https://www.khronos.org/opengl/wiki/Common_Mistakes )

The problem was resolved (thank you JB) finally and it was not due to OpenGL but it was simply because I hadn't created an QApplication for the producer (which is necessary for qt producers). The whole month's been a steep curve, definitely not easy, but, I enjoyed it!

Right now, I have a producer which is, now, almost complete and with a little more tweaking, will be put to use, hopefully. I'm still facing a few minor issues which I hope to resolve soon and get a working producer. Once we get that, I can start work on the Kdenlive side. Let's hope for the best!

18 Aug 2019 4:19am GMT

17 Aug 2019

feedPlanet KDE

KDE Frameworks 5.61, Applications 19.08 in FreeBSD

The KDE community's large software product releases - Frameworks, Plasma, and Applications - come down the turnpike with distressing regularity. Like clockwork, some might say. We all know Plasma is all about clocks.

Screenshot of About dialogs

Recent releases were KDE Frameworks 5.61 and KDE Applications 19.08. These have both landed in the official FreeBSD ports tree, after Tobias did most of the work and I pushed the big red button.

Your FreeBSD machine will need to be following current ports - not the quarterly release branches, since we don't backport to those.

All the modern bits have arrived, maintaining the KDE-FreeBSD team's commitment to up-to-date software for the FreeBSD desktop. The one thing we're currently lagging on is Qt 5.13. There's a FreeBSD problem report tracking that update.

Updating from previous

As usual, pkg upgrade should do all the work and get you a fully updated FreeBSD desktop system with KDE Plasma and the whole bit.

I ran into one issue though, related to the simultaneous upgrade of Akonadi and MySQL. I ended up in a situation where Akonadi wouldn't start because it needed to update the database, and MySQL wouldn't start because it couldn't load the database tables.

Since Akonadi functions as a cache to my IMAP server and local maildirs, and I don't keep any Akonadi-style metadata anywhere, my solution was to move the "old" akonadi dirs aside, and just let it get on with it: that means re-downloading and indexing a lot of mail. For people with truly gigantic collections, this may not be acceptable, so I'm going to suggest, without actually having tried it:

I haven't seen anyone else in the KDE-FreeBSD support channels mentioning this issue, so it may be an unusual situation.

Missing functionality

The kio-gdrive port doesn't build. This is an upstream issue, where the API in 19.08 changed but there's no corresponding kio-gdrive release to chase that API. I can see it's fixed in git master, just not released.

All the other bits I use daily (konsole, kate, kmail, falkon) work fine.

17 Aug 2019 10:00pm GMT

ownCloud and CryFS

It is a great idea to encrypt files on client side before uploading them to an ownCloud server if that one is not running in controlled environment, or if one just wants to act defensive and minimize risk.

Some people think it is a great idea to include the functionality in the sync client.

I don't agree because it combines two very complex topics into one code base and makes the code difficult to maintain. The risk is high to end up with a kind of code base which nobody is able to maintain properly any more. So let's better avoid that for ownCloud and look for alternatives.

A good way is to use a so called encrypted overlay filesystem and let ownCloud sync the encrypted files. The downside is that you can not use the encrypted files in the web interface because it can not decrypt the files easily. To me, that is not overly important because I want to sync files between different clients, which probably is the most common usecase.

Encrypted overlay filesystems put the encrypted data in one directory called the cipher directory. A decrypted representation of the data is mounted to a different directory, in which the user works.

That is easy to setup and use, and also in principle good to use with file sync software like ownCloud because it does not store the files in one huge container file that needs to be synced if one bit changes as other solutions do.

To use it, the cypher directory must be configured as local sync dir of the client. If a file is changed in the mounted dir, the overlay file system changes the crypto files in the cypher dir. These are synced by the ownCloud client.

One of the solutions I tried is CryFS. It works nicely in general, but is unfortunately very slow together with ownCloud sync.

The reason for that is that CryFS is chunking all files in the cypher dir into 16 kB blocks, which are spread over a set of directories. It is very beneficial because file names and sizes are not reconstructable in the cypher dir, but it hits on one of the weak sides of the ownCloud sync. ownCloud is traditionally a bit slow with many small files spread over many directories. That shows dramatically in a test with CryFS: Adding eleven new files with a overall size of around 45 MB to a CryFS filesystem directory makes the ownCloud client upload for 6:30 minutes.

Adding another four files with a total size of a bit over 1MB results in an upload of 130 files and directories, with an overall size of 1.1 MB.

A typical change use case like changing an existing office text document locally is not that bad. CryFS splits a 8,2 kB big LibreOffice text doc into three 16 kB files in three directories here. When one word gets inserted, CryFS needs to create three new dirs in the cypher dir and uploads four new 16 kB blocks.

My personal conclusion: CryFS is an interesting project. It has a nice integration in the KDE desktop with Plasma Vault. Splitting files into equal sized blocks is good because it does not allow to guess data based on names and sizes. However, for syncing with ownCloud, it is not the best partner.

If there is a way how to improve the situation, I would be eager to learn. Maybe the size of the blocks can be expanded, or the number of directories limited?
Also the upcoming ownCloud sync client version 2.6.0 again has optimizations in the discovery and propagation of changes, I am sure that improves the situation.

Let's see what other alternatives can be found.

17 Aug 2019 8:30pm GMT

Magnetic Lasso for Krita is here

I won't say that I am done with Magnetic Lasso now, but the results are a lot better now to be honest. Take a look at one of the tests that I did,

17 Aug 2019 10:57am GMT

15 Aug 2019

feedPlanet KDE

Kdenlive 19.08 released

After a well deserved summer break, the Kdenlive community is happy to announce the first major release after the code refactoring. This version comes with a big amount of fixes and nifty new features which will lay the groundwork for the 3 point editing system planned for this cycle. The Project Bin received improvements to the icon view mode and new features were added like the ability to seek while hovering over clips with the mouse cursor and now it is possible to add a whole folder hierarchy. On the usability front the a menu option was added to reset the Kdenlive config file and now you can search for effects from all tabs instead of only the selected tab. Head to our download page for AppImage and Windows packages.

Highlights

3 point editing with keyboard shortcuts

With 19.08.0 we added groundwork for full editing with keyboard shortcuts. This will speed up the edit work and you can do editing steps which are not possible or not as quick and easy with the mouse. Working with keyboard shortcuts in 19.08 is different as in the former Kdenlive versions. Mouse operations have not changed and working as before.

3 important points to understand the new concept:

Source (left image):
On the left of the track head the green vertical lines (V1 or A2). The green line is connected to the source clip in the project bin. Only when a clip is selected in the project bin the green line show up depending of the type of the clip (A/V clip, picture/title/color clip, audio clip).

Target (right image):
In the track head the target V1 or A1 is active when it's yellow. An active target track react to edit operations like insert a clip even if the source is not active (see "Example of advanced edit" here).

The concept is like thinking of connectors:
Connect the source (the clip in the project bin) to a target (a track in the timeline). Only when both connectors on the same track are switched on the clip "flow" from the project bin to the timeline. Be aware: Active target tracks without connected source react on edit operations.

You can find a more detailed introduction in our Toolbox section here.

Adjust AV clips independently with Shift + resize to resize only audio or video part of a clip. Meta/Windows-key + Move in timeline allows to move the audio or video part to another track independently.

Press shift while hovering over clips in the Project Bin to seek through them.

Adjust the speed of a clip by pressing CTRL + dragging a clip in the timeline.

Now you can choose the number of channels and sample rates in the audio capture settings.

Other features

  • Added a parameter for steps that allows users to control the separation between keyframes generated by the motion tracker.
  • Re-enable transcode clip functionality.
  • Added a screen selection in the screen grab widget.
  • Add option to sort audio tracks in reverse order.
  • Default fade duration is now configurable from Kdenlive Settings > Misc.
  • Render dialog: add context menu to rendered jobs allowing to add rendered file as a project clip.
  • Renderwidget: Use max number of threads in render.
  • More UI components are translatable.

Full list of commits

  • Do not setToolTip() for the same tooltip twice. Commit.
  • Use translations for asset names in the Undo History. Commit.
  • Fix dropping clip in insert/overwrite mode. Commit.
  • Fix timeline drag in overwrite/edit mode. Commit.
  • Fix freeze deleting a group with clips on locked tracks. Commit.
  • Use the translated effect names for effect stack on the timeline. Commit.
  • Fix crash dragging clip in insert mode. Commit.
  • Use the translated transition names in the 'Properties' header. Commit.
  • Fix freeze and fade ins allowed to go past last frame. Commit.
  • Fix revert clip speed failing. Commit.
  • Fix revert speed clip reloading incorrectly. Commit.
  • Fix copy/paste of clip with negative speed. Commit.
  • Fix issues on clip reload: slideshow clips broken and title duration reset. Commit.
  • Fix slideshow effects disappearing. Commit.
  • Fix track effect keyframes. Commit.
  • Fix track effects don't invalidate timeline preview. Commit.
  • Fix effect presets broken on comma locales, clear preset after resetting effect. Commit.
  • Fix crash in extract zone when no track is active. Commit.
  • Fix reverting clip speed modifies in/out. Commit.
  • Fix audio overlay showing up randomly. Commit.
  • Fix Find clip in bin not always scrolling to correct position. Commit.
  • Fix possible crash changing profile when cache job was running. Commit.
  • Fix editing bin clip does not invalidate timeline preview. Commit.
  • Fix audiobalance (MLT doesn't handle start param as stated). Commit.
  • Fix target track inconsistencies:. Commit.
  • Make the strings in the settings dialog translatable. Commit.
  • Make effect names translatable in menus and in settings panel. Commit.
  • Remember last target track and restore when another clip is selected. Commit.
  • Dont' process insert when no track active, don't move cursor if no clip inserted. Commit.
  • Correctly place timeline toolbar after editing toolbars. Commit.
  • Lift/gamma/gain: make it possible to have finer adjustments with Shift modifier. Commit.
  • Fix MLT effects with float param and no xml description. Commit.
  • Cleanup timeline selection: rubber select works again when starting over a clip. Commit.
  • Attempt to fix Windows build. Commit.
  • Various fixes for icon view: Fix long name breaking layout, fix seeking and subclip zone marker. Commit.
  • Fix some bugs in handling of NVidia HWaccel for proxies and timeline preview. Commit.
  • Add 19.08 screenshot to appdata. Commit.
  • Fix bug preventing sequential names when making serveral script renderings from same project. Commit.
  • Fix compilation with cmake < 3.5. Commit.
  • Fix extract frame retrieving wrong frame when clip fps != project fps. Commit. Fixes bug #409927
  • Don't attempt rendering an empty project. Commit.
  • Fix incorrect source frame size for transform effects. Commit.
  • Improve subclips visual info (display zone over thumbnail), minor cleanup. Commit.
  • Small cleanup of bin preview thumbnails job, automatically fetch 10 thumbs at insert to allow quick preview. Commit.
  • Fix project clips have incorrect length after changing project fps. Commit.
  • Fix inconsistent behavior of advanced timeline operations. Commit.
  • Fix "Find in timeline" option in bin context menu. Commit.
  • Support the new logging category directory with KF 5.59+. Commit.
  • Update active track description. Commit.
  • Use extracted translations to translate asset descriptions. Commit.
  • Fix minor typo. Commit.
  • Make the file filters to be translatable. Commit.
  • Extract messages from transformation XMLs as well. Commit.
  • Don't attempt to create hover preview for non AV clips. Commit.
  • Add Cache job for bin clip preview. Commit.
  • Preliminary implementation of Bin clip hover seeking (using shift+hover). Commit.
  • Translate assets names. Commit.
  • Some improvments to timeline tooltips. Commit.
  • Reintroduce extract clip zone to cut a clip whithout re-encoding. Commit. See bug #408402
  • Fix typo. Commit.
  • Add basic collision check to speed resize. Commit.
  • Bump MLT dependency to 6.16 for 19.08. Commit.
  • Exit grab mode with Escape key. Commit.
  • Improve main item when grabbing. Commit.
  • Minor improvement to clip grabbing. Commit.
  • Fix incorrect development version. Commit.
  • Make all clips in selection show grab status. Commit.
  • Fix "QFSFileEngine::open: No file name specified" warning. Commit.
  • Don't initialize a separate Factory on first start. Commit.
  • Set name for track menu button in timeline toolbar. Commit.
  • Pressing Shift while moving an AV clip allows to move video part track independently of audio part. Commit.
  • Ensure audio encoding do not export video. Commit.
  • Add option to sort audio tracks in reverse order. Commit.
  • Warn and try fixing clips that are in timeline but not in bin. Commit.
  • Try to recover a clip if it's parent id cannot be found in the project bin (use url). Commit. See bug #403867
  • Fix tests. Commit.
  • Default fade duration is now configurable from Kdenlive Settings > Misc. Commit.
  • Minor update for AppImage dependencies. Commit.
  • Change speed clip job: fix overwrite and UI. Commit.
  • Readd proper renaming for change speed clip jobs. Commit.
  • Add whole hierarchy when adding folder. Commit.
  • Fix subclip cannot be renamed. Store them in json and bump document version. Commit.
  • Added audio capture channel & sample rate configuration. Commit.
  • Add screen selection in screen grab widget. Commit.
  • Initial implementation of clip speed change on Ctrl + resize. Commit.
  • Fix FreeBSD compilation. Commit.
  • Render dialog: add context menu to rendered jobs allowing to add rendered file as a project clip. Commit.
  • Ensure automatic compositions are compositing with correct track on project opening. Commit.
  • Fix minor typo. Commit.
  • Add menu option to reset the Kdenlive config file. Commit.
  • Motion tracker: add steps parameter. Patch by Balazs Durakovacs. Commit.
  • Try to make binary-factory mingw happy. Commit.
  • Remove dead code. Commit.
  • Add some missing bits in Appimage build (breeze) and fix some plugins paths. Commit.
  • AppImage: disable OpenCV freetype module. Commit.
  • Docs: Unbreak menus. Commit.
  • Sync Quick Start manual with UserBase. Commit.
  • Fix transcoding crashes caused by old code. Commit.
  • Reenable trancode clip functionality. Commit.
  • Fix broken fadeout. Commit.
  • Small collection of minor improvements. Commit.
  • Search effects from all tabs instead of only the selected tab. Commit.
  • Check whether first project clip matches selected profile by default. Commit.
  • Improve marker tests, add abort testing feature. Commit.
  • Revert "Trying to submit changes through HTTPS". Commit.
  • AppImafe: define EXT_BUILD_DIR for Opencv contrib. Commit.
  • Fix OpenCV build. Commit.
  • AppImage update: do not build MLT inside dependencies so we can have more frequent updates. Commit.
  • If a timeline operation touches a group and a clip in this group is on a track that should not be affected, break the group. Commit.
  • Add tests for unlimited clips resize. Commit.
  • Small fix in tests. Commit.
  • Renderwidget: Use max number of threads in render. Commit.
  • Don't allow resizing while dragging. Fixes #134. Commit.
  • Revert "Revert "Merge branch '1904'"". Commit.
  • Revert "Merge branch '1904'". Commit.
  • Update master appdata version. Commit.

15 Aug 2019 10:05pm GMT