September 24, 2016

I started a tiny project a couple of days ago: arch-audit.

arch-audit main (and unique) goal is to display the Arch Linux packages that are affected by known vulnerabilities on your system.

To do that, arch-audit parses the CVE page on the Arch wiki, which is maintained by the Arch CVE Monitoring Team.

arch-audit output is very verbose when it’s started without any argument, but two options --quiet (or -q or -qq) and --format (or -f) allows to change the output for your use case. There’s also a third option --upgradable to display only packages that have already been fixed in the Arch Linux repositories.

In my opinion a great use case is the following:

$ ssh www.andreascarpino.it
openssl>=1.0.2.i-1
lib32-openssl>=1:1.0.2.i-1
Last login: Sat Sep 24 23:13:56 2016
$

In fact, I added a systemd timer that executes arch-audit -uq everyday and saves its output to a temporary file that is configured as banner for SSH. Then, everytime I log into my server, I get notified about packages that have vulnerabilities, but that already have been fixed. Time to do a system update!

So, now I’m waiting your feedbacks! Have fun!

BTW, Lynis already added arch-audit support!

It has been about two weeks since I last wrote about AtCore. In that time Tomaz has commited a few changes that allow us to use a plugin system so that AtCore can specialize in speaking your firmware!? Or something like that. Really what It means is that we should be able to keep most all of the common stuff within the AtCore object and use the plugins to give us firmware specific stuff when needed.

Did someone say Test?.

The test is pretty stright foward and that is to evaulate how well AtCore is doing at sending print commands to the printer to do this really we just need to be able to print an object that takes some amout of time.

Late nights printing tiny pyramids

I’ve been awake all night watching this thing print is working as expected. First I had to find a decent model to print and I came across this cool Fractal pyramid

038b2aff02be59222448f0799d856868_preview_featuredModel by ricktu

 

 

Mandatory hardware pictures ?

Two computers.. one to record and play host while the other keeps my sanity durring the nights print.It would be along print the slicer estimates the print to take around 5 hours. Ok time for the mandatory hardware pictures of stuff Check out the computer that will be hosting the printer and recording video for later.In this Set up we will have

img_20160924_061356chairs eyeview

Two cameras extruder cam and an overview cam. Sadly my 3rd camera didn’t want to play along it was

img_20160923_193812time for a new floor?

just unable to get a decent focus on the printer LCD so we will have to go without this time.

 

 Watch the Timelapse video ….7 hours later…..

After 7 hours of printing we have it completed. The Best part i have saved for last when printing

img_20160924_061312triangles……

 

i have used glow in the dark filiament. To quickly charge up the glowing i have placed

 

img_20160924_054439Glow

the model between the lights of some very bright led lamps. Unfortunately the Camera didn’t do such a great job picking up the detail with the model glowing in the dark

 

 

So how did we do?

Well the print was a success! The RAM usage was a bit high for my liking but is most likey due to our text log. We will do further tests to check that. The Firmware Plugin for Repitier seams to be printing stabily for any lenght print I would call that a success!

 

 


Dear digiKam fans and users,

After a second release 5.1.0 published one month ago, the digiKam team is proud to announce the new release 5.2.0 of digiKam Software Collection. This version introduces a new bugs triage and some fixes following new feedback from end-users.

read more

Me encanta cuando la gente de la Comunidad se va ayudando para solucionar un problema. Bienvenidos a la pequeña de historia de cómo corregir el problema del color de los menús en Inskcape que pude solucionar gracias al grupo de Telegram de KDE España conocido como Cañas y Bravas.

Cómo corregir el problema del color de los menús en Inskcape

No es que sea un especialista de Inkscape, el programa de dibujo vectorial libre, pero lo suelo utilizar para pequeños retoques o montajes. El problema venía cuando lo habría en mi openSUSE Leap 42.1 con Plasma 5.5. Resulta que los menús contextuales aparecían de una forma casi inteligible: letra blanca sobre fondo gris. Se ve perfectamente el problema en la imagen inferior.

Cómo corregir el problema del color de los menús en inskcape_01

Pensé que era algo del tema de colores Breeze pero por muchos cambios de combinaciones de colores que realicé no conseguí solucionarlo. Así que comenté en el grupo de Telegram de KDE España el problema y tras algunas sugerencias me dieron la solución.

Como sabréis, y si no lo comento ahora, Inkscape (igual que Gimp, por ejemplo) son aplicaciones que utilizan librerías Gtk, mientras que el entorno Plasma del proyecto KDE utiliza Qt. En estos casos, Plasma intenta utilizar una decoración especial pero al parecer no está del todo ajustada.

Para solucionar el problema debemos ir a las Preferencias del Sistema, ir a la sección Colores y dirigirnos a la segunda pestaña “Opciones”. Ahora deberemos quitar la opción “Aplica los colores a las aplicaciones no-Qt” y automáticamente se soluciona el problema.

 

Cómo corregir el problema del color de los menús en inskcape_02

En la imagen inferior podemos ver como ahora tenemos la letra blanca pero el fondo es oscuro, teniendo una visibilidad perfecta y dejando ahora a Inkscape perfectamente funcional.Cómo corregir el problema del color de los menús en inskcape_03

En definitiva, una solución sencilla para un problema que nos puede dar algún dolor de cabeza de tanto forzar la vista.

 

September 23, 2016

Aunque KDE Blog es un blog que suele escribir solo un servidor, siempre ha estado abierto a colaboraciones. Este es el caso del presente artículo de la eescritora invitada Edith Gómez, editora en Gananci, apasionada del marketing digital y  especializada en comunicación online que nos presenta “5 herramientas Software Libre para emprendedores”.

 

 

5 herramientas Software Libre para emprendedores

Cuando comenzamos un negocio sabemos que los gastos van a ser muy notables y que, en muchos casos, terminaremos poniendo dinero de nuestro propio bolsillo sin ver ningún tipo de ganancia durante los primeros meses de vida. Aunque existen algunos gastos de los que no nos podemos olvidar, como la renta, las facturas mensuales o la compra de mercancía, hay otros que sí podemos evitar si hacemos uso de herramientas gratuitas que están a nuestro alcance.
Hoy en día no podemos darnos el capricho de desarrollar un negocio sin hacer uso de las herramientas tecnológicas, porque fácilmente podemos desaparecer.
Por ejemplo, los negocios pequeños que ni tienen un local establecido, estarán logrando desarrollarse a partir del potencial que consiguen de las redes sociales. Otros, sin embargo, cuentan con programas o aplicaciones útiles que les simplifican el día a día rutinas muy comunes.
Por esto mismo es fundamental que conozcas cuáles son las opciones de software gratuitas y más viables con el fin de exponer y potencia lo máximo posible tu negocio.

 

1. Punto de venta: LemonPOS

Si tienes un negocio o empresa en el que ofreces servicios o productos es muy útil que cuentes con un sistema de punto de venta cara al público (comúnmente denominados POS, “point of sale” o TPV, “terminal punto de venta”).
Este tipo de software facilita las transacciones realizadas entre los clientes y los negociantes. Aumenta la eficiencia de los trabajadores y también automatiza la generación de reportes y otros procesos.
LemonPOS es un tipo de software caracterizado por ser de código abierto para el punto de venta que emplea MySQL en la conexión con bases de datos. Este estilo de programación basado en el cliente/servidor, permite que podamos ejecutar el programa desde las sucursales de nuestra empresa, pudiendo conectarse la base de datos central. Por si fuera poco, cuenta con una interfaz muy sencilla y agradable a la vista, por lo que cualquier usuario puede utilizarla de forma intuitiva.
Dos aplicaciones son las que componen LemonPOS: Lemon, centrada en la función de ventas y, Squeeze, aplicación a través de la que se gestionan los productos (agregar, eliminar, cambiar el precio, agregar descuentos, etc.) que se verán en Lemon para poder adquirirse. En la actualidad este software solamente está disponible para Linux, aunque se espera que en un futuro próximo esté disponible la versión para Windows.

 

2. Finanzas/contabilidad: GnuCash

GnuCash es un sistema de contabilidad que vio la luz con el objetivo de dar soporte personal al usuario. Si bien, poco a poco se ha convertido en una solución enfocada a las pequeñas y medianas empresas (“Pyme”). Puede ser instalado en sistemas operativos como son Windows, Linux y Mac OSX. Cuenta con una app, aplicación, en Google Play.
GnuCash es un sistema estupendo ya que lleva la contabilidad de todos los pequeños negocios. Además es capaz de generar informes totalmente personalizados, programar transacciones, o de gestionar presupuestos, entre otras acciones.

 

3. Facturación: Codeka

Codeka es una aplicación centrada en controlar las facturas y todas las actividades relacionadas con el almacenaje de una PYME. Entre sus principales aspectos se hallan: la gestión de los clientes y proveedores, de los artículos, categorías o familias, de cobras y pagos, la creación de nuevos códigos de barras con el fin de identificar los productos y también una terminal de punto de venta (TPV).

 

4. Paquetería de Office

Es imprescindible que el día a día un empresario termine utilizando un procesador de textos y una hoja de cálculo, puesto que sirven para crear desde un letrero hasta reportes de gran utilidad. Si bien, conocemos el coste que supone comprar una licencia y también el rendimiento tan limitado que suelen tener los ordenadores, por lo que te proponemos las siguientes soluciones.
Microsoft Office es el software más grande que hay dentro de la oficina, pero también existen otras soluciones para crear documentos con las mismas características. Entre ellos se encuentran el Open Office y el Libre Office, que ya llevan mucho tiempo ayudándonos. El chico nuevo entre estos se conoce como Kingsoft Office, un software chino cuya interfaz es prácticamente igual a la de Microsoft Office.

 

5. Marketing y Publicidad

Además de las herramientas para la gestión adecuada de las actividades correspondientes al negocio, también es útil contar con herramientas que nos puedan ayudar a elaborar la imagen corporativa y empresarial como el logo, el lema, etc. Es importante también que creemos anuncios, volantes y otro tipo de recursos.
Para la creación del logo podemos utilizar la herramienta conocida como InkScape, tiene un código abierto para la edición de gráficos vectoriales. Es muy parecido al Adobe. Su interfaz es simple, limpia y sencilla por lo que podrás crear tu logotipo con total facilidad, manipular los objetos y realizar perfectos diseños.
Los diseños creados en InkScape puedes distribuirlos en tus redes sociales con el fin de darles un toque más personal o también en tu web de negocio. Para esto puedes utilizar el software de maquetación Scribus, que da lugar a la creación de publicaciones con un toque más profesional.
Twitter: @edigomben

Today’s weekly mobile IMG update brings,

  • Updated packages
  • New appstream release
  • Kirigami based new discover design

You can flash using instructions at https://plasma-mobile.org/nexus-5/

September 22, 2016

This announcement is also available in Italian and Taiwanese Mandarin.

The latest updates for KDE's Plasma, Applications and Frameworks series are now available to all Chakra users.

The Plasma 5.7.5 release is the final bugfix update for the 5.7.x series, as 5.8.0 will be released soon. It includes a month's worth of bugfixes and new translations, with notable changes found in the plasma workspace, sddm-kcm and networkmanager packages.

Applications 16.08.1 include more than 45 recorded bugfixes and improvements to kdepim, kate, kdenlive, konsole, marble, kajongg, kopete, umbrello, among others.

Frameworks 5.26.0 include bugfixes and improvements to breeze icons, plasma framework, kio, ktexteditor and sonnet.

Other notable package upgrades:

[core]

  • cups 2.1.4
  • git 2.10.0
  • mariadb 10.1.17 providing the security fix of MySQL 0-day "CVE-2016-6662"
  • php 5.6.25
  • poppler 0.47.0 - this breaks backward compatibility, if you have any local/CCR packages depending on it you will have to recompile them

    [desktop]
  • pdf2svg 0.2.3

    [lib32]
  • wine 1.9.19

    [gtk]
  • amule 10958

    It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.

    Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade. To be sure, please use the mirror status page to check that your mirror synchronized with our main server after this announcement.
  • Hi everybody,

    After announcing that our timeline was translated into Spanish, now I want to announce that it is also available in Chinese. Thanks to Leslie Zhai now we have one version of the timeline in Chinese simplified.

    screenshot_20160922_130829

    Screenshot of Chinese version.

    Besides that I did some adjustments as captions centralized, images turned into links, and improvement in the captions texts.

    If you also have any suggestions, translation, or adjustment, let me know.  Our repository can be cloned here


    A few weeks ago after discussing with Luke Yelavich about what to work on in speech-dispatcher next I decided to take a stab at making it use GSettings for its settings. (You can see the work in progress here if you like.) I've used GSettings before for work projects so thought it would be a good/easy thing to take on.

    There are many advantages of using GSettings over plain ini-style files.

    • Type checking (You can't enter a string for a numeric setting for example).
    • Notification of setting changes.
    • Command-line changing of settings.
    • Default values for settings defined in the schema(s).

    On that wip branch speech-dispatcher itself has been changed to use GSettings and also reacts to many setting changes dynamically. It doesn't react to changing the port type or port number or unix socket path dynamically, since we have no mechanism to tell client applications that it is changing. There are also GSettings schemas for the output modules, just need to make them read their settings from GSettings instead of the old ini-style .conf files. spd-conf also has been modified to write to GSettings rather than .conf files. That change alone reduced the spd-conf python script by quite a few lines of code and made it a lot easier to read.

    As I was doing this work I got thinking about the differences between GSettings and QSettings. Besides one being glib/c based and the other being Qt/C++ they are really pretty similar. There are a few differences though:
    • QSettings doesn't emit signals when a setting changes. (I found a few forum posts asking why this is with possible workarounds. Nothing built into QSettings though).
    • QSettings doesn't have a schema for the settings themselves. There's no way to introspect a setting file to see what settings are possible. It just depends what keys the application reads.
    • QSettings doesn't have a command-line tool to set the settings. Since QSettings is cross platform it uses the Registry by default on Windows, PList files by default on macOS, and ini-style files on linux
    • QSettings does have type checking, but no range checking or anything like that.

    I was a bit disappointed that QSettings that I've used for many many years is lacking these seemingly obvious and probably useful features. I wonder if we as a community implemented these features in QSettings if the Qt company would accept them.

    toolboxWe’ve added a new Toolbox section that has posts dedicated to new and improved functionality in Kdenlive. Check back regularily for updates.

    In a few weeks the Qt World Summit 2016 will open its doors in San Francisco and I have been given the chance to speak there about my experiences while developing the Qt World Summit 2016 Conference App. This article series here will give you some additional information to my presentation.

    For nearly 40 years I have been developing software, where the last 8 years I have focused on mobile App Development. I started mobile App Development with BlackBerry OS7 (Java) followed by BlackBerry 10 native Apps (Qt 4.8, Cascades UI Controls).

    In 2016 BlackBerry, for first time ever, started to build secure Android Phones and my customers asked for x-platform Apps. Personally, I liked the way BlackBerry 10 Apps were built using QML and Cascades. Fortunately Qt just started Qt 5.6 Tech Preview of new Qt Quick Controls 2. I did some first tests to see if Qt Quick Controls 2 will enable me to develop good looking and performant mobile Apps.

    First steps went well so I decided to spend some more time and to give Qt 5.7 and Qt Quick Controls 2 a try in real-life projects. Over the last 4 years I built many mobile business Apps for Enterprise and SMB and I also did some Apps for Developer Conferences.

    I asked Tero Kojo to develop the QtCon 2016 Conference App as a proof-of-concept to rely on new Qt Quick Controls 2. You can download the QtCon Conference App from Google Play (https://play.google.com/store/apps/details?id=org.ekkescorner.c2g.qtcon), Apple App Store (https://itunes.apple.com/us/app/qtcon-2016-conference-app/id1144162386), Amazon App Store (https://www.amazon.com/ekkescorner-QtCon-2016-Konferenz-App/dp/B01L7DVJTO), as APK (https://app.box.com/s/fgeo14re3hrp47shg915geo1q4gzyxrz) or build it by yourself from Open Source Github Repo (https://github.com/ekke/c2gQtCon_x).

    The App was built without any extra native Code – pure Qt only. Feedback was great and I just started to do the Qt World Summit 2016 Conference App – Github Repo will be public soon. Hopefully this time the App will also be available for Windows 10 from Windows App Store. Special thanks to Maurice Kalinowski for his help, the QtCon Conference App is running on Windows 10, although I had some problems uploading this to Windows App Store.

    There is a blog series about all my experiences using Qt Quick Controls 2 to develop mobile Apps (http://j.mp/qt-x), also a series in (German) Web & Mobile Developer Magazin and now some articles here at Qt Blog, too. You can expect some 3 – 4 articles here at Qt Blog about developing Qt Conference Apps.

    All development is done in my spare time and my goal is to motivate mobile App Developers to try out Qt Quick Controls 2 to develop x-platform Apps. I never did Qt development before, also never did native Apps for Android, iOS or Windows but now I am able to develop and upload Apps to Google Play or Apple App Store :) I am also using Google Material Style to provide a modern mobile App feeling. Thanks to J-P Nurmi, Mitch Curtis and others for great hints HowTo customize Qt Quick Controls 2.

    From my experiences over the last 6 months, developing mobile Apps with Qt 5.7 and Qt Quick Controls 2 is much more comfortable and easier than using Xamarin, React Native, Cordova, Angular or Ionic. The good news for all my friends from BlackBerry 10 community: there is a great amount of re-use of C++ Code from Cascades and also architecture style is similar using Signals/Slots and QObject* as data model.

    Speed is key to success

    The first impression of any mobile App with regards to User Experience comes from starting the App. The User should never have the feeling that an App is slow. Some of my recipes for a speedy start are below:

    • fast creation of C++ Classes
    • immediately show something on the screen
    • be dynamic: only instantiate UI Controls you really need

    How am I doing this? Only instantiate C++ Classes, avoid any initialization as open Databases, load Cache Files and more.

    DataServer::DataServer(QObject *parent) : QObject(parent)
    {
        // Do NOTHING HERE
    }

    Use the fastest possible way to show some UI to the User. My root and main Navigation Control is a Drawer. The Drawer contains a list of “Destinations“, where a Destination is a specific area of the Application as

    • Home
    • Schedule
    • Speakers
    • Venue

    01_drawer

    Each Destination can be one of the Qt Quick Controls 2 Navigation Controls (http://doc.qt.io/qt-5/qtquickcontrols2-navigation.html) or Container Controls(http://doc.qt.io/qt-5/qtquickcontrols2-containers.html):

    • Pane
    • Page
    • StackView
    • SwipeView / Tab Bar

    Inside the Drawer you can use a ListView to let the User select a Destination – take a look at Qt Quick Controls 2 Gallery Example. I‘m using a Repeater to create different types of Controls: Destinations, Divider, Header, …

    To show the selected Destination best way is to use a StackView as your root UI Control and swap the content – so there‘s always only one Item at this root StackView.

    02_destinations

    To startup immediately don‘t create all the Drawer – Destinations ! This can easy be done with a little trick: define the Repeater without a data model.

            Repeater {
                id: destinations
                // Don‘t set the model here !
                // model: navigationModel
                Destination {
                    id: destinationLoader
                }
            }
    
    

    So nothing will be created now. To show something to the User create a lightweight Control as initialItem. I‘m using a BusyIndicator.

            // STACK VIEW INITIAL ITEM (BUSY INDICATOR)
            // immediately activated and pushed on stack as initialItem
            Loader {
                id: initialPlaceholder
                source: "pages/InitialItemPage.qml"
                active: true
                visible: false
                onLoaded: {
                    // Show BUSY INDICATOR
                    rootPane.initialItem = item
                    item.init()
                    // Now something is VISIBLE - do the other time-consuming stuff
                    startupDelayedTimer.start()
                }
            }
    
    

    The next trick is to start a Timer with a small delay to allow QML to show and animate the BusyIndicator. Then from Timer timeout execute all the initialization stuff and call some Q_INVOKABLE methods from your C++ Classes to load data from Cache and more.

    As soon as this is done you can go on with creation of UI Controls. To trigger this set the Repeater Data Model and all the Destinations will be created and HomePage will become current Item on root StackView.

            Timer {
                id: startupDelayedTimer
                interval: 300
                repeat: false
                onTriggered: {
                    initialPlaceholder.item.showInfo("Initialize Data ...")
                    dataManager.init()
                    settings = dataManager.settingsData()
                    dataUtil.setSessionFavorites()
                    // … and so on ...
                    // inject model into Destinations Repeater
                    destinations.model = navigationModel
                    // show the Navigation Bars (Drawer and Favorites)
                    initDone = true
                    // now NavigationBars available
                    // show first destination
                    rootPane.activateDestination(firstActiveDestination)
                }
            }

     

    Here we go: first „real“ Page is visible.

    But wait: not all Destinations will really be created from the Repeater – this would take too much time and consume too much memory. All the Destinations are created dynamically using Loaders and I implemented some Activation Policies:

    • Immediate: The Control will be instantiated and remain. I‘m using this only for the first visible Page – the HomePage.
    • When-Selected: First time a User selects a Destination will create the Control and remain. This happens for all Destinations a User normaly will use while the App is running: Schedule, Speakers,…
    • While-Selected: Those Destinations are only created when needed and be destroyed if User changes the Destination. Candidates for this Policy: Help, Settings, About, …

    Take a look at the code how all of this is implemented, attend my Session at Qt World Summit 2016 in San Francisco (http://www.qtworldsummit.com/speakers/ekkehard-gentz/) or meet me at #QtWS16.

    Stay tuned – next article will cover the QObject* Data Model I‘m using, Caching and Data Binding.

    The post Qt Conference Apps – out of the Developer Trenches – Part 1 appeared first on Qt Blog.

    Aunque el proyecto KDE Neon es muy reciente, el impacto en la Comunidad está siendo importante. Es por ello que me complace presentar el análisis de KDE NEON 16.04 con Plasma 5.7.2 que ha realizado CoperFix con el que nos podremos hacer una idea del estado de esta iniciativa.

    Análisis de KDE NEON 16.04 con Plasma 5.7.2

    Análisis de KDE NEON 16.04 con Plasma 5.7.2

    Como he comentado en la introducción, de la mano de CoperFix nos llega un interesante vídeo donde realiza un Análisis KDE NEON 16.04 con Plasma 5.7.2.

    En los más de 15 minutos que dura el vídeo, además de ver el funcionamiento de KDE Neon, nos muestra detalles como:

    • Donde ver las versiones de los componentes.
    • El consumo de recursos, que comenta que está muy optimizado (se me escapó el spoiler)
    • La página oficial donde descargar el sistema y las distintas versiones que tenemos del mismo.
    • Lo vacío que viene la colección de aplicaciones y fondos de pantalla. De hecho, él comenta las aplicaciones que ha instalado para probar cosa.
    • Comenta Kwallet, su utilidad pero lo pesado que acaba resultando.
    • También comenta los problemas que tiene con las traducciones y la forma de solucionarlo.
    • Del mismo modo soluciona el problema de no tener las previsualizaciones de los vídeos en Dolphin.
    • Cambiar los lanzadores de aplicaciones o las barras de tareas.
    • Habla de Discover, la tienda de aplicaciones que pinta bien pero que todavía tiene errores.
    •  Después se centra en el maravilloso Preferencias del Sistema con el que podemos personalizar nuestro Plasma 5.
    • Nos enseña algunas animaciones y algunas características de Dolphin.

     

    En definitiva, un excelente vídeo 100% recomendable para cualquiera que quiera iniciarse en el maravilloso mundo de los escritorios Linux utilizando el mejor, a mi entender, de ellos: Plasma 5.

    Si os ha gustado, como suelo decir, no olvidéis dar un Like y, si os animáis, realizar un comentario. Estoy seguro que CoperFix os lo agradecerá.

    Kubuntu 16.10 beta has been published. It is possible that it will be re-spun, but we have our beta images ready for testing now.

    Please go to http://iso.qa.ubuntu.com/qatracker/milestones/367/builds, login, click on the CD icon and download the image. I prefer zsync, which I download via the commandline:

    ~$ cd /media/valorie/ISOs (or whereever you store your images)
    ~$ zsync http://cdimage.ubuntu.com/kubuntu/daily-live/20160921/yakkety-desktop-i386.iso.zsync

    The other methods of downloading work as well, including wget or just downloading in your browser.

    I tested usb-creator-kde which has sometimes now worked, but it worked like a champ once the images were downloaded. Simply choose the proper ISO and device to write to, and create the live image.

    Once I figured out how to get my little Dell travel laptop to let me boot from USB (delete key as it is booting; quickly hit f12, legacy boot, then finally I could actually choose to boot from USB). Secure boot and UEFI make this more difficult these days.

    I found no problems in the live session, including logging into wireless, so I went ahead and started firefox, logged into http://iso.qa.ubuntu.com/qatracker, chose my test, and reported my results. We need more folks to install on various equipment, including VMs.

    When you run into bugs, try to report them via "apport", which means using ubuntu-bug packagename in the commandline. Once apport has logged into launchpad and downloaded the relevant error messages, you can give some details like a short description of the bug, and can get the number. Please report the bug numbers on the qa site in your test report.

    Thanks so much for helping us make Kubuntu friendly and high-quality.

    September 21, 2016

    I read that Neon Dev Edition Unstable Branches is moving to Plasma Wayland by default instead of X.  So I thought it a good time to check out this week’s Plasma Wayland ISO. Joy of joys it has gained the ability to work in VirtualBox and virt-manager since last I tried.  It’s full of flickers and Spectacle doesn’t take screenshots but it’s otherwise perfectly functional.  Very exciting 🙂

     

    Facebooktwittergoogle_pluslinkedinby feather

    We’re only one month away from the deadline for submissions for the 2016 Krita Artbook! We’ve already received a lot of great submissions, but you should still submit your work if you want to be part of the very first Krita Art book.

    This book will be sent out to the seventy Kickstarter backers who selected the artbook as their reward, and it will be available from the Krita shop.

    kiki_artbook_small

    Here’s a short recap of the rules:

    • A competent jury will judge all submissions and pick the best, since space is going to be limited
    • Use Krita 3.0.1′ new soft-proofing feature together with the Fogra39 CMYK profiles (260, not 300) to check your colors. The color pages will be glossy, so use the coated variant.
    • The book will be printed professionally, either hard-cover or soft-cover (that depends on the final page count).
    • The dimensions are 200 x 280 mm.
    • There will be a glossy color page and a black & white page available for every artist.
    • The black & white page contains information about you, whatever you want to tell the world.
    • There will be room for a black & white illustration as well.

    Here’s a mock-up of what we intend:

    spread

    If you want to be in on it, send your submission to foundation@krita.org. We need the following:

    • Your color art work at the full resolution: a minimum resolution of 150dpi but our experience is that 300dpi looks better.
    • Keep at least 3mm bleed on the outside of your picture (making the submission size 206×286 mm) and add cutting marks if you know how (if you don’t know how, we do, and will add them).
    • An optional black & white artwork. This needs to be even higher resolution (600dpi) since the black and white pages are printed at a higher resolution.
    • Information about you: a short bio, contact details — whatever you want to tell about yourself, about half a page so there’s room for the B&W artwork. There is no real-names rule: you can call yourself what you want.

    The artwork needs to conform to a few rules:

    • There is no set topic: just show off what you think you do best! But…
    • No gore or pornography. Nudity is fine, flashing swords are fine, people being strangled by their own guts, no.
    • No fan-art or characters copyrighted by others than you.
    • Made using Krita: you can use other tools, too, but Krita has to be used for most of the work.

    The deadline for submissions is November 1st!

    Send your submission to foundation@krita.org

    Save

    Save

    Save

    Save

    September 20, 2016

    KDE Project:

    Cool, Kexi 3.0.0 Beta 1 and related libraries have landed, ready for testing and packaging. Please find downloads and change logs at https://community.kde.org/Kexi/Releases/3#3.0.0_Beta_1

    As usual report bug and wishes are welcome, details at https://community.kde.org/Calligra/File_a_bug_or_wish.

    This time the release got automated a bit more. Changelogs generated with some bash coding can be now easily pasted on the wiki, and mediawiki templates {{bug}}, {{commit}}, {{diff}} work also for your project, on any wiki page. What are your favourite changelog tools? Maybe Phabricator would offer something ultimate like https://secure.phabricator.com/w/changelog/?

    Later we would move some content from wiki to semi-static generated pages on kexi-project.org. So this obsolete page would become more like marble.kde.org or kate-editor.org.

    I know, I know. it's hard to try without examples and tutorials. Stay tuned. For now, API docs sit at at https://api.kde.org/playground-api/libs-apidocs, a temporary location.

    Have fun!

    the case of the one byte packet

    Yesterday I pushed a change set for review that fixes an odd corner case for the Guam IMAP proxy/filter tool that was uncovered thanks to the Kolab Now Beta program which allows people to try out new exciting things before we inflict them upon the world at large. So first let me thank those who are using Kolab Now Beta and giving us great and valuable feedback before turning to the details of this neat little bug.

    So the report was that IMAP proxying was breaking with iOS devices. But, and here's the intriguing bit, only when connecting using implicit TLS; connecting to the IMAP server normally and upgrading with STARTTLS worked fine. What gives?

    In IMAP, commands sent to the server are expected to start with a string of characters which becomes the identifying tag for that transaction, usually taking the form of "TAG COMMAND ARGS". The tag can be whatever the client wants, though many clients just use a number that increases monotonically (1, 2, 3, 4, ...). The server will use that tag to prefix the success/failure response in the case of multi-line responses, or tag the response itself in the case of simpler one-line responses. This allows the client to match up the server response with the request and know when the server is indeed finished spewing bytes at it.

    We looked at the network traffic and in that specific case iOS devices fragment the IMAP client call into one packet with the tag and one packet with the command. No other client does this, and even iOS devices do not do this when using the STARTTLS upgrade mechanism. As a small performance hack, I had allowed the assumption that the "TAG COMMAND" part of client messages would never be fragmented on the network. This prevented the need for buffering and other bookkeeping in the application within a specific critical code path. It was an assumption that was indeed not guaranteed, but the world appeared to be friendly and cooperating. After all, what application would send "4" in one network packet, and then "XLIST" in a completely separate one? Would it (the application, the socket implementation, ..) not compose this nicely into one little buffer and send it all at once? If so, what network topology would ever fragment a tiny packet of a few dozen bytes into one byte packets? Seemed safe enough, what could go wrong .. oh, those horrible words.

    So thanks to one client in one particular configuration being particularly silly, if technically still within its rights, I had to introduce a bit of buffering when and where necessary. So I took the opportunity to do a little performance enhancement that was on my TODO while I was mucking about in there: tag/command parsing which is necessary and useful for rules to determine whether they care about the current state of the connection, is now both centralized and cached. So instead of happening twice for each incoming fragment of a command (in the common case), it now happens at most once per client command, and that will hold no matter how many rules are added to a ruleset.

    So, one bug squashed, and one little performance enhancement, thanks to user feedback and the Kolab Now Beta program. As soon as the patch gets through code review, it should get pushed through packaging and deployed on Kolab Now Beta. Huzzah.a

    September 19, 2016

    cafe-sept-16
    Today we will start again our monthly Kdenlive Café after a summer pause. All interested users are invited to join in for this informal meeting.
    The Café will take place this tuesday, 20th of september 2016, at 9pm Central European Summer Time (CEST = UTC + 2), on our usual #kdenlive channel on irc.freenode.net.
    Among the topics, we will make a quick evaluation of the current 16.08.x release, discuss the roadmap for 16.12 and also share infos on the current state of packaging, how to get involved and much more. Feel free to join us!

    Jean-Baptiste Mardelle

    Our packaging team has been working very hard, however, we have a lack of active Kubuntu Developers involved right now. So we're asking for Devels with a bit of extra time and some experience with KDE packages to look at our Frameworks, Plasma and Applications packaging in our staging PPAs and sign off and upload them to the Ubuntu Archive.

    If you have the time and permissions, please stop by #kubuntu-devel in IRC or Telegram and give us a shove across the beta timeline!

    KDevelop 5.0.1 released

    One month after the release of KDevelop 5.0.0, we are happy to release KDevelop 5.0.1 today, fixing a list of issues discovered with 5.0.0. The list of changes below is not exhaustive, but just mentions the most important improvements; for a detailed list, please see our git history.

    An update to version 5.0.1 is highly recommended for everyone using 5.0.0.

    Issues fixed in 5.0.1

    • Fix a deadlock in the background parser, which especially occured on projects containing both C++ and Python/JS/QML code and caused either parsing or the whole application to freeze randomly. [BR: 355100]
    • Do not display the "project is already open in a different session" dialog on starting up a session under some circumstances.
    • Fix a crash which sometimes happened when switching git branches on command line.
    • Fix a crash when starting debugger from command-line. [BR: 367837]
    • Mouseover highlight now uses the "Search highlight" color from the configuration dialog, instead of a hard-coded bright yellow. [BR: 368458]
    • Fix a crash in the PHP plugin when editing text in the line after a "TODO". [BR: 368257]
    • Fix working directory of Custom Makefile plugin [BR: 239004]
    • Fix a possible crash on triggering an assistant popup action [BR: 368270]
    • Fix a freeze under some circumstances when the welcome page is displayed. [BR: 368138]
    • Fix some translation issues.
    • Fix imports sometimes not being found in kdev-python without pressing F5 by hand [BR: 368556]

    Issues fixed in the Linux AppImage

    • Ship the subversion plugin.
    • Fix QtHelp not working.
    • Ship various X11 libraries, which reportedly makes the binary run on relatively old systems now (SLES 11 and similar)
    • Disable the welcome page for now.

    Download

    The source code for 5.0.1 is available here: http://download.kde.org/stable/kdevelop/5.0.1/src/
    Source archives are signed with the GPG key of Sven Brauch, key fingerprint 4A62 9799 32BB BCE5 E395 6ACF 68CA 8E38 C4BB 3F4B.

    The AppImage pre-built binaries for Linux can be downloaded from here: http://download.kde.org/stable/kdevelop/5.0.1/bin/linux/

    sbrauch Mon, 09/19/2016 - 17:30
    Category

    Comments

    Permalink

    In reply to by Chris Hills (not verified)

    Hmm. I tried with chrome and chromium, works fine for me. Which URL did you request exactly?

    Speaking of highlights and colors, I know it is possible to change the "Global colorization intensity" but what about the actual colors of cout, string etc?

    I have to admit I tried to modify each and every color and checkbox for the color scheme of sources/c++, but I haven't found how to change this redish cout's or cin's color.

    Permalink

    In reply to by Petros (not verified)

    The colors for the semantic highlighting are currently not configurable, sorry. They can just be changed in their intensity and they adjust to the background brightness.

    Creating devices with multiple screens is not new to Qt. Those using Qt for Embedded in the Qt 4 times may remember configuration steps like this. The story got significantly more complicated with Qt 5’s focus on hardware accelerated rendering, so now it is time to take a look at where we are today with the upcoming Qt 5.8.

    Windowing System Options on Embedded

    The most common ways to run Qt applications on an embedded board with accelerated graphics (typically EGL + OpenGL ES) are the following:

    • eglfs on top of fbdev or a proprietary compositor API or Kernel Modesetting + the Direct Rendering Manager
    • Wayland: Weston or a compositor implemented with the Qt Wayland Compositor framework + one or more Qt client applications
    • X11: Qt applications here run with the same xcb platform plugin that is used in a typical desktop Linux setup

    We are now going to take a look at the status of eglfs because this is the most common option, and because some of the other approaches rely on it as well.

    Eglfs Backends and Support Levels

    eglfs has a number of backends for various devices and stacks. For each of these the level of support for multiple screens falls into one of the three following categories:

    • [1] Output management is available.
    • [2] Qt applications can choose at launch time which single screen to output to, but apart from this static setting no other configuration option is provided.
    • [3] No output-related configuration is provided.

    Note that some of these, in particular [2], may require additional kernel configuration via a video argument or similar. This is out of Qt’s domain.

    Now let’s look at the available backends and the level of multi-display support for each:

    • KMS/DRM with GBM buffers (Mesa (e.g. Intel) or modern PowerVR and some other systems) [1]
    • KMS/DRM with EGLDevice/EGLOutput/EGLStream (NVIDIA) [1]
    • Vivante fbdev (NXP i.MX6) [2]
    • Broadcom Dispmanx (Raspberry Pi) [2]
    • Mali fbdev (ODROID and others) [3]
    • (X11 fullscreen window – targeted mainly for testing and development) [3]

    Unsurprisingly, it is the backends using the DRM framework that come out best. This is as expected, since there we have a proper connector, encoder and CRTC enumeration API, whereas others have to resort to vendor-specific solutions that are often a lot more limited.

    We will now focus on the two DRM-based backends.

    Short History of KMS/DRM in Qt

    Qt 5.0 – 5.4

    Qt 5 featured a kms platform plugin right from the beginning. This was fairly usable, but limited in features and was seen more as a proof of concept. Therefore, with the improvements in eglfs, it became clear that a more unified approach was necessary. Hence the introduction of the eglfs_kms backend for eglfs in Qt 5.5.

    Qt 5.5

    While originally developed for a PowerVR-based embedded system, the new backend proved immensely useful for all Linux systems running with Mesa, the open-source stack, in particular on Intel hardware. It also featured a plane-based mouse cursor, with basic support for multiple screens added soon afterwards.

    Qt 5.6

    With the rise of NVIDIA’s somewhat different approach to buffer management – see this presentation for an introduction – an additional backend had to be introduced. This is called eglfs_kms_egldevice and allows running on the automotive-oriented Jetson Pro, DRIVE CX and DRIVE PX systems.

    The initial version of the plugin was standalone and independent from the existing DRM code. This led to certain deficiencies, most notably the lack of multi-display support.

    Qt 5.7

    Fortunately, these problems got addressed pretty soon. Qt 5.7 features proper code sharing between the backends, making most of the multi-display support and its JSON-based configuration system available to the EGLStream-based backend as well.

    Meanwhile the GBM-based backend got a number of fixes, in particular related to the hardware mouse cursor and the virtual desktop.

    Qt 5.8

    The upcoming release features two important improvements: it closes the gaps between the GBM and EGLStream backends and introduces support for advanced configurability. The former covers mainly the handling of the virtual desktop and the default, non-plane-based OpenGL mouse cursor which was unable to “move” between screens in previous releases.

    The documentation is already browsable at the doc snapshots page.

    Besides the ability to specify the virtual desktop layout, the introduction of the touchDevice property is particularly important when building systems where one or more of the screens is made interactive via a touchscreen. Let’s take a quick look at this.

    Touch Input

    Let’s say you are creating digital instrument clusters with Qt, with multiple touch-enabled displays involved. Given that the touchscreens report absolute coordinates in their events, how can Qt tell which screen’s virtual geometry the event should be translated to? Well, on its own it cannot.

    From Qt 5.8 it will be possible to help out the framework. By setting QT_LOGGING_RULES=qt.qpa.*=true we enable logging which lets us figure out the touchscreen’s device node.  We can then create a little JSON configuration file on the device:

    {
        "device": "drm-nvdc",
        "outputs": [
          {
            "name": "HDMI1",
            "touchDevice": "/dev/input/event5",
          }
        ]
    }
    

    This will come handy in any case since configuration of screen resolution, virtual desktop layout, etc. all happens in the same file.

    Now, when a Qt application is launched with the QT_QPA_EGLFS_KMS_CONFIG environment variable pointing to our file, Qt will know that the display connected to the first HDMI port has a touchscreen as well that shows up at /dev/input/event5. Hence any touch event from that device will get correctly associated with the screen in question.

    Qt on the DRIVE CX

    Let’s see something in action. In the following example we will use an NVIDIA DRIVE CX board, with two monitors connected via HDMI and DisplayPort. The software stack is the default Vibrante Linux image, with Qt 5.8 deployed on top. Qt applications run with the eglfs platform plugin and its eglfs_kms_egldevice backend.

    drivecx_small

    Our little test environment looks like this:

    disp_both

    This already looks impressive, and not just because we found such good use for the Windows 95, MFC, ActiveX and COM books hanging around in the office from previous decades. The two monitors on the sides are showing a Qt Quick application that apparently picks up both screens automatically and can drive both at the same time. Excellent.

    The application we are using is available here. It follows the standard multi-display application model for embedded (eglfs): creating a dedicated QQuickWindow (or QQuickView) on each of the available screens. For an example of this, check the code in the github repository, or take a look at the documentation pages that also have example code snippets.

    A closer look reveals our desktop configuration:

    disp2

    The gray MouseArea is used to test mouse and touch input handling. Hooking up a USB touch-enabled display immediately reveals the problems of pre-5.8 Qt versions: touching that area would only deliver events to it when the screen happened to be the first one. In Qt 5.8 this is can now be handled as described above.

    disp1

    It is important to understand the screen geometry concepts in QScreen. When the screens form a virtual desktop (which is the default for eglfs), the interpretation is the following:

    • geometry() – the screen’s position and size in the virtual desktop
    • availableGeometry() – without a windowing system this is the same as geometry()
    • virtualGeometry() – the geometry of the entire virtual desktop to which the screen belongs
    • availableVirtualGeometry() – same as virtualGeometry()
    • virtualSiblings() – the list of all screens belonging to the same virtual desktop

    Configuration

    How does the virtual desktop get formed? It may seem fairly random by default. In fact it simply follows the order DRM connectors are reported in. This is often not ideal. Fortunately, it is configurable starting with Qt 5.8. For instance, to ensure that the monitor on the first HDMI port gets a top-left position of (0, 0), we could add something like the following to the configuration file specified in QT_QPA_EGLFS_KMS_CONFIG:

    {
      "device": "drm-nvdc",
      "outputs": [
        {
          "name": "HDMI1",
          "virtualIndex": 0
        },
        {
          "name": "DP1",
          "virtualIndex": 1
        }
      ]
    }
    

    If we wanted to create a vertical layout instead of horizontal (think an instrument cluster demo with three or more screens stacked under each other), we could have added:

    {
      "device": "drm-nvdc",
      "virtualDesktopLayout": "vertical",
      ...
    }
    

    More complex layouts, for example a T-shaped setup with 4 screens, are also possible via the virtualPos property:

    {
      ...
      "outputs": [
        { "name": "HDMI1", "virtualIndex": 0 },
        { "name": "HDMI2", "virtualIndex": 1 },
        { "name": "DP1", "virtualIndex": 2 },
        { "name": "DP2", "virtualPos": "1920, 1080" }
      ]
    }
    

    Here the fourth screen’s virtual position is specified explicitly.

    In addition to virtualIndex and virtualPos, the other commonly used properties are mode, physicalWidth and physicalHeight. mode sets the desired mode for the screen and is typically a resolution, e.g. “1920×1080”, but can also be set to “off”, “current”, or “preferred” (which is the default).

    For example:

    {
      "device": "drm-nvdc",
      "outputs": [
        {
          "name": "HDMI1",
          "mode": "1024x768"
        },
        {
          "name": "DP1",
          "mode": "off"
        }
      ]
    }
    

    The physical sizes of the displays become quite important when working with text and components from Qt Quick Controls. This is because these base size calculations on the logical DPI that is in turn based on the physical width and height. In desktop environments queries for these sizes usually work just fine, so no further actions are needed. On embedded however, it has often been necessary to provide the sizes in millimeters via the environment variables QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT. This is not suitable in a multi-display environment, and therefore Qt 5.8 introduces an alternative: the physicalWidth and physicalHeight properties (values are in millimeters) in the JSON configuration file. As witnessed in the second screenshot above, the physical sizes did not get reported correctly in our demo setup. This can be corrected, as it was done for the monitor in the first screenshot, by doing something like:

    {
      "device": "drm-nvdc",
      "outputs": [
        {
          "name": "HDMI1",
          "physicalWidth": 531,
          "physicalHeight": 298
        },
        ...
      ]
    }
    

    As always, enabling logging can be a tremendous help for troubleshooting. There are a number of logging categories for eglfs, its backends and input, so the easiest is often to enable everything under qt.qpa by doing export QT_LOGGING_RULES=qt.qpa.*=true before starting a Qt application.

    What About Wayland?

    What about systems using multiple GUI processes and compositing them via a Qt-based Wayland compositor? Given that the compositor application still needs a platform plugin to run with, and that is typically eglfs, everything described above applies to most Wayland-based systems as well.

    Once the displays are configured correctly, the compositor can create multiple QQuickWindow instances (QML scenes) targeting each of the connected screens. These can then be assigned to the corresponding WaylandOutput items. Check the multi output example for a simple compositor with multiple outputs.

    The rest, meaning how the client applications’ windows are placed, perhaps using the scenes on the different displays as one big virtual scene, moving client “windows” between screens, etc., are all in QtWayland’s domain.

    What’s Missing and Future Plans

    The QML side of screen management could benefit from some minor improvements: unlike C++, where QScreen, QWindow and QWindow::setScreen() are first class citizens, Qt Quick has currently no simple way to associate a Window with a QScreen, mainly because QScreen instances are only partially exposed to the QML world. While this is not fatal and can be worked around with some C++ code, as usual, the story here will have to be enhanced a bit.

    Another missing feature is the ability to connect and disconnect screens at runtime. Currently such hotplugging is not supported by any of the backends. It is worth noting that with embedded systems the urgency is probably a lot lower than with ordinary desktop PCs or laptops, since the need to change screens in such a manner is less common. Nevertheless this is something that is on the roadmap for future releases.

    That’s it for now. As we know, more screens are better than one, so why not just let Qt power them all?

    The post Qt Graphics with Multiple Displays on Embedded Linux appeared first on Qt Blog.

    Hi all,

    Thanks to collaboration of Victorhck and Eloy Cuadra, now we also have the KDE 20 years Timeline available in Spanish.

    If you would also like to help us increase the reach of our timeline, translating it to another language, you can simply clone our repository here. For security reasons, the written permission in the KDE websites is restricted, but you can clone the repository, enter your translation in the local xml file and then send us the translated file.

    If you also have any suggestions or adjustment, let us know.🙂


    September 18, 2016

    In the last days we moved our content from labplot.sourceforge.net to labplot.kde.org. When visiting the old page you’ll be automatically redirected to the new one. This is the last step in our transition from SourceForge to KDE’s infrastructure. The new homepage got a more modern look and a responsive web-design. In the next months we’ll work on adding more content to the homepage (screenshots, documentation, examples and HOWTOs).

    Though the re-design of the homepage took quite a lot of time, we didn’t forget the actual development – the work in the code on the next release is in progress. In the next release we’ll incorporate the work done during GSoC2016 – support for the FITS-format and a theme manager will be added to the feature list of LabPlot. In addition to this, several data reduction algorithms, integration and differentiation of data will join the family of already available analysis functions in LabPlot. On the plotting part, breaking of axes is currently being worked on and we plan to release it soon, too.

    In recent days Andreas, Gnastyle and me worked a lot to improve Breeze mimetype icons.

    The changes could be categorized as shapes and colors. Andreas and Gnastyle worked on shapes and I polished them and added new colors. Here you can see a preview of the icons I propose. The colors are mainly from Breeze palette from Ken and hacked a bit. The idea is to recognize icons also by colors.

    new colors for mimetypes

    The points we (Andreas, Gnastyle and me) disagree are shape for executable files and icons for Office Open XML (MS Office 2007+ default formats):

    Mimetype options

    I think that the most important thing is to make clear what is a file and what an application or anything else. That’s why my executable icons still look like files. Gnastyle thinks it’s more important to easily recognize the executable files in a folder with a lot of source files. I think my executable icon is enough recognizable and that you can always sort files by type in Dolphin and show them in groups, so it’s easy to find executables when needed.

    About OOXML icons, I think we shouldn’t use Microsoft Office logos because:
    1. we could have license issues update: they are copyrighted so we are not able to include them in Breeze
    2. OOXML formats are not MS Office specific, IIRC Europen Union commissioned Microsoft to define them and they are currently used by other office suites like Libreoffice, the one we mostly use on GNU/Linux

    Since these are big changes on icons KDE uses, I want to know thoughts from the community specially from people involved in products that use them, like Plasma team. I need to know:
    1. if you like the direction for colors
    2. about the executable files
    3. about OOXML icons

    It would be appreciated if everyone interested will subscribe visual-design mailing list and reply to the thread I’m going to start there.

    Thanks.

    September 17, 2016

    Hello everyone,

    Now Dock Panel and Plasmoid v0.3 is here!!!


    Now Dock Window Previews





    Now Dock 0.3 - youtube video

    I want to thank everyone who helped me with this release and all the community around this effort that sent patches, made a huge debugging effort to improve the experience and in the end encouraged all the project's contributors!!

    Now Dock Plasmoid New Features:
    • support different launchers per activity
    • window previews
    • highlight windows
    • anchor your plasmoid wherever you want in order to provide proper zoom animation
    • visual indicator for tasks progress (e.g. copying files)
    • change infrastructure for icons in order to solve many issues with old implementation and provide no blurred icons always
    • configure animation duration
    • work smoothly with Now Dock Panel (v0.3)
    • support Plasma 5.8

    task progress (copying a file)

    Now Dock Panel hovering widgets


    Now Dock Panel Features:
    • Now Dock Panel Configuration Window
    • add plasmoids and animate them
    • lock plasmoids in order not to animate
    • automatic categorizing of plasmoids that probably would break the hovering animation
    •  automatic mode to grow or shrink the icons based on the length or height of the panel
    • anchor the panels content in every way you want, center, left, right, top, bottom
    • beautiful visuals for dragging and drag n' drop plasmoids
    • support plasma's panel theme and set its background size


    opening app launcher

    Now Dock Panel Configuration

    Links
    [Now Dock Plasmoid v0.3 - store.kde.org]
    [Now Dock Panel v0.3 - store.kde.org]


    I hope you find them useful!!

    regards, 
    michail

    We are going to close the date selection Doodle for the Randa Meetings 2017 on Wednesday next week. So hurry up and add yourself if you plan to come to Randa next year.

    Flattr this!

    During Akademy, I saw that a lot of people had a very modern looking Mail program, which I didn’t know, and I was surprise to hear it was KMail.

    I used KMail at work (during the whole year, yes this year), on a KDE4 station, and honestly, I didn’t like the experience. At all. So I kept using Thunderbird, which I’m used to etc. However, I grew bored of the interface, there is not much innovation, and most modules are just not maintained any more.

    So seeing this nice UI I told my self “eh, let’s give a try again”. So I pacman-S-ed kmail2, which was overall 3 Mo only (I use Plasma and Korganizer, so I guess I already had all the dependencies people are complaining about).

    Configuration

    Setting up KMail’s account (I have 4) was quite obvious, like Thunderbird and most other Mail managers.

    I had a lot of issues finding out how to define my Sent and Draft folders. The Trash was where I expected (in the account management) but the 3 others in the Identity management. Why? What is different between theses 3 folders?

    This leads me to another question… Why identities and accounts are separated? Are there use-cases where you have one identity for 2 accounts? I have 4 identities, and 4 corresponding email accounts. So to me it’s just more thinking to have when I want to change configuration. Is my answer model based on my identity or my account? And the SMTP parameters?

    If it were me, I would put the identity section as the first tab of the Accounts settings. But that’s only me.

    Else, by going through the menus, everything gets done quite fast.

    Overall user experience

    Out of this, I really like the fact that it’s starts very fast and that it’s very responsive. Also since I use my Nextcloud instance for all my PIM-related stuff (contacts, calendars, …), everything is integrated thanks to Akonadi. Really, don’t kill it, it’s so great to set things up once for all programs.

    I also followed the advice I was given (by Cola I think) to use the 3-columns disposition. The experience is just amazingly better (you can do that with Thunderbird as well, but it looks too clustered on my tiny screen).

    Screenshot_20160917_104234

    My only problems so far are

    • Bug 362575, which prevent unsubscribing IMAP folders, so I get several useless folders like “Contacts”, “Notes”, “Journal,” etc. (it’s a Microsoft Exchange account).
    • Crashes when I try to affect a new tag to an email (I get a segfault).
    • And finally I expected that selecting 3 emails and click “Reply” would create an email to all recipients. I would really like to have such a feature, but hey, after 2 days, I think it’s working quite good.

    I’m also quite confused about “Local subscription”, “Server-side subscription”. What is a model (reply model from the config menu, model you save, or reply with personalized model)? Still don’t know :S.
    Maybe you should ping the VDG/Usability guys and see what to change in the organization and names?

    TL;DR

    Finally my experience with KMail is a good experience, and I think I won’t need to go back to Thunderbird. Guys, you did great job since KDE4 on this project. There is still some bugs and UX issues, but IMHO you are on the right tracks. Keep up the good work!

    September 16, 2016

    Many Plasma users asked for a consistent Telegram icon in the systray, that by default is blue, while Plasma uses monochrome icons in the systray by default. This is how it looks like with Breeze style:

    telegram monochrome icon

    telegram monochrome icon dark

    telegram monochrome icon

    How to apply it

    Download this zip, extract it, and copy the contents of Breeze or BreezeDark folders into
    .TelegramDesktop/tdata/ticons/
    (that is hidden in your Home) and replace the icons Telegram cached there.

    Menu to switch between light/dark

    These icons are “static”, they doesn’t follow the theme automatically like Plasma’s icons do. So if you often switch between Breeze and Breeze Dark you may like a menu like this on the Telegram icon:

    telegram monochrome icon

    To add it:

    1. Copy both Breeze and BreezeDark into “.TelegramDesktop/tdata/` (not in “ticons”)

    2. go into .local/share/application, where the launchers of your apps should be and edit the Telegram one with Kate or another text editor. If you don’t have a Telegram launcher but it’s listed in your app menu, check usr/share/applications and copy it from there into ./local/share/application (don’t try to edit it with root permissions, if your distro shipped it, it will be replaced with the next distro upgrade). If you have no Telegram launcher create one with Kmenuedit. Add to the Telegram .desktop launcher the following text:

    Actions=breeze;breeze-dark;default;
    
    [Desktop Action breeze]
    Exec=sh `rm -rf ~/.TelegramDesktop/tdata/ticons; ln -s Breeze ~/.TelegramDesktop/tdata/ticons`
    Icon=lighttable
    Name[it_IT]=Usa icona Breeze nella systray
    Name=Use Breeze icon in systray
    
    [Desktop Action breeze-dark]
    Exec=sh `rm -rf ~/.TelegramDesktop/tdata/ticons; ln -s Breeze\ Dark ~/.TelegramDesktop/tdata/ticons`
    Icon=lighttable
    Name[it_IT]=Usa icona Breeze Dark nella systray
    Name=Use Breeze Dark icon in systray
    
    [Desktop Action default]
    Exec=rm -rf ~/.TelegramDesktop/tdata/ticons
    Icon=edit-clear
    Name[it_IT]=Usa icona predefinita nella systray
    Name=Use default icon in systray
    

    It simply creates links to Breeze or Breeze Dark (or delete it to restore the default icon). Now you can use the menu to switch theme (restart Telegram to see the changes).

    In the zip there is also the svg source if you want to use other colors.

    I hope you like it. Ciao!

    One of the tools I use a lot to work with git repositories is Tig. This handy ncurses tool let you browse your history, cherry-pick commits, do partial commits and a few other things. But one thing I wanted to do was to be able to start an interactive rebase from within Tig. This week I decided to dig into the documentation a bit to see if it was possible to do so.

    Reading the manual I found out Tig is extensible: one can bind shortcut keys to trigger commands. The bound commands can use of several state variables such as the current commit or the current branch. This makes it possible to use Tig as a commit selector for custom commands. Armed with this knowledge, I added these lines to $HOME/.tigrc:

    bind main R !git rebase -i %(commit)^
    bind diff R !git rebase -i %(commit)^
    

    That worked! If you add these two lines to your .tigrc file, you can start Tig, scroll to the commit you want and press Shift+R to start the rebase from it. No more copying the commit id and going back to the command line!

    Note: Shift+R is already bound to the refresh action in Tig, but this action can also be triggered with F5, so it's not really a problem.

    A month ago I subscribe to a course from a Brazilian friend, Henrique Bastos, an awesome guy that knows a lot about Python and Entrepreneurship.
    My goal with this course is to learn others programming languages, and in this case, Django is the Python framework for the Web, and I think that would be a good skill to have.
    I don’t know anything about Python, the only skill that I have is with C++ and Qt, and isn’t an advanced skill. And here in Brazil, a lot of my friends knows Python, and always happen a discussion about wich programming is better and why. But for me build arguments like that I need to learn the language. To see its weakness and strengths.

    I’m finishing the second module of the course. And in the last lessons, Henrique focus on the test. Everything that we need to implement to handle requests and a subscription form of our app, need to have a test first. Is the TAFT method: Test all the fucking time!

    In a first moment I got pissed, why not go directly to implementation? But with the development of the app and the tests that I was writing, I started to see the importance of the tests. Funny is, that in college I’m doing a class called Software Engineer II, the current topic is about tests, and how the concept of the software tests is defined and wich kind of tests we need to do in a software.

    This is an example of a class inside my test.py, to check if a Post on the subscription form is valid or not:

    
    class SubscribeInvalidPost(TestCase):
    def setUp(self):
    self.resp = self.client.post('/inscricao/', {})
    
    def test_post(self):
    """Invalid POST should not redirect"""
    self.assertEqual(200, self.resp.status_code)
    
    def test_template(self):
    self.assertTemplateUsed(self.resp, 'subscriptions/subscription_form.html')
    
    def test_has_form(self):
    form = self.resp.context['form']
    self.assertIsInstance(form, SubscriptionForm)
    
    def test_form_has_errors(self):
    form = self.resp.context['form']
    self.assertTrue(form.errors)
    

    I’m having some difficulties on the Python syntax. Since in all my short life like a programmer was using C/C++ or even Pascal(in the very beginning), I’m used to using the syntax of them. I got kind of upset after an if() that I forgot to add the ‘:’ in the end. >.<

    However, so far, I like it a lot of this course, Henrique usually says that “Python comes with batteries”, that mean, Python has all the support on the API that you need, without the need to worry about what is happening below or to implement a new class to handle some specifications. And I’m learning that.

    Django has an API called Forms, it’s a library only to handle formulary data. You can clean the data and have a dictionary returned with the cleaned data, you can validate all the data from the forms: If the data is an email, the Django already checks if is a valid email. Click here for the doc.

    We are using Heroku, like the platform of deploy. And damn, it’s a hell of a tool. I hope in the future create more projects and update them to Heroku. You can work on everything on your localhost, and they configure Heroku, after that you can push to a branch inside Heroku platform, and it will install everything that you need for your project to run, build and put on the air. Easy like plug and play =D

    A good thing to make clear is that Django is an API for backend in Python. To front-end, you can use everything that you like it. =D

    Until the end of the course, I will finish a website with all database behind to handle subscriptions and manage of a hypothetical event.

    I will continue to post about it, see you in the next post!

    That’s all folks! =D

     

     



    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.