New widgets in old Glade files

Problem: disabled widgets in older Glade files

It may occur that certain widgets in Glade are greyed out after opened in Glade.


A hint is hown in tooltips like


The cause for this behaviour is the Gtk+ version given at the beginning of the file:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated with glade 3.20.1 -->
  <requires lib="gtk+" version="3.0"/>

This line will not be altered even if the file is saved by a more recent Glade version. So you just manually replace "3.0" by a current version ("3.20" at present).

BeeLine - keep on riding

Further testing of the navigation compass BeeLine

See also my introductory BeeLine article.

It's alive!

BeeLine lives. There has been made some nice development progress. You could almost assume somebody from the team read my first article because nearly everything mentioned in the improvement section has been realized.

Another positive aspect is communication. The team reacts very fast on interactions on Twitter and via e-mail. It's quite exhilaranting to experience that there are real people working behind a product/brand...(yes, I'm looking at you, Google).


My four points of criticism were:

  1. lack of practicality on waypoint handling
  2. accidentally finish rides
  3. unclear button assignments
  4. wish for better route functionalities (import)


Manual scrolling

Scrolling through route waypoints is accomplished by pressing the N/S buttons. If you reach the last waypoint you can end your ride by confirming the "Arrived?" question.

There still is no information on waypoint progress on the device but it is shown in the app.


App: waypoint status

Automatic routing

If "Automatic Waypoint" is activated in the settings the next waypoint will be selected when passing the current one less than 100 meters. If you keep a distance larger than that Beeline will not change the selected waypoint even if another waypoint is closer.

When choosing automatic waypoint routing there always remains the option to manually skip waypoints.

I regard this to be a real killer feature which makes routing simple and precise while remaining discreet and in no way annoying.

Button assignment

As already said skipping through waypoints is done by pressing the top or bottom button. Pressing and holding the bottom button switches the integrated lamp on and off. The right and left buttons let you flip through

Compass <-> Speed <-> Time <-> Battery status (phone and BeeLine) <-> Compass

It did not happen anymore that I accidentally finished a ride, so this problem vanished.

Route import (whoop, whoop)

Not only can a route be created via BeeLine app but also be imported from a GPX file. In doing so the track will be simplified and (significant) changes of direction will be converted into waypoints. Two waypoints are always connected by a straight line (beeline).


Left: imported simplified route with waypoints. Right: original GPS track in Locus app

As you can see this works pretty nice. This route conversion provides waypoints for relevant route details (important changes of direction, crossroads, bridges) without determining a certain track layout.


Only few waypoints necessary to outline route

Make a wish

To avoid this article to be suspected of being some sponsored shit I reserved some space for my personal feature requests:

Ride routes in opposite direction

This would save some work for creating routes in reverse order.

Waypoint progress

I'd like to have that waypoint progress status shown on the device like it is displayed in the app ("Waypoint 6/20"). Yes, I know that this is unrelated to distances. That information does not have to be permanently present, I can imagine it to be integrated as a page on the right/left button page scroll function.

Pause ride

A funtion to pause/continue routes instead of finishing them would be helpful (for example to proceed on long tours or when spontaneously jumping into a nearby supermarket).


We all hate it: the horseshoe symbol on the Beeline - bar left, bar right, front wheel up and agein. This is easy with the racing bike but a torture with the pannier packed trucker.

I don't really have a constructive suggestion here. The calibration horseshoe often appears during a ride and disappears after a while (sometimes within seconds). I mostly ignore it now.

Me vs. me

  1. I often ride the same routes.
  2. Everybody likes statistics.

So why not show a route summary with some information (frequency, duration, distance, speed)?


BeeLine has developed great and I will use it more frequently now. By expanding route functionalities (create, import, save, automatic routing) the device has become a really interesting and useful tool rather than just being a gadget.

Of course BeeLine still depends on a smartphone connection providing location service and Bluetooth. It cannot replace a standalone navigation system. Therefore battery consumption of the phone has to be considered on long tours. Power banks exist.

Comment on

Stacks and notebooks

Organize contents on screen

Gtk.Stack and Gtk.Notebook are layout containers that can hold any widgets.

A notebook provides a multipage layout including a classic tab functionality. A stack also provides this basic functionality and you will able to switch between different layout pages.

The main difference is the control widget of the stack is a separate widget (Gtk.StackSwitcher). Several stack switcher widgets can be assigned to one stack. A stack switcher can be placed into the headerbar and animated transitions between stack pages are supported.

Stack subjectively fit better into the GNOME environment but notebooks provide more customization/functionality options.

In the example there is a window containing a stack including a notebook on the third page showing different websites.




Stacks can be found in the sidebar's 'Container' section. Pages are easily created and edited via Glade. Sub-widgets in the example file are Gtk.Image, Vte.Terminal and Gtk.Notebook.

The stack switcher widget can be obtained from 'Controls and Display' and is placed to the headerbar. It's also possible to put it into a regular container widget like boxes. Pages can be shown in vertical or horizontal order. In "General > Stack" a stack element must be assigned to the widget. The page name shown by the stack switcher widget can be edited via "Packing > Title" of the sub-widget. This sub-widget has to be created in the first place, a new created stack has empty pages.


Notebook can also be found in the 'Container' section. The tab's control unit is an integrated label child widget automatically generated on page creation. Gtk.ScrolledWindows are used here as the pages' container widgets. These are also required for displaying (long) tables (see also List-/TreeStore articles No. 1 und No. 2).

The tab bar of a notebook provides reserved space for additional widgets like fixed buttons ("General > Start/End Action"). In the example there will be created a "Home" button in the start area.


There are no signals required for switching between stack pages and notebook tabs. In the example only two signals are assigned, one for catching the "exit" command within the terminal and one for the button in the notebook tab bar.


The webpages in the example are rendered by WebKit2. The essential module to use is WebKit2.WebView. A new WebView object itself already is a scrollable Gtk+ widget within a Gtk.Viewport element. According to the API reference it does not have to be placed in a Gtk.ScrolledWindow container widget. Having tested this that works for Gtk.Stack but not for Gtk.Notebook. That's why in the example there is used a ScrolledWindow as underlying container widget.

The following pattern is used to create a WebView widget:

#create new WebView widget
webview = WebKit2.WebView()
#send URL to widget
#add webview to notebook
#add webview to stack
stack.add_titled(webview, name, "StackSwitcher title")

Read more…

NoN: Konsoledierung

Knights of Ni - jetzt wird's schick

Einmal eingerichtet, benötigt man für das Befeuern einer Nikola-angetriebenen Seite nur einen Dateimanager, einen Editor, ein Terminal und normalerweise zwei Kommandos.

Und weil ich es gern bequem habe, habe ich mir etwas Unterstützung dafür gebastelt.

Was bisher geschah

Die per Button aufgerufenen Nikola-Kommandos wurden bisher folgendermaßen verarbeitet:

  • nikola build lief im Hintergrund als
  • nikola github_deploy wurde im separaten Terminalfenster ausgeführt; dieses wurde nach der erfolgreichen Ausführung wieder geschlossen

Und das soll jetzt alles vorbei sein?

Neu ist immer besser.

—Barney Stinson

Die Oberfläche ist nun per Gtk.Stack zweigeteilt. Per Gtk.StackSwitcher in der Headerbar lässt sich zwischen der normalen Oberfläche und einem Terminal hin- und herwechseln.

Dies hat mehrere Eigenschaften und Vorteile:

  • Das Teminal öffnet sich im aktuellen Verzeichnis der Nikola-Instanz.
  • Das Terminal kann beliebig verwendet werden.
  • Beim exit wird es nur resettet.
  • build und github_deploy werden in diesem Terminal ausgeführt, wenn sie über die Oberfläche (Buttons) gestartet werden.
  • Beim Ausführen über die Buttons wechselt der Focus auf das Terminal und nach Beenden des Tasks wieder zurück zur Oberfläche. Mit super Überblende (aktivierte Animationen erforderlich)!
  • Optisch aufgeräumter, da kein separates Fenster mehr benötigt wird.