related to this old issue: https://github.com/geany/geany/issues/788 I have stated my rationale there, repeating here: -------------------------------------------------------------------------------------- dear all, this original post really is about a not so well thought design of geany. I want to tell you a bit specific sitation. I am running Geany on my phone (Ubuntu Touch), you can see here: neither it does on other Linux machines by default
Now, on the phone, the most of the filesystem except ~/, is read-only. Also, is very limitted in space. Installing geany's files into /usr or anywhere outside of ~/ would be considered very expensive. So me, I installed it locally under my home. Should geany be a bit more flexible, that'd be not a problem at all. Even desktop launcher can be added to ~/.local/usr/share/applications/ instead of /usr/share/applications, and so on, HOWEVER, I had to manually ln -s my home based installation back to /usr/share/geany.
Sure, I can do this, just as I can install with a prefix to my home, but that is not convenient. That is not allowing for there to be a way of convenient automated installation to user's home directory. And basically, the ONLY portion which makes it hard, is that path containing the glider.
Just imagine how much more flexible and convenient the Geany would become if you could simply supply the path via environmental var or a command line switch.
Again, I can help myself, but I wanted to point out that in deed, Geany has a small part that limits it without clear reason for it to be that way.
Best Regards, Kris
Geany has to know where to find its data files, but it is a C program, a compiled language, so the paths can only be set at build time. You can zip up an install tree but it has to go in the same place on the target machine. A pull request that added a command line option to specify the prefix at runtime may be accepted but somebody has to make it.
Rather than reading the Glade file path from environment variable or command line option, I'd rather use [GResources](https://developer.gnome.org/gio/stable/GResource.html) to compile the GtkBuilder into the main binary. This is how I would've done it originally but it didn't exist yet, and so would have required using non-standard build tools (ex. `exo-csource` or custom script). Now that it exists and Geany is already depending on a new-enough Glib to use GResources, IMO this is the way to go and the recommended approach for GTK+ UI definitions AFAIK.
Though there is still all the other data files Geany needs to find, glade is just the first one it looks for.
glade is just the first one it looks for
And the only one that prevent Geany from running if not available.
GResources sounds like a very good idea, but I also proposed in the other post, that the paths, instead of being constants generated by prefix during ./configure, are completely replaced in all of the source code, with GetDataPath() function, and then you just add that function in some central place, and it uses $PATH-like loginc to test few paths according to priority: 1. path specified by the prefix (current), if not found then 2. path relative to user's home folder ($HOME), if still not then 3. path relative to the folder of the executable (argv[0])
Also, optionally, an environmental variable could also be tested in that function and give, for example highest priority.
Conceptually it feels sound to me, and if Geany source code is fairly well structured, or if someone knows it well, should be an easy task as well.
btw, the function suggested does not need to scan the path list every time. It would only perform selection the 1st time, and set a global variable, that would not change for the rest of the program. Would be fast that way.
github-comments@lists.geany.org