I spent some free time today getting caught up on the large backlog of phonon-gstreamer bugs. Towards the end, I started to have delusions of grandeur: Imagine a phonon-gstreamer codebase that doesn’t require supporting a zillion different audio frameworks, and instead belays that task to something that I don’t have to maintain.

My question here, is how many people would throw a fit if phonon-gstreamer dropped support for ALSA and OSS, and forced everyone to use pulseaudio by way of GStreamer’s excellent pulseaudio support?

Hold on, lower your pitchforks for a minute. Let us consider the audio framework landscape in the modern world:

• Pulseaudio is the One True Way for audio playback in Gnome
• For 90% of the support questions we handle in #kde-multimedia, the solution is “use pulseaudio”.
• Pulseaudio can handle using OSS, ALSA, Bluetooth, or whatever your audio output is, through one consistent entry point
• It is a total headache to figure out any bugs in your audio when music goes from Amarok->Phonon->Phonon-GStreamer->(ALSA, OSS, Pulseaudio, god knows what)->Speakers->Earholes

Additionally, I really don’t feel like testing phonon-gstreamer on all those different kernel-level interfaces with exotic setups every time I fix a bug and am afraid I’d introduce another twelve. The PulseAudio folks seem to do a fantastic job at that already. Phonon isn’t meant for real-time playback or production studio quality audio. Thats what Jack is meant for.

I can’t think of a good reason why we shouldn’t stand on the shoulders of giants by making PulseAudio handle all the hard stuff on Unix involving massaging PCM formats, equalizers, matching playback category with output device, enumerating outputs both real and virtual, volume control, etc.

If you can, leave a comment on this post. I’m not making an official statement saying that I’m definitely removing ALSA and OSS support from phonon-gstreamer, I’m merely asking for feedback to see what can be done to fix things at all levels in the audio stack.

Sirko brought up the idea to organise a hackfest together with developers of applications for Linux desktops and experts interested in colour management. The idea behind that event was to bring interested developers together, support them in implementing color management in their software and move forward that topic across desktops and distributions.

During the recent LGM we found a chance to involve Richard Hughes and planed together about what we like to do during the hackfest. We spotted three main areas of interest: desktop applications including window managers, web browsers and printing. These topics are already worked on, but in a scattered way.

As example, Gwenview is a really great application for managing pictures. But it has no color management implemented yet. Color management in KWin is worked on during the GSoC this year, but in the opposite color management in the compositing manager mutter on the GNOME side is far away as can be read here. Not many web browsers support color management and if they who do, it is often incomplete. The SVG v2 standard will for example introduce additional color management features compared to SVG v1. So it is now the right time to get these implemented in order to be well prepared. For the KDE printing stack there is also a GSoC project this year, but also the Linux Foundation has a working group for this topic.

So, by meeting in person in one place, we want to get something done and build a good understanding of the role of each participating group for a working end to end colour management.

The hackfest will very likely happen in Brno in the Czech Republic at the Red Hat offices. A good time appears later this year 16th till 19th November. Now we like to collect more ideas, speak to people and sort financial issues.

Continuing with my previous post about the Zeitgeist team’s improvements with regards to speed, there’s a nifty tool in the sources I wrote yesterday that uses a genetic algorithm to find the slowest queries you can throw at the engine.

If you’re not familiar with genetic algorithms, here’s a brief review of how they work:

• Start off with an array of numbers, with each index corresponding to a particular attribute of the problem.
• Evaluate the fitness of that genome
• Simulate evolution of the successful genomes by crossing, mutations, etc, just as you would with real DNA chromosomes

In the case of this Zeitgeist tool, the chromosome refers to a query, and each allele (index of the array) refers to an attribute of the query. Here’s a relevant comment from the sources:

# Chromosome to data mapping:
# 0, 1 - Timerange begin and end. If both are zero, we use timerange.always()
# 2 - The search type. Anything over 30 is a dead individual.
# 3-5 - Specify template properties. Anything besides 0 and 1 is dead.
# 3 - Specify a subject interpretation
# 4 - Specify a subject manifestation
# 5 - Specify an event actor

Using the super cool pyevolve library, implementing a genetic algorithm is super easy:

def eval_func(chromosome):
  query = buildQuery(chromosome)
  if query is None:
    return 0

  start = time.time()
  results = engine.find_events(*query)
  overall = (time.time() - start)
  return (results["find_events"]*2+results["find_event_ids"]*4+results["get_events"])*1000

genome = G1DList.G1DList(6)
genome.evaluator.set(eval_func)
ga = GSimpleGA.GSimpleGA(genome)
ga.evolve(freq_stats = 1)
query = buildQuery(ga.bestIndividual())
assert query is not None
print query, len(engine.find_events(*query))

Let it run for a long while on a big database, and you end up with a query that takes forever. Due to how evolution works, it isn’t the longest running query, but it is certainly one that takes a long time.

Hey everyone, I am riding 100 miles (161 km) for Chicago’s 2012 Tour de Cure. My goal this year is to raise $1,500, because last year I was blown out of the water by the generosity of the people at my mom’s work, the KDE community, the cycling community, and a few friends. So, if 300 of you donated the minimum $5, I would make my goal Last year I had a blast doing this ride and completed it in 6.5 hours. My other goal this year is to finish it in under 6 hours.

To donate, you can click on the Support image above, or go to my Tour de Cure page. Scroll down, and on the right hand side you will see “CLICK HERE TO SPONSOR ME”, click it. I appreciate any and all help!

Donate To My Tour de Cure 2012 Ride is a post from Richard A. Johnson's blog.

We are pleased to announce the new  open-slx Weekly News 18 in the Formats PDF and EPUB.

You can find in this week (abstract):

• open-slx Screencast: Updating Plasma Active
• Vivaldi Tablet with 8GB
• Tizen runs Android Apps too
• Installing Java 7
• and more...

The open-slx Weekly News 18 are downloadable there [881,31 kB] (PDF) and there [11,94 kB] (EPUB).

Because Textwriters are needing Coffe just  donate anything.

Original Post: http://community.open-slx.com/news-42-open-slx-weekly-news-18-published.html

Technorati Tags:Technology, News, Mobile App, Tablet, Tablets

Download: PDF-Format [881,31 kB] EPUB-Format [11,94 kB]

Dieser Wochenrückblick wurde unter der Creative Commons by Share Alike veröffentlicht.

Wir freuen uns, den neuen open-slx Wochenrückblick 18 in den beiden beliebten Formaten PDF und EPUB zu veröffentlichen.

Unter anderem in dieser Woche:

• open-slx Screencast: Plasma Active updaten
• Vivaldi Tablet mit 8GB
• Tizen fährt auch Android Apps
• Java 7 installieren
• und mehr...

Der open-slx Wochenrückblick 18 kann hier [833,53 kB] (PDF) und hier [19,10 kB] (EPUB) heruntergeladen werden.

Da Textschreiber immer wieder einen Koffeinschub brauchen, kannst du hier einen Kaffe spenden.

Original Post: http://community.open-slx.com/news-41-open-slx-wochenrueckblick-18-veroeffentlicht.html

Ältere Ausgaben können hier eingesehen werden.

Technorati Tags:Technology, News, Mobile App, Tablet, Tablets

Download: PDF-Format [833,53 kB] EPUB-Format [19,10 kB]

Dieser Wochenrückblick wurde unter der Creative Commons by Share Alike veröffentlicht.

Europes biggest event arround Linux and Open Source – LinuxTag, is’nt far away anymore and Oyranos will participate on it. LinuxTag take its place in Berlin from 23.-26. May on the exhibition area arround the Funkturm. On saturday the 26th of May I will present together with Sirko an talk about colour management – “Bring Color To The Game“. The talk will not introduce Oyranos as CMS, it will more explain what color management is and about the actual status on free desktops. We want as well to talk about what a user needs to get colour management running. During LinuxTag I will be reachable on the openSUSE booth for questions and introduction into profiling and bring some colorimeters.

As mentioned in my previous post, you can now link your documents, files and folders to your activities. That, by itself, isn’t much. The first thing that you could do with that is show the linked documents on your desktop by using the Contour layout, which is quite nice even outside of Plasma Active, but although usable on the desktop as well, it has some problems.

So, how to make this available to the normal users, you ask? Easy – make it available to the normal file managers via KIO – just type activities:/ in Dolphin, Konqueror or the Folder View applet, and you’ll get a list of all activities, and files that belong to them.

You can see what it looks like in the screenshots. At the moment, it is a bit buggy, but it will work as expected for SC 4.9.

Hi all,

I am sri13 @ IRC. Last year, I completed GSOC under KDE and did some work in Krita. Now, I am not doing any thing in krita and I am feeling very bored as there are no challenging tasks. .

Any new challegenes to do in KDE or Krita . . ?

Please tell me . . ,I wanna try different . .

A picture of Oz Fox from Stryper I took ages ago. We’re rock stars.

So, after working on the cool “Large image displaying library” in KHTML I decided to look into other parts of KHTML, and work on getting my lolcat page working in KJS/KHTML. It turned out quite easy, KHTML is very friendly, both the code base and the community around it.

So, after fixing a couple of other small issues, I decided to take on Twitter which has stopped rendering properly in KHTML/KJS. Thanks to the excellent debugging support in the khtml kpart, it only took a couple of minutes to track the error down. The issue turned out to be that the maximum stack size in the KJS interpreter was too small, Twitter is serious about its Javascript. The issue is then if we should bump up the maximum amount of stack frames, since if we eat up all the available stack space we can get nasty crashes without Dr. Konqi (the crash reporting tool) showing up. But for now KHTML in git should render Twitter just fine.

Lastly, a tip if you want to debug production sites with long lines in KJS; turn on the “Reindent Sources” option if it is slow, the katepart embedded in the javascript debugger isn’t a fan of the long lines most websites put together.

And as usual, thanks to the KHTML developers for help with everything.

Having got the first release of LightDM out the way we're looking forward to what our future releases should entail.

0.1 was released purely so we could start testing and get feedback as to what features need to be added for subsequent releases. In some areas we are already ahead of KDM, and even the LightDM frontend used by Unity but in some areas 0.1 is really lagging behind and there's a lot to be done before it's "complete" and ready for distributions to ship.

What's coming in 0.2

Multi-screen support

I have a branch which hopefully makes some progress on this. However with only one screen this is somewhat hard to test! Ideally I need to work with upstream to come up with a QML plugin that we can use in KSplash-QML too.

Live previews in the config tool

One of the special features of LightDM-KDE is that it's really easy your settings, such as change your wallpaper or add a company logo. I'm adding a way to show a live preview of this whilst you change the settings.

Seamless logins

KSplash has a QML backend, we're powered by QML...by copying the same code from our greeter theme to a KSplash theme it will look identical. This means we can load the same background you chose for your login screen, and we won't have the issues with differing aspect ratios that we see in KDM.

General improvements

0.1 shipped with several bugs, broken translations, poor keyboard shortcuts, and loads of UI bugs. We're slowly fixing these, including getting a lot of these changes merged upstream back into Plasma Components. Massive thanks to Aurélien Gateau for his help on this.

Powermanagent

This has already been implemented thanks to Alex Fiestas.

How to try out in Kubuntu 12.04

Even though LightDM isn't the default display manager in Kubuntu it made it's way into the repositories, installation and testing is one command away. You will then be prompted as to wether you want KDM or LightDM to be your default display manager. You don't need to change the default just to try it.

sudo apt-get install lightdm-kde-greeter

Can I see a screenshot that isn't related to anything you just said?

Sure! Blogs without screenshots are dull, and it's hard to screenshot power management....

How to get involved

Report bugs to https://bugs.kde.org/ selecting the product lightdm. If you want to get involved coding or designing;,drop me an email (which can be found at the top of any header file of the source)! Or join #kde-lightdm on Freenode.

As Trever blogged yesterday, the Zeigeist team has been busy with tweaking the DB and the engine. During that process tools and benchmarks have been developed to make the tweaking and testing more interesting. Trever will be blogging about that tomorrow so make sure to check his blog.

Our end goal is  trying to scale the engine to be able to handle a few billion events just as fast as it can handle a few hundred thousand. While we are not there yet we managed to have some pretty nice stable results for the first iteration. A lot of results show more than 100% speed enhancement. In other words a lot of queries from our standard benchmarks now consume more than 50% less time to execute. Here are some graphs of our benchmarks.

Green indicates the 0.9 release

Yellow indicates the new trunk

Most notable performance enhancement is querying Zeitgeist with a specified timeframe (from data x to date y).

Same queries with an open timeframe also improved

We also have a copy of the Synapse queries benchmarked

The queries here are typical queries used to extract info from Zeitgeist. So right now the team is really happy with the initial results. For Synapse on my local DB (over a year old), all my synapse queries perform under 0.08 seconds. We still can get more out of this. The trick here was improving our indexes and our sql query generator.

Next month we will be going through another iteration.

A repeated problem we run into when using QMake is that it focuses on being a build tool, and because of that does not implement some features for executing parts of the project (like tests). Others ran into this issue as well, as for example this discussion of specifying run configurations from QMake on Qt DevNet indicates. Multi-part projects often consist of dynamic libraries that contain the features, and applications and tests that link this library. Amongst other things, this approach allows tests to link objects which contain the application’s code. Now when the tests are executed, the dynamic linker needs to be able to pick up the freshly built library and link the test with it at execution time. Projects usually run test cases with make test, and ideally the tests should execute out of the box after the sources have been configured and built (out of the box meaning that no tweaking of the environment variables should be needed between make and make test). After all, it should be as easy as possible for developers to execute tests.

This is also a problem in IDEs like Qt Creator, but also others – for every build configuration (having separate shadow build directories), the developer needs to configure the library path before being able to debug the application. This second problem needs to be fixed in the IDEs. For the first one – configuring test runs from the QMake .pro file – we have developed a solution called QMakeTestRunner that takes care of the problem. QMakeTestRunner assists in setting library paths when running unit tests in products built with QMake. It makes make test work out of the box right after makefiles have been generated. It is Free Software, published on Github, and small and easy to integrate into projects as a Git submodule. Much of this information will go into the documentation on Github as well.

Motivation, aka “The Problem”

QMake as a build system is simple and complete for building code, but it lacks a simple way to run unit tests dependent on libraries which are part of the project itself. In this case, paths which are created in the build directory need to be added to the dynamic linker library path before the tests can be executed. Especially with shadow builds, this would require manual setup, and make test would not work out of the box after QMake has been run.

QMakeTestRunner, aka “The Solution”

As soon as any target in a QMake project has the testcase attribute assigned to CONFIG, QMake automatically generates a target called check that runs this test. Unfortunately, make check does not allow the manipulation of the linker paths before running the tests either. QMakeTestRunner contains boilerplate code that wraps QMake’s make check target with a new one called make test, and through variables specified in the QMake file allows the specification of paths to be added to the linker path.

Usage

QMakeTestRunner is intended to be used as a git submodule to the main project. It should not require any modifications to be used. It requires Python to be in the path, checks for it, and the QMake run will fail if Python cannot be detected. When using other version control systems than Git, QMakeTestRunner should be small enough to simply be copied into the project as a subdirectory.

Project configuration example

The following example adds the directory libs/ in the project build directory to the linker path. It assumes the QMakeTestRunner repo is located under 3rdparty/QMakeTestRunner. The path where the dynamic library is generated in below the output (build) directory, which is why it is prefixed with OUT_PWD:

TEST_LIB_PATHS += $$OUT_PWD/libs
include( 3rdparty/QMakeTestRunner/testtarget.pri )

To trigger extra diagnostic output of the test runner, add

TEST_VERBOSE = 1

before including testtarget.pri.

make test

Once testtarget.pri has been included, a test target is defined in the makefiles. Simply run make test to execute the original make check with the necessary paths.

Mac OSX Frameworks

Frameworks on OSX are a different kind of library. The framework path is passed into the dynamic linker using a different environment variable. To specify a framework path, set the TEST_FRAMEWORK_PATHS variable before including testtarget.pri.

TEST_FRAMEWORK_PATHS += $$OUT_PWD/frameworks

Setting up QMakeTestRunner as a Git submodule

Using a Git submodule has the benefit that the code for the runner does not need to be duplicated into the repository of the project that is supposed to use it. It also makes it easy to pull updates to the test runner by simply updating the submodule to a new revision. To add the submodule as 3rdparty/QMakeTestRunner in your project, follow these steps:

> mkdir -p 3rdparty
> git submodule add git://github.com/AgileWorkersSoftware/QMakeTestRunner.git 3rdparty/QMakeTestRunner
> git submodule init

The directory 3rdparty/QMakeTestRunner should now contain the current revision of the test runner scripts.

License, contributions, issues and support

QMakeTestRunner is Free Software licensed under the GPL, version 3. Contributions to it are welcome, please propose them as Github pull requests. To submit a bug report or feature wish, please use the Github issue tracker for the project.

Commercial support for QMaketestRunner or general issues with QMake is provided by Agile Workers Software. We are happy to help.

I just came up with a trick question. Let’s see if you can solve it.

Why will 20 become smaller when you add another zero?

Update: Commenters have been very creative. My original solution was to add the zero at the front, yielding “020″, which is 16 in many programming languages. Other solutions are “20^0 = 1″ include “0.20″.

The Zeitgeist team has been hard at work lately. We recently moved from Launchpad and Bzr to freedesktop.org and git, just in time for the 0.9 release. Since then, Seif and I have been hammering away at making a bunch of speed improvements and trying to scale the engine to be able to handle a few billion events just as fast as it can handle a few hundred thousand.

Our first experiment has been focusing on the sqlite indexes. This one index tweak appears to increase our benchmark speeds by almost 45%:

CREATE INDEX event_timestamp_subj_interp_subj_id_id
                   ON event(timestamp, subj_interpretation, subj_id, id)

And here’s the graph to prove it:

Shorter lines are better. Blue is the 0.9 release, and the orange is the tiny index change. All of our raw data is in this google spreadsheet, so feel free to have a look. I can’t guarantee that you’ll immediately understand the information, but I’m open to explain it to those interested.

Kdenlive 0.9 has just been released. We encourage all users to upgrade to this new version that fixes many small issues and should improve the overall user experience. Some of the new features include:

Improved effects workflow

The effect stack was rewritten to allow adjusting parameters for several effects in one go. Effects can also be grouped, groups can be saved and effects or groups can be dragged and dropped onto another clip

Automatic audio alignment

If you have been working on a scene with several camcorders, Kdenlive can now automatically align the clips in timeline using the audio.

Easy import of online resources

Kdenlive now has an online resource browser that allows you to easily preview and import audio, graphic and video resources from archive.org, freesound audio library and open clip art.

Usability improvements

Many small improvements and bugfixes should make your use of Kdenlive nicer and smoother, for examples:

• Recording can now be monitored through the audio and color scopes, audio normalization can analyse audio for better results
• Allow audio only recording
• Clips can be sorted by date
• New effects from MLT / frei0r: video stabilizers, IIR Blur, etc
• Offline editing (Backup the project with proxy clips only to work on less powerful computers)
• See a more complete changelog on our Kdenlive 0.9 info page

Get it!

The Kdenlive 0.9 source tarball can be downloaded from the KDE servers: download link.
Binary packages will be announced in our download page

The future

A big thank you to all the people that contributed in one way or another to improve this new version. Some bugfix 0.9.x releases will be made when necessary, but in the background we are working (well mostly Till) on a refactoring to cleanup the code and hope to reach the 1.0 milestone by the end of the year, thanks to the fantastic success of our fundraising campaign.

As usual, users are welcome to join our forums and bugtracker to report problems.

read more

This post is an update about the research project from my team, described a few weeks ago.

From the time we published the last post about QML Styling until now we have worked on this set of issues/features:

• Get feedback about research project
• Combo Box Component
• Combo Box Customizable Style
• Combo Box Plastique Style
• SubControl Styling
• Understand SceneGraph internals
• Understand other native platform internals

What is our vision now?

Last week, we have read a few blog posts, and talked with a few Qt & KDE application developers about what should be the priorities for creating desktop and mobile applications. I have presented our proposed solution for using native look and feel for QML widgets, how to create custom styles from scratch, using the CustomStyles helper, and how to apply them with the ApplicationStyle API.

Based on the feedback and the blog posts, my team sat down and came with the following set of statements which summarize our vision for what sould be our focus of our current research:

1. Usable QML components with native styles working ASAP
Developers want to code entire application UI with QML having native look and feel.
2. Easy customization
It's all about making easier to create components with different look only by filling in some templates to avoid code repetition for standard. These custom styles are targeted to be like a short cut, obviously for more complex behaviour, you will need to create your own style.
3. Powerful customization
Enabling to use QtQuick components as the style can make widgets look fluid. It's desirable that the new styling mechanism is at least as powerful as QStyle is today. As a first shot we want to enable styling do at least what QtWidgets style does. The main point here is to maximize the results and minimize ramblings about what is style or not.
4. Styling modularization
By spliting the old style scheme in a set of widget style, enables us to create the style for each component/platform independently instead of the monolithic QStyle. Now it's easier to mix styles and change them on demand more easily.
5. Disruption with QtWidgets
We wish to make this component set free from QtWidgets modules. One of the reasons is because now it is considered done and it's desirable for the new components set that it can be expanded. We also don't want to link with QtWidgets module, because the real dependency should be the QStyle only. The current ApplicationStyle approach, shows us that the styles depends only on QtQuick. One of the possible paths to achive this is:
1. Move QStyles out of QtWidgets with a few adaptions on it.
2. Create a SceneGraph based native styles when possible

Combo Box

We decided to choose the ComboBox component to work on because it is one of the most complex (if it isn't the most). Because of the complexity, we hoped that during its development we could be enlightened of knowing if we are in a correct path, what still misses, and what should be the next steps.

As we did in the Slider approach, which was divided in 3 different subcomponents:

• Handle
• Groove
• Tickmarks

While creating the ComboBox, we decided to divide it in 4 other subcomponents:

• ArrowStyle
• BackgroundStyle
• TextEditStyle
• DropListStyle

We basically mimicked how QStyle splits the QComboBox painting into subcontrols. The drop list was also delegated a sub style as QComboBox does with it's internal QListView. We haven't worked on the drop list style since it would require a native style such as Plasma's ListItemView, which also would rely on a ScrollBar.

Creating the combo box component showed us that positioning and size hints can be more tricky than it looks like.

The ComboBox got stuck in a few parts and unfortunately it's not complete right now. However we took the questions and answers from its development. :-/

Positioning and Size Hints

This topic of discussion came out when we were thinking about a theoretical style in which the ComboBox would be in the left. One of the issues we had in mind while developing the editable ComboBox was how to set a MouseArea that can know when set the focus to the text edit or to open the drop list. This would be possible to be done with current QStyle, since on it's approach the QWidget reads the subcomponent's size hints by the subControlRect method from QStyle.

We would like to have this positioning information on the style as well. The approach can be similar to what happens with the size, which you can read it from the widget reference.

The following piece of code is a simple example of how size hints can be taken:

// ComboBox.qml
Item {
    property alias arrowStyle: arrowControl.sourceComponent

    Loader {
        id: arrowControl
        width: arrowControl.implicitWidth
        height: arrowControl.implicitHeight
    }

    MouseArea {
        anchors.fill: arrowControl
        onClicked: {
            // do some action
            // ...
        }
    }
}

ArrowStyle defines the implicit size, which works as a size hint, and the position where they are. These properties together can work analogue to subControlRect, as they hold the same info. The component may ignore such hints and override the properties values, such as Slider's Handle style position.

// MyComboBoxArrowStyle.qml
Image {
    implicitWidth: 50
    implicitHeight: comboBox.height
    x: comboBox.width - width // Arrow could also appear on the left by setting x = 0
    source: "arrow.png"
}

One may ask "Can't I have a round button with a circular hit area?" That's more complex than just setting hints for the geometry of sub control styles. As we defined in our view we're trying to be at least as powerful as QStyle. We consider that, by now, we should be strict at least about the interaction styling of the components themselves. From my point behaviour difference should be defined as the component API.

Sub StyleComponents Sets

Another discussed topic was about the fragmentation of the style property of the components. For instance, take the following Slider style code:

// Slider style now
Slider {
    grooveStyle: CustomGrooveStyle { ... }
    handleStyle: CustomHandleStyle { ... }
}

The Slider style property is fragmented as more than one property. We thought that these properties could be centralized with a SliderStyle as an aggregator object. This helps API clarity for style manipulation since we can play with a single object reference that represents the component style, enabling to handle it atomically.

// Proposed Slider style usage
Slider {
    sliderStyle: CustomSliderStyle { ... }
}

with CustomSliderStyle as:

// Proposed Slider style creation
// CustomSliderStyle.qml

// Aggregated style object
SliderStyle {
    grooveStyle: CustomGrooveStyle { ... }
    handleStyle: CustomHandleStyle { ... }
    tickmarksStyle: CustomTickmarksStyle { ... }
}

or more compactly:

Slider {
    sliderStyle: SliderStyle {
        grooveStyle: NativeGrooveStyle { ... }
        handleStyle: CustomHandleStyle { ... }
    }
}

or even:

Slider {
    sliderStyle {
        grooveStyle: NativeGrooveStyle { ... }
        handleStyle: CustomHandleStyle { ... }
    }
}

This issue is only an idea only discussed between ourselves. It would be nice to have feedback about these API.

Insights from SceneGraph & QStyle study

The isolated study of the scene graph internals (getting rid of QQuickPaintedItem), and how it could be used to create the new styles directly on it, didn't told us much in fact. Only that is better we keep doing these styles in QML and using Scene Graph itself to create sub elements that needs a more refined handling.

On the other hand, the Windows and Mac styles investigation was very important to decide our next steps. It showed us that these styles uses platform native APIs to draw the native widgets on each platform on pixmaps. So we would have to deeply study these API to create our own implementation of native styles using the scene graph. For these reasons isn't too simple to give up from QQuickPaintedItem some time to going deep on them right now since our time and head count is limited.

Two steps forward, one step back

After the feedback from other developers, one of the main thing people want more is to have a widget set working with the native look and feel as soon as possible. Keeping this as our primary focus, we will left the restriction of depending on QtWidgets for now. So we will focus on having a working solution that can be easily replaced after. Fortunately, our proposed modular solution for styling fills that requisite.

Just a couple weeks ago we launched the renewed download.kde.org. The layout I had chosen was dated before it was implemented it seemed. I was pleasantly surprised that a couple days after I announced it, the webteam had the first mock-ups ready for a new theme. This general theme is called Neverland, and has been rolled out slowly on a few sites already.

I think the webteam deserves some more credit for their work, so I’m going to highlight some of the remarkable things they pulled of the last months. The first ‘challenge’ they had was to give the new bugzilla a new layout. The new bugzilla was rushed from the sysadmin side, this was caused by a serious security issue we found. Hence the webteam only had a week to come up with some layout. And they did. Unfortunately a week was too little time, and at the launch the new layout was not so good. Then the team had to operate for a few weeks with a smaller team, but when the team was back on full strength, bugs.kde.org was fixed and it now rocks. I’m very proud at it.

Another project the webteam took on was to apply Neverland to forum.kde.org. The forum is a big site, with a lot of users. Unfortunately the forum is very underestimated by developers. It really is a fun place to hang around. Some developers now start to discover the forum and are very excited about it. It’s a great place to communicate in a pleasant way with actual users of your application. Much better than via bugs.kde.org in my opinion. If you want a forum for your application, just let the team know. Anyhow, they rolled out the new theme there too, which was a big chunk of work. If you want a *very* cool impression of the changes and about the possibilities of Neverland, just look at their Tour!

And more recently they applied the new Neverland theme to download.kde.org. Instead of a boring index of all files and folders, it now has a nice background, nice fonts and a nice expandable header with the contents of the .message file in each folder, all in line with the rest of the Neverland-sites.

So a big thanks to the webteam. Especially Sayak Banerjee, Eugene Trounev and Ingo Malchow!

As we slowly move more and more software from svn to git, we need an extra anonymous git server. If you are a company providing virtual machines and love to do something for a big open source community, this is your chance!

We are looking for a virtual machine which we can use and which will be dedicated to provide an anonymous git service to our community. We had a couple of such servers until recently, but we had to say goodbye to one, because the SVN-size of our repo is also still growing, and that server did not have enough disk space to do both. Another one had some load issues, so we had to make a choice to take that one out of rotation too. We still have 2 left, but one malfunctioned today. And then suddenly we were left with only 1.

Hence this call for a new server. The specs are not that high, just some disk space (50GB would be nice), root access, somewhat good processors and a good internet connection.

We do have a small preference for a company this time, people offering a part of their private server is always appreciated, but for an anongit server, we would like good uptimes, quick response when there are problems, etc. Other wishes we have involve a KDE pastebin for images, some enhancements to files.kde.org and some more, so if we get more than one offer, I hope we can use the servers for those wishes.

In return you get list at our famous Thank You-page. We can even put your logo on there if the offer is very generous :) If you are interested mail us at sysadmin@kde.org.

This is coming about two weeks later than I would have liked, so the next pre-release is likely to come in two weeks to make up. Similarly, the monthly bugfix release for Muon Suite 1.3 is two weeks late. For that, I’ll likely just skip this month and release 1.3.2 in two weeks, as there haven’t been any serious bugs that need immediate attention. (Thankfully)

Anyways, I am proud to announce the first alpha release for Muon Suite 1.4. The Muon Suite is a set of package management utilities for Debian-based Linux distributions built on KDE technologies. Packages for Kubuntu 12.04 “Precise Pangolin” are available in the QApt Experimental PPA. Here’s what’s new:

Muon Discover

Muon Discover is the experimental new frontend in the Muon Suite. It was written by Aleix Pol Gonzalez as part of his employment at Blue Systems, and it’s pretty nifty. You can read more about it here.The idea is to create a Muon frontend that makes finding new software super-simple, and doing so with a little bit of flair. It’s no secret, that even though the existing Muon Software Center has some “bling” here and there, the interface is somewhat spartan.

Muon Discover will eventually replace the Muon Software Center, but not just yet. Muon Discover is young, and its interface is written entirely in QML. KDE has not issued a set of comprehensive UI guidelines for QML usage on the desktop, and currently Muon Discover is using the Plasma QML components for several of the controls in its interface. While we wait for a set of guidelines, the classic Muon Software Center will remain the default application installer, allowing Muon Discover to mature in the process. The QML Desktop Components (slated for release sometime around Qt 5.1 or 5.2, or so I have heard rumored) and KDE Frameworks 5 will likely be a big part of KDE’s QML standardization, so expect Muon Discover to replace the Muon Software Center in around that time period.

Muon Software Center

With all the buzz around Muon Discover, you may think that nothing has been done with the Muon Software Center. Well, never fear, as there are several cool new features and user experience improvements that have been made for Muon Suite 1.4.

• Thanks to work done by Aleix, the Muon Software Center no longer has to reset the view back to the main page when it reloads the APT cache. This provides for a much smoother experience whilst installing multiple applications.
• A progress view has been added for displaying currently running and pending transaction.

• All Muon frontends now use the KDE proxy, if set. (Before it only used the system proxy and APT proxy settings) Priority goes: KDE proxy, APT proxy, system proxy.
• Additional pages of application reviews can be fetched now.
• A busy throbber has been added to the main page to provide feedback during launch.
• Application views can now be sorted by Name, Rating, Buzz and search relevancy.

• By popular request, non-application packages can be toggled for application views. (Though you’re still probably better off using the Muon Package Manager for package management.)

• Ratings are cached locally so they can be accessed in the absence of an internet connection.

Muon Package Manager

The Muon Package Manager has not been forgotten, either. Highlights for the 1.4 release mainly include tools for better handling Multi-Arch packages on 64-bit systems.

• By default, when a package is available for both the native and foreign CPU architectures, only the native package is shown. Installed packages of any architecture are shown. This means no more duplication of most every single package in the archive polluting the Muon package view.
• A new architecture filter has been added, allowing you to filter packages by their architecture.

• The new Debian package categories “Education” and “Introspection” have been added to Muon’s category filters.
• A package’s archive component is now displayed in the technical details tab. (E.g. universe, main for Ubuntu packages)

Muon Update Manager

• Technical package items in the “System Updates” category are now displayed by their package name, as the description is not always descriptive enough.

Changelogs

Detailed changelogs for LibQApt and Muon can be found here and here, respectively.

Join us?

The Technikum Wien provided a nice place and great support for the LibreGraphicsMeeting. Many thanks to them. LGM happened together with the Linuxwochen Wien and developers and users could talk about graphics and arts themes. Additionally to the one presentation track over all days, we had BoF’s and workshops. Some of us took the chance to present to a non LGM audience and meet people there too.

The LGM talks covered lots of OpenCL projects. That means modern GPU computing power is available to open source graphics components in a much broader way. As the use of OpenCL is supported by the Mesa software implementation, there is some kind of guarantee, that OpenCL programs will run on elder hardware. That means OpenCL can be used without the need for developers to provide a fallback mechanism, which simplifies adoption.

The colour management talks provided lively discussions around many topics like printing, displaying and open hardware. We discussed as well the impact of introducing colour management in frameworks like GEGL. As mizmo showed interest, I explained the most basic terms of ICC rendering intents in a small BoF using ICC Examin. Animtim compiled and installed Oyranos from sources and wrote already a small tutorial on how to build Oyranos on kubuntu-12.04.

Markus Raab presenting Elektra on LGM 2012 Vienna

The presentation of Markus Raab about the Elektra configuration gave to me some impressive insights into the concepts and flexibility of that small framework. The really cool thing about this library is it can abstract a lot of details and provide additional features, which can be added on run time like DBus support. He announced a new release of Elektra as version 0.8.0 during the event.

The metalab was for most people from countries without a similar open hardware/open source collaboration zone a impressive visit. We all enjoyed to could stay there for some hours and felt, this place is much in the spirit of most LGM contributors.

Nathan Willis @ LGM 2012 Vienna

During Nathan Willis workshop about the Create wiki, we discussed to start a email list for create users. That list is supposed to provide help and talk about experiences with graphics applications and help from users for users.

Sirko (alias gnokii) and Tobias (alias houz) played diplomat and managed to channel information in a way that Richard Hughes and I could finally meet in a productive atmosphere and continued talking about technical issues. At the end we found a mod to work again together on standards inside the OpenICC collaboration project. I am pretty happy with that change. So, thanks to all parties who helped with that.

Café Hawelka Vienna

Tatica, Pete, Sirko and I walked around on the last day in Vienna and relaxed in the café above.

I'm pleased to announce the new available EBook-Manager calibre package 0.8.51 for openSUSE.

Whats happend since the last Minorupdate?

New Features

• When switching libraries preserve the position and selected books if you switch back to a previously opened library.
• Conversion pipeline: Filter out the useless font-face rules inserted by Microsoft Word for every font on the system
• Driver for Motorola XT875 and Pandigital SuperNova
• Add a colour swatch the the dialog for creating column coloring rules, to ease selection of colors
• EPUB Output: Consolidate internal CSS generated by calibre into external stylesheets for ease of editing the EPUB
• List EPUB and MOBI at the top of the dropdown list fo formats to convert to, as they are the most common choices

Bug Fixes

• E-book viewer: Improve performance when switching between normal and fullscreen views.
• Edit metadata dialog: When running download metadata do not insert duplicate tags into the list of tags
• KF8 Input: Do not error out if the file has a few invalidly encoded bytes.
• Fix download of news in AZW3 format not working
• Pocketbook driver: Update for new PB 611 firmware.
• ebook-convert: Error out if the user prvides extra command line args instead of silently ignoring them
• EPUB Output: Do not self close any container tags to prevent artifacts when EPUBs are viewed using buggy browser based viewers.
• Fix regression in 0.8.50 that broke the conversion of HTML files that contained non-ascii font-face declarations, typically produced by Microsoft Word

Where to get Calibre?

You just can add the Documentation:Tools Repository and install it via YaST or zypper. You also can use one of the following 1-Click Installer:

This one for the openSUSE 12.1 Documentation:Tools (12.1 Standard)

This one for the openSUSE 12.1 Documentation:Tools (12.1 KDE 4.8)

It can take some time, because of the packages are build but at not available in the Repo. Should come next time.

You wish to donate anything to the Packager?

Sounds good. Just read Donate a Coffee. 

You want to try out calibre with faenza Toolbaricons?

Have a look there (German Article). If you don't know german, just add the Documentation:Tools Repository and install "calibre-faenza-icons".