• i18nd

• add own context for the internal qml files

In D29706#669968, @davidedmundson wrote:

Who extracts and loads the translations for:

./ConfigAppearance.qml
./ConfigSensors.qml
./FaceDetailsConfig.qml
./UsedSensorsView.qml

in the top level of faces but not in an individual package.

• adress feedbacks

Sorry, i don't think it's the right path, for several reasons,

• The spinbox look is different from the desktop one, better or worse is secondary, but it's actually a sore point of the plasma theme at the moment :/
• It exposes very directly pixel numbers in the ui, unless it's a graphic application, i hate when it happens in an ui and in our software happens too much (and no, no user should ever be asked to know what a pixel is)
• it keeps the window still when the panel resizes, looking kinda broken, but worse, making even possible for the panel to cover up the spinbox itself

-1 :(

What Nate says, after that go for it

the different Units.qml depend from the style, QT_QUICK_CONTROLS_STYLE
all of them, including those in plasma-framework should be updated at once

• Merge branch 'sensors_lib' into mart/sensor_face

• Merge branch 'master' into mart/mewSystemMonitor

• infocenter modules in own category

• use kinfocenter for kinfocenter modules

• sensorColors is now a map
• fix preset uninstall

works perfectly :)

• adapt to api changes

• use QJsonArrays for sensors

• remove extra debug

• make disk usage a bar chart

• use regexp for multiple sensors
• left-alignlegends when they are too wide

• add space

• Controls QQC2

• adapt to api changes
• move faces config in own file

• move face properties in own file
• move face config in own file

• default to linechart
• default to textonly
• sensorIds highPrioritySensorIds
• kill table visualization
• TotalSensor->TotalSensors list
• SupportsTotalSensor->SupportsTotalSensors

In T10034#229260, @davidhurka wrote:

May I add a question here, a bit offtopic? It appeared to me that there is a general trend towards QtQuick because a) it looks great and b) tends to be touch and mobile friendly. While I disagree with a, I wonder whether an inherently complex UI like that of FreeCad would benefit from b. KXmlGui is great for customizing the toolbars and QDockWidgets are nice to rearrange the UI components on the screen. While I have nothing to say about the technical implemenation, would/could these features (which FreeCAD already has) be kept with QtQuick?

In T10034#229083, @kkremitzki wrote:

To cut to the chase, it seems like a technological leapfrogging would be possible by making a proof-of-concept Kirigami-based FreeCAD UI, and once it's been shown to be possible, the rest should follow. I think the "sell" to our community of leaning on KDE for UI/UX expertise and letting CAD programmers work on CAD instead should be pretty easy and outweigh possible packaging pain.

• start to port other faces
• port faces to new api
• add missing file
• adapt to api changes
• adress a part of comments

i think i would prefer a somewhat inaccurate message, rather than an obscuretecnicism which is technically accurate (

note that there is a whole rewrite pending for all systemmonitor applets in D28487 (and several related diffs)

unfortunately yeah, i had to port away from opacityanimator several places for this reason :(

In D29366#661956, @filipf wrote:

Ok, so the message can indeed still be turned on.

Setting:
~/.config/plasmarc [General] immutability=2 (or 4)

... does not work, however the following does:

~/.config/kdeglobals [KDE Action Restrictions][$i] plasma/plasmashell/unlockedDesktop=false

Which means that if widget locking now only exists as a restriction... perhaps it would make more sense to change the text of this inline message to say "Layout changes have been restricted by the system administrator"?

yeah, +1 for that

indeed, a bit more documentation then go for it