Arch Linux User Repository

Arch Linux is about keeping it simple so not putting any extra effort into reducing the dependency list would actually be kind of in-line with that :-)

I'll take a look, but as I said, this stuff is figured out by my deployment script which finds which libraries are used by the application and it then runs through that list finding out which package contains that library, I think to stop this listing every dependency I'd have to manually create "blacklists" of libraries unless there's some other way of doing it.

I don't want to end up in a situation where I'm spending an inordinate amount of time figuring out what dependencies I should or shouldn't list, if you can suggest any automated way of doing it I'm more than happy to accept PR's!

Generally it would be preferable to list only direct dependencies, though. E.g. libraries like libx11 are likely not necessary when using Wayland (unless the application really uses them directly). Or whether icu is required likely depends only on whether Qt is configured to use it (unless the application really uses it directly).

These parts were in the email notification I got, but I think you've removed them subsequently.

Some of the context/drop-down menus are misplaced under Wayland. I found

Don't get me started on <insert X renderer/window manager/x system>! :p

Yeah, it's pretty tricky, I've found that different window managers or compositors can have a vastly different way of rendering. I've tried really hard on all ports to make the application look like "native" (well, it uses ribbon bars, but they don't look out of place on any of the ports IMHO), but once you end up on Linux that task becomes incredibility difficult.

Specifically, trying to handle light/dark mode is an utter nightmare, there's code in the application which tries to detect if GTK is being used and then figure out if it's dark or light, it then falls back to testing whether the background it darker than the foreground for text as another check, that's before we even get to the point of "faking" light/dark mode on the OS so that the user can force it into one or the other.

Then there's the Qt factor, the different platforms all need platform-specific tweaks to move stuff around, a pixel here, a pixel there, you don't want to know how much time I've spent looking at various GUI objects zoomed in to get the best-looking result on that platform, it's hard work, Qt gives a good base to work from, but you really have to put a lot of extra effort in to get something that doesn't look out of place.

Otherwise the app looks quite fancy, so thanks for developing it. (From your nickname I assume you're the author.)

I am indeed, no worries. I have quite a few changes I'm working on and I was hoping to get these out a couple of weeks back, but I've been unwell so haven't got around to finishing them up.

Once those are out of the door I'm going to back to replace the QCustomPlot library I use for graphing, it's a very powerful library, but my graphing needs are fairly simple. The problem with the library is that it's a memory guzzler, a MASSIVE memory guzzler, this becomes apparent when running a trace for an extended period of time. I ran a test a week or so back where I left the windows port running for a couple of days without adding the results to the graphs (everything else was functional), the application under windows started on about 92MB of RAM, and a couple of days later when I went to check, it had actually released some and was down into the '80s. Try that with the graphing running and you'll see gigabytes being used.

The code I'm currently working on has revolved around the ribbon bar, I've added a clipboard group and am just in the process of providing the ability to copy an Image/PDF/text of the current data to the clipboard so that a snapshot of an issue can be generated to post elsewhere, it's particularly useful with the built-in host masking because it will automatically obfuscate any sensitive details that would otherwise appear in a screen capture.

I really appreciate your suggestions and feedback, I wrote the app for myself so it's been very much tailored to what I needed it to do, but I'm pushing on with expanding its capabilities, I have no idea if you've looked at the source (I assume you have because you knew it was a Qt application) but it's very modular and expanding it is fairly easy.

I suspect it would be more work not to list them all explicitly.

Arch Linux is about keeping it simple so not putting any extra effort into reducing the dependency list would actually be kind of in-line with that :-)

Generally it would be preferable to list only direct dependencies, though. E.g. libraries like libx11 are likely not necessary when using Wayland (unless the application really uses them directly). Or whether icu is required likely depends only on whether Qt is configured to use it (unless the application really uses it directly).

I'll take a look at the MAKEFLAGS stuff and see what I can do.

You actually just need to remove any extra flags which are currently present within the PKGBUILD and add the flags you want to build with to /etc/makepkg.conf in your build environment.

By the way,

• Some of the context/drop-down menus are misplaces under Wayland. I found https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes helpful for "porting" my Qt apps to Wayland. Possibly this is also a Qt bug, though.
• Otherwise the app looks quite fancy, so thanks for developing it. (From your nickname I assume you're the author.)

Hi,

Thanks for the feedback.

The dependencies are discovered automatically by my build & deployment scripts (triggered in my CI/CD system because maintaining this stuff by hand across multiple distributions is a nightmare), I suspect it would be more work not to list them all explicitly.

The whole process is automated as much as possible to try to prevent mistakes and to make it so that it doesn't take hours of blood, sweat and tears getting packages ready for distribution.

I'm not an arch user, so I'm making wild stabs in the dark here with packaging for arch, it's feedback like this that helps me fix stuff that isn't right. I'll take a look at the MAKEFLAGS stuff and see what I can do.

Thanks.

You don't need to list all of these dependencies explicitly, see https://wiki.archlinux.org/title/PKGBUILD#depends. It would also be better to avoid using nproc and rather stick to the MAKEFLAGS specified in /etc/makepkg.conf (which are picked-up automatically).

perfect

Sorry, please try again. I just built it on arch to double check.

:-(
==> Download dei sorgenti in corso...
-> Download di ${pkgname}-${pkgver}.tar.gz in corso...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0
curl: (22) The requested URL returned error: 404zbr> ==> ERRORE: Impossibile scaricare https://www.nedrysoft.com/downloads/${pkgname}/source/${pkgname}-${pkgver}.tar.gz
L'operazione sta per essere interrotta...

fixed. Thank you for reporting.

==> ERRORE: Impossibile scaricare https://www.nedryspft.com/downloads/${pkgname}/source/${pkgname}-${pkgver}.tar.gz