in reply to Re^5: ActiveState PerlApp + Gtk and themes
in thread ActiveState PerlApp + Gtk and themes

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...

Replies are listed 'Best First'.
Re^7: ActiveState PerlApp + Gtk and themes
by Marshall (Canon) on Jan 20, 2012 at 21:18 UTC
    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]
        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.

        When the .exe that PerlApp built runs, it will unpack itself into a directory, some temporary directory that the O/S assigns as you've seen - I think that is the same way on Unix or Windows (of course PathNames are different). The bound files will be in sub-directories from that. I think that you will be able to specify paths based upon "./" in your Perl code for @INC. "./" is the directory that your "unpacked" code is currently running in - whatever that directory path name is.

[reply]

In Section Seekers of Perl Wisdom