How exactly I can test if something works? And what are the requirements? PipeWire? Something else?
Or is this only for code review for now?

http://doc.qt.io/qt-5/deployment-android.html at the bottom of the page there is an example of usage scenario for qmake project:

Compiles, works. Tested over network from another PC, IPv4. Which VNC client supports IPv6..?

In D12698#259554, @zzag wrote:

Also, there is Firefox Nightly, which has its own icon too.

In D12476#258427, @roberts wrote:

It will fail gracefully, it checks for the presence of these /proc or /sys files and only acts if they exist. This code is only called if an EGL context is successfully created in any case, and in fact on Wayland rendering _is_ always direct.

Yeah, after reading about wayland more, I think so, it always uses DRM to render.

I'm not completely sure that IsDirect should be manually set to true in wayland code path (it looks like a hack just to test).
What happens if IsDirect is set to true, but software rendering is active? Will get_dri_device() fail gracefully or something horrible will happen? :)

In D12679#257717, @davidedmundson wrote:

I give them a KCM where they can easily toggle it back. That's only really useful after they've fixed their real problem, but I don't think we can really help with that.

Should this notifier provide some tip for user on how to go back to hardware rendering? Or is it not relevant here?

I've tested this and it seems to work!

Stupid question, what happens if dolphin is not installed?

I tested this, and it looks cool and works fine!

Just curious, why is this needed? To avoid dynamic memory allocations?

New version looks much better, no doubt. The only thing you may be asked about here is magical number 120, what is it? Some minimum width for item?

+1, looks better

On wayland, without this patch with OpenGL 3.2 version requested, it fails with error:

Could not get requested OpenGL profile, requested QSurfaceFormat::OpenGLContextProfile(CoreProfile) got QSurfaceFormat::OpenGLContextProfile(NoProfile)
Could not get requested OpenGL profile, requested QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile) got QSurfaceFormat::OpenGLContextProfile(NoProfile)

In D11758#240679, @graesslin wrote:

Could you please backport to Plasma/5.12 branch?

In D11758#240148, @cfeck wrote:

Is https://bugs.kde.org/show_bug.cgi?id=392716 related or even fixed with this commit?

• Move extra debug output under isDebugEnabled() block

Code looks fine, but I did not test if it actually works. ;)

I looked into Qt sources (QtWayland specifically), and found out that Qt uses similar approach - it loops over received configs and chooses the one that matches user's requested bit depths, if they were specified.
bool QEglConfigChooser::filterConfig(EGLConfig config) const
which is used from QWaylandGLContext class during context creation.

• Use camelCase; merge two "if" statements.

And now I'm reading news about mesa-18 new 10-bit color feature and realizing that maybe mesa-18 was my initial problem :)

Some prehistory for this: recently I finally got a new video card, based on AMD RX 560 specifically to test Plasma on Wayland, and was very disappointed by the fact that kwin_wayland falls back to QPainter compositing.
On my 4k screen this compositing type can be very laggy.
I use amdgpu opensource driver and mesa-18 from git, also xf86-video-amdgpu-18.0.1.

While I'm here and still remember some things that I don't like here - naming:

Regarding this - I don't know if it is really chinese look foreign enough to me anyway.
Some lines of text in your test script surely look like Japanese Hiragana to me, especially this one (and tests related to this)

echo "otto东到宛平路anna"> "終末なにしてますか？忙しいですか？救ってもらっていいですか？ EP01 太阳の倾いたこの世界で -broken chronograph-.txt"

Google translate confirms :)
But do your ranges include that characters? This answer on stackoverflow says that there are also other ranges for Hiragana, Katakana, etc... as @cfeck already said. Does it pass the test for you?

In D10829#213553, @michaelh wrote:

That's great. Any clues to solve this?

[ 35%] Building CXX object src/file/extractor/autotests/CMakeFiles/extractorIOTest.dir/__/iohandler.cpp.o
[ 35%] Linking CXX executable ../../../../bin/extractorIOTest
CMakeFiles/extractorIOTest.dir/__/iohandler.cpp.o: In function `Baloo::IOHandler::nextId()':
/home/super/devel/kde/src/frameworks/baloo-flex/src/file/extractor/iohandler.cpp:46: undefined reference to `Baloo::DocumentId::DocumentId(unsigned long long)'
/home/super/devel/kde/src/frameworks/baloo-flex/src/file/extractor/iohandler.cpp:49: undefined reference to `Baloo::DocumentId::operator unsigned long long() const'
collect2: error: ld returned 1 exit status

I know cmake only a very little bit and baloo seems very complicated an that respect.

To solve this warning you need to fix DocumentId class, add operator<<() for QDebug.

This gives a bunch of warnings like

src/engine/idutils.h:48:43: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
    return *(reinterpret-cast<DocId*>(arr));

Were these before...?

Maybe such kinds of changes can be committed without review? ;)

Maybe when a new vault is configured, it should add itself to baloo exceptions.
Is there any DBus call to baloo to do that?

There is also https://techbase.kde.org/Policies/Frameworks_Coding_Style. Guess I was wrong about #includes order, but honestly I've never seen commas at the start of the line.

Looks almost fine, just fix these:

Can you add simple instructions how to reproduce full testing scenario?

I use transparency while moving windows all the time, and would like to keep this feature.

In D10289#201864, @rkflx wrote:

@alexeymin Any tips on how to align the button properly?

quit() and exit(0) do the same thing - they all stop event loop, caused by QCoreApplication::exec(). See - https://code.woboq.org/qt5/qtbase/src/corelib/kernel/qcoreapplication.cpp.html#_ZN16QCoreApplication4quitEv

Patch applies, compiles, spectacle works.

In D10326#201699, @anemeth wrote:

While it is hidden we could adjust the window size to the captured image aspect ratio.
What do you think?

Maybe commit first part ( D10283 ) and continue from master? ;)

Hm yeah, attempt to use primary screen's geometry is probably fine, reverting to default size if something goes wrong.

In D10326#201584, @ngraham wrote:

introspect the user's screen aspect ratio

Yeah, agree, Copy to clipboard button should stay visible; if you hide or remove it, copy screenshot to clipboard automatically, righ after shot was taken or after modifications to image (annotate) like windows built-in SnippingTool does.

I've tested, confirming, works as described. I think removing extra buttons makes sense. Still can quit by pressing Esc :)

I also tested and it seems to work as described. Is there additional work planned?

+1 very positive! There should be as many default places as possible, scrollbars are not awful; at least Desktop, Documents, Downloads, Pictures, Music fit perfectly fine. User can easily remove unneeded entries (it's easier to remove than to add I think)
And collapsible headers would be very cool.

There was a similar fix commited somewhere (don't remember, in KIO?) related to QFile in newer Qt complaining about empty filenames passed, so this is probably fine too...

https://api.kde.org/frameworks/index.html says:

Tier 1 frameworks depend only on Qt (and possibly a small number of other third-party libraries), so can easily be used by any Qt-based project.

I don't spot any obvious problems in QML any more. And I like newer version more than previous...

"After" definitely looks better :)

Well, I tested it again, tried resizing yakuake window, closing random tabs, etc and everything is drawn OK and works fine. I think Eike @hein shoud say his final word.

Well, to me code looks good (except toStdString()), I don't see anything more. And at least it works (I'll try to use this build of yakuake for a few days to test).
What about other skins, btw?

Yes, now it's OK. I see arrows. No libpng errors. And tabs, switching are working as expected.

I tried once more; literally fresh checkout of yakuake.git, arc patch D7727, re-run cmake, make, make install, /usr/bin/yakuake and I see this:

In D9094#174235, @elvisangelaccio wrote:

on Windows we don't have dbus

So it resulted in something like aspell.dll requiring aspell.dll?
What is the simplest/fastest way to test this?

Which repository is it...?
For me it looks fine on the latest screenshots, combobox is less convenient.

I tested the latest change and it does not work for me, no icons, no buttons, .. :(

but why? :)

In D7725#147934, @kossebau wrote:

Thanks for the offer, @alexeymin:

Test plans:

Export screenshot image to Gwenview (or other app) via menu:

1. Take screenshot
2. Export Image... > Gwenview
3. Check file name shown in application Expected: Matching the filename pattern defined in the settings
   
   Drag and drop screenshot image to Dolphin (or other app):
4. Take screenshot
5. Open Dolphin, create a new directory and show it
6. Use mouse and drag the screenshot image into the directory in Dolphin
7. Check file name used for the created file Expected: Matching the filename pattern defined in the settings
   
   Drag and drop multiple screenshots to Dolphin (or other app):
8. Edit filename pattern settings to something without variables (so the same name would be used for every screenshot during testing)
9. Open Dolphin, create a new directory and show it
10. Take screenshot
11. Use mouse and drag the screenshot image into the directory in Dolphin
12. Take another screenshot
13. Use mouse and drag the screenshot image into the directory in Dolphin Expected: No filename conflicts.

If there was a test plan, I could at least try to apply this on my system and verify it works... How exactly the filename should change?

Nnnope, patch fails to apply for me, on current dolphin master. 😆 https://paste.kde.org/ppx1r8xxl

I can test this a bit later today to verify.

Is this resolved after https://mail.kde.org/pipermail/release-team/2017-September/010596.html ?

In D7813#146280, @hein wrote:

I.e. this keeps the interface unchanged because the parameter-passing to the old method didn't actually work, or what is the idea here?

Works with the same D-Bus interface as before; and no more warnings about unregistered types. Looks good...