Robert Basic's blog

Archive for the 'Software' category

XFCE4 desktop zooming with the keyboard

by Robert Basic on January 19, 2017.

XFCE4 has a zoom feature available when the desktop composition is turned on. By default, holding the Alt key and scrolling up or down the mouse wheel, I can zoom in or out the entire desktop. Once zoomed in, it follows the mouse pointer as to which part of the desktop to show.

I prefer doing as much as possible from my keyboard, and to use the mouse only when necessary.

I don’t care much for desktop composition, the transparent windows and animations are not my thing.

Toggle desktop composition

Given that desktop composition is required for the zooming feature, I want it enabled only when I want to use the zoom feature itself.

Using the following command, I can toggle the composition on and off:

xfconf-query --channel=xfwm4 --property=/general/use_compositing --type=bool --toggle

xdotool to fake the mouse

xdotool is a nice little program that fakes keyboard and mouse input, among other things.

Using that, running the following command from the terminal, zooms in:

xdotool keydown Alt click 4 keyup Alt

and this command zooms out:

xdotool keydown Alt click 5 keyup Alt

Just to make all this even easier, I put these commands in a couple of bash scripts and added them as keyboard shortcuts.

Now I have Super C to toggle the desktop composition, Alt + to zoom in and Alt - to zoom out.

Happy hackin’!

Tags: accessibility, compositing, desktop, keyboard, mouse, xfce4, zoom.
Categories: Blablabla, Software.

Force Python version in Vim

by Robert Basic on January 12, 2017.

Vim can be compiled with Python support. Vim can be compiled with both Python 2 and Python 3 support.

At the same time.

But not really.

Vim can have both of them, but use only one at a time. If you start using one version, there is no way to switch to the other one.

The silly thing is that if you simply ask Vim which version does it support, the first one asked and supported is going to be the one loaded and used. Trying to use the other one from that point will result in an error.

if has('python')
elif has('python3')
endif

Guess which one is loaded? Python 2.

Try calling Python 3 and ka-boom!

:py3 print('hello')
E836: This Vim cannot execute :py3 after using :python

Switch the order around:

if has('python3')
elif has('python')
endif

And now? Yup, Python 3.

Why is this ridiculous? Because if you have a bunch of Vim plugins loaded, the first one that asks for a specific Python version wins! Reorder the plugins and suddenly a different Python version is loaded.

Gotta love the software development world.

Luckily, this can also be used to fix the problem itself.

How?

Force one of the Python versions from the top of your .vimrc file:

if has('python3')
endif

Now you can have a little bit of sanity and be sure what Python version is Vim going to use. Of course, doing this might break plugins written solely for Python 2, so do it at your own risk.

Happy hackin’!

Tags: python, vim, vimrc.
Categories: Development, Software.

Issues with Vagrant after upgrading to Fedora 25

by Robert Basic on December 24, 2016.

Fedora 25 was released over a month ago, so I decided it was time to upgrade from 24.

Using the dnf plugin system-upgrade the entire process went smooth. The Fedora Magazine, as always, has a nice post on how to upgrade.

So far I ran into only a couple of minor issues with Vagrant.

The first one, which isn’t really a problem, is that Vagrant got downgroaded to version 1.8.x from 1.9.1 which I had installed in Fedora 24. The fix for that is easy, just install the new version again:

robert@odin ~$ sudo dnf install ~/Downloads/vagrant_1.9.1_x86_64.rpm

The second issue was that, well, vagrant didn’t really want to work. When trying to run vagrant up it would spit out the usual kernel module is not loaded error.

The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:

VirtualBox is complaining that the kernel module is not loaded. Please
run `VBoxManage --version` or open the VirtualBox GUI to see the error
message which should contain instructions on how to fix this error.

Running VBoxManage --version provided a helpful message, for once:

robert@odin ~$ VBoxManage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (4.8.15-300.fc25.x86_64) or it failed to
         load. Please try load the kernel module by executing as root

           dnf install akmod-VirtualBox kernel-devel-4.8.15-300.fc25.x86_64
           akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service

         You will not be able to start VMs until this problem is fixed.
5.1.10r112026

Looking at the list of installed packages with dnf list installed I saw that both the akmod-VirtualBox and the kernel-devel packages are installed.

Running the next command fixed the issue:

robert@odin ~$ akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service
Checking kmods exist for 4.8.15-300.fc25.x86_64            [  OK  ]

VBoxManage shows no warnings any more:

robert@odin ~$ VBoxManage --version
5.1.10r112026

and Vagrant works just fine again.

Happy hackin’!

Tags: akmod, fedora, vagrant, vboxmanage, virtualbox.
Categories: Development, Software.

Using Doctrine DBAL with Zend Expressive

by Robert Basic on December 22, 2016.

The Doctrine project comes with a database abstraction and access layer — Doctrine DBAL — which I prefer over other abstraction layers like Zend DB.

My good friend James, aka Asgrim, has written already how to integrate Zend Expressive and Doctrine ORM.

But what if want to use only the DBAL with Zend Expressive, and not the entire ORM?

It’s pretty easy as all we need to do is write one short factory that will create the database connection using the connection parameters we provide to it:

src/App/Infrastructure/Database/ConnectionFactory.php

<?php declare(strict_types=1);

namespace App\Infrastructure\Database;

use Doctrine\DBAL\DriverManager;
use Doctrine\DBAL\Driver\Connection;
use Interop\Container\ContainerInterface;

class ConnectionFactory
{
    public function __invoke(ContainerInterface $container) : Connection
    {
        $config = $container->get('config');
        $connectionParams = $config['db'];

        return DriverManager::getConnection($connectionParams);
    }
}

Configuration of the database connection is pretty straightforward as well:

config/database.php

<?php declare(strict_types=1);

return [
    'db' => [
        'driver' => 'pdo_pgsql',
        'dbname' => 'database_name',
        'user' => 'username',
        'password' => 'password',
        'host' => 'localhost',
        'port' => 5432,
    ]
];

For other options and possible values, take a look at the configuration documentation.

Next, we configure a container-interop service locator, like Zend ServiceManager to be able to access the database connection in parts of the application where we need it. This configuration consists of mapping a factory name to the ConnectionFactory factory:

config/dependencies.php

<?php declare(strict_types=1);

return [
    'dependencies' => [
        'factories' => [
            'db' => App\Infrastructure\Database\ConnectionFactory::class,
            // other factories ...
        ],
        // other type of dependencies ...
    ]
];

Now all we need to access the database connection is to grab it from the ContainerInterface container somewhere in our application and we’re all set:

src/App/SomeObjectFactory.php

<?php declare(strict_types=1);

namespace App;

use Interop\Container\ContainerInterface;

class SomeObjectFactory
{
    public function __invoke(ContainerInterface $container) : SomeObject
    {
        $connection = $container->get('db');
        return new SomeObject($connection);
    }
}

We can now use this $connection object to further create the query builder, work with transactions, the schema manager and other features the Doctrine DBAL provides us. Nice and easy.

Happy hackin’!

Tags: dbal, doctrine, zend expressive.
Categories: Development, Programming, Software.

Anatomy of a git diff

by Robert Basic on December 20, 2016.

I’m looking at git diffs every day, all day. Diffs hold a lot of information that can be valuable, and I think it’s a good thing to know how to fully read a git diff.

A simple diff looks something like this:

diff --git a/example.php b/example.php
index a5174a9..11aeb84 100644
--- a/example.php
+++ b/example.php
@@ -11,7 +11,10 @@ class Greeter
         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

This simple example holds most of the information that is needed from a diff.

The first line tells that the diff is in the git format and the filename(s) before and after the changes.

The second line tells about the type of file and its permissions (100644) and the two hashes are just that - shortened hashes of the pre- and post-images. AFAIK, this line is used when doing 3-way merges.

The lines 3 and 4 again deal with the name of the file(s). If it’s a new file, the source - --- - is /dev/null, and if an existing file was deleted, the target - +++ - will be /dev/null.

I’ll skip line 5 for a moment and come back to it later.

The next part, the actuall diff, shows what lines in the current hunk were added and what lines were removed:

         $this->name = $name;
     }
 
-    public function greet()
+    /**
+     * Return the greeting message.
+     */
+    public function greet() : string
     {
         return sprintf("Hello %s" . PHP_EOL, $this->name);
     }

Lines that start with a + sign were added, and lines with a - sign were removed. Lines with no + or - are here just to give us some context of the code. Looking at this diff we see that one line was removed and 4 lines were added.

Now back to line 5 as this is probably the hardest part to understand:

@@ -11,7 +11,10 @@ class Greeter

These numbers always seemed random to me.

This line is, I belive, called “unified diff hunk identifier”, and the format of this line is:

@@ from-file-range to-file-range @@ [header]

which to be honest, isn’t that helpful. The @ signs are just delimiters.

The first pair of numbers, -11,7, means that the current hunk in the source file starts at line 11 and has a total of 7 lines.

The starting line can be confirmed in any editor: $this->name = $name; really is the 11th line in the edited file. That’s easy.

The number 7 means that there are 7 lines in total that have a - sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a -, skipping the lines with the + at the beginning, we see the total is 7.

The second pair of numbers, +11,10 means that the current hunk in the target file starts at line 11 and has a total of 10 lines.

The number 10 means that there are 10 lines in total that have a + sign or no sign at all (contextual lines). If we count the number of contextual lines and lines with a +, skipping the lines with the - at the beginning, we see the total is 10.

Finally, class Greeter, the [header] part of this line, tells us were did the change happen. This may, or may not, be present.

This example is a simple one, but I think it covers most of the use cases of a git diff output, and it helps us understand the unified diff hunk identifier line (the line with @@s), which is useful to know, especially when editing git hunks manually.

Happy hackin’!

Tags: diff, git, hunk.
Categories: Development, Software.