in reply to ActiveState PerlApp + Gtk and themes

If you run the GUI version of perlApp (just type perlApp with no args) some of this might be more apparent.

For the "extra" .exe I think you need what is called a "bound file". Read the help (access easiest from the GUI). This will be added in the Files tab. You can configure it to be automatically extracted so that you can just run it from your Perl program. You can also cram in say a config file or some fancy graphic, etc.

In the front pane of the GUI, you can specifiy additional search paths (in addition to the normal Perl directories). I think this will help with your first 2 problems.

When you get this setup, the GUI version can save what you've done as a "project file" so you don't have to keep doing this stuff every time you make the .exe.

Update: As far as the .dll goes, I think that if all else fails, you can use the bound file trick to force it into the .exe package and if its automatically unpacked, I think at run time your program will find it. Congratulations on doing something pretty complicated - you've without doubt already surmounted many hurdles to get this far!

  • Comment on Re: ActiveState PerlApp + Gtk and themes

Replies are listed 'Best First'.
Re^2: ActiveState PerlApp + Gtk and themes
by Ralesk (Pilgrim) on Jan 20, 2012 at 16:20 UTC

    Thanks. We've been using the GUI ever since we've started playing with PerlApp, so we do already have a decent-ish project file for it. I'll look at the File tab more closely for adding the extra file we'd need to run, it might be that I missed some controls there.

    However, the other problem doesn't seem to be fixable with the library (blib, shared lib, etc.) list on the main tab, I've tried them and no change in the resulting file (the GTK+ DLLs only began to get included when I copied them to the Perl lib/auto directory). Might be doing something wrong, but adding more paths than the normal ones simply didn't change a thing.

    I have just found out that if I do copy the GTK+ libs to the "awkward" directories, the theming will go off in the original Perl script too, not just the packed one. This makes it slightly easier and faster to debug, as long as I can find a way to figure out to see just what kinds of files it tries to open. An open-source Windows strace app I found wasn't of any use, though.

[reply]
      I've never tried to build a GUI library before. I know that when Active State does this, they add extra heuristics to perlApp that makes it "smarter". This is how it can find and force additional modules into the .exe that aren't explicitly "used" (via a use xxx; statement) - there are probably other things that they do of which I am unaware. It may be that you are stuck with some kludgy stuff. I think the "bound file" idea will work and I think I've done it before, but its been awhile. Sorry that I can't help further.

      Update: I've used Taskinfo before. It can show files that a process currently has open, I don't know of there is a way to figure out what files were accessed (but are in the steady state closed: i.e. were opened read, but are now closed). The author has continuously updated this app since I first used it- speculation: maybe there is now some kind of "trace" option - I don't know.

[reply]

        Thanks for your help so far, I've just stumbled upon Process Monitor by SysInternals, and it seems to be of great help tracing down file opens and such. I've already found where I should be putting GTK's locale files with it. I'll take a look at the bound file stuff eventually, maybe I'll need it too (seems like it, with the additional binary I'm trying to ship with our app).

[reply]

In Section Seekers of Perl Wisdom