Gnome Wayland Screenshot tools (2018)

Most screenshot tools broke in Wayland. But luckily the developer community caught up quickly and we have a few functional alternatives.

Besides the native gnome-screenshot tool (which is a bit slow for heavy screenshotters) there are two other functional tools:

(Btw, I’m on Fedora 28, if you’re not, your milage may vary).

Fastest Tool:

If you’re looking for a 1-click thing without annotation, then Gnome-extension Screenshot Tool by oal is your friend.

Useful features include:

• Configurable to be ‘one click on toolbar’ to make screenshot (Primary button option).
• Auto copy to clipboard & autosave
• Area/window/screen
• Imgur & auto-upload support.
• Keybindings

Installation:
1) (If not done so already) Install Gnome extension support for your browser.

• Firefox
• Chrome
• Opera

2) (If not done so already) Also install the native connector (in addition to browser plugin).

On Fedora: dnf install chrome-gnome-shell

3) Install the extension:

https://extensions.gnome.org/extension/1112/screenshot-tool/

As a note, at time of writing, the area-selection seemed to include a blue overlay. Haven’t found a way around it so I use Flameshot for area screenshots.

Most Feature Rich : Flameshot

Features include:

• Rich annotation tools. (Pencil, arrows, shapes, blurring)
• Rich set of export tools (copy to clipboard, open in app, save, upload).
• But missing ‘add text to screenshot’ at the moment (May 2018), which shutter had.

Installation:

• sudo dnf install flameshot
• See also github page

Double click on the status-bar icon & (wait for 2-3 seconds) to select area to screenshot.

 

Happy screenshotting!

 

Eclipse + Flatpak Quick-start guide

Today I’m experimenting with the Eclipse to Flatpak port that our team has been working on.

To do so, I had to learn Flatpak.  It only took 10 minutes to learn the basics needed to survive. I.e adding/listing Flapack repos, installing & removing packages.

Flatpack basics:

• Flatpak is basically a package management system like yum/dnf/apk-get + version defined container for running gui apps.
• Flatpak word does not contain a ‘c’. (I was wondering why flatpack could not be found on my system).
• (Most?) of flatpak can be used via Software Center GUI, but I prefer the command line version as I need to manage repos.
• The command line has very good tab-completion I’ve litereley figured things out by pressing tab when ever I wonder what argument to type next.
• Flatpak is already installed on recent Fedora builds, but by default it has no repositories to feed from. You can add the flathub by opening it from here:
  https://flatpak.org/setup/Fedora/
  To verify that you’ve added the repo, you can list repos via:

  flatpak remote-list
  

• To list available packages:

  flatpak remote-ls
  

• To install these: (e.g I tested with Zotero)

  flatpak install org.zotero.Zotero
  flatpak install flathub org.zotero.Zotero  #if you want to specify which repo to install from
  

• To remove a package:

  flatpak uninstall org.zotero.Zotero
  

 

Eclipse in flatpak

Now I went a head and fidlded around with using Eclipse from Flatpak.
Eclipse comes in it’s own repository, as document by Mat Booth.
To set things up:

# Add the 'eclipse' repo. 
flatpak remote-add --if-not-exists eclipse https://fedorapeople.org/~mbooth/flatpak/eclipse.flatpakrepo

# Btw, if you want to delete a repo in the future, it's easy:
flatpak remote-delete eclipse     #again, tab completion is your friend.

# To see what's in Mat's eclipse repo, you can list it's content:
flatpak remote-ls eclipse
  org.eclipse.Committers   # I'm a committer, so I'm gonna go with this version.
  org.eclipse.Cpp 
  org.eclipse.Java 

flatpak install eclipse org.eclipse.Committers  #this asks if you want to install gnome 3.24 run time. Say yes.

Now you can run eclipse either via overviews or via command:

flatpak run org.eclipse.Committers

# or with environment variable:
YOUR_ENV_VAR=VALUE flatpak run org.eclipse.Committers

And voila, Eclipse is up and running:

Also useful:

# look for stuff in your flatpak
flatpak search vlc

# Update packages in the future:
flatpack update

# list what's installed
flatpak list
flatpak list --app #only list apps.

 

References:

• Good quick start: http://docs.flatpak.org/en/latest/using-flatpak.html
• Fedora mag:
  https://fedoramagazine.org/getting-started-flatpak/
  https://fedoramagazine.org/install-flathub-apps-fedora/
  https://fedoramagazine.org/explore-flatpak-fedora-24/

Make applications (Eclipse) use x11 backend on Wayland (Fedora 25)

I upgraded to Fedora 25 (beta), which by default uses the new Wayland display server, (which is a replacement for x11).

MatterMost native chat client (like slack/IRC) on Linux

 

So today I bumped into https://mattermost.eclipse.org 

This is like slack (sort of modern IRC) but open source.

I also found that is has a Linux Native client:
https://about.mattermost.com/downloads/

To get it to work, I just downloaded it, extracted it and ran the included “Mattermost” binary.

Connecting it to Eclipse was mildly counter intuitive.

When faced witht he ‘Teams’ dialogue, I thought I had to  type in Name OR URL, but it turns out you type in both. The name is just an alias ex “Eclipse”, and for URL you put in:

https://mattermost.eclipse.org/

Ex:

After you joined, you can find some channels to join. In my case:

Platform: SWT

Now when someone wants to chat with you, you can give them the URL:
https://mattermost.eclipse.org/eclipse/channels/platform-swt

Happy MatterMost-ing

Ramdisk for the impatient.

I have a pci-e based storage working at close to 1000mb/s (Mac Pro). I do lots of GCC/make compilations. What if you want things even faster than with a pcie? Then ramdisk is your friend.

My results:

• With Regular SSD:  2 minutes and 37 seconds   (on my co-worker’s machine w/Fedora)
• With my pci-e disk: 2 minutes and 35 seconds (my Mac w/Fedora)
• With Ramdisk:           1 minute and 15 seconds (my Mac w/Fedora)

So we have ~50% improvement in compilation time. For me, it’s worth the effort.

To set one up: Follow this guide

I.e:

[code language='bash']
sudo mkdir /mnt/ramdisk
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk
[/code]

To see how much of it is still available:

df -h

You might want to write an rsync script to copy folders onto the ramdisk that you want fast-access to. Ex a git repo that you compile frequently, some application binaries that you run. But obviously avoid putting data onto the disk.

 

 

 

(5 minute guide) How to upgrade Fedora 20 to Fedora 21 with Fedup

It’s that time of the year. We are all super busy, so this is a super short upgrade guide.

Assuming that you use Fedora as a workstation (as oppose to server) the below is for you:

Nautilus & Fedora: Open terminal from context menu

This article explains how to install a package to add a right-click menu to open the terminal from Nautilus.

Nautilus: Copy path to clipboard context menu

I find myself copying the path of a folder quite a lot. (mostly to use in Terminal)

Getting hold of the path is somewhat cumbersome thou.
Here is a 5 minute guide on adding a context menu option to do the job for you:

How to create cross-platform SWT applications packaged in a single jar in Eclipse

The deal with SWT is that you geneally create a jar that runs nativley on a single platform.

This means that if you want to create an application that works on windows/mac/linux in both 32/64 bit, then you need to compile/package jar 6 files and distribute one file per platform.

This is very cumbersome for small projects where you want a single file that runs on every platform.

The solution is to bundle the jars and load them dynamically with Mchr3k’s SWT Jar loader.

The next challenge is how to get this business working in Eclipse. Well, there is a guide for this.

Basically, you create a project with the name “HelloWorld”, you have to
download the swt jar’s and rename them to match os/version and then you
have to add a build.xml file. This takes about 30 minutes.

I followed the guide and actually got it to work.

To make life easier, I created a git-repo with a template project.  You can clone it and start a SWT project with that.

I used swt 4.4 in the project. In the future you might want to update it. To do so:

• Download the latest jar files from Eclipse’s download site .
  • click on the most recent version, e.g ‘4’4,
  • then search for “SWT Binary and Source”
  • download the Windows 32/64 Versions,   linux x86/x86_64/GTK+ versions, Mac OS X versions
  • open the archives and extract the ‘swt.jar’ files
  • match the jar files to the jar files in the project ./gui folder. But append new version. (4.4 -> 4.x)
• Edit the build.xml file,
  • change the “swtversion=”4.4″” to the newer version.
  • Also update <fileset dir=”./gui” includes=”swt-*-4.4.jar” />

Screen shots:

Linux

You can run the generated jar file with ‘java -jar crossSWT.jar”:

OS X

Here I had to launch the jar with a special paramater:
java -jar -XstartOnFirstThread crossSWT.jar

Windows

I don’t use windows :-), but rumors has it works on windows also.

How to compile various gtk3 versions and run eclipse Apps with those (for SWT Widget testing)

When developing SWT widgets, we need to test them on various GTK versions to ensure backwards compatibility.

There are some tricks and perks involved.

Get Gtk sources

• Go to the gtk git repo and pull the code: https://git.gnome.org/browse/gtk+/
  (I recommend the https version: https://git.gnome.org/browse/gtk+)
  (if you don’t know how to use eclipse’s EGit, read this)
• Check out the versions that you’re interested in (e.g 2.24, 3.10, 3.4, 3.8)
  These are found in major Linux distributions (e.g ubuntu 12..).
• For the time being, check out the newest gtk version (e.g 3.10 at the time of writing).
  (It’s easier to build a newer version than an older one)
• Open Terminal, go to your checked out gtk branch.
  Run the following commands:

  ./autogen.sh
  ./configure --enable-x11-backend --enable-wayland-backend
  make
  

• The first time you run the commands, you might run into errors telling you you’re missing something on your system. Inspect autogen.sh to see what it runs and then install the utilities with yum.
• Now copy gtk to another place on your system. E.g ~/src/gtk2_24 This way you don’t have to recompile this business every time.
• Now you can build the other versions and similarly copy them to ~/src/gtk*_*
• NOTE ON gtk3.4 (and maybe older) The Wayland configuration makes certain things look more correct. But sometimes it makes building older versions (like gtk3.4) near impossible due to missing dependencies. In this case, run the configure without these:

   ./autogen.sh ./configure make 

Configure Eclipse to use the gtk you compiled

• Edit your run-configuration of the code snippet that you want to run.
• Navigate to “Environmental Variables”
• Click on “Add”, type in:
  name: LD_LIBRARY_PATH
  path: #your_compiled_gtk      //e.g /home/lufimtse/src/gtk3_10/gtk/.libs
• Name your configuration (I reccomend appending gtk version, e.g “ControlExample (g3-10)”)
• It should look something like this:
  
• Now run the configuration and you should see your application rendered in gtk*.*.
  You may note that it won’t have any styling:
  
• The lack of styling is due to the fact that there is no theaming.
  Now sometimes you might want the compiled gtk to use your system theame to see impact of themes on looks.
  To do so, do as above except run the configuration as following:

  ./configure --prefix=/usr --sysconfdir=/etc --enable-broadway-backend --enable-x11-backend --disable-wayland-backend
  

  In the interest of comparison: (left native look, right bare look)
  

• Lastly, in your source code, you might want to verify that you’re running the compiled gtk and not your own. Use this line of code:

  System.out.println("GTK Version: " + OS.gtk_major_version() + "." + OS.gtk_minor_version() + "." + OS.gtk_micro_version());