Planet KDE

Syndicate content
Planet KDE - http://planetKDE.org/
Updated: 1 day 28 min ago

Kate Part (KF5): New Default Styles for better Color Schemes

Fri, 2014-03-07 16:31

Kate Part gained 17 new default styles in addition to the existing 14 default styles. These changes are available for Kate based on the KDE frameworks 5 initiative and currently live in ktexteditor.git module.

Default Styles are predefined font and color styles that are used by Kate Part’s syntax highlighting. For instance, Kate Part always had a default style for comments. Therewith, the comments in all syntax highlighting files look the same (by default, a gray color). Or keywords are by default always bold and black.

However, during the last years it became apparent that the list of 14 default styles were not always enough. Consequently, lots of syntax highlighting files defined their own hard-coded colors. For instance, doxygen comments were hard-coded in a dark blue color. The problem with hard-coded colors is that they do not adapt when changing the default styles. Hence, doxygen comments were barely readable on a dark color scheme.

Therefore, a discussion took place on kwrite-devel (thread 1, thread 2, thread 3) that ended in 17 new default styles and a categorization of these as follows (the new default styles are bold):

Category “Normal Text and Source Code

  • dsNormal: default for normal text and source code.
  • dsKeyword: Used for language keywords.
  • dsFunction: Used for function definitions and function calls.
  • dsVariable: Used for variables, if applicable. Example: $foo in PHP.
  • dsControlFlow: Used for control flow highlighting, e.g., if, then, else, return, continue.
  • dsOperator: Used for operators such as +, -, *, / and :: etc.
  • dsBuiltIn: Used for built-in language classes and functions, if applicable.
  • dsExtension: Used for extensions, such as Qt or boost.
  • dsPreprocessor: Used for preprocessor statements.
  • dsAttribute: Used for attributes of functions or objects, e.g. @override in Java, or __declspec(…) and __attribute__((…))in C/C++.

Category “Strings & Characters

  • dsChar: Used for a single character.
  • dsSpecialChar: Used for an escaped character in strings, e.g. “hello\n”.
  • dsString: Default for strings.
  • dsVerbatimString: Used for verbatim strings such as HERE docs.
  • dsSpecialString: Used for special strings such as regular expressions in ECMAScript or LaTeX math mode.
  • dsImport: Used for includes, imports, modules, or LaTeX packages

Category “Numbers, Types & Constants

  • dsDataType: Used for data types such as int, char, float etc.
  • dsDecVal: Used for decimal values.
  • dsBaseN: Used for numbers with base other than 10.
  • dsFloat: Used for floating point numbers.
  • dsConstant: Used for language constants, e.g. True, False, None in Python or nullptr in C/C++.

Category “Comments & Documentation

  • dsComment: Used for normal comments.
  • dsDocumentation: Used for comments that reflect API documentation, e.g., the default style for /** */ comments.
  • dsAnnotation: Used for annotations in comments, e.g. @param in Doxygen or JavaDoc.
  • dsCommentVar: Used to refer to variables in a comment, e.g. after @param <identifier> in Doxygen or JavaDoc.
  • dsRegionMarker: Used for region markers, typically defined by BEGIN/END.
  • dsInformation: Used for information, e.g. the keyword @note in Doxygen.
  • dsWarning: Used for warnings, e.g. the keyword @warning in Doxygen.
  • dsAlert: Used for comment specials such as TODO and WARNING in comments.

Category “Miscellaneous

  • dsOthers: Used for attributes that do not match any of the other default styles.
  • dsError: Used to indicate wrong syntax.
Existing Syntax Highlighting Files

If the new default styles are not used, syntax highlighting files are backwards compatible to Kate Part in KDE SC 4. However, the plan is to use the new default styles where applicable to avoid hard-coded colors. To this end, the kateversion attribute in the language element will be set to 5.0 (yes, Kate Part’s version changed from 3 to 5 to match KDE frameworks 5) to avoid loading incompatible syntax highlighting xml files in older Kate Part versions. Example:

<language name="C++" kateversion="5.0" [other attributes omitted]>

With the new default styles, the Default Styles tab looks as follows:

 

In comparison, the KDE 4.x version looks like this:

 

The new default style colors are not fixed yet, so improvements and additional color themes we can ship with Kate Part by default are a welcome addition!

A Note at 3rd Party Developers

There are other implementations (such as in Qt Creator or for Haskell). If you developers read this, we encourage you to add these default styles as well once Kate Part 5 is released (stable). Otherwise, the new syntax highlighting files may not be compatible.

Categories: FLOSS Project Planets

4.13 Beta 1 Workspaces, Platform and Applications for openSUSE: start the testing engines!

Fri, 2014-03-07 14:45

Yesterday KDE released their first beta of the upcoming 4.13 version of Workspaces, Applications and Development platform. As usual with the major releases from KDE, it’s packed with a lot of “good stuff”.  Giving a list of all the improvements is daunting, however there are some key points that stand out:

  • Searching: KDE’s next generation semantic search is a prominent feature of this release. It’s several orders of magnitude faster, much leaner on memory and generally is a great improvement from the previous situation (this writer has been testing it for the past months and he’s absolutely delighted about it).
  • PIM: Aside with tight integration with the new search feature, KMail gained a new quick filter bar and search, many fixes in IMAP support (also thanks to the recent PIM sprint) and a brand new sieve editor.
  • Okular has a lot of new features (tabs, media handling and a magnifier)
  • A lot more ;)

Given all of this, could the openSUSE KDE team stay still? Of course not! Packages are available in the KDE:Distro:Factory repository (for openSUSE 13.1 and openSUSE Factory) as there are lot of changes and need more testing. The final release will be provided also in the KDE:Relase413 repository (which will be created then).

Some notes on the search changes: you will need to migrate existing data from Nepomuk (should you want to: it’s optional). You can do that by running “nepomukbaloomigrator” when Nepomuk is running: it will automatically migrate your data and switch off the old system (virtuoso-t included). Also bear in mind that since the old Nepomuk support is considered “legacy” (but still provided), the programs that have not yet been ported to the new architecture have their Nepomuk integration disabled. One significant regression is file-activity linking, which will not work.

As usual, this is an unstable release and it is only meant for testing. Don’t use this in production environments! If you encounter a bug, if it is packaging related use Novell’s Bugzilla, otherwise head to bugs.kde.org. Also, before reporting anything, please check out the Beta section of the KDE Community Forums first.

That’s all, enjoy this new release!

Categories: FLOSS Project Planets

Now it’s polishing time

Fri, 2014-03-07 11:28

Work in Plasma Next is proceeding frantic as usual.
We are around a week from the release of the first Alpha (mark your calendard from a week from now), and the feature count is getting close the current release of KDE Plasma Desktop, in order to get the transition as smooth as possible.

Of course we aren’t trying to just do a carbon copy port, but to give some nice new features and improvements, such as a dramatically better behavior of the system tray (no more weird popups-from popups!), waay better support for high DPI screens and a nice new rewamped notifications system and UI.

The big thing tough is the new capabilities of the frameworks: KDE Frameworks 5 and the new Plasma Framework, with a desktop shell all based on QML2: so many things that in the past we couldn’t do, now will be possible.

And now as usual, a sneak peek of something that will not be in the alpha release yet.

The KDE Visual Design Group is doing a terrific job across very different areas of Plasma Next, the little area I’m collaborating with is the Plasma theme itself (a lot more nice stuff in many different areas will arrive from them in the future). I must say I’m impressed by their work.

But what if I have a screen with a ludicrous amount of DPI?

All of this is heavy under construction, so is still subject to a *lot* of changes until the final version

Categories: FLOSS Project Planets

Krita Training Session Next Month

Fri, 2014-03-07 08:46

For the second year, next month I’ll run a professional training session about drawing with Krita at ActivDesign in Rennes.
It will take place the week right after the Libre Graphics Meeting, from 7 to 9 April.
It is still possible to register if you’re interested (note: french-speaking session).

Besides, if you want some local personal training about Krita, in French like this time but also in English, you can always contact me directly on my contact page.

Here a little illustration made for the guide to Krita 2.8′s features pdf file, as you must already know 2.8 has been released a few days ago ;.)

Categories: FLOSS Project Planets

How to draw a red square in QtQuick

Fri, 2014-03-07 07:33

The following is a deceptively unsimple tutorial on how to draw a red square in QML onto a scenegraph.

The normal approach is as follows:

test.qml

import QtQuick 2.0 Item { Rectangle { color: "red" width: 100 height: 100 x: 100 y: 100 } }

Easy.

Going Native

However in some cases, we want a lot more control and to paint something slightly more complex than a red square.

Qt has an API to use the classic QPainter interface to draw our QQuickItems. In order to do this we must create a new QQuickPaintedItem, and register it for use from QML

reditem.cpp

#include <QPainter> #include <QQuickPaintedItem> class RedItem : public QQuickPaintedItem { void RedItem::paint(QPainter* painter) { painter->setBrush(QBrush(Qt::red)); painter->drawRect(contentsBoundingRect()); } }

At some point we need to register our type for qml with

qmlRegisterType<RedItem>("org.dave", 1, 0, "RedItem");

Our QML file then needs to change to use our new item instead.

Deeper!

Interally the QQuickPaintedItem approach is very different to how the orignal Rectange approach works. Here we are generating a giant pixmap of our red square and uploading it to an openGL texture. Given openGL can draw coloured squares natively this is a rather giant waste of memory and processing.

In order to utilise this behaviour we have to manipulate the scene graph directly.
Scene graph objects are split into two types QSGSimple* and QSG*. The former being a convienient wrapper round the second with some standard functionality.

reditem.cpp

RedItem::RedItem(QQuickItem* parent): QQuickItem(parent) { setFlag(QQuickItem::ItemHasContents, true); } QSGNode* RedItem::updatePaintNode(QSGNode *oldNode, QQuickItem::UpdatePaintNodeData*) { QSGSimpleRectNode *rectNode = static_cast<QSGSimpleRectNode*>(oldNode); if (!rectNode) { rectNode = new QSGSimpleRectNode; rectNode->setColor(QColor(Qt::red)); } rectNode->setRect(0, 0, width(), height()); return rectNode; }

In updatePaintNode we are given a pointer to the previous node (which may or may not be null) and update any properties on it. We are also able to delete the previous node, and create a new node or return a complex tree of nodes.

As updatePaintNode is called frequently it is a good idea to not update properties that have not changed, as to do so will mark them as "dirty" and perform more calculations on them.

Deeper Still

We can go lower still, and directly write openGL.

We now have 3 parts; The node, a material and a material shader.

The material shader is responsible for actually determining the colours and position of what gets painted.
This is run as two tiny programs that are compiled in the openGL context; the vertex and fragment shader.

In order to not have the same data for every node, there is only ever one shader in use.
Materials act as factory objects for the MaterialShader. Each Node will own a material, which will instantiate and share a single MaterialShader between them.

class RedMaterialShader : public QSGMaterialShader { public: virtual const char* const* attributeNames() const { static char const *const attr[] = { "vCoord", 0 }; return attr; } virtual const char* vertexShader() const { return "attribute highp vec4 vCoord;" "uniform highp mat4 matrix;" "void main()" "{" "gl_Position = matrix * vCoord;" "}"; } virtual const char* fragmentShader() const { //fragment shaders adjust the colour of each pixel //there is a special variable gl_FragColor which determines the colour of //the pixel at coord //in our case, always red return "void main() {" " gl_FragColor = vec4(1, 0, 0, 1);" //R, G, B, A "}"; } virtual void updateState(const RenderState& state, QSGMaterial* newMaterial, QSGMaterial* oldMaterial) { if (state.isMatrixDirty()) { program()->setUniformValue("matrix", state.combinedMatrix()); //in reality you want to cache the uniform location to save a lookup on every update } } static QSGMaterialType type; }; QSGMaterialType RedMaterialShader::type; class RedMaterial : public QSGMaterial { public: virtual QSGMaterialShader* createShader() const { return new RedMaterialShader; } virtual QSGMaterialType* type() const { return &RedMaterialShader::type; } }; RedItem::RedItem(QQuickItem* parent): QQuickItem(parent) { setFlag(QQuickItem::ItemHasContents, true); } QSGNode* RedItem::updatePaintNode(QSGNode *oldNode, UpdatePaintNodeData*) { QSGGeometryNode *node = static_cast<QSGGeometryNode*>(oldNode); if (!node) { node = new QSGGeometryNode; RedMaterial *m = new RedMaterial; node->setMaterial(m); node->setFlag(QSGNode::OwnsMaterial, true); QSGGeometry *g = new QSGGeometry(QSGGeometry::defaultAttributes_TexturedPoint2D(), 4); node->setGeometry(g); node->setFlag(QSGNode::OwnsGeometry, true); } QSGGeometry::updateTexturedRectGeometry(node->geometry(), QRect(0,0, width(), height()), QRect(0,0,1,1)); return node; }

There is a wrapper QSGSimpleMaterialShader, that reduces some of the boilerplate code, but is effectively the same.

Wrap up:

The Qt Quick and SceneGraph libraries are very well structured.

  • You can write QML without ever caring about underlying QQuickItems, but it's there if you need it.
  • You can write QQuickItems wihtout ever caring about the underlying scenegraph, but it's there if you need it.
  • You can write SceneGraph without ever caring about OpenGL, but it's there if you need it.

In general an application developer you should never need to touch scenegraph. The complexity is far higher than using QML. It is designed around speed rather than easy to use APIs. A lot of memory allocation and boiler plate code is the responsibility of the developer.

However, touching scenegraph directly is possible, and nothing to be too afraid of. It is worth having some knowledge in order to understand how the current QML items work underneath and how best to use them.

For those who make libraries; Plasma, Jolla, Ubuntu etc. this is something we will need to do in order to fully make use of the resources available.

Later I will blog about the changes I'm making in Plasma to use this for our custom SVG rendering making use of our existing caches and hopefully share textures and reduce our overall memory footprint.

Code

My examples are available at : git@git.kde.org:scratch/davidedmundson/qtquickplayground

Please note, the above examples deliberately focus on simplicity to explain the point, rather than speed. Additionally this is a new area for me, and I do not claim to be an expert yet. It is worth reading Qt docs heavily and reading through the original Qt code to see how to achieve the best performance.

Categories: FLOSS Project Planets

Which one is clearer?

Fri, 2014-03-07 04:14

This is a excerpt from a real project, just with variables renamed.

EDIT: * I’ve removed the issues from the original code so that this can be a real style vote, without sidetracking the readers.

Although, by fixing the code, I removed one of the things that I think the advantage of the second one is – it is much harder to make errors and dead code.

const qreal ratio = someFunction(); if (ratio < 1.5) { result = multiplier; } else if (ratio < 2.0) { result = multiplier * 1.5; } else if (ratio < 2.5) { result = multiplier * 2.0; } else if (ratio < 3.0) { result = multiplier * 3.0; } else { result = multiplier * ratio; } return result;

This was the usual imperative code that you’d find almost everywhere. And this is the alternative (functional) way of doing the same:

const qreal ratio = someFunction(); return multiplier * ( (ratio < 1.5) ? 1.0 : (ratio < 2.0) ? 1.5 : (ratio < 2.5) ? 2.0 : (ratio < 3.0) ? 3.0 : /* else */ ratio );

The second one is kinda what you’d do in maths:

/ 1.0 x < 1.5 | 1.5 1.5 ≤ x < 2.0 f(x) = < 2.0 2.0 ≤ x < 2.5 | 3.0 2.5 ≤ x < 3.0 \ x otherwise

What do you find more readable?

Categories: FLOSS Project Planets

The Vision of KDE

Thu, 2014-03-06 10:33

KDE’s current vision written in 2008 is rather outdated with its praise of KDE 4. So we should rethink what we want to achieve in future.

Introduction

Basically, a vision describes the goal of a project. It can be emotive and a source of inspiration, for instance by outlining how the final product makes the world a better place. It is roughly similar to a purpose or an aim, and guides through the development.

Examples for famous visions are:

  • “Landing a man on the moon and returning him safely to the earth by the end of the decade” by John F. Kennedy in 1961 starting the race to the moon (JFK’s moon speak)
  • “Information At Your Fingertips” by Bill Gates in 1995 about his vision of personal computing (Comdex Keynote)
  • “1000 songs in your pocket”,  about the first iPod in 2001 (Apple’s promo video)
  • “Get things done with ease, comfort and control”, Gnome’s current slogan about their desktop environment (Gnome 3)

A good vision describes the project’s final goals with a few words. It explains who will use the product, and how he or she will make advantage of it. A vision shared over all stakeholders, developers and users keeps all people involved. The major purpose is team-building.

The last example about Gnome’s goal (which is actually never called a vision  but rather applied as bottom-line) would be a not so good vision because it describes the current status and does not give any perspective for the future. A good vision can be reached, eventually!

Some Proposals for Discussion
  1. Cutting edge technology
    Recently, someone discussed his idea in terms of ‘cutting edge technology’. KDE, in his opinion, has the most recent framework and therefore we should just try out his suggestion. Cutting edge is not necessarily to understand as unreliable and high risk software, but as the first to introduce new ideas.
  2. All-purpose full-featured software
    Someone might understand KDE to be in direct competition to Gnome (or rather Unity, Mate). Positively, KDE does not oversimplifies things and provides all options to users. Since this difference is for the most users the killer feature it could be used in the vision.
  3. Powerful, yet easy to use
    Not only the UX guys want to have a system that is ‘easy to use’ but most developers want their apps to be awesome for all people. Assuming the end user will less and less care about the underlying technology the usability becomes more and more relevant. Following this consideration we should have a vision to be easy to use for everyone.
  4. Elegant software
    Often KDE is discussed in terms of elegance, which is a summary of all legacy vision aspects. Elegance is a synonym for ‘beautiful’ that has come to acquire the additional connotations of unusual effectiveness and simplicity.
  5. KDE: a community for all people
    Actually, open source software and in particular KDE is not comparable with other projects because many people fight for the greater good. To give this aspect the right importance we could include it explicitly in the vision.
  6. KDE: Qt5 at its best
    Last but not least the major technological difference of KDE to other desktop environments is the use of Qt. So we might simply adopt all of Qt ideas and vision.
And now…

When talking about a generic vision the fact that KDE consists of the desktop environment, the software compilation, and the community has to be considered. So these first thoughts are rather short but should serve as a starting point for a discussion. Now it’s up to you. Please let us know what you think about this topic, where you want KDE to be in 10 years, and how you would describe the vision.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.
Categories: FLOSS Project Planets

Calligra 2.8 is Out

Wed, 2014-03-05 17:37

Packages for the release of KDE's document suite Calligra 2.8 are available for Kubuntu 12.04 LTS and 13.10. You can get it from the Kubuntu Backports PPA (alongside KDE SC 4.12). They are also in our development release.

Categories: FLOSS Project Planets

Calligra 2.8 Released

Wed, 2014-03-05 15:00

The Calligra team is proud and pleased to announce the release of version 2.8 of the Calligra Suite, Calligra Active and the Calligra Office Engine. This version is the result of thousands of commits which provide new features, polishing of the user experience and bug fixes.

News in This Release

Calligra 2.8 contains a number of new features. Here is an excerpt of the most important ones.

Words, the word processing application, and Author, the writer’s application, both gained support for comments in the document.

Adding comments in Calligra Author 2.8

Sheets, the spreadsheet application, has improved support for pivot tables.

Pivot table in Calligra Sheets 2.8

For Kexi, the visual database creator, 2.8 version is focused on improving quality of existing features. Thanks to close collaboration with users, about 30 issues has been identified and corrected. The only new feature is ability to open hyperlinks in forms. But the big news is that the app is now available to build and run on Windows for the first time in 2.x series.

Query Designer of Kexi 2.8 on Microsoft Windows

Flow, the diagram editor, has new support for SVG based stencils.

Stencils based on SVG files in Flow 2.8

Krita, the full-featured free digital painting studio for artists provides a very exciting release! There are many new features, among them a new high-quality scaling mode for the OpenGL canvas, G’Mic integration, a wraparound painting mode for easy creation of textures and tiles, support for touch screens.

Switching between touch and desktop mode of Krita Gemini

Krita Sketch 2.8 running on tablet

The 2.8 release also features two new applications based on Krita: Krita Sketch, aimed at tablets and Krita Gemini, which can switch between desktop and tablet mode at the press of a button. The full set of improvements is huge! Krita has made its own release announcement on krita.org, which is well worth looking at. Krita 2.8 will also be available for Windows.

There are also some general improvements in all apps. It is now possible to copy and paste any shape between any documents in Calligra applications. Moreover, copying and pasting of images and rich text is now more advanced.

Try It Out

The source code of the release is available for download here: calligra-2.8.0.tar.xz.
Translations to many languages are here and MD5 sums here.
Alternatively, you can download binaries for many Linux distributions and for Windows. About the Calligra Suite

The Calligra Suite is part of the applications from the KDE community.
For more information visit http://www.calligra.org.

 

Categories: FLOSS Project Planets

New Perspective Tool for Krita

Wed, 2014-03-05 11:41

I have been meaning to right about this fabulous new tool that is the brain child of none other than David Revoy (the mockup of the same can be seen @ New Perspective Tool). Well, like many of you out there I am also mesmerized by this new tool, but, upon me is the task of […]

Categories: FLOSS Project Planets

Kubuntu Testing and You

Wed, 2014-03-05 10:05

With the latest Kubuntu 14.04 Beta 1 out the door, the Kubuntu team is hard at work to deliver the highest possible quality for the upcoming LTS release.

As part of this we are introducing basic test cases that every user can run to ensure that core functionality such as instant messaging and playing MP3 files is working as expected. All tests are meant to take no more than 10 minutes and should be doable by just about everyone. They are the perfect way to get some basic testing done without all the hassle testing usually involves.

If you are already testing Beta 1, head on over to our Quality Assurance Headquarters to get the latest test cases.

Feel free to run any test case, at any time.

If you have any questions, drop me a mail at apachelogger@kubuntu.org, or stop by in #kubuntu-devel on irc.freenode.net.

kitten by David Flores

Categories: FLOSS Project Planets

Trojita 0.4 "Ukraine" is released

Wed, 2014-03-05 09:22

Hi all,
we are pleased to announce version 0.4 of Trojitá, a fast Qt IMAP e-mail client. For this release, a lot of changes were made under the hood, but of course there are some changes that are visible to the user as well.

Improvements:
  • Users are able to use multiple sessions, which means that it is possible to use Trojitá with multiple IMAP accounts at the same time. It can be used by invoking Trojitá with the --profile something switch. For each profile, a new instance of the application is started. Please note that this is not our final solution for the multi-accounts problem; work on this is ongoing. For details, refer to the detailed instructions.
  • In the Composer Window, users can now control whether the current message is a reply to some other message. Hopefully, this will make it easier to reply to a ton of people while starting a new thread, not lumping the unrelated conversations together.
  • Trojitá will now detect changes to the network connection state. So for example, when a user switches from a wireless connection to a wired one, Trojitá will detect that and try to reconnect automatically.
  • Trojitá gained a setting to automatically use the system proxy settings.
  • SOCKS5 and HTTP proxies are supported.
  • Memory usage has been reduced and speed has been improved. Our benchmarks indicate being ten times faster when syncing huge mailboxes, and using 38% less memory at the same time.
  • The Compose Window supports editing the "From" field with hand-picked addresses as per common user requests.

This release has been tagged in git as "v0.4". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS .

This release is dedicated to the people of all nations living in Ukraine. We are no fans of political messages in software announcements, but we also cannot remain silent when unmarked Russian troops are marching over a free country. The Trojitá project was founded in a republic formerly known as Czechoslovakia. We were "protected" by foreign aggressors twice in the 20th century — first in 1938 by the Nazi Germany, and second time in 1968 by the occupation forces of the USSR. Back in 1938, Adolf Hitler used the same rhetorics we hear today: that a national minority was oppressed. In 1968, eight people who protested against the occupation in Moscow were detained within a couple of minutes, convicted and sent to jail. In 2014, Moscowians are protesting on a bigger scale, yet we all see the cops arresting them on Youtube — including those displaying blank signs.

This is not about politics, this is about morality. What is happening today in Ukraine is a barbaric act, an occupation of an innocent country which has done nothing but stopped being attracted to their more prominent eastern neighbor. No matter what one thinks about the international politics and the Crimean independence, this is an act which must be condemned and fiercely fought against. There isn't much what we could do, so we hope that at least this symbolic act will let the Ukrainians know that the world's thoughts are with them in this dire moment. За вашу и нашу свободу, indeed!

Finally, we would like to thank Jai Luthra, Danny Rim, Benjamin Kaiser and Yazeed Zoabi, our Google Code-In students, and Stephan Platz, Karan Luthra, Tomasz Kalkosiński and Luigi Toscano, people who recently joined Trojitá, for their code contributions.

The Trojitá developers

  • Jan Kundrát
  • Yuri Chornoivan
  • Karan Luthra
  • Pali Rohár
  • Tomasz Kalkosiński
  • Christian Degenkolb
  • Jai Luthra
  • Stephan Platz
  • Thomas Lübking
Categories: FLOSS Project Planets

New Blue Systems Office Edinburgh

Wed, 2014-03-05 06:21
KDE Project:

The Blue Systems office in Edinburgh has moved across The Meadows to the Grassmarket to a larger office which is also surrounded on two sides by curious artist collectives and the occasional hipster café. Hosted in Edinburgh's new technology incubator Codebase we are in another building which is nicer on the inside looking out, this time with a view of our local volcano Arthur's Seat.

I'd like to thank Cloudsoft for squatting in the office with me, making software to manage your applications in the cloud they are hiring now if you fancy a job in the most beautiful city in the world..

In terms of skill set we are looking for, the main thing is that they are
good software engineers rather than specific skills. However, here are a
few potential areas:
1. Experienced Java programmer (and/or other languages a big plus; Java
is not a pre-requisite).
2. Devops experience.
3. Good sys admin skills.
4. Distributed computing (i.e. understands the architectural
considerations etc).
5. Cloud/virtualization.
6. Javascript / web-dev (for one of them, perhaps)

Categories: FLOSS Project Planets

Rocking India

Wed, 2014-03-05 04:34

Last week in Gandhinagar, India, conf.kde.in finished. As Free Software conferences go, this one was more than decent! Thanks to a single track of high quality talks, all ~300 visitors were in the same room and in the breaks were discussing the same subjects. Of course this presents a challenge to the team picking the talks as they have to fit the entire audience, but the fact that the majority of visitors to this event are ICT students makes that relatively easy. That does not mean the talks were all beginner level: the talk by Peter about how to integrate Simon's voice abilities in applications (demo-ed on Amarok) and the 'Language renaissance' C++11 talk by Kevin certainly don't fall in that category. Yet, seeing the number of questions, most students were able to follow and learn from these talks.

My own talk was about where KDE, both technically and socially/organizationally, is going, also resulted in quite a few questions. They ranged from "what does RTFM mean" to discussions about involvement of startups and decision making processes. Much of what I talked about won't be new for KDE people who follow what is going on in our community quite closely. I mostly extrapolate from trends which have been visible for quite a few years. But for those who are new or less close to our community, I plan on putting it in a blog post or two over the coming days/weeks.

pictures or it didn't happenI took quite a few pics and made some videos out of that. It basically goes from the first to the last day...



India certainly is a nice country to visit, I greatly enjoyed the warm welcome of our Indian KDE community!

Categories: FLOSS Project Planets

kdevelop-python for python 3: beta release

Tue, 2014-03-04 14:20

Good news: Python 3.4 is about to be released, and with it kdevelop-python's first version to support Python 3. Until that happens in a few days, here's a beta:
kdev-python version 1.5.80-py3
http://download.kde.org/unstable/kdevelop/kdev-python/1.5.80/src/kdev-python-1.5.80-py3.tar.xz.mirrorlist
SHA256:99ca1ce97e2a7e553051be7505c17a921ab1aaf318999826ea285f771bcc538a

The kdev-python 1.6-py3 series is compatible with KDevelop 4.6 (kdevplatform 1.6) and is suitable for working with Python 3.x source code.
If you're only interested in using (as opposed to packaging or developing) kdev-python, you should consider installing kdev-python from your distribution's package manager instead of downloading the source code. There are a few things which need to be announced about this, so read on!
Embedded Python forkFirst and foremost, this abomination is finally gone in the -py3 series. Python 3.4 merged a patch which is required by kdev-python, and now we can use the system's python installation. This will especially make kdev-python comply with all distribution's requirements for packaging software, which means it will hopefully soon be available in all major distribution's package repositories.
This also means that kdev-python now depends on Python =3.4.
Python 2 compatibilityThe py3 series is not compatible with Python 2, and currently you can not install kdev-python and kdev-python3 side-by-side. I will try to address this restriction in the future and I will also publish a script to install the two versions into separate environments, but for now that's what is like. Especially, for packagers, this means that kdev-python must conflict with kdev-python3. The problem cannot be solved by renaming all the files, it also requires new UI and glue code to be written to select the correct language version, which I only have done partially as of today.
Branch names in kdev-python.gitI also used this opportunity to reorganize the branches in kdev-python.git a bit:

  • python3 is now python3-legacy (do not use)
  • python3-nofork is now python3; this branch is the most recent (unstable) version of the python3 version of the plugin, and compiles against kdevplatform master
  • there's a 1.6-py3 branch which is like 1.6 but for python 3.
If you had any of the renamed branches checked out, you might need to do git reset --hard origin/branchname. In the near future, master will also be renamed to python2 and python3 will be renamed to master (but not yet).
Feature comparison of kdev-python3 and kdev-python2Generally, the Python 3 version has all the features from Python 2 plus a few more and some bug fixes. Not all new Python 3 features are understood yet (the syntax is supported, but the semantics isn't, e.g. nonlocal does nothing), though. What is there however is support for function annotations:
If the expressions in a function annotation represent a type (i.e. not an instance or something different) they are used to adjust the function's return and argument types.I really hope this feature gets used for type hints, so this is a first step to encourage you to use it for that. ;)
Not all is awesome just yet, though: Although I'm not aware of any major issues, there will be regressions (things which were working in Python 2 but are now broken). There are always regressions, even with the ~90% test coverage kdev-python has. That's the purpose of this beta: go forth and test, and report all the bugs to the tracker so they can be slain!
Categories: FLOSS Project Planets

quick sprinter updates

Tue, 2014-03-04 12:39

Sprinter development continues to press forward, and in part that is thanks to Emmanuel Pescosta who has been porting KRunner plugins to the Sprinter framework since last week. There are now eight runners completed (activities, applications, calculator, datetime, places, powerdevil, recentdocs, uri, windows and youtube) and Emmanuel is currently in the middle of porting the audio player control runner.

This plugin porting is being done in a sprinter-plugins repository. With the plugins in this new repository, the Frameworks 5 dependencies have been dropped from the sprinter repository which now only requires QtCore, QtGui, QtNetwork and QtDeclarative. Note the lack of QtWidgets! There is a TODO file in sprinter-plugins that has a nice list of plugins left to do, and we are working on them one at a time in branches which get merged down into master once the plugin is fully ported and functional.
Stability and API tweaksAs we've been porting plugins we've also been finding places where the API could be better and identifying (and fixing) bugs in both libsprinter and the various Frameworks 5 libraries the plugins use. Par for the course, really.
The Runner API has gained a few helpers, such as a global cache for images generated for matches and MatchData which provides access to the QueryContext and RunnerSessionData objects while also handling QueryMatches that are generated. The latter process was just too fiddly and easy to get wrong, but MatchData makes it dead simple: just use the << operator to add matches as they become available and MatchData does all the rest.
The RunnerSessionData object is also now available via QueryMatch, which means Runners can access data members in the session object when executing matches. Basically that means less code and fewer allocations.
Sprinter now also has generic drag-and-drop support. In KRunner this had to be implemented by each Runner plugin, but with Sprinter the QuerySession model itself handles it all. As long as a QueryMatch has userData (a QVariant), it can generate a QMimeData for drag and drop.Plugin metadataOne of the issues I ran into was using Qt's new JSON-based plugin metadata system and the KService framework's idea of how this same data is represented. Up until now, KDE application have used .desktop files to register plugins, but the JSON metadata which is baked right into the plugin's library file (*.so) itself is more convenient and robust (as there is no .desktop file to lose). Sebastian Kügler had written a small tool to translate plugin .desktop files into .json files which provided the necessary starting point. It had some (known) limitations, however; in particular, it did not handle translations. It also carries some heavy dependencies from Frameworks 5 that shouldn't really be necessary. So I spent some time looking at what could be possible and came up with a small tool that generates json like this:


{
"PluginInfo": {
"Authors": [
"David Edmundson ",
"Emmanuel Pescosta "
],
"Contact": {
"Email": "emmanuelpescosta099@gmail.com"
},
"Description": {
"ar": {
"Name": "الأماكن"
},
"ast": {
"Name": "Llugares"
},
"be@latin": {
"Name": "Miescy"
},
"bg": {
"Name": "Места"
},
.. lots of translations ..
"en": {
"Comment": "Open devices and folder bookmarks",
"Name": "Places"
},
.. lots of translations ..
},
"Icon": "user-home",
"License": "LGPL",
"Version": "1.1"
},
"Sprinter": {
"GeneratesDefaultMatches": true,
"MatchSources": [
"FromFilesystem"
],
"MatchTypes": [
"FilesystemLocationType"
]
}
}

Note that applications can have their own blocks (in this case, "Sprinter") as it is entirely free-form JSON. The top-level PluginInfo block is what will end up getting standardized for KDE style plugins. This has allowed Sprinter to move information about plugins into the JSON, which means they can be filtered based on things like "what kind of results does this plugin provide" without actually loading the plugin.

We will be migrating from .desktop files to these json files across KDE's codebase as applications move to Frameworks 5, but this will not happen immediately as there are quite a few steps to get through first. I need to generalize the tool I wrote for Sprinter, adjust KPluginInfo internals a bit, massage the desktoptojson cmake macro and work with the translation team coordinator(s) to work the .json files into the workflow automation that currently is used with .desktop files. The JSON tool will be able to be used as both a one-time migration helper, turning .desktop files into .json files so that developers don't have to do this by hand, as well as an incremental translation updater so that new translations get merged in.

Performance wise, parsing these big blocks of JSON is nice and fast, with my laptop handling well over 1000 plugins per second. Reading the string data from random plugin files on disk can be quite slow, however, particularly with cold caches and rotating disks. To resolve that issue, David Faure will be working on a tool that we need anyways for application .desktop files that generates an incremental cache at installation time. This will be replacing kbuildsycoca and is being coordinated with other projects via freedesktop.org, even. One cache to rule them all.
Next Milestone: v0.2The milestone we're heading for now is "v0.2". The TODO items standing in the way right now includes some API review, checking the QML integration, a small improvement to default match generation, one important bug fix and the learning and autocomplete features. I expect these things to take most of this month, during which time more plugins will get ported as well.
There are many other items in the TODO file in the sprinter repository that are not yet scheduled, in case anyone is looking for interesting things to sink their teeth into.

Categories: FLOSS Project Planets

a suggestion about promotional pieces

Tue, 2014-03-04 09:06


In film making, it is better to show than to tell the audience what is going on. Great films have actors communicating emotion in their body language, facial expressions and how they deliver their lines. Less great films have scripts in which characters say things like "Wow, Joe, you sure are angry right now!"

There's an of echo of this principle when promoting products, though I'll focus here on the context of Free software: it is most effective to demonstrate how the product you are highlighting is great. Show the benefit, rather than explain the mechanism. But above all else: avoid the temptation to spend time describing why the alternatives are not great at those same things.


Most people are smart enough to draw comparisons on their own without them being explicitly written out for them. Most people will read a positive article and come to conclusions like, "Oh hey, that software is great at .. hm.. what I'm using isn't great at that.. interesting.. maybe I should check this out". 

Humans are actually pretty good at reaching those kinds of interpretations on their own. Just as we can read emotion into non-verbal communication, even when it's completely make-believe in a movie, most people are good at comparing what we have with what we are observing. Some people struggle with such things, but the majority do not.

Best of all, almost nobody is daft enough to complain that you're being positive about things. (Assuming you don't misrepresent the product, of course .. but that's a different issue.) However, when one spends time talking about the negatives of other products when the intent is to communicate positive things about the topic product, the audience tends to pay more attention to the negative parts. They are likely to become distracted from the intended topic, and the result is often even more distracting (and draining) rebuttals.


By way of example: in an article that I read today about a Free software product (in theory, at least), I counted 6 paragraphs about the topic product ... out of 25. The other 19 paragraphs were about other software products. Let that sink in for a moment: 19 to 6. 76%. Three quarters.

In those 19 paragraphs, the author mentioned 5 different competing products. Few, if any, of their audience use all 5 of those products, so the article was off-topic for most of the audience at least part of the time. The topic product was not highlighted; it drowned in a sea of 6 products. 5 to 1. 83%. Four fifths.

Instead of spreading the awesomeness of the title product, the author ended up writing about other products in a negative light. In doing so, they felt the need to offer caveats and observations about how people react to negative comparison pieces (this was obviously not their first stroll down this path), which only further distracted from the intended topic.

If you want to avoid "a flood of [negative] email/comments", as the article's author lamented, here three simple suggestions for both promotional and critique pieces:

  • Unless the article is an objective comparison piece, such as reporting the results of a rigorous benchmark, focus on a limited number of products. One, in fact, is a great number
  • Demonstrate the attributes of the product, rather than claim or explain
  • Let the audience create the comparisons in their own mind
I believe that if Free software was generally covered in this manner, it would contribute to Free software communities being more likely to celebrate each other's strengths (and support each other) while simultaneously being more apt to seriously contemplate their own shortcomings in order to improve. 
More constructive behavior, fewer schisms and less arguing? Sounds nice to me ... and we can still have our favorites :)
Categories: FLOSS Project Planets

Are your Qt builds going OOM?

Tue, 2014-03-04 07:15

If you’re, like me, regularly building Qt, you probably have noticed a decent hunger for memory, especially when linking Webkit. This part of the build can take well over 8GB of RAM, and when it fails, you get to do it over again.

The unfortunate data point is that my laptop only has 4GB, which is enough for most (but one) cases. Short of buying a new laptop, here’s a trick how you can get through this part of the build: Create a swap file. Creating a swapfile increases your virtual memory. This won’t make it fast, but it at least gives Linux a chance to not run out of memory and kill the ‘ld’ process. Creating a swapfile is actually really easy under Linux, you just have to know your toolbox. Here’s the quick run-down of steps:

First, create an empty file:

fallocate -l 4096M /home/swapfile

Using the fallocate syscall (which works for newer kernels, but only for btrfs, ext4, ocfs2, and xfs filesystems), this can be done fast. In this example, I have enough space on my home partition, so I decided to put the swapfile there. It’s 4GB in size, which should be plenty of virtual memory to finish even the greediest of builds — your mileage may vary. If you’re not able to use fallocate, you’ll need a bit more patience and dd.

As your swap should never be readable by anybody else than root, change its permissions:

chmod 600 /home/swapfile

Next, “format” the swapfile:

mkswap /home/swapfile

Then, add it to your virtual memory pool:

swapon /home/swapfile

You can now check with tools like `free` or `top` (tip: use the much nicer `htop` if you’re into fancy) that your virtual memory actually increased. Once your build is done, and you need your disk-space back, that’s easy as pie:

swapoff /home/swapfile rm /home/swapfile

If you want to make this permanent (so it’ll survive a reboot), add a line like the following to your fstab:

/home/swapfile none swap defaults 0 0

This is just a really quick tip, more details on this process can be found in the excellent Arch Wiki.

Categories: FLOSS Project Planets

System Tray in Plasma Next

Tue, 2014-03-04 01:53

In the past the system tray was implemented using the xembed specification. An application which wants to use the system tray creates a small window which gets embedded into the system tray. This means that the control over this area belongs to the application and not to the desktop shell hosting the system tray.

The result is that each item in the system tray may behave differently. Some set a different cursor, thus the cursor is flickering if you move from one icon to another. Some open/close the application when clicking the icon, some might provide a context menu on right mouse click or interact with further input events. But what is present in all cases is that there is no consistent behavior. From a user experience point of view this is very bad as the users learn that the system is inconsistent and works in an unexpected way.

Some years ago the Plasma hackers started to address these issues by implementing a new specification called Status Notifier. This specification got also adopted in Unity/Ubuntu as the Application Indicator. The new specification addresses the issues outlined above as the control is moved to the hosting desktop shell. This allowed us in Plasma to provide a consistent look and feel by using the monochrome icons and controlling which items to show when.

But still we supported the xembed system tray specification for legacy applications which were not adopted to the new specification. This means that all the issues are still present. It’s still possible that an item behaves completely different because it’s using the legacy protocol.

When we drafted the plans for the new implementation of the system tray in Plasma Next we of course also discussed the future of the xembed based implementation. It was a challenging topic as we want to go to Wayland and obviously an xembed based system tray icon won’t work on a Wayland powered system tray (yes in theory it could work through XWayland). Also getting the xembeded window integrated into our QtQuick based system tray is not the most trivial task.

Also some of the design aspects just don’t work with the legacy system tray. We want to support reasonable dpi and xembed items are hard coded to 22×22 pixels, that’s probably a lot of fun on a high dpi screen. We also want to categorie the system tray items, so that they are logically grouped. For that the status notifiers allow to tell us that it’s an application item and whether it’s currently passive, active or demands attention. This gives the host the required power to properly place the item. But with the legacy system tray we are just lacking this information and don’t really know what to do with an item.

QSystemTrayIcon as xembed in Plasma Current and status notifier in Plasma Next

When we discussed all these issues it became apparent that we do not want to invest the time in implementing the legacy system for Plasma Next. Nevertheless we do not want to break the functionality of existing applications. So we investigated ways of how we can ease the transition. KDE applications use the status notifier already and most GTK+ applications also use the appindicator library for unity integration, so they just work the way we want it. But for example the QSystemTrayIcon still uses the legacy system on X11. As it’s Qt there is also the QPA-API which allows us to provide Plasma-specific implementations through our platform theme. That’s the approach we decided to go: force any QSystemTrayIcon to use the status notifier API through our platform theme. Unfortunately the QPA-API was not sufficient for our needs and thus we had to extend it, which will be available in Qt 5.3. If Qt base is compiled with X11 support the QPA system is not used at all and the change to fix this slightly missed the 5.3 merge window. The last missing bit to get this work is in our frameworkintegration repository to implement the required API. This is currently under review which means that it will be available once we release our first release of Plasma Next. Though it will take until Qt 5.4 till the feature will be working properly. As a nice side-effect this also adds an implementation for QSystemTrayIcon on Wayland/Plasma.

Although we invested lots of time into making it work as smooth as possible there will be applications for which the system tray icon will not be working. Nevertheless, we decided to not implement support for it as we want to focus on the core and it was not justified to invest lots of time on an implementation only needed for a short period of time. Applications still using Qt 4 will hopefully soon get ported to Qt 5 and then the issue fixes itself. Overall from an end-user perspective this means that nothing really changes. The system tray is still going to work, in fact it will be better as all items can be scaled, themed, behavior adapted to input methods, logically grouped and much more. Nevertheless it’s possible that there are applications which still use the legacy protocol and that will break. In case it’s an open source application it will be easy to fix and we as the Plasma team are happy to help as much as we can. And in any case Plasma is a very flexible framework allowing you to implement an alternative system tray which supports the xembed system tray. It doesn’t have to be the core team which keeps the compatibility with the legacy system.

Categories: FLOSS Project Planets

Krita 2.8.0 Released

Mon, 2014-03-03 19:00

Today, the Krita team releases Krita 2.8. Krita 2.8 is a big milestone release, since this is the first release that is ready for end-users on Windows! Krita 2.8 has also many new features, hundreds of bug fixes, performance improvements, usability fixes and look-and-feel improvements. Let's join David Revoy for a tour of...

What's new in Krita 2.8?

Krita 2.8 running in Trisquel GNU/Linux 6.0, showing the default interface. The character on the canvas is Kiki the Cyber Squirrel, Krita's Mascot.

Author of screenshot and mascot: Tyson Tan

Krita 2.8 highlights: Windows version

Krita 2.8 will be the first stable Krita release for Windows. We have been making experimental builds for Windows for about a year now, and a lot of testers helped us to stabilize it. While this is not really a new feature for the Linux user, the step and the work on it was so huge that it does merit the 1st rank in this feature list! Most work on the Windows port has been done by KO GmbH, in cooperation with Intel.

Development: Dmitry Kazakov, Boudewijn Rempt.

Better tablet support:

Krita has relied on Qt's graphics tablet support since Krita 2.0. We consciously dropped our own X11-level code in favour of the cross-platform API that Qt offered. And apart from the lack of support for non-Wacom tablets, this was mostly enough on X11. On Windows, the story was different, and we were confronted by problems with offsets, bad performance, no support for tablets with built-in digitizers like the Lenovo Helix.

So, with leaden shoes, we decided to dive in, and do our own tablet support. This was mostly done by Dmitry Kazakov during a week-long visit to Deventer, sponsored by the Krita Foundation. We now have our own code on X11 and Windows, though still based on Qt's example. Drawing is much, much smoother because we can process much more information and issues with offsets are gone.

Photo: David Revoy testing Krita with four tablets.

Development: Dmitry Kazakov, Boudewijn Rempt.

New high-quality scaling mode for the OpenGL canvas

Krita was one of the first painting applications with support of OpenGL to render the image. And while OpenGL gave us awesome performance when rotating, panning or zooming, rendering quality was lacking a bit.

That's because by default, OpenGL scales using some fast, but inaccurate algorithms. Basically, the user had the choice between grainy and blurry rendering.

Again, as part of his sponsored work by the Krita Foundation, Dmitry took the lead and implemented a high-quality scaling algorithm on top of the modern, shader-based architecture Boudewijn had originally implemented.

The result? Even at small zoom levels, the high-quality scaling option gives beautiful and fast results.

Image by Timothee Giet

Development: Dmitry Kazakov, Boudewijn Rempt.

Krita Gemini

On Linux, the Krita Sketch user interface is now bundled with Krita 2.8, and users can switch from one interface to another. Krita Sketch and Krita Gemini were developed by KO GmbH together with Intel. On Windows, Krita Gemini will be available through Valve's Steam platform.

 {youtube}qiSGuCzRZFk{/youtube}

{youtube}lLwFJ0jF37s{/youtube}

Development: Arjen Hiemstra, Dan Leinir Turthra Jensen, Timothée Giet , Boudewijn Rempt

Wrap Around mode

The Wrap Around mode (activate it with the W key, or in View > Wrap around mode) tiles the artwork on the canvas border for easy creation of tiled textures. It is only visualized in OpenGL mode (Settings > Configure Krita > Display).

Development: Dmitry Kazakov.

New default presets, better tagging system

Krita 2.8 offer a new set of brush presets, with new icons following standards. Here is a screenshot with a sample of them.

Additionally, now It is easier and faster to assign tags to resources -- with a single right click.

Development: Sascha Suelzer

Resources: Timothée Giet, Ramon Miranda, Wolthera, David Revoy, and other Krita community artists.

Layer-picker

Directly select a layer by pressing the 'R' key and clicking with mouse/stylus on the canvas.

Development: Dmitry Kazakov.

Icons: David Revoy

Custom transparency checkboxes:

Transparency checkboxes represent the transparent colors. Now the colors and size of the checkboxes are configurable: You can change it in Settings > Preferences > Transparency Checkboxes. Here is a demo with a dark checker theme to show the halo around the Krita 256x256 *.png logo:

Development: Boudewijn Rempt.

New palette docker

It’s now easier to switch palettes with the Palette docker. Adding and removing a color can be performed directly on the docker. A set of new palette presets made by talented authors are now also bundled with Krita by default. You can display the Palette docker via: Setting > Docker > Palette.

Development: Sven Langkamp

Resources: Tim Von Rueden, Spencer Goldade, Richard Fhager, Kim Taylor, David Revoy.

Pseudo Infinite canvas

If you scroll the canvas a lot in one direction, you’ll notice a big button appearing with an arrow on it on the border of the screen  A single click on this big button will extend the canvas automatically in this direction.

This feature will help you to focus on drawing and never worry about the drawing surface available.

Additional options for the crop tool

The crop tool can now ‘grow’ (you can crop a document outside the canvas limit and extend the canvas) and also get decorations (third guidelines, middle crosshair).

Development: Camilla Boemann

Better color pickers

The color pickers get new icons and more options.

  • Ctrl + LeftClick --- Pick from merged image to Fg color
  • Ctrl + Alt + LeftClick --- Pick from current layer to Fg color
  • Ctrl + RightClick --- Pick from merged image to Bg color
  • Ctrl + Alt + RightClick --- Pick from current layer to Bg color

You can change the shortcuts (like Alt) for the Color pickers in the Settings > Configure Krita > Canvas Input Settings and unfold ‘Alternate Invocation’.

Development: Dmitry Kazakov, icons: David Revoy

New Color balance filter

Color balance changes the overall colors of an artwork via sliders and is used for color correction. It’s an ideal filter to give an extra mood to your artwork (warmer, cooler) or enhance black and white studies. You can find the filter here: Filter > Adjust > Color balance (Ctrl+B)

{youtube}Jos-2j4bgIE{/youtube}

Development: Sahil Nagpal, Dmitry Kazakov

Initial support for G'mic

Use hundreds of famous Gmic filters directly in Krita. It’s a first implementation, and still experimental and unstable. Also, it does not yet take the selection into account and doesn't show a preview yet.

You can find the feature under the menu: Layer > Apply Gmic actions.

Development: Lukáš Tvrdý, David Tschumperlé.

Clone array tool

This new feature creates a number of clones of the current layer so you can paint on it as if the tiles were repeated. The feature is convenient for the creation of isometric tiles.

You can find the feature in Layer > Clone Array

Note that, ‘Clone layers’ child can be moved independently from the parent layer with the move tool. You can clone any base layer, and position them to your liking ; they keep the dynamic properties to the live clone.

{youtube}IFKgqhTmM3w{/youtube}

Images, test and videos by Paul Geraskin.

Development: Dmitry Kazakov.

More custom shortcuts

Krita gets a new panel in the preferences (Setting > Configure Krita > Canvas Input Settings) to offer you the possibility to customize all related canvas shortcuts. That means: all the zoom- and color picker keys are configurable now.

Development: Arjen Hiemstra

More compact, better looking

A lot of work was done to make the Krita 2.8 user interface more compact, and dim the saturation of the icons to let the user focus on the canvas.

Other new Features:
  • Make it possible to copy the projection of a group layer
  • Make it possible to drop images on the startup page
  • Isolate layer or mask: right-click on the layer or mask, select "isolate" and temporarily work only on that layer or mask.
  • Make it possible to load ACT palette files
  • Make the channel docker work on the image, not the individual layer
  • Add a wraparound layer move mode
Removed Features
  • OpenShiva filter and generator scripting language. This is replaced by the G'Mic plugin.
Improvements of old features
  • Make it possible to end paths and selection paths with Shift-Click, Enter, Esc and clicking on a handle shown over the first point
  • Improve the reference images docker
  • Make predefined brush tips use a size parameter rather than scale
  • Update the default brush presets largely (new icons, new presets, better organization)
  • Make the fill layer command obey the alpha lock switch
  • Make the PSD import filter ignore malformed resource blocks
  • The resource tagging system has been hugely improved
  • Implemented anisotropic spacing for the Krita brushes. Now if you change the 'ratio' option of the brush, the horizontal and vertical spacing will be relative to the width and height of the brush correspondingly.
  • Added support for 16 bit color depths in Color Balance and Dodge and Burn Filter
  • Improve painting of sharp corners with the Drawing Angle sensor enabled ("fan corners feature")
  • Improve the UI of the Sobel Filter
  • Add support for loading single-layer PSD Grayscale images
  • Improve the image docker: displays a color picker when hover over the image in the docker, scale to fit filenames, use the theme highlight for the selected icons
  • Use 'size' instead of 'scale' to scale the predefined brushes
  • Make the fill tool obey the layer alpha lock state
  • Rework the brush outline cursor and add a combined brush outline and dot or crosshair cursor mode. Brush outlines now also behave sensibly with very big and very small brushes.
  • add option to hide preset strip and/or scratchpad in the brush editor
  • Make it possible to copy the projection of a group layer to the clipboard
  • Add the filter name to the filter layer or mask name
  • Make it possible to drag and drop an image on the startup window
  • Improve rendering of vector layers
  • Apply thickness parameter to the hatching brush
  • Add a shortcut (shift + Z) to undo points added to paths
  • Allow the multibrush to use an angled axis and have an option to show the axis
  • Improve mirroring of layers or masks (and make it four times as fast)
  • Improve the layout of many dialogs: imagesize, layersize, phong bumpmap, canvas size, modify selection, jpeg and jp2 export
  • Cut memory usage of pattern resources in half
  • Cut runtime memory usage when switching predefined brushes
  • Update the default workspaces, adding versions for high and low res screens
  • Pixel and vector selections can be converted to each other
  • Updated line smoothing algorithms
  • Fix saving compositions
  • New erase toggle icon
  • Fix a memory leak when using the brightness/contrast curve
  • Save resolution info to OpenRaster files
  • Make handling custom input profiles more robust, also when updating (this should be the first 2.7.9.x release where you shouldn't need to remove the input settings folder)
  • add a reset button to the input profile editor
  • Fix wraparound mode for the selection painting tools
  • Crop selection masks when activating the wraparound mode
  • Fix painting the cursor outline when there is no cursor outline
  • Make painting on high bit depth images much faste when the OpenGL canvas is enabled
  • Fix updates of the canvas rulers
  • Fix moving of a selection out of a layer
  • Fix saving indexed PNG files with current versions of libpng
  • Update to the latest G'Mic version and enable the G'Mic plugin on windows
  • Make the G'Mic dialog resize when selecting a filter (fixes layout issues)
  • Add a crash handler for Windows that uploads minidumps (the website that goes with it is not done yet!) and offers a clean restart
Optimizations
  • Rewrite the OpenGL canvas: it's now much faster and more robust, as well as more extensible.
  • Rewrite the tablet support to support non-wacom tablets on Windows and Linux and have better support for Wacom tablets. It is now possible to use multiple tablets (like Cintiq + Intuos) and issues with offsets are gone.
  • Freehand lines are now much smoother and more precise
  • Load all resources in the background, as soon as possible
  • Fix memory leak when downscaling an image
  • Fix memory leak when making selections
  • Make painting gradients much faster
  • Make selections much faster
  • Painting with predefined brushes is 20% faster

The Krita 2.8 release has been made possible by:

  • the KDE project and community which provided the infrastructure, the foundations and frameworks Krita has been built on as well as the community we are proud to be part of.
  • the Krita Foundation which, supported by the Krita user community has been able to sponsor Dmitry Kazakov as a full-time developer on Krita during this development period. Consider joining the Develop Fund to make sure Krita's development will continue at its current break-neck pace!
  • KO GmbH, responsible for most of the work of making Krita work on Windows and providing commercial support for Krita users, as well as the Krita on Steam effort.

Many Linux distributions will offer Krita 2.8 in their backports repositories. Windows users can download Krita 2.8 here, provided by KO GmbH.

 Muses Training DVD

The best way to get to know Krita is through the Muses DVD! Check out the contents, or order your copy now!

The regular price is € 32,50 including shipping.

Categories: FLOSS Project Planets