31 Oct 2014

feedPlanet KDE

Season of KDE - Let's go!

We're now in the countdown. The deadline for applications is midnight 31 October UT. So give the ideas page one last look:

https://community.kde.org/SoK/Ideas/2014

We even got one last task just now, just for you devops. Please talk to your prospective mentor and get their OK before signing up on https://season.kde.org/

If you have already signed up and your mentor has signed off on your plans and timeline, get to work!

31 Oct 2014 8:35am GMT

Window and Desktop Switcher moved to Look’n’Feel Package

Today we did an important change in how KWin will distribute its assets in the upcoming 5.2 release. When we started our thoughts about the Look'n'Feel Package and how we want to have meta themes for the complete Plasma workspace we also wanted to have this for the Window and Desktop switcher provided by KWin. So the structure of the Look'n'Feel Package already has all the pieces for including the Window and Desktop Switcher, but it was not used. Now we finally addressed this for the 5.2 release and moved the default switcher into the Look'n'Feel Package and KWin can locate the switchers from the Look'n'Feel Package.

At the same time we want to follow in a better way the "Simple by default, powerful when needed" approach. Our configuration should be simple and thus not offer an overwhelming amount of switchers. But it also should be powerful and thus one can install additional switchers either through GHNS or through your package manager. The result is that all the additional switchers so far shipped with KWin were moved to kdeplasma-addons repository. So all switchers are still available (powerful when needed), just not shown when opening the configuration menu (simple by default).

This also opens the door for including more switchers in the plasma addons repository. So far we had been very reluctant to add more switchers to the KWin repository. There were already too many switchers installed by default and it gives a feeling of we don't know what we want. By only installing one switcher by default this improves significantly and allows to add high quality switchers with enough differentiation to other switchers to the plasma addons repository.

The change has also some implications for users of non Plasma desktop environments wanting to use KWin as their window manager. By moving the switchers out, KWin removes some of the Plasma dependencies. All switchers provided by KWin are using Plasma components, the default switcher is part of the design concept for Plasma 5 following the same idea as other similar components. Thus KWin had a direct dependency on Plasma with the window switchers. This is now kind of solved by not offering any switcher at all.

My suggestion for desktop environment projects wanting to use KWin is to provide their own default Look'n'Feel package with a Window and Desktop switcher specific for their environment. On the other hand I don't see a problem with providing a simple fallback theme in KWin. And of course there are still the Desktop Effects for switching between Windows (CoverSwitch and FlipSwitch) installed by default and just need to be enabled.

31 Oct 2014 8:18am GMT

29 Oct 2014

feedPlanet KDE

knotification, kde connect and what we can do to make future connected

So, i was "politely" annoying people on kde channels last days because i found some interconnected pieces of KDE software that is not really integrated, but are screaming to do that.

All started when i questioned on our older knotify dialog, which for years we blamed to not be extensible, and mck182, our own Martin Klapetek, give me a class about the wonders of knotification on Frameworks 5. What lead me to this, is the desire of have several devices ( and possibly machines ) interconnecting their notifications, in both ways. and mostly KDE Connect is one of the middle guys to do that.

At same time, not expected but welcome, Albert Vaca blogged about the other side of my idea, the goals for KDE Connect. He clearly asked of usable plugins to do exchange of information on devices, like Android, iOS, etc..

Where we as KDE are not seeing is that this, like all of our frameworks, should be transparent, in a way that ANY frameworks application that uses knotification could directly access ANY device registered, in both ways.

Simple example:

We work daily on computers, mostly on the time want to be not bothered. We receive a message coming from some person on mobile, then suddenly, unless we muted, the notification appears on your screen, even far from your mobile. KDE Connect ALREADY do that. But, if is other way ? I have konversation irc opened, but i marked away, then someone from work ping me about some important thing. Konversation could pick this message and forward to my mobile. Or ANY device i choose to do that. This KDE Connect not do, and probably not designed to do.

And what could be done to aiming for this kind of future. ?

First of all, i think i should be got to VDG group to create a feasible knotification extended dialog where we can register multiple endpoints ,like, one mobile android, one mobile iOS, one tablet Windows, one desktop, and then we can simple connect our software notifications to hits on that. And receive from this or that mobile.

This conceptually is easy to imagine if we are using a diagram representing the devices and the notification sources, but i hardly imagine how this could be put the the desktop ground, that's why VDG is my bet.

Second, we need make some unification on the KDE Connect plugins idea and our knotification system, so talking talk as one framework, this i would love to discuss with Albert and Martin, and everyone that can buy this idea, if someone on the deep grounds of KDE labs already not started.

Hope someone buy this idea and push forward, because this is kind of thing is impossible to do it alone, and thanks our beloved KDE project is specialized to work as a family, and make things happens.

29 Oct 2014 7:19pm GMT

Kubuntu Vivid in Bright Blue

KDE Project:

Kubuntu Vivid is the development name for what will be released in April next year as Kubuntu 15.04.

The exiting news is that following some discussion and some wavering we will be switching to Plasma 5 by default. It has shown itself as a solid and reliable platform and it's time to show it off to the world.

There are some bits which are missing from Plasma 5 and we hope to fill those in over the next six months. Click on our Todo board above if you want to see what's in store and if you want to help out!

The other change that affects workflow is we're now using Debian git to store our packaging in a kubuntu branch so hopefully it'll be easier to share updates.

29 Oct 2014 7:11pm GMT

resolv_wrapper 1.0.0 – the new cwrap tool

I've released a new preloadable wrapper named resolv_wrapper which can be used for nameserver redirection or DNS response faking. It can be used in testing environment to route DNS queries to a real nameserver separate from resolv.conf or fake one with simple config file. We tested it on Linux, FreeBSD and Solaris. It should work on other UNIX flavors too.

resolv_wrapper

You can download resolv_wrapper here.

flattr this!

29 Oct 2014 11:24am GMT

28 Oct 2014

feedPlanet KDE

Put LXQt to work on Fedora 21 and epel 7

After i joined RedHat on some time ago, i slowly start to been involved more and more on Qt and KDE matters, even been more active joining Fedora KDE SIG, as a newbie :-).

One of the recently internal discussions lead to a necessity of bring lightweight desktop, at least one, in a polish state.

Since LXQt is finally came on 0.8.0 to Qt5, and we're actively working on Fedora 21, Qt5 builds and KDE Frameworks, and there are needs to jump and do at least the first usable state of the project, i jumped the wagon.

Eugene Pivnev was already working on initial packaging for Fedora, but i was advanced in the work when lead KDE packager from Fedora, Rex Dieter, told me, but at least i could use part of his work on sysstat packages and qtxdg packages. I borrowed his full packages.

was only two days of work and is still in the baby steps, that's why i packaged everything on Fedora copr buildsystem until we have proper review. We still have no group for install whole desktop and need to install packages by hand, and there's an explicit dependency on openbox as window manager, but was a quick decision to make things work fast.

I'm still deciding how to deal with lxqt-admin package due some dependencies, but is the only missing from the 0.8.0 series on http://www.lxqt.org

So, if you want to try it, recompile, help me, complain to me, you can find the work here:

https://heliocastro.fedorapeople.org/lxqt/

For the repository on copr:

Ps. I will not intend to compile/enable Qt 4 builds, only Qt 5 build because this is the direct goal

28 Oct 2014 11:35pm GMT

Accessibility is alive (QtSpeech progress, Jovie's deprecation)

For some time I've been considering what to do about Jovie which was previously known as ktts (KDE Text To Speech). Since before the first KDE Frameworks release actually, since kdelibs used to host a dbus interface definition for the KSpeech dbus interface that ktts and then Jovie implemented. I have a qt5 frameworks branch of Jovie, but it didn't make much sense to port it, since a lot of it is or could become part of the upcoming QtSpeech module. So Jovie has no official qt5 port and wont be getting one either.

What will Okular, KNotify, and other applications that want to speak to users do instead? The answer is QtSpeech. QtSpeech is a project started by Frederik Gladhorn to bring speech api's to all the platforms that Qt supports. It is still in its infancy, but is quickly improving. A few weeks ago when I built my kf5 stack with kdesrc-build I noticed that kdepim(libs?) was depending on it and it hasn't been released yet, so I got motivated to send some improvements to qt-project. Frederik and Laurent Montel have been pushing fixes and improving it also. It is as easy if not easier to use than the KSpeech dbus api (and doesn't require dbus either) and can be used to speak text on linux/unix, osx, windows, and android platforms so far. If you are an expert on any of these platforms please send patches to implement api on these platforms in their backends, the more eyes on this project the faster we can get it solidified and released.

You may be asking but what about feature X in Jovie that I will miss desperately. Yes there are a few things that QtSpeech will not do that Jovie did. These will either need to be done in individual applications or we can create a small framework to add these features (or possibly add them to QtSpeech itself if they make sense there). The features I'm thinking of are:

1. Filtering - Changing ": Hey QtSpeech is really coming along now" to "jpwhiting says 'Hey QtSpeech is really coming along now'" for KNotifications and the like. This could likely be implemented easily in knotify itself and exposed in the notifications configuration dialog.
2. Voice switching - Changing which voice to use based on the text, or the application it is coming from or anything else. This might make sense in QtSpeech itself, but time will tell if it's a wanted/needed feature.
3. User configuration - Jovie had a decent (not ideal, but it was functional) ui to set some voice preferences, such as which voice you wanted to use, which pitch, volume, speed, gender, etc. This will become the only part of Jovie that will get ported, which is a KDE Control Module for speech-dispatcher settings. This may also change over time, as speech-dispatcher itself possibly grows a ui for it's settings.

All in all, progress is being made. I expect QtSpeech to be ready for release with Qt 5.5, but we'll see what happens.

28 Oct 2014 10:05pm GMT

Work in progress

So what's happening since last release one month back? If you look only at source code evolution, you may think I already entered hibernation... not completely!

I've been following the packaging progress of the new release, to be sure I didn't miss something as for my first time (re-shipped UI translations and docs; and there is a new MLT dependency due to stabilizer change).
I'm also keeping an attentive eye on bug tracker and forums, to be sure nothing is breaking in users hands due to small changes introduced. Some very active Kdenlive fans already do a wonderful job, sometimes I feel I can add something, knowing the program's internals and backends.

In parallel, I'm trying to make some progress in migration to KDE project...
For what purpose? With better words than mine, the KDE manifesto explains the advantages of being part of such a wide community. Important aspects, regarding Kdenlive history, is long-term access to all the data, and mutualizing efforts not only for coding but also for services hosting (homepage, forum, mailing list, bug tracker, build bot), and for documentation and translation teams, etc.
The process is going on, with most data transferred to KDE servers, and completing the incubation steps one by one.

Last but not least, I'm spending lot of time in the code... but not writing a single line!
As discussed several times, the first step towards Kdenlive evolutions is code reordering/cleaning/refactoring. So I am studying the existing code (big parts I've never read entirely, only jumping at lines pointed by backtraces or analyzers...) and the unfinished refactored code from previous years. I'm taking notes, considering how to join both ends, and not far from starting to put my mess!
If you have advice on methods or tools for this step, please share!

28 Oct 2014 9:54pm GMT

Ceph Developer Summit 2014 - Hammer

The Ceph Developer Summit (CDS) for the next major Ceph release called Hammer started today some hours ago (2014/10/28). It's again a virtual summit via video conference calls.

I've submitted three blueprints:


We already discussed the Ceph security and enterprise topics. You can find the results/logs in the pad. The sessions are recorded and will be available afterwards.

If you are interested in Ceph development: now it's time to join the video conference call. You can find all links, the timetable and blueprints to discuss here. There will be a second track with a lot of interesting discussions tomorrow.

If you are interested to work e.g. on the Ceph security topic: check the pad and feel free to contact me.

28 Oct 2014 5:39pm GMT

Communicating from Plasma 5

Porting KDE Telepathy to Qt 5 and Plasma 5

I started working on that port back in the last KDE Telepathy sprint in Barcelona last April. Back then, I started to work on it because I have been doing heavy usage of the KTp plasmoids back when using the KDE 4 Plasma series and I didn't want to live without them. Back then, I only ported the minimum parts of ktp-common-internals so it would work with KF5, as well as the plasmoids. It was quite some work, but definitely worth it since I've been using them ever since, and it's worked wonderfully.

Last week I started working on those ports again, this time trying to start get all of them ready for end-users, first step being starting to port the rest of modules. It's worth mentioning how good the response has been, given that many people chipped in and gave some modules a go. It's a bit weird to do this kind of porting in KTp, because there's tons of little repositories to port rather than a big one, but I guess it's kind of part of it's beauty anyway… ;)

KPeople as a KDE Framework

KPeople is a Framework for fetching contacts from different sources (Telepathy, Akonadi, Facebook, etc) and unifying them into a same model,

An important part of making sure all of KTp works is ensuring that its dependencies are up to speed and this time the one I'd like to bring some light to is KPeople. The port is ready really, only depending on having some of its own dependencies from kdepimlibs in a releasable state, but it's also quite in shape too. It's a framework I'd really like to see shining in the next months.

Furthermore, I finally managed to find some time and get the automatic contact merging back on. This I started more than a year back and then Franck Arrecot worked to make some GUI interface for it, I think it's quite interesting. Take a look into it if you think it's interesting. :)

We need you!

Last but not least, there's still lots to be done. I'd like to aim for a nice and clean release of KTp by the end of the year, ready to be shipped with Plasma 5.3 and the applications, if the maintainers allow so.

So if you'd like to help, you can take a look at this Kanban board we created and take the tasks you'd like.

28 Oct 2014 3:29pm GMT

Window decoration themes in KDecoration2

Most of the window decorations available for KWin are not native decorations but themes for a native theme engine, such as deKorator, Smaragd, QtCurve or my own Aurorae. Themes are much easier to design and to distribute than a native decoration which has to be implemented in C++ and be distributed by the Linux distribution. Thus themes are an important part of the decoration system.

But we did a very bad job of integrating the themes into our configuration system. The configuration system only knows about native decorations and doesn't know that the native decoration is in fact a theme engine. This makes selecting a theme difficult, because a user has to first select the theme engine and then configure this to select the theme. Downloading new themes through GHNS is also difficult as again it requires to go through the configuration of the theme engine. We can do better.

With Aurorae I tried to address some of the problems by extending the configuration system to know about Aurorae, to be able to find the themes and render previews for it. This only worked because Aurorae and the configuration module are in the same source tree and could share code. Nevertheless it needed to have multiple code paths in the configuration module to load the native themes, Aurorae's SVG themes, Aurorae's QML themes and to render the three different kind of themes.

The solution works for one theme engine, but others are still not supported. Which is something I find very sad as it turns the theme engines to second class citizens and also looks bad as my theme engine has full support while others don't, while doing as a good or even a better job at themeing than Aurorae.

When I started to think about KDecoration2 and started to draft the API design I wanted to make sure that theme engines become a first class citizen in KWin. Last week I started to port the Aurorae theme engine to KDecoration2 and added the missing pieces to make KDecoration2 fully theme aware. The configuration of the selected theme is moved into the framework and the selected theme is passed to the native plugin when a Decoration gets created.

As a result of this work the command line options for kdecoration-viewer changed to:

kdecorationviewer [plugin] [theme]

which allows us to load for example the plugin for Aurorae with one of the SVG based themes:

To announce support that the decoration plugin is a theme engine, the decoration plugin has to put some information into the JSON meta data:

"org.kde.kdecoration2": {
        "themes": true,
        "defaultTheme": "kwin4_decoration_qml_plastik",
        "themeListKeyword": "themes"
    }

If the value for themes is present and true the framework will pass theme information to the Decoration. The framework looks in its configuration for the theme to be used, if there is none it falls back to the defaultTheme from the JSON meta data. The configured theme is passed to the Deocration when being created through KPluginFactory::create which takes a QVariantList as argument. As first element the framework passes in a QVariantMap with a key/value pair of "theme" as key and the configured theme as the value.

The last value of the meta data above is themeListKeyword which is used by the configuration module to locate all themes and provide them. I have not yet finalized the mechanismn so this is still experimental code. The keyword is used to create a different Object through the KPluginFactory. Right now this is a QObject with a QVariantMap property called "themes". Each key is the user visible name and the value is the internal plugin name. That's enough information for the configuration module to create a dedicated instance for each of the themes, create a preview for it and properly load/store the information. It allows us to have a configuration module which currently looks like this:

This new configuration module does not have any Aurorae specific code any more. It just knows about plugins and themes and can display them all. As one can see in this screenshot the KCM does not need to know whether it's a QML based theme (e.g. Plastik) or a SVG based theme (all the others). Which is a nice improvement to the situation before.

The mechanismn for locating the themes will probably change and be moved to KDecoration2 directly. It needs some more tweaks to expose GHNS information and support looking for new themes and deleting existing themes. So there is still a little bit of work to be done. But overall the state is now looking really good and I will soon start the review process for the new API so that KDecoration2 will land in Plasma 5.2. Of course that will be faster if we get more help to finalize the last missing pieces.

28 Oct 2014 12:37pm GMT

Shared Values ⇒ Shared Ideas? What we can Learn from Firefox Australis

If you're asking yourself "Huh? Australis? Is that edible?", then let me explain: Australis is the codename of the new user interface that was introduced with Firefox 29 (see the Article on the Mozilla UX Blog for some background).

Australis is the result of years of design and prototyping iterations, which were lead by the recently defined Firefox Design Values. Of those values, especially one looks quite similar to the KDE design vision/motto/slogan/tagline/mantra (yes, it has been called all that!) that I described in my last blog post and which is described in more detail in the "Design Vision and Principles" page of the KDE HIG (though I swear to Stallman that I hadn't read the Firefox Design Values when I came up with that tagline):

Theirs:

Balances power and simplicity - Firefox is simple and easy to use, clean and straightforward in its design. But simplicity is a means, not the end - the end is understanding and user-agency.

Ours:

Simple by default - Simple and inviting. KDE software is pleasant to experience and easy to use.

Powerful when needed - Power and flexibility. KDE software allows users to be effortlessly creative and efficiently productive.

Though not identical, these values are very similar in their meaning: Both the Firefox and KDE User Experience teams aim for a simple overall user interface, which still offers easy access to powerful features for those who need them. The similarity becomes clear when one compares what I've outlined in the aforementioned blog post with the principles which the Firefox UX team derives from that value:

80/20/2: default to surface minimalism and easy access to the rest

user-agency and understanding, not just less

Even though neither of us blatantly copied the other (they were first, but I only became aware of that document after we wrote ours), the similarity isn't purely coincidental, either: Both KDE and Mozilla have started off from a quite tech-savvy user- as well as contributor-base, and both aim to reach a broad(er) audience without taking the powerful features which advanced users need away from them.

And - not surprisingly either - both groups came to a similar conclusion for how to solve this dilemma: Putting those things which most people use regularly on the main user interface, while offering well-integrated access to the more advanced and/or less frequently used features. In the Australis UI, there are three tiers of access to features (from most to least frequently used): The toolbar (actually, also the tab bar, but for the sake of simplicity I'll just subsume both under "toolbar"), the button menu and the (hidden by default) classical menu bar.

However, the tricky part is that for many applications there isn't "the normal user" and "the advanced user", and therefore there isn't "the normal feature" or "the advanced feature". The same person can for example be a power user for graphics software who needs a very powerful tool for their job as a designer, but at the same time be an absolute novice when it comes to software development tools, because they have only just started teaching themselves some basic programming to be able to whip up some interactive prototypes.

A browser is one of those applications: It's an application which every user with an Internet connection uses (with the majority using it every day they use a computer), which many use "casually" but many also use for highly sophisticated tasks (and in case of ChromeOS even for pretty much every task). Therefore there is no chance to say "An average browser user uses this and that feature, whereas an advanced browser user uses this and that feature". The same goes for frequency of user scenarios: Some people use their browser mostly for reading on websites, others use web applications more often than "plain" websites, web designers/developers frequently use highly specialized tools.

So what did the Firefox UX team do to accommodate to that uncertainty? They made the user interface highly customizable, allowing users to populate both the toolbar and button menu with whatever UI elements they wish, as well as to rearrange the elements within each area freely. This means that users can adapt the UI to their personal usage patterns. And even UI elements that are created by addons are treated just like the ones that ship with Firefox by default.

Screenshot of Firefox in Customize mode

What my Firefox looks like in Customize mode - And yes, I've put the search bar in the friggin' button menu, because I mostly use web shortcuts instead!

Is this high degree of customizability worth the effort for every application? Certainly not. For applications which are only rarely used or for which usage patterns are indeed highly consistent across users, a static user interface works just fine and has the big advantage for users that if they forget where a certain function is, they can consult the documentation or ask someone else, both of which are not possible if they can decide where to put it.

However, for applications which are used frequently and for which usage patterns vary between users, a flexible user interface solves the problem that even the best user research and most carefully designed default user interface cannot accommodate to the users' idiosyncrasies. And even though some companies or designers may have made some people believe that an option is always a sign of bad user interface design, one of the dialog principles laid out in section 110 of the ISO 9241 ("Ergonomics of Human System Interaction") is still "suitability for individualization".

So, for all who feared that somehow KDE now decided to be "like Apple" or "like GNOME", which translates for them to "Not giving the user any options", fear not: In those cases where it makes sense, a flexible UI is precisely the embodiment of "Simple by default. Powerful when needed."


Filed under: KDE, User Experience

28 Oct 2014 1:00am GMT

27 Oct 2014

feedPlanet KDE

Beyond the color pickers

KDE Project:

Andy, Thanks so much for picking up the topic of color pickers (pun intended).

I'd like to add to the topic by discussing cases when accuracy is not as important at results. In this case there's a problem of abundance of choice. You don't have time to quickly and correctly pick one from the 16777216 colors. Plus alpha value? Come on! Whenever you're confronted with a photoshop/gimp-like color picker you either choose random color, or single color that's globally predefined in a palette. I also understand that very few 'casual' users maintain own palettes for consistency.

What's worse, for subsequent choices of colors, the same difficulties repeat with various level or annoyance. I know advanced users sometimes add currently picked the color to a Custom Colors table of the color picker, but that's all.
(Andy covered the color swatches topic, that's a clear improvement). The table as it's present in KDE apps and other apps, is global per your OS account, so context-less, as if it was designed in hurry. It comes from old Windows software, early 90's. The context is not even at application level, and obviously not related to the project you're working on. (BTW, this is why I think the story of KDE Activities would better start at (smart) apps level not at desktop level)

I'd like to mention there are other approaches. I mean especially themes, explained on my blog 3 years ago:

https://blogs.kde.org/2011/12/14/fruits-css2-shared-themes

So the themes can address the problem of abundance of choice. In one go you can pick a color set, and application can use it to apply defaults to your document title, heading, maybe some background. Possibilities depend on what the content is for given application.

Second thing is live previews, something that benefits from the power of themes. Without them you pick a color without seeing the context. Picking your selection in a 10 pixels box is not the same as observing it temporarily applied to the destination area (filling an object's backgound, setting text color, etc.). So very the same blog mentions Document themes selector picking MS Office 2010 as an example:

You try the selection by hovering your mouse pointer and you immediately see the live preview. As engineers and they say it's hard to implement. That shouldn't stop us. I believe such concept can play well with side context panels we have already documented in the HIG.

All that, naturally depends or application, but the usefulness is beyond of the color picking. One can imagine color theme for widget style can pick the colors (and paragraph settings, font settings, by the way) from the theme.

For all this to work, we need developers that are willing to apply the concept to their apps. And an organized effort to avoid dozens of app-defined, incompatible theme notations/definitions floating around. Ideally, the place of favourite theme(s) is the KDE system settings. For me that's not just a proposal without a follow up, Kexi will be applying it at one point.

Comments? Please share them on the VDG forum.

27 Oct 2014 8:24am GMT

Start your Season of KDE engines!

Season of KDE (#SoK2014) was delayed a bit, but we're in business now:

http://heenamahour.blogspot.in/2014/10/season-of-kde-2014.html

Please stop by the ideas page if you need an idea. Otherwise, contact a KDE devel you've worked with before, and propose a project idea.

Once you have something, please head over to the Season of KDE website: https://season.kde.org and jump in. You can begin work as soon as you have a mentor sign off on your plan.

Student application deadline: Oct 31 2014, 12:00 am UTC - so spread the word! #SoK2014

Go go go!

27 Oct 2014 7:32am GMT

Testing A11y in Plasma 5

I made the jump on all available computers, and am now running Plasma5 on the foundation of Kubuntu 14.10 everywhere. Once the upgrade work was done, I filed a few bugs, and then wanted to test accessibility (often abbreviated a11y), since Qt5 has a11y built-in.

Jpwhiting in #kde-accessibility found Frederik's blog: http://blogs.fsfe.org/gladhorn/, where I found that the key was setting up the environment to expose KDE software to the mostly-GNOME a11y applications. For now this must be done via the commandline:

gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true

It is a work-around, but it works!

Once orca is installed, and the environment is set up, you will hear each letter as you type, and when you open menus, they are read aloud. I understand it will read IRC channels aloud, but I don't want this! Some people use this method to study while they do something else, which sounds cool.

KDE developers, please test your ported code for accessibility. If you don't have time, please ask for testers to file bugs.

Distro testers, please test your install screens and upgrade paths for, at the very least, successful screen reading. There is really is now no excuse to keep blind users from using our wonderful software.

Qt 5 is accessible! Are we using it to serve our blind users?

27 Oct 2014 7:09am GMT

26 Oct 2014

feedPlanet KDE

KDE makes Qt

Recently I was trying some statistics on the qtbase-module (where QtCore, QtGui, QtWidgets and so on lives) and was wondering who made them.
Not based on their current paid affilation, like Thiago's graphs, but if each commit was made by a person coming from KDE.

So, I got hold of Thiago's scripts, a lovely mix of perl and zsh, and a QtBase git repository. First steps was to try to classify people as person coming from KDE or not. Of course, I'm a KDE person. Thiago is a KDE person. David Faure is a KDE person. Olivier Goffart is a KDE person. Lars Knoll is a KDE person.

By the help of the KDE accounts file, and some of the long time KDE contributors, I got after a half day of work a good list of it. Then next steps was trying to put it into Thiago's perlscripts

All of it kind of succeeded:

qtbase-KDE.graph

So, KDE people makes up for 40-60% of the weekly commits to QtBase. This is again shows that KDE is important to Qt, just as the reverse is. So, let's keep KDE healthy.

KDE is running a end-of-year fundraiser over here https://www.kde.org/fundraisers/yearend2014/. Go ahead and donate, and help KDE stay healthy. For your own sake. And for Qt's.

26 Oct 2014 9:36pm GMT