Package Details: sdrtrunk-bin 0.6.1-1

Git Clone URL: https://aur.archlinux.org/sdrtrunk-bin.git (read-only, click to copy)
Package Base: sdrtrunk-bin
Description: A cross-platform java application for decoding, monitoring, recording and streaming trunked mobile and related radio protocols using SDR
Upstream URL: https://github.com/DSheirer/sdrtrunk
Licenses: GPL3
Conflicts: sdrtrunk, sdrtrunk-bin, sdrtrunk-git
Provides: sdrtrunk
Submitter: k4yt3x
Maintainer: k4yt3x
Last Packager: k4yt3x
Votes: 2
Popularity: 0.030100
First Submitted: 2023-03-08 05:06 (UTC)
Last Updated: 2024-12-06 23:03 (UTC)

Latest Comments

drws commented on 2023-08-19 08:44 (UTC) (edited on 2023-08-19 08:45 (UTC) by drws)

Science is unfortunately not a good solution either (there is nothing scientific about voice communication program, also others don't use it). I agree that Network is also not the best, but I found parallels with VoIP.

Since Audio and Network are "official supersets" of HamRadio I'd pick it from one of those two.

Edit: Also, is there a Java runtime dependency missing from this package?

k4yt3x commented on 2023-08-17 15:01 (UTC)

@drws I have reviewed the material again. I agree that we can change the main category. sdrtrunk's primary functions isn't over the network, so I don't think it belongs in Network. It's also not an old-fashioned audio player, so honestly, if not Utility, I think it better belongs in Science like stated in the first comment. It's going to be one of Science and Audio I think.

drws commented on 2023-08-17 09:29 (UTC)

I understand and agree with your reasoning. But even in this case Audio or Network is a more suitable top-level category according to ref2.

Also, if XDG category is not recognized, DE should put the application into Other category. DEs have issues with that sometimes, but these are bugs that should be reported to developers.

No matter the fact that this is a talking application, Network seems more suitable than Audio, given the XDG specs and other applications.

k4yt3x commented on 2023-08-16 17:26 (UTC)

@drws The reason for me to want to keep the Utility category is because Utility is in the list of Main Categories every desktop environment MUST support, where HamRadio is in the list of Additional Categories that may not be supported by all DEs. I just think it's better to have at least one tag from the Main Categories.

Ref: https://specifications.freedesktop.org/menu-spec/latest/apa.html

drws commented on 2023-08-16 17:17 (UTC)

@k4yt3x: I think the best would be to simply have HamRadio, without the Utility category. Firstly that's more or less the standard solution for SDR applications and secondly this full-featured GUI app doesn't really fall under Utility category description. Last but not least, thank you for maintaining the package!

k4yt3x commented on 2023-05-25 18:39 (UTC) (edited on 2023-05-25 18:40 (UTC) by k4yt3x)

@utc-fan I think it belongs more in utility than science. I've added HamRadio to it.

utc-fan commented on 2023-05-25 11:04 (UTC)

I propose changing the categories in the desktop entry from "Utility" to something along the lines of "Science;HamRadio"