The Akademy programme (saturday, sunday) is actually pretty long; the conference days stretch into feels-like-evening to me. Of course, the Dutch are infamous for being “6pm at the dinner table, and eat potatoes” so my notion of evening may not match what works on the Mediterranean coast. Actually, I know it doesn’t since way back when at a Ubuntu Developer Summit in Sevilla it took some internal-clock-resetting to adjust to dinner closer to midnight than 18:00.
- Attend a bunch of talks. Telemetry / User Feedback sounds like a must-see for me, and lightning talks, and Input Methods is something I know nothing about and should (hey, my work-work application is Latin-1 only and therefore can’t even represent the names of all of its developers properly, and that in 2017), and the analysing code and fuzzing talk connects way back to the English Breakfast Network days of KDE Code Quality.
- Hammer (and saw, and sand, and paint) on the KDE CI for FreeBSD; this will involve a fair amount of futzing with the base system, but also gently pushing changes to a whole bunch of repositories. KDE Frameworks 5 are mostly blue / yellow. It’s time to start adding higher layers of the software stack to the whole.
- BoF it up around CMake, FreeBSD, CI, and LDAP.
- Have fun at the day trip.
Hi, I'm Davide and I'm 22.
I was born on May 17th so I'm considering being accepted by KDE as a little gift.
The first month is usually related to "Community Bonding". What this means?
First of all, I've created this blog. Here I'll post updates about Chat Bridge (now renamed to Brooklyn) and myself.
Then, I've retrieved my KDE Identity account. The main problem was that I've lost my username.
So I've written to firstname.lastname@example.org and five minutes after the username was no longer a problem.
Shortly after I've done lots of stuff, but I don't want to bother my readers.
After this boring to-do list, I've contacted my mentor to keep him updated.
We decided to start the development of the application and we defined how the app configuration file must be.
You can use it for your projects (it is obviously open-source), what are you waiting for?
For now it works only on IRC/Telegram but it will support Rocketchat and it is modular.
It can also only support plain text, but it's temporary, don't worry.
I'm planning (but I've not decided yet because of university exams) to go to Akademy 2017 with some guys at WikiToLearn.
I can't wait to start coding!
What do you think about this project?
Do you have plans to use it?
Don't be shy, write me everything you want!
- Brooklyn repo: https://cgit.kde.org/scratch/davider/brooklyn.git/
The annual openSUSE Conference 2017 is upcoming! Next weekend it will be again in the Z-Bau in Nuremberg, Germany.
The conference program is impressive and if you can make it, you should consider stopping by.
SMB is a long running concern of the heart of the two of us: Both Stefan, who even does it for living, and me have both used openSUSE in the area of SMB for long and we know how well it serves there. Stefan has even initiated the Invis Server Project, which is completely free software and builds on top of the openSUSE distributions. The Invis Server adds a whole bunch of extra functionality to openSUSE that is extremely useful in the special SMB usecase. It came a long way starting as Stefans own project long years ago, evolving as proper maintained openSUSE Spin in OBS with a small, but active community.
The interesting question is how openSUSE, Invis Server and other smaller projects like for example Kraft can unite and offer a reliable maintained and comprehensive solution for this huge group of potential users, that is now locked in to proprietary technologies mainly while FOSS can really make a difference here.
In the workshop we first will introduce the existing projects briefly, maybe discuss some technical questions like integration of new packages in the openSUSE distributions and such, and also touch organizational question like how we want to setup and market openSUSE SMB.
Participants in the workshop should not expect too much presentation. We rather hope for a lively discussion with many people bringing in their projects that might fit, their experiences and ideas. Don’t be shy
In KDE we cover a mix of platforms and form factors that make our technology very powerful. But how to reach so many different systems while maintaining high quality on all of them?What variables are we talking about? Form factors
We use different form factors nowadays, daily. When moving, we need to be straight-forward; when focusing we want all functionality.
Together with QtQuick Controls, Kirigami offers ways for us to be flexible both in input types and screen sizes.Platforms
We are not constantly on the same device, diversity is part of our lives. Recommending our peers the tools we make should always be a possibility, without forcing them into major workflow changes (like changing OS, yes).
Qt has been our tool of choice for years and it’s proven to keep up with the latest industry changes, embracing mobile, and adapting to massively different form factors and operating systems. This integration includes some integration in their look and feel, which is very important to many of us.Devices & Quality Assurance
We are targeting different devices, we need to allow developers to test and make it easy to reproduce and make the most out of the testing we get, learn from our users.
Whatever is native to the platform. APK (and possibly even Google Play) on Android, Installers on Windows and distribution packages for GNU/Linux.
Furthermore, we’ve been embracing new technologies on GNU/Linux systems that can help a lot in this front including Snap/Flatpak/AppImage, which could help streamline this process as well.
Some of these technologies are slowly blooming as they get widely adopted, and our community needs as well to lead in offering tooling and solutions to make all of this viable.
- We need straightforward quality assurance. We should ensure the conditions under which we develop and test are our users’ platforms. When facing an error, being able to reproduce and test is fundamental.
- We should allow for swift release cycles. Users should always be on fresh stable releases. When a patch release is submitted, we should test it and then have it available to the users. Nowadays, some users are not benefiting from most stable releases and that’s makes lots of our work in vain.
- Feedback makes us grow. We need to understand how our applications are being used, if we want to solve the actual problems users are having.
All of this won’t happen automatically. We need people who wants to get their hands dirty and help build the infrastructure to make it happen.
There’s different skills that you can put in practice here: ranging from DevOps, helping to offer fresh quality recipes for your platform of choice, improving testing infrastructure, or actual system development on our development tools and of course any of the upstream projects we use.
Hop on! Help KDE put Free Software on every device!
Hi everyone, is everything ok? I hope so.
Today, I will talk about my week working on Krita during this community bonding period that ends next Sunday.
You probably are asking, why I put a Garfield comic here. First, I love cats and Garfield :). Second, I figure out that represents what open source community needs, more consistency and constant work. Boud told me sometimes that we need to commit and be in touch with the community every day. It's a problem, send a huge modification or do not enter in IRC for a long time. I'm trying to be more constant because is not all about code.
This week was pretty cool why I could know more the community, talking with users and devs to define the initial set for the Krita's showcase.
Monday - I opened a discussion in the Krita’s forum to obtain new suggestions for the Krita’s showcase.
Tuesday - I was trying to understand some current features of the Krita that users told me like Image Reference and Palette.
Wednesday - I organized and wrote all suggestion of users from the forum and from the IRC on the phabricator task.
Thursday - I asked more experienced devs for help with suggestions in the task thread, as you can see here.
Friday - A day to solve some personal problems.
Saturday - I wrote an answear with my guideline for the GSoC period.
That’s it for now. Thanks, Krita community. Until next week, See ya!!
Today I streamed the first half of the Plasma 5.11 wallpaper production, and it was an interesting experience. The video above is the abridged version sped up ~20x, heavily edited to the actual creation, and should be a fun watch for the interested.
It looks like there’s another full work-day that needs to go into the wallpaper still, and while I think I’ll also record the second half I don’t think I’ll livestream it; while I’m very appreciative of the viewers I had, it was quite a bit of extra work and quite difficult to carry on a one-man conversation for 8 hours, while working, for at most a few people. Like I said, I will still record the second half of the wallpaper for posterity, I simply don’t think I’ll be streaming it. I do think I’ll keep streaming the odd icon batch, as those are about as long as I want, so they can be kept to a digestible hour.
The wallpaper as it is is based on an image of a reef along with a recent trip to the beach during the Blue Systems sprint. There’s still a long way to go, and I can easily see another 8 hours going into this before it’s completed; there’s water effects, tides, doing the rocks, and taking a second pass at the foam – among other things – especially before I hit the level of KDE polish I’d like meet.
Looking at it, I may also make a reversed image with only the shoreline components for dual-screen aficionados.
Within the next week or so I’ll post the next timelapse after I complete the wallpaper.
Two days after the Global Accessibility Awareness Day we go live with the registration for the Randa Meetings 2017. Thus we would like to bring as many people to Randa this September to make more of our and other Free Software more accessible.
Another topic during this year’s Randa Meetings will be KDE PIM but it’s for sure not forbidden to work on accessibility feature of our PIM stuff as well.
So please come and make KDE more accessible. CU there.
What we changed since the alpha release:
- Bugfix: The download of Simon Base Models work again flawlessly (bug: 377968)
- Fix detection of utterid APIs in Pocketsphinx
You can get it here:
In the work is also an AppImage version of Simon for easy testing. We hope to deliver one for the Beta release coming soon.
Known issues with Simon 0.4.90 are:
- Some Scenarios available for download don't work anymore (BUG: 375819)
- Simon can't add Arabic or Hebrew words (BUG: 356452)
We hope to fix these bugs and look forward to your feedback and bug reports and maybe to see you at the next Simon IRC meeting: Tuesday, 23rd of May, at 10pm (UTC+2) in #kde-accessibility on freenode.net.
Simon is an open source speech recognition program that can replace your mouse and keyboard. The system is designed to be as flexible as possible and will work with any language or dialect. For more information take a look at the Simon homepage.
Not only, but to a large extent I worked in the last few months on foundational improvements to KWin’s DRM backend, which is a central building block of KWin’s Wayland session. The idea in the beginninng was to directly expand upon my past Atomic Mode Setting (AMS) work from last year. We’re talking about direct scanout of graphic buffers for fullscreen applications and later layered compositing. Indeed this was my Season of KDE project with Martin Flöser as my mentor, but in the end relative to the initial goal it was unsuccessful.
The reason for the missed goal wasn’t a lack of work or enthusiasm from my side, but the realization that I need to go back and first rework the foundations, which were in some kind of disarray, mostly because of mistakes I did when I first worked on AMS last year, partly because of changes Daniel Stone made to his work-in-progress patches for AMS support in Weston, which I used as an example throughout my work on AMS in KWin, and also because of some small flaws introduced to our DRM backend before I started working on it.
The result of this rework are three seperate patches depending on each other and all of them got merged last week. They will be part of the 5.10 release. The reason for doing three patches instead of only one, was to ease the review process.
The first patch dealt with the query of important kernel display objects, which represent real hardware, the CRTCs and Connectors. KWin didn’t remember these objects in the past, although they are static while the system is running. This meant for example that KWin requeried all of them on a hot plugging event and had no prolonged knowledge about their state after a display was disconnected again. The last point made it in particular difficult to do a proper cleanup of the associated memory after a disconnect. So changing this in a way that the kernel objects are only queried once in the beginning made sense. Also from my past work I already had created a generic class for kernel object with the necessary subclasses, which could be used in this context. But still to me this patch was the most “controversial” one of the three, which means it was the one I was most worried about being somehow “wrong”, not just in details, but in general, especially since it didn’t solve any observable specific misbehaviour, which it could be benchmarked against. Of course I did my research, but there is always the anxiety of overlooking something crucial. Too bad the other patches depended on it. But the patch was accepted and to my relief everything seems to work well on the current master and the beta branch for the upcoming release as well.
The second patch restructured the DrmBuffer class. We support KWin builds with or without Generic Buffer Manager (GBM). It made therefore sense to split off the GBM dependent part of DrmBuffer into a seperate file, which gets only included when GBM is available. Martin had this idea and, although the patch is still quite large because of all the moved around code and renamed classes, the change was straight forward. I still managed to introduce a build breaking regression, which was quickly discovered and easily to solve. This patch was also meant as a preperation for the future direct scanout of buffers, which will then be done by a new subclass of DrmBuffer, also depending on GBM.
The last patch finally directly tackled all the issues I experienced when trying to use the before that rather underwhelming code path for AMS. Yes, you saw the picture on the screen, the buffer flipping worked, but basic functionality like hot plugging or display suspending were not working at all or led to unpredictable behaviour. Basically a complete rewrite later with many, many manual in and out pluggings of external monitors to test the bahaviour the problems have been solved to the point I consider the AMS code path now to be ready for daily use. For Plasma 5.11 I therefore plan to make it the new default. That means that it will be available on Intel graphics automatically from Linux kernel 4.12 onwards, when on the kernel side the Intel driver also defaults to it. If you want to test my code on Plasma 5.10 you need to set the environment variable KWIN_DRM_AMS and on kernels older than 4.12 you need to add the boot parameter i915.nuclear_pageflip. If you use Nvidia with the open source Nouveau driver, AMS should be available to you since kernel 4.10. In this case you should only need to set the environment variable above on 5.10, if you want to test it. Since I only tested AMS with Intel graphics until now, some reports back how it works with Nouveau would be great.
That’s it for now. But of course there is more to come. I haven’t given up on the direct scanout and at some point in the future I want to finish it. I already had a working prototype and mainly waited for my three patches to land. But for now I’ll postpone further work on direct scanout and layered compositing. Instead the last weeks I worked on something special for our Wayland session in 5.11. I call it Night Color, and with this name you can probably guess what it will be. And did I mention, that I was accepted as a Google Summer of Code student for the X.org foundation with my project to implement multi buffered present support in XWayland? Nah, I didn’t. Sorry for rhetorical asking in this smug way, but I’m just very happy and also a bit proud of having learned so much in basically only one year to the point of now being able to start work on an X.org project directly. I’ll write about it in another blog post in the near future.
It's been almost a year since I, Filipe and Aracele were having a beer at Alexander Platz after the very last day of QtCon Berlin, when Aracele astutely came up with a very crazy idea of organizing QtCon in Brazil. Since then, we have been maturing such an idea and after a lot of work we are very glad to announce: QtCon Brasil 2017 happens from 18th to 20th August in São Paulo.
QtCon Brazil 2017 is the first Qt community conference in Brazil and Latin America. Its goals are twofold: i) provide a common venue for existing Brazilian and Latin-American Qt developers, engineers, and managers share their experiences on creating Qt-powered technologies and ii) disseminate Qt adoption in Latin America, with the purpose of expanding its contributors base, encouraging business opportunities, and narrowing relationships between sectors like industry, universities, and government.
In this first edition of QtCon Brazil, the conference will focus on cross-platform development enabled by Qt. With that, the meeting can benefit a wider range of stakeholders, with interest in all sort of platforms, including desktop (Windows, Linux, and OS X), mobile (Android and iOS), embedded, and IoT. We are bringing together experienced Qt specialists from Brazil and overseas to delivery a state-of-art program of talks and training sessions that illustrate how Qt has been used as enabling technology for many sectors in industry.
QtCon Brazil 2017 will take place in São Paulo – the most important technical, social, and cultural hub in Brazil and the world’s tenth largest GDP. São Paulo is easily reachable from most of Brazilian airports, provides satisfactory infrastructure regarding the venue and accommodation, and is a strategic place to augment the achievements of this first edition of QtCon Brazil. The venue where the meeting will happen is Espaço Fit, a multifunctional conference center with an auditorium for 220 people and that provides all required infrastructure regarding multimedia equipments, Wi-Fi, and catering services. Espaço Fit is located in São Paulo downtown – at Avenida Paulista – it is easily reachable from airports, in a walking distance from metro stations, and nearby a large array of hotels.
QtCon Brasil 2017 is kindly sponsored by The Qt Company, Toradex, openSUSE and KDE. It has also the valuable support for logistics and outreach of Carreira RH and Embarcados. Thank you all for making QtCon Brasil possible.
ICC Examin allows since version 1.0 ICC Color Profile viewing on the Android mobile platform. ICC Examin shows ICC color profile elements graphically. This way it is much easier to understand the content. Color primaries, white point, curves, tables and color lists are displayed both numerically and as graphics. Matrices, international texts, Metadata are much easier to read.
* most profile elements from ICC specification version 2 and version 4
* additionally some widely used non standard tag are understood
ICC color profiles are used in photography, print and various operating systems for improving the visual appearance. A ICC profile describes the color response of a color device. Read more about ISO 15076-1:2010 Standard / Specification ICC.1:2010-12 (Profile version 188.8.131.52), color profiles and ICC color management under www.color.org .
The ICC Examin App is completely rewritten in Qt/QML. QML is a declarative language, making it easy to define GUI elements and write layouts with fewer code. In recent years the Qt project extended support from desktop platforms to mobiles like Nokias Meego, Sailfish OS, iOS, Android, embedded devices and more. ICC Examin is available as a paid app in the Google Play Store. Sources are currently closed in order to financially support further development. This ICC Examin version continues to use Oyranos CMS. New is the dependency to RefIccMAX for parsing ICC Profile binaries. In the process both the RefIccMAX library and the Oyranos Color Management System obtained changes and fixes in git for cross compilation with Android libraries. Those changes will be in the next respective releases.
The FLTK Toolkit, as used in previous versions, was not ported to the Android or other mobile platforms. Thus a complete rewrite was unavoidable. The old FLTK based version is still maintained by the same author.
This July KDE's user and developer community is once again going to come together at Akademy, our largest annual gathering.
I'm going there this year as well, and you'll even be able to catch me on stage giving a talk on Input Methods in Plasma 5. Here's the talk abstract to hopefully whet your appetite:
An overview over the How and Why of Input Methods support (including examples of international writing systems, emoji and word completion) in Plasma on both X11 and Wayland, its current status and challenges, and the work ahead of us.
Text input is the foundational means of human-computer interaction: We configure or systems, program them, and express ourselves through them by writing. Input Methods help us along by converting hardware events into text - complex conversion being a requirement for many international writing systems, new writing systems such as emoji, and at the heart of assistive text technologies such as word completion and spell-checking.
This talk will illustrate the application areas for Input Methods by example, presenting short introductions to several international writing systems as well as emoji input. It will explain why solid Input Methods support is vital to KDE's goal of inclusivity and how Input Methods can make the act of writing easier for all of us.
It will consolidate input from the Input Methods development and user community to provide a detailed overview over the current Input Methods technical architecture and user experience in Plasma, as well as free systems in general. It will dive into existing pain points and present both ongoing work and plans to address them.
This will actually be the first time I'm giving a presentation at Akademy! It's a topic close to my heart, and I hope I can do a decent job conveying a snaphot of all the great and important work people are doing in this area to your eyes and ears.
See you there!
The current world of high DPI works fine when dealing with a single montior and only dealing with modern apps.
but it breaks down with multiple monitors.
What we need to render:
As well as windows being spread across outputs, we also want the following features to work:
- Legacy applications to still be readable and usable
- Mouse speed to be consistent
- Screenshots to be consistent across screens
- All toolkits behaving the same through a common protocol
Handling scaling is part of the core wayland protocol and, with some changes in kwin, solves all of these problems.The system
The system is a bit counter-intuitive, yet at the same time very simple; instead of clients having bigger windows and adjusting all the
input and positioning, we pretend everything is normal DPI and kwin just renders the entire screen at twice the size.
Clients, then provide textures (pictures of their window contents) that are twice the resolution of their window size.
This covers all possible cases:
- we render a 1x window on a 2x screen:
Because kwin scales up all the rendering, the window is shown twice the size, and therefore readable, albeit at standard resolution.
- we render a 2x window on a 1x screen:
The window texture will be downsampled to be the right size.
- we render a 2x window on a 2x screen:
Kwin scales up all the output, so we draw the window at twice the size. However, because the texture is twice as detailed this cancels out
and we end up showing it at the native drawn resolution giving us the high DPI detail.
The changes in KWin are not about adding explicit resizing or input redirection anywhere; but instead about decoupling the assumption between the size of a window or monitor, and its actual resolution.What changes for app developers?
All the kwin code changes landed in time for Plasma 5.10, but dynamically changing the screen scale exposed some problems elsewhere in the stack. Thefore the main UI has been disabled till hopefully Plasma 5.11. This also allows us to expand our testing with users that want to manually edit their kscreen config and opt-in.What about fractional scaling?
Despite Qt having quite good fractional scaling support, the wayland protocol limits itself to integers. This is in the very core protocol and somewhat hard to avoid. However, there's technically nothing stopping kwin from scaling to a different size than it tells the client to scale at...So it's something we can revisit later.
On June 23rd 2017, there’s a new, one day training in our Berlin facility, this time in German.
Training in FOSS Compliance will be available, in English, in Berlin and other locations later this year. More on that below, in English. Meanwhile, since our first open-enrolment training to help you with the complex issues around compliance is in German…….
Der Begriff Corporate Compliance ist seit einigen Jahren in den Fokus der Öffentlichkeit gerückt, aber wenige Unternehmen wissen bislang um die …
I am pleased to confirm that Qt 5.9 LTS officially supports the INTEGRITY RTOS. INTEGRITY was supported with Qt 4.8 and will again be supported from Qt 5.9 onwards. The interest in running Qt on INTEGRITY has been coming primarily from Automotive for use in safety certified Instrument Clusters, but it is also available for other industries.
One might ask why is it important to support INTEGRITY for Qt? Why is the leading cross-platform application and UI framework needed in RTOS applications? Aren’t these the ones so deeply buried into our infrastructure, that you almost never notice when you come across one? Well, yes and no. It is true that most of the RTOS applications are still done without any UI, let alone a fancy and interactive graphical user interface. But the number of those RTOS applications that require an advanced GUI framework to meet the user expectation is growing fast. Other embedded operating systems, such as embedded Linux, are not sufficient when it comes to real-time capability, reliability, security and certified operations for certain industries such as automotive, medical and industry automation.
Qt 5.9 LTS for INTEGRITY is covered by our excellent technical support for all existing Qt for INTEGRITY license holders. All the most important modules are available, for example: Qt Core, Qt Network, Qt GUI, Qt Quick, Qt Qml, Qt Quick Controls 2 and Qt 3D. Initially we are supporting NXP i.MX6 and NVIDIA Tegra X1 hardware. Other hardware, such as Intel Apollo Lake can also be used, and we intend to continue adding support for new hardware with subsequent Qt releases. The following video shows Qt 5.9 LTS based digital instrument cluster running on top of INTEGRITY RTOS with NXP i.MX6 and NVIDIA Tegra X1.
Leveraging the Qt framework with INTEGRITY RTOS enables an easy way of adding state-of-the-art graphical user interfaces to security and safety critical systems. It is easier to certify the product to comply with the requirements of for example the automotive or medical industries when the solution is built on top of an RTOS that is already certified for that industry domain. We see many industries, for example medical, automotive, industrial automation, aerospace and defense, directly benefiting from now being able to leverage Qt for INTEGRITY. The in-built capabilities of the INTEGRITY RTOS platform allow the Qt framework to run in such a way that it does not interfere with the real-time parts of the system. This simplifies creation of safety critical systems and enables certifying the Qt based system to standards for functional safety such as IEC 61508, ISO 26262 and IEC 62304.
INTEGRITY is not only a certified RTOS, but also provides a real-time hypervisor allowing guest OSes such as Linux to run on the same SoC as the safety critical RTOS. This simplifies building complex systems such as digital cockpits. The following video shows Qt Automotive Suite running on top of Linux as well as a Qt-based instrument cluster running on INTEGRITY RTOS – both on the same Intel Apollo Lake SoC leveraging INTEGRITY Multivisor hypervisor.
If you have not yet considered leveraging Qt for your next safety-critical project, I recommend taking a deeper look. Our sales, consultants and support are available to guide you through the evaluation process. If you have any questions, we are very happy to discuss more on how Qt meets the needs of your next product – please contact us.
The program has been finalized, and registration is now open, for Akademy 2017, in Almería, Spain. I had a tiny amount of input for the programme and schedule, and I’d really like to thank the Real Programme Committee for putting together a neat set of talks covering KDE technology and community for us all, and the local team in advance for all their great work.
I don’t see an official I’m-going banner yet on the under-construction wiki page with tips and tricks for this year’s conference, and I’m not going to subject anyone to my art skills either (I can’t seem to find my older Kolourpaint-based efforts for earlier Akademies, either).
[[ And since there’s always bugs: my IRC nick is [ade], which on import into the conference system got turned into the string Array. PHP never ceases to amaze. ]]
It’s getting to be that time of the release cycle where I’ll be making a new wallpaper for the next Plasma release. For the 5.11 cycle I’ll be doing things a bit differently owing to a request on Reddit several weeks back; this wallpaper is going to be done over a livestream!
The wallpaper livestream will be on Saturday the 20th, and start ~10:00am Eastern Daylight time, or 2:00pm GMT. I’m going to estimate the stream to last ~8-10 hours, with a couple short breaks somewhere in the middle.
The aim will be to get the majority of the wallpaper done during the stream (they take that long!), with anything done beyond the stream falling into tweaks and correction territory. There’s also the chance you may see a few attempts until I settle, as I have a few designs in mind and there may be some experimentation there along with some spectacular failures along the road.
I’ll keep a chat open, and I’ll field any questions I get, but beyond that I figure it will be the kind of stream people might like as background noise. I also suspect it might be the kind of thing people will want to minimize now and again – I think it will be a passive viewing experience. When the livestream is over I’ll go back and create a sped-up version which I’ll post on YouTube.
Which brings me to an important question I have for everyone who does or is into livestreams; I’ve never streamed before! I know about Twitch and YouTube, even Hangouts, and have heard about OBS; are there any recommendations for which streaming service/software I should broadcast with? Comment here (or on Reddit, I’ll be posting there) with input as to the best way to stream a fairly long art session. Also, I’m considering using a webcam as well – please let me know if that’s of interest, and if there’s software for a total rookie to do it.
Lastly, if the stream is fairly successful at least on a technical level, I’ll look into shorter episodes featuring Aether icon development which would probably see rounds of 3-4 icons being completed in the space of a shorter session.
This cycle I’ve decided to look at what art and design I can improve in Kubuntu. The first was having something we’ve never had, a wallpaper contest that’s available to ALL users. We’re encouraging all our artist users to submit art ranging from digital, photographic, and beyond! You all have till June 8 to submit your wonderful and artful work.
I’ve also taken a look at our slideshow in its current state:
After a weekend, a few extra days and some great feedback from both our Kubuntu community and the KDE VDG, I’m really pleased with the improvement. It’s based on the work the Ubuntu Budgie team have done on their slideshow so a HUGGGGEEEE shout out to them for their great work. Here is the current WIP state:
Currently the work is in my own branch, of the ubiquity-slideshow-ubuntu package on Launchpad. Once I’ve mostly finished and we’ve gotten some feedback, I’ll send a merge request to put it in the main package and brought to you for Kubuntu 17.10.
If you don’t know me already, I have been involved with WikiToLearn for the past year and half, contributing to the development of the project in its various parts. In the past few months I have been especially involved in the development of its frontend: together with a few other developers I designed and built the current web interface from scratch.
Altrought definitely better than what we had in the past, this interface is far from being the best experience we can offer to our users: many areas need improvements especially in the subject of user interaction, speed and ease of use. These are the main reasons I am building a progressive web app for WikiToLearn during this GSoC. I will be guided by my mentor Alessandro Tundo, who is currently the maintainer for the technological part of WikiToLearn.What will change for the users
If everything goes according to plan, when we switch the users from using the existing website to using my progressive web app the first thing they will notice is speed (or to better say the lack of slowness).
Thanks to advanced caching mechanism and complete control over the user interaction, we will be able to provide a quick and lightweight interface together with seamless transitions between the various pages: staring at a blank page for a few seconds every time you click on a link is all but ideal especially for a content-driven website.
Next I will build offline browsing right into the website, allowing users to browse courses and pages they already visited right from the browser: many times I found myself waiting for the Internet to come back to read the next part of a course; this hopefully won’t be a problem anymore.
Another important feature I am planning to develop is a better native interface for browsing courses: right now course indexes are simply content page with a textual index in them; Overall for the final user is very confusing to search and browse the courses, taking many clicks (and pages) to go from the main page to their desired content. I will design and implement a quicker and much clearer interface for this part of the website.
Android users will be even able to install the website on their mobile phone just like if it was a native app, not a killer feature but definitely something interesting that we can achieve since we are building a modern web app: all the cool developers are doing this, why should we miss out?
Finally with this project we also want to provide an improved experience for long lasting operations, for example downloading PDFs and uploading files. Right now when you try to download a course in PDF format, it can take many seconds (or even a minute or two if the course is really big). During this time the user is left staring at a loading bar: yes it is a pretty one, but still it is a loading bar. With this improved web app the download and the rendering of downloadable books will continue in the background allowing the user to keep browsing the website freely.“Details, please”
I will be building the web app from scratch, completely separated from our traditional backend, Mediawiki. This will allow to use the best and most recent technologies, tools and strategies for building web apps in 2017. (If you are into these things expect another blog post very soon about the technological stack and the implementation details).
Overall I am focusing on firstly building a solid base for the development, providing the needed libraries and APIs to work with the interface and with the backend. I want it to be easy for future developers to jump right into the project and have all the tools, documentation and instructions to start contributing right away, no matter their level of knowledge. This has been an issue in the past: our architecture is a bit complex and it is not always clear for new developers where to go to change things.Community Bonding
During the community bonding period I will work on setting up the repositories and building a reusable template for the project: you may think this is a quick operation but there are many tools and best practicies to follow, especially if we want to do things the right way, from the start.A sneak peek of the project template
I will also experiment a bit with automatically testing web interfaces and CI tools: more of this in the next blog post.
I am very excited to be working on this project this summer. Not only I will have the chance to see what is like working full time on an open source project but I will also have the possibility to learn tons of new concepts which are definitely going to be very useful in the future.
Thanks for reading and I hope to see you again on the next post!