Can forcing bigger font DPI make things better?

I'm pretty sure Krita devs think about when they split application out of Calligra repo and make its own copy of libs, flakes, etc. So beneficial of splitting libs in their own release plan will be for all applications. That will a huge work pretty underrated by all users.

Ok, is it clear now?

Test with qputenv(QT_ENABLE_HIGHDPI_SCALING, "1") it's especially for 5.14+

You can't run kinfocenter or what?

Application: Info Center (kinfocenter), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f4c245a2840 (LWP 318849))]

Maybe we can drop 62, but not 72.

+1

So with the patch is it drawn when it is ticked in window decoration?

Is that configurable (Window decorations -> ^ Draw separator between titlebar and a window ?

It looks like a hack knowing Qt algorithm, can we append the pid in the name? It looks like same, but if we have more than one instances?

In D25339#563822, @xuetianweng wrote:

Having different font height for every line?

I'm fine with your decision, just i don't want to be the only person accepted such a change.

Let's other members leave their opinion as well. I don't want to have surprised people by removing Flow.

I'm unsure about that, if some people still prefer using Flow will make this change superfluous. I can't make decision about this changes, if you think it should be done - i'm fine.

+1, i'm ok with that.

Can we just use queued connection, it'll avoid mutex weirdness.

I see it in line above, but using qobject_cast and not checking for nullptr is waste of time, say if you're sure in type use static_cast, if not check result of qobject_cast against nullptr.

Set QT_PLUGIN_PATH to you local path with plugin after that set the system path for others
QT_PLUGIN_PATH=/local/path:/system/path executable

Not using references is not a big problem with QString nor QUrl since they are reference counting objects, say if you don't change their content they are immutable, so

const QString s = other; // it's fine
void func(QString s)
{
     const QString o = s; // use o instead of s is also fine, using plain s is fine too, if you don't touch mutability 
     ...
}

I think add should be conditional.

@tcanabrava https://phabricator.kde.org/R319:6e8153a78e3c63e514a6ecb62f6c9b4b504e7eb7 _viewSplitter->setFocusProxy(controller->view()) is missing so that's the problem to me, not related to Dolphin code.

You can try it like that:

if (!m_editMode) {
    event->setAccepted(false);
}

or

event->setAccepted(m_editMode);

In D24755#551320, @kmaterka wrote:

In D24755#550415, @anthonyfieroni wrote:

That should be fine, in QPA we have a tray icon per sni, update menu should be on same object which will not be a problem, check it.

There are two objects in QPA that live independently:

• KDEPlatformSystemTrayIcon (QPlatformSystemTrayIcon), with KSNI instance, KSNI and KDEPlatformSystemTrayIcon are destroyed on QSystemTrayIcon->hide() and new instance (with new KSNI) is created on QSystemTrayIcon->show()
• SystemTrayMenu (QPlatformMenu) is not destroyed on QSystemTrayIcon->hide() and will be reused later on QSystemTrayIcon->show()
  
  kdeplatformsystemtrayicon.cpp#L339
  
  ` void KDEPlatformSystemTrayIcon::updateMenu(QPlatformMenu *menu) { //... if (SystemTrayMenu *ourMenu = qobject_cast<SystemTrayMenu*>(menu)) { m_sni->setContextMenu(ourMenu->menu()); } } `
  
  About you patch: I understand your idea, but it changes API contract and is not backward-compatible. Current documentation says:

The KStatusNotifierItem instance takes ownership of the menu, and will delete it upon its destruction.

This is quite clear, I want to be really careful here - I don't want to be blamed for memory leaks :) I think that we need to keep:

https://phabricator.kde.org/source/plasma-desktop/browse/master/kcms/mouse/backends/x11/x11_libinput_dummydevice.cpp$126
It should be changed also, right?
When you create a diff add a more context to it, like git diff -U100 > patch

Kirigami itself depends on 5.11 https://phabricator.kde.org/source/kirigami/browse/master/CMakeLists.txt$8 so update version to that one https://doc.qt.io/qt-5/qtquickcontrols-index.html

In D23866#535801, @svuorela wrote:

I have played a bit around with QTextBrowser, but couldn't get a working result yet.

I'm using it from 5.1 and it's great because it's not so dark, -1 from me.

In D23918#530952, @zzag wrote:

Um, I would say that's really bad code unless you use private inheritance.

You don't need virtual destructor when you don't have at least one virtual method, since you don't have at least one that method you don't want to delete object by its pointer to base. You use it to extend its functionality since that you declare objects by derived type, also you can add virtual destructor to derived class then extend with virtual methods and keep pointer to middle one. There is nothing wrong with stl containers or any other class without virtual destructor without at a virtual method.
https://onlinegdb.com/Bk9IKrc8S

In D23918#530932, @zzag wrote:

Sorry to disappoint you but that's an unwritten rule in C++ community. The main reason why one should avoid inheriting qvector or std::vector has something to do with destructors. More specifically, neither one of those container types has virtual destructor. However, you could fix that with private inheritance, which will look very ugly!

I think QTextBrowser fits better than WebEngine.

Let's commit this, it's fair small patch but it covers some unwanted crashes.

I can't test, but it should be fine.

Test plan:

That makes sense but none handle that schemes or should be responsible for that?

Fix a bunch of crashes :)

-1 to disable something without knowing the reason to not work.

It's added in D8738. Looks like a use after free issue https://phabricator.kde.org/source/kwin/browse/master/orientation_sensor.cpp$140 can be deleteLater, i think. Also DBus adaptors shouldn't be deleted, they should persist in app lifetime.

In D23389#518211, @ngraham wrote:

I can add a note for translators that this string should be kept as short as possible.

My big concern is that translated text is mainly not too big in English but in other lang. Even we change it to "Default Out" (since it has a label "Outputs").

But in settings is radio button

Why not it's a checkbox ? Make default looks big.

In D23350#516765, @ngraham wrote:

So this is a complaint that comes up a lot. I do see what you mean, and in my opinion, what we need is a dual-mode size control UI that lets you switch between "scale icons to fit in panel", "static icon size", and "n columns".

updateTimer uses slider value and it takes 200 ms to react, so you can sync the timer with keyboard one by increase the interval https://phabricator.kde.org/source/plasma-pa/browse/master/applet/contents/ui/ListItemBase.qml$198

Since we have 4 values on right / left, 0 should be the default one, no?