February 18, 2018

The Machine

The Raspberry Pi3 is a small single board computer that costs around $35 (USD). It comes with a network port, wifi , bt , 4 usb ports , gpio pins , camera port , a display out, hdmi, a TRRS for analog A/V out. 1GB of ran and  4 ~1GHz armv8 cores Inside small SOC. Its storage is a microSd card they are a low cost and low power device. The Touchscreen kit is an 800×480 display that hooks to the Gpio for touch and dsi port for video. To hold our hardware is the standard touch screen enclosure that often comes with the screen if you buy it in a kit.

Raspian?

Most of the time it is sufficant to run Raspian the official distro that is made for the raspberry pi. raspian is a fork of debian as much like debian it has some old packages. Inorder to build AtCore (with the gui) you need at least qt5.8 raspian comes with 5.7. This is not a show stopper but compling qt does take quite some time and can easily take a week if we were to build it on the rpi itself. Setting up a cross complier will save you alot of time but even on my fastest machine it will still take some hours to build qt for the pi. I decided it would instead be faster to install a completely unsupported OS on the device. I was going to install install arch linux on the rpi. Arch is a rolling distro that ships with qt 5.10.

Doubly Unsupported

Arch linux on the raspberry pi is what you might call “doubly unsupported” That is that the raspberry pi foundation does not support running arch on the pi. You only get support from the arch community. Arch Linux is not officially supported on platforms other then x86_64 the rpi running on arm.  Worry not for the Arch community has some forks such as archlinux-arm this is what we will be installing. Like most things arch you get some instructions. After getting the os installed its still arch so you only get a cli interface on your first boot and are left to set up the rest of the system.

Post Install

For my system I installed plasma-meta , xf86-video-fbturbo-git and sddm. With those I was able to have a working plasma shell. I also installed dolphin, kate and konsole as well as the few atcore dependencies. I then added my user to the uucp group so I was able to r/w to serial devices and restarted. When all the dependencies are installed you can proceed to build atcore. Since this is arch we can simplify the building part just by using atcore-git from the aur. Im Happy to say it took only 5minutes and 48 seconds to build atcore-git on the rpi. I then used pacman to install the atcore-git pacakage and it was time to see how our gui was looking on such a small screen.

The Result

At first the contents of the atcore-gui spill off the screen due to the way our docks are tabbed, however since they are docks you can just adjust them to make a quick usable interface. After adjusting the gui AtCore worked exactly the same as it does on other systems. Below you can see a picture and video.

IMG_20180217_110445

Can do better

There is lots of room for improvement. Atcore-gui does not save any settings. You’ll need to move the docks around each time you launch the program. Atcore-gui can not automaticly connect to a device on launch. again for reasons of not saving settings This gui is of course not really made for use on a touch screen and it does seam to work good enough to use. Some non atcore changes on the system itself would be nice. A few services running on the pi would improve this over all. Mjpeg streamer or another method of streaming video from the attached camera on my printers extruder. Uploads are done via stfp thats not always easy for everyone. The pi does not launch atcore-gui on start up . Small stuff like this could easily be adjusted. I was really just playing around to see how atcore ran on the rpi. I was very happy when this worked well.

February 17, 2018

Me complace compartir con todos vosotros que en poco más de un mes podremos disfrutar de una nueva emisión del Maratón Linuxero, un proyecto colaborativo de emisiones en directo a través de Software Libre que el pasado mes de septiembre logro el hito histórico de emitir de forma continua 8 horas de noticias relacionadas con el Software Libre.

Nueva emisión del Maratón Linuxero

El próximo 31 de marzo podremos disfrutar de una nueva emisión del Maratón Linuxero, un evento de radiofónico que sigue recogiendo lo mejor de los podcasters del panorama del Software Libre para ofrecernos horas de entretenimiento e información sobre este apasionante mundo.

De esta forma, tras la increíble emisión del 3 de septiembre (donde KDE España estuvo muy presente) y las posterior réplica en forma de mini Maratones del 15 de octubre y del 31 de diciembre, nos presentan otra nueva emisión, también de tamaño reducido, que mantiene vivo públicamente este proyecto.

Nueva emisión del Maratón Linuxero

En esta ocasión el tema escogido es Edición Multimedia con lo que nos esperan unas cuantas horas en las que aprenderemos una buena multitud de cosas sobre el apasionante este mundo, el cual ya no es el patito feo del Software Libre.

Más información: Maratón Linuxero

¿Qué es el Maratón Linuxero?

Maratón Linuxero 1.2Para definir el Maratón Linuxero lo mejor es leer lo que nos dice su página de Acerca, aunque os hago un breve resumen:

El Maratón Linuxero es un proyecto creado por podcasters y oyentes de GNU/Linux que quieren realizar un evento en directo a través de aplicaciones y servicios de software libre.

Su origen fue ver si era posible sacar adelante emisiones en directo como otras organizaciones han hecho, pero sin recurrir a sistemas privativos, o por lo menos que sean afines al Software Libre o de código abierto.

No solo están colaborado podcasters, sino también administradores de sistemas, desarrolladores, diseñadores y artistas para realizar el blog, servicios, carteles, promos y vídeos del proyecto.

Para finalizar este pequeña entrada os dejo las otras vías de contacto con el Maratón Linuxero:

Blog: https://maratonlinuxero.org/
Telegram: https://t.me/maratonlinuxero
Mastodon: https://mastodon.social/@maratonlinuxero
Twitter: https://twitter.com/maratonlinuxero
Correo: maratonlinuxero@disroot.org maratonlinuxero@gmail.com
Youtube: https://www.youtube.com/maratonlinuxe…
Radio Maratón: http://www.radiomaraton.ml
App Android Radio Maratón: https://maratonlinuxero.github.io/Mar…
Feed Podcast Maratón Linuxero: http://maratonlinuxero.github.io/feed…
Feed Podcast Maratón Linuxero formato ogg: http://maratonlinuxero.github.io/feed…
Audios en Archive.org: https://archive.org/details/@maratonl…

 

Howdy everyone! So many folks have asked me to set up a Patreon page that I’ve gone and done it: https://www.patreon.com/ngraham

By supporting me on Patreon, you’re helping me provide the focus, direction, support, and technical contributions that work to turn the KDE software suite into a lean, mean, bug-free productivity machine, and get it distributed well so that our users have great options for getting our software.

Of course, I’m only one man; what really matters is not me, but rather you! KDE’s greatest strength is its passionate community of developers and users, who work tirelessly to develop, improve, polish, promote, and use KDE software. I truly couldn’t do this without all of you, and in fact, I wouldn’t even want to! All of you are the reason why I work so hard on KDE software. Thank you, so very much.

Become a patron

We’ve been focusing like crazy on the Krita 4 release. We managed to close some 150 bugs in the past month, and Krita 4 is getting stable enough for many people to use day in, day out. There’s still more to be done, of course! So we’ll continue fixing issues and applying polish for at least another four weeks.

One of the things we’re doing as well is redesigning the set of default brush presets and brush tips that come with Krita. Brush tips are the little images one can paint with, and brush presets are the brushes you can select in the brush palette or brush popup. The combination of a tip, some settings and a smart bit of coding!

Our old set was fine, but it was based on David Revoy‘s earliest Krita brush bundles, and for Krita 4 we are revamping the entire set. We’ve added many new options to the brushes since then! So, many artists are working together to create a good-looking, useful and interesting brushes for Krita 4.

It’s still work in progress! But we want your feedback. So… Download the new Krita 4 development builds, and start doodling, sketching, painting, rendering… And then tell us what you think:

Do the brush preset survey!

Apart from the new brushes, and the bug fixes, there’s also news for Linux users: we updated our AppImage build scripts, and the new appimage includes Python scripting and the Touch UI docker. Note: by default all scripts are disabled, so you need to go to Settings/Configure Krita/Python scripts and enable the scripts you want to use.

Help with the release!

We’re having our hands full with tasks like coding, bug fixing, manual updating… More than full! One task that looks like it’s going to slip is creating a cool what-new-in-4 release video. So: if you’re good at creating videos and want to help the team, please join us on #krita on irc.freenode.net and help us out!

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes. On Windows, gmic-qt is included.

Linux

On Linux, you need to download the gmic-qt appimage separately. You can configure the location of gmic-qt in Krita’s settings. Krita requires the “XDG_DATA_DIRS” environment variable to be set. Most distributions do this, but if yours doesn’t, set “XDG_DATA_DIRS” to “/usr/local/share/:/usr/share/” as a workaround. Next build Krita will do this by itself.

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

OSX/macOS

The minimum version of OSX/macOS is 10.11

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

md5sums

For all downloads:

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

This is going to be a double-header: today we’re discussing Discover as well as Kirigami–KDE’s UI framework that facilitates writing convergent apps that look and feel good on both the desktop and a mobile device.

…At least that’s the idea. The truth is, KDE users have voiced a lot of criticism for how well this works out in practice. An especially common complaint is that the desktop user experience gets short shrift, and Kirigami apps feel like big phone apps.

We’ve heard this feedback, and we’re acting on it. Over the past week, we’ve been hard at work to make Kirigami UI components behave more appropriately on the desktop, and have Discover make use of them instead of its custom components.

So I have exciting news for everyone who has complained about Discover’s design being too mobile-ey and wasting too much space: that’s going to be a thing of the past. Here’s how the Featured page now looks in git master:

No more huge header with the picture of the coffee cup that nobody liked! This is not the final appearance; there’s still polish work to be done, and we are heavily iterating over Kirigami to improve it to make the Desktop UI a first-class citizen. But it’s a model for what we’re going for.

We also added some other much-requested user-centric features to Discover, such as making reviews more prominent. Have a look!

  • Discover now shows the top three reviews right on the app page (KDE bug 380514, implemented in KDE Plasma 5.13):
  • Discover’s review submission pop-up is now more user-friendly and makes it impossible to accidentally submit a one-star review (KDE bug 390426 and Phabricator revision D10500, improved in Plasma 5.13):
    Note the presence of a close button! Another much-requested feature for Kirigami pop-ups.
  • You can now use Discover to write an app’s first review (KDE bug 390339 and KDE Phabricator revision D10476, fixed in KDE Plasma 5.12.1):
  • Kirigami scrollable pop-ups (used for Discover’s review page) no longer let you scroll beyond the content in desktop mode (KDE bug 388942, fixed in KDE Applications 5.44)
  • Kirigami non-scrolling pop-ups (used for Discover’s review input pop-up) now have correct bottom padding (KDE bug 390032, fixed in KDE Frameworks 5.44)
  • Kirigami toolbar headers are bit taller their titles and navigation buttons have appropriate padding (KDE Phabricator revisions D10483 and D10524, fixed in KDE Frameworks 5.44)
  • Kirigami pop-ups (used for Discover’s screenshots and reviews pop-ups) now have close buttons (KDE bug 387815, Fixed in KDE Frameworks 5.44)
  • Discover’s “show more reviews” button now always shows the correct number of reviews, has slightly better text, and no longer lets you write the first review for apps that you haven’t installed yet (KDE Phabricator revisions D10527 and D10525, Fixed in KDE Plasma 5.13)
  • Items in app lists now have better top padding, so they don’t touch the header (KDE Phabricator revision D10548)
  • Improved the metadata for the KDE Nightly Builds Flatpak repo so it has a more appropriate name, in preparation for encouraging our users to try it out (more on that soon…):

Well there you have it. We never stop working on improving Discover, and we really do listen to user feedback. Mark my words, Discover is going to become one of the most-loved Linux software centers, you heard it here first! Help is always appreciated, so feel free to start contributing and making a difference to a project that truly matters. You don’t have to be a programmer to have an impact!

And if you look at my efforts and like what you see, consider donating on Patreon to help me do it full-time, rather than squeezing it in before and after my regular job. With your support, I could bring forth even more for KDE!

February 16, 2018

I was working on adding sounds to Pixel Wheels rescue helicopter, so I started SFXR Qt and after a few experiments I came up with a decent sound. Unfortunately it did not sound that good in the game. It was much more dull than in the app. Listening again to the sound in SFXR Qt I realized there were subtle variations between each plays, which made the sound more interesting.

Initial investigation

At first I was puzzled, how could the sound differ from play to play? After a more thorough code inspection I found the culprit: the noise buffer. When you select a noise wave form, the app generates a 32 item long array of random floats between -1 and 1, and go through it in a "segment" (a sound can be made of multiple segments). When a new segment starts, the buffer is regenerated, causing the sound to be subtly different each time it is repeated.

Let's make it sound dull

I want SFXR Qt sounds to sound like they are going to sound in the game, so I set out to get rid of those variations.

I picked the sound created the first time you click on the "Explosion" generator button as my guinea pig. It sounds like this:

My first fix attempt was to create a long buffer with as many items as there are samples in the sound, and reuse it as the sound was being replayed. That failed: the noise was much more high pitched.

Debugging random noise buffers is hard, or at least, I am not used to working on this kind of topics. One change I made to make behaviors more deterministic was to make the noise buffer generators of both the master branch and my work branch use their own, fixed random seed, separated from the seed used by the generator buttons. This made it possible to compare the sounds generated by running both versions side by side.

I could hear the difference but I was getting nowhere, why did my noise buffer sound differently than the original implementation? And then I had a revelation: the original buffer contains 32 items, and the code using it looks like this:

sample = noise_buffer[phase * 32 / period];

Where period is the duration of the current segment, and phase is the sample index in the segment.

As you can see, there is no modulo: the noise buffer is stretched to fill the segment. This means that each value in the buffer is used period / 32 times consecutively before the next value is used. Using the same noise values longer means less variations, which translate into lower pitched noises.

Comparison of the two generated noises

Armed with this revelation, I reworked the code to use a fixed 32 item buffer and reuse it between segments. The result was less high pitched, but it was also a lot less noisy:

More head scratching led to the second revelation: reusing the same noise buffer across segments caused the creation of regular waves with a frequency of 1 / period. The buffer needs to contain different values for each segments to avoid creating those low frequency waves.

My third implementation fixed this by creating a list of 32 item noise buffers, one for each segment, and reusing the same list each time the sound is replayed. This finally produced the same result as the original. Victory!

Simplifying

Using a list of buffers worked, but it felt over-complicated. My first simplification attempt was to use one long buffer again, but go through it by slices of 32 items. That worked, but the code was not much simpler.

I eventually came up with a simpler approach: what I needed was a random value generator which returned the same value for period / 32 calls, and which could be reset to produce the same pseudo-random sequence each time the sound restarts. This can be implemented by keeping the last value returned and changing it at the right time. Reproducibility can be achieved by resetting the random seed each time the sound restarts. I implemented this in a NoiseGenerator class:

// Header
class NoiseGenerator {
public:
    explicit NoiseGenerator(int sampleCount);
    void reset();
    float get(float alpha);
private:
    const int mSampleCount;
    unsigned int mRandomSeed = 0;
    int mLastIndex = -1;
    float mLastValue = 0;

    float randomRange(float range);
};

// Implementation
NoiseGenerator::NoiseGenerator(int sampleCount)
    : mSampleCount(sampleCount) {
}

void NoiseGenerator::reset() {
    mRandomSeed = 0;
    mLastIndex = -1;
}

float NoiseGenerator::get(float alpha) {
    int index = mSampleCount * alpha;
    if (index != mLastIndex) {
        mLastIndex = index;
        mLastValue = randomRange(2.0f) - 1.0f;
    }
    return mLastValue;
}

float NoiseGenerator::randomRange(float range) {
    return rand_r(&mRandomSeed) / float(RAND_MAX) * range;
}

Back to this helicopter sound

Now that I can trust SFXR Qt to play sounds faithfully, the next step is ironically to make it capable of producing the sound it produced before by accident, but this time in a way which can be used in Pixel Wheels. To do so I plan to add an option to set a number of repeats so that it can generate N times the same sound with noise variations. But that's a story for another week...

Igor Ljubuncic of Dedoimedo is at it again, and has just published a list of high-profile KDE Plasma bugs and papercuts. As a Plasma fan, his intention is to call attention rather than criticize, and I’ve put together a response for every issue he raised. For the full list, scroll down.

Here’s the thing: reporting issues is important. QA is important. Raising awareness of problems is important. But as you’ll see from the list below, nearly every legitimate issue that Igor brings up is already known and tracked in Bugzilla. Many are already fixed, in fact.

The problem is lack of resources, not lack of awareness of issues. Fixing bugs requires developers. And we need more in order to fix them all at the rapid pace that our users expect. We know about the bugs. We want to fix the bugs. But we need your help to do it!

The best way is to start submitting some patches. You don’t even need to know any programming! Here is a non-programming patch I submitted just today, for example. A lot of my patches are utterly trivial in nature, like this one or this one. These are easy fixes; low-hanging fruit. Anyone with some technical knowledge can get started today! There’s a ton of support.

If you want to help propel KDE to the great heights it’s capable of, climb on board!

And now, for the full list, if you dare:

  • [C] Widget button on the left side is too close to the desktop folders.

    Will be fixed soon: https://phabricator.kde.org/D10563

  • [C] Widgets list always opens on the left side, regardless of the button placement.

    This isn’t a bug. The widget list can be opened from multiple interfaces; if it always followed the Desktop Toolbox, it would just be inconsistent with something else. Still, we may be able to make some usability improvements: https://bugs.kde.org/show_bug.cgi?id=390575

  • [C] Wireless icon (when not connected) is too pale and may be mistaken for a gap in the system area in the panel.

    Already fixed; see https://bugs.kde.org/show_bug.cgi?id=384018

  • [C] When connecting to a Wireless network, the user may be prompted for password twice, which is probably related to the KDEWallet service.

    See https://bugs.kde.org/show_bug.cgi?id=387502. This is mostly up to distros; most of them don’t configure KWallet properly. Kubuntu already does for the actual user account, but doesn’t for the live session. But it will soon; see https://phabricator.kde.org/T7981

  • [F] When you add/pin applications to the task manager, the menu auto-closes. This is annoying and distracting if you want to add more than one icon at a time.

    See https://bugs.kde.org/show_bug.cgi?id=390585

  • [F] Menu session end buttons all have the same result, regardless of what you click on. Whether you choose suspend, reboot or shutdown, you still have a 30-sec timeout screen with the same options presented again. A confirmation is nice, but it should also correlate to the chosen action. Clicking suspend or reboot and then choosing shutdown a few seconds later negates the first choice.

    It already does; the action you chose is the one that’s selected in the confirmation screen.

  • [C] The system menu does not differentiate between several versions of the same application, if installed. For example, the standard repo and the snap version of VLC 3.0 both show exactly the same, and the only way to tell them apart is by the icon (lower-res for the snap), or alternatively, by launching the program to check which version it is.

    See https://bugs.kde.org/show_bug.cgi?id=389035

  • [F] The order of different versions of the same application as listed in the system menu changes based on usage/launches.

    That’s a feature, not a bug. For an app list based on frequency of use, you should expect each version of an app to appear separately and have its own ordering. If you didn’t care about them being separate, you wouldn’t install multiple versions of the same app.

  • [C] Panel height resize is done using a drag/slider rather than a precise input value. Both options ought to exist, so that both methods can be used. Hand sliding, especially without an external mouse pointer, is tedious and inaccurate.

    Improved with https://bugs.kde.org/show_bug.cgi?id=372364. Further improvements possible.

  • [C] Brightness slider does not go all the way to the right on the 100% mark.

    Already fixed, a long time ago (Igor even blogged about it having been fixed!). Must have been using a distro with an old version of Plasma, or a defective theme.

  • [C] The clipboard in the system area, after you copy media files, does not have a perfect vertical alignment, leading to the bottom-most line to be partially obscured (cropped).

    Not a bug; this is how all scrollable lists work everywhere. Perfect alignment is impossible when the list can be filled with arbitrarily-sized content.

  • [F] Default font color is too pale – insufficient contrast; should be black.

    Already almost fixed. See https://bugs.kde.org/show_bug.cgi?id=381288

  • [F] Default font size is too small (10pt).

    See https://phabricator.kde.org/T7864

  • [C] Default font anti-aliasing settings are sub-optimal in all tests I have performed, including different laptops, with Intel and Nvidia graphics. The system defaults should be set to RGB and slight hinting.

    See https://bugs.kde.org/show_bug.cgi?id=389598 and https://phabricator.kde.org/T7618

  • [F] Spectacle does not have an option to remove/disable shadows when taking a screenshot of an active window area. The shadow size also depends on the selected theme – and may be impacted by compositing, which can lead to inconsistent results. It is also not apparent whether there are shadows in created screenshots or not while they are being taken.

    See https://bugs.kde.org/show_bug.cgi?id=372408

  • [F] Spectacle usage model is complicated – Save & Exit is the same button that opens the preferences menu, and it is not immediately apparent this is the case. It also makes no sense to place the two under the same hierarchy element.

    Already fixed. See https://pointieststick.wordpress.com/2018/02/15/usability-productivity-highlight-spectacle/

  • [C] System settings menu opens at a “wrong” default size, leading to category labels text breaking over multiple lines.

    See https://bugs.kde.org/show_bug.cgi?id=389617

  • [C] System settings category labels are too pale – and barely visible.

    See https://bugs.kde.org/show_bug.cgi?id=384638

  • [F] The installation of new themes, icons and other decoration is vague and broken. Sometimes, there are multiple install options that do not clearly signify to the user what they’re installing, and these installations often fail due to misconfigured third-party resources. Even when installed, decorations may not show up in relevant lists due to unlisted incompatibilities. It may take a full session restart (log out, log in) to see the effects of newly applied decorations.

    A known issue. This is a big task, too big for a Bugzilla ticket. But it’s on our radar screens.

  • [F] System customization should include a backup and restore-to-defaults options, including a desktop/system wide configuration, as well as individual options. This may also be realized as preview function, so the users can see what the new theme/decoration will do before it is applied.

    See https://bugs.kde.org/show_bug.cgi?id=389568

  • [F] Discover shows no screenshots and no rating for selected programs.

    No screenshots: Not Discover’s fault; it’s up to app developers to properly advertise their work, or packagers to bail them out and do it for them. We can’t do anything about this in Discover. See https://pointieststick.wordpress.com/2018/01/27/how-to-make-an-app-look-good-in-discover/ As a workaround, use Flathub instead of your distro’s packages wherever possible; they care about good packaging and make sure that app listings look good.

    No ratings: See https://bugs.kde.org/show_bug.cgi?id=389601

  • [F] Discover sources management remains confusing and insufficient – no way to change locality/priority of listed distributions, no way to search or install proprietary software.

    You already can change the priority of different backends. Changing priority of individual repos within a backend is tracked with https://bugs.kde.org/show_bug.cgi?id=388921

  • [F] In the sources view, Discover has a scrollbar that obscures the list of repos and also partially blocks the UI itself.

    Already fixed: https://bugs.kde.org/show_bug.cgi?id=389602

  • [F] Discover seemingly keeps on checking for updates, even though the action is not happening and/or it should have completed already.

    This is very distro-specific, and we haven’t seen it in quite a while with recent versions of Discover. Anyone who sees this should file a bug! Just complaining about it isn’t enough; we need for people who experience it to file bugs!. If you want to be QA, then you have to be willing to use the appropriate channels to report issues, or else it’s just noise. See https://community.kde.org/Get_Involved/Bug_Reporting

  • [F] Discover search results are broken; programs that can be found using the command-line package manager utility do not show in the UI when the same search string is used.

    Discover is not a package manager. By design, it only shows packages with AppStream metadata. The goal is that users shouldn’t ever need to do manual package management. If anything ever doesn’t show up in Discover that should, this is the your distro’s fault, but you can help us fix it!

  • [F] It is difficult to find the option to configure/enable the desktop session restart (X kill), normally activated by the Ctrl + Alt + Backspace combo. There are no less than three different options to configure and use keyboard shortcuts. You have normal and advanced settings, but then you also have the hardware configuration, and it’s the last one that you actually need for this.

    This is an advanced feature that shouldn’t be required for normal users during normal use; why would we want to make it more prominent?

  • [C] Dolphin requires drag ‘n’ drop to add shortcuts to the sidebar; an (easily discoverable) menu option would be preferable, especially for network shares.

    It’s right there in the right-click context menu:

  • [C] There’s no easy way to quickly remove/hide entries in the Dolphin sidebar, except by removing the entire category.

    Sure there is:

  • [C] The list of devices in Dolphin seems random – devices should include both label, device name and size through a configurable setting, and there should be an option to allow the user to sort the devices based on their preference.

    See https://bugs.kde.org/show_bug.cgi?id=367614

  • [F] In Dolphin, copying files to Samba shares will result in their timestamp being updated to the current mark. This is most significant when working with pictures.

    See https://bugs.kde.org/show_bug.cgi?id=356651

  • [C] No way to add URL shortcuts by drag ‘n’ drop from browsers; no favicons are used as shortcut icons.

    This works just fine. Could use some usability polish, though: https://bugs.kde.org/show_bug.cgi?id=389600

  • [C] No way to add an existing URL shortcut (on the desktop) to the task manager. Launched program/site via the shortcut defaults to the browser application icon.

    See https://bugs.kde.org/show_bug.cgi?id=389613

  • [C] The panel clock is too big – full height – while the rest of the system area icons are smaller. The use of the alternative gadget Event Calendar helps, but this should be a customizable option in Plasma defaults.

    Already fixed; see https://bugs.kde.org/show_bug.cgi?id=375969

  • [F] KDE Connect only works with Android devices.

    This is caused by limitations in the kinds of software allowed on iOS.

  • [F] iPhone/iOS devices will not be auto-mounted in Dolphin; you may need to use a manual configuration to identify and mount them.

    Never seen this; my iPhone works fine. A detailed bug report would be helpful here.

  • [F] The mount prompt in the system area (regardless of the device/phone/camera) type is vague. It offers several mount options, associated with programs, but it does not identify the mount protocol, e.g. MTP or PTP. This only becomes apparent after the device has been mounted and presented in the file manager.

    Not a bug; the mount protocol is (or should be) irrelevant to a normal user. No other OS includes this kind of super technical information there.

  • [F] There is no umount option for phones or cameras in Dolphin.

    Already fixed: https://phabricator.kde.org/D8348

  • [F] Media playback (music and video) from Samba shares does not work well. There is no unified approach to how the remote filesystems should be treated, and it is up to individual applications to handle authentication and playback.

    See https://bugs.kde.org/show_bug.cgi?id=75324

  • [C] Not all media players have system integration, and/or some have their individual icons + media playback button in the system area.

    This is entirely up to those media players to conform to the MPRIS spec. Blame them, not us.

  • [F] Accessibility options are vaguely defined or executed. They should be available out of the box and configured for immediate use, including the lock and login screens.

    A legitimate concern. We will investigate this.

  • [F] Open file dialogs for different applications behave in different ways, including how directory trees and files are displayed. Often, paths and names are truncated, and there’s no standard display method.

    These are most often Qt bugs, but still a priority in my list.

The above issues are high-profile and will earn their fixers a lot of praise, and will likely be featured here. So go on and fix some bugs! It’s easier than you think.

In the last post, we discussed a new approach to design time and build time integration of external tools in Visual Studio using MSBuild rules and targets. This will be included in the upcoming release of version 2.2 of the Qt VS Tools. In this post, we will discuss the performance improvements that are also included in this new version.

We’ll focus on two situations where users of the current version (2.1) of the Qt VS Tools have reported sub-standard performance:

  • Adding new header files, especially to projects with many configurations
  • Converting Qt projects (.pro files) with many files

We’ll look at the scale of these problems and why they occur, then discuss the steps that have been taken to fix the problems and the improvements that have been achieved.

Adding Header Files to a Project

To understand the scale of this problem and the effectiveness of our solution, we ran the same set of tests using both the current and the new version. These tests consisted of adding several header files containing Qt macros to projects with varying numbers of configurations. For more information on the test setup and a detailed analysis of the results, please refer to the section “Measuring Performance”, at the end of this post.

Looking into the results of testing version 2.1, we found that the time to add files to a project got progressively worse, up to several minutes, the more configurations were defined in the projects. The worst case scenario was just under 45 minutes for adding 10 files to a project with 20 configurations. It was possible to determine that the performance degradation is closely related to the approach previously followed, where files generated by moc were explicitly added to the project in order to be included in the C++ compilation. The time spent modifying properties of generated files accounted for 98% of total time.

As we discussed in the previous post, the new approach based on MSBuild rules and targets allows source files to be added to the build process while it is ongoing. This way, instead of adding the files generated by moc as static project items, they are added dynamically to the C++ compilation during the processing of the moc target. This should represent a significant improvement to the cost of adding new header files to a project. The test results from version 2.2 show that this is indeed the case: the time spent on each test case was, on average, 95% less than that of version 2.1, and what was previously the worst case scenario (10 files added to a project with 20 configurations) now took only 3,2 seconds to complete.

This improvement in performance is not limited to the action of adding header files to projects. It will have an impact in all operations that handle generated files as project items. The following is a list of other use cases that should also benefit from the increase in performance (especially in projects with several configurations):

  • Importing Qt projects (see next section);
  • Creating new Qt classes;
  • Manually adding/removing the Q_OBJECT macro in a file;
  • Changing the Qt version;
  • Changing the path to the moc, rcc and uic generated files.

Importing Qt Projects

The problem described above also applies when importing a .pro file, since properties of generated files are also accessed and modified during import; in fact, the import procedure modifies properties of all project files. To avoid this problem, in the new version of the Qt VS Tools, the Visual Studio project that is generated by qmake is not immediately loaded into Visual Studio; all modifications are carried out as an XML transformation on the project file. Only then is it loaded into Visual Studio. This way we avoid any project-wide processing while the project is loaded.

To test this optimization, we imported the Qt example project demobrowser. Below is a recording of this test using version 2.1 (left) and version 2.2 (right) of the Qt VS Tools (the recording also includes building and running the program). We found that the time to import the project decreased from over 30 seconds in the current version to less than 6 seconds in the new version.

Importing demobrowser

 

Measuring Performance

To measure the scale of the performance problem when adding new header files, we ran a series of tests with an instrumented build of the Qt VS Tools that recorded the number and duration of calls to every function. As the performance seemed to be influenced by the number of project configurations, we tested with several projects containing respectively 2, 5, 10, 20 and 40 configurations. As the number of files added also seemed to be a factor, we tested each project with 5, 10, 20 and 40 files added, for a total of 20 test cases. We will use the variable C to represent the number of configurations, and the variable F to represent the number of files added.

The results of testing with version 2.1 of the Qt VS Tools show that the performance degrades significantly as we increase the number of configurations and the number of files added. The graph below summarizes the test results. Some tests were interrupted after 45 minutes; this is noted in the graph by grayed-out bars. The blue bar on the left serves as a 1 minute scale.

Test Results v2.1

Looking further into the test data, we find that most of the elapsed time was spent calling functions of the Visual Studio SDK. For example, in the test case C=20,F=10, which took almost 45 minutes to complete, 98% of that time was spent in the following calls:

Calls to Visual Studio SDK

These functions were called while adding generated files to the project – files generated by moc must be added to the project in order to be included in the C++ compilation. For every header file added, one generated file per configuration will also be added to the project, i.e. F×C generated files. In the test case of C=20,F=10, this accounts for the 200 calls, e.g. to the AddFile function.

Each one of the F×C generated files can only be compiled if the corresponding project configuration is active. For all other configurations, the file must be set to “excluded from build”. This is the reason for the larger number of calls to the set_ExcludedFromBuild function, i.e. F×C×(C-1) calls to that function. In the example of the C=20,F=10 test case, this accounts for the 3800 calls to set_ExcludedFromBuild.

We’ve also found that the functions of the Visual Studio SDK tend to become slower as the number of calls increases. In the case of set_ExcludedFromBuild, we see that the average time per call went from 11 milliseconds, when calling the function 10 times, to 535 milliseconds per call for 3800 calls:

Calls to set_ExcludedFromBuild

With the approach followed in version 2.1, which requires that generated files be added to the project, there doesn’t seem to be much room for improvement in performance: almost all time is spent inside external functions and these functions are called exactly the number of times needed. The problem of the performance degradation seems then directly linked to the approach itself.

To test the performance of the new approach, we ran the same 20 test cases using the new version 2.2 of the Qt VS Tools, which uses the Qt/MSBuild targets; the results are shown in the graph below. As before, the blue bar on the left represents the same 1 minute scale.

Test Results v2.2

Comparing the results of both tests, in version 2.2 the time spent was, on average, 95% less than that of version 2.1. The average cost of adding header files to a project, per file and configuration (i.e. total time divided by F×C), decreased from 300 milliseconds to 40 milliseconds.

The post Qt in Visual Studio: Improving Performance appeared first on Qt Blog.

On Valentines day TechEmpower released the results of fifth round of it’s benchmarks tests on web frameworks, it took almost a year since round 14 and I really hope round 16 comes out sooner.

Since this round took a long time and was scheduled to be release many times last year I decided not to update Cutelyst to avoid not having the chance to fix any issues and have broken results. Cutelyst 1.9.0 and Qt 5.9 were used, both had some performance improvements compared to round 14, and thus you can see better results on this round compared to 14, most notably the JSON tests went from 480K request/second to 611K req/s, also due this old Cutelyst release jemalloc was again not used due a bug we had in CMake files that didn’t link against it.

In this round some  other frameworks also done their optimizations and a few managed to do better than Cutelyst, even though we were faster in all tests compared to the last round. It might be even related to some OS tuning as most results seemed to went up a bit, however if you put the filter on “FullStack” frameworks Cutelyst is leading in most tests.

TreeFrog framework had results in TechEmpower long before I wrote the tests for Cutelyst, but due errors on TreeFrog tests on last rounds this was the first round where you can compare the results of two Qt Web Frameworks.

For the next round I expect the results to be even better now that we will properly use jemalloc, and our epoll dispatcher got a better implementation, I also plan to use Cutelyst 2 and try increasing some buffers as the servers have plenty of RAM that I didn’t care on using.

If you want to know more about Cutelyst visit https://cutelyst.org/ and give us a Star on GitHub (we are now past 300!!) https://github.com/cutelyst/cutelyst

KMyMoney  es el gestor de finanzas personales para KDE. Su funcionamiento es  similar a Microsoft MoneyQuicken, aunque su precio un poco menor. Recientemente ha dado el salto al nuevo entorno Qt5 y KF5, así que me complace anunciar que ha sido lanzado KMyMoney 5, lo que significa que el proyecto sigue vivo y con una buena salud.

 

Lanzado KMyMoney 5.0.0

Lanzado KMyMoney 5.0.0KDE es un proyecto que abarca a cientos de programadores, todos ellos con sus inquietudes y sus objetivos diferenciados. De esta forma se puede ofrecer software de calidad para el publico con inquietudes generales (KDE Connect para integrarse con nuestro smartphone, digiKam para las imágenes, KTorrent para bajar torrents, Okular para ver pdfs, etc) y software de calidad para inquietudes más específicas, como es el caso de KMyMoney cuyo salto a las nuevas tecnologías Qt5 y KF5 se ha cristalizado en esta nueva versión.

Y como en todas las nuevas versiones, el equipo de desarrollo de KMyMoney ha trabajado mucho para hacer que sea la mejor de todas y la más sencilla de utilizar.

No obstante, en este KMyMoney 5 gran parte del trabajo se ha hecho “bajo el capó”, es decir, se ha focalizado en la transición al nuevo entorno de desarrollo, y se ha aprovechado para reorganizar y mejorar el código interno.

A pesar del cambio estético inherente al utilizar este nuevo entorno Qt5 y KF5, el funcionamiento básico se ha mantenido casi idéntico a las versiones anteriores. Y en cuanto a las novedades solo quisiera destacar la posibilidad de realizar gráficos con ejes logarítmicos para los informes o el soporte para nuevas monedas. Todo esto se puede ampliar en las notas de lanzamiento.

 

En definitiva, un gran programa para controlar nuestros gastos, en constante evolución e integrado con nuestro escritorio Plasma de  KDE, como es el hecho de que tiene incluido soporte para las actividades.

¿Qué es KMyMoney?

Como he comentado, KMyMoney es el gestor de finanzas personales de KDE, es decir, una aplicación que te permite tener registrados (que no controlados, eso ya  es una cuestión personal) tus ingresos y gastos, así como tus operaciones financieras, tus diferentes tarjetas de crédito o débito, etc.

KMyMoney está pensado para el uso personal o de un pequeño negocio, no para manejar las cuentas de empresa.

February 15, 2018

Over the past few weeks, we’ve done a lot of Usability & Productivity work for Spectacle, KDE’s screenshot tool. I’d like to share the progress! But first, a screenshot. Here’s how spectacle looks now:

We’ve been hard at work making Spectacle easier to use and more featureful, and you can see some of those changes in the above screenshot. Here’s the full list of user-facing changes and bugfixes:

  • The save button now defaults to showing “Save As…” (KDE Phabricator revision D10153)
  • The Save button now remembers the last Save mode that you used by default (KDE Phabricator revision D10198)
  • Removed the confusing and destructive Discard/Quit button (you can still quit the app with Ctrl+Q or the Escape key, or by clicking on the window’s close button (KDE Phabricator revision D10283)
  • Added a visible “Configure…” button so that you can more easily find Spectacle’s settings (KDE Phabricator revision D10289)
  • Added a new “Tools” menu button that can hold extra features, and moved “Print” to it. Now the “Save” button finally has only actual Save actions! (KDE Phabricator revision D10371)
  • Spectacle’s new Tools menu now provides an easy link to your screen recording app if you have one installed, and if you don’t, it suggests a few (KDE Phabricator revision D10295)
  • Made the main window size itself optimally based on the shape of the screenshot (KDE Phabricator revision D10377):
  • Spectacle can now be configured to quit after copying the screenshot to the clipboard (KDE bug 389773) – note that you will need to tell Klipper (the clipboard manager) to accept images for this to work. For more information, see the bug report.
  • Spectacle’s new Tools menu provides an easy way to see where the last screenshot was saved (KDE bug 389695)
  • Drag-and-drop to Chromium windows now works (KDE bug 369404)
  • Spectacle no longer displays the dreaded “Ambiguous shortcut warning” dialog if you use the same keyboard shortcut twice (KDE bug 389691)

All of these improvements will be available in KDE Applications 18.04.

And we’re not done yet. We’re scoping out work to add an inline image editor/annotator and improve the user experience where you want to use spectacle to quickly take a screenshot and copy it to the clipboard without showing the main window (often for the purposes of pasting it into a chat window). An option to omit window shadows or reduce their size is also in the works.

Spectacle is used by hundreds of thousands or even millions of people, so this work has an impact! It’s a great time to be part of something big. Hop on board, and we’ll work together to continue making everything even better.

Como estaba previsto en el calendario de los desarrolladores, el pasado martes 13 de febrero la Comunidad KDE ha comunicado que ha sido lanzada la primera actualización de Plasma 5.12 LTS. Una noticia que aunque es esperada y previsible es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran pedazo de Software Libre.

Lanzada la primera actualización de Plasma 5.12 LTS

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes 13 de febrero se lanzó la primera actualización de Plasma 5.12, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones.

Es por tanto, una actualización 100% recomendable.

Más información: KDE.org

Las novedades de Plasma 5.12 LTS

Muchas y variadas son las novedades que nos presenta Plasma 5.12, lo cual hace que sea una jugosa tentación aquellos que todavía no confían en el proyecto de la Comunidad KDE y una ilusionante vuelta de tuerca para aquellos que llevamos tiempo disfrutando de sus bondades.Lanzada la primera actualización de Plasma 5.12 LTS

Una de las más importante, como no podía ser de otra forma en una LTS, es la mejora general del entorno, lo cual se materializa en mejoras de velocidad y en la optimización en el uso de la memoria. En otras palabras, cuando ejecutamos Plasma, ahora se usa menos CPU y menos memoria que en versiones previas. Por ejemplo, el tiempo que tarda en iniciarse un escritorio Plasma ha reducido drásticamente.

En cuanto a pequeñas mejoras tenemos:

  • Nueva funcionalidad “Color de noche” para reducir la exposición a la luz azul en las horas nocturnas.
  • Mejora de la usabilidad del menú global: al añadir una panel de menú global o un botón de decoración de ventana activa sin necesidad de ningún paso extra de configuración.
  • Mejoras de accesibilidad en el KRunner: ahora se puede utilizar completamente con los lectores en pantalla, como Orca
  • La miniaplicación de iconos ahora usa el icono de web del sitio web
  • Vuelve a poderse seleccionar el texto de notificación, incluyendo una funcionalidad de copia de enlace
  • La disposición del menú de aplicaciones del Kickoff se ha simplificado.
  • La miniaplicación meteorológica ahora puede mostrar opcionalmente la temperatura junto al icono del estado del tiempo en el panel.
  • La actividad del sistema y el Controlador del sistema ahora muestran las gráficas para proceso del uso de la CPU.
  • El texto del widget Reloj ahora tiene un tamaño más adecuado.
  • Las sombras de las ventanas ahora están centradas horizontalmente y son más grandes
  • El diálogo de propiedades ahora muestra los metadatos del archivo.

Discover

Capítulo aparte merece Discover, el gestor de aplicaciones, temas, plasmoides y de cualquier cosa instalable de Plasma. Y es que son muchas las facetas que han mejorado y que lo convierten en un pieza básica del entorno Plasma.

Lanzado Plasma 5.12 LTS

Discover, pieza clave en el desarrollo del escritorio Plasma sigue mejorando.

De esta forma tenemos:

  • Mucha más estabilidad (quizás la más necesaria)
  • Mejoras en la implementación del Snap y el Flatpak (básica para la revolución que se está gestando para la instalación de aplicaciones)
  • Implementación de los URL apt: //
  • Las distribuciones pueden activar actualizaciones desconectado
  • Mejor usabilidad en factores de forma de teléfono: usa la acción principal del Kirigami, que tiene una vista específica para buscar
  • Integra las señales globales del PackageKit a las notificaciones
    • Actualización de distribución para los lanzamientos nuevos
    • Notificación de reinicio cuando el Discover instala o actualiza paquetes que requieren un reincio
  • Mejoras en la interfaz de usuario
    • Se han rediseñado las páginas de las aplicaciones para mostrar un software destacado.
    • Cabeceras más simples en secciones de no visualización
    • Vistas de navegación más compactas, con el fin de ver más aplicaciones de golpe
    • Las capturas de pantalla para aplicaciones son más grandes y tienen navegación por teclado
    • La lista de aplicaciones instaladas ordena alfabéticamente
    • IU más completa para configurar orígenes

Wayland avanza a pasos agigantados

Lo moderno se debe imponer poco a poco a lo obsoleto. Está claro que Wayland es el futuro y su integración en Plasma mejor en cada versión. De esta forma, por primera vez, se añade Wayland en el mantenimiento a largo plazo, así que se irán solucionando los errores en la series 5.12.x LTS.

Lanzado Plasma 5.12 LTS

Wayland y su ventana de configuración de pantallas. Cada día más cerca de reemplazar el veterano X.org

Para los más curiosos, estas son las nuevas funcionalidades de Wayland:

  • La resolución de la salida se puede definir desde el KScreen
  • Activación y Desactivación de las salidas desde el KScreen
  • Posibilidad de rotación de la pantalla
  • Rotación automática de pantalla a partir del sensor de orientación
  • Calibración automática de la pantalla táctil
  • Ya no se requiere más la implementación del XWayland; las aplicaciones que solo permitan las X todavía harán uso
  • Las ventanas del Wayland se pueden establecer a pantalla completa
  • Usa una política de planificación en tiempo real para mantener la fluidez de la entrada
  • Selección automática del Compositor en base a la plataforma usada
  • Comienza la implementación de las reglas de ventana
  • Color de noche para eliminar la luz azul de la pantalla en horario nocturno; esto es una sustitución solo por Wayland de la gran aplicación Redshift a las X

Wayland viene a Plasma y está a punto de ser el motor de visualización por defecto.

En resumen, un gran anuncio para una gran Comunidad que sigue apostando por el denostado escritorio y demostrando versión tras versión que Plasma es lo mejor que le puede pasar a tu ordenador.

¡KDE Rocks! ¡Larga vida a Plasma!

 

A verdigris statue

I have just tagged the version 1.0 Verdigris. I am taking this opportunity to write an article about two C++ tricks used in its implementation.

Verdigris is a header-only C++ library which lets one use Qt without the need of moc. I've written an introductory blog post about it two years ago and have since then received several contributions on GitHub that extend the software.

Optionally Removing Parentheses in a Macro

This trick is used in the W_PROPERTY and the W_OBJECT_IMPL macro. The first argument of W_PROPERTY is a type. Typically: W_PROPERTY(QString, myProperty MEMBER m_myProperty).
But what happens when the type contains one or several commas, as in: W_PROPERTY(QMap<QString, int>, myProperty MEMBER m_myProperty)? That's not valid, macro expansion does not consider template and therefore the first argument would be up to the first comma. The solution is to put the type name in parentheses. The new problem is then how can we ignore parentheses in the implementation of the macro.

Let's rephrase the problem with simplified macros. Imagine we want to do a macro similar to this:

// Naive implementation of a macro that declares a getter function
#define DECLARE_GETTER(TYPE, NAME) TYPE get_##NAME()

// Can be used like this
DECLARE_GETTER(QString, property1);   // line A
// OK: expands to "QString get_property1()"

// But this does not work:
DECLARE_GETTER(QMap<QString, int>, property2);
// ERROR: 3 arguments passed to the macro, but only 2 expected

// And this
DECLARE_GETTER((QMap<QString, int>), property3);  // line B
// ERROR: expands to "(QMap<QString, int>) get_property3()"
// Can we get rid of the parenthesis?

The question is: How can we implement DECLARE_GETTER so both line A and line B produce the expected result? Can we get the macro to remove the parentheses.

Let's make a first attempt:

// REMOVE_PAREN will be our macro that removes the parenthesis
#define DECLARE_GETTER(TYPE, NAME) REMOVE_PAREN(TYPE) get_##NAME()

// Forward to REMOVE_PAREN_HELPER
#define REMOVE_PAREN(A) REMOVE_PAREN_HELPER A
#define REMOVE_PAREN_HELPER(...) __VA_ARGS__

DECLARE_GETTER((QMap<QString, int>), property1);
// OK: expands to "QMap<QString, int> get_property1()"
// This worked because "REMOVE_PAREN_HELPER (QMap<QString, int>)" was expanded to "QMap<QString, int>"

DECLARE_GETTER(QString, property2);
// ERROR: expands to "REMOVE_PAREN_HELPER QString get_property2()"
// There was no parenteses after REMOVE_PAREN_HELPER so it was not taken as a macro"

We managed to remove the parentheses, but we broke the case where there are no parentheses. Which lead to a sub-question: How to remove a specific token if present? In this case, how to remove "REMOVE_PARENT_HELPER" from the expansion

// Same as before
#define DECLARE_GETTER(TYPE, NAME) REMOVE_PAREN(TYPE) get_##NAME()

// Macro that removes the first argument
#define TAIL(A, ...) __VA_ARGS__

// This time, we add a "_ ," in front of the arguments
#define REMOVE_PAREN_HELPER(...) _ , __VA_ARGS__

#define REMOVE_PAREN(A) REMOVE_PAREN2(REMOVE_PAREN_HELPER A)

#define REMOVE_PAREN2() TAIL(REMOVE_PAREN_HELPER_##__VA_ARGS__)
//  ##__VA_ARGS__ will "glue" the first token of its argument with "REMOVE_PAREN_HELPER_"
// The first token is:
//  -  "_" if REMOVE_PAREN_HELPER was expanded, in which case we have "REMOVE_PAREN_HELPER__"
//      which will be removed by the TAIL macro; or
//  - "REMOVE_PAREN_HELPER if it was not expanded, in chich case we now have
//    "REMOVE_PAREN_HELPER_REMOVE_PAREN_HELPER"

// So we define a macro so that it will be removed by the TAIL macro
#define REMOVE_PAREN_HELPER_REMOVE_PAREN_HELPER _,

The above code should give you an idea on how things should work. But it is not yet working. We need to add a few layers of indirection so all macros arguments gets expanded

Here is the real code from Verdigris:

#define W_MACRO_MSVC_EXPAND(...) __VA_ARGS__
#define W_MACRO_DELAY(X,...) W_MACRO_MSVC_EXPAND(X(__VA_ARGS__))
#define W_MACRO_DELAY2(X,...) W_MACRO_MSVC_EXPAND(X(__VA_ARGS__))
#define W_MACRO_TAIL(A, ...) __VA_ARGS__

#define W_MACRO_REMOVEPAREN(A) W_MACRO_DELAY(W_MACRO_REMOVEPAREN2, W_MACRO_REMOVEPAREN_HELPER A)
#define W_MACRO_REMOVEPAREN2(...) W_MACRO_DELAY2(W_MACRO_TAIL, W_MACRO_REMOVEPAREN_HELPER_##__VA_ARGS__)
#define W_MACRO_REMOVEPAREN_HELPER(...) _ , __VA_ARGS__
#define W_MACRO_REMOVEPAREN_HELPER_W_MACRO_REMOVEPAREN_HELPER ,

#define DECLARE_GETTER(TYPE, NAME) W_MACRO_REMOVEPAREN(TYPE) get_##NAME()

// And now it works as expected:
DECLARE_GETTER(QString, property1);
DECLARE_GETTER((QMap<QString, int>), property2);

Note that the W_MACRO_MSVC_EXPAND is there only to work around a MSVC bug.

Building a constexpr State in a Class from a Macro

Conceptually, this is what the macro does

class Foo : public QObject {
   W_OBJECT(Foo) // init the state
   int xx();
   W_INVOKABLE(xx) // add things to the state
   int yy();
   W_INVOKABLE(yy) // add more things
};
W_OBJECT_IMPL(Foo); // Do something with the state

But what's the state? How do we represent it?
The idea is to have a static function (let's call it w_state) whose return value contains the state. Each W_INVOKABLE macro would then expand to a new definition of that function. Of course, it needs to take a different argument, so this just declares a new overload. We do it by having a w_number<N> class template, which inherits from w_number<N-1>. (This idea is basically inspired from CopperSpice's cs_counter, whose authors described in a talk at CppCon 2015)

Here is a simplified expanded version:

template<int N> struct w_number : public w_number<N - 1> {
    static constexpr int value = N;
    static constexpr w_number<N-1> prev() { return {}; }
};
// Specialize for 0 to break the recursion.
template<> struct w_number<0> { static constexpr int value = 0; };


class Foo {
public:
    // init the state  (expanded from W_OBJECT)
    static constexpr tuple<> w_state(w_number<0>) { return {}; }

    int xx();

    // add &Foo::xx to the state by defining w_state(w_number<1>)
    static constexpr auto w_state(w_number<tuple_size<
                decltype(w_state(w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(n.prev()), make_tuple(&Foo::xx)))
    { return tuple_cat(w_state(n.prev()), make_tuple(&Foo::xx)); }

    int yy();

    // add &Foo::yy to the state by defining w_state(w_number<2>)
    static constexpr auto w_state(w_number<tuple_size<
                decltype(w_state(w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(n.prev()), make_tuple(&Foo::yy)))
    { return tuple_cat(w_state(n.prev()), make_tuple(&Foo::yy)); }
};

// Use that state
constexpr auto FooMetaObject = buildMetaObject(Foo::w_state(w_number<255>()));

This is working pretty well. At the end of this simplified example, our state is a std::tuple containing &Foo::xx and &Foo::yy, from which we could build the meta object. (In the real implementation, the state is a bit more complicated and contains more data)

This works because the call to w_state(w_number<255>())) that we use to get the size of the tuple, is referring to the previous declaration of w_state. Since our current function is not yet defined yet, the most appropriate function is the remaining one with the highest number.
Notice that we have to repeat the same code in the decltype and after the return and we cannot use return type deduction because we need to use that function before the class is fully defined.

So far so good. However, I've hit what I think is a compiler bug when doing that with class template (eg, Foo would be template<typename> Foo). For this reason, instead of using static functions, I have used friend functions in verdigris. The principle is exactly the same. It is not well-known, but friend functions can be declared inline in the class, despite still being global functions. (I've also used that fact in the implementation of Q_ENUM)
One just needs to add a type which relates to the current class as an argument. I use a pointer to a pointer to the class instead of just a pointer because I don't want potential pointer conversion when calling it with a derived class.

class Bar {
public:

    // init the state  (expanded from W_OBJECT)
    friend constexpr tuple<> w_state(Bar **, w_number<0>) { return {}; }

    int xx();

    friend constexpr auto w_state(Bar **t, w_number<tuple_size<decltype(w_state(
            static_cast<Bar**>(nullptr), w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::xx)))
    { return tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::xx)); }

    int yy();

    friend constexpr auto w_state(Bar **t, w_number<tuple_size<decltype(w_state(
            static_cast<Bar**>(nullptr), w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::yy)))
    { return tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::yy)); }
};

// Use that state
constexpr auto BarMetaObject = buildMetaObject(w_state(static_cast<Bar**>(nullptr), w_number<255>()));

Conclusion

Please let me know when you find Verdigris useful or want to help out, either here in the comments or contribute directly on GitHub.

February 14, 2018

After the initial release of Plasma 5.12 was made available for Artful 17.10 via our backports PPA last week, we are pleased to say the the PPA has now been updated to the 1st bugfix release 5.12.1.

The full changelog for 5.12.1 can be found here.

Including fixes and polish for Discover and the desktop.

Also included is an update to the latest KDE Frameworks 5.43.

Upgrade instructions and caveats are as per last week’s blog post, which can be found here.

The Kubuntu team wishes users a happy experience with the excellent 5.12 LTS desktop, and thanks the KDE/Plasma team for such a wonderful desktop to package.

Last week the Ceph Day Germany took place at Deutsche Telekom in Darmstadt. Around 160 people took part in the event and attended the talks of the 13 speakers over the day.

It was a great day with a lot of discussions, feedback and networking for the Germany/European Ceph community. The event ended in a networking reception with drinks and fingerfood, planed for an hour but actually ended after nearly two.

A big thank you to the sponsors (SUSESAPDeutsche Telekom AGTallenceIntel42on.comRed Hat and Starline) which made the event possible. The same applies to the speakers and attendees, without you it would have been a meaningless event. A special thank you to Danielle Womboldt from Red Hat for all the organisational help and Leo as the Ceph community manager.

We didn't manage to record all sessions due to technical problems, but the most of them. You can find the videos and slides from the speakers in the agenda of the Ceph day or directly in the following Google Drive folder. We will upload the recordings also to the Ceph YouTube channel later. There is also a subfolder with some impressions of the day.

I'm proud that we hosted the event. If you could not attend or would like to learn more about the community I recommend to attend to the next Ceph Day in London in April 2018. See you next time and at the Cephalocon APAC next month in Beijing.


Today is "I Love Free Software Day"!

We're celebrating by shining a spotlight on our contributors and on our collaboration with other FOSS communities and organizations. Free Software is an integral part of our lives, and it's important to show appreciation, support, and gratitude to everyone who works on making it better every day.

One of those people is Franklin Weng, a KDE contributor who started his Free Software journey by translating Kalzium. Franklin's contributions led him to amazing opportunities and projects. Read on to find out why he loves KDE so much.

Kalzium – The Start of An Amazing Journey

by Franklin Weng

When I was a high school student, chemistry was not my cup of tea. My grades in chemistry were not bad either, but I hated memorizing those organic compounds. Then, I decided to major in computer science at university, and from that moment, destiny tightly bonded me and Free and Open Source Software.

Around 2001 or 2002, I started to use and later contribute to KDE. However, Kalzium is the start of another amazing story for me. It happened in 2007...


A throwback to the old look of Kalzium - in Chinese!

I started translating KDE software around 2005. At the time, the Traditional Chinese language packages had almost been abandoned by KDE because of the very slow translation rate. Some senior FOSS community members called to others to "save" Traditional Chinese, and finally we did. From that moment on, I kept translating KDE because I simply asked myself: "Since I'm using this desktop environment, why not do it?"

So I translated everything in KDE. Everything. I started with KMail because I wanted a mail client that would reside in my system tray. Then I translated more KDE PIM applications, KDE Multimedia, KDE Graphics, KDE Games,... even KOffice. And of course, KDE Edu applications - from the simple, lovely ones, like KTuberling, KTouch, and KHangman, to huge ones like KStars and KGeography (that last one is enormous). Kalzium was just another one for me; I even translated KMyMoney - without any accounting background.

Then in 2007, I got an email.


Franklin's credits as the translator of the app.

"I saw you translated the Kalzium software. Could we meet and talk about that?"

That email was from my now friend, Eric Sun, who was (and still is) the Executive Secretary of the Open Source Software Application Consulting Center (OSSACC), a project launched by the Ministry of Education in Taiwan. The project promotes free software for use in primary and high schools. At first I had no idea why this guy would like to meet me. Would he discuss chemistry with me? I wasn't a chemistry-aholic at all!

We met at a Burger King in Taipei. He introduced himself and told me about his idea, which made me appreciate him a lot! He, as the Executive Secretary and also an FOSS enthusiast like me, wanted to introduce educational Free Software applications to teachers and students to help them acquire knowledge from many different fields, without any financial cost.

To promote those Free Software applications, the first step is, of course, to localize them. Teachers and students, especially in primary schools, would never accept software with English interfaces. He noticed that there had been some software with Traditional Chinese translations, and he was curious about who did it. Bingo! It was me.


This is what Kalzium looks like these days.

We started a series of plans. The main plan was a customized Linux distribution named ezgo - which I have already introduced here in October of 2013.

After that, we have also done a lot of work together, mostly introducing public domain educational resources, including FOSS to schools. I became one of KDE e.V. members and the president of the BoD of Software Liberty Association Taiwan, an NPO which promotes FOSS in Taiwan. In recent years, we have helped Taiwan governments to migrate to LibreOffice and ODF.

Thinking about the past 10 amazing years on the road of promoting FOSS, the start point was that I translated Kalzium. Of course, I wasn't aware that contributing translations to KDE would give me such an amazing tour in my life. Nevertheless, I always use this as an example to tell my young friends in Taiwan: "See? Chemistry is not my thing, but translating Kalzium (and many other KDE applications) made my life wonderful!"


Big thanks to Franklin for contributing to KDE for so many years, and for spreading the word about our software and its educational potential!

Do you have a story about how you fell in love with KDE? Let us know in the comments!

New year, new Kube =)

  • Setup a clearer structure for the application with “Views” as the highest level components (composer, conversation, addressbook, log, accounts).
  • Made sure that individual views are self contained and can be launched using qmlscene. This is not only good for modularity, but simplifies the workflow when working on the UI.
  • Improved the test and prototyping infrastructure: Blogpost
  • A little investigation in where all the memory goes: Blogpost
  • Added an extension mechanism that allows us to easily experiment with new views, without compromising the main application.
  • Support to unlock kube from the commandline as a poor-mans keyring integration.
  • A rather large cleanup of encryption related code used in the message parser got rid of over 1k SLOC.
  • The encrypted/signed state of a mail is now properly visualized.
  • A storage upgrade mechanism was added (Although upgrading for now means removing all local data).
  • Large payloads are no longer stored externally but inline in the database. Tests have shown that this is not less performant, but improves the fault resiliency and simplifies the system.
  • A first version of Xapian based fulltext search for local content just landed (Blogpost will follow).
  • As always, a variety of bugfixes.

Kube Commits, Sink Commits

Previous updates

More information on the Kolab Now blog!

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

For more info, head over to: kube.kde.org

February 13, 2018

I’m starting a new blog and this is the first post.

I’ll try to write about the things I do in the open source communities I’m involved in (openSUSE, SUSE, KDE, etc.). I also plan to write about other personal projects I work on and about development languages, technology, Linux and Free Software in general.

I hope I can keep it interesting ��

February 12, 2018

With the new Plasma LTS came an update to KDE neon LTS Edition and lots of people asking which edition to use and what the difference is.  This caused us to review the purpose of LTS and as a result we’ve just hidden LTS from the download page.  The only difference with the LTS edition is that it stays on Plasma’s LTS release but apps and libraries still get updates.  This doesn’t fit well with the main use cases of an LTS which is that it only gets bug fixes and no new features.  Further we test Neon LTS edition less than any other edition so it’s more likely we’ll miss some problem, which is the opposite of what most people would expect. There are distros whose release model fits better with the needs of Plasma LTS but the constant updates of Neon don’t fit too well.  We’ll keep the edition around and don’t expect to make any changes to the repositories or builds, they’re useful for devs testing Plasma LTS, but we’re not advertising it for download since it gives a different expectation of what to expect than fits into the release method of Neon.

 

KMarkdownWebView 0.5.0 has been released.

Example: KMarkdownWebView KParts plugin used by Ark (using Oxygen theme for some retro look �� )

The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies. It implements a C++/Qt-based wrapper around a local webpage with a JavaScript library (“marked”) which creates HTML from the plain text in Markdown format passed in.
The software contains

  • a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format.
  • a Markdown file KIO thumbnail generator plugin, which allows KIO-powered file managers & dialogs to show thumbnails and previews of files in Markdown format in the target format (currently only available when building against QtWebKit)

The KMarkdownWebView KParts plugin is also prepared for improved experience with the KTextEditor Document Preview plugin for KTextEditor-based applications like the editor Kate and IDE KDevelop.

KMarkdownWebView can be built with either QtWebEngine (preferred by the build system) or QtWebKit. Pass -DUSE_QTWEBKIT=TRUE to CMake to enforce the use of QtWebKit.

Changes since 0.4.0

  • Update of “marked” source copy to latest release v0.3.12
  • Translations updated for some languages (fi, fr, sl)

Download sources

Download from: https://download.kde.org/stable/kmarkdownwebview/0.5.0/src/

sha256: 84bcc4b2626109241633a52ee5cd203105fd2488277b478572a3a5b593d3de42 kmarkdownwebview-0.5.0.tar.xz

Signed with my PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau
kmarkdownwebview-0.5.0.tar.xz.sig

February 11, 2018

This week involved a lot of visual polish, and we squashed quite a few bugs causing apps to appear pixellated when they should be crisp and sharp. There was more performance tuning, too, and of course general bugfixing and polish. Take a look!

  • Fixed a visual bug causing thumbnails in Folder View (i.e. desktop icons) to be pixellated and glitchy; they are now sharp and pretty (KDE bug 376848, fixed in Plasma 5.12.1):
  • Dolphin’s Ratings UI now looks good in HiDPI mode (KDE Phabricator revision D10324, improved in KDE Applications 18.04):
  • Fixed a visual glitch causing high-resolution or vector distro logos and the plasma logo in KInfoCenter to appear pixellated and glitchy in HiDPI mode; they are also now sharp and pretty (KDE bug 388633, fixed in KDE Plasma 5.12.1):
  • Fixed a bug causing Chromium and Chrome to always append “.bin” to the end of downloaded files for users of distros with old versions of Qt and/or the shared-mime-info package (KDE bug 382437, fixed in KDE Frameworks 5.44)
  • Network mounts from /etc/fstab, autoFS, or FUSE now show up under the “Network” category in the Places panel (KDE Phabricator Revision D10319, available in KDE Frameworks 5.43)
  • You can now use the F11 keyboard shortcut to toggle the aside preview pane in KDE open/save dialogs (KDE bug 389880, available in KDE Frameworks 5.43):
  • Alt+Enter keyboard shortcut now opens the Properties dialog for Folder View (i.e. Desktop icons) just like it does in Dolphin (KDE bug 389862, available in KDE Plasma 5.13)
  • Mouse wheel now scrolls the correct number of lines in Konsole when using the libinput driver (KDE bug 386762, fixes in KDE Applications 18.04)
  • The escape key now cancels out of the ctrl+tab tab switcher menu in Kate and KDevelop (KDE bug 389484, fixed in KDE Applications 18.04)
  • Spreadsheet files located on Google Drive accessed using Dolphin now open in the correct app (KDE bug 388598, fixed in kio-gdrive 1.2.2)
  • The Print Manager received an enormous amount of fixes and improvements (Available in KDE Applications 18.04)
  • Items in Kate’s Sessions applet are now sorted alphabetically (KDE Phabricator revision D10208, fixed in KDE Applications 18.04)
  • Gwenview now respects the window manager’s commands to enter and leave Full Screen mode (KDE Bug 195046, fixed in KDE Applications 18.04)
  • Dolphin’s git plugin (available in the dolphin-plugins package can now perform merge and log actions (KDE Phabricator revisions D10213 and D10267, available in KDE Applications 18.04)
  • Lots of UI polish for Discover, including making it and all other Kirigami apps look good in HiDPI mode (KDE bug 390076, fixed in KDE Frameworks 5.44)
  • Move and copy performance with large files has been dramatically improved (KDE bug 384561, improved in KDE Frameworks 5.43)
  • Even faster move and copy performance with many small files (KDE phabricator revisions D10085 and D10124, improved in KDE Frameworks 5.43 and KDE Applications 18.04)

KDE developers are really picking up momentum, and the improvements are coming very rapidly. It’s a fantastic time to get involved in something big!

Programadores e Wannabes, Eu estarei dando um curso gratuito de Qt dia 19 de fevereiro de 2018 na Unicamp, o local será no IC3 – Instituto de Computação – Lab 305.

Quem tiver interesse em participar, favor enviar um e-mail para tcanabrava at kde.org, o curso tera duracao de 8 horas e pegara um pouco de C++ e Muito de Qt

O horario do curso sera de 08 da manha as 18, e ofereceremos cerficicado para quem precisar.

.Fellow Hackers, I’ll be at Unicamp university in Campinas teaching Qt in a free course on the 19th of february, the course will take place in the IC3, Lab 305.

If anyone wanna join just e-mail me at tcanabrava at kde.org

February 10, 2018

Elisa is a music player developed by the KDE community that strives to be simple and nice to use. We also recognize that we need a flexible product to account for the different workflows and use-cases of our users.

We focus on a very good integration with the Plasma desktop of the KDE community without compromising the support for other platforms (other Linux desktop environments, Windows and Android).

We are creating a reliable product that is a joy to use and respects our users privacy. As such, we will prefer to support online services where users are in control of their data.

We have released the version 0.1 alpha 2 last week.

Screenshot_20180202_172327Elisa with Breeze Dark color theme

Now is really a good time to join the Elisa team. Alexander did quite a lot of changes to lower the barrier to entry. He is actively maintaining the community Elisa wiki page. We have plenty of small tasks open in Elisa workboard.

We also welcome other kind of contributions like design, graphics, promo, etc.

The project is trying to stay agile and to give users an easy way to follow our work by supporting distributions channels like binary-factory or the flatpak build of KDE applications. There are also some distributions with ways to build latest code as a package (Arch AUR).

The following things have been integrated in Elisa git repository:

  • Remove duplicated property in AbstractMediaProxyModel by Matthieu Gallien ;
  • Makes AllAlbumsModel use a thread for long operations in order to not block the UI by Matthieu Gallien ;
  • Reorder methods in mediaplaylist by Alexander Stippich ;
  • Fix comment about license of the documentation to match the one in kdoctools by Matthieu Gallien ;
  • Always explain that support for UPnP is currently broken by Matthieu Gallien ;
  • Add missing runtime dependencies to README.packagers by Matthieu Gallien ;
  • Add one missing dependency for packagers by Matthieu Gallien ;
  • Move application menu to own file by Alexander Stippich ;
  • Fix artist name in album view by Alexander Stippich ;
  • Use clearPlayList instead of extra code in qml by Alexander Stippich ;
  • Add dependency to readme and fix link by Alexander Stippich ;
  • Implement a filter view and play buttons for all views by Alexander Stippich ;
  • Remove duplicate MimeType entry in the desktop file by Robert-André Mauchin ;
  • Fixes warnings reported by clazy checker tool by Matthieu Gallien ;
  • Fix installation of elisa qml package for the configuration dialog by Matthieu Gallien ;
  • Small tweak to the qmlpackage for the elisa configuration module by Matthieu Gallien ;
  • Avoid crashing when invoked from dbus without a valid list of files to open by Matthieu Gallien ;
  • Unbreak the ability to configure shortcuts by Matthieu Gallien ;
  • Fix restore of playlist position on start by Matthieu Gallien ;

Elisa has moved to kdereview. The feedback from the different releases has motivated this move in order to be able to (if Elisa is accepted by the KDE community) make regular releases to allow user to give feedback.

After a long time of constant distraction by my daily work, I finally found again a bit time to take care of KTextEditor/Kate/… issues.

One thing that really started to be an itch I wanted to scratch is some rendering fault that occur with ‘special’ font sizes.

Given I wanted to do again a bit work on the macOS port, I was really annoyed that on my screen the only application with text rendering issues was “my” one :/

I assume a lot of people have sometimes seen stuff like that in KTextEditor based applications like Kate or KDevelop:

These small white lines really stick out like a sore thumb �� It looked like some off-by-one rounding issue, surely one should be able to find it…

I tried to track down where in our rendering in KTextEditor we do create these artifacts, but I never found any place that looks like a possible cause.

After a bit more tinkering it became obvious that actually it would be more or less impossible for the KTextEditor code to mess up the painting in such a way, as we normally draw one line more or less as one thing using QTextLayout that handles the painting of the selection background, too.

Using QtCreator as an non-KTextEditor based application that uses the Qt layouting & rendering it was possible to get similar effects on macOS (or X11):

:=) Good thing that Qt is open source. A quick look into the qtextlayout.cpp and a qt5 compile later, I was able to trace the issue down to some qFloor calls for painting the selections.

I hope my patch is correct and will be accepted (QTBUG-66036 / Gerrit 219804)  or at least helps others to do the correct fix.

At least for the syntaxhighlighter example shipped with Qt I was able to reproduce the issue before my patch but not afterwards.

Would Qt not be open-source, I would have been at the end of the line after seeing no “error” in our codebase in KTextEditor.

With Qt as some open-source project, it is a completely different story.

Besides, the Qt documentation for “how to build it” and “how to contribute” on the Qt Wiki are well enough to understand that I was able to nicely compile the stuff from scratch on macOS and provide the Gerrit review request in no time.

February 09, 2018

As I mentioned in my previous article about adding sounds to Pixel Wheels, I started yet-another side project: SFXR Qt. This is a QtQuick port of SFXR, a retro sound-effect generator by DrPetter.

SFXR Qt Screenshot

SFXR is a fun way to quickly generate old-school sound effects for your game, even if you are not a sound engineer. The generator buttons in the top-left area give you good starting points to create various sounds, and you can fiddle with the various sliders to adjust the sound to your liking.

There are many forks/ports of SFXR, why another one?

I started the port for a few reasons:

First, the current UI is hard to use: something is wrong with the sliders, they do not follow the mouse. The UI is also super small on a HD screen.

Second, the other ports are all Flash-based, which I am not comfortable relying on.

But more important: I wanted to dive into sound generation a bit, and it was a fun way to get into this!

Was it worth the pain?

I think so! I am happy with the way it sounds and it was fun to dive in an area I am not very experienced with. Furthermore I was able to make a few improvements to the user experience, such as automatically previewing sounds as you move the sliders, editing multiple sounds or adding a loop option.

You can ear some of the sound effects produced in this video of Pixel Wheels. All sounds have been generated with SFXR Qt, except for the engine and skidding sounds.

(View on Youtube)

Where is the code?

SFXR Qt source code is on GitHub. There are no pre-compiled binaries for now. I might look into creating some if there is enough demand.

Be advised that some parts of the code (cough core/synthesizer.cpp cough) are still a bit rough: SFXR is written in C, and I haven't ported everything to C++ yet.

This week Discover gained a lot of little UI polish improvements, and Discover developers also fixed a major crash present in 5.12.

  • The main Featured page now shows more apps on distros like Ubuntu and KDE Neon that have lousy AppStream data (KDE bug 390016, fixed in KDE Plasma 5.12.1):
  • Notifications now stick around for longer, so they’re easier to read (KDE bug 388087, fixed in KDE Plasma 5.12.1)
  • Discover’s button that takes you to the page where you can write a review now has correct padding within its overlay (KDE bug 390030, fixed in Plasma 5.12.1)
  • Fixed a prominent crash in 5.12 when searching from the app page, deleting the search term, and searching again (KDE bug 390114, fixed in Plasma 5.12.1)
  • Discover’s review submission button is now labeled “Submit” (KDE bug 390031, fixed in Plasma 5.13)
  • Discover’s review submission button is now visible but disabled for apps that aren’t installed yet, not gone entirely (KDE bug 390053, fixed in Plasma 5.13)
  • Discover (and all other Kirigami apps that have High-DPI and vector imagery) now look crisp and sharp when run in HiDPI mode (KDE bug 390076, fixed in KDE Frameworks 5.44)

If you like what you see, consider becoming a KDE contributor and join the team! The speed of improvements is pretty directly proportional to the amount of help we have, so the more hands on deck, the better KDE software becomes!

We have released version 2.9.0 of our Qt application introspection tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime. GammaRay 2.9 introduces a number of new features interesting to Qt Quick, QWidgets, Qt 3D and non-graphical Qt users alike.

Qt Quick

One focus area of this release is the paint analyzer. It got significantly improved argument inspection, stack traces for all operations, and, in addition to QWidgets, QGraphicsView and QQuickPaintedItem, it's now also available for the Qt Quick software renderer (with Qt 5.9.3 or newer) and Qt 3D painted textures. The paint analyzer now also measures the time each operation takes. With all that combined you have a powerful tool when being faced with rendering performance issues in applications using the Qt Quick software renderer.

GammaRay paint analyzer / profiler with a Qt Quick software renderer application.

 

For the Qt Quick OpenGL renderer we have some interesting new feature too of course, such as the texture inspection tab. This enables you to see the textures used on the GPU backing Image elements or Text elements using distance field rendering. This is useful to spot sub-optimal texture atlas usage, or textures containing unnecessary content, both of which can hurt GPU memory consumption. The texture inspection view supports analyzing this with diagnostic overlays, highlighting transparent borders or repeated areas that can for example be optimized by the use of BorderImage elements.

GammaRay texture inspector highlighting a largely transparent element in a texture atlas

 

Core Features

There's also new features for the non-UI aspects of Qt. The new QML binding inspector (requires Qt 5.10 or newer) allows you to analyze the dependencies of a QML property binding. It provides source code navigation to the corresponding binding dependency and thus is quite useful for debugging non-trivial binding loops.

GammaRay QML binding inspector showing a binding loop.

 

The new QObject creation stack trace view expands on the QObject creation source navigation we introduced in the previous release and also shows you the full stack trace leading up to the creation of a specific object (not available on all platforms). Very useful when you spot objects in GammaRay that shouldn't be there (anymore).

GammaRay object creation stack trace view.

 

Widgets

For QWidget users, the GammaRay widget inspector is now able to visualize the tab focus chain. This makes testing the tab order a lot more convenient than tabbing manually through a big dialog.

GammaRay tab focus chain visualization highlighting unexpected transitions.

 

Qt 3D

Qt 3D isn't forgotten either. The geometry inspector got a couple of extensions, such as vertex picking support and a number of new diagnostic shading modes that allow you to easily spot issues in e.g.  normal, tangent or texture coordinate attributes.

GammaRay Qt 3D geometry inspector visualizing the normal attribute of a vertex buffer.

 

And that's just scratching the surface, there's many more features and improvements in this release. You can find a full list of changes here.

If you like GammaRay, there's an easy way to support its development. Just enable telemetry data submission via 'Help > Contribute' in the GammaRay client. This allows us to see which platforms, Qt versions and tools are most relevant for you, so we can focus on those. Thank you!

GammaRay is available as part of Qt Automotive Suite including Qt Creator integration and professional support, or GPL-licensed on Github.

[training_callout] continue reading

The post GammaRay 2.9.0 Release appeared first on KDAB.

“Of course it runs FreeBSD, too” is something I said a lot in the past week (regarding the Pine64, mostly, but also about my Slimbook). I also said “Of course it runs on FreeBSD, too” a lot. Naturally area51, the unofficial KDE-FreeBSD ports tree, contains the latest in released KDE software. Plasma 5.12 and KDE Frameworks 5.42, with Qt 5.9.4. We just bumped Qt to pick up a patch from KDE’s Eike Hein to fix some weird hover behavior. So we’re all up-to-date on the KDE front, and I’ve been running it as my main desktop since the build finished in poudriere.

On the official ports front, Qt 5.9.4 and KDE Frameworks 5.42 are what we’ve got. There’s a big move coming up of KDE4 ports, which is to make room (in a sense) for KDE Applications and the Plasma Desktop ports. If you’re using KDE4 from ports, then expect package bumps and renames over the weekend (no functional change, just a lot of ports will get a -kde4 name to distinguish them from the currently-maintained, up-to-date un-suffixed ports which will land afterwards.

There is a dearth of good Unicode fonts for Malayalam script. Most publishing houses and desktop publishing agencies still rely on outdated ASCII era fonts. This not only causes issues with typesetting using present technologies, it makes the ‘document’ or ‘data’ created using these fonts and tools absolutely useless — because the ‘document/data’ is still Latin, not Malayalam.

Rachana Institute of Typography (rachana.org.in) has designed and published a new traditional orthography ornamental Unicode font for Malayalam script, for use in headings, captions and titles. It is named after Sundar, who was a relentless advocate of open fonts, open standards and open publishing. He dreamed of making available several good quality Malayalam fonts, particularly created by Narayana Bhattathiri with his unique calligraphic and typographic signature, freely and openly to the users. The font is licensed under OFL.

The font follows traditional orthography for Malayalam, rather than the unpleasing reformed orthography which was solely introduced due to the technical limitations of typewriters in the ’70s. Such restrictions do not apply to computers and present technology, so it is possible to render the classic beauty of Malayalam script using Unicode and Opentype technologies.

‘Sundar’ is designed by K.H. Hussain — known for his work on Rachana and Meera fonts which comes pre-installed with most Linux distributions; and Narayana Bhattathiri — known for his beautiful calligraphy and lettering in Malayalam script. Graphic engineers of STM Docs (stmdocs.in) did the vectoring and glyph creation. Yours truly took care of the Opentype feature programming. The font can be freely downloaded from rachana.org.in.

The source code of ‘Sundar’, licensed under OFL is available at https://gitlab.com/rit-fonts/Sundar.

February 08, 2018

  SoK is finally coming to an end tomorrow for the 40 days projects and it's been a great experience for me being a part of this wonderful season of code �� I learned many things during this period and most important of all, experience. I got the chance to interact more with my awesome …


Older blog entries

 

 


Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.