French Mac Keyboard with Microsoft Remote Desktop App under Sierra or more recent

French Mac Keyboard with Microsoft Remote Desktop App under Sierra or more recent

Between OS X El Capitan (10.11) and Sierra (10.12) the keyboard driver has been completely changed by Apple. The Karabiner tool that allowed us to act directly at the driver level have been completely rewritten by Takayama Fumihiko for now two years. The new name of this application is Karabiner-Elements.

Karabiner-Elements is stable even if we do not yet find all the features of the previous version. Moreover, it is a “rewrite from scratch”: the main concepts remain, but everything else has changed. Finally, according to the developer, a set of features will no longer work as before (power button, ejection, Touch Bar …) because of deep changes in the management of these keys in the OS (but those should not concern us so much).

I have prepared for you a new configuration file that allows for French Apple keyboards to use Microsoft Remote Desktop App ® (including the beta version) pretty much correctly. Its goal is to produce the expected result for all the symbols drawn on the keyboard (at least mine, a 2012 A1243). The concepts to identify the keys remain the same as those developed in my previous article: Mac: To finish with the keyboard problems of Microsoft Remote Desktop App. On the other hand, the new version distinguishes between the main types of keyboards: ISO, ANSI and JIS. Note that in France, keyboards are predominantly ISO. Thus we are looking, to go from an Apple ISO keyboard to an ISO PC.

Just note:

  • We do not have yet tools to distinguish the remote session window from those which sometimes open asking for credentials before the remote connexion is set. Beware of passwords that use symbols that are not common to the PC and Mac keyboard.
  • You can not use the option “Use F1, F2, etc. as standard function keys” in a specific application yet. But as we regularly need F5 to “update” on Windows, my advice is to activate this option permanently. I’m afraid there will never be any change on this point.
  • Some configurations require the use of unexpected keys: Current key to use for complex editing on Mac French keyboard # 1172 .
  • When the virtual keyboard is opened in your remote Windows session, some keys may behave strangely (for example, a grave accent).
  • MacBook users with Touch Bar may need to add these rules: Touch bar does not change to f1-f12 when I press the key fn.

To exploit this new configuration, just get the latest version of Karabiner-Elements. In the Complex Modifications tab click Add rules, then Import more rules from the Internet. In the window that opens select in the section International (Language Specific): Microsoft Remote Desktop for Mac French Keyboard, then add the symbols you are interested in (all in once or one by one). In the same way, I add a specific swap left cmd and ctrl available also for the beta version.

Just enjoy now…

Microsoft® ODBC Driver 13 for SQL Server on Debian Jessie installation

Microsoft® ODBC Driver 13 for SQL Server on Debian Jessie installation

SQLSevrer Union Debian
For the version 11 of the Microsoft ODBC Driver for SQL Server on Debian Wheezy there was this really good post. Most of it remains usefull and here is just an update knowing everything is quite easier on jessie as the version of the unixodbc package manages those Microsoft drivers.

The hardest is to take the right version of the ODBC driver on the Microsoft website. In version 11 only RedHat driver was released and its libraries were luckily supported by Debian (just changing their names). It’s not with version 13. However, Microsoft now offers several versions of the drivers including an “Ubuntu” one, closer to Debian. It is available at: https://download.microsoft.com/download/2/E/5/2E58F097-805C-4AB8-9FC6-71288AB4409D/msodbcsql-13.0.0.0.tar.gz.

The dependencies to install version 13 are:

  • unixodbc: version 2.3.1 that comes with Jessie is enough (but optimizable by compiling a new version)
  • libgss3: this is new in version 13

Then the installation is limited to:

sudo apt-get install unixodbc libgss3
wget https://download.microsoft.com/download/2/E/5/2E58F097-805C-4AB8-9FC6-71288AB4409D/msodbcsql-13.0.0.0.tar.gz
-zxf tar-13.0.0.0.tar.gz msodbcsql
cd-msodbcsql 13.0.0.0
sudo ./install install --force

NB: It looks possible not to use the --force option, but you’ll have to patch install.sh and deal with the installation of odbc_config.

Once done, always run a small ldd /opt/microsoft/msodbcsql/lib64/libmsodbcsql-13.0.so.0.0 to ensure that all your dependencies are met and functional.

Finally, you just have to use it knowing the installer automatically creates this entry in /etc/odbcinst.ini:

 
[ODBC Driver for SQL Server 13]
Description = Microsoft ODBC Driver for SQL Server 13
Driver = / opt / microsoft / msodbcsql / lib64 / libmsodbcsql-13.0.so.0.0
Threading 1 =
UsageCount = 3
Mac : Get Rid of Keyboard Foreign Layout Troubles with Microsoft Remote Desktop

Mac : Get Rid of Keyboard Foreign Layout Troubles with Microsoft Remote Desktop

Microsoft Remote Desktop IconFor over a year now, Microsoft provides a free application called Microsoft Remote Desktop to access a computer (usually running Windows) through RDP from a Mac or iOS or Android device. This version should replace another free application provided by Microsoft: Remote Desktop Connection Client for Mac. If I remember well, the latter had taken his time to fully manage Mac keyboards in a foreign language. It looks the same for this new App: this problem does not seem a priority. Indeed, for now this app assumes you are using a PC keyboard on your Mac.

As Microsoft Remote Deskto is a promising product (in particular, it supports RemoteApp from a Mac, xfreerdp being a little disappointing on this point), I thought it deserved a little search. I finally found two different methods to overcome the problem, one looking more usable than the other.

Read More Read More

Zdmultilang v.1.2.2 has been released

Zdmultilang v.1.2.2 has been released

A new version of zdmultilang has been released. You can read more on the official website.

I did look at the changes that do not jeopardize the work I had done arround the improvment of the widget support. However, I did a ‘diff’ of the 2 versions so I can provide a new file: zd_multilang with support for multilingual widgets.

This should supports installation on a v.1.2.2 or less version of zdmultilang.

Work around the zdmultilang plugin

Work around the zdmultilang plugin

I’ve been testing several multilingual wordpress plugins (xLanguage, qTranslate and Gengo), before I stopped on zdmultilang.

This fit what I was looking for: the ability to manage translated pages / articles with a special relationship with the original. Moreover, in order to best meet the plugin spirit, I was looking for something that leaves the platform directly operational in the event of cancellation.

For me, it only lacked a multilingual widget management. So I tried to add this functionality as I describe here.

The standardization of widgets

WordPress always uses the same pattern to store widgets data: it is a parameter name / value hash array that is stored in the wp_option table through the get_option and update_option functions. Also, in the first instance, I modified the zdmultilang language switcher widget to comply with this standard.

On the road to options by language

Zdmultilang already manages language options: blogname and blogdescription in the wp_zd_ml_langs table. However, if we want to manage widgets by language we will have to change the architecture. My choice was to create the wp_zd_ml_options table whose structure is based on the wp_options table where I added the LanguageID field. This table contains all the options I wanted to keep in a specific language. So, I put there blogname and blogdescription as this place now seemed legitimate.

Exemple de la table wp_zd_ml_options

How to build dynamic hooks for our widgets?

As said before, the parameters of the widgets are stored in the wp_options table. So, in order to stay as closed as possible to the WordPress architecture, it seemed appropriate the use the pre_option_... and pre_update_option_... hooks (where ... is the name of the widget) provided by the get_option and update_option functions. The use of the “pre” hook is nice as it exits the initial get_option or update_option functions almost immediately. On the other hand, this requires to completly rewrite the initiale functions inside the plugin. For consistency, most of the functions regarding options have been rewritten: get_option, update_option, add_option, load_alloptions. It always has been done using the initial WordPress functions to take advantage of caching tools as alloption and notoption avoiding to much queries to the database. This is especially useful in our case. Indeed, widgets do not always have parameters and there is no way we can get this information. So we’re going to register as much shortcut filters as widgets based on the only information we have: the $wp_registered_widgets array. Thus, if a widget does not have a parameter, we should exit very quickly thanks to notoption. That way the database shouldn’t be stressed.

Then, we still have to register our new zd_get_option and zd_update_option functions to the hooks identified above. In order to accomplish this, we get inside the $wp_registered_widgets hash array and for each widget we build a dynamic function that we register to the hook. A sample of code :

foreach($wp_registered_widgets as $widget_name => $widget) {
	$funcname = 'zd_multilang_get_option_'.$widget['classname'];
	$function = "function $funcname".'() {
			$option=str_replace("zd_multilang_get_option_","",__FUNCTION__);
			return zd_multilang_get_option($option);
			}');
	eval($function);
	add_filter('pre_option_'.$widget['classname'], $funcname);
}

Here is an exemple with the widget-text :
Imagine get_option('widget_text'); is called. Its first action is $pre = apply_filters( 'pre_option_widget_text';. As widget-text is a widget we did add_filter('pre_option_widget_text', 'zd_multilang_get_option_widget_text'); where zd_multilang_get_option_widget_text return zd_multilang_get_option('widget_text');. So call to get_option('widget_text') will lead to zd_multilang_get_option('widget_text').

Once all those shortcut filters are installed, we can recall the wp_widgets_init() which resets all widgets. But this time, it will look for the parameters in our wp_zd_ml_options table through our zd_multilang_get_option function. That sounds good: it was our goal.

How to store sidebars by language?

The sidebars are registered by the theme. Here also, we have no idea of their number. So we are going to keep an additional option equivalent to sidebars_widgets option that contains information on the content of sidebars. Our option will contain nb of sidebars in the theme x nb of languages dealt by zd_multilangue elements. Then we will rebuild on the fly the result WordPress expects to find based on the context (simple blog reading or administering widgets through the admin screen).

How users will administer widgets in each language?

In the beginning I wanted to make a setup screen for widgets a bit like zdmultilang manages categories, tags … However, the management of widgets by WordPress (wp-adminwidgets.php) is not obvious ( work in case of javascript deactivation, compute modified data if ever before displaying anything …). Also, I finally resigned myself to add a language selector to the initial widgets admin page. Again, the hooks offered by WordPress don’t help so much and make the code non trivial. But, at last, it works.

Copie d'écran du sélecteur de langue dans le gestionnaire de widget

How to test those changes to the plugin?

You can access my code by following this link: zd_multilang with support for multilingual widgets but it comes with the status: it works for me. In addition, you may lose your blogname and blogdescription data by language if you decide to revert to an earlier version.

Don’t forget to leave your comments in case of test.