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

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 :)

  • Comment on Re^8: ActiveState PerlApp + Gtk and themes

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

      I haven’t encountered the packed script itself yet, only the supporting libs and the bound files, during runtime. Nowhere inside %TEMP%, not in a recognisable format anyway.

      But what we need is not the script but the bound files, well, in that case I have some bad news (I think). Way before I installed the strace implementation or Process Explorer, I tried to figure out what was in view for the script, and did a system("dir"); — I got the files from the directory where I had started the EXE from and not where the unpacked script mysteriously and temporarily lives. And the bound files are nowhere to be seen there unfortunately (I haven’t re-checked, but I think I would have noticed if there had been .dll files where normally there isn’t a single one), only in the previously discussed PID-labeled directory in %TEMP%. So I’m afraid I’ll need that absolute path.

[reply]
[d/l]
        The "bound files" should be relative path to the .exe, ie. ./ (current directory that the .exe is running within). The OS will unpack the Perl .exe into some directory somewhere - what the full path name is, we don't know and should not care.
[reply]

      So, here are the bound files in the perlapp project file:

      Bind: lib/gtk-2.0/2.10.0/engines/libwimp.dll[file=C:\uhu\gtk\lib\gtk-2.0\2.10.0\engines\libwimp.dll,extract,mode=666]
Bind: lib/gtk-2.0/2.10.0/engines/libpixmap.dll[file=C:\uhu\gtk\lib\gtk-2.0\2.10.0\engines\libpixmap.dll,extract,mode=666]
Bind: share/themes/MS-Windows/gtk-2.0/gtkrc[file=C:\uhu\gtk\share\themes\MS-Windows\gtk-2.0\gtkrc,text,extract,mode=666]
Bind: share/locale/hu/LC_MESSAGES/gtk20.mo[file=C:\uhu\gtk\share\locale\hu\LC_MESSAGES\gtk20.mo,extract,mode=666]
Bind: share/locale/hu/LC_MESSAGES/gdk-pixbuf.mo[file=C:\uhu\gtk\share\locale\hu\LC_MESSAGES\gdk-pixbuf.mo,extract,mode=666]
Bind: share/locale/hu/LC_MESSAGES/atk10.mo[file=C:\uhu\gtk\share\locale\hu\LC_MESSAGES\atk10.mo,extract,mode=666]
Bind: share/locale/hu/LC_MESSAGES/glib20.mo[file=C:\uhu\gtk\share\locale\hu\LC_MESSAGES\glib20.mo,extract,mode=666]
Bind: share/locale/hu/LC_MESSAGES/gtk20-properties.mo[file=C:\uhu\gtk\share\locale\hu\LC_MESSAGES\gtk20-properties.mo,extract,mode=666]

      This will have those files unpacked to %TEMP%\pdk-%USERNAME%-$$\{lib,share}\.... The libwimp.dll and the MS-Windows gtkrc file seem to be crucial in getting the UI look right. Libraries are found with help from the GTK_EXE_PREFIX environment variable, and shared stuff are found via the GTK_DATA_PREFIX envvar. Locale is supposedly controlled by XDG, but XDG_DATA_DIRS did not have any effect and it is still searched in %TEMP%\pdk-%USERNAME%\<Gtk2 hashdir>\.

      The Perl code thus needed the following “hack” so GTK+ knows where to look:

      if ($windows) {  ## $windows as set up earlier in the code = TRUE if (
+$^O eq 'MSWin32' or $^O eq 'MSWin64');
    $ENV{GTK_EXE_PREFIX} = "$ENV{TEMP}\\pdk-$ENV{USERNAME}-$$";
    $ENV{GTK_DATA_PREFIX} = "$ENV{TEMP}\\pdk-$ENV{USERNAME}-$$";
    $ENV{XDG_DATA_DIRS} = "$ENV{TEMP}\\pdk-$ENV{USERNAME}-$$";  ## Has
+ no effect, see above.
}

      [download]

      Now all I need is bundle that other binary I mentioned earlier and possibly figure out how to change the locale lookup dir somehow, and I’m done.

[reply]
[d/l]

In Section Seekers of Perl Wisdom