Stable was the plan, yes.

• do however init the stat struct, its members are not initialized otherwise
• streamline get_dri_device return
• do not init l3 to nullptr inside the info loop. l3 is the entry for the infos, so simply leave it as-is (nullptr initially, preceding entry after that)
• also sort infos by their device id. it'd be weird to have a list of card2 then 1 then 0

Competes with D27902
While this diff runs the risk of not being able to resolve 100% of the time (sans ip address fallback in listDir) it has the huge advantage that discovery isn't getting super slow when multiple wsd hosts are found and consequently need costly host resolution performed. So, I like this diff muuuuch better.

In D28479#639376, @dantti wrote:

LGTM, is the new function available since old CUPS versions? Just to make sure it won't break usage with old versions.

Oh and FWIW, this fixes build problems on debian where -Werror=format-security is set by default (and consequently tripping over format strings without arguments).

I take it the library isn't actually api-stable? So we could also change that function name, it should really be assembleUri given the arguments.

You know, I may have noticed this when working on kinfocenter and then quickly forgotten about it again 😂
Good stuff!

This is since fixed and supposedly pause and unpause no longer leave paused pipelines around, which is all we needed from this anyway.

Mind the comment about the +2 please.

https://github.com/pangea-project/pangea-tooling/commit/8ff2aa91db3640d3a8eb3eff6bf3781fd40f0254

In D28161#634951, @ahmadsamir wrote:

Please don't touch kdsoap-ws-discovery-client though. It's not maintained here -> https://gitlab.com/caspermeijn/kdsoap-ws-discovery-client

That's confusing; but OK, I'll revert that part of the diff.

Looks good to me, not that this means much with regular expressions. The lack of tests on this stuff makes me sad :((

I've actually had a better idea! Well kinda and it may be trickier to do.

I love it!

In D28276#634264, @broulik wrote:

This is because the device monitor emits all devices, not the query returning unwanted devices?

.

Any opinions on landing this for 20.04 still? It is technically a bugfix. It is also practically a whole lot of risky code, making me rather uneasy about putting it in past beta.

About fixing the UX:
There is some kind of preview tech in milou which you can take a look at and maybe build upon.
The line space is just never going to be enough for a text only representation of a dict entry, plus it looks fairly forced anyway. So, my thinking is that ideally we'll want a minimal text display but then be able to expand that with a rich "preview" of the dict entry for the clients where we need that (notably krunner I suppose). Rich in this case means having full on control over how it is displayed using a bespoke QML item. This could work a lot like clipboard entries do, where each entry can have multiple mimetypes, one of them ought to be text which is kind of the go-to fallback, but they others may give a richer experience when the client supports it. Matches could behave much the same way, and from a glance at the existing milou code that is kind of where things were headed.

Mh. Not quite what I had in mind but I suppose it makes sense this way.
I think we need a test case for the highlighter though :| It totally blows up in my face when I trace a running dolphin because toskip isn't quite right.

Neon/unstable I guess

I guess a localized number would be one with a thousand separator? 😆

Please also add test cases for the regressions Kai highlighted. Thanks!

Quick recap from what we talked about on telegram: putting the print after the bt is most definitely going to throw off the backtrace parsing logic, so doing it this way would require extensive changes there, which is a dangerous place to make extensive changes.
Or we could define a simple function to ignore errors https://stackoverflow.com/questions/17923865/gdb-stops-in-a-command-file-if-there-is-an-error-how-to-continue-despite-the-er but that's also a bit faffy.
Another completely standalone approach would be to change BacktraceGenerator (I think?) to invoke the print in a completely independent gdb invocation i.e. separate the print call from the regular batchcommands and have drkonqi assemble it back into the final report. That way the actual tracing batch command couldn't fail on the print.

D28026

• isValid is const now
• use qdiriterator
• use QFile::encodeName for the stat call

@dvratil ping? :(