Let’s go for my web review for the week 2023-23.

Our Right To Challenge Junk Patents Is Under Threat  | Electronic Frontier Foundation

Tags: tech, patents, law

This is bound to make the US patent system even worse than it already is…

https://www.eff.org/deeplinks/2023/06/our-right-challenge-junk-patents-under-threat

Vision Pro

Tags: tech, apple, ux, ar, vr, xr

Probably the best analysis of the new Apple device I’ve seen so far. Focuses more on the design of the user experience and compares with the strategy behind other similar devices. There are likely a lesson or two to be drawn from it.

https://notes.andymatuschak.org/Vision%20Pro

Developers are lazy, thus Flatpak

Tags: tech, linux, packaging, flatpak

A good reminder that Flatpak is no silver bullet. It’s a bit of a rant at times still it has some good points in particular the security implications are not always properly conveyed to the users. Some thinking might be required regarding what’s lost compared to “traditional” packaging approaches.

https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

ugrep - A faster, user-friendly and compatible grep replacement.

Tags: tech, tools, command-line

There’s a new grep alternative in town. Looks really fast and has an interesting interactive mode. Definitely something to check out.

https://github.com/Genivia/ugrep

Debugging Outside Your Comfort Zone: Diving Beneath a Trusted Abstraction

Tags: tech, complexity, architecture, config, debugging, automation

Very interesting case full of lessons. Of course, increasing the complexity of the system overall can lead to such hard to find issues. It’s also a tale into how seemingly innocuous settings can interact in unexpected ways. I also like the lessons learn pointing to the fact that you can and should debug even the systems you use through abstractions, diving into the code is almost always a good thing (even if in this particular case it wasn’t strictly necessary in the end). And last but not least it shows the tension between mastery and automation… the more you automate the least you master the system, and at the same time this automation is necessary for building resilience in the system.

https://www.infoq.com/articles/debugging-beneath-trusted-abstraction/

graydon2 | The Rust I Wanted Had No Future

Tags: tech, rust, language, design, community

Interesting post, highlights why it’s better when languages are designed in a more community fashion (make sure to read until the conclusion). At least in term of popularity it seems to help.

https://graydon2.dreamwidth.org/307291.html

PEP 695 – Type Parameter Syntax | peps.python.org

Tags: tech, python, pyright, type-systems

This will hopefully solve most of the oddities in the generic types syntax of Python. Will be available with CPython 3.12 and will need support from type checkers of course.

https://peps.python.org/pep-0695/

The Many Problems with Celery | Log Blog Kebab

Tags: tech, python, celery

Celery is a popular solution for job queues in the Python world… it’s far from perfect though. This list of fixes to make it safer to use is welcome if you’re stuck with it.

https://steve.dignam.xyz/2023/05/20/many-problems-with-celery/

ReactPy

Tags: tech, python, frontend

OK, that looks like an interesting idea for the frontend bits if your stack is mainly Python based. Still very young though.

https://reactpy.dev/docs/index.html

GitHub - bloomberg/pystack: 🔍 🐍 Like pstack but for Python!

Tags: tech, python, debugging

Looks like a very powerful tool for debugging and analyzing processes involving a Python interpreter.

https://github.com/bloomberg/pystack

My Approach to Building Large Technical Projects – Mitchell Hashimoto

Tags: tech, project-management, architecture, tests

Nothing really new but well written. This highlights fairly well the importance of decomposing projects, having at least the broad strokes of the architecture laid down and how automated tests help drive the progress. It’s nice to see it all put together.

https://mitchellh.com/writing/building-large-technical-projects

Bye for now!

We are happy to announce the release of Qt Creator 11 Beta!

Hello world,

This is my second blog post for Google Summer of Code 2023, where I will share what I accomplished during the GSoC-23 community bonding period.

Community Bonding period

During this time GSoC contributors spend 3 weeks learning about their organization’s community and preparing for their coding project. They get to know mentors, read documentation, get up to speed to begin working on their projects

During the community bonding period, the organizers took two introductory sessions kick starting our journey. The first Welcome Session was about the best practices and tips for a successful Google Summer of Code. Following that, GSoC Contributor Summit took place, during which previous participants and mentors shared their experiences of being part of GSoC.

During this time I also got to interact with fellow GSoC contributors and learned more about their interesting projects and their plans .

Furthermore, I utilized this time to get a head-start on my project by familiarizing myself with QT’s model-view programming with the help of official QT's documentation and Tokodon’s source code. Additionally, I implemented the User-Interface of the button to be used to open the moderation tool. The merge request for which can be found here.

An image showing the User Interface of Tokodon with implemented entry point of moderation Tool can be found below.

Next I am working on implementing the account Moderation tool :)

I will be writing regular blog posts on my website. You can read my previous blog-posts and follow my progress here

Hindsight preface: This was written in very tired state.

I have been chatting about this with people who know more than I ever will about Flatpak.

Soo I have added few edits here and there.

If I seem frustrated, most of my frustration is aimed at the unnecessary shit slinging over packaging formats.

We all want the good stuff, why the hell are we fighting?!

Might as well, since everyone else is doing this.

First off, I am just a dev, and mostly a user, not packager and...

I don't really care about the packaging format, as long as it works.

Anyhow, these are my current thoughts on them, both positive and negative.

I get the thing I want

I like Flatpaks when I am using an ancient system like Debian Stable, and still if it has Flatpak support, I can download actually usable versions of many applications. Even nightly versions!

This is good. I like this.

flatpak run blabla.org.bla.bla.bla.com.eu.biz.exe.yes

Flatpaks are clearly made GUI applications in mind, but still, typing that whole prose of commands and having to remember the org.com.package.eu lines hinders terminal UX.

Sometimes you just need to run things through terminal to debug things, or maybe you want to make a new shortcut of the app, or whatever. Maybe you want to even make a terminal application into a Flatpak app!

Typing that massive command really deters using flatpaks for terminal applications too, because every time you install apps, you have to make an alias or memorize the magic words.

Flatpak, when installing an application, should just create that for you.

Yes there's third party solutions. But the solution should be first party one.

But it is a minor nit in the end and I can live with it.. But I am gonna complain about it from time to time due to my bad memory lol.

Flatpaks can take sometimes too much space

The more packages you install through Flatpak, the more it "pays off."

This makes sense in systems that use mostly or always Flatpaks.

But when you mix and match, because, as a user you really don't care, you just want the app to work you may be frustrated to suddenly see your laptop with 256gb SSD losing big portion of it's space to the 5 apps you installed with dependencies, that do not match and can't be reused.

If you're starved for space, you may be better off just uninstalling Flatpaks in general and then using native packages, which (hopefully) your distro manages for you so that the dependencies are shared.

And no, saying "bro, just buy more space, bro" is not an excuse. Not everyone has that luxury, especially if they live in poorer countries and such. It's time to stop this silly notion of making things bigger because "well we have so much space now."

So if you need to ooze everything out of your system space, you may want to avoid Flatpaks if you don't install everything from there.

But if you're using a distro that uses Flatpaks for everything, your file usage is going to be very similar like with native packages. Unless every app has different dependencies even if they're based on same framework.

There really is no good or bad here. Just different use cases.

Edit: I have heard very different opinions on this. My thoughts on this have not changed, but I do believe it works for some but not for all. I think we need more benchmarking and actual evidence to make further claims.

So take my point about this with the "source: me and my pals" level.

Permission management

This is where I tend lose my marbles with Flatpaks. (But it's not really Flatpaks fault)

There are times when the app is uploaded to Flathub by some random and they never really checked what permissions the Flatpak actually needs.

So the it can be either leaking like a sieve or not working at all.

Luckily, I see this less often, but only if the app is sent to Flathub by the people who know what permissions are actually needed.

Still, there are times when I have to install Flatseal (Luckily KDE has it's own permission manager now!) and fiddle with some switches until the app does what it was actually designed to do. This is especially noticeable by programming tools like text editors.

So I just usually end up giving all the permissions. I just want the app to work.

And if even then it doesn't do the thing I need it to do, I just use a native package.

Having Android style pop-up asking for permission when the app needs it could be good solution for this. Edit: Apparently this is a thing with portals. That is super neat. I just didn't know, possibly because I'm on KDE Plasma. Plasma can use portals for this too, but KDE priority is now to get Qt6 out and working.

On the flipside, when installing random apps, I do feel a bit more safer. But I do not know if it's a placebo, due to the fact that I am reaaally not a security expert. :P

Where are my files???

Sometimes when installing an application from Flatpak, one expects to get multiple applications. My best example for this is Xonotic: Xonotic comes with the game binaries and dedicated server binaries.

I tried to find those with the Flatpak I was using for Xonotic but I could never find them.

Backing up configs can be a mystery too. Flatpak could have some integrated configuration manager or something that helps users syncing their configs easily.

Edit: Seems to be out of scope, but personally I do believe Flatpak would just benefit from this.

Github

Why the hell is all Flathub related stuff on Github? Is it to save on hosting costs or something? If so, I hope Flathub can move on it's own system soon.

In general I am tired of everything being tied to Github, but that's a separate rant.

Learn from Twitter and Reddit: Do not build your thing around just one corporate owned service. It will end up badly. I've seen in the future with my tinfoil hat, and I know.

Trust me, bro.

To sum it all up..

I really don't care about your packaging method. I care that the app works as expected when I launch it.

So far native packages have been better in my experience when it comes to this.

But I am not a "Flatpak hater!"

I do want these to work!

Because when it works it's awesome. It makes distributing files much easier.

I think sandboxing is a cool feature (if it is not just a placebo, I am no security expert). I can use newest coolest shiny things on distros that get updated once in a decade.

I just don't think the current solution is The Solution yet. It needs refinement and the above negative points are the papercuts that put me off of using it.

But I root for you, Flatpak. I think you're onto something really good in here.

PS. And I am tired also of some people thinking that, like Rust, it's the Holy Solution To Everything Ever. There's no such thing when it comes to computers. I want to be wrong though.

PPS. I hope I didn't type too "angry" here. I blame my lacking english skills. And lacking social skills. And just lack of skills in general. Skill issue(s).

No dislike towards anyone who works on Flatpak, just absolute pure respect. This stuff must be difficult to work on especially when some part of internet seems to always be screaming when something is done to it.

This post was just me whining a bit, here in my tiny corner of the internets.

glhf.

Over 120 individual programs plus dozens of programmer libraries and feature plugins are released simultaneously as part of KDE Gear.

Today they all get new bugfix source releases with updated translations, including:

• konsole: Adjust selection point coords when scrollback shrinks (Commit, fixes bug #470346)
• neochat: Focus message search window's search field by default (Commit, fixes bug #469879)
• yakuake: Prevent unnecessary tab switching when closing a tab (Commit, fixes bug #392626)

Distro and app store packagers should update their application packages.

• 23.04 release notes for information on tarballs and known issues.
• Package download wiki page
• 23.04.2 source info page
• 23.04.2 full changelog

Eleftherios will be delivering a keynote at #Akademy2023 where he will be talking about Libre Space Foundation and the value of free software in space.

In this interview he tells us about how he got started in the space industry, and how his love for open source shaped his choice of career.

Last time we discussed Value Semantics. However, I missed one topic that is super important for a better understanding of basic building blocks of C++. Today, we are going to talk about an object. Without further ado, let’s dive deeper!

Object

What is an object? According to the C++ standard, part 3.9.8 under the name of [basic.types]

 An object type is a (possibly cv-qualified) type that is not a function type, not a reference type, and not a void type.

Now is int i an object? Yes.

Is void* p an object? Still yes, because pointers are types themselves, they are not references.

As we said, references are not types, but what if we declare something like struct S{ int& ref;}; would that be an object type? Put your answers down below, I’d like to see your opinion on this. 🙂

Lifetime

When we talk about objects, the one idea that always follows is lifetime.

Lifetime is a period in which an object is fully initialized. It begins with

• storage with the proper alignment,
• obtaining size for type T, and
• if the object has non-trivial initialization, its initialization is complete.

The lifetime of an object of type T ends when:

• T is a class type with a non-trivial destructor,
• the destructor call starts, or
• the storage which the object occupies is reused or released

This is an extraction from [basic.life] paragraph of C++ standard. In easy words, complex objects live from the end of the constructor, until the beginning of a destructor, and the trivial objects, like int live from their storage allocation, until the end of the scope. Seems pretty easy, right?

So, if you see something like:

auto& GetData(){
    const int i = 5;
    return i;
}

you’d probably say that there is something fishy about it, and you’d be correct. Although i is returned from a function, notice the auto& here. It says that we’re actually returning a reference to a local variable. After the function returns, the stack is cleaned. Hence, you invoke a good old UB.

But what if we change the function to return a string instead of an int?

auto* GetData(){
    const char* i = "Hello";
    return i;
}

Now we get a normal “Hello” string from a function. This is due to a simple rule of a language, that states that all strings are valid throughout the entire program because they have a static storage.

But let’s change the story again:

auto* GetData(){
    const char[] i = "Hello";
    return i;
}

Notice that I’ve changed only one character and suddenly everything breaks. The behavior is undefined, everything crashes and burns. What happened here? We actually initialized the array with a copy of static data and returned a pointer to it.

Strings live longer, than you think they will, except when they don’t – Jason Turner @ CppCon 2018

Complex objects and their lifetimes

As we already discussed, lifetime of a complex object begins with a constructor and ends with a destructor. Although there are objects that have implicit destructors and constructors, there still may be things that may surprise you.

Firstly, the lifetime begins with the ending of the constructor execution.

That means a lot. Let’s have a look at an example:

struct S {
S(){}
~S(){}
};

int main(){S s;}

I think everyone will agree that the call order is constructor, and then destructor. But what if I present exceptions to the equation? What if S() may throw?

Well, the answer is: the destructor does not start! Why? Because the lifetime of an object did not start, since the constructor didn’t finish its execution.

Here lies a menace:

struct S {
S(int a){
    a = new MyWidgetNothrow(a);
    b = new MyWidgetThrows(a);
}
~S(){
   delete a;
   delete b;
}

MyWidget* a;
MyWidget* b;
};

int main(){S s;}

Are widgets deleted with the unwinding if the second object throws? No, the memory will leak. Hence, this is why the usage of new operator is a bad code smell and we should avoid it whenever possible. Here is an example on Godbolt.

However, a good thing to mention is that the stack unwinder actually destroys all initialized objects from within the class on throw. So, the pointer being an object type is trivially destroyed, but not the memory behind it.

What can we do to make this code work? Delegating constructors comes into play!

struct S {
S() = default;
S(int a):S{} {
a = new MyWidgetNothrow;
b = new MyWidgetThrows;
}
~S(){
delete a;
delete b;
}

MyWidget* a = nullptr;
MyWidget* b = nullptr;
};

int main(){S s;}

Here, the delegation constructor finished its execution, hence the object is alive, and the destructor finishes successfully on throw. This information brings us to the point of smart pointers. Since in many cases you can’t have an additional constructor to delegate to, or even a constructor at all, you need smart pointers to have robust code and ensure correct ownership of the objects.

Conclusion

Today we have touched a very basic yet complex topic of object lifetimes. Of course, there is a lot more to say and we will continue basics in the next post tackling move semantics with lifetime implications and finishing with a sprinkle of ownership semantics of smart pointers.

I hope you enjoyed the read. There is a plan for a video series that tackles modern C++ 20/23 topics and use the concepts in practice. Stay tuned for the announcement. 🙂

Be careful when returning references and wrapper objects from a function, and use new as rarely as possible! Enjoy object lifetime!

Sincerely,

Ilya “Agrael” Doroshenko

The post Object Lifetime appeared first on KDAB.

There’s a little RISC-V board on my desk – little in size, but it has 8GB of RAM and 1TB of storage – which is going to do some KDE build work.

For some background, The Register has a bit on what the Linux Foundation is doing in this space.

It’s a modern-ish Linux kernel:

[    0.000000] Linux version 5.15.0-starfive (sw_buildbot@mdcsw02)
               (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld
               (GNU Binutils) 2.35) #1 SMP Mon Dec 19 07:56:37 EST 2022
[    0.000000] Machine model: StarFive VisionFive V2

with a variety of storage options (eMMC is not connected today):

mtdblock1    31:1    0     3M  0 disk 
mtdblock2    31:2    0     1M  0 disk 
mmcblk1     179:0    0  29.7G  0 disk 
nvme0n1     259:0    0 931.5G  0 disk 

There’s a capable X11 desktop included, I think, but for now I’m working only over serial or ssh to bootstrap development.

Something I’ve recently bemoaned is that kdesrc-build somewhat takes away the old-fashioned “build it by hand and good luck” approach to building KDE. We have lots of carefully crafted dependency information in CMakeLists.txt, we used to have extensive documentation, and still have traditional packaging information in o-so-many-distro’s, but .. well, I’m going for an artisanal feel I guess.

• Install g++, cmake, ninja-build and git packages,
• Clone the KDE Qt Patch collection base repository,
• Run configure with a -prefix so everything gets built on that nvme drive.

In a total throwback to early years of Solaris packaging of KDE4, this means I get stuck in a loop of “what dependency am I missing now”. While trying the default branch (Qt6), I needed to add libmd4c-html0-dev (Debian, eh, so there’s separate -dev packages for everything). After that I switched to kde/5.15 branch, the KDE Qt Patch collection that I would want for a KDE Plasma stack.

I’m going to let it grind through building Qt5 (base) overnight to see how we do, build-wise. Creating qmake takes long enough (compared to the last Qt5 (base) build I did, which was on a 12th-generation i9 with 24 threads and 64GB RAM, that I think “overnight” might not be long enough.

Pictures of the assembled board in action to follow.

Plasma 6 porting continues, with stability improving daily and new features and user interface improvements trickling in.

New Features

Okular now lets you choose the default scaling mode when printing PDFs (Martin Schnitkemper, Okular 23.08. Link)

Global Themes can now set the window decoration border size (me: Nate Graham, Plasma 6.0. Link)

User Interface Improvements

Gwenview’s color correction settings have been rephrased to be more comprehensible and correct (Adam Fontenot, Gwenview 23.08. Link)

Apps that have been marked as “Favorite” in Kickoff/Kicker/Application Dashboard/etc are now weighted more a bit more highly in KRunner-powered search results (Alexander Lohnau, Plasma 6.0. Link)

KRunner’s own search history no longer includes searches made in other KRunner-powered search tools such as Kickoff (Alexander Lohnau, Plasma 6.0. Link)

In the Clipboard widget, when you generate a QR code for some text, you can now drag it anywhere images can be dragged (Fushan Wen, Plasma 6.0. Link)

When a Flatpak app requests permission to run in the background, the way this is presented is now clearer and more user-friendly (Vlad Zahorodnii, Plasma 6.0. Link)

Metadata from Krita’s .kra files is now parsed, extracted, and displayed in “Details” views of the Properties Dialog, Dolphin’s Information Panel sidebar, etc (Joshua Goins, Frameworks 6.0. Link)

Other Significant Bugfixes

(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)

When using the optional ddcutil support in Powerdevil, changing the brightness via any of the current methods now prioritizes changing the brightness of a laptop’s built-in screen, rather than only adjusting the brightness of an external screen. Support for per-screen brightness control is being scoped out and may come in the future! (Quang Ngô, Plasma 5.27.6. Link)

Category names in Widget Explorer are once again translated (Alexander Lohnau, Plasma 5.27.6. Link)

Switching Global Themes or color schemes in System Settings no longer results in the “Appearance” category list item becoming temporarily invisible (Someone awesome, Plasma 6.0. Link)

Windows marked “Show on top” now remain where they are when the “Peek at Desktop” effect is invoked (Vlad Zahorodnii, Plasma 6.0. Link 1 and link 2)

Other bug-related information of interest:

• 3 Very high priority Plasma bugs (down from 4 last week). Current list of bugs
• 52 15-minute Plasma bugs (same as last week). Current list of bugs
• 66 KDE bugs of all kinds fixed this week. Full list of bugs

Web presence

Another “KDE for” page has been created, this time showcasing what KDE can do for software developers! (Carl Schwan, right now! Link)

Changes not in KDE that affect KDE

In the Plasma Wayland session sidebars and docks provided by QDockWidget now work much better: it’s now re-dockable, and visually moved when dragged (David Redondo, Qt 6.6. Link)

…And everything else

This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.

How You Can Help

If you’re a developer, please please please start living on Plasma 6 and fixing the bugs that you encounter. It’s usable for daily driving (I’m doing so) but still very much pre-alpha and in need of work to get it into a releaseable state by the end of the year. We need your help!

Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!