[7.4][rtp][Pollock]Problem with menus and packaged app

>> Carl,
>>
>>> >rtpUnscheduleWindow:
>>
>> I don't know about this at all. I can only assume that this method
>> doesn't know how to deal with Pollock windows.
>
> Alright, but I need a fix for this pronto.
>
> I'm curious as to why there is an rtp-related method in there after the
> application is packaged.
>
> -Carl
>
>
>
>

> So, perhaps I should avoid using the runtime packager.  I could write my  
> own script for stripping things out that doesn't leave any unpredictable  
> gotchas in there.  Has anyone else done this?
>
> -Carl
>
> ----- Original Message ----- From: "Carl Gundel" <[hidden email]>
> To: <[hidden email]>
> Sent: Friday, June 23, 2006 3:42 PM
> Subject: Re: [7.4][rtp][Pollock]Problem with menus and packaged app
>
>
>>> Carl,
>>>
>>>> >rtpUnscheduleWindow:
>>>
>>> I don't know about this at all. I can only assume that this method  
>>> doesn't know how to deal with Pollock windows.
>>
>> Alright, but I need a fix for this pronto.
>>
>> I'm curious as to why there is an rtp-related method in there after the  
>> application is packaged.
>>
>> -Carl
>>
>>
>>
>>
>

> -----Original Message-----
> From: Carl Gundel [mailto:[hidden email]]
> Sent: Monday, June 26, 2006 11:55 AM
> To: [hidden email]
> Subject: Re: Don't use RTP? Re: [7.4][rtp][Pollock]Problem with menus and
> packaged app
>
> Charles,
>
> Thanks for your interest in my problem.
>
> > Don't strip. Just say no :)
>
> Well, I took a short detour and ended up back using RTP.  I did manage to
> figure out how to fix the bug I was seeing, along with a couple of other
> things (of course).  I will post my workaround when I get a chance.
>
> > figure out a base image for yourself that has the necessary support you
> > need for your app but not your app. You can strip that in the sense of
> > getting rid of IDE stuff but I just start with the base.im provided by
> > Cincom. Compress it , reshack it if on Windows etc. Then use this image
> as
> > your SRE (Smalltalk Runtime Environment) and just load your app's
> parcels
> > at runtime.
>
> I would like to do that when I get a chance.  On the other hand, I wish
> the
> runtime packager was simply more effective at stripping things out.
>
> > Out of curiosity , when you are successful in stripping your app how big
> > is your executable compressed?
>
> Well, so far I've managed to get things down to 11.5MB, but I know there
> is
> all kinds of stuff in there that can still come out.  Some of it will be
> easy and will just need a little trial and error experimentation, but I
> know
> there's lots of tangled coupling in there that shouldn't be, and that's
> going to make it hard.  I would like to get this down to around 5MB (or
> less).
>
> I wish the RTP didn't report it's progress with a GUI.  That obviously
> makes
> stripping a complicated matter.  Also, the removal of methods, classes and
> artifacts should be done using the most primitive methods so that unwanted
> development tool related stuff can come out without crashing the RTP.
>
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com

> Charles,
>
> Thanks for your interest in my problem.
>
>> Don't strip. Just say no :)
>
> Well, I took a short detour and ended up back using RTP.  I did manage  
> to figure out how to fix the bug I was seeing, along with a couple of  
> other things (of course).  I will post my workaround when I get a chance.
>
>> figure out a base image for yourself that has the necessary support you  
>> need for your app but not your app. You can strip that in the sense of  
>> getting rid of IDE stuff but I just start with the base.im provided by  
>> Cincom. Compress it , reshack it if on Windows etc. Then use this image  
>> as your SRE (Smalltalk Runtime Environment) and just load your app's  
>> parcels at runtime.
>
> I would like to do that when I get a chance.  On the other hand, I wish  
> the runtime packager was simply more effective at stripping things out.
>
>> Out of curiosity , when you are successful in stripping your app how  
>> big is your executable compressed?
>
> Well, so far I've managed to get things down to 11.5MB, but I know there  
> is all kinds of stuff in there that can still come out.  Some of it will  
> be easy and will just need a little trial and error experimentation, but  
> I know there's lots of tangled coupling in there that shouldn't be, and  
> that's going to make it hard.  I would like to get this down to around  
> 5MB (or less).
>
> I wish the RTP didn't report it's progress with a GUI.  That obviously  
> makes stripping a complicated matter.  Also, the removal of methods,  
> classes and artifacts should be done using the most primitive methods so  
> that unwanted development tool related stuff can come out without  
> crashing the RTP.
>
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com

>> Carl,
>> The 11.5 MB size is it compressed or not?  Im my application, after  
>> striping, I am getting down to about 15 MB size ant then after using  
>> imageCompress.exe I have an image of about 6.5 MB in size.  The reason  
>> my image is so big  that I use a lot of things -- networking, security,  
>> graphics, etc., etc. not to mention application code itself.
>
> This is uncompressed.  For my application it doesn't make so much sense  
> to consider the compressed size.  My customers will care about how large  
> their own Liberty BASIC applications will be and so my own VW-based  
> BASIC runtime platform must be as small as possible.  BASIC programmers  
> expect things to be small (they complain if simple programs compile to  
> more than 100K), and so I start at a position of weakness at least in  
> that respect.
>
> In addition since my software is marketed as shareware I will lose sales  
> if the download is too large.  It is currently only 3.2MB and this  
> includes two VisualSmalltalk images, some support libraries, a  
> voluminous help file, and lots of example code.  I'll be lucky if I can  
> get it down to twice that size using VW and even if I manage that my  
> download count will suffer.
>
> On the upside, Liberty BASIC on VW is faster, more flexible, and  
> multiplatform.  :-)
>
> -Carl Gundel, author of Liberty BASIC
> http://www.libertybasic.com

>With my packaged app I'm using the latest version of Pollock from the dev repository and I get the following stack dump when I try to use menus in my application window.  The code that constructs the menus looks like this:
>
>Panda.Menu
> menuItems: (Array with: ((Panda.MenuItem label: '&Run')
>     submenu: (Panda.Menu new addMenuItem: ((Panda.MenuItem label: '&Run')
>         keystroke: (Panda.Keystroke shift: #F5);
>         actionID: #run))))
>
>The application works fine in the RTP test mode without discovering any dynamic references.  I  tried this with and without adding my own things to remove.  Same either way.
>
>-Carl Gundel, author of Liberty BASIC
>http://www.libertybasic.com
>
>Initial Context Stack Arguments:
>[1] UndefinedObject(Object)>>doesNotUnderstand:
>Receiver: (id=1) nil
>Arg1: (id=11432) a Message with selector: #open and arguments: #()
>[4] BlockClosure(Object)>>ifNotNil:
>Receiver: (id=15672) BlockClosure [] in WindowManager class>>initializeNoWindowBlock
>Arg1: (id=387) BlockClosure [] in WindowManager>>rtpUnscheduleWindow:
>[5] WindowManager>>rtpUnscheduleWindow:
>Receiver: (id=10512) a WindowManager
>Arg1: (id=5726) a Panda.ActiveTransient 168
>[6] WindowManager>>unscheduleWindow:
>Receiver: (id=10512) a WindowManager
>Arg1: (id=5726) a Panda.ActiveTransient 168
>[7] Panda.ActiveTransient(Window)>>unscheduleWindow
>Receiver: (id=5726) a Panda.ActiveTransient 168
>[8] Panda.ActiveTransient(Panda.TransientWindow)>>close
>Receiver: (id=5726) a Panda.ActiveTransient 168
>[9] Panda.ActiveTransient>>close
>Receiver: (id=5726) a Panda.ActiveTransient 168
>[10] Panda.ActiveTransient(Panda.TransientWindow)>>closeMenu
>Receiver: (id=5726) a Panda.ActiveTransient 168
>[12] Panda.ActiveTransient(Object)>>ifNotNil:
>Receiver: (id=5726) a Panda.ActiveTransient 168
>Arg1: (id=12616) BlockClosure [] in Panda.MenuPane>>closeMenu
>[13] Panda.MenuPane>>closeMenu
>Receiver: (id=10698) a Panda.MenuPane
>[15] Panda.MenuPane(Object)>>ifNotNil:
>Receiver: (id=10698) a Panda.MenuPane
>Arg1: (id=4636) BlockClosure [] in Panda.MenuPaneItem>>closeMenu
>[16] Panda.MenuPaneItem>>closeMenu
>Receiver: (id=7385) a Panda.MenuPaneItem "&Run"
>[18] Panda.MenuPaneItem(Object)>>ifNotNil:
>Receiver: (id=7385) a Panda.MenuPaneItem "&Run"
>Arg1: (id=11761) BlockClosure [] in Panda.MenuPaneItemAgent>>closeMenu
>[19] Panda.Win95MenuPaneItemAgent(Panda.MenuPaneItemAgent)>>closeMenu