Packaged OSX app duplicates Windows #190

Closed
diasks2 opened this Issue Jan 23, 2016 · 16 comments

Comments

Projects
None yet
2 participants
@diasks2

diasks2 commented Jan 23, 2016

I created two simple Shoes apps to demonstrate the issue. I packaged them using Shoes 3.2.26 and then tested the app on OSX 10.11.3.

sample.rb produces the following error. The gem used in sample.rb does not have any dependencies, so I would think it should work:

Warn in <unknown> line 0 | 2016-01-23 10:51:45 +0900
Ignoring byebug-5.0.0 because its extensions are not built.  Try: gem pristine byebug --version 5.0.0

Warn in <unknown> line 0 | 2016-01-23 10:51:45 +0900
Ignoring nokogiri-1.6.6.2 because its extensions are not built.  Try: gem pristine nokogiri --version 1.6.6.2

Error in <unknown> line 0 | 2016-01-23 10:51:45 +0900
cannot load such file -- encrypted_strings
/Users/diasks2/Desktop/Sample.app/Contents/MacOS/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/Users/diasks2/Desktop/Sample.app/Contents/MacOS/lib/ruby/site_ruby/2.1.0/rubygems/core_ext/kernel_require.rb:54:in `require'
sample.rb:7:in `<main>'
/Users/diasks2/Desktop/Sample.app/Contents/MacOS/lib/shoes.rb:493:in `eval'
/Users/diasks2/Desktop/Sample.app/Contents/MacOS/lib/shoes.rb:493:in `visit'
eval:1:in `<main>'

sample2.rb works fine.

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Jan 23, 2016

I just noticed that sample.rb actually did open successfully in the background behind the Shoes console that displayed the above error message. If I delete the app and then reinstall it I can no longer produce the above issue. Hmm

diasks2 commented Jan 23, 2016

I just noticed that sample.rb actually did open successfully in the background behind the Shoes console that displayed the above error message. If I delete the app and then reinstall it I can no longer produce the above issue. Hmm

@ccoupe ccoupe added the OSX label Jan 23, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Jan 23, 2016

Contributor

The pristine warnings are harmless. The gems are there and do work. There is an existing bug report about them.

I suspect some sort of race condition is the reason. There are threads involved with Shoes.setup.

Contributor

ccoupe commented Jan 23, 2016

The pristine warnings are harmless. The gems are there and do work. There is an existing bug report about them.

I suspect some sort of race condition is the reason. There are threads involved with Shoes.setup.

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Jan 24, 2016

Here is what seems to be going on after digging into it further (and I need to rename this issue as it is actually something completely different to what I first thought).

Opening either of these packaged sample apps opens two windows (they are both in the same xy coordinates on the screen so one window is hidden directly behind the other).

One window (the top one) is opened immediately before any gem dependencies are installed. The second window (the one is the background) is opened after the installer finishes running. Thus, if it is the first time opening that app on a computer the first window may open the Shoes error console if the second window hasn't finished installing the gems before they are called in the first window. On the second opening, since the gems are now already installed on that computer the error console will not open; however two windows of the app will still be opened.

This opening of two windows of the app happens even if I package with the latest beta (3.3.1).

I experience this issue on both OSX 10.9.5 and OSX 10.11.3

diasks2 commented Jan 24, 2016

Here is what seems to be going on after digging into it further (and I need to rename this issue as it is actually something completely different to what I first thought).

Opening either of these packaged sample apps opens two windows (they are both in the same xy coordinates on the screen so one window is hidden directly behind the other).

One window (the top one) is opened immediately before any gem dependencies are installed. The second window (the one is the background) is opened after the installer finishes running. Thus, if it is the first time opening that app on a computer the first window may open the Shoes error console if the second window hasn't finished installing the gems before they are called in the first window. On the second opening, since the gems are now already installed on that computer the error console will not open; however two windows of the app will still be opened.

This opening of two windows of the app happens even if I package with the latest beta (3.3.1).

I experience this issue on both OSX 10.9.5 and OSX 10.11.3

@diasks2 diasks2 changed the title from Error packaging gem with no dependencies to Two windows of the same app open for a packaged OSX app Jan 24, 2016

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Jan 24, 2016

I wasn't sure if the Shoes.setup block was causing this issue, so I created an even more basic hello world app which when packaged for OSX and then opened still opens 2 windows of the app.

diasks2 commented Jan 24, 2016

I wasn't sure if the Shoes.setup block was causing this issue, so I created an even more basic hello world app which when packaged for OSX and then opened still opens 2 windows of the app.

@ccoupe ccoupe changed the title from Two windows of the same app open for a packaged OSX app to Packaged OSX app duplicates Windows Jan 24, 2016

@ccoupe ccoupe added the Normal label Jan 24, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Jan 24, 2016

Contributor

Yes that is a different bug and I do remember it. I thought I fixed it but I guess not. Yes, you don't notice it because one App.window covers the other but there is only one Shoes console for all Shoes.apps. Since gem installing via Shoes.setup is a long process there is plenty of opportunity for mischief between them

Contributor

ccoupe commented Jan 24, 2016

Yes that is a different bug and I do remember it. I thought I fixed it but I guess not. Yes, you don't notice it because one App.window covers the other but there is only one Shoes console for all Shoes.apps. Since gem installing via Shoes.setup is a long process there is plenty of opportunity for mischief between them

ccoupe added a commit that referenced this issue Feb 2, 2016

address osx issues #190, #188
* Fixes the dup app issue with something of a hack - add a -f or --file
  before the script when an app is packaged (include shoes)
  or use `open -a /Applications/Shoes.app for a download if needed
* Similar changes to custom installer

@ccoupe ccoupe added this to the 3.3.1 milestone Feb 2, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 2, 2016

Contributor

I've created (discovered?) a way to fix @diasks2 issue. Works for me and I needed it too. It's either a workaround of a hack because OSX is just too strange when it comes to launching an app with arguments (script name). Look for beta 3.3.1 at the usual place, time stamp > Feb 1 2016, 21.18

Contributor

ccoupe commented Feb 2, 2016

I've created (discovered?) a way to fix @diasks2 issue. Works for me and I needed it too. It's either a workaround of a hack because OSX is just too strange when it comes to launching an app with arguments (script name). Look for beta 3.3.1 at the usual place, time stamp > Feb 1 2016, 21.18

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Feb 2, 2016

Thanks. I downloaded that beta and gave it a shot. If I open my app from that beta with the 'Open an App' option then it works - no issues. However, if I 'Package an App with Shoes' from that beta and then try to run the packaged app - it tries to open the app then immediately dies and closes the app.

This is on OSX 10.9.5 using the app from the repo that I added you as a collaborator on.

diasks2 commented Feb 2, 2016

Thanks. I downloaded that beta and gave it a shot. If I open my app from that beta with the 'Open an App' option then it works - no issues. However, if I 'Package an App with Shoes' from that beta and then try to run the packaged app - it tries to open the app then immediately dies and closes the app.

This is on OSX 10.9.5 using the app from the repo that I added you as a collaborator on.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 2, 2016

Contributor

It's weird when working with betas and packaging. How did you package (gui? command-line? which OS was the package done from? Was it is also running the newest 3.3.1 beta? Which version is in the cache?) Some of the fixes applied to the packaging Shoes and some applied to scripts run on the destination. Details are important and viscously confusing.

Contributor

ccoupe commented Feb 2, 2016

It's weird when working with betas and packaging. How did you package (gui? command-line? which OS was the package done from? Was it is also running the newest 3.3.1 beta? Which version is in the cache?) Some of the fixes applied to the packaging Shoes and some applied to scripts run on the destination. Details are important and viscously confusing.

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Feb 3, 2016

Thanks, figured out the issue. I am packaging using the GUI. The problem seems to be that the version that it downloads to include Shoes with the app is hardcoded to http://shoes.mvmanila.com/public/shoes/shoes-3.3.0-osx-10.9-tgz instead of the beta. So I needed to go into .shoes/walkabout/package/shoes-3.3.0-osx-10.9.tgz and replace that file with the beta renamed to shoes-3.3.0-osx-10.9.tgz to trick it into using the beta when it asked to use the version in the cache.

When packaging Shoes within an app, I think the GUI packager should search http://shoes.mvmanila.com/public/shoes for the version equal to the version of the app that is currently running.

The beta does fix the issue of two Windows opening. Thanks!

diasks2 commented Feb 3, 2016

Thanks, figured out the issue. I am packaging using the GUI. The problem seems to be that the version that it downloads to include Shoes with the app is hardcoded to http://shoes.mvmanila.com/public/shoes/shoes-3.3.0-osx-10.9-tgz instead of the beta. So I needed to go into .shoes/walkabout/package/shoes-3.3.0-osx-10.9.tgz and replace that file with the beta renamed to shoes-3.3.0-osx-10.9.tgz to trick it into using the beta when it asked to use the version in the cache.

When packaging Shoes within an app, I think the GUI packager should search http://shoes.mvmanila.com/public/shoes for the version equal to the version of the app that is currently running.

The beta does fix the issue of two Windows opening. Thanks!

@diasks2 diasks2 closed this Feb 3, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 3, 2016

Contributor

I'm going to reopen because I know of one edge case where it's as right as I'd like. That edge case is not what you're working on @diasks2. Another way of testing betas and packaging is to tell Shoes to use a different website to download from (it's a cobbler options). That option exists so Shoes is not tied to my web site (like the older Shoes was). It can be forked or set up a enterprise version. The trick with that option is remember to delete the file when you want to go back to the original site.

There are 30 possible combinations of packaging with (3.3.1) and the only dependable way to test them is to go the --ruby script.rb. They also build in 1 to 3 seconds, with no website delay If you understand how the scheme works.

Contributor

ccoupe commented Feb 3, 2016

I'm going to reopen because I know of one edge case where it's as right as I'd like. That edge case is not what you're working on @diasks2. Another way of testing betas and packaging is to tell Shoes to use a different website to download from (it's a cobbler options). That option exists so Shoes is not tied to my web site (like the older Shoes was). It can be forked or set up a enterprise version. The trick with that option is remember to delete the file when you want to go back to the original site.

There are 30 possible combinations of packaging with (3.3.1) and the only dependable way to test them is to go the --ruby script.rb. They also build in 1 to 3 seconds, with no website delay If you understand how the scheme works.

@ccoupe ccoupe reopened this Feb 3, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 3, 2016

Contributor

When packaging Shoes within an app, I think the GUI packager should search http://shoes.mvmanila.com/public/shoes for the version equal to the version of the app that is currently running.

Two issues, that I've considered before. Betas should not bleed in to regular packaging for regular user. Better version matching is quite complicated. I haven't paid for the download bandwidth to store every version of Shoes. About 2/3 to 3/4 of Shoes downloads are done by hackers, collectors, bots, and student projects to crawl the web. So a 3.2.24 packager gets the latest 'release', 3.3.0 at this time. Of course, it's just Ruby (cgi) at the server, and in the packager both of which are changeable if someone wants to dig deep and do something better or host their own. Think about the case of a future 3.3.16 and all that is available on the server is 3.3.12.

Contributor

ccoupe commented Feb 3, 2016

When packaging Shoes within an app, I think the GUI packager should search http://shoes.mvmanila.com/public/shoes for the version equal to the version of the app that is currently running.

Two issues, that I've considered before. Betas should not bleed in to regular packaging for regular user. Better version matching is quite complicated. I haven't paid for the download bandwidth to store every version of Shoes. About 2/3 to 3/4 of Shoes downloads are done by hackers, collectors, bots, and student projects to crawl the web. So a 3.2.24 packager gets the latest 'release', 3.3.0 at this time. Of course, it's just Ruby (cgi) at the server, and in the packager both of which are changeable if someone wants to dig deep and do something better or host their own. Think about the case of a future 3.3.16 and all that is available on the server is 3.3.12.

@diasks2

This comment has been minimized.

Show comment
Hide comment
@diasks2

diasks2 Feb 3, 2016

That makes sense...maybe an option in the GUI to choose Shoes from the file system. This way instead of always defaulting to .shoes/walkabout/package/{} the user could tell it where to look and what file to use.

diasks2 commented Feb 3, 2016

That makes sense...maybe an option in the GUI to choose Shoes from the file system. This way instead of always defaulting to .shoes/walkabout/package/{} the user could tell it where to look and what file to use.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Mar 8, 2016

Contributor

Closing. It's time for 3.3.1

Contributor

ccoupe commented Mar 8, 2016

Closing. It's time for 3.3.1

@ccoupe ccoupe closed this Mar 8, 2016

@ccoupe ccoupe modified the milestones: 3.3.2, 3.3.1 Jun 23, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Jun 23, 2016

Contributor

This issue is not fixed well enough. The two windows (scripts) is a very strange osx thing depending on how Shoes was launched. The previous hack, works but does not solve he real problem.

Contributor

ccoupe commented Jun 23, 2016

This issue is not fixed well enough. The two windows (scripts) is a very strange osx thing depending on how Shoes was launched. The previous hack, works but does not solve he real problem.

@ccoupe ccoupe reopened this Jun 23, 2016

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Jul 2, 2016

Contributor

In Shoes 3.3.2 (next release), this bug is hopefully crushed. If you run shoes from the command line, the script name gets passed in as a normal ruby ARGV element and Shoes runs it. OSX also sends shoes an open file event and Shoes opens the script again (apple-script like) because it's declared to be a GUI program. In Shoes 3.3.2 the launch script will notify Shoes that it's a terminal launch and not a GUI launch and it will ignore the Apple Event sent to it. But:

If you've got open -a /Applications/Shoes,app' in your scripts (textmate/automater/....) you'll have to change them slightly.

Contributor

ccoupe commented Jul 2, 2016

In Shoes 3.3.2 (next release), this bug is hopefully crushed. If you run shoes from the command line, the script name gets passed in as a normal ruby ARGV element and Shoes runs it. OSX also sends shoes an open file event and Shoes opens the script again (apple-script like) because it's declared to be a GUI program. In Shoes 3.3.2 the launch script will notify Shoes that it's a terminal launch and not a GUI launch and it will ignore the Apple Event sent to it. But:

If you've got open -a /Applications/Shoes,app' in your scripts (textmate/automater/....) you'll have to change them slightly.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Jan 21, 2017

Contributor

Closed in Shoes 3.3.2

Contributor

ccoupe commented Jan 21, 2017

Closed in Shoes 3.3.2

@ccoupe ccoupe closed this Jan 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment