First Thoughts on the Mac Mini

Size

The Mac mini is my first Mac computer.  I bought it so that I could get ebe working to support assembly development on OS X.  The most obvious feature of the mini is its small size.  It's roughly the size of a Wii, which is like a fairly thick book.

OS X

OS X Mountain Lion was installed and I had no problems getting it set up with a seyfarth account for first use.  I also rapidly stumbled (or was led) into performing an update to 10.8.1.

I got somewhat used to the dock and the system bar at the top of the screen without a lot of grief.  It felt like the system was not taking much advantage of the right mouse button.

Safari and everything else seems to scroll backwards with the mouse wheel.  I haven't considered if one way has some inherent virtue, but I do find it annoying when I forget and scroll the wrong way.

xterm fonts

I needed to figure out how to cope with setting the font size for xterm.  Historically I have used "xterm -fn 10x20", which gives a nice font.  The "-fn" option specifies a font name.  Now depending on what a person has installed on their Linux system there could be a large number of fonts.  Running "xlsfonts" will print a list of fonts.  On my computer I noticed "terminus-32" which gave a pretty large font.

This is needed as I start letting users configure ebe.  One of the configurable items will be the font for xterm which is used for terminal I/O for the program being debugged.  I can't figure out a good way to settle this issue inside ebe, so I will give the user a few suggestions for fonts on my computer and suggest experimenting  with the names printed by xlsfonts.

Another option is to use TrueType fonts.  A useful list can be obtained using

    fc-list :scalable=true:spacing=mono: family

Then you can specify a font for xterm using -fa Courier (or whatever) and specify a size using -fs 14 (or some other number).  This gives more options.

Problem with after_idle

I ran into a bug with ebe recently which occurred under Debian Squeeze.  When ebe was started it "flashed" the menubar preventing it from working.  The same source code worked well under Ubuntu so I started looking for the problem.

I installed virtualbox on my home computer and installed Squeeze and sure enough the problem was there in the virtual Squeeze.  The likely problems seemed to be python, tkinter or pmw.  After some effort I managed to configure apt to allow installing packages from the testing repository.  I installed newer versions of python and pmw which were pretty much the same versions as I had on Ubuntu.  Still the problem persisted.

Now I knew that I was writing the line and column number of the editing cursor in the menubar in ebe, so I figured there might be some chance that I had screwed up that code.  I searched and located that all over the place in ebe I used after_idle to call a function which updated the line and column information on the menubar.  It looked like the problem was corralled.

I reread the documentation about the Tkinter after_idle function.  It claimed that after_idle would call a function once for a call to after_idle.  It seemed to me that after_idle was continuing to call my function to show the location.  This could happen if the location update code called after_idle or if after_idle was broken.

It turned out that after_idle was being called as a result of using my location update code.  I didn't locate a place where it could have happened and the fact that the code worked on Ubuntu and Windows makes it seem that the best bet was a problem with after_idle.  I realize that problems can occasionally make little sense and certainly studying the Tkinter code was beyond the call of duty, so I decided to solve the problem without figuring out exactly why the problem ever showed up.

The solution was pretty simple.  I added an additional function, show_location1, which I interposed between show_location which calls after_idle and show_location2 which actually does the location updates.  I am now using after_idle to call show_location1 and show_location1 calls after to trigger a call to show_location2 after 500 msecs.  The problem still exists, but updating the location twice a second doesn't interfere with the normal operation of ebe.

My expectation is that this is not a problem with my code, but I am not certain.  It makes me think that perhaps I would have been better off using QT with C++ rather than python.  Who knows which would cause the least trouble?

KDE Focus Stealing Prevention

I spent a little time last night trying to devise keystrokes which I could use in ebe to switch the current window rapidly.  Ebe has a total of 6 windows and finding the right one from a task bar can be a little tedious.

I first considered using the Windows key (Mod4 for Tkinter) along with a letter to switch.  I am already using Windows + S to start synaptic, so that may be a problem.  Then I considered briefly Alt.  I am already using Alt + D to bring up the Data menu which is a slight conflict.  I may eliminate the Data menu and use Alt, but for now I am using Shift+Control.

It took a little while before I learned that I needed to bind 'Shift-Control-C' instead of 'Shift-Control-c'.  I don't know why you have to tell Tkinter you want a capital letter when you have already specified Shift.  Perhaps I could specify 'Control-C' just as well.

These issues are fairly easy to cope with - the major problem was figuring out how to get the desired window to be on top of all the other windows.  I rapidly found the "lift" function and tried console.lift() to bring the ebe console window to the front.  It failed over and over.  I read quite a bit before I became suspicious that my window manager, KDE, was not allowing me to make the window be the top window.  That was indeed the case.

KDE uses an interesting "feature" called "focus stealing prevention".  Apparently some people are annoyed by applications which suddenly jump to the top.  I've used multiple window managers and I assume most of them do not have this KDE feature, but I haven't been plagued with applications popping up.  (Well a long time ago I used the MacOX, before X, to implement multitasking and had to bring processes to the front to receive messages.  That was a bit flashy, but off-track.)

I did discover a solution in KDE.  Using the KDE main menu follow "Settings" and select "System Settings".  This will bring up a settings window.  Using the "Window Behavior" option on the left you get a choice for "Focus stealing prevention level".  Setting this to "None" eliminates the problem.

Kindle version done

I decided to start on the Kindle version of my assembly book today.  I consulted this see what I had done before with htlatex.  I converted the book using htlatex and then ran it through calibre to convert to a .mobi file.  My math and table fonts were a little small and too light, so I did a google search and found where I had posted my solution to this problem from last year.

I also had a problem with images from screenshots being too blurry.  Google rapidly found a solution to convert the .eps file to .png bypassing the use of the .dvi file.  That issue was easily solved.

It is now done, though the width of the screen on the Kindle is a little too narrow for my wishes.  Of course the Kindle will allow rotating 90 degrees, but the Nook doesn't.  I will format my epub version tomorrow.

I don't pretend to know the exact reasons but I get a lot more sales from Amazon than from B&N.  I think it's about 10 to 1.  Does this spell DOOM for B&N?  I think B&N might keep on selling if they can keep their stores on college campuses.  If Amazon smells that money, then B&N might be toast.