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

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.

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

Replies are listed 'Best First'.
Re^3: ActiveState PerlApp + Gtk and themes
by Marshall (Canon) on Jan 20, 2012 at 16:31 UTC
    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]
        I think Process Monitor does most of what TaskInfo does and I think that one is free (Igor will want some money for his shareware - but I doubt that a modest sum is a problem for your organization). I've corresponded with Igor before and if you have a special requirement, he'll listen to what you have to say and actually reply!. For disclosure: I have no pecuniary interest in this - so this is not a ad for Igor.

        I do think that this "bound file" idea has a very high probability of working. From the help:

        Bound Files Container To include additional files in the output executable (accessed via the PerlApp::get_bound_file() and PerlApp::extract_bound_file() functions), use the Bound files container. The Bound files container corresponds to the --bind file command-line option.

        Extract Configure whether the bound file should be automatically extracted when the application is run, or if invoking PerlApp::get_bound_file() or PerlApp::extract_bound_file() is needed to obtain the file. This setting corresponds to the --bind command's extract argument.

[reply]

In Section Seekers of Perl Wisdom