To test the default custom packager I need some icons and an a Shoes app (must be shy’able app). I ‘ll use my Shoes app, ytm – Yield to Maturity calculator which is stored in the ~/Projects/ytm/ directory on my system. I don’t want the icons inside the ytm/ – a decision I’ll probably change later. For now, being a clever boy, I’ll create ~/Projects/icons/ytm/ and do the dirty work in there. For now I only care about the icon on the Desktop.
For Linux that’s
PNG image data, 128 x 128, 8-bit/color RGBA, non-interlaced. I’ll be using Gimp on Linux so the first thing to do is create a gimp file ytm.xcf, and create a new file 128*128 with a transparent background and then set the text tool to 48 pts and cleverly create this minimalist thing that I export from Gimp into a png.
It’s only a test. It doesn’t have to be pretty! I’ll name it ytm-128.png. Then scale it and export for 64×64, 48×48, 32×32 and 16×16. you can easily guess the the names.
Now I need to make a Windows ico file. And a OSX icns file. Gimp is less helpful to clueless folks like me. I have ImageMagick so it’s a simple
$ convert ytm-16.png ytm-32.png ytm-64.png ytm-128.png ytm.ico. That’s a larger file (90Kb) than I’d like but it’s only a test. The interwebs is filled with cloud apps to do the work for you. I used IConvertIcons. Good enough for me.
ccoupe@bronco:~/Projects/icons/ytm$ ls -ld ytm.*
-rw-rw-r-- 1 ccoupe ccoupe 20974 Nov 27 00:26 ytm.icns
-rw-rw-r-- 1 ccoupe ccoupe 99678 Nov 27 00:18 ytm.ico
-rw-rw-r-- 1 ccoupe ccoupe 1033 Nov 27 00:28 ytm.png
-rw-rw-r-- 1 ccoupe ccoupe 2824 Nov 26 22:44 ytm.xcf
I’ve been working on the Shoes hanging bug on Windows. It hasn’t been easy and I’m way above my pay grade on Windows internals. So many rabbit holes to explore. Every time I think I know what’s happening, I’m proven wrong.
Today, once again. I think I know what’s going wrong. I’ve got clues and hypotheses. I’ve confirmed some “that’s not right” behavior deep down in Shoes and Gtk/win32. I’m also smart enough to know that I don’t know my ass from a hole in the ground. I’m getting a lot more Windows education than I ever wanted.
At the moment, I think gtk/win32 and Ruby have different ideas about what an ‘fd’ is and that I should ‘unify‘ them. [snort]. One fd table to rule them all. Or a hack so each (Gtk, Ruby) believes their is one unified fd table. I’m leaning towards the hack. And then I’ll fix the real problem.
Or Shoes 4 will be released.
You might see Shoes 3.2.15-gtk2-*.install files in the download directory. For the moment, those are the Linux installers for Shoes. You might even notice that they are less than one half the size of 3.2.14’s .run files. 7MB instead of 19MB.
Gob smack me too! 3.2.15 was built without debug symbols. If you’ve got a small memory device running off a flash card like the raspberry pi, that actually makes Shoes on the pi ‘not really that slow’ . I could blow some smoke about paging and locality of ELF sections and other things. What matters is is it’s faster and smaller with makes if faster to download and package.
Why did I change the name from .run to .install? Because someone on the mailing list actually tried to package a Shoes script in Linux for Linux and he found the process a tad bit confusing. Sure I could write some better wiki docs but that’s not a good solution. It should be easier and for Linux (which is what I care about the most) I could be a lot better. First step – change the name so Shoes installers are not confused with packaged Shoes scripts and they cause “huh?” moments.
Yeah, I’ll have to do some code slinging in shoes/lib/app_packager and modify a bash script or two in order to get the download if needed option working again. For Linux. My plan is not to run the fricking installer every time. Install shoes 3.2 Federales once if its not there and then run thes users script. That won’t happen anytime soon, if ever for Windows unless I learn a whole lot more about Windows.
That’s the plan for 3.2.15 – better Linux app packaging. And smaller sizes.
I’ve got the Linux and Windows versions of Shoes 3.2.14 sorted out when it comes to using the Shoes built in gems (hpricot, sqlite3). It was mostly a problem with my build/testing setup. If the GEM_HOME environment variable is set (which rvm will set) then the Ruby inside Shoes got a bit confused. A lot confused. Don’t have rvm – not a problem. But I do have rvm and I suspect many Shoes Folks do. It was an easy fix in cache.rb to delete it, if it’s there (for sandboxed Tight Shoes). Finding that problem was a little tedious.
Shoes 3.2.14/OSX is being a bit picky and hissy. I think the otool/install-name-tool dance is required.
For convience, or continuity or ‘just because I can’, I’ve extracted Hackey Hack and made it available for download (see download tab. It works well enough for me with Shoes 3.2.14. I do not care about Hackety Hack other than Shoes 3.2 ought to be able to run it. It does. Except for the OSX problem with 3.2.14 not being available. Stay tuned.
I continue to learn. That means mistakes were made. Enough with the Negative Nancy self inflicted recriminations. Be positive! I got this to work on Shoes 3.2, Raspberry PI.
You could die, have a long conversation with the diety of your choice and be sent back to earth as an avenging angel while it starts up. The opening animation just swamps the Pi in all the wrong ways. Not a teaching tool for the pi. I’m disappointed but not surprised.
I did not cross compile the hpricot and sqlite3 gems. Thats even more sucky than I remembered. I just used Shoes Cobbler to install the gems on the systems that have the compilation tools and libs to do so.
So where does that leave us with those Shoes Gems (hpricot, sqlite3)? I don’t want them tightly tied into to building Shoes 3.2. Perhaps a separate project ‘shoes-extras’ or ‘shoes-pack’ gemset, based more on rake-compiler. Not really a Shoes thing. Just cross compile the gems. And make them available to Shoes – maybe another Cobbler button to load them from the website and install them into the ~/.shoes/+gems
Sqlite3 would be the interesting one. That gem should include the ruby gem stuff AND the sqlite3.so and .h and .c