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 mentioned my idea of having a ‘custom installer’ than Shoes script writers could use when packaging a script or directory (aka .shy) Shoes would supply a simple custom installer or the user could add their own (after modifying the default, most likely).
I’ve just checked in an update to winject.rb into my github that does the hard part – copy a Windows.exe replacing the icons inside with different ones. I believe Linux and OSX will be almost easy when it comes to icons, so I started dealing with what is not easy – Our best-est friend Windows.
Time for a pretend FAQ: What is a (default) custom installer?
- It’s a Shoes script that runs before starting the real app. It is not an NSIS type of installer. It can’t tweak the Windows registry.
- It’s a Shoes script. It can do a lot. Do you have an populated sqlite3.db file in your .shy that to be able to be updated and have the updates persist across invocations of your app? A custom installer (a Shoes script) can copy your Shy contents to a permanent directory the user chooses and then make it look like its an app instead of a shoes script
- For Linux, it could create a menu entry with your icon to your app that uses the existing Shoes. Fewer marching ants in the terminal. That is all the motivation I need to do this.
- for OSX, it could create what looks like an App, with your icon
- For Windows, it could create an .exe with your icons. Users would have to create an alias if they want it in their menus or task bar.
- That sound’s like an real app! No, it’s not. It might look like one and that might be good enough.
- Do I have to create all platforms icons? If you use the default custom installer then Yes you do. A .png for Linux and icns set for OSX and .ico (set) for Windows. Why? Because Shoes is cross platform by default. You could write your own installer if it’s too much trouble.
Will this be in 3.2.19? Unless I run into roadblocks, yes.
Windows user should pay attention. In no particular order,
- The windows install now has two exe’s. shoes.exe and cshoes.exe.
Shoes.exe is the one you all know.
cshoes.exe is used on the command line which means windows users get all the command line love that Linux and OSX folk are used to. Like
cshoes.exe -h and
cshoes --ruby non-gui-script.rb
- Advanced: It’s possible to drive the packager with a script instead of button clicks by using the shoes –ruby or cshoes –ruby. Not documented. Read the code in app_package.rb and packshoes.rb
Shoes.app :resizable => false now works for Windows and works more correctly for Linux. OSX didn’t have the bug.
- When a packaged app (script or shy’d up directory) is run on the downloading user’s system, the temp file created to hold it is deleted when Shoes exits.
- On Windows, the .shoes directory has moved to AppData – see below.
- Windows uses Ruby 2.1.4. No big deal since Shoes really doesn’t care. Yes, 2.1.5 is current but I can’t do everything at once.
The AppData usage could be a big change for some Windows users. I’ll try to explain in my clueless manner. When I log in to Windows 7, my HOME directory is
C:\Users\Cecil of course yours will be different. Shoes needs someplace to put things like download gems, the image cache and temp files. Well behaved Windows applications put that kind of stuff in AppData (ex: C:\users\Cecil\AppData) and well behaved Linux apps and OSX apps store stuff in ~/.something. Shoes is now well behaved.
On Windows, you can’t see AppData from the File Explorer without a dead chicken and chanting a secret incantation. Google “show AppData” for instructions. Most people don’t need to peek in there but you might want to, and you probably should at least once or twice if you’ve been running Shows on Windows for a while. Inside AppData is Local. Click into there. Shoes 3.2.18 will create it’s ‘Shoes’ folder in Local. Inside Local is Temp and Shoes may have left all kinds of use space wasting stuff in Temp. You ought to clean that up. The Shoes Droppings will be apparent just by reading the folder or filenames. Move them to the wastebasket and empty. If any of them are in use at the moment Windows won’t let you delete them. Hopefully, Shoes will no longer leave it’s trash behind.
Windows users who have installed new gems with Shoes: After you install 3.2.18, you might want to drag the contents of \Users\you\.shoes to AppData\Local\Shoes and delete .shoes Or reinstall the Gems or both.
Ian Trudel has been contributing a lot to Shoes 3.2 in the last month or two. Damn near all the Windows improvements in Shoes 3.2 are his direct contribution or his coaching me or insisting that I just don’t know enough about what I want to do. He’s almost always correct. If you need a multi-lingual, smart person on your project, check that LinkedIn link.
I think the next release 3.2.18, will please the more knowledgeable Windows developers and users. Who doesn’t aspire to be knowledgeable? There’s some bug fixes ahead and some fixes to problems you might not have seen yet or cared enough about to report them. Details that matter to me and to Ian.
Remember, Shoes 3.2 is only a maintenance release. Just cleaning up the old bugs and mis-features with an occasional helping of something new.
I doubt my app specific installer features will make it into 3.2.18. It works but it’s very incomplete and bugs get to the front of line. So report your bugs.
Shoes 3.2.17 is available in the downloads directory. Important bug fixes for Windows and OSX and Windows gets a feature or two.
- OSX: fixes the disappearing text in a edit_line.
- All: packaging a directory works.
- Windows: Shoes/Windows can package for Windows.
New Windows Features (h/t Ian T, aka Backorder who helped a lot getting these features working)
- A new installer which adds a working uninstall menu item, a desktop icon link and is generally ‘not evil’ and is current with modern versions of NSIS practices’ unlike the five year old installer.
- Doesn’t use the shoes.bat file. It’s gone. Just invoke shoes.exe
- Shoes is installed (default) in “Program Files (x86)” but not in the “Common Files”
- The Shoes installation directory is added to Path environment variable so command line jockey’s can just type
- You may find Install and uninstall to be a little faster and a bit more informative.
A special “shout out” to the bug reporters. Don’t assume anyone is going to fix a bug if you don’t report it.
The Samba! Because I love me some Samba.
I hate Windows Networking – it’s so clumsy. The Samba folks have done an admirable job shining a turd to a high sheen but …
No need to go there. I hate copying things to the Virtualbox shared folder too and I was doing a lot of that. One way: make a change in linux, copy to Windows, test. Now the Windows issues are deep enough and I’ve learned just enough Windows to be dangerous that I want to make code changes in Windows, try it. I’ll probably end up installing MinGW and RubyInstaller so I might as well document it. I’ll want to install vi too but I’ll delay that until the bare bones are set up.
My Linux Oracle VirtualBox has the ability to set (export) a linux directory as a CIFS share. For me that is ~/Projects which is E: in my Windows 7 VM. I removed the shared folder option in VirtualBox settings. It may take a couple of restarts of the Win 7 VM to get it hunky dory. I believe Virtualbox has it’s own Samba server which may conflict with any other samba you might have running. Or not,
There are bugs in Shoes 3.2.16 with packaging from Windows for Windows. Two bugs and
maybe three. We’re working on it.
On the bright side (for me), I mentioned in the previous post about the wiki Packaging post. If you had read that post you might remember that mentioned there are simples ways to setup Shoes 3.2.16 to use a different website for packaging. When I wrote that code into Shoes 3.2 I was thinking about not getting locked into something like the hackety.org mess should I vanish from the Shoes community. As it turns out, it’s also a good way to setup a separate site to test beta’s (3.2.17). Don’t ask to be part of the 3.2.17 beta test crew. We have a good idea what the bugs are. Fixing them is the hard part.
If you know something about Windows pe formats and which resources are UTF16LE then pipe up.