Skip to content

Tuesday, 29 October 2024

Ruqola 2.3.1 is a feature and bugfix release of the Rocket.chat app.

New features:

  • Use "view-conversation-balloon-symbolic" icon when we have private conversation with multi users
  • Add version in market application information
  • Fix reset password
  • Fix mouse position when QT_SCREEN_SCALE_FACTORS != 1
  • Add missing icons
  • Fix create topic when creating teams
  • Fix discussion count information
  • Remove @ or # when we search user/channel
  • Fix edit message logic

URL: https://download.kde.org/stable/ruqola/
Source: ruqola-2.3.1.tar.xz
SHA256: 99356ec689473cd5bfaca7f8db79ed5978efa8b3427577ba7b35c1b3714d5fcb
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
https://jriddell.org/jriddell.pgp

Monday, 28 October 2024

Fractional scaling is hard. Anyone that had the misfortune of working on it knows that… so it won’t surprise a lot of people that it’s not all figured out yet! Today I’ll talk about the fractional scaling problems with KWin’s server side decorations, and why we need to do an API break to fix it.

What’s the problem?

This is the simplest part. Many decorations have elements that need to be pixel perfect, like outlines that are only a single pixel wide. When they’re not perfectly scaled, or positioned wrongly, that’s sometimes quite visible and annoying:

What causes these issues?

The source of all evil with fractional scaling is also the cause of most issues here: Integer logical coordinates.

Logical coordinates are a way to represent the size of something on the screen in a mostly display-independent way and are quite useful for the size and position of things like windows or the cursor. They’re calculated in a really simple way:

coordinate_logical = coordinate_pixels / scale

With just that equation, there are no problems just yet - you can just multiply the logical coordinate with the display scale, and you get back the original coordinate in pixels. When you round that logical coordinate, and do some calculations with it, things get weird though… let’s look at the concrete example of a window at scale 1.25, and with a 1 pixel wide outline:

unitoutline widthwindow widthoutline widthtotal sizetotal size in pixels
(integer) pixels12712929
fractional logical0.821.60.823.229
integer logical12212430

As you might’ve guessed, KWin’s decoration plugin API is using integer logical coordinates, and this mismatch between the window size vs. the size of its components causes most of the problems. Just doing a straight forward int -> float conversion isn’t enough to fix this though, a few more changes are needed.

Changes in KWin

KWin will provide decorations with the fractional logical size of windows, provide them with the scale factor they should render for, and use the decoration’s fractional border sizes to position the window and decoration pieces properly in the scene.

Changes in Decorations

Because of the API break, decorations using the C++ API need to be updated to the new KDecoration3 API, or they will not be loaded. A minimalistic port would only need to round all the values, but there will of course still be fractional scaling issues with that.

Assuming you want to make the decoration work properly with fractional scaling, you also need to use the provided scale factor to calculate border sizes, and when painting things with QPainter, you need to take care to snap all geometries to the pixel grid, or anti-aliasing may turn single-pixel lines into a blurry mess.

Note that this work isn’t completed yet, and some additional API changes may happen while we’re breaking the API already. A porting guide with all the changes will be provided before the release of Plasma 6.3.

As Aurorae decorations are just svg files, they are not affected by this API break and will continue to work like before without any changes.

If you have any questions about this change, or about how to port a decoration over to the new API, please reach out to us at #kwin:kde.org on matrix!

One of the quickest ways to determine whether particular application runs using Xwayland is to resize one of its windows and see how it behaves, for example

A script element has been removed to ensure Planet works properly. Please find it in the original post.

While it can be handy for the debugging purposes, overall, it makes the Plasma Wayland session look less polished. So, one of the goals for 6.3 was to fix this visual glitch.

This article will provide some background behind what caused the glitch and how we addressed it. Just in case, here’s the same application, which was shown in a screen cast above, but with the corresponding resizing fixes in:

A script element has been removed to ensure Planet works properly. Please find it in the original post.

X11 frame synchronization protocol(s)

On X11, all window changes typically take place immediately, including resizing. This can lead to some issues. For example, if a window is resized, it can take a while until the application repaints the window with the new size. What if the compositing manager decides to compose the screen in meanwhile? You’re likely going to see some sort of visual glitches, e.g. the window contents getting cropped or seeing parts of the window that have not been repainted yet.

In order to address this issue, there exists an X11 protocol to synchronize window repaints during interactive resize. An application/client wishing to participate in this protocol needs to list _NET_WM_SYNC_REQUEST in the WM_PROTOCOLS property of the client window and also set the XID of the XSync counter in the _NET_WM_SYNC_REQUEST_COUNTER property. When the WM wants to resize the window, the following will happen:

  1. The window manager sends a _NET_WM_SYNC_REQUEST client message containing a serial that the client will need to put in the XSync counter after processing a ConfigureNotify event that will be generated after the window is resized. The compositing manager and the window manager will block window updates until the XSync request acknowledgement is received;
  2. The WM resizes the client window, for example by calling the xcb_configure_window() function;
  3. The client would then repaint the window with the new size and update the XSync counter with the serial that it had received in step 1;
  4. The window manager and the compositing manager unblock window updates after receiving receiving the XSync request acknowledgement. For example, now, the window can be repainted by the compositing manager and there shouldn’t be glitches as long as the client behaves well.

Note that the window manager and the compositing manager are often the same. For example, both KWin and Mutter are compositing managers and window managers.

The frame synchronization protocol described above is called basic frame synchronization protocol. There is also an extended frame synchronization protocol, but it is not standardized and it is implemented only by a few compositing managers.

_NET_WM_SYNC_REQUEST and Xwayland

KWin supports the basic frame synchronization protocol, so there should be no visual glitches when resizing X11 windows in the Plasma Wayland session, right? At quick glance, yes, but we forget about the most important detail: Wayland compositors don’t use XCompositeNameWindowPixmap() or xcb_composite_name_window_pixmap() to grab the contents of X11 windows, instead they rely on Xwayland attaching graphics buffers to wl_surface objects, so there is no strict order between the Wayland compositor receiving an XSync request acknowledgement and graphics buffers for the new window size.

In order to help better understand the issue, let’s consider a concrete example. Assume that a window with geometry 0,0 100x100 is being resized by dragging its left edge. If the left edge is dragged 10px to the right, the following will happen:

  1. A _NET_WM_SYNC_REQUEST client message will be sent to the client containing the XSync counter serial that must be set after processing the ConfigureNotify event that will be generated after the Wayland compositor calls xcb_configure_window() with the new window size;
  2. The Wayland compositor calls xcb_configure_window() to actually resize the window;
  3. The client receives the sync request client message and the ConfigureNotify event, repaints the window, and acknowledges the sync request;
  4. The Wayland compositor receives the sync request acknowledgement and updates the window position to 10,0.

But here is the problem, when the window position is updated to 10,0, it’s not guaranteed that the wl_surface associated with the X11 window has a buffer with the new window size, i.e. 90x100. It can take a while until Xwayland commits a graphics buffer with the right size. In meanwhile, the compositor could compose the next frame with the new window position, i.e. 10,0, but old surface size, i.e. 100x100. It would look as if the right window edge sticks out of the window decoration. After Xwayland attaches a buffer with the right size, the right window edge will correct itself.

So, ideally, the Wayland compositor should update the window position after receiving the XSync request acknowledgement and Xwayland attaching a new graphics buffer to the wl_surface.

With that in mind, the frame synchronization procedure looks as follows:

  1. The compositor blocks wl_surface commits by setting the _XWAYLAND_ALLOW_COMMITS property to 0 for the toplevel X11 window. This is needed to ensure the consistent order between XSync request acknowledgements and wl_surface commits. As long as the _XWAYLAND_ALLOW_COMMITS property is set to 0, Xwayland will not attempt to commit the wayland surface, for example attach a new graphics buffer after the client repaints the window;
  2. The compositor sends a _NET_WM_SYNC_REQUEST client message as before;
  3. The compositor resizes the client window as before;
  4. The client repaints the window and acknowledges the XSync request as before;
  5. After receiving the XSync acknowledgement, the compositor unblocks surface commits by setting the _XWAYLAND_ALLOW_COMMITS property to 1. Note that the window updates are still blocked, i.e. the window position is not updated yet;
  6. After Xwayland commits the wl_surface with a new graphics buffer, the window updates are unblocked, e.g. the window position is updated.

The frame synchronization process looks more involved with Xwayland, but it is still manageable.

_NET_WM_SYNC_REQUEST support in applications

Most applications that use GTK and Qt support _NET_WM_SYNC_REQUEST, but there are applications that don’t participate in the frame synchronization protocol. If you use one of those apps, you will observe visual glitches during interactive resize.

Closing words

Frame synchronization is a difficult problem, and requires some very intricate code both on the compositor and the client side. But with the changes that we’ve made, I’m proud to say that KWin is one of the few compositors that properly handles frame synchronization for X11 windows on Wayland.

I would also like to express many thanks to the Xwayland developers (Michel Dänzer and Olivier Fourdan) for helping and assisting us with fixing the glitch.

Working on Kwave

Kwave is an audio editor based on the KDE Frameworks. It was started in 1998 by Martin Wilz, and Thomas Eschenbacher has been the main developer since 1999. In recent years development has slowed. I wanted to do some software development and contribute to KDE, and I’m interested in audio, so towards the end of 2023 I started working on Kwave.

Kwave had not been ported to Qt 6 and KDE Frameworks 6 yet, so that’s what I started working towards. My first merge requests were to update deprecated code. (MR Convert plugin desktop files to json, MR Port away from deprecated Qt API, MR port away from deprecated I18N_NOOP macros, MR bump KF5_MIN_VERSION and update where KMessageBox API has been deprecated, MR port QRegExp to QRegularExpression)

With that preparatory work done, I worked at porting Kwave to Qt 6 and KDE Frameworks 6. Most of that work was straight-forward. The biggest changes were in Qt Multimedia, which Kwave can use for playback and recording. I finally got that done and merged in August 2024, just after version 24.08 was branched, so that change will get released in version 24.12 in December 2024. (MR port to Qt6 and KF6)

Next I did some code cleanup. (MR use ECMGenerateExportHeader, MR add braces to avoid ambiguous else, MR call KCrash::initialize() after KAboutData::setApplicationData())

Laurent Montel added the FreeBSD job to the Continuous Integration configuration, but the build failed initially. I’ve never ran FreeBSD, but with a few tries and pushing changes to trigger CI, I managed to get the CI to pass. I’m glad Laurent took the initiative here, because the FreeBSD job uses clang, so with the existing Linux job using gcc, CI makes sure Kwave builds with both compilers now. (MR Add freebsd)

I applied for a KDE Developer account and got approved on August 24, 2024. Now I could commit changes myself instead of having to remind others to do it.

Carl Schwan cleaned up some code and updated the zoom toolbar to use standard icons, which enabled removing the built-in zoom icons. (MR Modernize ZoomToolbar) That was the incentive I needed to remove the rest of the built-in icons and use standard icons instead, which helps Kwave fit the users theme better. (MR use icons from current theme) I also reordered the playback toolbar in a way that seemed more logical to me. (MR update player toolbar)

I investigated a bug: Kwave Playback settings dialog loads incorrectly until you switch playback methods and fixed it in MR: make sure a valid method gets selected when PlayBackDialog opens

I have some more work in progress, and I plan to continue working on Kwave. I will try to blog about what I’m doing, but I’m not going to commit to any regular schedule.

Get Involved

Kwave depends on the rest of KDE. It is built on the Frameworks, and the KDE sysadmin team keeps the infrastructure running. You can help KDE by getting involved, or at least donate.

If you would like to help improve Kwave, use it and try out its features! If you have questions or ideas, discuss them. If you find bugs, report them. If you want to get involved with development, download the source code and start hacking!

If you think my own work on Kwave is worth something and you can afford it, you can donate to me through Liberapay, Stripe, or PayPal.

Sunday, 27 October 2024

As we have been doing yearly, a few weeks ago we had the 2024 edition of Linux App Summit (LAS). For those of you who don’t know, the Linux App Summit is a conference co-organised between KDE and GNOME among others where to bring together the different stakeholders of the linux ecosystem to make sure we have all the collaboration tools in place to have a great state of the art platform for the uses the world needs from us.

This year it was special in that since it became the Linux App Summit, we held it outside of Europe! We had LAS in Monterrey, the northernmost part of México in the ITESM (Instituto Tecnológico y de Estudios Superiores de Monterrey), a really nice campus and a beautiful venue.

Besides meeting people from other projects as I’d normally do in LAS, this year I had the added opportunity to meet the community the other side of the ocean. There certainly are good differences between how we organise FOSS communities Europe and there, it’s always useful to experience and iterate to ensure we are truly creating a community for everyone.

LAS ’25, Call for hosts

Are you considering bringing such communities to your home town? Please reach out, you can find some information how to do that here: https://linuxappsummit.org/bids/.

In my opinion, organising a conference is one of the best ways to bring FOSS talent to where you are. It’s often hard to find new ways to be part of what we do, this is a great one. I personally had the opportunity to do it in LAS’19 in Barcelona and it was a great experience.

LAS has the added value of being a melting pot of people from different communities so it’s a great opportunity to meet people that you might not crossed paths with before!

¡Hola Federico!

Wednesday, 23 October 2024

10 Tips to Make Your QML Code Faster and More Maintainable

In recent years, a lot has been happening to improve performance, maintainability and tooling of QML. Some of those improvements can only take full effect when your code follows modern best practices. Here are 10 things you can do in order to modernize your QML code and take full advantage of QML's capabilities.

1. Use qt_add_qml_module CMake API

Qt6 introduced a new CMake API to create QML modules. Not only is this more convenient than what previously had to be done manually, but it is also a prerequisite for being able to exploit most of the following tips.

By using the qt_add_qml_module, your QML code is automatically processed by qmlcachegen, which not only creates QML byte code ahead of time, but also converts parts of your QML code to C++ code, improving performance. How much of your code can be compiled to C++ depends on the quality of the input code. The following tips are all about improving your code in that regard.

add_executable(myapp main.cpp)

qt_add_qml_module(myapp
 URI "org.kde.myapp"
 QML_FILES Main.qml
)

2. Use declarative type registration

When creating custom types in C++ and registering them with qmlRegisterType and friends, they are not visible to the tooling at the compile time. qmlcachegen doesn't know which types exist and which properties they have. Hence, it cannot translate to C++ the code that's using them. Your experience with the QML Language Server will also suffer since it cannot autocomplete types and property names.

To fix this, your types should be registered declaratively using the QML_ELEMENT (and its friends, QML_NAMED_ELEMENT, QML_SINGLETON, etc) macros.

qmlRegisterType("org.kde.myapp", 1, 0, "MyThing");

becomes

class MyThing : public QObject
{
    Q_OBJECT
    QML_ELEMENT
};

The URL and version information are inferred from the qt_add_qml_module call.

3. Declare module dependencies

Sometimes your QML module depends on other modules. This can be due to importing it in the QML code, or more subtly by using types from another module in your QML-exposed C++ code. In the latter case, the dependency needs to be declared in the qt_add_qml_module call.

For example, exposing a QAbstractItemModel subclass to QML adds a dependency to the QtCore (that's where QAbstractItemModel is registered) to your module. This does not only happen when subclassing a type but also when using it as a parameter type in properties or invokables.

Another example is creating a custom QQuickItem-derived type in C++, which adds a dependency on the Qt Quick module.

To fix this, add the DEPENDENCIES declaration to qt_add_qml_module:

qt_add_qml_module(myapp
 URI "org.kde.myapp"
 QML_FILES Main.qml
 DEPENDENCIES QtCore
)

4. Qualify property types fully

MOC needs types in C++ property definitions to be fully qualified, i.e. include the full namespace, even when inside that namespace. Not doing this will cause issues for the QML tooling.

namespace MyApp {

class MyHelper : public QObject {
    Q_OBJECT
};

class MyThing : public QObject {
    Q_OBJECT
    QML_ELEMENT
    Q_PROPERTY(MyHelper *helper READ helper CONSTANT) // bad
    Q_PROPERTY(MyApp::MyHelper *helper READ helper CONSTANT) // good
    ...
};
}

5. Use types

In order for qmlcachegen to generate efficient code for your bindings, it needs to know the type for properties. Avoid using 'property var' wherever possible and use concrete types. This may be built-in types like int, double, or string, or any declaratively-defined custom type. Sometimes you want to be able to use a type as a property type in QML but don't want the type to be creatable from QML directly. For this, you can register them using the QML_UNCREATABLE macro.

property var size: 10 // bad
property int size: 10 // good

property var thing // bad
property MyThing thing // good

6. Avoid parent and other generic properties

qmlcachegen can only work with the property types it knows at compile time. It cannot make any assumptions about which concrete subtype a property will hold at runtime. This means that, if a property is defined with type Item, it can only compile bindings using properties defined on Item, not any of its subtypes. This is particularly relevant for properties like 'parent' or 'contentItem'. For this reason, avoid using properties like these to look up items when not using properties defined on Item (properties like width, height, or visible are okay) and use look-ups via IDs instead.

Item {
    id: thing

    property int size: 10

    Rectangle {
        width: parent.size // bad, Item has no 'size' property
        height: thing.height // good, lookup via id

        color: parent.enabled ? "red" : "black" // good, Item has 'enabled' property
    }
}

7. Annotate function parameters with types

In order for qmlcachegen to compile JavaScript functions, it needs to know the function's parameter and return type. For that, you need to add type annotations to the function:

function calculateArea(width: double, height: double) : double {
    return width * height
}

When using signal handlers with parameters, you should explicitly specify the signal parameters by supplying a JS function or an arrow expression:

MouseArea {
    onClicked: event => console.log("clicked at", event.x, event.y)
}

Not only does this make qmlcachegen happy, it also makes your code far more readable.

8. Use qualified property lookup

QML allows you to access properties from objects several times up in the parent hierarchy without explicitly specifying which object is being referenced. This is called an unqualified property look-up and generally considered bad practice since it leads to brittle and hard to reason about code. qmlcachegen also cannot properly reason about such code. So, it cannot properly compile it. You should only use qualified property lookups

Item {
    id: root
    property int size: 10

    Rectangle {
        width: size // bad, unqualified lookup
        height: root.size // good, qualified lookup
    }
}

Another area that needs attention is accessing model roles in a delegate. Views like ListView inject their model data as properties into the context of the delegate where they can be accessed with expressions like 'foo', 'model.foo', or 'modelData.foo'. This way, qmlcachegen has no information about the types of the roles and cannot do its job properly. To fix this, you should use required properties to fetch the model data:

ListView {
    model: MyModel

    delegate: ItemDelegate {
        text: name // bad, lookup from context
        icon.name: model.iconName // more readable, but still bad

        required property bool active // good, using required property
        checked: active
    }
}

9. Use pragma ComponentBehavior: Bound

When defining components, either explicitly via Component {} or implicitly when using delegates, it is common to want to refer to IDs outside of that component, and this generally works. However, theoretically any component can be used outside of the context it is defined in and, when doing that, IDs might refer to another object entirely. For this reason, qmlcachegen cannot properly compile such code.

To address this, we need to learn about pragma ComponentBehavior. Pragmas are file-wide switches that influence the behavior of QML. By specifying pragma ComponentBehavior: Bound at the top of the QML file, we can bind any components defined in this file to their surroundings. As a result, we cannot use the component in another place anymore but can now safely access IDs outside of it.

pragma ComponentBehavior: Bound

import QtQuick

Item {
    id: root

    property int delegateHeight: 10

    ListView {
        model: MyModel

        delegate: Rectangle {
            height: root.delegateHeight // good with ComponentBehavior: Bound, bad otherwise
        }
    }
}

A side effect of this is that accessing model data now must happen using required properties, as described in the previous point. Learn more about ComponentBehavior here.

10. Know your tools

A lot of these pitfalls are not obvious, even to seasoned QML programmers, especially when working with existing codebases. Fortunately, qmllint helps you find most of these issues and avoids introducing them. By using the QML Language Server, you can incorporate qmllint directly into your preferred IDE/editor such as Kate or Visual Studio Code.

While qmlcachegen can help boost your QML application's performance, there are performance problems it cannot help with, such as scenes that are too complex, slow C++ code, or inefficient rendering. To investigate such problems, tools like the QML profiler, Hotspot for CPU profiling, Heaptrack for memory profiling, and GammaRay for analyzing QML scenes are very helpful.

The post 10 Tips to Make Your QML Code Faster and More Maintainable appeared first on KDAB.

Monday, 21 October 2024

Oxygen Icons 6.1.0 is a feature release of the Oxygen Icon set.

It features new SVG symbolic icons for use in Plasma Applets.

It also features improved icon theme compliance, fixed visability and added mimetype links.

URL: https://download.kde.org/stable/oxygen-icons/
Source: oxygen-icons-6.1.0.tar.xz
SHA256: 16ca971079c5067c4507cabf1b619dc87dd6b326fd5c2dd9f5d43810f2174d68
Signed by: E0A3EB202F8E57528E13E72FD7574483BB57B18D Jonathan Riddell jr@jriddell.org
https://jriddell.org/jriddell.pgp

Sunday, 20 October 2024

Hey folks! Apologies for the long gap since my last post. A lot has happened both personally and professionally—I got a new job and relocated, which led to me extending my GSoC deadline to wrap up the remaining tasks. I’m happy to share that I’ve now completed everything, and all the pending MRs related to my GSoC work have been merged. Here’s a quick overview:

MRs merged:

  • Reset form implementation in Okular : Okular now has form reset functionality, allowing you to clear fields or return them to their default values. !MR1007
  • Support for MouseDown, MouseEnter and MouseExit events : The corresponding event object is now generated when these mouse events are triggered. !MR994
  • Keystroke, Validate, Calculate and Format event support for Comboboxes : These essential events were previously not triggered for comboboxes. This MR adds support for them. !MR1027
  • Fix order of execution of events for text form fields : Keystroke, Validate, Calculate, and Format actions weren’t always executed in the correct order, especially during undo/redo or when modified via JavaScript. This MR fixes that and ensures KVCF actions are only triggered when a field value is committed, improving keyboard usability. !MR1002
  • Support for modifying the appearance stream text in form field choice (Poppler) : Added functionality to modify appearance stream text in form fields without altering their actual values. !MR1590
  • SubmitForm functionality (Poppler) : Support for reading the SubmitForm action was added to Poppler. While Okular doesn’t yet implement the actual submission process, this lays the groundwork for future integration. !MR1579

Future Scope:

Although much progress has been made during GSoC’24, there are still many areas where Okular’s PDF form functionality could be expanded:

  • The actual submission of forms in Okular can be built on top of the SubmitForm action now supported by Poppler.
  • Adding support for the SelectionChange event in ListBoxes would enhance their interactivity.
  • Additional functions could be implemented for CheckBoxes, ComboBoxes, and ListBoxes, such as programmatically checking items, clearing, deleting, inserting, and setting items. Some of these changes would also require updates to Poppler.
  • Improving keyboard navigation for form fields could further boost accessibility and ease of use.

Conclusion:

Participating in GSoC with KDE and contributing to Okular has been an incredible learning experience, and I’m proud of the contributions made. Huge thanks to my mentor, Albert Astals Cid, for his constant support, guidance, and patience through all my mistakes. Special thanks to Sune Vuorela for his reviews and insights which helped me learn a lot, and to the KDE Mentorship and GSoC teams for their indirect but invaluable help. I’m looking forward to continuing my journey with KDE.

See you next time. Cheers!

Hello again, sorry it’s been a while since the last post. In this case, I’m doing a never-before-seen multi-month post!

This may be the last post in this series, as the KDE Promo team has launched “This Week in KDE Apps” which covers my work here (and I also have plans to contribute to… 😅) Nate Graham typically reports on my Plasma changes in his “This Week in Plasma” series. All that would be left is the uninteresting changes, so I was thinking it might be more sensible to do an emersion-style “Status update” that’s isn’t strictly KDE related. We’ll see!

Plasma

[Feature] You can now tweak the pen pressure. This is useful if you prefer a specific style to your strokes, and you can’t change this directly in your preferred application. We plan to have add “soft” and “hard” presets to make using the curve easier. This is one of the last items paid for by our NLnet grant, so it’s exciting to see it finally come to fruition! [6.3]

The new pen pressure control in the Drawing Tablet KCM.

[Feature] The stylus cursor is now hidden on the Calibration page but this will only work once your distribution switches to Qt 6.8. The credit belongs to Nicolas Fella as he’s the one who put in the work upstream in Qt! [6.2.1]

[Bugfix] The calibration accuracy is now improved slightly and refining your existing calibration further should work closer to how you expect. [6.2.1]

[Bugfix] Added more safety rails in the Calibration code to prevent possible crashes. [6.2.1]

[Bugfix] Made sure the calibration matrix is reset when you hit the “Defaults” button. [6.2.1]

[Bugfix] Now the Calibration window opens on the correct screen. [6.2.1]

[Bugfix] Now the action dialog doesn’t show up in the wrong place when your KCM scrolls a lot, like mine. [6.2.1]

Tokodon

[Feature] The welcome page when you first open Tokodon now looks much nicer and friendly. Hopefully it makes it clearer what Tokodon is, and also includes an even clearer badge to indicate what service it connects to. [24.12]

The new welcome page.

[Feature] Display public servers to ease registration for first-time Mastodon users. Right now there’s not any filtering options, but this is a huge improvement over an empty textbox and expecting users to know where to find a server. [24.12]

The new servers page.

[Feature] My post tag display improvement was merged, which limits tags to one line. Note that this isn’t the final design we’ll go with, but they will no longer spill onto multiple lines. [24.12]

This is how tags will look when there’s too many to display at once.

[Feature] It seems people want Cohost’s “Following” feed for Mastodon, and of course Tokodon could do it! So that’s what I did, and implemented Cohost’s “Following” feed. Albiet it’s currently limited due to the Mastodon API we have available, so it comes with two big caveats currently: You only see when people were last active by the day, and the pagination kinda sucks. [24.12]

The following feed.

[Feature] Added support for managing your social graph within Tokodon. For example if you don’t want someone to follow you anymore, or to quickly unfollow someone from your “Following” list. [24.12]

Now you can force remove your followers. Don’t worry, I’m not removing you @patchexcempt!

[Feature] Self-identified bots are now correctly identified on the profile page. [24.12]

The LWN Mastodon is now correctly marked as a bot.

[Feature] Due to limitations in the Mastodon API, we now put a button on the account page to denote there are more settings available online. [24.12]

Where to find this link in the settings.

[Feature] Changed the media tab to a grid view, making it easy to see a user’s media all at once. This works different compared to Mastodon Web as you can even filter by featured tag in this mode - but it’s not shown in this screenshot. [24.12]

Screenshot of the media tab on an artist’s account.

[Feature] Laid the initial groundwork unread notifications. You now have a number indicator in the sidebar for unread notifications, and mark them as read. [24.12]

[Feature] Added list user management, so now you can use lists to their full advantage within Tokodon itself. [24.12]

Time to categorize everything KDE-related into a nice list…

[Feature] The warning iconography for “Content Warnings” are now removed, and replaced with “Content Notice” to denote it’s true and more generic purpose. [24.12]

How “content warnings” look now.

[Feature] Added support for read markers, allowing you to continue reading where you last left off. [24.12]

[Feature] Now the authorship of links are displayed in link preview cards including a Mastodon account, if available. See this official Mastodon blog post for more details. [24.12]

How authors appear in link preview cards now.

[Feature] Added a way to view poll results before voting, finally. [24.12]

Finally, I can see it all!

[Feature] Now it’s possible to see which poll options you voted for. [24.12]

Finally, I can remember it all!

[Feature] When clicking the “ALT” button, the media description pops up. This could be useful if you want to quickly view what the media is, before unhiding it. [24.12]

[Feature] Tokodon now supports displaying admin report, severed relationship and moderation warning notifications. These notifications can then be configured in the notifications settings as per usual. The details shown in the notifications can still use a bit of work, though. [24.12]

These are test notifications, since v4.3.0 is so new I haven’t seen them yet!

[Feature] The Notifications page is redesigned, to better suit non-English languages. I also added a button to go straight to Notification settings from here. [24.12]

How the notifications page looks like, on a mobile device.

[Feature] When you’re using Tokodon on a newer and emptier Mastodon account, the application is much friendlier with more helpful explanatory text everywhere. [24.12]

No posts in your Home? No bookmarks?

[Feature] Tokodon’s UI is now more responsive. The sidebar will appear on mobile devices if their screen is wide enough, like the Android tablet I use Tokodon on. [24.12]

[Feature] Timeline streaming and read markers can be turned off, if you prefer. [24.12]

The new timeline settings.

[Feature] When viewing someone’s profile, a list of people you follow that you have in common is now shown. Hopefully this will make it easier to find new friends on Mastodon! [24.12]

Note that if you make your social graph private, you won’t show up here.

[Feature] You can now edit your profile fields within Tokodon, without having to do it through Mastodon Web. [24.12]

YES!

[Feature] You can now see trending links (or “news”) on the Explore page, and also suggested users. I’m intentionally not showing a screenshot since it doesn’t look very good yet. [24.12]

[Bugfix] The font size in the post composer now follows your preferred font setting. [24.12]

[Bugfix] Tapping a post only works by tapping on the content itself, not the margins. [24.12]

NeoChat

[Feature] You can open location links in your preferred map application. This is the same Map application under the Applications KCM, so you can choose something like OpenStreetMap or even Marble. [24.12]

Clicking this button will do it.

[Feature] The location chooser is now better in general. There’s a toolbar button to re-center the map, and if your device supports positioning then it can use that to center itself. [24.12]

Can’t show it here on my desktop, yet.

[Feature] The security page is overhauled and now contains more relevant settings from other pages. [24.12]

Hopefully NeoChat can make your experience on Matrix a more secure one.

[Feature] NeoChat’s welcome page when you first open it now looks a bit nicer. [24.12]

More settings buttons, woo!

[Bugfix] Now when you only have friend invites and no messages a better icon is displayed, instead of none at all. [24.12]

No longer blank!

[Bugfix] The buggy look of the date section header is finally fixed. [24.08.1]

Itinerary

[Feature] I added support for United Airlines reservations, so they can be imported to Itinerary and show up in KMail. Paired with Kalendar, this makes it really easy to keep track of my travel plans! I hope to add support for more North American airlines as I fly them, it’s surprisingly easy to write extractors. [24.08.1]

How a United reservation shows up in KMail now, much more useful!

Frameworks

[Feature] Added support for separator actions in ToolBarLayout in Kirigami. [6.7]

[Feature] Added command names for “Remove Spaces” and “Keep Extra Spaces” in KTextEditor, for a secret future project. [6.7]

[Feature] You can now disable the scrollbar interactivity on ScrollablePages in Kirigami. [6.8]

[Feature] Initial support for QML bindings to the KTextAddons emoticons API. This means that eventually our applications will no longer need to have their own special emoji picker, and our Unicode data will be unified! [1.6]

Libraries

[Bugfix] The caption text in applications that use the Kirigami add-ons fullscreen image viewer is now copyable. I usually write alternative text for my artwork in Tokodon first, and then copy it elsewhere. So it’s really cool to be able to do this within Tokodon itself and not have to go through Mastodon Web. [1.6]

KDE Goals

The goal I championed for, “We care about your Input” was selected! You can check it out on the goals page on the KDE website, which also includes links to our public workboard, chat and the original proposal. Let’s make KDE Plasma the perfect desktop environment for artists! (And everyone else too, I guess 😜)

Akademy

I also attended Akademy this year! You can read more about it in it’s dedicated blog post if you missed it.

The fountain, again!

It’s been almost a year since I started this series, and I can’t believe I’ve done almost a dozen of these. People seem to really like them, and I’m really appreciative of that! Like I said in the beginning, there will most likely not be a next part as it will be rolled into someone else’s blog posts now.

If you want a hint as to what I’ll be about blogging next, you might want to remember where this all began.

Saturday, 19 October 2024

I’m pretty interested in tablet stuff . Not because I think it makes senseo type long chunks of text using an on-screen keyboard, but they should make for a good drawing and painting experience. I’ve already written about the largest tablet I ever had, a 24″ Cintiq Pro and the Remarkable 2.

Today I’m going to run the gamut of the other tablets I’ve used…A living room table with five tablets around a decorated bowl holding coasters

Let’s start at eleven o’clock. That’s an iPad pro, first generation. I got it to see whether painting applications would work on it, and maybe port Krita to it. In the end, I pretty much only used it to read comics on. It’s top-heavy, the pen is top-heavy and I just didn’t like the painting applications I could get for it, like Procreate. I did create a little mock-up Qt-based painting application for testing purposes. But… I really, really hated the Apple Pencil. Like, really.  I also dislike iPadOS quite a bit.

Then, at two o’clock, the latest addition to the stable. The Remarkable Paper Pro. It’s bigger than the Remarkable 2, which isn’t necessarily a good thing. It’s supposedly the most advanced color e-ink panel there is, and there’s a front light. That makes it better than my Remarkable 2, which I now handed over to Irina, because without the front light, it’s unusable in anything but the brightest sunlight. That might just be my eyes, of course. The color, though… It’s fine for reading comics or pdf’s, if you like that seventies cheaply printed comic book look. Since the Remarkable runs its own OS, you cannot install Android apps, and since the OS changes quite a bit from version to version, third party apps ten not to work, or even brink the device, despite the device being remarkably open. (Sorry, pun intended.) The device does ooze quality, though! And the pen is great, really great.

Then, at four o’clock, there’s an Onyx Boox. It does run Android, and I wanted to see how well it would run Krita. Well, Krita runs, but the device is a bit slow. The pen is pretty nice, too, even if the cap is dinky. The color is worse than the remarkable’s one, but, again, if you’re reading counterfeit seventies Uncle Scrooge PDF’s, it’s fine. I mostly use this device to learn Hangul and read right-to-left manga. It’s too slow, and the display is too slow, for vertical scrolling manhwa.

Next, at six o’clock, the Samsung Tab S4 Android tablet that we got when we first ported Krita to Android. Despite being really old and not getting any OS updates anymore, it’s still doing fine. I mostly use it to read manga and manhwa using Nihom, and still for testing Krita. The pen is too small to be comfortable, but I only use it for testing. What’s really annoying is that every Saturday morning, I get a notification that Samsung’s legal stuff has changed — even though I don’t get any security updates.

Finally, at eight o’clock, the Frunsi Rubenstab. It’s a bit heavy, a bit small, a bit slow, but on the whole, it’s amazing. It runs Android. It’s mostly designed to be used in landscape mode. The pen is great, the display is good, the large bezels make it easy to hold and it comes with just about too much extra stuff, ranging from ant-static gloves to a brush-like implement.