24 Jun 2018

feedPlanet KDE

This week in Usability & Productivity, part 24

After a light week, we're now roaring back with a veritable avalanche of Usability and Productivity! Look at all this cool stuff:

New Features

Bugfixes

UI Polish & Improvement

See all the names of people who worked hard to make the computing world a better place? That could be you next week! Getting involved isn't all that tough, and there's lots of support available. Give it a try today! It's easy and fun and important.

If my efforts to perform, guide, and document this work seem useful and you'd like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

24 Jun 2018 4:44am GMT

23 Jun 2018

feedPlanet KDE

Finally: First stable release of KBibTeX for KDE Frameworks 5

After almost exactly two years of being work-in-progress, the first stable release of KBibTeX for KDE Frameworks 5 has been published! You can grab the sources at your local KDE mirror. Some distributions like ArchLinux already ship binary packages.

( Read more... )

Donate using Liberapay



comment count unavailable comments

23 Jun 2018 7:53pm GMT

Latte Dock, Beta 1 for v0.8 (v0.7.95)


Hello everyone Latte Dock v0.7.95 which is the first beta of v0.8 is here. Latte v0.8 is a huge release and one of its main goals is to make the user feel with it very natural and comfortable.


Plasma 5.12 with Latte v0.7.95 *

"A powerful and intuitive panel/dock manager that provides an elegant Plasma experience"


To use it you should build it yourself from download.kde.org or ask your distro packagers to provide it for you.

Summer came in south Europe and Latte is moving forward. The first beta of an extreme major release is here. Latte has been updated a lot both for internals and user-side. Feel free to join evolution in dock and panel management and report back any issues.

Important for contributors: Beta1 will last 10 days, during these days translators will be able to report string improvements at bugs.kde.org. English isnt my native language, (proof reading / simpler expanations) might be necessary. When Beta2 is released around 3 to 5 July the string freeze will take place. Beta2 period will last 10 more days. So v0.8 is scheduled for 13 to 15 Jully. During all these days improvements and fixes can be landed through review process at kde phabricator.

Dont hesitate, just take part and participate if you feel so. I am the single developer of Latte for a few months now and fully open to discuss new implementations, code improvements and new features.


new layouts editor with locked and borderless layouts

No more talking, what v0.8 brings and why is it so important?


Videos for new features


New Features from v0.7.79 to Beta1
  • Filter Windows by Launchers, show only windows that there is already a launcher present for the current running activity
  • Improve Separators behavior
  • Lock/Unlock Layouts, different layouts can become read-only and writeable
  • Ungroup tasks of the same application
  • Borderless maximized windows per layout, the user can use that setting in order to replicate a Unity-style layout and a Plasma one at the same time.

Landed Features in v0.8

---------
* Wallpaper: https://www.webolution.gr/wp-content/uploads/october-2560x1600.jpg

* Archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E

23 Jun 2018 7:09am GMT

22 Jun 2018

feedPlanet KDE

Musing About Communities Size And Activity

If you remember my previous installment I raised a couple more questions which I pointed out as tougher to address and I'd keep on the side for a while. Well, I decided to look at something simpler in the meantime... which unexpectedly took more time than expected.

First I thought I'd try to reproduce the cohesion graph from Paul's Akademy 2014 talk... but it looks like we have a reproducibility issue on that one. However hard I try I don't manage to reproduce it. What I get is very different, so either there's a bug in my tentative script or there was a bug in Paul's script or somehow the input data is different. So one more mysteries to explore, I'm at a loss about what's going on with that one so far.

Then I realized that already more than a month passed fiddling with that particular issue so I looked for something else. I still wanted something simple. That's why I went for weekly activity and team size for the whole history of some repository. Sure everyone does that, but I looked at how we could make this kind of things more readable to have a better idea of trends. Indeed most of the graphs I look at tend to be noisy. For instance if we look at Thiago's graphs about the Qt community, there's clearly valuable information but the ones covering the history "since the beginning" don't convey much idea about the trends. That's what I'll try to improve in the current installment. Similar data, just a different way to look at it.

The Transparent KDE Community

Let's start with the community closest to home: KDE.

[KDE Until 2018, full page version]


First a note on the production of the graph itself. This is done by looking at all the available history of all the git repositories I could clone from KDE (I'm using kdesrc-build for that). The small dots are the absolute data points sampled per week. Since they (obviously) exhibit quite some noise, I then apply to them a low-pass filter which gives us the final line plots on top of the data points. They give us less accurate absolute value but better clues on the actual trends. Also note that the two curves are on different scales (one on the left the other on the right) so don't get confused about that. Again it's not about comparing absolute values between the curves but trends.

Before really focusing on the data in graph above, a note on the team size. Here we consider the size of the "team" producing commits for a given week. It's not telling us the whole size of the community, it's not even telling us the whole size of the developers community. It just tells us how many developers from the community have been active that particular week. So obviously the community size is larger than that. We have a simple model here, evaluating the community size would require something much more complex about heuristics on when someone can be considered not participating anymore or not. I'll sound like a broken record but this simple model is still relevant for showing trends in the activity level of a community so I'll stick with it for now.

With all of that in mind, it's interesting to see that active part of the community has been steadily growing until around 2010. This is clearly the tipping point and so after 2010 the community started to be less active. My gut feeling is that it's been also shrinking but the graph is no proof of that. At its peak there were around 200 people active each week, now it seems to be around 100 on average (yes I'm rounding aggressively here). The good thing is that from the plots, it seems it stabilized since 2016, but only time will tell if it stays stable or somehow grows again.

Also interesting to note is that the peak and beginning of the shrink is around the same period than the drop in cohesion pointed out by Paul in his Akademy 2014 talk.

So why the shrink? What happened around 2010? The only thing which comes to mind is our change of tooling... it's in fact the only thing which can explain both a reduction in cohesion and in size. Clearly we lost something with the switch to git, existing contributors were perhaps less motivated and newcomers were perhaps not joining as much.

It might sound surprising now that git is a big deal and extremely popular... but at the time it wasn't really a walk in the park. KDE has been an early adopter of git and for people with limited spare time it was yet another thing to learn. Now git is fashionable and learned by most but contributors are not coming back to us, so something is still amiss. Maybe our tooling is still too fragmented? Indeed people are used to very uniform platforms like GitHub or GitLab nowadays with a very organized view on the code and having to deal almost exclusively with git commands and a bit of web interface, we're nowhere near that. Maybe building our projects is still too complicated? Indeed people are used to grabbing the code, running a single build command and have the thing built and ready to run and hack on... we're nowhere near that.

That's why it's important that the onboarding of new contributors is now one of KDE's goals. Hopefully it will make sure that we don't just stabilize as we did now but start to grow again. I'm slightly concerned that it seems to focus mainly on documenting the status quo without necessarily improving the tooling. Don't take me wrong, documenting how to join us is super important! It's just that it needs to be made simpler as well. It's not the same impact on people interested to join to follow a documented process of 100 steps or to follow a documented process of 5 steps.

Now that I rambled about KDE... what about other communities?

The Dual-Licensed Qt

Let's check out on our friends from the Qt project! It's more of an industry type of community, plenty of people paid to contribute, the project is backed by a commercial owner. For that community I looked only at "Qt itself" which is not as easy to define than you would think. I basically went for the two main products: the qt repository (containing the Qt4 history), the qt5 repository and all its sub-modules and the qt-creator repository. That covers fairly well what you get if you install a SDK with only the Free Software components. Note that the history isn't as complete as in the KDE case so it's not going back to before the governance of Qt became open. This means we won't see all the way to Qt creation and it's likely that the beginning of the curves won't be reliable since they won't follow the right commit patterns and show instead big bulks of code in a limited number of commits by a limited number of people.

[Qt Until 2018, full page version]


What a surprise! We can see it is very slowly getting less and less activity over time. Both the number of commits and the number of people active a given week has been stagnating or going down since 2010. Again before 2010 the numbers can't be trusted, but the graph reads as a decrease in activity as soon as the governance got opened. And there's no way to know if that was the trend already before opening the governance, we can't even gauge the correlation there.

Another surprise is the surge on the team size plot around 2012. It created a small surge in commits too but didn't change the overall trend on the commit count. This period would require an investigation of its own to get a clearer picture on its cause. My current theory after checking the "per employer activity" graph done by Thiago is that it seems to correlate both with KDAB getting much more involved in the development and KDE's effort toward KDE Frameworks creation.

As for the overall trend toward less activity, should we start to worry about Qt's health? Well, it depends what you are considering. Qt as a product, I wouldn't worry yet. If we look at absolute number it still clocks around 200 commits with around 50 contributors each weeks. For such a product it doesn't strike me as very low maintenance level. Qt as a community on the other hand... if the numbers are indeed correct (remember how I defined the corpus leading to the history we're looking at: it might have a blind side), I see no way to spin it positively. It is clearly a shrinking community (much like KDE as we've seen above).

Still, there's the Qt Company around they're in business and they seem to try to hire currently. So it's likely that there is a slow shift from the main repositories to other repositories (potentially non public). Not necessarily bad news for the product since it'll likely mean new features getting in down the line, etc. But even though it's not ideal community wise since it's harder to contribute.

The Crazy Multimedia People From VLC

And now what about VLC? It is after all one of the most successful Free Software out there. It's very specialized on its domain though (multimedia) and so as such maybe not showing the same activity profile than others? That's what we're going to look into.

Note that here I'm focusing only on vlc itself, but the VideoLAN Organization do more than just VLC. So please don't compare the plots below to KDE, it's slightly unfair comparison to both. It'd be as if I was plotting only one product from KDE.

Still I was curious about VLC itself since it's the least arcane of the projects from VideoLAN. Also I didn't find the time to produce an extensive and definitive list of the VideoLAN repositories. Something I'd like to do later though to have a more complete picture.

[VLC Until 2018, full page version]


At a glance we can see a very different profile compared to the previous too and as such it was worth producing those plots. It seems to have a very stable community. The trends are clear, since 2003 we got a fairly stable team size and mostly stable commit count. That being said there are two points worth noticing.

First, we can see a five years period between 2007 and 2012 where the commit count is much more of a bumpy ride. Similarly on that period we see more of the community active at the same time then dropping again. It seems to match with a period of new ports of VLC on more platforms and the work leading up toward VLC 2.0. Surprisingly we don't see a similar pattern toward the preparation of VLC 3.0.

Second, despite a mostly stable team size since 2012, we can see a constant increase in commits over time. So it looks like the patch leading up to VLC 3.0 had a different pattern than the one leading up to VLC 2.0. The activity increased but mostly in commits under the roughly the same number of people each weak. That means the turn around of commits per person was higher during that period than before. This is a clear change of pattern since VLC 2.0. My current theory would be that it could be caused by the creation of Videolabs which is a company created in 2012 and employing mostly VLC developers. This company provides services around VLC and multimedia. It is the only event that I know of which would explain that plot. That being said and as mentioned above I have only a partial view of the VideoLAN history here, so take that theory with caution.

The Very Successful Rust

And last but not least, I wanted to take a very quick peak at Rust. It's very different from our previous cases, no application or frameworks in the traditional sense but a language. It seems very popular toward developers using it, I'm personally interested in it hence why it is in that post.

Due to its nature it's even harder to choose a corpus of repositories to define it... Should I take just the compiler? Other tooling? Documentation? Should I try to reach toward the whole ecosystem since it's a language? I decided to go for compiler, tooling and documentation (that is mostly code coming from rust-lang and rust-lang-nursery). It made sense to go for those because they really are an integral part of the "Rust experience" if you look at it as a coherent product. Just the compiler would be clearly too small, and the whole ecosystem would drown us in data which would just tell us how popular Rust is to its users which is not what we're after here.

[Rust Until 2018, full page version]


First word which comes to mind: wow! Indeed, it's very successful and clearly skyrocketing currently. There's just a slowdown in 2015 for which I have no good explanation, maybe people were tired after releasing 1.0? If someone who knows intimately the Rust community has another theory I'm very eager to hear it.

Anyway, apart from 2015, both the team size and the commit count are still correlated and they just go up, and up and up. Clearly they are doing something right and are very successful at attracting contributors to Rust itself. I'd say it's not just a fad with people playing with it and making libraries or apps with it. It looks like they manage to convert users into contributors very successfully. Well done!

Now of course it's a much younger project, so time will only tell when it will plateau and if it starts shrinking again. For now, it's clearly looking similar to the first years of KDE. Maybe the KDE community should look more at Rust and find ideas on how to be so popular again.

22 Jun 2018 5:36pm GMT

KDE on FreeBSD – June 2018

The KDE-FreeBSD team (a half-dozen hardy individuals, with varying backgrounds and varying degrees of involvement depending on how employment is doing) has a status message in the #kde-freebsd channel on freenode. Right now it looks like this:

http://FreeBSD.kde.org | Bleeding edge http://FreeBSD.kde.org/area51.php | Released: Qt 5.10.1, KDE SC 4.14.3, KF5 5.46.0, Applications 18.04.1, Plasma-5.12.5, Kdevelop-5.2.1, Digikam-5.9.0

It's been a while since I wrote about KDE on FreeBSD, what with Calamares and third-party software happening as well. We're better at keeping the IRC topic up-to-date than a lot of other sources of information (e.g. the FreeBSD quarterly reports, or the f.k.o website, which I'll just dash off and update after writing this).

In no particular order:

So we're mostly-up-to-date, and mostly all packaged up and ready to go. Much of my day is spent in VMs packaged by other people, but it's good to have a full KDE developer environment outside of them as well. (PS. Gotta hand it to Tomasz for the amazing application for downloading and displaying a flamingo .. niche usecases FTW)

22 Jun 2018 10:56am GMT

Integrating Cloud Solutions with Qt

These days, using the cloud for predictive maintenance, analytics or feature updates is a de facto standard in the automation space. Basically, any newly designed product has some server communication at its core.

However, the majority of solutions in the field were designed and productized when communication technology was not at today's level. Still, attempts are being made to attach connectivity to such solutions. The mission statement is to "cloudify" an existing solution, which uses some internal protocol or infrastructure.

Let's consider our favorite example in this series, the Sensor Tag demo. Multiple sensors publish their telemetry data to an MQTT broker. If this infrastructure cannot be changed, a cloud-based solution needs to be attached to it, like in the graphic below:

cloud_connector

The first thing we need is a connector, which translates internal protocols and payload-formats into what a cloud solution accepts as valid input.

So, let's create one!

One of the great features in Qt is that you can connect to any cloud solution provider. Whichever you chose, the principles in this post will be the same. We are going to use Microsoft Azure and its IoTHub solution in our example.

The demo contains a topic called "sensors/active". Each active device continuously reports itself as available on this topic. If a connection is interrupted or the device disconnects, a retained message is sent indicating the offline state. This is going to be the entry point for the connector.

Subscribing to that topic is done with QMqttClient::subscribe

m_activeSub = m_client->subscribe(QLatin1String("sensors/active"), 1);


Each time a new client goes online, a new SensorInformation instance is created. The sensor is stored in conjunction with its ID in a map.

[...]
    if (split.at(1) == "Online" && !m_sensors.contains(split.at(0))) {
        const QString subName = QString::fromLocal8Bit("sensors/%1/#").arg(QString::fromUtf8(split.at(0)));
        auto sub = m_client->subscribe(subName, 1);
        if (!sub)
            return;

        auto sensor = new SensorInformation(sub, this);
        connect(sensor, &SensorInformation::publishRequested, m_azure, &AzureConnection::publishMessage);
        m_sensors.insert(split.at(0), sensor);
[...]

Additionally, the SensorInformation stores the subscription and parses the received messages. Periodically (or whenever a single value changes) the device state requests a sync to the cloud via the publishRequested signal.

The IoTHub expects messages to have its payload formatted as JSON. As demonstrated in our previous posts of this series, this is a simple task using Qt, and more specifically, QJsonDocument.

To send messages to Azure, a thin layer around the IoTHub SDK is created to hook into Qt. A minimalistic approach looks like this:

class AzureConnection : public QObject
{
    Q_OBJECT
public:
    AzureConnection();
    ~AzureConnection();

    void init(const QString &connectionString);
    void cleanup();

Q_SIGNALS:
    void messageReceived(const QByteArray &content);
    void messageSent();
    void messageError();

public Q_SLOTS:
    void publishMessage(const QByteArray &content);

private:
    AzureConnectionThread *m_thread;
};

Azure expects each connection to have a unique ID to identify the account, the device and the session. In this example, we expect this string to be known beforehand. An API exists to do device provisioning to Azure, but that is not part of this article.

The initialization is handled via

    if (platform_init() != 0)
        return false;

    m_iotClientHandle = IoTHubClient_LL_CreateFromConnectionString(qPrintable(connectionString), AMQP_Protocol);
    if (m_iotClientHandle == NULL)
        return false;

    IOTHUB_CLIENT_RESULT receiveEvent = IoTHubClient_LL_SetMessageCallback(m_iotClientHandle, ReceiveMessageCallback, this);
    if (receiveEvent != IOTHUB_CLIENT_OK)
        return false;

    return true;

The SDK itself handles everything via callbacks, more specifically the message state. Once a message is sent by calling IoTHubClient_LL_SendEventAsync() the state of the message is handled in a callback. The various options are handled in SendConfirmationCallback()

    EVENT_INSTANCE *eventInstance = (EVENT_INSTANCE *)userContextCallback;
    switch (result) {
    case IOTHUB_CLIENT_CONFIRMATION_OK:
        qDebug() << "ID: " << eventInstance->messageTrackingId << " confirmed";
        break;
    case IOTHUB_CLIENT_CONFIRMATION_BECAUSE_DESTROY:
        qDebug() << "ID: " << eventInstance->messageTrackingId << " not confirmed due to destroy";
        break;
    case IOTHUB_CLIENT_CONFIRMATION_MESSAGE_TIMEOUT:
        qDebug() << "ID: " << eventInstance->messageTrackingId << " not confirmed due to timeout";
        break;
    case IOTHUB_CLIENT_CONFIRMATION_ERROR:
        qDebug() << "ID: " << eventInstance->messageTrackingId << " not confirmed due to confirmation error";
        break;
    default:
        qDebug() << "ID: " << eventInstance->messageTrackingId << " Unknown confirmation";
        break;
    }

Once a message has returned the confirmation state, it has been parsed and processed by the IoTHub. Any previous state indicates that it has not yet been stored and is cached locally.

After the messages have been confirmed, analytics (or any other operation) can be applied to the data (eg. TimeSeries Insights or the new IoTCentral products). Check out the custom dashboard in our demo video at the Embedded World 2018:

This example uses one executable to handle all available sensors. Naturally, a highly scalable setup demands further requirements. Given that the presented Qt connector runs on a server instance already, it could easily be integrated into a virtualization scenario using containers or similar.

As you have seen, not only can you use Qt to create devices and gateways with and without an HMI, but also bridges between various aspects of a deployment setup. With a consistent API, all building blocks can easily be moved, while the code stays the same due to its cross-platform capabilities.

The post Integrating Cloud Solutions with Qt appeared first on Qt Blog.

22 Jun 2018 10:47am GMT

Qt Contributor Summit 2018

I guess you'll have seen Albert's blog post about the Qt Contributor Summit, if not do it.

I thought it would be interesting to recap a bit. As he put it, most discussions revolved around how to iterate every part of Qt into Qt 6. It's exciting, a little bit scary but exciting.

One bit especially interesting is the graphics stack. Back in Qt 5.0, Qt took the liberty of limiting the graphics stack to OpenGL, but the world has changed since: On Windows the only proper stack is Direct3D 12, Apple introduced Metal and recently deprecated OpenGL and Vulkan is coming rather strong. It looks like embracing these systems transparently will be one of the most exciting tasks to achieve. From a KDE & Plasma perspective I don't think this is scary, OpenGL is here to stay on Linux. We will get a Framework based on a more flexible base and we can continue pushing Plasma, Wayland, Plasma Mobile with confidence that the world won't be crumbling. And with a bit of luck, if we want some parts to use Vulkan, we'll have it properly abstracted already.

Furthermore, here's some of the re-caps some people (mainly Thiago ^^') uploaded after the sessions:

I think it was a great conference, thanks to Tero and The Qt Company for putting it together. And thanks to the sponsors for making it possible. 🙂

See you all again, Qt-ies!

22 Jun 2018 10:19am GMT

Konsole’s search tool

Following my konsole's experiments from the past week I came here to show something that I'm working on with the VDG, This is the current Konsole's Search Bar.

It works, It's nice, It's one of the few things I really like on konsole. It's also full of little bugs that annoyed me for quite a while.

I started to fix all of those bugs and discovered that most of them happened because we had *one* search bar that was shared between every terminal view, and whenever a terminal was activated we would reposition, reparent, repaint, disconnect, reconnect the search bar. Easiest solution: Each Terminal has it's own search bar. Setuped only once. The one bug I did not fix was the Opening / Closing one as the searchbar is inside of a layout and layouts would reposition things anyway.

All of the above bugs got squashed by just moving it to TerminalDisplay, and the code got also much cleaner as there's no need to manual intervention in many cases. On the review Kurt - the Konsole maintainer - asked me if I could try to make the Search prettier and as an overlay on top of the Terminal so it would not reposition things when being displayed.

Tougths?

22 Jun 2018 9:24am GMT

Second Post and First Weekly

Now I am officially in the summer break, and can focus on GSoC. From now on, posts will be made weekly.

In the first phase, I finished the UI design and finalized the design decisions of the palette docker.

Decisions made:

Because of the last one, I have been refactoring related code in the last month. The refactoring is generally completed, with KisDlgInternalColorSelector being the last dependency that haven't been moved to enable KisPaletteView to be used everywhere needed.

After the refactoring, a new palette chooser is going to be written to be used to choose the palettes.

22 Jun 2018 12:00am GMT

21 Jun 2018

feedPlanet KDE

KDE on Android: CI, CD & SDK

I guess we all agree that one of the biggest stoppers to get a contribution out is the ability to get the system ready to start working on the contribution. Today I want to talk a bit about generating Android binaries from our machine.

In the KDE Edu sprint we had the blatant realisation that it's very frustrating to keep pushing the project while not being swift at delivering fresh packages of our applications in different systems. We looked into windows, flatpak, snap and, personally, I looked into Android once again.

Nowadays, KDE developers develop the applications on their systems and then create the binaries on their systems as well. Usually it's a team effort where possibly just one person in the team will be familiar with Android and have the development combo in place: Android SDK, Android NDK, Qt binaries and often several KDE Frameworks precompiled. Not fun and a fairly complex premise.

Let's fix that.

Going back to the initial premise of delivering KDE Edu binaries, the first thing we need is a continuous distribution system for Android, much like we already had for binary-factory.kde.org.

Our applications will be bundling some KDE Frameworks, we need to know which work, to make sure they don't break to some extent, much like what build.kde.org is already doing.
And last but not least, while at it, we need to create a system that makes it simple for developers to do the same that our automatic systems are doing.

Docker to the rescue

We needed a way to pull everything we will need into a system: SDK, NDK, Qt binaries, few build dependencies. For this we created the following image:
https://hub.docker.com/r/kdeorg/android-sdk/ (Source)

With this image one can create binaries for his application locally.

We have also deployed it in build.kde.org to build some KDE Frameworks. Note that we are lacking some dependencies on Android so our offer is limited in comparison to traditional GNU/Linux. Also we are not running tests, it's something we could look into but I'm not yet sure how useful that would be.

I want to develop

Here you have a wiki that explains how to use the docker image to build your KDE application.

I want to test

I set up an F-Droid repository that offers the binaries listed in the binary-factory conveniently, so that when there is a new version we will get the update.

Future

All of this ties directly to the runtime integration I mentioned already in this blog post.

21 Jun 2018 11:50pm GMT

LabPlot 2.5 released

It took much more time to finalize the release than we planned in the beginning after the 2.4 release was done. But we hope the number of features we implemented for 2.5 and their impact on the workflows supported by LabPlot can justify this delay. The source code and the installers for Windows and for Mac OS X can be found on our download page, as usual.

In this release we again increased the number of data sources and added the support for the import of data from SQL databases. The user can import either from single tables or import the result of a custom SQL queries.



Import from a table


Import the result of a custom SQL query


Starting with 2.5 we can import © OriginLab Origin projects files. It goes without saying that the first release having this feature cannot handle the complete feature set of Origin. In this release we concentrated on the import of Origin's data containers - workbooks and matrix books and 2D-plots. A new dialog for the project import was added that provides a preview of the content of the selected project file and where the user can select which objects to import:



Import Project Dialog



Similar to the import of Origin projects, we support the import of native LabPlot projects. With this, complete or partial merging of different projects becomes possible. More information on this feature can be found here.

Another major new feature is the support of live data. We dedicated a blog recently to this topic. Though it is possible to read live data from files, pipes and different types of sockets (local, TCP, UDP), the support for sockets is experimental in this release and will be made more stable in the next release.

Among other smaller improvements in the area of data import we want to mention the new ability of LabPlot's main window to react on drag&drop events. Now, if the user drags a file and drops it on LabPlot, the import dialog is immediately opened and the user can specify how to import the file. Similar for project files - drag&drop of LabPlot and Origin project files loads the project.

More work was also invested in the auto-detection of data types during the import. Some additional options in the import dialog were added where the user can specify the locale and the format for date/date-time values to be used during the import.

We implemented couple of nice features for faster creation of plots and curves:





This was described in more details in the dedicated blog post for UX improvements. There are couple of other smaller changes that will improve the general user experience like the syntax highlighting for LaTeX code in text labels, tool tips for the supported mathematical functions and constants in text fields for mathematical expressions and the animated zooming in worksheet views.

Similar to the previous releases, we continue working on the data analysis functions in LabPlot. In 2.5 we greatly improved data fitting and added some logic to automatically guess the parameters for fit models specified by the user, for fitting with weights, etc. We refer to the blog which describes the new features in more detail.

Theming that was added in LabPlot 2.4 was further extended and improved. Now, also plot legends and text labels respect the color palettes defined in a theme and it is possible to apply a theme to the whole worksheet and to all its children and not to single plots only. We added a new application options for the default theme that has to be used for new worksheets. With this option the user can select and theme that will be applied on default of every new worksheet and its children.

On the plotting side, among several smaller fixes and performance improvements we now automatically switch to the scientific representation for numbers bigger than 10^4 on the axis tick labels. Furthermore, we added the possibility to add new text labels to the plots. With this, in addition to the already and always available text label for the plot title the user has the possibility to add more text information to the plot.

The command line interface was extended and we added the options to start the application in the presenter mode and to specify the name of the (LabPlot or Origin) project file to open it directly upon start.

The list of the supported mathematical functions was extended. Users compiling with GSL 2.4 can use Hermite polynomials in LabPlot. Users compiling with libcerf will benefit from many different complex error functions.

Though the primary development and testing happens on Linux mostly, we invested more into Windows and Max OS X builds and provide a better support for these platforms now. Also, with this release we ship for the first time a version of Cantor on Windows and Max OS X to provide the support for common open source computer algebra systems in LabPlot as introduced in 2.3 also on these platforms. This feature is experimental on these platforms at the moment but it will get more attention in future from us and we hope to be on par soon with what we have for Linux versions.

All in all, a lot of new features and improvements this time! This release took quite a lot of our time and required a lot of effort to finalize everything. It was not always easy but now when everything is done we can relax a bit. But only a bit :-). This year we have two GSoC-students working on really cool projects that will enable LabPlot to read data from MQTT and from web services. Besides this, couple of other features are already in progress and we hope to bring another release this year.

21 Jun 2018 6:32pm GMT

Qt Creator 4.7 Beta2 released

We are happy to announce the release of Qt Creator 4.7 Beta2!

It is roughly 2 weeks after the Beta1 release, and 2 weeks before our planned release candidate, so we want to give you the opportunity to fetch an updated work-in-progress snapshot in between.
If you haven't yet read about the improvements and new features that are coming with 4.7 (or if you have forgotten), I would like to point you to the blog post for the first beta.

Get Qt Creator 4.7 Beta2

The opensource version is available on the Qt download page, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.7 Beta2 is also available under Preview > Qt Creator 4.7.0-beta2 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.7 Beta2 released appeared first on Qt Blog.

21 Jun 2018 12:10pm GMT

CMake 3.12 Update on FreeBSD

CMake 3.12 has reached rc1. That means we're testing the update on FreeBSD, and building lots and lots of packages. And, as I've written previously, every CMake update triggers a bunch of interesting software findings.

As a motto, I've got "use it, aggressively improve it" on my website (you can hire me for odd CMake and C++ jobs, too). So hitting compile issues makes me turn to fixing software outside of KDE.

What I found interesting in those two was once again the variety in CMake styles - "Modern CMake Style" still needs to catch on in many places, and the wider ecosystem. Mantis bug-tracker! Mercurial! I remember being a big Mercurial fan years ago when doing KDE-Solaris and complaining how obtuse git is. (It's still obtuse, but I'm used to it now).

There's another four dozen ports that have fallout from this update; amusingly Kitware's VTK 5 and VTK 6 are among them - although a first glance tells me that's C++ problems and not CMake problems, actually. (Generally, using NULL in places where you want to write 0; older macro definitions of NULL would re-write to something that could successfully be cast to 0, but clang6 in C++17 mode, the default, uses nullptr which doesn't cast).

21 Jun 2018 10:55am GMT

The day Kate Gregory enjoyed Qt

At my company we use C++ for everything, from creating microservices to website backends and as a generator for website frontends, I mean, we do a lot of c++. And because of that we always need more c++ people, but sometimes it's hard to find developers, but it's easy to find php / python / javascript ones. Because of that we hired Kate Gregory's famous c++ course - "Teaching the Teacher" to train current C++ developers to teach C++. (now, that's a lot of 'C++' in a simple sentence, I know. bear with me.)

For those that doens't know, Kate Gregory is somebody that uses, advocates our beloved language even before I was born, and talks all over the world about C++ and also do trainings for companies, And so I enlisted to be her student.

It was a really pleasant course going thru how to proplery explain C++ for people that know how to program but don't know how to C++, and for that I'm grateful. But then when I commented out about Qt in the middle of the class she rolled her eyes, that made me feel a bit uneasy so I talked to her on why the eye-roll. "Qt is not c++", and I tougth this was already settled down for years, so I asked her if she would be open to see some simple c++ code written in Qt and tell me what she thinks of it. "Well, Yes. but people already tried and it was not good".

Then I tried, and when you are showing Qt to people that are interested in the language there's a few things that you should not try to talk about:

What I actually talked about, to remove some misconceptions about "Qt is for Widgets, Qt is Not C++"

I'v created the following source codes, all compile without moc, all are clean c++ code for people that don't belive Qt can be compiled with a plain compiler, all of them are *way* easier to read and write than anything that the STL can provide, and I'v showed them to Kate. (wordpress don't let me update cpp files so I renamed it to txt)

After looking at them Kate said "You are actually the first person to show me Qt code that's nice to look, this is actually pleasant.", I realized that whenever We (and by we I mean KDE, Qt Company, Qt Advocates) try to advocate Qt to C++ developers we attack in the wrong front, let's put less focus on Widgets / QML and more focus on easy of use for things that STL provides and Qt does better, or for things that STL *should* provide but doesn't (like QString vs std::string - it's 2018 and till today there's no codepoint support for utf-8 in it, sigh).

21 Jun 2018 9:40am GMT

First Beta Release of Krita 4.1

Three months after the release of Krita 4.0, we're releasing the first (and probably only) beta of Krita 4.1, a new feature release! This release includes the following major new features:

And there's more. Read the full release notes to discover what's new in Krita 4.1! With this beta release, the release notes are still work in progress, though.

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.)

When it is updated, you can also use the Krita Lime PPA to install Krita 4.1.0-beta.2 on Ubuntu and derivatives. We are working on an updated snap.

OSX

Note: the touch docker, gmic-qt and python plugins are not available on OSX.

Source code

md5sum

For all downloads:

Key

The Linux appimage and the source tarball 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.

21 Jun 2018 7:52am GMT

New adventures – old challenges

Times pass and we all change. I've realized that I've gone from mostly coding at work, to almost not coding at all (I reflect on this in the Under utveckling pod - Swedish only). I've also realized that what I do in automotive has a much wider application (see my fosdem talk on this). Thus, the conclusion is that the time has come to change context.

I've also spent a lot of time on promoting free and open source software. I've spoken at conferences, gone to hackathlons, spoken at the university, and arranged meetups. All this culminated in foss-north which I've been organizing for the past three years.

The conclusion from all of this is that there is an opportunity to focus on this full time. How can free and open source software be leveraged in various industries? How does one actually work with this? How does licensing work? and so on. To do so, I founded my own company - koderize - a while back and from now on I'm focusing fully on it.

Before joining Pelagicore back in 2010 I was solo consulting for a year. This was a great opportunity and I finally got to spend some time working directly with the former Trolls at what later became The Qt Company. However, I also came to realize that solo consulting makes me go slightly mad. Also, my wife complained that I talked to much every afternoon when she came home ;-)

Thus, I want colleagues. That is why myself and some great people that I've passed by during my years in this field are founding Kuro Studio (the web page is minimalist - i.e. empty).

The team we're setting up complement each other and the sum of our experience covers the full full-stack. We can do team building, purchasing, processes, QA, agile, development, design, licensing, devops - even some hardware. The goal is to create an end-to-end product design team that can help out during any phase of product development, as well as organizational development.

At the end of the day I'm still passionate about what I have been doing the past 8 years. Cars excite me, and combining that with Qt and Linux makes me even more excited. That means that I'll still be around in that field. As a matter of fact, my first assignment is in that area.

So, at the end of the day, time pass, we grow, but some things still stay the same. A big thank you to everyone at Pelagicore - it was a great ride.

21 Jun 2018 7:13am GMT