I Use This!
Activity Not Available

News

Analyzed over 1 year ago. based on code collected about 2 years ago.
Posted 1 day ago by Thomas Fischer
Finally, KBibTeX 0.9 got released. Virtually nothing has changed since the release of beta 2 in May as no specific bugs have been reported. Thus ChangeLog is still the same and the details on the changes since 0.8.2 as shown on the release announcement for 0.9-beta2. Grab the sources at KDE&aposs download mirrors. comments
Posted 1 day ago by Thomas Baumgart (ipwizard)
KMyMoney as a financial application deals with numbers a lot. As a KDE application, it supports internationalization (or i18n for short) from the very beginning. For accuracy reasons it has internal checks to verify the numbers a user can enter. ... [More] The validation routine has a long history (I think it goes back to the KDE3 days) and we recently streamlined it a bit as part of the journey to use more and more Qt standard widgets instead of our own. This led to the replacement of the KMyMoneyEdit widget with the newer AmountEdit widget. Everything worked great for me (using a German locale) until we received notifications that users could only enter integer numbers but no fractional part. This of course is not what we wanted. But why is that? The important piece of information was that the user reporting the issue uses the Finland svenska (sv_FI) locale on his system. So I set my development system to use that locale for numbers and currencies and it failed for me as well. So it was pretty clear that the validation logic had a flaw. Checking the AmountValidator object which is an extension of the QDoubleValidator I found out that it did not work as expected with the said locale. So it was time to setup some testcases for the validator to see how it performs with other locales. I still saw it failing which made me curious so I dug into the Qt source code one more time, specifically the QDoubleValidator. Well, it looked that most of the logic we added in former times is superfluous meanwhile with the Qt5 version. But there remains a little difference: the QDoubleValidator works on the symbols of the LC_NUMERIC category of a locale where we want to use it the LC_MONETARY version. So what to do? Simply ignore the fact? This could bite us later. So the next step was to check what happens within the testcases: Using the current code base they fail. Ok, good news I caught the problem. Using the plain QDoubleValidator and running the testcases again showed that all were positive. So no problem? What if a locale uses different symbols for the decimal point and the thousands separator? Does such a locale exist? Looking at all of them seemed a bit tedious, but tedious work is something for a computer. Here’s the little script I wrote (for simplicity in Perl): checklocalesDownload So, they do exist. Bummer, we need to do something about it. On my box, I collect 484 locales where 110 show differences. That’s close to 25% of the locales, too much to simply ignore the problem. Since some of the locales where present in multiple formats (e.g. br_FR, br_FR@euro and br_FR.utf8) I concentrated on the utf8 versions and the ones that contained an at-sign in their name). This modified the figures to 37 with differing values out of 182 locales checked. Still 20%. Here’s that list. <> denotes an emtpy string, and _ denotes a blank in the locale. If I would not replace those values one could not see a difference in a terminal session. Locale dp mon_dp sep mon_sep aa_DJ.utf8 . . <> _ aa_ER@saaho . . <> , be_BY@latin , . . _ be_BY.utf8 , . . _ bg_BG.utf8 , , <>   bs_BA.utf8 , , <> _ ca_AD.utf8 , , <> . ca_ES@euro , , <> . ca_ES.utf8 , , <> . ca_FR.utf8 , , <> . ca_IT.utf8 , , <> . de_AT@euro , , . _ de_AT.utf8 , , . _ es_MX.utf8 . .   , es_PE.utf8 , . . , eu_ES@euro , , <> . eu_ES.utf8 , , <> . gez_ER@abegede . . <> , gl_ES@euro , , <> . gl_ES.utf8 , , <> . hr_HR.utf8 , , <> _ it_CH.utf8 , . ' ' it_IT@euro , , <> . it_IT.utf8 , , <> . mg_MG.utf8 , , <> _ nl_BE.utf8 , , . _ nl_NL@euro , , <> _ nl_NL.utf8 , , <> _ pl_PL.utf8 , , <> . pt_PT@euro , , <> . pt_PT.utf8 , , <> . ru_RU.utf8 , .     ru_UA.utf8 , . . _ so_DJ.utf8 . . <> _ sr_RS@latin , , <> . tg_TJ.utf8 , . . _ tt_RU@iqtelif , . .   182 locales processed, 37 locales differ. Next I went in and tried to figure out what differences exist. A bit of UNIX foo (i.e. combining the tools of your toolbox) shows the results: ./checklocales | tr '\t' ':' | cut -d: -f2- | tr ':' '\t' | sort | uniq | grep -v "mon_dp" | grep -v "process" reveals the following result (I added the header here manually): dp mon_dp sep mon_sep , , <> _ , , <> . , , . _ , . . _ , . . , , . .   , . ' ' . . <> _ . . <> , . .   , , , <>   , .     Running this additionally through “wc -l” shows 12 different combinations. The last one is strange, because it does not show anything in the last two columns. Looking at the full table shows that this is the entry produced by ru_RU.utf8. Why is this now? Running LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep we get decimal_point="," mon_decimal_point="." thousands_sep=" " mon_thousands_sep=" " which looks just fine, but why did we not see the underbar for the blanks in the thousands separator? Running the above output through our friend od we see why: LC_ALL=ru_RU.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " , 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " 302 240 " \n m o n _ t 0000100 h o u s a n d s _ s e p = " 302 240 0000120 " \n 0000122 Ah, “302 240” octal: that is some UTF-8 encoded character presented as a blank in my default locale. Ok, since it is the same no big deal. But there are two more: , . .   . .   , Going into the long list we see that these are the results of tt_RU@iqtelif and es_MX.utf8. Looking at od’s output we see: LC_ALL=tt_RU@iqtelif locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " , 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " . " \n m o n _ t h 0000100 o u s a n d s _ s e p = " 342 200 202 0000120 " \n 0000122 LC_ALL=es_MX.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep | od -c 0000000 d e c i m a l _ p o i n t = " . 0000020 " \n m o n _ d e c i m a l _ p o 0000040 i n t = " . " \n t h o u s a n d 0000060 s _ s e p = " 342 200 211 " \n m o n _ 0000100 t h o u s a n d s _ s e p = " , 0000120 " \n 0000122 so again just some special chars which are shown as blank, but they differ between numeric and currency representation in the said locales. While trying a few things I stumbled across the following output. See for yourself: LC_ALL=C.utf8 locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep decimal_point="." mon_decimal_point="." thousands_sep="" mon_thousands_sep="" LC_ALL=C locale -k decimal_point mon_decimal_point thousands_sep mon_thousands_sep decimal_point="." mon_decimal_point="" thousands_sep="" mon_thousands_sep="" What? The C locale (non UTF-8 version) has no monetary decimal point defined? This may end in strange results, but since nowadays we talk about UTF-8 I simply put it aside. Back to the original problem: the AmountValidator. Looking at the results above, it seems not to make sense to simply use the QDoubleValidator version. Would it make sense to allow both versions? To use the QDoubleValidator we would need to replace the currency versions of the two characters with their numeric version. The question is: would that lead to false strings in any of the locales? Looking at the long list, we find the following where both characters are different: Locale dp mon_dp sep mon_sep be_BY@latin , . . _ be_BY.utf8 , . . _ es_PE.utf8 , . . , ru_UA.utf8 , . . _ tg_TJ.utf8 , . . _ tt_RU@iqtelif , . .   es_PE.utf8 seems to be the worst candidate. The meaning is simply reversed. Let’s add this locale to the testcases and see how it performs. Looks like it works out of the box. Strange, I expected a different result. Anyway, the changes to KMyMoney are now committed to the master branch and I can continue with the next problem. [Less]
Posted 2 days ago by Nate Graham (ngraham)
Week 75 in KDE’s Usability & Productivity initiative is here! It’s a little lighter than usual because we’re all feverishly preparing for the dual Plasma and Usability & Productivity sprints nest week in Valencia, Spain. I’ll be there, as ... [More] well as the whole Plasma team, a bunch of VDG people, and a number of folks who have stepped up to work on apps for the U&P initiative. Sprints like these promise the kind of face-to-face contact needed for big projects, and should be a fantastically awesome and productive time! I’d like to offer a special thanks to Slimbook (makers of the KDE Slimbook II laptop) for hosting the sprint! Anyway, here’s the week’s report: New Features When using multiple screens, it’s now possible to configure whether the settings for a particular screen apply to that screen in every arrangement that includes that screen, or only in the current screen arrangement (Roman Gilg, KDE Plasma 5.17.0) Bugfixes & Performance Improvements The Baloo file indexing service now notices when extended attributes on folders change, no longer does unnecessary work when an indexed folder is renamed, is faster to index un-indexed files, is even lighter when run on a laptop on battery power, and terminates its indexer processes when stopped or disabled, and (Stefan Brüns, KDE Frameworks 5.60) The screen locker now works harder to lock the screen on X11 when something has grabbed keyboard focus (e.g. when a context menu is open) (David Edmundson, KDE Plasma 5.17.0) Settings for font rendering are now saved and retrieved properly in all circumstances (Bhushan Shah, KDE Plasma 5.16.1) There is no longer a one-pixel pap between the panel and application windows when using certain 3rd-party Plasma themes with Qt 5.13 (Friedrich Kossebau, KDE Plasma 5.16.1) User Interface Improvements The session and keyboard chooser menus on the SDDM login screen are now visually consistent with everything else (Carson Black, Plasma 5.16.1): Discover no longer shows huge unnecessary horizontal padding for screenshots on Plasma and apps addons (Aleix Pol Gonzalez, KDE Plasma 5.16.1) The System Settings Night Color page received now has a better layout (Filip Fila, KDE Plasma 5.17.0): Konsole’s settings window has been modernized and given a user interface overhaul (Mariusz Glebocki, Konsole 19.08.0): Text in Dolphin’s information panel is now mouse-selectable and copyable (Gabriel Felipe Huwe, Dolphin 19.08.0) Improved High DPI support in Yakuake (Matthieu Gras, Yakuake 3.0.6) Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite! If you find KDE software useful, consider making a donation to the KDE e.V. foundation. [Less]
Posted 2 days ago by Tomaz Canabrava (tomaz)
We are seeing a strange trend nowadays: The terminal is being more widely used in windows, after they fixed the broken cmd.exe and MS is actually actively promoting their terminal applications like Visual Studio Code and the new Windows Terminal, but ... [More] on the other hand the Unix world was always terminal based, even if you tend to use the Desktop Environment for your daily needs you probably also had a Terminal open somewhere. And because we had always been terminal users, there are a lot of terminals for Linux, But it’s not easy to keep a terminal up to date, it’s usually fragile code and hard to maintain, that means that a lot of projects, good projects, are abandoned. Good terminals that unfortunately didn’t make it Tilix: Is one of the best terminal emulators out there, it’s a shell written in D, on top of VTE, the author lacks the time to continue working on it. Terminator: I don’t know if this one is abandoned as there’s no news on the web about it, the news that I know is that version 2 is scheduled for release in 2017, never happened though. If you are sad that your favorite terminal is without a maintainer, try to maintain it, free software depends on developers. The state of Konsole: Konsole is receiving more reviews, more code and more contributors in the last year than it got in the past 10 years. In the past, the project is kept alive by Kurt, and he did an awesome job. But a project as big as konsole needs more people. Three new developers joined konsole and are activelly fixing things over the past year, no plans to stop. Terminator / Tilix split mode is working A few features to be completely equal to minix / terminator is missing, but not hard to implement Now it has more developers and more code flowing, fixing bugs, improving the interface, increasing the number of lines of code flowing thru the codebase. We don’t plan to stop supporting konsole, and it will not depend on a single developer anymore. We want konsole to be the swiss army knife of terminal emulators, you can already do with konsole a lot of things that are impossible in other terminals, but we want more. And we need more developers for that. Konsole is, together with VTE, the most used terminal out there in numbers of applications that integrate the technology: Dolphin, Kate, KDevelop, Yakuake, and many other applications also use konsole, so fixing a bug in one place we are helping a lot of other applications too. Consider joining a project, Consider sending code. [Less]
Posted 3 days ago by Carl Schwan (ognarb)
In the last week, there have been various small improvements to the kde.org website. Search bar in kde.org/applications KDE has a lot of applications and with the last update to kde.org/application made by Jonathan Riddell, all these applications ... [More] are now displayed on the website. The problem is that it’s now difficult to search for a specific application, so I added a search bar to this page. See Merge request 5 kde-org-applications Support multiple screenshots per application According to the AppStream specification, an application can have multiple screenshots. If before only the first screenshot was displayed, now all screenshots are displayed in a carousel. See Merge request 3 kde-org-applications Adding schema.org information The application page now contains some additional metadata information. This can help search engines to better understand the content of the webpage. See Merge request 7 kde-org-applications Improving the Plasma product page With Plasma 5.16, we now have a new wallpaper, so I changed the wallpaper displayed at kde.org/plasma-desktop. Problem: the contrast between the text and the background wasn’t great. So I added a small breeze like window, created only with CSS and HTML. Junior jobs There still are a lot of things that can be improved, and we would appreciate some help to do it. If you always wanted to contribute to KDE, but don’t have any knowledge in Cpp and Qt, then you can also help with web development. If you are interested, I listed some junior jobs. The carousel used to display the application screenshots still has some problems. The next and previous buttons don’t use the same theme as the carousel shown on the homepage. Also, when screenshots have a different size, the transition is not perfect. For more information, see bug 408728. We need to add a description for each page in kde.org. This will improve the SEO used for KDE. First we need to define the new variable in aether, use it, and then we can start adding descriptions. This task needs to be done in cooperation with kde-promo and this should help with Search Engine Optimization (SEO). I wrote a small installation instruction on how to setup your local development environment. And if you need any help, you can as always contact me in Mastodon at @carl@linuxrocks.online or with matrix at @carl:kde.org. [Less]
Posted 3 days ago by Aleix Pol (apol)
During the next days, we’ll be having several sprints in València. First we’ll be having the KDE e.V. Board on Monday and Tuesday then we’ll be having two big sprints: Plasma, where we’ll be planning and working on the features for the next year ... [More] (or more!) Usability & Productivity goal’s that will look into different applications and components in KDE that need attention to work properly and improve them. If you are around and you’d like to meet the different groups, we’ll be having open dinners so you can join and ask us anything. The Board dinner will be next Monday 17th June at 20:30. The Plasma & Usability dinner will be next Saturday 22nd June at 20:30. Send me an e-mail to aleixpol@kde.org saying when you’d like to come. The location will be decided depending on the amount of people who ends up coming. Last but not least, big thanks to Slimbook for hosting us for this sprint! [Less]
Posted 3 days ago by Kuntal Majumder (hellozee)
This would start with a quote: Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing.
Posted 3 days ago by Jonathan Riddell (riddell)
The KDE Applications website was a minimal possible change to move it from an unmaintained and incomplete site to a self-maintaining and complete site.  It’s been fun to see it get picked up in places like Ubuntu Weekly News, Late Night Linux and ... [More] chatting to people in real life they have seen it get an update. So clearly it’s important to keep our websites maintained.  Alas the social and technical barriers are too high in KDE.  My current hope is that the Promo team will take over the kde-www stuff giving it communication channels and transparancy that doesn’t currently exist.  There is plenty more work to be done on kde.org/applications website to make it useful, do give me a ping if you want to help out. In the mean time I’ve updated the kde.org front page text box where there is a brief description of KDE.  I remember a keynote from Aaron around 2010 at Akademy where he slagged off the description that was used on kde.org.  Since then we have had Visions and Missions and Goals and whatnot defined but nobody has thought to put them on the website.  So here’s the new way of presenting KDE to the world: Thanks to Carl and others for review.   [Less]
Posted 5 days ago by Krita News
Time for another development update. The last one was in April. We skipped reporting on May, because doing a release takes a lot of time and effort and concentration! And then we had to do a bugfix release in the first week of June; the next release ... [More] , Krita 4.2.2, will be out by the end of this month. We’re still fixing bugs like crazy, helped by long-standing community member Ivan Yossi, who started fixing bugs full-time in May, too. But then, we’re also getting a crazy number of bug reports. Honesty compels us to say that many of those reports are not so very valuable: there are many people with broken systems who report problems that we cannot solve in Krita, and many people report bugs without telling us anything at all. Hence we created a manual page on reporting bugs! But there are also many helpful bug reports that give us a chance to improve things. So, how does Krita’s development work these days? Well, there are the many people who work on Krita as volunteers, which has always been the mainstay of Krita development. Then there are this year’s four Google Summer of Code students, who are all making good progress in their projects.  Krita has participated in every edition of Google Summer of Code since the beginning. But these days, there are four people working on Krita full-time, thanks to donations, the development fund (which we’re working on to revamp a bit and make it more useful to supporters, too), the Windows Store and the Steam Store. None of us is exactly getting rich, but we’re getting by. And we’re doing stuff that would otherwise be hard to do: projects that take several weeks or months to complete, fixing lots of bugs all over the place, doing janitorial stuff like fixing warnings and so on. Since this is a development update, we’ll just in passing mention all the great work that’s been done on this website, the manual, and all the work supporting our users on places like the forum or reddit. We’re all hanging out on the Krita IRC channel, which is the main place where contributors to Krita come together to discuss whatever needs to be discussed. We have a weekly meeting every Monday from 14:00 to 15:00 CE(S)T — which means that if you’ve got a question about Krita, that’s probably not the right time to join the channel. In August, we’ll have another Krita Sprint, a big one, with 25 people attending. Half of the people coming to the Sprint are contributors, half are artists and half are both. So, that’s how our community in general works — but what did we do specifically, since the release? Since 4.2.0, we released 4.2.1 with a bunch of bug fixes already, and the fixing has not abated. Tiar has finished most of the work on making Krita report back any and all failures when saving an image. Dmitry has been fixing some severe issues in the layer stack, GPU canvas and tool handling, Boudewijn has been fixing bugs all over the place and Ivan has been busy with animated brush tips (that is, Gimp Image Hose files). Color is random, left and right hands come one after the other, and hand direction  is dependent on drawing direction. Image by Ivan Yossi. Not for 4.2.2, but 4.3 (which should be out in September) are two new features already: the palettize filter by Carl Schwan, still work in progress, but that’s fine, 4.3 isn’t done yet, and the High Pass filter by Miguel Lopez: Allows interactively painting in truecolour while viewing matched to palette, with optional pattern-based dithering. Image by Carl Schwan At the Libre Graphics Meeting, which was attended by Boudewijn, Wolthera and Tiar, several projects presented the history of their project with cool graphs. Well, since Krita officially turned twenty on June 8th (which we completely forgot to celebrate, because of all the release work), we thought it might be interesting to analyze the history of Krita’s codebase a bit as well. Interestingly, this commit isn’t even in Krita’s git repository anymore: a lot of history was lost over the years. Krita started out as KImageShop in KDE’s CVS repository. Then, after KImageShop had been renamed to Krayon and Krita, the CVS repository was converted to Subversion. Then the subversion repository was converted to git, and the git repository split into a KOffice, a Calligra and a Calligra-History repository.  And then the Krita repository was extracted from the Calligra repository. Still, let’s take a look at what we found out. We used theseus-of-git to analyze the repository. Here’s the number of lines of code written by the top twenty-five developers. Another interesting graphic shows how long code survives over the years. Just as in the previous graph, there’s a huge peak of code that quickly disappears, and that’s when KOffice/Calligra was being developed together with Nokia for the Maemo document viewer application. When Krita was separated from Calligra, all that code was no longer necessary. The type of files in the repository is pretty constant: it’s .cpp and .h files, meaning, that Krita is and always has beem mostly C++. The funniest thing is maybe the enormous number of lines of code in .xmi files. That’s Umbrello‘s file format, and it represents UML diagrams of Krita’s codebase. Those had to be updated manually, and at one point, we just deleted them because they had gotten useless. [Less]
Posted 5 days ago by Krita News
Time for another development update. The last one was in April. We skipped reporting on May, because doing a release takes a lot of time and effort and concentration! And then we had to do a bugfix release in the first week of June; the next release ... [More] , Krita 4.2.2, will be out by the end of this month. We’re still fixing bugs like crazy, helped by long-standing community member Ivan Yossi, who started fixing bugs full-time in May, too. But then, we’re also getting a crazy number of bug reports. Honesty compels us to say that many of those reports are not so very valuable: there are many people with broken systems who report problems that we cannot solve in Krita, and many people report bugs without telling us anything at all. Hence we created a manual page on reporting bugs! But there are also many helpful bug reports that give us a chance to improve things. So, how does Krita’s development work these days? Well, there are the many people who work on Krita as volunteers, which has always been the mainstay of Krita development. Then there are this year’s four Google Summer of Code students, who are all making good progress in their projects.  Krita has participated in every edition of Google Summer of Code since the beginning. But these days, there are four people working on Krita full-time, thanks to donations, the development fund (which we’re working on to revamp a bit and make it more useful to supporters, too), the Windows Store and the Steam Store. None of us is exactly getting rich, but we’re getting by. And we’re doing stuff that would otherwise be hard to do: projects that take several weeks or months to complete, fixing lots of bugs all over the place, doing janitorial stuff like fixing warnings and so on. Since this is a development update, we’ll just in passing mention all the great work that’s been done on this website, the manual, and all the work supporting our users on places like the forum or reddit. We’re all hanging out on the Krita IRC channel, which is the main place where contributors to Krita come together to discuss whatever needs to be discussed. We have a weekly meeting every Monday from 14:00 to 15:00 CE(S)T — which means that if you’ve got a question about Krita, that’s probably not the right time to join the channel. In August, we’ll have another Krita Sprint, a big one, with 25 people attending. Half of the people coming to the Sprint are contributors, half are artists and half are both. So, that’s how our community in general works — but what did we do specifically, since the release? Since 4.2.0, we released 4.2.1 with a bunch of bug fixes already, and the fixing has not abated. Tiar has finished most of the work on making Krita report back any and all failures when saving an image. Dmitry has been fixing some severe issues in the layer stack, GPU canvas and tool handling, Boudewijn has been fixing bugs all over the place and Ivan has been busy with animated brush tips (that is, Gimp Image Hose files). Color is random, left and right hands come one after the other, and hand direction  is dependent on drawing direction. Image by Ivan Yossi. Not for 4.2.2, but 4.3 (which should be out in September) are two new features already: the palettize filter by Carl Olsson, still work in progress, but that’s fine, 4.3 isn’t done yet, and the High Pass filter by Miguel Lopez: Allows interactively painting in truecolour while viewing matched to palette, with optional pattern-based dithering. Image by Carl Schwan At the Libre Graphics Meeting, which was attended by Boudewijn, Wolthera and Tiar, several projects presented the history of their project with cool graphs. Well, since Krita officially turned twenty on June 8th (which we completely forgot to celebrate, because of all the release work), we thought it might be interesting to analyze the history of Krita’s codebase a bit as well. Interestingly, this commit isn’t even in Krita’s git repository anymore: a lot of history was lost over the years. Krita started out as KImageShop in KDE’s CVS repository. Then, after KImageShop had been renamed to Krayon and Krita, the CVS repository was converted to Subversion. Then the subversion repository was converted to git, and the git repository split into a KOffice, a Calligra and a Calligra-History repository.  And then the Krita repository was extracted from the Calligra repository. Still, let’s take a look at what we found out. We used theseus-of-git to analyze the repository. Here’s the number of lines of code written by the top twenty-five developers. Another interesting graphic shows how long code survives over the years. Just as in the previous graph, there’s a huge peak of code that quickly disappears, and that’s when KOffice/Calligra was being developed together with Nokia for the Maemo document viewer application. When Krita was separated from Calligra, all that code was no longer necessary. The type of files in the repository is pretty constant: it’s .cpp and .h files, meaning, that Krita is and always has beem mostly C++. The funniest thing is maybe the enormous number of lines of code in .xmi files. That’s Umbrello‘s file format, and it represents UML diagrams of Krita’s codebase. Those had to be updated manually, and at one point, we just deleted them because they had gotten useless. [Less]