Improve best practices enforced by the package.js module
Submitted by Paolo Borelli
Link to original bug (#739553)
Description
I have been playing around with a small app from scratch in gjs this Sunday, and I have found that the package.js module enforces some conventions that are not particularly good or intuitive (at least imho). Some of those seem easy to change (even in a backward compatibile way).
I'll write down some notes here, it could be it is just me missing the rationale for some of the choices or a matter of taste...
-
It suggests to add a script in the data dir with a fully qualified filename "org.gnome.FooApp" and then create a foo-app symlink from bin to this script. This seems not very useful to me. What's the point of such script? Who is supposed to call it? Programmatic invocations should go through the dbus interface. It seems to me there should just be the utility script in bin with the commandline-friendly name. This would a) avoid the usage of hackish symlinks b) avoid a script with an awkward fully qualified name c) remove the usage of an executable script in "data"
-
It suggests the use of the fully qualified name as PACKAGE_NAME for autotools, this does imho more harm than good since it then forces the use of hacks to have a sensible tarball name etc, and confuses people referring to autotools documentation (as if that was not already confusing enough)
-
it uses the name passed in both to determine the package dir and to determine the path inside resources. Since resources always use paths like /org/gnome/MyApp/ui" etc, this implies that files need to be installed in /usr/share/org.gnome.MyApp, instead of /usr/share/my-app which is what I was expecting. I realize this is a matter of taste and not a big problem, but I do not particularly like this convention since it is verbose and the added name spacing does not buy us anything as far as I can see. It is also less grep/find friendly due to capitalization rules
-
It calls g_set_prgname with the fully qualified name, which is unexpected. We alredy have plenty of glib/gtk api that set prgname implicitely and adding one more that hijacks the call before the other run is not very nice. For instance sometime I use the g_get_prgname to create log files in my own namespaced dir and I'd much rather have nice short names like my-app.log
I guess apart from (1) they are all related to the use of the fully qualified name...
To sum things up, my expectations would be:
- keep using "my-app" as pkgname so that tarballs are called my-app-1.0.xz etc as usual with autotools
- have gresources files etc installed in /usr/share/my-app
- the gresource files would use /org/gnome/MyApp/ui internally (I do not care if the resource files themselves are called org.gnome.MyApp.src.gresource or my-app.gresource)
- Just install /usr/bin/my-app as a gjs script without a symlink to another script
- Do not hijack set_prgname and let gtk set as usual
I think these things could be possibile by passing in to package.init both the short name and the fully qualified name, falling back to the current behavior when just one is specified