This post is based on my Dell M3800 with Linux Neon.
KDE already does a good job with touchpad gestures (e.g., two fingers for scrolling, 3 finger tap for pasting, etc.) but it does not support 3 finger swype gestures like in MacOs, e.g., for displaying all the windows or for showing the desktop.
Today I tried this utility, Libinput-gestures, which works like magic! The utility comes with good default for typical gestures (including pinch) but I configured that to fit my needs (in particular, I wanted to mimic MacOs behavior for 3 finger swypes: up = display all windows, down = display all windows of the same class and for pinch out = show desktop.
The installation of Linput-gestures is really easy (just follow the instructions at its web page).
Remember that, first of all, your user must be in the input group, so first run
1
sudo gpasswd-a$USER input
Then logout from your current session, and login again.
and if you want it to be started at login time, then run
1
libinput-gestures-setup autostart
The default gestures are in /etc/libinput-gestures.conf. If you want to create your own custom gestures then copy that file to ~/.config/libinput-gestures.conf and edit it.
These are the lines I changed in my configuration (remember that each time you modify the configuration you need to restart libinput-gestures, i.e., instead of start in the command line above, just use restart):
Shell
1
2
3
4
5
6
7
8
# KDE: Present Windows (current desktop)
gesture swipe up xdotool key ctrl+F9
# KDE: Present Windows (Window class)
gesture swipe down xdotool key ctrl+F7
# KDE: Show desktop
gesture pinch out xdotool key ctrl+F12
You only need to know the keyboard shortcuts of the actions you want to associate to mouse gestures. With that respect, you might want to have a look at the current shortcuts in KDE Settings (the interesting components are “KWin” and “Plasma”):
Each project’s code is tested in a specific .tests project. The code consists of simple Java classes doing nothing interesting, and tests just call that code.
The Maven parent pom file is written such that Jacoco is enabled only when the profile “jacoco” is explicitly activated:
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<profile>
<id>jacoco</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco-version}</version>
<configuration>
<excludes>
<exclude>**/plugin1/Main.class</exclude>
</excludes>
</configuration>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
This is just an example of configuration; you might want to tweak it as you see fit for your own projects (in this example I also created a Main.java with a main method that I exclude from the coverage). By default, the jacoco-maven-plugin will “prepare” the Jacoco agent in the property tycho.testArgLine (since our test projects are Maven projects with packaging eclipse-plugin-test); since tycho.testArgLine is automatically used by the tycho-surefire-plugin and since we have no special test configuration, the pom.xml of our test projects is just as simple as this:
if you need a custom configuration, then you have to explicitly mention ${tycho.testArgLine} in the <argLine>.
Now we want to create an aggregate Jacoco report for the classes in plugin1 and plugin2 projects (tested by plugin1.tests and plugin2.tests, respectively); each test project will generate a jacoco.exec file with coverage information. Before Jacoco 0.7.7, creating an aggregate report wasn’t that easy and required to store all coverage data in a single an .exec file and then use an ant task (with a manual configuration specifying all the source file and class file paths). In 0.7.7, the jacoco:report-aggregate has been added, which makes creating a report really easy!
Here’s an excerpt of the documentation:
Creates a structured code coverage report (HTML, XML, and CSV) from multiple projects within reactor. The report is created from all modules this project depends on. From those projects class and source files as well as JaCoCo execution data files will be collected. […] This also allows to create coverage reports when tests are in separate projects than the code under test. […]
Using the dependency scope allows to distinguish projects which contribute execution data but should not become part of the report:
compile: Project source and execution data is included in the report.
test: Only execution data is considered for the report.
So it’s just a matter of creating a separate project (I called that example.tests.report) where we:
configure the report-aggregate goal (in this example I bind that to the verify phase)
add as dependencies with scope compile the projects containing the actual code and with scope test the projects containing the tests and .exec data
Now run this command in the example.parent project:
Shell
1
mvn clean verify-Pjacoco
and when the build terminates, you’ll find the HTML code coverage report for all your projects in the directory (again, you can configure jacoco with a different output path, that’s just the default):
Since, besides the HTML report, jacoco will create an XML report, you can use any tool that keeps track of code coverage, like the online free solution Coveralls (https://coveralls.io/). Coveralls is automatically accessible from Travis (I assume that you know how to connect your github projects to Travis and Coveralls). So we just need to configure the coveralls-maven-plugin with the path of the Jacoco xml report (I’m doing this in the parent pom, in the pluginManagement section in the jacoco profile):
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.