This package will allow me to remove the packaged version of this library from https://src.fedoraproject.org/rpms/imhex and use this system lib. Spec URL: https://jonathanspw.fedorapeople.org/nativefiledialog-extended.spec SRPM URL: https://jonathanspw.fedorapeople.org/nativefiledialog-extended-0-1.20220813git6967d28.fc38.src.rpm Description: A small C library with that portably invokes native file open, folder select and file save dialogs. Write dialog code once and have it pop up native dialogs on all supported platforms. Avoid linking large dependencies like wxWidgets and Qt. Fedora Account System Username: jonathanspw
I don't think NFD is a header-only library. I suspect it will require more work to able to distribute a shared library. And perhaps the package could provide both the GTK+ and the "portal" versions (in separate subpackages) ...
There is no code related to generating shared libs that I can find, and only 3 files are generated. Two are headers and one is a static lib. I'm not sure how to generate both a gtk version and portal version from a single build but that's a good idea. Could you offer some guidance on how that might be accomplished since I think the generated header files will have the same name/path.
Worked with upstream a bit and here's a build with proper shared libs. Still not sure on the split package though to cover both GTK and portal. This version is only GTK. Spec URL: https://jonathanspw.fedorapeople.org/nativefiledialog-extended.spec SRPM URL: https://jonathanspw.fedorapeople.org/nativefiledialog-extended-1.0.0-1.fc38.src.rpm
formal review is here, see the notes explaining OK* and BAD statuses below: OK source files match upstream: e910c6549ef7ffd6a209aac26724c6d14404e094 nativefiledialog-extended-1.0.0.tar.gz OK package meets naming and versioning guidelines. OK specfile is properly named, is cleanly written and uses macros consistently. OK dist tag is present. OK license field matches the actual license. OK license is open source-compatible. License text included in package. OK latest version is being packaged. OK BuildRequires are proper. OK compiler flags are appropriate. OK package builds in mock (Rawhide/ppc64le). OK debuginfo package looks complete. OK* rpmlint is silent. OK final provides and requires look sane. N/A* %check is present and all tests pass. OK shared libraries are added to the regular linker search paths. OK owns the directories it creates. OK doesn't own any directories it shouldn't. OK no duplicates in %files. Ok file permissions are appropriate. OK no scriptlets present. OK code, not content. OK documentation is small, so no -docs subpackage is necessary. OK %docs are not necessary for the proper functioning of the package. OK headers in devel subpackage OK no pkgconfig files. OK no libtool .la droppings. OK not a GUI app. - rpmlint complains about missing documentation in devel, but the README in main pkg is sufficient - some packages use a trick with Xvfb to run graphical tests - the soname (library version) should be handled more safely, eg. with %{_libdir}/libnfd.so.1 instead of the wildcards, also would be good to know about the ABI stability and versioning plans from upstream The package is APPROVED.
(In reply to Jonathan Wright from comment #3) > Worked with upstream a bit and here's a build with proper shared libs. > > Still not sure on the split package though to cover both GTK and portal. > This version is only GTK. I think it's OK to start with the single GTK variant. For the portal support it would mean building it twice in %build, then installing the portal variant into a "portal" subpackage. One question is whether the variants would be with identical ABI ... Another would what should be the default and how to express it ...
In your email you mentioned this: > An easy fix is to add "Requires: xdg-desktop-portal-gtk", but it won't make the KDE users happy, I guess. But I'm not sure why. It appears that `xdg-desktop-portal-gtk` is part of Plasma anyway. That could be a simple solution as well after all.
(In reply to Jonathan Wright from comment #6) > In your email you mentioned this: > > > An easy fix is to add "Requires: xdg-desktop-portal-gtk", but it won't > make the KDE users happy, I guess. > > But I'm not sure why. It appears that `xdg-desktop-portal-gtk` is part of > Plasma anyway. That could be a simple solution as well after all. I think it's because KDE lists xdg-desktop-portal-gnome as a default package, but I guess they would prefer xdg-desktop-portal-kde instead. But I am not familiar with this "portal" concept. And there might be other Qt based desktops in Fedora.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/nativefiledialog-extended