Monthly Archives: December 2014

Less snark ahead? 3.2.19 is availabe.

I’ve updated the What is Federales? page because people do read that and it was seriously out of date and my casual snarky attitude may have offended sensitive people. (I just did it again, didn’t I?)

Now that Shoes 3.2 is a serious project, I have new responsibilities to be more professional.

If you believe that, my skills at communication have mesmerized you. Or maybe I’m just working on the plumbing. I am proud of what I’ve done in the last year (special Hat Tip to Ian Trudel)

Since you are used to disappointment, I’ll release 3.2.19 in without my not so secret advanced default packaging options. Just one bug fixed in 3.2.19 – the NSIS installer bug –if your Windows PATH is larger than 1024 bytes, it matters. Is that a sign of maturity in me or in Shoes 3.2?

Background grinding

Apologies for being so quiet here. I’ve very busy working on the Shoes plumbing. Many of you may not care about such things, but I do and plumbing has a higher priority than ‘fancy new stuff I dreamed up’.

I’ve been helping Ian build Shoes 3.2 for OSX 10.6. Its working for him on 10.6 and I can run it but I can’t build a 10.6 from my 10.9 system and until I can, it’s in Limbo land for 10.6. I have much to learn about OSX and so far the solutions aren’t as simple as some folks believe. I may have uncovered a Shoes/OSX bug with SSL that no one knew about.

I’ve also decided that I need to convert my github fork into a new github organization (a new project for most of you). That would have a new and separate bug reporter and new wiki. That’s a pain in the behind for me and anybody with a clone of my repo but that’s the nature of open source. I’ll have to create new bug reports for anything in the old system that is still a bug. That alone will take a fair amount of my time. And then moving and rewriting the wiki articles.

I started my maintenance efforts for Shoes 3.2 some 53 weeks ago in my haphazard way. I fixed some show stopping problems in Red Shoes, brought up to speed with current Ruby and gems versions and fixed some very vexing issues on Windows (thanks Ian), got it working again on OSX (it was broken there even though it appeared to work). I tossed in some Linux enhancements and I restored packaging and untied it from a fixed Shoes location to download from.

Now, it’s time for me to accept the rest of the task for getting Shoes 3 running again == A Fork. No, not a git fork, a project fork. I suspect the Shoes 4 folks will cheer so I don’t see this as a fractious thing. It’s still just Shoes C/MRI (Red Shoes).

[Update]
Shoes 3.2 has it own bug reporter/issues! And tags! And a team member!

Some folks won’t take you seriously until you ‘Git’re right’. That’s another reason to work on the github plumbing.

NSIS bugfix in Ubuntu

One fix in the upcoming Shoes 3.2.19 was to rebuild my copy of NSIS with some patches and use it for packaging Windows .exe’s. It’s the long string bug (H/T Ian Trudel).

This does not affect packaging for or with Shoes.

That also means a patched up NSIS is a prerequisite for anybody building Shoes from source and if they want to build and distribute Shoes for Windows. Fortunately for me, I was able to find a way to do the NSIS build on Ubuntu (14.04). It’s pretty easy. Don’t use their ‘dpkg -‘ instructions though. Because you have to sudo and deb names mav have changed. The other thing I needed to do was to prevent Ubuntu from replacing my version with the old one during a software update. Net wisdom suggests a ‘hold’ is the way to go. We’ll see. I locked the packages in Synaptic and then decided to lock them with aptitude. sudo apt-mark hold nsis sudo apt-mark hold nsis-common

This will bite me some time in the future. Almost guaranteed. I’ll install a new linux instead of Updating or Ubuntu will do something and I’ll never know until the bug is reported again. Why? Because my path setting in Windows will never get large enough.

Default Custom App Installer – Linux Target

That title just rolls of the tongue, doesn’t it? Here’s view of the 3.2.19 packager when you select “I want Advanced Options” when packaging an Directory (a .shy). It would be meaningless to use advanced options for a single file. It’s for ‘Apps’ that have multiple ruby files or images or sqlite3 db files or other files.
packager-3.2.19

It’s close enough to the final version (he says) to discuss what the choices mean. If you don’t provide your own installer script then you’ll be using the default customer installer. Page down for a screen shot of that, in action.

If you want your own installer to run on the users system then you’d push that button and select your Shoes script – you’d probably start with a copy of static/stubs/app-install.tmpl Notice where it says to always include a png? It’s serious.You need to do that even it you are targeting Windows or OSX.

Remember, the installer Shoes script, custom or default will run on the users machine using what ever Shoes it can find. It might be a Shoes included or it might be a part of a download if needed package that only installs Shoes if its not already installed. This secondary app-installer runs in Shoes on the users system, before/instead of the shy you packaged. Clear? Probably not.

There is a choice ‘Expand shy in users Directory”. When Shoes runs a .shy it creates a temporary directory, expands the shy into it and runs the .rb you chose as the staring script when you created the .shy. When the program exits, usually if things are working corrrectly, that temp dir is deleted. Anything you write in that temp dir is deleted. this is considered a very good thing by some folks. Shoes always worked that way and it’s the default option here.

Perhaps you don’t want that. Maybe you’re using an older Green Shoes script that assumes it can save files right next to the script. Or you want users to be able to edit and change your code but they can’t because it’s hidden in a .shy (temp dir) that disappears when Shoes quits. Then you check that expand option. You are the developer. You can hide your code or allow access.

Here’s how my YTM default custom app installer looks:

default-custom-install

We can see several interesting things. The title is not “Shoes”! If the users theme allows it, the icon would be that .png you had to include. It will fail if you didn’t. The text in the panel shoes tehm the Shy meta data. The end user can pick where they want the ‘App’ installed. They can’t control your choice of expand or not. Either way they get something perament they can double click or run from menus/filemanager or Finder or Explorer. No need for the launching from the command line in Linux.

I’m showing the Linux version because that’s all that that works so far. I wish it was prettier with better functionality but there are limits to Linux. There will be limits to Windows and OSX but I do the hard case first because that sets the scope for all platforms.

I almost forgot. That categories edit_line only shows up on linux and entries in their are highly dependent on the users Linux, Windows manager and theme. You can ask for categories but don’t be surprised if you setup doesn’t honor your choices.

Did I mention it’s all Shoes. If you don’t like my default custom installer you can write your own. And you can this packaging from any Shoes platform to any other Shoes in the 3.2 family.

How does it work? It’s pretty simple on the surface, Here’s listing of the tmp dir while the custom installer is started
ccoupe@bronco:/tmp/shoes-ytm-custom.19160$ ls -l
total 152
-rw-rw-r-- 1 ccoupe ccoupe 20974 Dec 5 20:26 ytm.icns
-rw-rw-r-- 1 ccoupe ccoupe 99678 Dec 5 20:26 ytm.ico
-rw-rw-r-- 1 ccoupe ccoupe 4517 Dec 5 20:26 ytm-install.rb
-rw-rw-r-- 1 ccoupe ccoupe 1033 Dec 5 20:26 ytm.png
-rw-rw-r-- 1 ccoupe ccoupe 9065 Dec 5 20:26 ytm.shy
-rw-rw-r-- 1 ccoupe ccoupe 430 Dec 5 20:26 ytm.yaml

There are the icon’s I added on the building system. The running gui screen is ytm-install.rb. ytm.shy is the the .shy I chose to package. ytm.yaml is the options used to build ytm-install.rb with. Most of them are useless but expandshy isn’t. It controls what is written to the users chosen directory. ~/Applications/ytm in this case. This example is packed expandshy = false. Let’s click the install button and see what is placed in ~/Applications/ytm
ccoupe@bronco:~/Applications/ytm$ ls -l
total 20
-rw-rw-r-- 1 ccoupe ccoupe 257 Dec 5 20:47 ytm.desktop
-rw-rw-r-- 1 ccoupe ccoupe 1033 Dec 5 20:47 ytm.png
-rw-rw-r-- 1 ccoupe ccoupe 9065 Dec 5 20:47 ytm.shy

There’s the ytm.shy and the ytm.png. ytm.desktop is the Linux menu entry that was copied to one or two places on your Linux system. You can launch YTM in 3 ways. There’s a menu entry (my system) in Others. If my file browser understands .desktop files it will launch on a double click. Lastly, I could use the terminal.

What about expandshy = true?
ccoupe@bronco:~/Applications/ytm$ ls -l
total 52
-rw-r--r-- 1 ccoupe ccoupe 639 Dec 5 21:00 foo.csv
-rw-r--r-- 1 ccoupe ccoupe 761 Dec 5 21:00 foo.rb
-rwxr-xr-x 1 ccoupe ccoupe 745 Dec 5 21:00 quote.rb
-rw-r--r-- 1 ccoupe ccoupe 613 Dec 5 21:00 README.txt
-rw-r--r-- 1 ccoupe ccoupe 1230 Dec 5 21:00 TODO.txt
-rw-rw-r-- 1 ccoupe ccoupe 256 Dec 5 21:00 ytm.desktop
-rw-rw-r-- 1 ccoupe ccoupe 1033 Dec 5 21:00 ytm.png
-rwxr-xr-x 1 ccoupe ccoupe 14414 Dec 5 21:00 ytm.rb
-rw-r--r-- 1 ccoupe ccoupe 456 Dec 5 21:00 ytmsec.csv
-rw-r--r-- 1 ccoupe ccoupe 456 Dec 5 21:00 ytmsec.csv.sav

It’s every thing in my original shy only this time all the files are permanent. I can update my csv data files and the changes will stick. My launch options are the same – the .desktop points to ytm.rb in the the previous example it pointed to ytm.shy.

Expand or not, the end user of ytm only has to use the terminal once to execute the downloaded file and only suffers the marching ants on the terminal once.

The same design principles will apply to OSX and Windows. Details matter of course because they aren’t equal.

With your own custom installer script you can get as clever and pretty as Shoes and Ruby allows. Maybe you only care about Windows. Fine! Be that way, if you like. If you can find or create a gem that manipulates the Registry, you can use Shoes to download it and you have the ability to copy the existing Shoes into a different directory and install your app just like NSIS would. Difficult work, but do able. Pretty simple gem for someone to write.

Clever Linux and OSX tricks are easier than Windows. Copy an exsting.shoes/federales to somewhere else – make it your own app. Before your imagination runs wild, remember where gems are stored. These are possibilities you can do. I’m only supplying the ‘default’ custom installer.

I wonder what would happen if I packaged Hackety Hack with an expandshy = true and it’s icons. It could be done with any Shoes 3.2.19 platform. Assuming I get the Windows and OSX version working.

More icon fun.

Could I have more fun? Yes I could. Shoes 3.2.19 has two new methods. See if you can spot them in the following test script:

# test.rb
Shoes.app :title => "The Wizard says" do
para "test"
set_window_title "Yield to Maturity"
para name
para Dir.getwd
set_window_icon_path File.join(Dir.getwd,"ytm.png")
end

Congratulations if you say “where is ‘name’ set”? The short story is not all methods of Shoes.app are documented. And they might work is mysterious ways. For example there is a name= that you might think does the same thing as set_window_title. It doesn’t. Perhaps you think, “I can change the title of the window on the Shoes.app call just like you did. What’s the point of a new set_window_title method?” Mostly, there’s no point unless you need to change the title later.

The new set_window_icon_path method is a way to associate an new icon with your script instead of the Shoes Federales icon. If you have a task bar with the Shoes Manual and your app, separate icons could be handy. Plus, some people really like icons.

Beware the Bewares for they are many

  1. The method names may change if the Shoes 4 folks don’t like it.
  2. The OS or Theme may not change anything. It’s only a request that the OS or theme may decline to do and your script won’t know nor can it do anything about it.
  3. You have to create an icon and be able to find it. Png 128*128 works for Linux and Windows but downscaling by the OS or theme may not show the love you expect. Black letters on a transparent background can be hard to see in some themes
  4. I haven’t written the code for OSX. It might be different or not work..On OSX it doesn’t change the finder name but the dock looks nice.
  5. It does NOT change the icon of a packaged script. Read that again. This changes the icon after your script starts. It does not change the icon of the file. I hope to have a different facility for that. Linux doesn’t have custom icons for a file so that won’t happen and Windows and OSX only have them for executables and they are .ico and .icns formats, not png.
  6. Did I mention this is a work in progress and even if the set_window_icon_path succeeds nothing may change?
  7. It’s kind of a neat feature. If you want to package up your script for Linux and make it look better you should add the set_window_icon_path call and provide an png icon in your .shy.
  8. You don’t have Shoes 3.2.19 because it’s not released. So you’ll have time to create an icon. Make some ico and icns too.

Other than that, it’s kind of neat but bit weird, OS wise.