Plasma issueshttps://invent.kde.org/groups/plasma/-/issues2024-03-21T18:21:26Zhttps://invent.kde.org/plasma/plasma-mobile/-/issues/316homescreens/folio: Move HomeScreenState away from singleton2024-03-21T18:21:26ZDevin Linhomescreens/folio: Move HomeScreenState away from singletonCurrently [HomeScreenState](https://invent.kde.org/plasma/plasma-mobile/-/blob/master/containments/homescreens/folio/homescreenstate.h?ref_type=heads) is a singleton, which is problematic because it is shared across all screens (causing ...Currently [HomeScreenState](https://invent.kde.org/plasma/plasma-mobile/-/blob/master/containments/homescreens/folio/homescreenstate.h?ref_type=heads) is a singleton, which is problematic because it is shared across all screens (causing many issues for external screens). We can keep the models as singletons, but we should have a separate HomeScreenState per containment instance.6.1https://invent.kde.org/plasma/kscreen/-/issues/11How to deal with the increasing amount of display settings2024-03-01T16:40:54ZXaver HuglHow to deal with the increasing amount of display settingsThe KCM is slowly getting crowded as we support more display capabilities and workarounds, and I think it's worth looking into how to manage this better design wise. This is how things look on my system with !289, HDR enabled and RGB ran...The KCM is slowly getting crowded as we support more display capabilities and workarounds, and I think it's worth looking into how to manage this better design wise. This is how things look on my system with !289, HDR enabled and RGB range forcefully shown (because amdgpu doesn't support it yet):
![Screenshot_20240226_063903](/uploads/135d6d585efd540ccc914c99b2a5487f/Screenshot_20240226_063903.png)
We currently have these options, already grouped because they're a lot:
- the usual basic output stuff: enable/disable, position, mode (resolution + refresh rate), scale, rotation, mirroring
- output "priority" ("primary" screen setting in 2-monitor setups)
- variable refresh rate
- overscan (workaround for horrible displays, usually old TVs)
- rgb range (workaround for horrible displays and/or drivers, sadly not *that* uncommon)
- HDR + some settings for it, *or* color management based on ICC profiles, *or* color management based on the EDID
And the global settings
- scaling for X11 apps
- allow / disallow screen tearing
I also want to still add:
- maximum bits per color (workaround for horrible displays/cables/drivers that can make a screen randomly flicker to black or not work at all)
- a setting to reduce brightness flicker for VRR displays (also a workaround for displays)
- a page for HDR calibration / color adjustments / profiling
- a setting to make outputs "audio only" (workaround for HDMI being used for audio transfer, when it's a video cable. Check https://bugs.kde.org/show_bug.cgi?id=473685 for details)
- a setting to reduce power usage by reducing color accuracy on laptop displays
- maybe a setting for automatic brightness
- a setting for automatic whitepoint adjustment (based on ambient color sensors some laptops and phones have)
- a setting for manual whitepoint adjustment
- not a setting but still: information about how the display is connected: the actually used bpc, the physical connector type, the GPU it's connected to
One of the options for how to deal with this would be to split this into three pages:
1. the main page, with the options that a lot of people will know and be interested in: the basic stuff like position, mode, scale etc, probably variable refresh rate, and the global settings
2. a "workarounds" page, which users should only need to open if they have some problem with their display. This would contain overscan, rgb range, maximum bits per color, maybe the brightness flicker thing for VRR, the "audio only" thing. The information about the display would also be useful in here, with a button to copy it for bug reports perhaps
3. a "HDR and color management" page, for all the color related stuff (minus the "rgb range" thing)
To make the more esoteric options understandable, I'd like to have always-visible explanations directly on the page - at least for the workarounds. Something in the direction of
```
RGB Range: [automatic]
Determines whether or not the range of possible color values should be limited for this display, which is often needed with old TVs. Try changing it if colors look washed out
```
would imo be a lot better than `ContextualHelpButton`s next to every option.
What do you think? Do you have any alternatives in mind? @teams/vdghttps://invent.kde.org/plasma/plasma-pass/-/issues/5Add appstream file2024-02-25T13:23:03ZDaniel Vrátildvratil@kde.orgAdd appstream fileWithout appstream info, it won't be findable in Discover.
Make sure to release afterwards.Without appstream info, it won't be findable in Discover.
Make sure to release afterwards.Daniel Vrátildvratil@kde.orgDaniel Vrátildvratil@kde.orghttps://invent.kde.org/plasma/plasma-desktop/-/issues/117Single unified Mouse & Touchpad KCM2024-03-15T18:16:24ZJakob PetsovitsSingle unified Mouse & Touchpad KCMThe plan in https://invent.kde.org/plasma/systemsettings/-/issues/15 is to have a "Mouse & Touchpad" KCM, rather than a "Mouse & Touchpad" category. In addition to merging the existing "Mouse" and "Touchpad" KCMs, it would also absorb th...The plan in https://invent.kde.org/plasma/systemsettings/-/issues/15 is to have a "Mouse & Touchpad" KCM, rather than a "Mouse & Touchpad" category. In addition to merging the existing "Mouse" and "Touchpad" KCMs, it would also absorb the majority of the "General Behavior" KCM (which provide options that apply to both). The "Screen Edges" KCM would be a sub-page within the top-level "Mouse & Touchpad" KCM.
This would have been a ton of work pre-6.0, but with only libinput-based backends remaining as a result of #79, it's much more feasible now. Rough plan of action to make this happen:
1. Remove the now unnecessary QtWidgets middle man in `kcm_mouse` and `kcm_touchpad`, migrate both to `KQuickConfigModule` and `KCModuleData`.
* This might eventually help to enable highlighting for modified settings, but will need more changes.
* Consider expanding libkwindevices to also support mouse and touchpad properties, and switching to that for the `deviceModel` used by QML.
2. Move `kcm_mouse` into `kcm_touchpad`, or the other way round, with as few code changes as possible.
* Use `NavigationTabBar` (like in PowerDevil's KCM) to switch between mouse and touchpad settings, embed the existing QML KCMs as respective tab contents.
* Make sure to involve localization teams for string change considerations.
3. Move the appropriate settings from "General Behavior" (a.k.a. `kcm_workspace`, kcms/workspaceoptions) as a third tab (but first in tab order) into "Mouse & Trackpad".
4. Move any remaining settings out of "General Behavior" and kill that KCM.
5. Figure out how to embed "Screen Edges" (a.k.a. `kcm_kwinscreenedges`) into "Mouse & Touchpad" as a sub-page, even though it lives (for now?) in KWin.
6. Clean up code along the way where necessary. Consider renaming the KCM to e.g. `kcm_mouse_touchpad` or `kcm_pointerinput`.
MRs:
* !2067
* !2082
* !2122
* more to come6.1Jakob PetsovitsJakob Petsovitshttps://invent.kde.org/plasma/plasma-mobile/-/issues/315kded/autodetectapn: Run when SIM is swapped2024-03-21T18:21:27ZDevin Linkded/autodetectapn: Run when SIM is swappedThis isn't a high priority item because from my knowledge, we can't hotswap SIMs in any of the supported phones right now, but we eventually should have `kded/autodetectapn` run when a new SIM is detected. Currently it just runs on sessi...This isn't a high priority item because from my knowledge, we can't hotswap SIMs in any of the supported phones right now, but we eventually should have `kded/autodetectapn` run when a new SIM is detected. Currently it just runs on session launch.https://invent.kde.org/plasma/plasma-mobile/-/issues/321shell: Crashes on screen rotation2024-03-27T01:32:37ZDevin Linshell: Crashes on screen rotationUpdate: This is fixed with a hack for now https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/458
Keeping this open in order to get a proper fix.
The shell seems to crash when the screen is rotated:
```
zwlr_layer_surface_v1@7...Update: This is fixed with a hack for now https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/458
Keeping this open in order to get a proper fix.
The shell seems to crash when the screen is rotated:
```
zwlr_layer_surface_v1@74: error 1: the layer surface has a width of 0 but its anchor doesn't include the left and the right screen edge
The Wayland connection experienced a fatal error: Protocol error
QQuickItem::stackBefore: Cannot stack QQuickRectangle(..., parent=..., geometry=0,0 0x0) before QQuickPopupItem(0xffff95c01560), which must be a sibling
```6https://invent.kde.org/plasma/kwin/-/issues/207Drop Workspace::deletedRemoved2024-02-23T09:48:56ZVlad ZahorodniiDrop Workspace::deletedRemoved`Window::destroyed` should provide the same semantics.`Window::destroyed` should provide the same semantics.https://invent.kde.org/plasma/plasma-mobile/-/issues/314taskswitcher: Gestures in gesture only mode need too much "distance"2024-03-01T11:50:25ZLuis Büchitaskswitcher: Gestures in gesture only mode need too much "distance"on portrait I need to swipe up fairly far to get into the task switcher (otherwise I just go to homescreen), on landscape the gesture is almost unusable, I need to swipe almost the entire landscape height (width of the display) to get in...on portrait I need to swipe up fairly far to get into the task switcher (otherwise I just go to homescreen), on landscape the gesture is almost unusable, I need to swipe almost the entire landscape height (width of the display) to get into the task switcher.
Tested on a original pinephone on postmarketOS with plasma mobile nightly6.1https://invent.kde.org/plasma/plasma-mobile/-/issues/313taskswitcher: Gesture only mode only works after using action drawer once2024-02-23T15:31:52ZLuis Büchitaskswitcher: Gesture only mode only works after using action drawer onceAs mentioned in https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/451, the gesture only mode only works after each reboot after using the action drawer at least once. Dropping it down even in the "small" view is enough for ges...As mentioned in https://invent.kde.org/plasma/plasma-mobile/-/merge_requests/451, the gesture only mode only works after each reboot after using the action drawer at least once. Dropping it down even in the "small" view is enough for gestures to work afterwards.6.1https://invent.kde.org/plasma/kwin/-/issues/206Architecture discussion for brightness control in KWin2024-03-20T16:01:49ZAnurag ThakurArchitecture discussion for brightness control in KWinAs part of my SoK project, I am creating this issue to discuss the proposed architecture for implementing brightness control in KWin
## Current Status
The current architecture looks like this:
```mermaid
graph TB
Action -- "DBus" -->...As part of my SoK project, I am creating this issue to discuss the proposed architecture for implementing brightness control in KWin
## Current Status
The current architecture looks like this:
```mermaid
graph TB
Action -- "DBus" --> Kact
Enum -- "DBus" --> plasma-workspace/applets/brightness
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph powerdevil/daemon
Kact("KAuth Action (backlightbrightness.cpp)")
Enum("Screen Enumeration (backlighthelper_linux.cpp)")
end
```
## Proposals
There are a few different ways we could implement brightness control in KWin:
### Wayland only (1)
If X11 support can be dropped, we could move the brightness handling code to kwin completely. the architecture could look like this:
```mermaid
graph TB
Action -- "DBus/Wayland API" --> HDR
Enum -- "DBus/Wayland API" --> plasma-workspace/applets/brightness
HDR --> Kact
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph kwin/new_code
HDR("HDR handling")
Kact("KAuth/logind/sysfs call")
Enum("Screen Enumeration")
end
```
#### Benefits
- Simple architecture
- No code duplication
#### Drawbacks
- No X11 support
- More code changes required
### Wayland + X11 (2)
If X11 support needs to be retained, we need to support the scenario where a different window manager is used, so brightness control can't depend on KWin. Xaver proposed that we use the existing backlight helper from powerdevil and use a new wayland protocol for communication between kwin and powerdevil as DBus may not be responsive enough.
The architecture could look like this:
```mermaid
graph TB
Action -- "DBus" --> Kact
Enum -- "DBus" --> plasma-workspace/applets/brightness
Kact -- "Yes\n\nWayland Protocol" --> HDR
Kact -- "No (X11)" --> X11
HDR -- "Wayland Protocol" --> Help
subgraph plasma-workspace/applets/brightness
Action[User Action]
end
subgraph powerdevil/daemon
Kact{"Kwin present?"}
Enum("Screen Enumeration (backlighthelper_linux.cpp)")
X11("Existing code")
Help("Backlight Helper")
end
subgraph Kwin
HDR("HDR etc. handling")
end
```
#### Benefits
- Less code changes required
- Support for X11 retained
#### Drawbacks
- Complicated architecture
- Possible performance penalty
### Wayland + X11 (3)
Alternatively, KWin can provide the DBus interface for the brightness applet on wayland and powerdevil can continue to provide it on X11.
```mermaid
graph TB
Action -- "DBus" --> Chk
Chk -- "Wayland" --> Kwin
Chk -- "X11" --> Control
Kwin --> ncnt
Enum -- "DBus (X11)" --> plasma-workspace/applets/brightness
Enum2 -- "DBus (Wayland)" --> plasma-workspace/applets/brightness
subgraph plasma-workspace/applets/brightness
Action[User Action]
Chk{"Session Type"}
end
subgraph kwin
Kwin("DBus API provider")
ncnt("HDR handling + backlight control")
Enum2("Screen Enumeration")
end
subgraph powerdevil
Control("Existing control")
Enum("Screen Enumeration")
end
```
#### Benefits
- Basically (1) with X11 support retained
- Kwin code can be improved independently of powerdevil and X11
- Later if X11 support is dropped, it would become the same as (1)
#### Drawbacks
- Slight code duplication
- More code changes required
Please share your insights and mention if I missed/misunderstood anything.https://invent.kde.org/plasma/plasma-workspace/-/issues/117Follow-up from "[kcms/users] Fix sizing in fingerprint dialog"2024-02-20T23:11:26ZNate GrahamFollow-up from "[kcms/users] Fix sizing in fingerprint dialog"The following discussion from !3928 should be addressed:
- [ ] @ngraham started a [discussion](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3928#note_875971): (+4 comments)
> Since internally this component has ...The following discussion from !3928 should be addressed:
- [ ] @ngraham started a [discussion](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3928#note_875971): (+4 comments)
> Since internally this component has an icon that could benefit from being displayed at a standard size, I'm not convinced about these hardcoded implicit sizes set here. I'd prefer for the component to internally set an implicit size that's based on the size of the icon, plus the size of the progress circle, plus optionally any needed exterior padding.6Nicolas FellaNicolas Fellahttps://invent.kde.org/plasma/kwin/-/issues/205Drop support of modifier-only shortcuts and migrate config2024-03-28T16:14:47ZYifan ZhuDrop support of modifier-only shortcuts and migrate configSupport of modifier-only shortcuts in being implemented in kglobalacceld in
- https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44
- https://invent.kde.org/plasma/kwin/-/merge_requests/5251
- https://invent.kde.org/frameworks...Support of modifier-only shortcuts in being implemented in kglobalacceld in
- https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44
- https://invent.kde.org/plasma/kwin/-/merge_requests/5251
- https://invent.kde.org/frameworks/kguiaddons/-/merge_requests/115
- https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/148
So we should consider
- [ ] dropping that functionality from kwin and moving it where it better belongs (https://invent.kde.org/plasma/kwin/-/merge_requests/5268)
- [ ] and migrating all existing modifier-only shortcuts
~~Note: https://invent.kde.org/plasma/kglobalacceld/-/merge_requests/44 doesn't work on X11 yet, I will need to look into that.~~ Everything should be working!
BUG: 371560
Related by technically independent: turning on multi-key shortcuts by default in
- https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/105
- https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/20606.1Yifan ZhuYifan Zhuhttps://invent.kde.org/plasma/plasma-mobile/-/issues/309mmplugin: Deduplicate code from kcms/cellularnetwork2024-02-12T20:02:12ZDevin Linmmplugin: Deduplicate code from kcms/cellularnetworkThere is a lot of shared code, let's de-duplicate it
https://invent.kde.org/plasma/plasma-mobile/-/blob/master/components/mmplugin/signalindicator.cpp
https://invent.kde.org/plasma/plasma-mobile/-/blob/master/kcms/cellularnetwork/modem...There is a lot of shared code, let's de-duplicate it
https://invent.kde.org/plasma/plasma-mobile/-/blob/master/components/mmplugin/signalindicator.cpp
https://invent.kde.org/plasma/plasma-mobile/-/blob/master/kcms/cellularnetwork/modem.cpphttps://invent.kde.org/plasma/plasma-workspace/-/issues/115RFC: replace "icon spacing" settings in Icon Task Manager and System Tray wit...2024-02-17T19:51:04ZJin Lium.liu.jin@gmail.comRFC: replace "icon spacing" settings in Icon Task Manager and System Tray with a panel-level "density" settingThe main problem with the current setting: in the default panel (as in the screenshot in https://kde.org), the user would perceive Kickoff and Icon Task Manager as a single row of icons, instead of two applets. But if the user change the...The main problem with the current setting: in the default panel (as in the screenshot in https://kde.org), the user would perceive Kickoff and Icon Task Manager as a single row of icons, instead of two applets. But if the user change the icon spacing setting, the spacing between the Kickoff icon and the rest of icons becomes uneven.
So I propose lifting the setting up into the panel config dialog. All applets in the panel should set their margin according to the panel setting (supposedly implemented in some common code). And containers like Task Manager and System Tray should also set their internal margins.
Moreover, when the panel is full, it could reduce the density (just like Task Manager currently does), so all applets shrink simultaneously. Thus, while the user-facing "density" setting probably has only three options, e.g. Compact, Normal, Spacious, the actual setting passed to applets should be in px.https://invent.kde.org/plasma/krdp/-/issues/15Needs porting to FreeRDP 3.x2024-02-09T12:04:48ZNeal GompaNeeds porting to FreeRDP 3.xI had assumed based on 4ff283a7afdcf4fed67450aeb1739463f4a59488 that KRdp builds with FreeRDP 3, but that is apparently not the case currently.
Fedora is switching to FreeRDP 3 for Fedora 40, but it currently fails to build with [my com...I had assumed based on 4ff283a7afdcf4fed67450aeb1739463f4a59488 that KRdp builds with FreeRDP 3, but that is apparently not the case currently.
Fedora is switching to FreeRDP 3 for Fedora 40, but it currently fails to build with [my commit](https://invent.kde.org/ngompa/krdp/-/commit/2ac6b00d376c9f15fedca71b0268c6d33fe9bc92) to bump to FreeRDP 3.
Here's a full build log from the Fedora Rawhide package build: [80f8d261.txt](/uploads/d7b25c343ffa370901c0badf4885ff6f/80f8d261.txt)https://invent.kde.org/plasma/kwin/-/issues/202Requirements for dropping Xorg support2024-03-19T18:01:32ZXaver HuglRequirements for dropping Xorg supportWith #139 we won't be as restricted by Xorg anymore - both architecturally and in terms of bugfixes for Xwayland triggering regressions on Xorg (like with https://invent.kde.org/plasma/kwin/-/commit/3a28c02f287f4acdde77508aa716ca01a3be75...With #139 we won't be as restricted by Xorg anymore - both architecturally and in terms of bugfixes for Xwayland triggering regressions on Xorg (like with https://invent.kde.org/plasma/kwin/-/commit/3a28c02f287f4acdde77508aa716ca01a3be7514) - but we'll still have to maintain kwin_x11, and keep the APIs shared with kwin_wayland in sync, like effects and scripts (or force them to support only one or the other). This will likely work out okay for a while, but doing it forever is not great.
As a way out of that, at some point in the future we will completely freeze kwin_x11, and eventually drop it entirely. This issue serves as a list of user facing problems that at least kind of work on Xorg and need be taken care of before that can happen:
- [ ] explicit sync for NVidia: !4693, [xserver!967](https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/967), [wayland-protocols!90](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90)
- [ ] old NVidia GPUs on legacy driver branches that don't support gbm:
- [ ] With driver version 470, we can at least start a working session by using dumb buffers and CPU rendering. Maybe show some warning that the driver isn't supported anymore, and that the user should switch to Nouveau?
- [ ] For even older stuff, we can't show anything in a Wayland session - SDDM probably needs to keep a fallback to Xorg for a while, and warn the user about the incompatibilities there
- [ ] plasmashell could still support Xorg with other WMs
- [ ] screen sharing for Xwayland apps: Xwayland video bridge should be shipped by default in distros, and possibly integrated into Plasma directly
- [ ] the upstream color management protocol needs to implemented (not just a snapshot like https://invent.kde.org/plasma/kwin/-/merge_requests/5060), and at least some of the more common apps relying on color management should be ported to use it
- [ ] accessibility. Don't know exactly what's still missing, please add sub-items here as appropriate!
- [ ] task automation (which has overlap with accessibility). At least the common stuff should imo be covered, like triggering key sequences with a keyboard shortcut. There's some existing stuff for this too:
- [ ] KWin scripts for this exist. I don't know if any are sufficient though
- [ ] ydotool exists as well, but it requires root access
- [ ] many things can be done through AT-SPI2
- [ ] support for libei / input leap
- [ ] session restoration
- [ ] (good) unattended remote desktop solutionhttps://invent.kde.org/plasma/plasma-mobile/-/issues/307taskswitcher: KWin effects seem to be extremely slow on the pinephone2024-03-16T17:19:29ZDevin Lintaskswitcher: KWin effects seem to be extremely slow on the pinephoneThe task switcher is considerably slower than other parts of the shell on the Pinephone (~5fps). I suspect that it's related to how it's a KWin effect.The task switcher is considerably slower than other parts of the shell on the Pinephone (~5fps). I suspect that it's related to how it's a KWin effect.6https://invent.kde.org/plasma/plasma-mobile/-/issues/305quicksettings: Holding to open settings app doesn't show app launch screen2024-02-07T03:50:15ZDevin Linquicksettings: Holding to open settings app doesn't show app launch screen6https://invent.kde.org/plasma/plasma-mobile/-/issues/303No indication of currently active calls2024-02-11T16:07:08ZBart RibbersNo indication of currently active callsWhen a call is ongoing, there is no indication for it at all. So you can pick up, but there is no way to see who is calling while it's active or to hang up.When a call is ongoing, there is no indication for it at all. So you can pick up, but there is no way to see who is calling while it's active or to hang up.https://invent.kde.org/plasma/plasma-desktop/-/issues/116How to deal with margins around applets2024-03-26T07:57:50ZNiccolò VenerandiHow to deal with margins around appletsHere's a fun choice: should applets themselves have the responsibility to draw margins around them, or should their container do that?
There are a couple of places where this issue arises. Firstly, we have the panel; if we draw the back...Here's a fun choice: should applets themselves have the responsibility to draw margins around them, or should their container do that?
There are a couple of places where this issue arises. Firstly, we have the panel; if we draw the background of all applets "lightcoral", we can easily see that _most_ applets draw _some_ margin around them, though we still have the panel draw some margin between the applets themselves:
![Screenshot_20240127_192614](/uploads/89a5ce57cbdd2239ae6f1bf3adab22da/Screenshot_20240127_192614.png)
This can, IMO, create some issues. As an example, a nice idea would be for icons-only applets to have exactly a 1:1 aspect ratio (they currently don't); however, if we do that, the additional margin provided by the panel will be quite unnecessary (and, actually, might even feel excessive). However, if we allow applets to define the external margin themselves with little to no help from the panel, there's no way for themes to actually customize the density of the elements.
We have a similar problem with applets in dialogs. The theme will define an external margin to be used between the border of the dialog and the inner items. Usually, that amount is very small, and as a result, all applets will add some extra margin themselves. This causes some inconsistencies between applets (applying different amounts of margins) and makes it impossible for themes to have dialogs with no margins whatsoever (should they even be allowed to? I say yes, because why not).
---
My personal take, after a bit of time and thought, is that we should always explicitly ask applets (both compact and full representations) to _always_ touch the external borders; if they set a certain size, they should always use all of it. This gives complete control of the external margin to the containment, which I feel is the easiest way to get both consistency and customization. This will require a bit of work on our own applets (I can do that) and asking for compliance from third-party applets (now is the best time to do that).
There are some scenarios where the applet reasonably can't actually touch the borders. As an example, all icons (for some reason which I'll never accept!) come with a margin built in directly in the SVG. _In a utopia_ I would make all SVGs touch the external borders, but we can't feasibly implement this. _Ideally_ we could read the actual size of the SVG element inside the file and base the size of the applet on that. Worst case scenario, we allow that SVG-icon margin to mess a bit with our design (as it does now, really). Buttons and other elements also come with built-in margin, but I'd say that's fine, since it actually gets used to e.g. display highlights and such.Niccolò VenerandiNiccolò Venerandi