Christian Liebel's Blog

Setting up TeXstudio on Mac OS X 10.11 El Capitan

For a couple of years now, TeXstudio is my favorite IWE (Integrated Writing Environment) for LaTeX. Last year, I switched from Windows to OS X, but I didn’t take my LaTeX environment with me. Since I’m going to need LaTeX more often in the next time, I finally set it up on OS X 10.11 El Capitan. Unfortunately, this was not an easy task. And here’s why:

Installing MacTeX and TeXstudio

The most common TeX distribution on Mac is MacTeX, and this distribution is incredibly huge: MacTeX’s installation package is about 2.3 gigabytes in size. The distribution contains all important TeX binaries, Ghostscript and some GUI tools for managing packets or modifying global TeX settings. (There’s also a way smaller distribution called BasicTeX, whose package is only 109 megabytes in size. However, I haven’t tested this distribution in combination with TeXstudio.)

Okay, installing a package is easy so far. But after you have installed MacTeX and TeXstudio, you will find that TeXstudio reports that it’s not able to find a LaTeX distribution. Huh, why is that?

Keep Out, Super User!

“Don’t touch my system folders” — El Capitan

El Capitan’s all-new System Integrity Protection disallows modifying system folders such as /usr or /sbin even if you are granted super user rights. Those system folders can be modified with system rights only – for a good reason.

Hence, El Capitan doesn’t only prevent you from installing (linking) the binaries of MacTeX to the very common location of TeX distributions in /usr/texbin, it even breaks your existing installations of MacTeX if you upgrade from Yosemite or earlier versions of OS X to El Capitan.

TeXstudio looks for a tex distribution in the /usr/texbin folder only, and obviously won’t find it there. Therefore, you have to remap all commands usally found in /usr/texbin to the new location in /Library/TeX/texbin:

latex       "/Library/TeX/texbin/latex" -synctex=1 -interaction=nonstopmode %.tex    
dvips       "/Library/TeX/texbin/dvips" -o %.ps %.dvi
MakeIndex   "/Library/TeX/texbin/makeindex" %.idx    
BiBTeX      "/Library/TeX/texbin/bibtex" %.aux    
pdfLaTeX    "/Library/TeX/texbin/pdflatex" -synctex=1 -interaction=nonstopmode %.tex    
dvipdf      "/Library/TeX/texbin/dvipdfm" %.dvi    
dvipng      "/Library/TeX/texbin/dvipng" -T tight -D 120 %.dvi
Metapost    "/Library/TeX/texbin/mpost" --interaction nonstopmode 
Asymptote   "/Library/TeX/texbin/asy" %.asy

If you installed MacTeX and experience problems with the GUI or command line tools (or both) because of missing paths or binary files, make sure you execute the Setup-2015.pkg package in the TeX folder in Applications. This fixes the paths to the TeX distribution in Library.

Note: You can also perform those steps on versions of OS X prior to El Capitan. In this case your TeX environment will continue to work after upgrading to El Capitan.

Configuring TeXstudio for Git

Git is one of the most advanced version control systems around. However, TeXstudio only includes support for the older and less powerful Subversion (SVN). At the time of this writing, the feature request regarding Git support is more than four years old. But thanks to Git’s support for aliases, you can map SVN’s commit command ci to Git’s commit command (source):

git config --global alias.ci "commit"

Finally, you have to set git as the command for SVN and SVNADMIN. Now you can enable automated commits to keep intermediate results of your progress.

If you have another IWE or use other tools that don’t find your MacTeX installation, make sure to check out this guide by Herbert Schultz about upgrading your TeX environment to El Capitan.

Et voilà! Your TeX environment on El Captian is up and running.

The Mysterious 17 Pixels Shift

One of the most curious bugs I ever came across was found deep inside a third-party JavaScript grid component. This grid component had a fixed height and width. It calculated column widths by taking the total grid width and distributing it to the different columns, each of which got a certain, predefined percentage.

On Mac OS X, everything looked nice. But on Windows, the column headers were oddly shifted and did not match the content columns. While investigating the bug, we found out that the columns were shifted by exactly 17 pixels to the left. But why 17 pixels? And not 5, 10, 15 or anything power of 2?

It turned out that the grid component also took the scroll bar width into account to reserve this space if the scrollbar is shown, i.e. if the height of all grid rows exceed the given height of the grid. This scroll bar width matches 17 pixels in most browsers on Windows with default display settings (source):

Browser (Windows)	Scroll Bar Width
Internet Explorer	17px
Chrome	17px
Firefox	17px

You can check your current scroll bar width using the Scrollbar Pixel Width Test from the same author that wrote the article linked above.

This effect did not occur on OS X, because the scroll bar width always equals zero pixels here. OS X only has a floating scroll bar that appears while scrolling rather than a static one, therefore no space is reserved. (The author of the above test states that it would not work on OS X. In fact, the test works perfectly: The scrollbar pixel width on OS X simply is 0 pixels.)

It seems that nobody seriously tested the grid component on Windows. And while Macs are widespread in the world of web and/or cross-platform development, an important thing to keep in mind is that you should always test your components and/or apps on all of the target platforms to ensure that everybody can enjoy your app. Don’t expect your component or app to run perfectly on all platforms if you saw it running on a single platform only.

Fun fact: Microsoft Edge’s scroll bar on Windows 10 has a width of 12 pixels.

Speeding up Your Mono Server Application, but Watch the Argument Order

Mono has a --server option that can radically improve the response behavior of .NET server applications when run on Mono. From mono’s man page:

--server: Configures the virtual machine to be better suited for server operations (currently,  allows a heavier threadpool initialization).

However, when I tried using the server option for the first time, I was very disappointed that it didn’t work. After some time I found out that I caused the problem myself. Why? Because

mono MyApp.exe --server

is unfortunately not the same as

mono --server MyApp.exe

The latter is correct and works like a charm (on Mono 3.2.3 and higher).

Mono’s options must be placed before the file name, because otherwise the option is treated as an argument passed to the given .NET application. This is a simple, yet mean mistake, because you are used to append any parameters at the end of a command.

Conclusion: Sometimes it can be helpful to also look at the top of the man page, where it clearly states that the actual argument order is like the following:

mono [options] file [arguments...]

Looking Back: AngularJS, Cordova and the Windows Phone Back Button

Recently we brought a Cordova-based web app which already runs successfully on iOS and Android to Windows Phone 8.1. One of the issues you will definitely come across when porting your app to this platform is the handling of the back button, an essential part of Windows Phone’s user experience.

By default, pressing the back button on Windows Phone closes your Cordova-based app, regardless of the current state. Instead, the back button should bring you back to the previous view; except on the main page, where pressing it must suspend the current app (according to the Windows Store Policies, 10.4.4):

Where applicable, pressing the back button should take the user to a previous page/dialog. If the user presses the back button on the first page of the app, then the app terminates (unless it is allowed to run in the background).

Not respecting those policies may not only lead to a rejection of your app, but also to bad ratings in the Store.

Using what’s already there

As an AngularJS developer, you will quite likely use a routing framework such as ngRoute, ui-router or the “New Router” (also known as component router) introduced in Angular 1.4. All those routers rely on the window location property of the browser. Therefore, you can simply go one step back in the app’s history in order to achieve what the back button in Windows Phone (and Android) usually does.

Windows (Phone) exposes its runtime to JavaScript apps in a library called WinJS. WinJS again exposes an event to handle back button presses. When you return true in the event handler, the event is canceled and the app continues to run, otherwise the default behavior will take place and the app suspends. We will subscribe to this event and check where we are: If we are on the main view, the app will suspend. Otherwise, we will go back one step in the history using the browser’s back stack:

if (window.WinJS && window.WinJS.Application) {
    window.WinJS.Application.onbackclick = function () {
        if (window.location.hash === '#/') {
            return false;
        }

        window.history.back();
        return true;
    };
}

Please note that you may have to modify this snippet so it suits your needs. If you use the HTML5 history functionality or your main view resides in a completely different route, this would not work. Instead of checking the value of window.location.hash, you could also retrieve the current route or state from your framework.

That’s it! Maybe.

If everything works now, you are done! But if you use older versions of Angular or host your app in an iframe, there’s probably some more work to do. Calling window.history.back there will always bring you back to the main state. At the time of this writing, this is an bug still open in Angular and in Internet Explorer. To work around it, you can disable the HTML5 history detection in $sniffer like so:

if (window.WinJS) {
    $provide.decorator('$sniffer', function($delegate) {
        $delegate.history = false;
        return $delegate;
    });
}

Now Angular watches and processes your location. But this change again may result in digest iteration errors (Error: 10 $digest() iterations reached. Aborting!) in Angular, for example when triggering window.history.back in digest-related operations such as functions invoked by ng-click. To address this problem, you can monkey-patch window.history.back like the following to get the navigation out of the digest cycle:

var originalBack = $window.history.back;
$window.history.back = function() {
    $timeout(function () {
        originalBack.apply($window.history);
    }, 0, false);
};

Now we are finally done and your app should run properly with full back button support on Windows Phone. Enough looking back for today. Let’s look forward.

Enabling Cross-Platform Touch Interactions: Pointer vs. Touch Events

Your customers love mobile devices and apps. And they love the way of interacting with them, using touch.

Detail of Michelangelo’s Creation of Adam

Touch is a very natural input method and multi-touch allows intuitive gestures such as pinch-to-zoom. As mobile or web developers, we also love apps and touch interaction. But, face it, we are also quite lazy. We want to run code written once to execute on several browsers and platforms resulting in one and the same behavior. Unfortunately, there are two competing methods that allow interacting with websites using touch input:

Touch Events (W3C recommendation) were introduced by Apple with the release of iOS 2.0 in 2008. Touch events translate touch screen input (and only touch screen input) to events similar to the traditional mouse events (touchstart=mousedown, touchend=mouseup).

Pointer Events (W3C recommendation) encapsulate a whole bunch of input methods in one single layer of abstraction. Mouse, touch and pen input are all translated to one common “pointer” event the application can react to.

So, which method should we decide for? A good starting point could be looking at the browser support of both methods.

Desktop browser support

Browser	Touch Events	Pointer Events
Chrome	yes	no
Firefox	disabled by default	no
Internet Explorer 10/11	no	prefixed/yes

Mobile browser support

Browser	Touch Events	Pointer Events
Chrome	yes	no
Android Browser	yes	no
Safari (iOS)	yes	no
Internet Explorer 10/11	no	prefixed/yes
Internet Explorer 11 (Windows Phone 8.1 Update)	yes	yes

Okay… that’s quite disappointing. Neither touch nor pointer events provide a true cross-platform support. Whereas most browsers don’t support pointer events at all, Internet Explorer completely lacks support for touch events on the desktop (e.g. tablets and touch-enabled devices with Windows or Windows RT).

Waiting for your touch… in some manner

You might say, “Wait, that Internet Explorer?” That browser with the TV advertisement accompanied by Blake Lewis’s “I’ve been waiting for your touch”? Yep, that browser. Neither the desktop version nor the Modern UI app included support for touch events. (That’s also the reason why you can’t interact with the three.js examples using Internet Explorer on desktop and touch, because those demos bind to touch events only, which aren’t supported by IE.)

Internet Explorer exclusively supports touch interactions if the target website binds to pointer events. But since most mobile websites incorporate touch events exclusively, Microsoft later introduced touch event support for Internet Explorer 11 on Windows Phone 8.1 Update to increase the mobile browser’s compatibility with touch-enabled websites that only bind to touch events.

Reshuffling the pack

However, browser support will radically improve: Microsoft’s upcoming browser Edge (previously called “Project Spartan”) fully supports touch events since Build 10041 of the Windows 10 Technical Preview, even on the desktop. Pointer events are about to be implemented in Chromium and will be enabled by default in Firefox Nightly.

Why pointer events?

With the launch of Microsoft Edge, it now seems safe to use touch events cross-platform. But are they the way to go? I don’t think so: pointer events abstract a lot of input methods (mouse, touch, pen, Kinect, …). Implemented once, you get all the others for free. (Remember, we’re lazy?) Furthermore, pointer events even include crazy details such as the angle between device and pen. And finally, pointer events serve a much better performance compared to touch events, especially on mobile. That’s why pointer events are definitely worth a try.

Alright, so what should I use now?

Although touch devices are around for quite a long time now, supporting cross-platform touch is still a cutting edge topic. Touch events feature a good browser support, but are slow and rather restricted. Pointer events are not available in all of the major browsers yet, especially in Safari. As so often, there’s no one perfect way to go, at least for the moment. In the following, you will find two suggestions to master cross-platform touch support with the means we have today. Please note that both approaches are about remodeling data that is actually available from input types the browser supports.

Polyfills: There are polyfills for both touch and pointer events. There’s the Pointer Events Polyfill, subtitled a unified event system for the web platform from the jQuery foundation and Cameron Henlin’s Touch polyfill for Internet Explorer 10 and 11. If you have an existing website or application using one of the two event types, you could use a polyfill to make it work in browsers not supporting the specific event type. As an example, the aforementioned three.js examples can be made to work with Internet Explorer if you include the touch polyfill. If you start development today, working with pointer events and the pointer events polyfill is an option, especially if you need low-level access to the events (e.g. actual values).

hammer.js: Another option to support touch input is using a JavaScript library called hammer.js, that again encapsulates the traditional mouse events, touch and pointer events. It offers a broad browser support. If you start developing today, this would also be an option, especially if you need high-level access to the events (e.g. gesture recognizers).

Have fun! And touch it.