22 Aug 2019

feedPlanet GNOME

Molly de Blanc: Meet the GNOMEies: Max Huang

Max Huang has been GNOME since 2010, starting with forming a GNOME users group in Taiwan. Max has a story you may understand: being a user, meeting the right person, and slowly finding yourself more and more deeply involved with a community in terms of working together and making friends.

A photo of three people, holding signs reading "GNOME Asia," "openSUSE," and "COSCUP."Max Huang, on the left

Tell us a little bit more about yourself

I have contributed to GNOME for the past nine years. I promote free software and GNU/Linux at my school in Taiwan. I am one of GNOME.Asia Committee Advisors members, working with GNOME.Asia team.

I've helped organize several GNOME.Asia summits, in Taipei, Chongqing, Tokyo, India, Indonesia, Beijing, South Korea, and Hong Kong. I've served on the GNOME travel committee for several years. In 2012, I also worked with openSUSE and KDE to have a conference with COSCUP in Taiwan.

Before I started organizing events, I went to Bangalore, India, learned how to host the GNOME booth, and started making a GNOME user video.

Before that, I started the GNOME Taiwan Users Group, which hosted a lot of workshops with GTK, as well as a party for the GNOME 3 launch.

What is your role within the GNOME community?

I organize and promote GNOME. :)

Why did you get involved in GNOME?

I met Emily Chen at 2010, she led me into GNOME community. I am a GNOME user - of course. :)

Why are you still involved with GNOME?

The answer is "friendship and smiles." To me, smiles are the greatest power to promote GNOME and FOSS. I have made many new friends in GNOME and FOSS through different events.

Why still get involved with GNOME and open source?

Everyone can be a contributor with different methods. Just spending your time - you will get smiles and friends, learn and grow.

What are you working on right now?

Promoting GNOME through open source, workshops, and speeches.

What are you excited about right now - either in GNOME or free and open source software in general:

Getting the community together more. :)

What is a major challenge you see for the future of GNOME?

We need to work on documentation and the first steps for getting users and organizers involved with GNOME. How can we brow the user and contributor bases?

What do you think GNOME should focus on next?

The GNOME Board tasks. :P I trust them, they will do their best. :)

What should we have asked you about that we didn't? (Please also
answer.)

I think the question is great. Thanks again for interviewing me.

Photo courtesy of COSCUP on Flickr. Licensed CC-BY-SA.

22 Aug 2019 2:09pm GMT

Alejandro Piñeiro: ARB_gl_spirv and ARB_spirv_extension support for i965 landed Mesa master

And something more visible thanks to that: now the Intel Mesa driver exposes OpenGL 4.6 support, the most recent version of OpenGL.

As perhaps you could recall, the i965 Intel driver became 4.6 conformant last year. You have more details about that, and what being conformant means in this Iago blog post. On that blog post Iago mentioned that it was passing with an early version of the ARB_gl_spirv support, that we were improving and interating during this time so it could be included on Mesa master. At the same time, the CTS tests were only testing the specifics of the extensions, and we wanted a more detailed testing, so we also were adding more tests on the piglit test suite, written manually for ARB_gl_spirv or translated from existing GLSL tests.

Why did it take so long?

Perhaps some would wonder why it took so much time. There were several reasons, but the main one, was related to the need to add a lot of code related to linking on NIR. On a previous blog post ( Introducing Mesa intermediate representations on Intel drivers with a practical example) I mentioned that there were several intermediate languages on Mesa.

So, for the case of the Intel driver, for GLSL, we had a chain like this:

GLSL -> AST -> Mesa IR -> NIR -> Intel backend IR

Now ARB_gl_spirv introduces the possibility to use SPIR-V instead of GLSL. Thanks to the Vulkan support on Mesa, there is a SPIR-V to NIR pass, so the chain for that case would be something like this:

SPIR-V -> NIR -> Intel backend IR

So, at first sight, this seems like it should be more simple, as there is one intermediate step less. But there is a problem. On Vulkan there is no need of a really complex shader linking. Basically gathering some info from the NIR shader. But OpenGL requires more. Even though the extension doesn't required error validation, the spec points that queries and other introspection utilities should work naturally, as long as they don't require names (names are considered debug info on SPIR-V). So for example, on Vulkan you can't ask the shader about how big an SSBO is in order to allocate the space needed for it. It is assumed that you know that. But in OpenGL you can, and as you could do that using just the SSBO binding, ARB_gl_spirv requires that you still support that.

And here resided the main issue. On Mesa most of the linking is done at the Mesa IR level, with some help when doing the AST to Mesa IR pass. So the new intermediate language chain lacked it.

The first approach was trying to convert just the needed NIR stuff back to Mesa IR and then call the Mesa IR linker, but that was working only on some limited cases. Additionally, for this extension the linker rules change significantly. As mentioned, on SPIR-V names are optional. So everything needs to work without names. In fact, the current support just ignores names, for simplicity, and to ensure that everything works without it. So we ended up writing a new linker, based on NIR, and based on ARB_gl_spirv needs.

The other main reason for the delay was the significant changes on the SPIR-V to NIR pass, and NIR in general, to support SSBO/UBO (derefs were added), and also the native support of transform feedback, as Vulkan added a new extension, that we wanted to use. Here I would like to thank Jason Ekstrand for his support and patience ensuring that all those changes were compatible with our ARB_gl_spirv work.

So how about removing Mesa IR linking?

So, now that it is done, perhaps some people would wonder if this work could be used to remove Mesa IR on the GLSL intermediate language chain. Specially taking into account that there were already some NIR based linking utilities. My opinion is that no 😉

There are several reasons. The main one is that as mentioned ARB_gl_spirv linking rules are different, specifically on the lack of names. GLSL rules are heavily based on names. During the review it was suggested that need could be abstracted somehow, and reuse code. But, that doesn't solve the issue that current Mesa IR supports the linkage of several different versions of GLSL, and more important, the validation and error checking done there, that is needed for GLSL, but not for ARB_gl_spirv (so it is not done). And that is a really big amount of work needed. In my opinion, redoing that work on NIR would not bring a significant advantage. So the current NIR linker would be just the implementation of a linker focused on the ARB_gl_spirv new rules, and would just share utility NIR based linking methods, or specific subfeatures, as far as possible (like the mentioned transform feedback support).

Final words

If you are interested on more details about the work done to implement ARB_gl_spirv/ARB_spirv_extensions support, you can check the presentation I gave on FOSDEM 2018 (slides, video) and the update I gave the same year on XDC (slides, video).

And finally I would like to thank all the people involved. First, thanks to Nicolai Hähnle for starting the work, that we used as basis.

The Igalia team that worked on it at some point were: Eduardo Lima, Alejandro Piñeiro, Antía Puentes, Neil Roberts, some help from Iago Toral and Samuel Iglesias at the beginning and finally thanks to Arcady Goldmints-Orlov, that dealt with handling the review feedback for the two ~80 patches MR (Mesa and Piglit test suite MR) that I created, when I became needed elsewhere.

And thanks a lot to the all the the reviewers, specially Timothy Arceri, Jason Ekstrand and Caio Marcelo.

Finally, big thanks to Intel for sponsoring our work on Mesa, Piglit, and CTS, and also to Igalia, for having me working on this wonderful project.

22 Aug 2019 11:54am GMT

feedPlanet KDE

Day 88

Today, I'll talk about my GSoC experience and won't focus so much on Khipu, but in the next days I'll publish a post about Khipu and what I've done.

As I said in the old posts, the begin was the most complicated part for me. I made a project thinking that I'd be able to complete, I started studying the code and the things I'd make many weeks before the start. But I couldn't understand the code and I think it's my fault. I even lost three weeks after the start stuck in this situation. It was hard for me, because I was really scared about failing and at the same time dealing with my college stuff, because in Brazil, our summer (and our summer vacation), is in December-February, in July we have a three week vacation, but GSoC lasts three months. I wasn't having a good time at college as well, but with the help of my mentors I found a way to deal with the both things and as everything went well.

After this complicated start, to not fail, my mentor suggested that I could change my project. My initial project was to create new features to Khipu and Analitza (Khipu's main library) to make it a better application and move it out from beta. Then, my new project was to refactor Khipu (using C++ and QML). I was scared because I didn't know if I'd be able to complete it, but the simplicity of QML helped me a lot, and before the first evaluation (approx. two weeks after I decided my new project) I finished the interface, or at least most of it.

During the second period, in the start, I slowed down my code activities because I was in the end of my college semester and I had to focus on my final tests. But after this, I started to work in the backend and learned about models, connections between C++ and QML, and the most important: I improved my programming skills. I needed to learn to build a real program, and not making small patches as I used to do in my open source contributions history. In the end of this period, the screen was already working and showing 2D and 3D spaces and plotting functions.

So here I am, in the end of the third and last period writing about this experience. In this period, I worked in the program buttons and options, created dialogs, improved the readability of my code, documented my functions and files, and the technical stuff that I'll explain in the next post.
This period is being nice, because I gained so much maturity, not only for coding, but to my life. I feel I'm able to fix the bugs that still are there and to deal with new situations in my professional and even in my personal life.

This post has the purpose to share my experience to the students that will participate on the next years. So I'd like to give two advices based on my experience:
1- don't freak out, ask for help. The time that you lose scared and nervous, use it to think rationally on what you can do to solve that problem.
2- make a weekly activities schedule, it maybe will sound obvious, but after I started doing it, my productivity increased a lot, because is easier to control how much time I'm working and allocate time to my other activities.
And, of course, I'd like to say to KDE, Google and my mentors: thanks for this opportunity.

22 Aug 2019 3:00am GMT

21 Aug 2019

feedPlanet KDE

LabPlot's Welcome screen and Dataset feature in the finish line

Hello Everyone! This year's GSoC is coming to its end. Therefore I think that I should let you know what's been done since my last blog post. I would also like to evaluate the progress I managed to make and the goals set up at the beginning of this project.

As I told you in my last post, my main goal, in this last period, was to clean up, properly document, refactor, optimise the code and make it easier to read, so it would be fit to be brought to the master branch and to be used by the community.

My next proposition was to search for bugs and fix them, in order to make the implemented features more or less flawless. I can happily state, that I succeeded in this.

As proposed, I implemented a unit test for the main dataset related features. This proved to be useful since it helped discover some hidden problems which were all corrected. The main features, that tests were developed for, are:
I managed to create some "real" example projects so the users can explore the possibilities provided by LabPlot. These include the already existing ones (3 by count) and I added some dataset related ones. I also proceeded with the collecting of datasets. I managed to double the previous amount. Now we have 2000 datasets categorized, which is already a considerable amount.

As I said, the main priority was to improve and correct the code and not to develop major new features. However, some minor new ideas were still implemented. The first step was to improve the downloading and naming of the datasets. I also developed some caching mechanism for the downloaded files. When downloading a file, if an earlier copy is available it needs to be checked whether or not it was created earlier than 1 day. If it was, then the file needs to be deleted in order to proceed with the downloading, otherwise the downloading isn't necessary.

Another, more observable, feature is that the users can now easily display the full name and the description of the selected dataset, so they may be able to retrieve additional information before choosing a dataset to work with. Previously the users could also see the short name of the dataset which wasn't really practical since it didn't really offer much information about the dataset itself. I also added a counter to every collection, category and subcategory so now the users can see how many datasets belong to the previously listed units of categorization. I thought it might be useful. The following demo video will present these new features in use:

Show Details functionality of ImportDatasetWidget

I also created a backup functionality for ImportDatasetWidget. When the users press the "Refresh" button the metadata files "shipped with LabPlot" are copied to the "dataset folder", and the files which were previously there are kept as a backup. This was needed because by pressing refresh any newly added dataset disappears. This can be very unpleasant if done unintentionally, I speak out of experience. So by pressing the "Restore" button the effect of the "Refresh" button can be undone, meaning that the current metadata files are deleted, the backup files are restored and the widget is updated accordingly. The following video illustrates this functionality:

Restore backup functionality of ImportDatasetWidget

As I've already presented you the improvements and new features, I think it's high time I present to you an overall image of what has been accomplished during this summer's GSoC. I will present the new features in two groups: dataset related and welcome screen related. I will provide a demo video for each of them.

I'd like to start with the welcome screen since that will be the first thing people will see when they start using LabPlot. I think that the welcome screen turned out to be quite good looking, clean and simple (in the best possible meaning). It is quite responsive and by allowing the users to resize the different sections, it is customisable to a degree. I think it provides a great deal of functionality that can be useful for the great majority of the users, and it also helps in the process of getting to know LabPlot. In the next demo video I will present every aspect of LabPlot's welcome screen:

LabPlot's welcome screen

The other main part of the project was to implement functionality to import online datasets. This could be useful for those who like working with data or in the field of statistics. These datasets can be visualized by creating different plots: curves and histograms. This way LabPlot may be used for educational purposes as well. LabPlot comes with a great number of datasets which may be expanded individually by adding own datasets. I really hope that the users will find this new functionality useful and practical. Here is a video that demonstrates adding a new dataset and creating some plots based on it:

LabPlot's Dataset Functionality

And finally here comes the evaluation/summary. I truly think that every feature presented in my proposal is implemented and working. So I think the main aim is met: LabPlot now has full support for downloading and processing online datasets and has a gorgeous welcome screen. There were difficulties along the way, but with work, and help from my mentors, everything was dealt with. As I said everything works, but some unforeseen bugs or errors might appear in the future. Some steps for the future may be to improve the overall performance of the new features and improving the overall look of the welcome screen.

Working on this project for the last 3 months has been a great experience, and I can honestly say that I improved my coding skills and way of thinking in a way I haven't even dreamt for. I also improved my ability to work alone and solve problems on my own. I'm more than grateful to my mentor, Kristóf, who always helped me and had my back if I encountered any hardship. I'd also like to express my gratitude towards Alexander Semke, my mentor's former mentor and an invaluable member of the LabPlot team, who also helped me a great deal. I am determined to further improve the features, even after GSoC ended. I would be more than happy to stay in this amazing team and help them whenever they need me. It's my goal to work, in the future, on LabPlot with them, since I really liked being part of this team. I truly think that people should contribute more to the open-source community, and the end of GSoC shouldn't mean the end of the involvement as well.

This is it, guys. Thank you for reading the post, and thank you for your interest in my project. If there's any development regarding my project or a new task (in the future) I'll let you know here. Bye :)

21 Aug 2019 3:12pm GMT

feedplanet.freedesktop.org

Bastien Nocera: low-memory-monitor: new project announcement

I'll soon be flying to Greece for GUADEC but wanted to mention one of the things I worked on the past couple of weeks: the low-memory-monitor project is off the ground, though not production-ready.

low-memory-monitor, as its name implies, monitors the amount of free physical memory on the system and will shoot off signals to interested user-space applications, usually session managers, or sandboxing helpers, when that memory runs low, making it possible for applications to shrink their memory footprints before it's too late either to recover a usable system, or avoid taking a performance hit.

It's similar to Android's lowmemorykiller daemon, Facebook's oomd, Endless' psi-monitor, amongst others

Finally a GLib helper and a Flatpak portal are planned to make it easier for applications to use, with an API similar to iOS' or Android's.

Combined with work in Fedora to use zswap and remove the use of disk-backed swap, this should make most workstation uses more responsive and enjoyable.

21 Aug 2019 10:57am GMT

feedPlanet GNOME

Bastien Nocera: low-memory-monitor: new project announcement

I'll soon be flying to Greece for GUADEC but wanted to mention one of the things I worked on the past couple of weeks: the low-memory-monitor project is off the ground, though not production-ready.

low-memory-monitor, as its name implies, monitors the amount of free physical memory on the system and will shoot off signals to interested user-space applications, usually session managers, or sandboxing helpers, when that memory runs low, making it possible for applications to shrink their memory footprints before it's too late either to recover a usable system, or avoid taking a performance hit.

It's similar to Android's lowmemorykiller daemon, Facebook's oomd, Endless' psi-monitor, amongst others

Finally a GLib helper and a Flatpak portal are planned to make it easier for applications to use, with an API similar to iOS' or Android's.

Combined with work in Fedora to use zswap and remove the use of disk-backed swap, this should make most workstation uses more responsive and enjoyable.

21 Aug 2019 10:57am GMT

feedPlanet KDE

Distributed Beta Testing Platforms

Do they exist? Especially as free software? I don't actually know, but I've never seen a free software project use something like what I've got in mind.

That would be: a website where we could add any number of test scenarios.

People who wanted to help would get an account, make a profile with their hardware and OS listed. And then a couple of weeks before we make a release, we'd release a beta, and the beta testers would login and get randomly one of the test scenarios to test and report on. We'd match the tests to OS and hardware, and for some tests, probably try to get the test executed by multiple testers.

Frequent participation would lead to badges or something playful like that, they would be able to browse tests, add comments and interact - and we, as developers, we'd get feedback. So many tests executed, so many reported failure or regressions, and we'd be able to improve before the release.

It would be a crowd-sourced alternative to something like Squish (which I've never found to be very useful, not for Krita, not at the companies where it was used), it would make beta testers not just feel useful, it would make beta testing useful. Of course, maintaining the test scripts would also take time.

It sounds simple to me, and kind of logical and useful, but given that nobody is doing this - does such a thing exist?

21 Aug 2019 10:10am GMT

18 Aug 2019

feedplanet.freedesktop.org

Roman Gilg: KDE sprints in summer heat

End of June I attended the annual Plasma sprint that was this year held in Valencia in conjunction with the Usability sprint. And in July we organised on short notice a KWin sprint in Nuremberg directly following up on the KDE Connect sprint. Let me talk you through some of the highlights and what I concentrated on at these sprints.

Plasma sprint in Valencia

It was great to see many new faces at the Plasma sprint. Most of these new contributors were working on the Plasma and KDE Apps Ui and Ux and we definitely need some new blood in these areas. KDE's Visual Design Group, the VDG, thinned out over the last two years because some leading figures left. But now seeing new talented and motivated people joining as designers and Ux experts I am optimistic that there will be a revival of the golden time of the VDG that brought us Breeze and Plasma 5.

In regards to technical topics there is always a wide field of different challenges and technologies to combine at a Plasma sprint. From my side I wanted to discuss current topics in KWin but of course not everyone at the sprint is directly working on KWin and some topics require deeper technical knowledge about it. Still there were some fruitful discussions, of course in particular with David, who was the second KWin core contributor present besides me.

As a direct product of the sprint my work on dma-buf support in KWin and KWayland can be counted. I started work on that at the sprint mostly because it was a feature requested already for quite a long time by Plasma Mobile developers who need it on some of their devices to get them to work. But this should in general improve in our Wayland session the performance and energy consumption on many devices. Like always such larger features need time so I was not able to finish them at the sprint. But last week I landed them.

Megasprint in Nuremberg

At the Plasma sprint we talked about the current state of KWin and what our future goals should be. I wanted to talk about this some more but the KWin core team was sadly not complete at the Plasma sprint. It was Eike's idea to organize a separate sprint just for KWin and I took the next best opportunity to do this: as part of the KDE Connect and the Onboarding sprints in the SUSE offices in Nuremberg just a few weeks later. Jokingly we called the whole endeavor because of the size of three combined sprints the Megasprint.

KDE Connect sprint

I was there one or two days earlier to also attend the KDE Connect sprint. This was a good idea because the KDE Connect team needs us to provide some additional functionality in our Wayland session.

The first feature they rely on is a clipboard management protocol to read out and manipulate the clipboard via connected devices. This is something we want to have in our Wayland session also in general because without it we can not provide a clipboard history in the Plasma applet. And a clipboard selection would be lost as soon as the client providing it is closed. This can be intentionally but in most cases you expect to at least have simple text fragments still available after the source client quit.

The second feature are fake inputs of keyboard and mouse via other KDE Connect linked devices. In particular fake input via keyboard is tricky. My approach would be to implement the protocols developed by Purism for virtual keyboards and input methods. Implementation of these looks straight forward at first, the tricky part comes in when we look at the current internal keyboard input code in KWayland and KWin: there is not yet support for multiple seats or for one set multiple keyboards at the same time. But this is a prerequisite for virtual keyboards if we want to do it right including the support of different layouts on different keyboards.

KWin sprint

After the official begin of the KWin sprint we went through a long list of topics. As this was the first KWin sprint for years or even forever there was a lot to talk about, starting with small code style issues we needed to agree on till large long-time goals on what our development efforts should concentrate in the future. Also we discussed current topics and one of the bigger ones is for sure my compositing rework.

But in the overall picture this again is only one of several areas we need to put work in. In general it can be said that KWin is a great piece of software with many great features and a good performance but its foundations have become old and in some cases rotten over time. Fixes over fixes have been put in one after the other increasing the complexity and decreasing the overall cohesion. This is normal for actively used software and nothing to criticize but I think we are now at a point in the product life cycle of KWin to either phase it out or put in the hours to rework many areas from the ground up.

I want to put in the hours but on the other side in light of possible regressions with such large changes the question arises if this should be done dissociated with normal KWin releases. There was not yet a decision taken on that.

Upcoming conferences

While the season of sprints for this year is over now there are some important conferences I will attend and if you can manage I invite you to join these as well. No entry fee! In the second week of September the KDE Akademy is held in Milan, Italy. And in the first week of October the X.Org Developer's Conference (XDC) is held in Montreal, Canada. At XDC I have two talks lined up myself: a full length talk about KWin and a lightning talk about a work-in-progress solution by me for multi DPI scaling in XWayland. And if there is time I would like to hold a third one about my ongoing work on auto-list compositing.

In the beginning I planned only to travel to Canada for XDC but just one week later the WineConf 2019 is held close to Montreal, in Toronto, so I might prolong the stay a bit to see how or if at all I as a compositor developer could help the Wine community in achieving their goals. To my knowledge this would be the first time a KWin developer attends WineConf.

18 Aug 2019 8:00pm GMT

17 Aug 2019

feedplanet.freedesktop.org

Manuel Stoeckl: 2019-08-17: Final report

17 Aug 2019 10:00pm GMT