Planet KDE

Syndicate content
Planet KDE - http://planetKDE.org/
Updated: 1 day 5 hours ago

Krita 3.0.1 Development Builds

Fri, 2016-07-22 10:21

Because of unforeseen circumstances, we had to rejig our release schedule, there was no release last week. Still, we wanted to bring you a foretaste of some of the goodies that are going to be in the 3.0.1 release, which is now planned for September 5th. There’s lots to play with, here, from bug fixes (the double dot in file names is gone, the crash with cheap tablets is gone, a big issue with memory leaks in the graphics card is solved), to features (soft-proofing, among others). There may also be new bugs, and not all new features may be working correctly. Export to animated gif or video clips is still in development, and probably will not work well outside the developers’ computer.

After all, this is a development snapshot. Still, please experiment with it and test it, and we’re pretty sure that for many purposes it might be better already than the 3.0 stable release!

On the OSX front we’ve made progress, too, and this build should run fine on OSX 10.9 upwards, including 10.10. All libraries are updated to the latest version, too.

Windows

On Windows, Krita supports Wacom, Huion and Yiynova tablets, as well as the Surface Pro series of tablets. The portable zip file builds can be unzipped and run by double-clicking the krita link.

Krita on Windows is tested on Windows 7, Windows 8 and Windows 10. There is only a Windows 64 bits build for now. There is now also a debug build that together with the DrMingw debugger can help with finding the cause of crashes. See the new FAQ entry.

Linux

For Linux, we offer AppImages that should run on any reasonable recent Linux distribution. You can download the appimage, make it executable and run it in place. No installation is needed. At this moment, we only have appimages for 64 bits versions of Linux.

OSX and MacOS

Krita on OSX will be fully supported with version 3.1. Krita 3.0 for OSX is still missing Instant Preview and High Quality Canvas scaling. There are also some issues with rendering the image — these issues follow from Apple’s decision to drop support for the OpenGL 3.0 compatibility profile in their display drivers and issue with touchpad and tablet support. We are working to reimplement these features using OpenGL 3.0 Core profile. For now, we recommend disabling OpenGL when using Krita on OSX for production work. Krita for OSX runs on 10.9, 10.10, 10.11 and is reported to work on MacOS too.

Categories: FLOSS Project Planets

Kubuntu 16.04.1 LTS Update Out

Thu, 2016-07-21 22:57

The first point release update to our LTS release 16.04 is out now. This contains all the bugfixes added to 16.04 since its first release in April. Users of 16.04 can run the normal update procedure to get these bugfixes.

See the 16.04.1 release announcement.

Download 16.04.1 images.

Categories: FLOSS Project Planets

Double Post – Lakademy and Randa 2016

Thu, 2016-07-21 20:34

 

I Have a few favorites kde conventions that I really love to participate.

Randa and Lakademy are always awesome, both are focused on hacking, and I surely do love to hack.

On LaKademy I spend my days working on subsurface, reworking on the interface, trying to make it more pleasant to the eye,

In Randa I worked on KDevelop and Marble, but oh my…

I spend a few days working on KDevelop, in one of bugs that where preventing the release of the 5.0, I’v tried a bit if things with help from Kevin Funk and Aleix Pol, but everything that I fixed created another two corner cases, in the third day trying I stopped and went to work on  marble instead so I could clear my head. My Patch had almost 500 lines already, and more than 20 commits – Something told me that there was something wrong with the approach, but I actually didn’t know what else to try.

The problem was a widget being deleted inside of Qt’s Event Loop when a focus change occoured – the code should have prevented the focus loss, but  didn’t, a crash occoured instead.

Now, when I got back to Brazil I realized that the bug was fixed, so someone had worked on top of it and my patch should have been discarded… I went to look how the other developer fixed it, and at first I didn’t understood. He was working with invokeMetaMethod instead of calling the method directly (this + a few other checks), to summarize… he fixed in 20 lines what I didn’t managed to fix in 500.

It was a really good learning experience for me, I wouldn’t ever have tougth to use invokeMetaMethod inside of the Event Loop.

 

Categories: FLOSS Project Planets

GammaRay 2.5 release

Thu, 2016-07-21 10:48

GammaRay 2.5 has been released, the biggest feature release yet of our Qt introspection tool. Besides support for Qt 5.7 and in particular the newly added Qt 3D module a slew of new features awaits you, such as access to QML context property chains and type information, object instance statistics, support for inspecting networking and SSL classes, and runtime switchable logging categories.

We also improved many existing functionality, such as the object and source code navigation and the remote view. We enabled recursive access to value type properties and integrated the QPainter analyzer in more tools.

GammaRay is now also commercially available as part of the Qt Automotive suite, which includes integration with QtCreator for convenient inspection of embedded targets using Linux, QNX, Android or Boot2Qt.

Download GammaRay

The post GammaRay 2.5 release appeared first on KDAB.

Categories: FLOSS Project Planets

KDStateMachineEditor 1.1.0 released

Thu, 2016-07-21 10:47

KDStateMachineEditor is a Qt-based framework for creating Qt State Machine metacode using a graphical user interface. It works on all major platforms and is now available as part of the Qt Auto suite.

The latest release of KDAB’s KDStateMachineEditor includes changes to View, API and Build system.

View

  • Button added to show/hide transition labels
  • Now using native text rendering
  • Status bar removed

API

  • API added for context menu handling (cf. StateMachineView class)

Build system

  • Toolchain files added for cross-compiling (QNX, Android, etc.)
  • Compilation with namespaced Qt enabled
  • Build with an internal Graphviz build allowed (-DWITH_INTERNAL_GRAPHVIZ=ON)

KDStateMachineEditor Works on all major platforms and has been tested on Linux, OS X and Windows.

Prebuilt packages for some popular Linux distributions can be found here.

Homebrew recipe for OSX users can be found here.

The post KDStateMachineEditor 1.1.0 released appeared first on KDAB.

Categories: FLOSS Project Planets

KDAB contributions to Qt 5.7

Thu, 2016-07-21 10:46

Hello, and welcome to the usual appointment with a new release of Qt!

Qt 5.7 has just been released, and once more, KDAB has been a huge part of it (we are shown in red on the graph):

Qt Project commit stats, up to June 2016. From http://www.macieira.org/blog/qt-stats/

In this blog post I will show some of the outstanding contributions by KDAB engineers to the 5.7 release.

Qt 3D

The star of Qt 5.7 is the first stable release of Qt 3D 2.0. The new version of Qt 3D is a total redesign of its architecture into a modern and streamlined 3D engine, exploiting modern design patterns such as entity-component systems, and capable to scale due to the heavily threaded design. This important milestone was the result of a massive effort done by KDAB in coordination with The Qt Company.

If you want to know more about what Qt 3D can do for your application, you can watch this introductive webinar recorded by KDAB’s Dr. Sean Harmer and Paul Lemire for the 5.7 release.

Qt on Android

Thanks to KDAB’s BogDan Vatra, this release of Qt saw many improvements to its Android support. In no particular order:

  • Qt can now be used to easily create Android Services, that is, software components performing background tasks and that are kept alive even when the application that started them exits. See here for more information.
  • The QtAndroidExtras module gained helper functions to run Runnables on the Android UI thread. They are extremely useful for accessing Android APIs from C++ code that must be done on Android UI thread. More info about this is available in this blog post by BogDan.
  • Another addition to the QtAndroidExtras module is the QtAndroid::hideSplashScreen function, which allows a developer to programmatically hide the splash screen of their applications.
  • The QtGamepad module gained Android support.
Performance and correctness improvements

A codebase as big as Qt needs constant fixes, improvements and bugfixes. Sometimes these come from bug reports, sometimes by reading code in order to understand it better, and in some other cases by analyzing the codebase using the latest tools available. KDAB is committed to keeping Qt in a great shape, and that is why KDAB engineers spend a lot of time polishing the Qt codebase.

Some of the results of these efforts are:

  • QHash gained equal_range, just like QMap and the other STL associative container. This function can be used to iterate on all the values of a (multi)hash that have the same key without performing any extra memory allocation. In other words, this code: // BAD!!! allocates a temporary QList // for holding the values corresponding to "key" foreach (const auto &value, hash.values(key)) { }

    can be changed to

    const auto range = hash.equal_range(key); for (auto i = range.first; i != range.second; ++i) { }

    which never throws (if hash is const), expands to less code and does not allocate memory.

  • Running Qt under the Undefined Behavior Sanitizer revealed dozens of codepaths where undefined behaviour was accidentally triggered. The problems ranged from potential signed integer overflows and shift of negative numbers to misaligned loads, invalid casts and invalid calls to library functions such as memset or memcpy. KDAB’s Senior Engineer Marc Mutz contributed many fixes to these undefined behaviours, fixes that made their way into Qt 5.6.1 and Qt 5.7.
  • Some quadratic loops were removed from Qt and replaced with linear or linearithmic ones. Notably, an occurrence of such loops in the Qt Quick item views caused massive performance degradations when sorting big models, which was fixed in this commit by KDAB’s engineer Milian Wolff.
  • Since Qt 5.7 requires the usage of a C++11 compiler, we have starting porting foreach loops to ranged for loops. Ranged for loops expand to less code (because there is no implicit copy taking place), and since compilers recognize them as a syntactic structure, they can optimize them better. Over a thousand occurrences were changed, leading to savings in Qt both in terms of library size and runtime speed.
  • We have also started using C++ Standard Library features in Qt. While Qt cannot expose STL types because of its binary compatibility promise, it can use them in its own implementation. A big advantage of using STL datatypes is that they’re generally much more efficient, have more features and expand to a lot less code than Qt counterpart. For instance, replacing some QStack usages with std::stack led to 1KB of code saved per instance replaced; and introducing std::vector in central codepaths (such as the ones in QMetaObjectBuilder) saved 4.5KB.
  • While profiling Qt3D code, we found that the mere act of iterating over resources embedded in an application (by means of QDirIterator) uncompressed them. Then, reading a given resource via QFile uncompressed it again. This was immediately fixed in this commit by KDAB’s Director of Automotive, Volker Krause.
Other contributions

Last but not least:

  • It is now possible to use the Qt Virtual Keyboard under QtWayland compositors.
  • The clang-cl mkspec was added. This mkspec makes it possible to build Qt using the Clang frontend for MSVC. Stay tuned for more blog posts on this matter.
  • A small convenience QFlag::setFlag method was added, to set or unset a flag in a bitmask without using bitwise operations.

About KDAB

KDAB is a consulting company dedicated to Qt and offering a wide variety of services and providing training courses in:

KDAB believes that it is critical for our business to invest in Qt3D and Qt, in general, to keep pushing the technology forward, ensuring it remains competitive.

The post KDAB contributions to Qt 5.7 appeared first on KDAB.

Categories: FLOSS Project Planets

Four Habit-Forming Tips to Faster C++

Thu, 2016-07-21 10:46

Are you a victim of premature pessimisation? Here’s a short definition from Herb Sutter:

Premature pessimization is when you write code that is slower than it needs to be, usually by asking for unnecessary extra work, when equivalently complex code would be faster and should just naturally flow out of your fingers.

Despite how amazing today’s compilers have become at generating code, humans still know more about the intended use of a function or class than can be specified by mere syntax. Compilers operate under a host of very strict rules that enforce correctness at the expense of faster code. What’s more, modern processor architectures sometimes compete with C++ language habits that have become ingrained in programmers from decades of previous best practice.

I believe that if you want to improve the speed of your code, you need to adopt habits that take advantage of modern compilers and modern processor architectures—habits that will help your compiler generate the best-possible code. Habits that, if you follow them, will generate faster code before you even start the optimisation process.

Here’s four habit-forming tips that are all about avoiding pessimisation and, in my experience, go a long way to creating faster C++ classes.

1) Make use of the (named-) return-value optimisation

According to Lawrence Crowl, (named-) return-value optimisation ((N)RVO) is one of the most important optimisations in modern C++. Okay—what is it?

Let’s start with plain return-value optimization (RVO). Normally, when a C++ method returns an unnamed object, the compiler creates a temporary object, which is then copy-constructed into the target object.

MyData myFunction() { return MyData(); // Create and return unnamed obj } MyData abc = myFunction();

With RVO, the C++ standard allows the compiler to skip the creation of the temporary, treating both object instances—the one inside the function and the one assigned to the variable outside the function—as the same. This usually goes under the name of copy elision. But what is elided here is the temporary and the copy.

So, not only do you save the copy constructor call, you also save the destructor call, as well as some stack memory. Clearly, elimination of extra calls and temporaries saves time and space, but crucially, RVO is an enabler for pass-by-value designs. Imagine MyData was a large million-by-million matrix. There mere chance that some target compiler could fail to implement this optimisation would make every good programmer shy away from return-by-value and resort to out parameters instead (more on those further down).

As an aside: don’t C++ Move Semantics solve this? The answer is: no. If you move instead of copy, you still have the temporary and its destructor call in the executable code. And if your matrix is not heap-allocated, but statically sized, such as a std::array<std::array<double, 1000>, 1000>>, moving is the same as copying. With RVO, you mustn’t be afraid of returning by value. You must unlearn what you have learned and embrace return-by-value.

Named Return Value Optimization is similar but it allows the compiler to eliminate not just rvalues (temporaries), but lvalues (local variables), too, under certain conditions.

What all compilers these days (and for some time now) reliably implement is NRVO in the case where there is a single variable that is passed to every return, and declared at function scope as the first variable:

MyData myFunction() { MyData result; // Declare return val in ONE place if (doing_something) { return result; // Return same val everywhere } // Doing something else return result; // Return same val everywhere } MyData abc = myFunction();

Sadly, many compilers, including GCC, fail to apply NRVO when you deviate even slightly from the basic pattern:

MyData myFunction() { if (doing_something) return MyData(); // RVO expected MyData result; // ... return result; // NRVO expected } MyData abc = myFunction();

At least GCC fails to use NRVO for the second return statement in that function. The fix in this case is easy (go back to the first version), but it’s not always that easy. It is an altogether sad state of affairs for a language that is said to have the most advanced optimisers available to it for compilers to fail to implement this very basic optimisation.

So, for the time being, get your fingers accustomed to typing the classical NRVO pattern: it enables the compiler to generate code that does what you want in the most efficient way enabled by the C++ standard.

If diving into assembly code to check whether a particular patterns makes your compiler drop NRVO isn’t your thing, Thomas Brown provides a very comprehensive list of compilers tested for their NRVO support and I’ve extended Brown’s work with some additional results.

If you start using the NVRO pattern but aren’t getting the results you expect, your compiler may not automatically perform NRVO transformations. You may need to check your compiler optimization settings and explicitly enable them.

Return parameters by value whenever possible

This is pretty simple: don’t use “out-parameters”. The result for the caller is certainly kinder: we just return our value instead of having the caller allocate a variable and pass in a reference. Even if your function returns multiple results, nearly all of the time you’re much better off creating a small result struct that the function passes back (via (N)RVO!):

That is, instead of this:

void convertToFraction(double val, int &numerator, int &denominator) { numerator = /*calculation */ ; denominator = /*calculation */ ; } int numerator, denominator; convertToFraction(val, numerator, denominator); // or was it "denominator, nominator"? use(numerator); use(denominator);

You should prefer this:

struct fractional_parts { int numerator; int denominator; }; fractional_parts convertToFraction(double val) { int numerator = /*calculation */ ; int denominator = /*calculation */ ; return {numerator, denominator}; // C++11 braced initialisation -> RVO } auto parts = convertToFraction(val); use(parts.nominator); use(parts.denominator);

This may seem surprising, even counter-intuitive, for programmers that cut their teeth on older x86 architectures. You’re just passing around a pointer instead of a big chunk of data, right? Quite simply, “out” parameter pointers force a modern compiler to avoid certain optimisations when calling non-inlined functions. Because the compiler can’t always determine if the function call may change an underlying value (due to aliasing), it can’t beneficially keep the value in a CPU register or reorder instructions around it. Besides, compilers have gotten pretty smart—they don’t actually do expensive value passing unless they need to (see the next tip). With 64-bit and even 32-bit CPUs, small structs can be packed into registers or automatically allocated on the stack as needed by the compiler. Returning results by value allows the compiler to understand that there isn’t any modification or aliasing happening to your parameters, and you and your callers get to write simpler code.

3) Cache member-variables and reference-parameters

This rule is straightforward: take a copy of the member-variables or reference-parameters you are going to use within your function at the top of the function, instead of using them directly throughout the method. There are two good reasons for this.

The first is the same as the tip above—because pointer references (even member-variables in methods, as they’re accessed through the implicit this pointer) put a stick in the wheels of the compiler’s optimisation. The compiler can’t guarantee that things don’t change outside its view, so it takes a very conservative (and in most cases wasteful) approach and throws away any state information it may have gleaned about those variables each time they’re used anew. And that’s valuable information that can help the compiler eliminate instructions and references to memory.

Another important reason is correctness. As an example provided by Lawrence Crowl in his CppCon 2014 talk “The Implementation of Value Types”, instead of this complex number multiplication:

template <class T> complex<T> &complex<T>;::operator*=(const complex<T> &a) { real = real * a.real – imag * a.imag; imag = real * a.imag + imag * a.real; return *this; }

You should prefer this version:

template <class T> complex<T> &complex<T>;::operator*=(const complex<T> &a) { T a_real = a.real, a_imag = a.imag; T t_real = real, t_imag = imag; // t == this real = t_real * a_real – t_imag * a_imag; imag = t_real * a_imag + t_imag * a_real; return *this; }

This second, non-aliased version will still work properly if you use value *= value to square a number; the first one won’t give you the right value because it doesn’t protect against aliased variables.

To summarise succinctly: read from (and write to!) each non-local variable exactly once in every function.

4) Organize your member variables intelligently

Is it better to organize member variables for readability or for the compiler? Ideally, you pick a scheme that works for both.

And now is a perfect time for a short refresher about CPU caches. Of course data coming from memory is very slow compared to data coming from a cache. An important fact to remember is that data is loaded into the cache in (typically) 64-byte blocks called cache lines. The cache line—that is, your requested data and the 64 bytes surrounding it—is loaded on your first request for memory absent in the cache. Because every cache miss silently penalises your program, you want a well-considered strategy for ensuring you reduce cache misses whenever possible. Even if the first memory access is outside the cache, trying to structure your accesses so that a second, third, or forth access is within the cache will have a significant impact on speed. With that in mind, consider these tips for your member-variable declarations:

  • Move the most-frequently-used member-variables first
  • Move the least-frequently-used member-variables last
  • If variables are often used together, group them near each other
  • Try to reference variables in your functions in the order they’re declared

Nearly all C++ compilers organize member variables in memory in the order in which they are declared. And grouping your member variables using the above guidelines can help reduce cache misses that drastically impact performance. Although compilers can be smart about creating code that works with caching strategies in a way that’s hard for humans to track, the C++ rules on class layout make it hard for compilers to really shine. Your goal here is to help the compiler by stacking the deck on cache-line loads that will preferentially load the variables in the order you’ll need them.

This can be a tough one if you’re not sure how frequently things are used. While it’s not always easy for complicated classes to know what member variables may be touched more often, generally following this rule of thumb as well as you can will help. Certainly for the simpler classes (string, dates/times, points, complex, quaternions, etc) you’ll probably be accessing most member variables most of the time, but you can still declare and access your member variables in a consistent way that will help guarantee that you’re minimizing your cache misses.

Conclusion

The bottomline is that it still takes some amount of hand-holding to get a compiler to generate the best code. Good coding-habits are by no means the end-all, but are certainly a great place to start.

The post Four Habit-Forming Tips to Faster C++ appeared first on KDAB.

Categories: FLOSS Project Planets

GSoC Update: Tinkering with KIO

Thu, 2016-07-21 05:48
I'm a lot closer to finishing the project now. Thanks to some great support from my GSoC mentor, my project has turned out better than what I had written about in my proposal! Working together, we've made a lot of changes to the project.

For starters, we've changed the name of the ioslave from "File Tray" to "staging" to "stash". I wasn't a big fan of the name change, but I see the utility in shaving off a couple of characters in the name of what I hope will be a widely used feature.

Secondly, the ioslave is now completely independent from Dolphin, or any KIO application for that matter. This means it works exactly the same way across the entire suite of KIO apps. Given that at one point we were planning to make the ioslave fully functional only with Dolphin, this is a major plus point for the project.

Next, the backend for storing stashed files and folders has undergone a complete overhaul. The first iteration of the project stored files and folders by saving the URLs of stashed items in a QList in a custom "stash" daemon running on top of kded5. Although this was a neat little solution which worked well for most intents and purposes, it had some disadvantages. For one, you couldn't delete and move files around on the ioslave without affecting the source because they were all linked to their original directories. Moreover, with the way 'mkdir' works in KIO, this solution would never work without each application being specially configured to use the ioslave which would entail a lot of groundwork laying out QDBus calls to the stash daemon. With these problems looming large, somewhere around the midterm evaluation week, I got a message from my mentor about ramping up the project using a "StashFileSystem", a virtual file system in Qt that he had written just for this project.

The virtual file system is a clever way to approach this - as it solved both of the problems with the previous approach right off the bat - mkdir could be mapped to virtual directory and now making volatile edits to folders is possible without touching the source directory. It did have its drawbacks too - as it needed to stage every file in the source directory, it would require a lot more memory than the previous approach. Plus, it would still be at the whims of kded5 if a contained process went bad and crashed the daemon.

Nevertheless, the benefits in this case far outweighed the potential cons and I got to implementing it in my ioslave and stash daemon. Using this virtual file system also meant remapping all the SlaveBase functions to corresponding calls to the stash daemon which was a complete rewrite of my code. For instance, my GitHub log for the week of implementing the virtual file system showed a sombre 449++/419--. This isn't to say it wasn't productive though - to my surprise the virtual file system actually worked better than I hoped it would! Memory utilisation is low at a nominal ~300 bytes per stashed file and the performance in my manual testing has been looking pretty good.

With the ioslave and other modules of the application largely completed, the current phase of the project involves integrating the feature neatly with Dolphin and for writing a couple of unit tests along the way. I'm looking forward to a good finish with this project.

You can find the source for it here: https://github.com/KDE/kio-stash (did I mention it's now hosted on a KDE repo? ;) )
Categories: FLOSS Project Planets

Programmation Qt Quick (QML)

Thu, 2016-07-21 05:39

Paris, France 2016-08-22 2016-08-26 Paris, le 22 – 26 Août

En août offrez-vous une formation Qt en français avec un expert.

Apprenez les techniques de développement d’applications graphiques modernes, en utilisant la technologie Qt Quick (basée sur le langage QML) ainsi que la technologie objet Qt/C++.

“Mon équipe C++ a été ravie de cette formation. J‘espère pouvoir implémenter Qt dans nos applis ASAP.” CGG Veritas, Massy, France

Découvrir plus!

Voyez autres retours clients.

Enregistrez-vous

The post Programmation Qt Quick (QML) appeared first on KDAB.

Categories: FLOSS Project Planets

Kubuntu Podcast #14 – UbPorts interview with Marius Gripsgard

Wed, 2016-07-20 17:56

Show Hosts

Ovidiu-Florin Bogdan

Rick Timmis

Aaron Honeycutt

Show Schedule Intro

What have we (the hosts) been doing ?

  • Aaron
    • Working a sponsorship out with Linode
    • Working on uCycle
  •  Rick
    • #Brexit – It would be Rude Not to [talk about it]
    • Comodo – Let’s Encrypt Brand challenge https://letsencrypt.org//2016/06/23/defending-our-brand.html#1
Sponsor 1 Segment

Big Blue Button

Those of you that have attended the Kubuntu parties, will have seen our Big Blue Button conference and online education service.

Video, Audio, Presentation, Screenshare and whiteboard tools.

We are very grateful to Fred Dixon and the team at BigBlueButton.org. Go check out their project.

Kubuntu News Elevator Picks

Identify, install and review one app each from the Discover software center and do a short screen demo and review.

In Focus

Joining us today is Marius Gripsgard from the UbPorts project.

https://www.patreon.com/ubports

Sponsor 2 Segment

Linode

We’ve been in talks with Linode, an awesome VPS with super fast SSDs, Data connections, and top notch support. We have worked out a sponsorship for a server to build packages quicker and get to our users faster. BIG SHOUT OUT to Linode for working with us!

Kubuntu Developer Feedback
  • Plasma 5.7 is unlikely to hit Xenial Backports in the short term, as it is still dependent on QT 5.6.1 for which there is currently no build for Xenial.
    There is an experimental build the Acheronuk has been working on, but there are still stability issues.
Game On

Steam Group: http://steamcommunity.com/groups/kubuntu-podcast

Review and gameplay from Shadow Warrior.

Outro

How to contact the Kubuntu Team:

How to contact the Kubuntu Podcast Team:

Categories: FLOSS Project Planets

Plasma’s Publictransport applet’s porting status

Wed, 2016-07-20 17:10

You might remember that I spoke about Plasma’s Publictransport applet getting some reworking during the summer. It’s been over a month since I made that announcement on my blog and while ideally, I’d have liked to have blogged every week about my work, I haven’t really been able to. This is largely down to the&ellipsisRead the full post »

Categories: FLOSS Project Planets

KDE Brasil Telegram group and IRC United

Wed, 2016-07-20 09:06

We shouldn’t look like a bunch of old geeks all the times, and new users and new programmers doesn’t really like to use IRC, it’s just too text-based for them.

That’s why the KDE Irc channel now has a bot that will forward all messages to our Telegram Channel and vice-versa, this way all the new cool kids can talk to all the old geeks around and continue to make the KDE awesome in their platform of choice.

Thanks for the KDE Sysadmin Team for making this possible.

Categories: FLOSS Project Planets

KDE Community Working Group 2016

Tue, 2016-07-19 17:31

[Hope That Helps]

The KDE community working group exists for quite a while, helping develop the KDE community from behind the scenes.

Since we have just too many different cultures working together, from hundreds of different countries (literally), it’s a bit hard to find a common ground on what’s a polite and correct behavior to have in many situations, We have Germans, Brazilians, Indians, Mexicans, Northamericans, Canadians, Romenians, Kenians, and quite a lot of them don’t know how the correct behavior is, we know what we should be polite, and we should treat each other with respect, but what’s respect in one’s point of view may not be respect in another point of view.

And that’s why we exists – If you think someone from the community is abusing, please talk to us, we will be just like your mom and dad asking the kids to hug and not fight anymore.

you can reach us in community-wg at kde dot org

Also, people, Follow the rules.

Wiki, what’s going on? (Part 7)

Tue, 2016-07-19 12:14

 

Tears followed by joy and happiness, discussions followed by great moments all together, problems followed by their solution and enthusiasm. Am I talking about my family? More or less, because actually I am talking about a family: the WikiToLearn community!

This last period was full of ups and downs, but that is inevitable in such a project. We are a big family and we do have to face problems, but with willingness and devotion to what we are doing we can manage to overcome such problems and make things go as we want to – or, at least, try to do so.

We are putting our best efforts in what we are doing: our devs are working hard to release the 0.8 version, a first step toward our main goal – the 1.0; promo team is now trying to start local hives (or groups) in different countries; editors have their summer plans to review contents and to create new ones; the importing group is ready and very soon we are having more and more high-quality books available. Members of our family are working together to make WikiToLearn great and to give you (yes, you!) the best place we can give you to study and to create collaborative textbooks!

We are focused on September: with the beginning of the new academic year we have to fully exploit our potential and move toward #operation1000; moreover in September we are also celebrating our first birthday!

Guys, great things are coming: stay tuned!

L'articolo Wiki, what’s going on? (Part 7) sembra essere il primo su Blogs from WikiToLearn.

Categories: FLOSS Project Planets

KDE blowing out candles on FISL 17!

Tue, 2016-07-19 10:45

Decorated booth.

During the last week happened another edition of FISL, the Free Software International Forum, which is held since 2000 in the city of Porto Alegre, Rio Grande do Sul, Brazil. Our participation, as I had already announced here, was very special because we celebrate 20 years of the KDE community this year. The birthday it is only in October but as we could not pass up the opportunity to celebrate this date in such an important event as the FISL, we have prepared a special program.

On the first day it happened our mini-event, the Engrenagem (“Gear” in English), in which members of our community presentend several talks on various issues related to KDE. The Engrenagem was opened by David Edmundson talk, one of the Plasma developers.

Me.

My talk was the next. Its title was “20 anos de KDE: de Desktop a Guarda-Chuva de Projetos” (20 years of KDE: From Desktop to Project Umbrella). I presented the evolution process of our community, which led it from a desktop project to a incubator community. For those who did not attend the event the talk was recorded and it is available here. Below I also make available the slides of my presentation:

In addition to our talks, we have also prepared some surprises for the community of fans who showed up there. On the penultimate day of the event we had a special time in which we decorate our booth with balloons and a few other things, completing with birthday cake and candles! ❤

Our cake!

Us.

 

Who has not seen our talks can watch them here, searching by the “Engrenagem” term. All talks were recorded.

Who want to check out our photos at FISL, just visit our flickr


Categories: FLOSS Project Planets

System Settings help needed

Mon, 2016-07-18 14:27

First of all I need help, but before you help me I’d like to show you what a user without development skills can do to make plasma better.

I already post about the system settings redesign and cause developer are busy with other tasks, I reviewed the existing modules and update them to fit (more) our vision. I know it’s not how I would prefere in the end but I did the changes without development skills (no compiling, no new code). I use qt-creator for edit the ui files and play around with qml.

The Mouse cursor theme was updated, by move the buttons to bottom as in most other kcm’s. The height of the resolution depandant button will be change soon. (left plasma 5.7 right 5.8)

Color scheme: Preview on top and buttons on bottom. I’d like to remove the tabs and add an edit button where the tabs will pop up. Therefore I need an developer.

Emoticon theme: same here rearrange buttons. In general I’m not sure that it is a good idea to have the posibility to add a new theme in the kcm cause start from an existing one and config the xml file would be easier.

I did also some other changes, but I’d like to show you that you can change something without development skills so join the game.

If you have dev skills and be interested in some work on system settings, contact me you can increase the user experience.


Categories: FLOSS Project Planets

Breeze everywhere

Mon, 2016-07-18 12:16

The first half of this year, I had the chance to work on icon and design for two big free-software projects.

First, I’ve been hired to work on Mageia. I had to refresh the look for Mageia 6, which mostly meant making new icons for the Mageia Control Center and all the internal tools.

I proposed to replace the oxygen-like icons with some breeze-like icons.
This way it integrates much better with modern desktop, and of course it looks especially good with plasma.

The result is around 1/3 of icons directly imported from breeze, 1/3 are modified versions and 1/3 are created from scratch. I tried to follow as much as possible the breeze guidelines, but had to adapt some rules to the context.

I also made a wallpaper to go with it, which will be in the extra wallpaper package so not used by default:


available in different sizes on this link.

And another funny wallpaper for people that are both mageia users and Pepper & Carrot fans:


available in different sizes on this link
(but I’m not sure yet if this one will be packaged at all…)

Note that we still have some visual issues with the applets.
It seems to be a problem with how gtkcreate_pixbuf is used. But more important, those applet don’t even react to clic in plasma (while this seems at least to work fine in all other desktop).
Since no one seems to have an easy fix or workaround yet, if someone has an idea to help…

Soon after I finished my work on Mageia, I’ve been hired to work on fusiondirectory.
I had to create a new theme for the web interface, and again I proposed to base it on breeze, similar to what I did for Mageia but in another different context. Also, I modified the CSS to look like breeze-light interface theme. The result theme is called breezy, and is now used by default since the last release.


I had a lot of positive feedback on this new theme, people seem to really like it.

Before to finish, a special side note for the breeze team: Thank you so much for all the great work! It has been a pleasure to start from it. Feel free to look at the mageia and fusiondirectory git repositories to see if there are icons that could be interesting to push upstream to breeze icon set.

Categories: FLOSS Project Planets

From LaTeX to ConTeXt

Mon, 2016-07-18 08:23

Every year I start to create a new book, every year I delete the book folder because I think it’s going into the wrong direction, and ths year is no different, I’m starting to write a book about Qt5 programming with C++11, I hope this time things can go different. And what I usually do is setup my LaTeX enviroment (kile, texlive, a few libraries and all that) – but I was hitting a UTF8 issue that \includepackage[utf8 or utf8-x][inputenc] didn’t solved… And if you are not well versed in Tex debugging things can go hairwire in just no time.

So I started to look at the different tex enviroments that are in use nowdays, I heard of xetex and luatex but never gave them a go, until now. I started to study ConTeXt because I heard that it’s what all the cool kids in the hood are using it, at first I was afraid, I was petrified. All the macros that I know by heart had changed, All the packages that I used to setup had gone, what I could do?

Then I downloaded the ConTeXt help package, started playing with it and then it hit-me.  The lslistings package didn’t worked, how I was going to write a programming book if I can’t do proper code-highlighting on the book?

t-vim is love, t-vim is life.

A package for ConTeXt that uses vim as code-highlithing and thus having around 500+ languages with code colorization already done for you. I feel in love andthe book now is starting to shape.

I hope I don’t delete it again this year.

 

If you are into LaTeX / TeX and never gave ConTeXt a try, please do.

 

Categories: FLOSS Project Planets

Current status for mailrendering in kube & kmail

Mon, 2016-07-18 03:15

In my last entry I introduced libotp. But this name has some problems, that people thought, that it is a library for one-time-passwords, so we renamed it to libmimetreeparser.

Over the the last months I cleanup and refactored the whole mimetreeparser to turn it into a self-contained library.

Usage Dependencies

As a gerneral rule we wanted to make sure, that we only have dependecies in mimetreeparser, where we we can easily tell, why we need them. We end up with:

KF5::Libkleo KF5::Codecs KF5::I18n KF5::Mime
  • KF5::Libkleo is the dependecy we are not happy with, because it pulls in many widget related dependencies, that we want avoid. But there is light at the end of the tunnel and we will be hopefully switch in the next weeks to GpgME directly. GpgME is planning to have a Qt interface, that fulfills our need for decrypting and verifying mails. The source of the Qt interface of GpgME is libkleo, that's why the patch will be get quite small. At KDEPIM sprint in Toulouse in spring this year, I already give the Qt interface a try and made sure, that your tests are still passing.
  • KF5::Codecs to translate between different codes, that can occur in a mail
  • KF5::I18n for translations of error messages. If we want consistent translations of error messages we need to handle them in libmimetreeparser.
  • KF5::Mime because the input mail is a mimetree.
Rendering in Kube

In Kube we have decided to use QML to render mails for the user, that's made it easy to switch all html rendering specific parts away. So we end up with just triggering the ObjectTreeParser and create a model out of the resulting tree. The model is than the input for QML. QML now loads different code for different parts in the mail. For example for plain text it just shows the plain text, for html it loads this part in a WebEngine.
But as a matter of fact, the interface we use is quite new and it is currently still under development (T2308). For sure there will be changes, until we are happy with it. I will describe the interface in detail if we are happy with it. Just as sidenote, we don't want a separate interface for kube and kdepim. The new interface should be suitable for all clients. To not break the clients constently, we keep the current interface and develop the new interface from scratch and than switch we are happy with the interface.

Rendering in Kmail

As before we use html as rendering output, but with the rise of libmimtreeparser, kmail uses also the messageparttree as input and translate this into html. So we also have here a clear seperation between the parsing step ( handled in libmimetreeparser) and the rendering step, that is happening in messageviewer. Kmail has additional support for different mime-types like iTip (invitations) ind vCard. The problem with these parts are, that they need to interact directly with Akonadi to load informations. So we can actually detect if a event is already known in Akonadi or if we have the vCard already saved, which than changes the visible representation of that part. This all works because libmimetreeparser has an interface to add additional mime-type handlers ( called BodyPartFormatters).

And additionally messageviewer now using grantlee for creating the html, that is very handy and makes it now easy to change the visual presentation of mails, just by changing the theme files. That should help a lot if we want to change the look-and-feel of email presentation to the user. And allow us additionally to think about different themes for emailpresentation. We also thought about the implications of the easy changeable themes and came up with the problem, that it shouldn't be that easy to change the theme files, because malicious users, could fake good cryptomails. That's why the theme files are shipped inside resource files.

Meanwhile I was implementing this, Laurent Montel added javascript/jQuery support to the messageviewer. So I sat down and created a example to switch the alterantivepart ( html and textpart, that can be switched) with jQuery. Okay we came to the conclusion that this is not a good idea (D1991). But maybe others came up with good ideas, where we can use the power of jQuery inside the messageviewer.

Categories: FLOSS Project Planets

17th FISL, KDE Brazil and cake!

Sun, 2016-07-17 18:33

Hey, everything ok?

In this last week happened in a cold city called Porto Alegre, in Rio Grande do Sul in Brazil, the 17 edition of FISL, the Free Software International Forum.

Well… KDE has always participated in this forum, and the organization gave to us all day in a room, so the KDE Community could make a lot of talks.

I went there to talk about Stubbornness, Campus Party, and KDE, with the goal of sharing my experience about how this 3 things together changed my life. The point of this talk was made new persons get to know KDE, and encouraging them to go to(more) events. Because events/forums can change lives. Like changed my own. In my University, almost half of the students don’t care in go to events, and on this technology events, you will find what the company wants to share, and what skills you need to learn/know to work with them. And was in the Campus Party Sao Paulo 2015 that I saw that, and have my trigger to start to do something outside the college. Was a small talk that I did in 20 minutes, and got positive and bad feedbacks about it.

Also, I participate in another talk, with some friends, with the goal to share the pros and cons about the future of Drones and 3DPrinting. Since technology evolves really fast, and the IA that we are programming are getting smarter than never, we should think about the consequences of this technology. With 3DPrinting, a Drone could auto-replicate you, and depending on how it’s used, we can have a lot of bad things happening. We discussed a little bit about the ethics behind the use of Drones, and how that can affect the world that we live. Anyone with a 3DPrinter and some knowledge about robotics can build a Drone. In Brazil, we already had some issues about the use of Drones, and that started a discussion about regulation of use. An air space that the Drone need to be, so that cannot affect other things like airplanes and helicopters. Must be a regulation? Maybe. I need to study more about the subject so I can say more about it.

Also, KDE is making 20 years! YAY And we make a special party in our stand to celebrate this special BDay!

We had this *awesome* cake!

And was so great! Was a great time with the community of KDE Brazil and people that use KDE in day by day sharing with us this *awesome* day!

And yesterday, a friend of mine, Elias Silveira, publish in Facebook this draw of Konqi, that he did it using Krita 3.0! He is so skilled in draw things in Krita, that I get amazed every time that I saw a work of him in my feed. You can see Elias works here.

Well… 20 years of KDE, and I’m almost one year in this community, and I’m very thankful for being part of it. Thanks, KDE Brazil for the support, and all the community for giving me the chance to be a KDE contributor!

Happy Birthday, KDE! \o/

 


Categories: FLOSS Project Planets