Bound files, when their name is set to eg. some/path/file.dat will be expanded to %TEMP%\pdk-%USERNAME%-%PID%\some\path\file.dat. This seems incredibly useful, albeit ever so slightly uncomfortable due to the PIDded folder. At least it is full well possible to specify non-flat paths. Good!
As far as GTK+ is concerned (and Pango, and the others looking for their files), the files are expected as if the DLLs' place in the file system were the UNIX /usr/local or a /opt/$something, so the etc, lib or share stuff go into, for example auto/lib/Gtk2/{etc,lib,share}. This is, however, a completely different directory than the one where we autoextract bound files: the libs live in %TEMP%\pdk-%USERNAME%\$sha1something\, and don't seem to support expanding more than just the specified folder — so in particular, the subdirectories never exist in them and GTK+ won't find the needed libraries/config files/locales/whatever.
(I'm not sure if I've mentioned, the theming and the locale files are found by the non-packed script now, but as the packed one is missing the carefully placed files, a different method is now needed.)
So now I'm trying to figure out how to make good ol' GTK+ look for its resources in %TEMP%\pdk-%USERNAME%-%PID%, but for that, Running GTK+ Applications might be of good help. Had that page open in my browser all day, no luck yet, but it might come to me any time...
| [reply]
[d/l]
[select] |
Sounds like you have made further huge progress!
The bound files will be in a directory underneath "." (the current directory that Perl executes in). The absolute path to %TEMP%\pdk-%USERNAME%-%PID% directory should make no difference.
I hope that wiser Monks than me can weigh in here and explain how to set the @INC or whatever path or environment variables that GTK+ needs for it to run. It sounds to me like you are very, very close to getting this working!
| [reply] |
In the working directory? Hmm, I’m pretty sure I haven’t seen them, but I might just not have noticed them. I’ll definitely take a look at it again after some sleep, getting GTK+ to deal with . should be way more straightforward than with that weird folder.
Been spending almost the entire week playing around with various AS Perl installs (and the coworker-made PerlApp project), turns out something we use is allergic to 5.14, so when I tried AS myself, I went with the 5.12 installer of theirs. I played around with Strawberry because that one I heard is more CPAN-oriented, so I thought I’d try to get Gtk to work with it first, and if PAR breaks — which it did —, I can simply go back to the not-so-CPAN-friendly ActiveState (which in the end turned out to be just fine with self-compiled modules, go figure). So I’m glad it is kinda taking form finally. Or so it seems. I keep seeing the “light at the end of the tunnel”, every single day, and then comes a turn that makes me have to feel around in darkness for a while. I do like challenge, but I hope it’ll be over with soon! :)
Just for the record, PAR had some issues, with the system saying it can’t register Gtk2::Pango::Attributes or something like that, and, the Module::ScanDeps used by PAR also had some quirks, which could be solved by downgrading, but the last version that worked, broke pp’s add-module (-M) command entirely, which is kinda needed to amend the bundle if PAR forgets something, which it did. It sure was a fun trip :)
| [reply] |